Re: [ANN] 0.3.0 HugSQL release

[Robin Heggelund Hansen]

Fantastic release Curtis. This is an awesome 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.
For more options, visit https://groups.google.com/d/optout.

[ANN] hugsql-adapter-postgres-async 0.3.0

[Robin Heggelund Hansen]

A new release of hugsql-adapter-postgres-async is now available.

* Sync release number with hugsql release number.
* Make use of new feature in hugsql, that allows us to return all 
exceptions on the response channel.

Github: https://github.com/Skinney/hugsql-async

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Robin Heggelund Hansen]

You were right. Aleph depended on potemkin, upgrading that dependency fixed 
the problem.

onsdag 11. november 2015 12.12.40 UTC+1 skrev Alex Miller følgende:
>
> There is a Potemkin error that was exposed during 1.8 that looks like this 
> (the compile_stub) - is that library in your dependencies? If so, supplying 
> the latest version explicitly should fix the problem.

-- 
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] core.async 0.2.374

[Martin Raison]

Thanks!

Le mercredi 11 novembre 2015 14:30:34 UTC-8, Alex Miller a écrit :
>
> Dependency info:  [org.clojure/core.async "0.2.374"]
>
> This release bumps the versions of all upstream dependencies. In 
> particular, this pulls in new versions of tools.analyzer.jvm, tools.reader, 
> etc.
>
> The following bug was fixed via the tools.analyzer.jvm update:
>
>- ASYNC-149  - Fix 
>compilation of recur in case in go block
>
>

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

[Gareth Clapperton]

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

Re: [ANN] 0.3.0 HugSQL release

[Curtis Summers]

Colin,

This is a great question, and I concede that the compose-ability of
HoneySQL (and other DSLs) is almost always going to best HugSQL for the
simple reason that a Lisp is a better tool for composing than SQL is.

You could feasibly accomplish some composable queries by using HugSQL's Raw
SQL parameter type .  That seems a bit
clunky to me at scale, and I'm not sure I'd recommend it.

HugSQL is a month old, and I'm open to adding additional features that
would improve HugSQL's composable abilities.  This might include something
like SQL snippet functions and snippet parameter types.  All feedback is
welcome!

Thanks,

Curtis



On Wed, Nov 11, 2015 at 8:09 PM, Colin Yates  wrote:

> Congrats Curtis - this looks great.
>
> I do have one question: you compare in http://www.hugsql.org/#faq-dsls
> HugSQL with HoneySQL, however, the one killer feature that I use HoneySQL
> for is composable queries - or rather building up the Clojure data map
> through composition before rendering it as SQL. Is there an equivalent
> capability in HugSQL?
>
> As a trivial example, I need to be able to add joins to the query in
> response to the filters the user passes through. Equally, I will apply a
> “top X” if the user has specified that in their request and so on.
>
> Please don’t read this as ‘Honey SQL can do this, you can’t na na nana na’
> :-) It isn’t, simply asking for clarity as that comment in the page bought
> the two into comparison.
>
> Thanks, and again, congratulations!
>
> On 12 Nov 2015, at 00:51, Curtis Summers 
> wrote:
>
> I'm happy to announce the 0.3.0 release of HugSQL.
>
> HugSQL is a Clojure library for embracing SQL in your projects.
>
> This is a significant release because of the new documentation site:
>
> http://www.hugsql.org/
>
> Recent changes from 0.2.x to 0.3.0 include:
>
>- New doc site!
>- Comparison to Yesql (on doc site) - this was requested by many
>- Example application as source for doc examples (*The Princess Bride*
>themed!)
>- Tuple List Parameter Type for multi-record insert support
>- Pass-through options to the underlying database library (e.g.,
>:as-arrays?)
>- Defer adapter selection as late as possible
>- Added on-exception to HugsqlAdapter protocol to allow
>implementations to redirect exceptions (helps with usage in core.async
>channels)
>- Error checks for sql file existence, parameter mismatch errors
>- Minor bug fixes
>
> I'd like to give special thanks to Robin Heggelund Hansen, who jumped in
> early on filing issues, writing code, and making good suggestions for this
> very new project.  Robin is also the author of the HugSQL Adapter for
> postgres.async .
>
> What is HugSQL?  HugSQL...
>
>- takes the position that SQL is the right tool for the job when
>working with a relational database.
>- uses simple conventions in your SQL files to define (at compile
>time) database functions in your Clojure namespace, creating a clean
>separation of Clojure and SQL code.
>- supports run-time replacement of SQL Value Parameters (e.g., where
>id = :id), SQL Identifiers (i.e. table/column names), and SQL Keywords. You
>can also implement your own parameter types.
>- has protocol-based adapters supporting multiple database libraries
>and ships with adapters for clojure.java.jdbc (default) and clojure.jdbc
>
>
> Thanks!
>
> Curtis Summers
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/1vezOq3Ro78/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, 

Re: [ANN] 0.3.0 HugSQL release

[Colin Yates]

Congrats Curtis - this looks great.

I do have one question: you compare in http://www.hugsql.org/#faq-dsls HugSQL 
with HoneySQL, however, the one killer feature that I use HoneySQL for is 
composable queries - or rather building up the Clojure data map through 
composition before rendering it as SQL. Is there an equivalent capability in 
HugSQL? 

As a trivial example, I need to be able to add joins to the query in response 
to the filters the user passes through. Equally, I will apply a “top X” if the 
user has specified that in their request and so on. 

Please don’t read this as ‘Honey SQL can do this, you can’t na na nana na’ :-) 
It isn’t, simply asking for clarity as that comment in the page bought the two 
into comparison.

Thanks, and again, congratulations!

> On 12 Nov 2015, at 00:51, Curtis Summers  wrote:
> 
> I'm happy to announce the 0.3.0 release of HugSQL.
> 
> HugSQL is a Clojure library for embracing SQL in your projects.
> 
> This is a significant release because of the new documentation site:  
> 
> http://www.hugsql.org/ 
> 
> Recent changes from 0.2.x to 0.3.0 include:
> New doc site!
> Comparison to Yesql (on doc site) - this was requested by many
> Example application as source for doc examples (The Princess Bride themed!)
> Tuple List Parameter Type for multi-record insert support
> Pass-through options to the underlying database library (e.g., :as-arrays?)
> Defer adapter selection as late as possible
> Added on-exception to HugsqlAdapter protocol to allow implementations to 
> redirect exceptions (helps with usage in core.async channels)
> Error checks for sql file existence, parameter mismatch errors
> Minor bug fixes
> I'd like to give special thanks to Robin Heggelund Hansen, who jumped in 
> early on filing issues, writing code, and making good suggestions for this 
> very new project.  Robin is also the author of the HugSQL Adapter for 
> postgres.async .
> 
> What is HugSQL?  HugSQL...
> takes the position that SQL is the right tool for the job when working with a 
> relational database.
> uses simple conventions in your SQL files to define (at compile time) 
> database functions in your Clojure namespace, creating a clean separation of 
> Clojure and SQL code.
> supports run-time replacement of SQL Value Parameters (e.g., where id = :id), 
> SQL Identifiers (i.e. table/column names), and SQL Keywords. You can also 
> implement your own parameter types.
> has protocol-based adapters supporting multiple database libraries and ships 
> with adapters for clojure.java.jdbc (default) and clojure.jdbc
> 
> Thanks!
> 
> Curtis Summers
> 
> -- 
> 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: Style, Efficiency, and updating nested structure

[James Reeves]

In general, it's not helpful to reach for optimisations like mutability
without a benchmarking tool to tell you how much of a difference you're
making.

I'd be tempted to write something like:

  (defn find-project-index [projects id]
(first (keep-indexed (fn [i p] (if (= (:project_id p) id) i))
projects)))

  (defn update-projects [projects project]
(if-let [idx (find-project-index projects (:project_id project))]
  (update-in projects [idx :project-roles] into (:project_roles
project))
  (conj projects project))

But it seems a better idea to keep the projects in a map referenced by id.
Then find-project-index could be replaced with a key lookup.

- James

On 11 November 2015 at 21:25, 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 "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).
> ;;
>

[ANN] 0.3.0 HugSQL release

[Curtis Summers]

I'm happy to announce the 0.3.0 release of HugSQL.

HugSQL is a Clojure library for embracing SQL in your projects.

This is a significant release because of the new documentation site:  

http://www.hugsql.org/

Recent changes from 0.2.x to 0.3.0 include:

   - New doc site!
   - Comparison to Yesql (on doc site) - this was requested by many
   - Example application as source for doc examples (*The Princess Bride* 
   themed!)
   - Tuple List Parameter Type for multi-record insert support
   - Pass-through options to the underlying database library (e.g., 
   :as-arrays?)
   - Defer adapter selection as late as possible
   - Added on-exception to HugsqlAdapter protocol to allow implementations 
   to redirect exceptions (helps with usage in core.async channels)
   - Error checks for sql file existence, parameter mismatch errors
   - Minor bug fixes

I'd like to give special thanks to Robin Heggelund Hansen, who jumped in 
early on filing issues, writing code, and making good suggestions for this 
very new project.  Robin is also the author of the HugSQL Adapter for 
postgres.async .

What is HugSQL?  HugSQL...

   - takes the position that SQL is the right tool for the job when working 
   with a relational database.
   - uses simple conventions in your SQL files to define (at compile time) 
   database functions in your Clojure namespace, creating a clean separation 
   of Clojure and SQL code.
   - supports run-time replacement of SQL Value Parameters (e.g., where id 
   = :id), SQL Identifiers (i.e. table/column names), and SQL Keywords. You 
   can also implement your own parameter types.
   - has protocol-based adapters supporting multiple database libraries and 
   ships with adapters for clojure.java.jdbc (default) and clojure.jdbc


Thanks!

Curtis Summers

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

[Rangel Spasov]

I have been using Specter https://github.com/nathanmarz/specter recently 
with great success for doing all kinds of transformation:

(let [project-id 10
  new-role :r3
  projects
  [{:project-id 1 :project-roles [:r1]}
   {:project-id 2 :project-roles [:r2]}]

  ^IPersistentVector project-exists? 
  (s/select [s/ALL :project-id #(= % project-id)] projects)]
  
  (if (not (empty? project-exists?))
;project exists, transform with specter
(s/transform
  [s/ALL
   (fn [x] (= project-id (get x :project-id)))
   :project-roles]
  (fn [x]
(conj x new-role))
  projects)
;doesn't exist, simply conj to the vector
(conj projects {:project-id project-id :project-roles [new-role]})))

On Wednesday, November 11, 2015 at 1:25:51 PM UTC-8, 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 "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

Re: Style, Efficiency, and updating nested structure

[Michael Gardner]

- Worrying about the performance of a small, pure function like this is almost 
certainly premature optimization.

- Avoid concurrency constructs like atoms if you don't need them.

- Have you considered using group-by?

> On Nov 11, 2015, at 13:25, 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 "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 

Re: Style, Efficiency, and updating nested structure

[Atamert Ölçgen]

Hi Dave,

I would prefer functional approach (the latter, one without atoms and
reset!) over the one with mutable local state.

I would also refactor the update case as a separate function.

Both are from the style perspective.

I would try to optimize after I'm happy with how the code reads. And
definitely do that using data (benchmarks) instead of intuition.

As a side note, a set might be a better choice for :project_roles, vectors
allow duplicates.


On Wed, Nov 11, 2015 at 11:25 PM, 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 "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

Re: Style, Efficiency, and updating nested structure

[Nelson Morris]

I can't speak much to the efficiency analysis, but if I was solving the
problem I would attempt to change the data structure. If the `proj-roles`
could be a map then everything could be quick map updates.  Given you run
this in a loop to aggregate everything perhaps converting to that form
before hand is an option. Then at the end the map could be expanded out
into the vector form the rest of the application wants. Something like:


(defn order-roles [roles]
  (filterv roles [:own :edit]))
;; add other roles here
;; if ordering doesn't matter then use (vec roles) or roles

(defn expand [permissions]
(mapv (fn [[[id name] roles]]
{:project_id id
 :project_name name
 :project_roles (filterv roles ordered-permissions)})
  permissions))

(defn add-role [permissions id name role]
(update-in permissions [id name] (fnil #(conj % role) #{})))

;; Examples
(-> {}
(add-role 1 "One" :own)
(add-role 2 "Two" :edit)
expand)
[{:project_id 1, :project_name "One", :project_roles [:own]}
 {:project_id 2, :project_name "Two", :project_roles [:edit]}]

(-> {}
(add-role 1 "One" :own)
(add-role 1 "One" :edit)
expand)
[{:project_id 1, :project_name "One", :project_roles [:own :edit]}]

On Wed, Nov 11, 2015 at 3:25 PM, 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 "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
> 

[ANN] core.async 0.2.374

[Alex Miller]

Dependency info:  [org.clojure/core.async "0.2.374"]

This release bumps the versions of all upstream dependencies. In 
particular, this pulls in new versions of tools.analyzer.jvm, tools.reader, 
etc.

The following bug was fixed via the tools.analyzer.jvm update:

   - ASYNC-149  - Fix 
   compilation of recur in case in go block

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

Rich pushed a commit to master that will now detect this invalid primitive 
type hint and throw a compiler error.

Shantanu - your asphalt library will fail due to this new compile error. 
You should change your two ^int type hints to casts instead (int ...) to 
fix the error. FYI, this type mismatch was ignored (effectively a no-op) 
until the change from CLJ-1533 in 1.8.0-alpha2 which is why we did not see 
it previously.

On Wednesday, November 11, 2015 at 8:23:16 AM UTC-6, Nicola Mometto wrote:
>
> To be honest I'm not sure this should even be a valid use of type hints.
> You're telling the compiler that the result of (foo) is an int, when it is 
> infact a long.
>
> The correct way to do this should be:
>  (Integer/bitCount (int (foo))
>
> Again, lack of specification on what the correct type hinting semantics 
> should be make it hard to evaluate if this should be considered a bug or 
> just an user error that previously just got ignored.
>
> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
>
> Thanks, Nicola!
>
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846
>
> Shantanu
>
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
>>
>> Here's a minimal repro case:
>>
>> user=> (defn foo ^long [] 1)
>> #'user/foo
>> user=> (Integer/bitCount ^int (foo))
>> VerifyError (class: user$eval13, method: invokeStatic signature: 
>> ()Ljava/lang/Object;) Expecting to find integer on stack 
>>  java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
>>
>>
>> On 11 Nov 2015, at 07:46, Shantanu Kumar  wrote:
>>
>> One of my libraries (https://github.com/kumarshantanu/asphalt) is 
>> failing to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is 
>> below:
>>
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>> at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>> at clojure.lang.Compiler.eval(Compiler.java:6918)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>> at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>> at asphalt.test_util$eval198.invoke(test_util.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at 
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>> at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>> at asphalt.core_test$eval192.invoke(core_test.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.la

Style, Efficiency, and updating nested structure

[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) - g

Re: [ANN] Let's make clojure.org better!

[Colin Yates]

I don’t know how feasible that is as a tool lives in a much smaller space than 
everything you can do with that tool. “programming through Clojure” feels a bit 
like teaching Carpentry through examine a hammer…

On the other hand, do I think the Clojure community have some excellent ideas 
on how to program - absolutely. Most of the value I find from the various 
Clojure related videos are nothing to do with Clojure per-sa but to do with 
programming. Complicating, simple v easy and so on.

I do think there would be much value in a page of programming related resources 
that the community consider are ‘good’ but I am not sure that is the same set 
of resources as “I don’t know how to program, how do I learn”…

I wonder whether a related page of “how Clojure helped upgrade my programming” 
might be valuable...

> On 11 Nov 2015, at 20:24, Harrison Maseko  wrote:
> 
> Content idea: Would be nice to have a section for new-comers to programming, 
> introducing them to programming through Clojure. All of the existing Clojure 
> books that I know of are aimed at those with intermediate to advanced 
> programming skills in Clojure or another language. The content and learning 
> gradient in those books can be steep and could put off a beginner. Although 
> Clojure is such an advanced language, I think it's possible to implant 
> programming concepts in a complete beginner by using a subset of Clojure. But 
> maybe the the clojure.org Website is not the right place for that?
> Thanks,
> H
> 
> On Tuesday, November 10, 2015 at 5:57:45 PM UTC+2, Alex Miller wrote:
> Hi Hildeberto,
> 
> I built spikes of the site in a number of technologies like Cryogen, Stasis, 
> Sphinx, Asciidoctor, and some of the other Ruby-based static generators as 
> well. In the end, I found that JBake was the best match for our goals at this 
> time. The site build architecture has been decided and we're not interested 
> in revisiting that at this time. At some point down the road, based on 
> experience and tool evolution, we may take another look, but not soon. 
> 
> Cryogen is a great tool and I would recommend it to others. One problem I had 
> with it was its flexibility with respect to the url structure. I actually 
> think for the purposes of creating a blog etc that is a dimension that is 
> good to remove, but it was a downside for our use. 
> 
> We are working with a designer on the site look and feel and at some point 
> that will be visible. At the point where that is visible, I expect there will 
> be some evolution on front page, navigation structure, etc and would be happy 
> to get feedback on that.
> 
> Right now, we are primarily looking for content ideas and would love thoughts 
> on that. Or if there is interest in enhancing existing pages, I would also 
> like to talk about those.
> 
> Thanks,
> Alex
> 
> 
> 
> On Tuesday, November 10, 2015 at 9:41:40 AM UTC-6, Hildeberto Mendonça wrote:
> That's a great initiative! Thanks! But I'm just sad to see JBake instead of 
> Cryogen (https://github.com/cryogen-project/cryogen-core 
> ) which is written in 
> Clojure :-( Can we send a pull request replacing JBake by Cryogen or is JBake 
> a final decision?
> 
> -- 
> Hildeberto Mendonça, Ph.D
> Blog: http://www.hildeberto.com 
> Twitter: https://twitter.com/htmfilho 
> 
> -- 
> 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] Let's make clojure.org better!

[Harrison Maseko]

Content idea: Would be nice to have a section for new-comers to 
programming, introducing them to programming through Clojure. All of the 
existing Clojure books that I know of are aimed at those with intermediate 
to advanced programming skills in Clojure or another language. The content 
and learning gradient in those books can be steep and could put off a 
beginner. Although Clojure is such an advanced language, I think it's 
possible to implant programming concepts in a complete beginner by using a 
subset of Clojure. But maybe the the clojure.org Website is not the right 
place for that?
Thanks,
H

On Tuesday, November 10, 2015 at 5:57:45 PM UTC+2, Alex Miller wrote:
>
> Hi Hildeberto,
>
> I built spikes of the site in a number of technologies like Cryogen, 
> Stasis, Sphinx, Asciidoctor, and some of the other Ruby-based static 
> generators as well. In the end, I found that JBake was the best match for 
> our goals at this time. The site build architecture has been decided and 
> we're not interested in revisiting that at this time. At some point down 
> the road, based on experience and tool evolution, we may take another look, 
> but not soon. 
>
> Cryogen is a great tool and I would recommend it to others. One problem I 
> had with it was its flexibility with respect to the url structure. I 
> actually think for the purposes of creating a blog etc that is a dimension 
> that is good to remove, but it was a downside for our use. 
>
> We are working with a designer on the site look and feel and at some point 
> that will be visible. At the point where that is visible, I expect there 
> will be some evolution on front page, navigation structure, etc and would 
> be happy to get feedback on that.
>
> Right now, we are primarily looking for content ideas and would love 
> thoughts on that. Or if there is interest in enhancing existing pages, I 
> would also like to talk about those.
>
> Thanks,
> Alex
>
>
>
> On Tuesday, November 10, 2015 at 9:41:40 AM UTC-6, Hildeberto Mendonça 
> wrote:
>>
>> That's a great initiative! Thanks! But I'm just sad to see JBake instead 
>> of Cryogen (https://github.com/cryogen-project/cryogen-core) which is 
>> written in Clojure :-( Can we send a pull request replacing JBake by 
>> Cryogen or is JBake a final decision?
>>
>> -- 
>> Hildeberto Mendonça, Ph.D
>> Blog: http://www.hildeberto.com
>> Twitter: https://twitter.com/htmfilho
>>
>

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

On Wednesday, November 11, 2015 at 2:03:07 PM UTC-6, Andy Fingerhut wrote:
>
> Results of some testing done on 1.8.0-RC1:
>
> Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.  
> Reason: there have been (or still are) build or test failures with some of 
> them.  All JDKs listed below were 64-bit.
>

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.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Andy Fingerhut]

Results of some testing done on 1.8.0-RC1:

Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.
Reason: there have been (or still are) build or test failures with some of
them.  All JDKs listed below were 64-bit.

Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_80-b15: ok 3/3 trials
Ubuntu 14.04.3 LTS + OpenJDK 1.7.0_85: ok 3/3 trials
Ubuntu 14.04.3 LTS + IBM JDK 1.7.0: ok 10/10 trials, as long as failing
tests mentioned in http://dev.clojure.org/jira/browse/CLJ-1678 are
commented out
Ubuntu 14.04.3 LTS + IBM JDK 1.8.0 (based on jdk8u51-b15): same as for IBM
JDK 1.7.0
Mac OS X 10.11.1 + Oracle JDK 1.8.0_11: ok 631/631 trials

There were some JVM crashes during 'mvn test' that I have seen with an
earlier version of IBM JDK 1.8.0 (based on jdk8u45-b13), but with the
version mentioned above those seem to be gone.  The older one failed 5 out
of 10 trials.  The newer one gave passing test results with no JVM crash 10
out of 10 trials.

I plan to, but haven't yet, compared Eastwood results with 1.8.0-RC1 vs.
1.7.0.  That will take some work before I can give those results, primarily
updating Eastwood to work with 1.8.0-RC1.  Eastwood makes some assumptions
about the structure of ASTs (abstract syntax trees) that 1.8.0-RC!'s
:rettag addition changed.  I don't think it is much work, but not sure when
I will be able to get to it.  Until then, I have the following message near
the beginning of Eastwood's README:

It has been tried with some of the Clojure 1.8.0-alpha versions, but there
are known problems there (e.g. incorrect warning about misplaced
docstrings, perhaps incorrect warnings about wrong tags, etc.)

Andy


On Tue, Nov 10, 2015 at 9:30 AM, Alex Miller  wrote:

> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!*
> We would appreciate any and all testing you can do on your own libraries or
> internal projects to find problems. If no problems are found, we expect to
> make this the 1.8.0 final release!
>
> Try it via
>
>- Download:
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
> --
> 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: Pareto's Clojure

[Eric Normand]

Hi Sayth!

This is quite an interesting question.

I would dive into the abstractions at the core of Clojure: Seq, 
Associative, Fn, and Deref. Having a good grasp of these will give you a 
nice foundation into what the language is all about.

Seq
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/ISeq.java
Seqs represent sequences and they are typically accessed with `first` and 
`rest`.

What things implement this?
all collections, nil, Strings, and Iterators

Used by:

map, filter, reduce, doseq, for, into, etc

Associative
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Associative.java
Represents collections that have a key or index.

What things implement this?
maps, sets, vectors

Used by:
get, contains?

Fn
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java
Fn abstraction represents anything callable.

What things implement this?
fns, keywords, vectors, maps, vars

Use by:
any higher-order function

Deref
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IDeref.java
Used for deferred references (boxed pointers) to get the value pointed to.

What things implement this?
ref, var, atom, agent, future, delay, promise

Wow, that was kind of fun.

Eric



On Tuesday, November 10, 2015 at 5:27:44 PM UTC-6, Sayth Renshaw wrote:
>
> Morning 
>
> Currently driving through Clojure country reading Clojure for the brave 
> abs typing examples out of the clojure cookbook. 
>
> Following Paretos principle 80/20 rule the 20% usually drives the 80% of 
> outcomes. if I did a deep dive into the most important 20% of clojure what 
> would I dive into? 
>
> Cheers 
>
> Sayth

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

In this case, I am definitely in agreement with FD that producing invalid 
bytecode does not seem like an acceptable outcome. The other two options 
are a compiler error or having the compiler ignore or resolve the mismatch 
such that it produces valid bytecode. Rich is looking at it.

On Wednesday, November 11, 2015 at 9:59:24 AM UTC-6, Nicola Mometto wrote:
>
> Clojure has a history of adopting the GIGO approach
>
>
>

-- 
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] Let's make clojure.org better!

[Alex Miller]

On Wednesday, November 11, 2015 at 10:27:34 AM UTC-6, Nelson Morris wrote:
>
> Is there a list of reviewers and editors?
>

In the interest of getting this public, I did not wait to figure out all 
the details of the review and editing process before we made the 
announcement. I am hoping to get a feel for volume and workload as we get 
going too to inform the process. For the moment, I will serve as the 
reviewer for all submissions. Rich will serve as editor for the reference 
portions of the content and I will serve as editor for the rest.

Over time these lists will expand and include people both inside and 
outside Cognitect.


-- 
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: Pareto's Clojure

[Alan Thompson]

Finish reading CFBT, and add "Living Clojure".  Then read the other ones
and keep the Clojure Cookbook handy for concrete examples on specific
tools. Don't forget "Web Development with Clojure" for a focused tutorial
on that topic.
Alan

On Tue, Nov 10, 2015 at 3:23 PM, Sayth Renshaw 
wrote:

> Morning
>
> Currently driving through Clojure country reading Clojure for the brave
> abs typing examples out of the clojure cookbook.
>
> Following Paretos principle 80/20 rule the 20% usually drives the 80% of
> outcomes. if I did a deep dive into the most important 20% of clojure what
> would I dive into?
>
> Cheers
>
> Sayth
>
> --
> 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: Procedurally generated animation in Clojure

[Christopher Small]

Oh; and nice work Mike! :-)

Chris


On Wednesday, November 11, 2015 at 8:48:22 AM UTC-8, Christopher Small 
wrote:
>
> If you haven't tried it in a while, you may want to look again. They've 
> created an alternate API or mode which is more functional/immutable. 
> Perhaps that _is_ what you saw though, and you're just referring to the 
> mutable Java underpinnings leaking through...
>
> My 2c
>
> Chris
>
>
> On Tuesday, November 10, 2015 at 12:22:01 PM UTC-8, Mars0i wrote:
>>
>> Cool.  Thanks.  I experimented with the quil 
>>  wrapper around Processing 
>>  at one point.  I'm glad quil exists, but the 
>> underlying non-functional-programming model of Processing can sometimes 
>> make it awkward.
>>
>

-- 
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: Procedurally generated animation in Clojure

[Christopher Small]

If you haven't tried it in a while, you may want to look again. They've 
created an alternate API or mode which is more functional/immutable. 
Perhaps that _is_ what you saw though, and you're just referring to the 
mutable Java underpinnings leaking through...

My 2c

Chris


On Tuesday, November 10, 2015 at 12:22:01 PM UTC-8, Mars0i wrote:
>
> Cool.  Thanks.  I experimented with the quil 
>  wrapper around Processing 
>  at one point.  I'm glad quil exists, but the 
> underlying non-functional-programming model of Processing can sometimes 
> make it awkward.
>

-- 
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] Let's make clojure.org better!

[Nelson Morris]

Is there a list of reviewers and editors?

On Tue, Nov 10, 2015 at 9:14 AM, Alex Miller  wrote:

> The Clojure community is full of talented writers and valuable experience,
> and together we can create great documentation for the language and the
> ecosystem. With that in mind, we are happy to announce a new initiative to
> replace the existing http://clojure.org site. The new site will contain
> most of the existing reference and information content but will also
> provide an opportunity for additional guides or tutorials about Clojure and
> its ecosystem.
>
> The new site content is hosted in a GitHub repository
>  and is open for contributions.
> All contributions require a signed Clojure Contributor Agreement. This
> repository will accept contributions via pull request and issues with
> GitHub issues. The contribution and review process is described in more
> detail on the site contribution
> 
> page.
>
> We are currently working on the design elements for the site but if you
> would like to suggest a new guide, tutorial, or other content to be
> included on the site, please file an issue
>  for discussion or create
> a thread on the Clojure mailing list
>  with [DOCS] in the subject.
> There will be an unsession at the Clojure/conj 
> conference next week for additional discussion. This is the beginning of a
> process, and things will likely evolve in the future. In the meantime, we
> look forward to seeing your contributions!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Clojure has a history of adopting the GIGO approach


> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
> 
> Thanks, Nicola!
> 
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846 
> 
> 
> Shantanu
> 
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
> Here's a minimal repro case:
> 
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack  
> java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
> 
> 
>> On 11 Nov 2015, at 07:46, Shantanu Kumar gmail.com 
>> > wrote:
>> 
>> One of my libraries (https://github.com/kumarshantanu/asphalt 
>> ) is failing to compile with 1.8 
>> (works fine with 1.6, 1.7); the stack trace is below:
>> 
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>>  at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>>  at clojure.lang.Compiler.eval(Compiler.java:6918)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>>  at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>>  at asphalt.test_util$eval198.invoke(test_util.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>>  at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>>  at asphalt.core_test$eval192.invoke(core_test.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$lo

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Fluid Dynamics]

On Wednesday, November 11, 2015 at 9:23:16 AM UTC-5, Nicola Mometto wrote:
>
> To be honest I'm not sure this should even be a valid use of type hints.
> You're telling the compiler that the result of (foo) is an int, when it is 
> infact a long.
>
> The correct way to do this should be:
>  (Integer/bitCount (int (foo))
>
> Again, lack of specification on what the correct type hinting semantics 
> should be make it hard to evaluate if this should be considered a bug or 
> just an user error that previously just got ignored.
>

It's a bug. Even if ^int (thing-that-returns-long) is a user error, the 
result should be a sane error message from the Clojure compiler, not bad 
bytecode that later fails with a VerifyError. 

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

Aside on the type hinting specs: - I would be happy to have a doc
contribution at https://github.com/clojure/clojure-site that defines specs
that I could move through review with Rich.

On Wed, Nov 11, 2015 at 8:22 AM, Nicola Mometto  wrote:

> To be honest I'm not sure this should even be a valid use of type hints.
> You're telling the compiler that the result of (foo) is an int, when it is
> infact a long.
>
> The correct way to do this should be:
>  (Integer/bitCount (int (foo))
>
> Again, lack of specification on what the correct type hinting semantics
> should be make it hard to evaluate if this should be considered a bug or
> just an user error that previously just got ignored.
>
> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
>
> Thanks, Nicola!
>
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846
>
> Shantanu
>
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
>>
>> Here's a minimal repro case:
>>
>> user=> (defn foo ^long [] 1)
>> #'user/foo
>> user=> (Integer/bitCount ^int (foo))
>> VerifyError (class: user$eval13, method: invokeStatic signature:
>> ()Ljava/lang/Object;) Expecting to find integer on stack
>>  java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
>>
>>
>> On 11 Nov 2015, at 07:46, Shantanu Kumar  wrote:
>>
>> One of my libraries (https://github.com/kumarshantanu/asphalt) is
>> failing to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is
>> below:
>>
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class:
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature:
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;)
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>> at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>> at clojure.lang.Compiler.eval(Compiler.java:6918)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>> at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>> at asphalt.test_util$eval198.invoke(test_util.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>> at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>> at asphalt.core_test$eval192.invoke(core_test.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:58

Re: [ANN] Let's make clojure.org better!

[Alex Miller]

Yes, all of the instructions point you to a stable build of JBake 
2.5.0-SNAPSHOT. There is, in particular, a fix coming in 2.5.0 that allows 
us to output files with no extension so that urls look like 
http://clojure.org/reader instead of http://clojure.org/reader.html. When 
2.5 is released, I'll change the instructions to point to the stable 
release instead.

The build instructions on the site may change periodically, but the 
instructions should always be up to date there.


On Wednesday, November 11, 2015 at 8:08:33 AM UTC-6, Hildeberto Mendonça 
wrote:
>
> All set here! Just to point out that the site generation didn't work with 
> JBake v2.4.0 (latest stable). So, if you already use JBake, you will have 
> to upgrade it to v2.5.0-SNAPSHOT, as suggested in the README file.
>
>

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

To be honest I'm not sure this should even be a valid use of type hints.
You're telling the compiler that the result of (foo) is an int, when it is 
infact a long.

The correct way to do this should be:
 (Integer/bitCount (int (foo))

Again, lack of specification on what the correct type hinting semantics should 
be make it hard to evaluate if this should be considered a bug or just an user 
error that previously just got ignored.

> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
> 
> Thanks, Nicola!
> 
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846 
> 
> 
> Shantanu
> 
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
> Here's a minimal repro case:
> 
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack  
> java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
> 
> 
>> On 11 Nov 2015, at 07:46, Shantanu Kumar gmail.com 
>> > wrote:
>> 
>> One of my libraries (https://github.com/kumarshantanu/asphalt 
>> ) is failing to compile with 1.8 
>> (works fine with 1.6, 1.7); the stack trace is below:
>> 
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>>  at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>>  at clojure.lang.Compiler.eval(Compiler.java:6918)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>>  at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>>  at asphalt.test_util$eval198.invoke(test_util.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>>  at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>>  at asphalt.core_test$eval192.invoke(core_test.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT

Re: [ANN] Let's make clojure.org better!

[Hildeberto Mendonça]

All set here! Just to point out that the site generation didn't work with
JBake v2.4.0 (latest stable). So, if you already use JBake, you will have
to upgrade it to v2.5.0-SNAPSHOT, as suggested in the README file.

On Wed, Nov 11, 2015 at 5:38 AM, Dmitri  wrote:

> Just a note that the author of Cryogen is very responsive regarding
> discussions on improvements and pull requests for additional functionality.
> If there's a particular feature that's missing it might be worth creating
> an issue or opening a pr for it.
>
>
> On Tuesday, November 10, 2015 at 10:57:45 AM UTC-5, Alex Miller wrote:
>>
>> Hi Hildeberto,
>>
>> I built spikes of the site in a number of technologies like Cryogen,
>> Stasis, Sphinx, Asciidoctor, and some of the other Ruby-based static
>> generators as well. In the end, I found that JBake was the best match for
>> our goals at this time. The site build architecture has been decided and
>> we're not interested in revisiting that at this time. At some point down
>> the road, based on experience and tool evolution, we may take another look,
>> but not soon.
>>
>> Cryogen is a great tool and I would recommend it to others. One problem I
>> had with it was its flexibility with respect to the url structure. I
>> actually think for the purposes of creating a blog etc that is a dimension
>> that is good to remove, but it was a downside for our use.
>>
>> We are working with a designer on the site look and feel and at some
>> point that will be visible. At the point where that is visible, I expect
>> there will be some evolution on front page, navigation structure, etc and
>> would be happy to get feedback on that.
>>
>> Right now, we are primarily looking for content ideas and would love
>> thoughts on that. Or if there is interest in enhancing existing pages, I
>> would also like to talk about those.
>>
>> Thanks,
>> Alex
>>
>>
>>
>> On Tuesday, November 10, 2015 at 9:41:40 AM UTC-6, Hildeberto Mendonça
>> wrote:
>>>
>>> That's a great initiative! Thanks! But I'm just sad to see JBake instead
>>> of Cryogen (https://github.com/cryogen-project/cryogen-core) which is
>>> written in Clojure :-( Can we send a pull request replacing JBake by
>>> Cryogen or is JBake a final decision?
>>>
>>> --
>>> Hildeberto Mendonça, Ph.D
>>> Blog: http://www.hildeberto.com
>>> Twitter: https://twitter.com/htmfilho
>>>
>> --
> 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.
>



-- 
Hildeberto Mendonça, Ph.D
Blog: http://www.hildeberto.com
Twitter: https://twitter.com/htmfilho

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Phillip Lord]

I've been trying out RC1. I've tried enabling the direct linking in
leiningen, by sticking:

:jvm-opts ["-Dclojure.compiler.direct-linking=true"]

I can't see any particular performance change (when running tests
anyway).

Is there a way to know whether it is actually working?

Phil


Alex Miller  writes:

> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Shantanu Kumar]

Thanks, Nicola!

Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846

Shantanu

On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
>
> Here's a minimal repro case:
>
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack 
>  java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
>
>
> On 11 Nov 2015, at 07:46, Shantanu Kumar  > wrote:
>
> One of my libraries (https://github.com/kumarshantanu/asphalt) is failing 
> to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is below:
>
> $ lein do clean, with-profile dev,c18 test
> Exception in thread "main" java.lang.VerifyError: (class: 
> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
> Expecting to find integer on stack, compiling:(core.clj:201:1)
> at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
> at clojure.lang.Compiler.eval(Compiler.java:6918)
> at clojure.lang.Compiler.load(Compiler.java:7360)
> at clojure.lang.RT.loadResourceScript(RT.java:372)
> at clojure.lang.RT.loadResourceScript(RT.java:363)
> at clojure.lang.RT.load(RT.java:453)
> at clojure.lang.RT.load(RT.java:419)
> at clojure.core$load$fn__5673.invoke(core.clj:5895)
> at clojure.core$load.invokeStatic(core.clj:5894)
> at clojure.core$load_one.invokeStatic(core.clj:5694)
> at clojure.core$load_one.invoke(core.clj)
> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
> at clojure.core$load_lib.invokeStatic(core.clj:5738)
> at clojure.core$load_lib.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$load_libs.invokeStatic(core.clj:5776)
> at clojure.core$load_libs.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$require.invokeStatic(core.clj:5798)
> at clojure.core$require.doInvoke(core.clj)
> at clojure.lang.RestFn.invoke(RestFn.java:457)
> at 
> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
> at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
> at asphalt.test_util$eval198.invoke(test_util.clj)
> at clojure.lang.Compiler.eval(Compiler.java:6913)
> at clojure.lang.Compiler.eval(Compiler.java:6902)
> at clojure.lang.Compiler.load(Compiler.java:7360)
> at clojure.lang.RT.loadResourceScript(RT.java:372)
> at clojure.lang.RT.loadResourceScript(RT.java:363)
> at clojure.lang.RT.load(RT.java:453)
> at clojure.lang.RT.load(RT.java:419)
> at clojure.core$load$fn__5673.invoke(core.clj:5895)
> at clojure.core$load.invokeStatic(core.clj:5894)
> at clojure.core$load_one.invokeStatic(core.clj:5694)
> at clojure.core$load_one.invoke(core.clj)
> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
> at clojure.core$load_lib.invokeStatic(core.clj:5738)
> at clojure.core$load_lib.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$load_libs.invokeStatic(core.clj:5776)
> at clojure.core$load_libs.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$require.invokeStatic(core.clj:5798)
> at clojure.core$require.doInvoke(core.clj)
> at clojure.lang.RestFn.invoke(RestFn.java:457)
> at 
> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
> at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
> at asphalt.core_test$eval192.invoke(core_test.clj)
> at clojure.lang.Compiler.eval(Compiler.java:6913)
> at clojure.lang.Compiler.eval(Compiler.java:6902)
> at clojure.lang.Compiler.load(Compiler.java:7360)
> at clojure.lang.RT.loadResourceScript(RT.java:372)
> at clojure.lang.RT.loadResourceScript(RT.java:363)
> at clojure.lang.RT.load(RT.java:453)
> at clojure.lang.RT.load(RT.java:419)
> at clojure.core$load$fn__5673.invoke(core.clj:5895)
> at clojure.core$load.invokeStatic(core.clj:5894)
> at clojure.core$load_one.invokeStatic(core.clj:5694)
> at clojure.core$load_one.invoke(core.clj)
> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
> at clojure.core$load_lib.invokeStatic(core.clj:5738)
> at clojure.core$load_lib.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$load_libs.invokeStatic(core.clj:5776)
> at clojure.core$load_libs.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$require.invokeStatic(core.clj:5798)
> at clojure.core$require.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$apply.invoke(core.clj)
> at user$eval91.invokeStati

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Here's a minimal repro case:

user=> (defn foo ^long [] 1)
#'user/foo
user=> (Integer/bitCount ^int (foo))
VerifyError (class: user$eval13, method: invokeStatic signature: 
()Ljava/lang/Object;) Expecting to find integer on stack  
java.lang.Class.getDeclaredConstructors0 (Class.java:-2)


> On 11 Nov 2015, at 07:46, Shantanu Kumar  wrote:
> 
> One of my libraries (https://github.com/kumarshantanu/asphalt) is failing to 
> compile with 1.8 (works fine with 1.6, 1.7); the stack trace is below:
> 
> $ lein do clean, with-profile dev,c18 test
> Exception in thread "main" java.lang.VerifyError: (class: 
> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
> Expecting to find integer on stack, compiling:(core.clj:201:1)
>   at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>   at clojure.lang.Compiler.eval(Compiler.java:6918)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$require.invokeStatic(core.clj:5798)
>   at clojure.core$require.doInvoke(core.clj)
>   at clojure.lang.RestFn.invoke(RestFn.java:457)
>   at 
> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>   at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>   at asphalt.test_util$eval198.invoke(test_util.clj)
>   at clojure.lang.Compiler.eval(Compiler.java:6913)
>   at clojure.lang.Compiler.eval(Compiler.java:6902)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$require.invokeStatic(core.clj:5798)
>   at clojure.core$require.doInvoke(core.clj)
>   at clojure.lang.RestFn.invoke(RestFn.java:457)
>   at 
> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>   at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>   at asphalt.core_test$eval192.invoke(core_test.clj)
>   at clojure.lang.Compiler.eval(Compiler.java:6913)
>   at clojure.lang.Compiler.eval(Compiler.java:6902)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

Can you file a ticket for that VerifyError Shantanu?

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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

There is a Potemkin error that was exposed during 1.8 that looks like this (the 
compile_stub) - is that library in your dependencies? If so, supplying the 
latest version explicitly should fix the problem.

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