[ANN] thi.ng collection update (CLJ/CLJS)

[Karsten Schmidt]

Hi guys,

thi.ng is a collection of over a dozen largely x-platform Clojure &
Clojurescript libs for computational/generative design & data
visualization tasks.

I just wanted to give a little heads up that this project has recently
seen a number of releases and, as a whole, by now is generally quite
stable and usable (*is used*) for realworld projects (although most
libs remain in constant parallel development to make them more feature
complete). I've collated a number of images of projects and links to
the most important libs here:

http://thi.ng/

Most notably of those:

http://thi.ng/geom
By far the largest sub-project and backbone for most others: A 2D/3D
geometry package w/ comprehensive vector algebra, swizzling,
intersections, matrix types & helpers, quaternions, pure shape
primitives with ~50 protocols for polymorphic enquiry & manipulation,
meshes (incl. I/O), mesh subdivisions, CSG mesh ops, Verlet physics
engine (only particles, springs, behaviors)... Most of this lib is
pure geometry w/ no rendering specifics, although there're separate
modules for SVG rendering w/ shader support & decorators [1], WebGL
wrapper and converters from shapes/meshes to VBOs and various shader
presets/utils.

http://thi.ng/shadergraph
GLSL (WebGL) pure function library & dependency graph (based on
com.stuartsierra/dependency), GLSL minification during CLJS compile
time

http://thi.ng/color
RGB, HSV, CMYK, CSS conversions, color presets (incl. D3 category schemes)

http://thi.ng/luxor
Complete scene compiler DSL for http://luxrender.net, based around thi.ng/geom

http://thi.ng/morphogen
Declarative 3D form evolution through tree-based transformations,
basically an AST generator of geometric operations to transform a
single seed node into complex 3D objects

http://thi.ng/tweeny
Interpolation of nested (presumably animation related) data
structures. Allows tweening of deeply nested maps/vectors with
completely flexible tween fns/targets and hence easy definition of
complex timelines

http://thi.ng/validate
Purely functional, composable data validation & optional corrections
for nested data. Supports both maps & vectors, wildcards, comes with
many predefined validators, but extensible...

http://thi.ng/trio
A generic, non-RDF specific triple store API and feature rich
SPARQL-like query engine
(and my prime example of using the literate programming approach with
org-mode[2][3])

Last but not least: Super special thanks are due to the following people:

Rich, Alex + rest of clojure.core
David (+everyone else involved) for the immense effort on making CLJS
proper useful,
Chas, Kevin and anyone else working on CLJX...
none of this would have been possible without these amazing tools!

Best, K.

Ps. There're a number of other libs in this collection which are in
dire need of updating (last touched spring 2013) - these are related
to general OpenCL functionality and voxel rendering. Some of the
example images on the above site were created with these...

[1] https://github.com/thi-ng/geom/blob/master/geom-svg/src/examples.org
[2] https://github.com/thi-ng/trio/blob/master/src/query.org
[3] http://orgmode.org/

-- 
Karsten Schmidt
http://postspectacular.com | http://thi.ng/

-- 
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: Current best-of-breed JDBC libraries?

[Gary Johnson]

I actually prefer yesql for most of my Clojure<->SQL interaction.

Since a significant portion of my job involves me writing and optimizing 
SQL queries, I like being able to seamlessly switch between psql, 
org-babel's sql mode, and yesql with a simple cut and paste operation. For 
extra emacs sexiness, check out the yesql-ghosts package in MELPA. This 
automatically inserts all of the imported function signatures (as defns) as 
a text overlay below any (defqueries ...) form when a clojure buffer is in 
cider-mode.

Keep on hackin' in the free world,
  ~Gary

On Tuesday, February 24, 2015 at 9:04:36 AM UTC-5, Colin Yates wrote:
>
> Hi all,
>
> What are you all using for interacting with an RDBMS? In the past I looked 
> at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just 
> rocks). I have lost touch a bit - any recommendations?
>
> Thanks.
>

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

Re: Current best-of-breed JDBC libraries?

[blake]

I ran through all of the above and found it easier just to build my queries
straight and call with clojure.java.jdbc. But my needs were light.

On Tue, Feb 24, 2015 at 10:40 AM, Colin Yates  wrote:

> I haven't used it but I remember building up pages of SQL in Clojure
> wasn't fun. The idea of putting that SQL into a .sql file, accessible
> by non-Clojure DB developer is very appealing.
>
> On 24 February 2015 at 18:24, Niels van Klaveren
>  wrote:
> > Perhaps I'm missing something, but I don't really see the advantages of
> yesql over standard parametrized clojure.java.jdbc queries ?
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Can someone offer refactoring suggestions for my protocol example?

[Steve Miner]

It’s probably fine to do a linear search with .indexOf for small vectors, but 
I’ll just say as a matter of style I prefer to use a couple of maps to hold 
previous and next items.  The maps are callable like functions, which I think 
reads very nicely.  Using your example data for ranks:

;; helper functions
(defn prev-map [coll] (zipmap (rest coll) coll))
(defn next-map [coll] (zipmap coll (rest coll)))

(def ranks [:private :corporal :sergeant :lieutenant :captain :major :colonel 
:general])

(def previous-rank (prev-map ranks))

(def next-rank (next-map ranks))

(next-rank :corporal)
;=> :sergeant

Perhaps, in your example with promotions you'd want the end items to stick 
rather than return nil for the overflow cases.  (In other situations, you might 
want to wrap around.)

(defn bounded-prev-map [coll]
  (assoc (zipmap (rest coll) coll) (first coll) (first coll)))

(defn bounded-next-map [coll]
  (let [lst (if (vector? coll) (peek coll) (last coll))]
(assoc (zipmap coll (rest coll)) lst lst)))

Just a suggestion.


> On Feb 23, 2015, at 1:44 PM, Daniel Hinojosa  
> wrote:
> This example works, but it still has the feel of a lot of duplication, are 
> there any refactorings that I can do to this to make it more concise?
> 
> https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj

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

How not to drop core.async publication items?

[Cristian C]

My test case would be something like this:

;; I have a channel that I want to wrap in a publication
(def publisher (async/chan))
(def publication (async/pub publisher :topic))

;; then I put data into the publisher channel
(async/put! publisher {:topic :foo :payload "first message"})

;; then I create a channel to read data from that publication
(def reader (async/chan))
(async/sub publication :foo reader)
(async/go (println "value is: " (async/ value is {:topic :foo :msg "second message"}

Is there a way not to lose that first item?

-- 
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: should edn recognise defrecord?

[Steve Miner]

The edn format does not include records.  The transit README gives an example 
of how to write a transit handler for a record.  See the section on 
extensibility.

https://github.com/cognitect/transit-format#extensibility 


Before transit existed, there was a little library that I used to encode a 
Clojure record as a tagged literal (for edn compatibility).  It’s only for the 
Clojure side at the moment, but I imagine it wouldn’t be hard to port to CLJS.  
However, I suggest that you use transit.

https://github.com/miner/tagged 



> On Feb 24, 2015, at 4:40 PM, Colin Yates  wrote:
> 
> I am sending instances of defrecords from clojurescript via transmit/edn and 
> getting:
> 
> 2015-Feb-24 19:23:52 + dev-os-mbp.local DEBUG [taoensso.sente] - Bad 
> package: [[:client/message #health.shared.domain.PingCommand{}]] 
> (clojure.lang.ExceptionInfo: No reader function for tag 
> health.shared.domain.PingCommand {:type :reader-exception})
> 
> The defrecord is defined using cljx and is definitely there on the server.
> 
> Do I need to write a reader function to recognise instances of defrecord - my 
> assumption was that this should just work?
> 
> Thanks!


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

should edn recognise defrecord?

[Colin Yates]

I am sending instances of defrecords from clojurescript via transmit/edn 
and getting:

2015-Feb-24 19:23:52 + dev-os-mbp.local DEBUG [taoensso.sente] - Bad 
package: [[:client/message #health.shared.domain.PingCommand{}]] 
(clojure.lang.ExceptionInfo: No reader function for tag 
health.shared.domain.PingCommand {:type :reader-exception})

The defrecord is defined using cljx and is definitely there on the server.

Do I need to write a reader function to recognise instances of defrecord - 
my assumption was that this should just work?

Thanks!

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

Re: Can someone offer refactoring suggestions for my protocol example?

[Colin Fleming]

There's one important case where (coll n) is not the same as (get coll n) -
when coll is nil. In that case (get coll n) will return nil and (coll n)
will barf. I tend to use get in those cases because of this.

On 24 February 2015 at 08:50, Colin Yates  wrote:

> A minor point (get col n) is the same as (col n).
>
> It's more of a stylistic thing, but your use of protocols and
> implementation is quite 'stateful'. I would have done the same with
> vanilla maps:
>
> (def employee [first-name last-name level]
>  {:first-name .})
>
> (defn promote [{:keys [level] :as employee]
>   (assoc employee :level (next-item levels level)))
>
> but that is just me - maybe I ran too far from the OO world
>
> On 23 February 2015 at 18:44, Daniel Hinojosa
>  wrote:
> > This is for my language matrix project that has samples for 10 different
> > languages.  My clojure knowledge is ok, but not really as great where I
> > would like it to be, therefore looking towards the community for help.
> >
> > This example works, but it still has the feel of a lot of duplication,
> are
> > there any refactorings that I can do to this to make it more concise?
> >
> >
> https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj
> >
> > Thank you in advance,
> >
> > Danno
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: New scientific article out on plague and climate, using clojure, quil and incanter for data analysis, and lighttable as IDE.

[Christopher Small]

This is awesome. I had just opened the BBC news summary article, and then 
scrolled down my Clojure Group digest to see your post. Nice work. Always 
good to see other scientists using Clojure in their work.

On Tuesday, February 24, 2015 at 2:59:41 AM UTC-8, Boris V. Schmid wrote:
>
> Hi all,
>
> Published a new paper, using clojure, quil, and incanter to do some custom 
> statistics (permutation testing) and data exploration, and lighttable as 
> IDE Aim was to discover the wildlife reservoirs of plague in medieval 
> Europe, but we ended up finding evidence for repeated reintroductions of 
> the bacterium into Europe from Asia, over the course of 4 centuries. I 
> continue to use clojure today, although I am switching from incanter/charts 
> to https://github.com/JonyEpsilon/gg4clj to have access to ggplot2. 
> ggplot2 is just more powerful than the JfreeChart-based charting of 
> Incanter.
>
> Thanks all for making the tools I use every day :-).
> @BorisVSchmid
>
> Background on the article:
>
> https://theconversation.com/plague-outbreaks-that-ravaged-europe-for-centuries-were-driven-by-climate-change-in-asia-37933
>
> Article is open access, and available from PNAS
> http://www.pnas.org/content/early/2015/02/20/1412887112
>
> Source code and datasets available here: 
> https://zenodo.org/record/14973#.VOxH5vnF9vo
>

-- 
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: Current best-of-breed JDBC libraries?

[Colin Yates]

I haven't used it but I remember building up pages of SQL in Clojure
wasn't fun. The idea of putting that SQL into a .sql file, accessible
by non-Clojure DB developer is very appealing.

On 24 February 2015 at 18:24, Niels van Klaveren
 wrote:
> Perhaps I'm missing something, but I don't really see the advantages of yesql 
> over standard parametrized clojure.java.jdbc queries ?
>
> --
> 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: Current best-of-breed JDBC libraries?

[Niels van Klaveren]

Perhaps I'm missing something, but I don't really see the advantages of yesql 
over standard parametrized clojure.java.jdbc queries ?

-- 
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: Current best-of-breed JDBC libraries?

[Colin Yates]

Honeysql has to be one of the best examples of data transformation
where Clojure really shines. {domain-data} -> {honey-sql data} -> SQL.
Love it.

I understand YeSQL's sweet spot is where the SQL is static except for
parameters so yeah, not applicable for building up queries at runtime.
Still, if SQL is known up front then it seems very nice.

On 24 February 2015 at 18:10, Sean Corfield  wrote:
> On Feb 24, 2015, at 9:16 AM, Colin Yates  wrote:
>> I am surprised that yesql isn't more adopted, particularly now named
>> parameters is there - has anyone run into roadblocks with it?
>
> Most of our SQL is dynamically created -- data-driven -- so YeSQL isn't 
> really a good fit, as I understand it. We're either building SQL from a map 
> of key/value pairs or from composable pieces using HoneySQL (for our complex 
> reports that are all driven by data as well).
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> 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: Current best-of-breed JDBC libraries?

[Sean Corfield]

On Feb 24, 2015, at 9:16 AM, Colin Yates  wrote:
> I am surprised that yesql isn't more adopted, particularly now named
> parameters is there - has anyone run into roadblocks with it?

Most of our SQL is dynamically created -- data-driven -- so YeSQL isn't really 
a good fit, as I understand it. We're either building SQL from a map of 
key/value pairs or from composable pieces using HoneySQL (for our complex 
reports that are all driven by data as well). 

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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: Current best-of-breed JDBC libraries?

[Colin Yates]

OK - thanks all.

I am surprised that yesql isn't more adopted, particularly now named
parameters is there - has anyone run into roadblocks with it?

On 24 February 2015 at 16:50, Sean Corfield  wrote:
> On Feb 24, 2015, at 6:04 AM, Colin Yates  wrote:
>> What are you all using for interacting with an RDBMS? In the past I looked 
>> at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just 
>> rocks). I have lost touch a bit - any recommendations?
>
> At World Singles, all our MySQL interaction is done through clojure.java.jdbc 
> (which I maintain), and HoneySQL for our more complex reporting queries. We 
> like the composability of HoneySQL for complex stuff.
>
> We have a small wrapper around clojure.java.jdbc for basic CRUD stuff 
> (get-by-id, delete-by-id, find-by-keys) that encapsulates the 
> identifier/entity mappings and the DB connections we use, but we’re slowly 
> moving away from that toward raw clojure.java.jdbc and leveraging the :row-fn 
> and :result-set-fn keys more.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> 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: Current best-of-breed JDBC libraries?

[Sean Corfield]

On Feb 24, 2015, at 6:04 AM, Colin Yates  wrote:
> What are you all using for interacting with an RDBMS? In the past I looked at 
> clojure.java.jdbc, honeysql and korma (and for querying, honeysql just 
> rocks). I have lost touch a bit - any recommendations?

At World Singles, all our MySQL interaction is done through clojure.java.jdbc 
(which I maintain), and HoneySQL for our more complex reporting queries. We 
like the composability of HoneySQL for complex stuff.

We have a small wrapper around clojure.java.jdbc for basic CRUD stuff 
(get-by-id, delete-by-id, find-by-keys) that encapsulates the identifier/entity 
mappings and the DB connections we use, but we’re slowly moving away from that 
toward raw clojure.java.jdbc and leveraging the :row-fn and :result-set-fn keys 
more.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



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

Re: [ANN] Buddy 0.4.0: Security library for clojure.

[Sven Richter]

Hi,

What I like about buddy is that I can define access rules like this: 
https://funcool.github.io/buddy-auth/latest/#access-rules
It gives me the ability to have the rules in one place and adjust them with 
patterns as I wish, it reminds me of shiro and I really like that approach.

Best Regards,
Sven


Am Montag, 23. Februar 2015 02:25:43 UTC+1 schrieb Dave Sann:
>
> buddy-auth vs friend?
>
> What is the difference/motivation?
>
>
>
> On Monday, 23 February 2015 06:32:22 UTC+11, g vim wrote:
>>
>> On 22/02/2015 11:36, Andrey Antukh wrote: 
>> > Documentation: 
>> > https://funcool.github.io/buddy-core/latest/ 
>> > https://funcool.github.io/buddy-auth/latest/ 
>> > https://funcool.github.io/buddy-hashers/latest/ 
>> > https://funcool.github.io/buddy-sign/latest/ 
>> > 
>>
>> Great addition to Clojure web development security. For new users might 
>> I suggest adding a namespace table to -core, -hashers and -sign as with 
>> -auth? 
>>
>> gvim 
>>
>

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

Re: [ANN] Introducing pulley.cps

[Nathan Davis]

Sure, you can write code in CPS style by hand.  Javascript developers do it
all the time.  But it's a very tedius, mechanical transformation.  And
tedius, mechanical transformations are what Lisps excel at ;-)

We could also ask why we would want (reified) continuations?  From a
theoretical point of view, continuations are the fundamental basis for
control flow.  If continuations are reified as a first-class construct,
then we have a basis for implementing all sorts control-flow constructs.
For example, cooperative multitasking (green threads) is almost trivial to
implement with continuations.  Mitchell Wand's Continuation-Based
Multiprocessing 
is a good read for this application.

Finally, the combination of CPS with thunking and trampolining gives us
tail call optimization for free.  This allows us to express many complex
iterative processes in a recursive, functional, manner while retaining
space efficiency.  Some people find this more natural than iterative
alternatives, such as state machines.  Again, this can be done by hand, but
is very tedious.

Nathan Davis

On Tue, Feb 24, 2015 at 3:03 AM, Vladimir Bokov 
wrote:

> Hi, Nathan
>
> Would you like to describe shortly, why one would need such transformation.
> What are the benefits and what prevents to write code in CPS style by hand?
>
> p.s. sorry, I'm far from being expert in this field :)
>
> четверг, 19 февраля 2015 г., 23:45:10 UTC+6 пользователь Nathan Davis
> написал:
>
>> Dear Fellow Clojurians,
>>
>> I'm pleased to annouce release 0.1.0 of pulley.cps, a tool for
>> transforming Clojure code into Continuation-Passing-Style. You can find it
>> at http://github.com/positronic-solutions/pulley.cps.
>>
>> While this is not the first attempt at such a tool, to the best of my
>> knowledge it is the most complete to date. The rather lengthy Readme (which
>> for now also doubles as User Guide, API Documentation, and design document)
>> goes into more detail, but here's a quick run-down of features:
>>
>>- Two macros, cps and cps-fn, serve as primary entry points for
>>transforming code.
>>- Transformed code can call native code (non-transformed functions
>>and Java methods) and vice versa.
>>- Due to the nature of CPS, we get tail-call optimization for free
>>(i.e., all tail-calls within transformed code are naturally TCO'd). Of
>>course, calls from CPS to native code still consume Java stack space, and
>>non-tail calls within transformed code will consume *heap* space.
>>- Dynamic bindings are fully supported, and do not interfere with TCO
>>(binding is fully tail-call optimizable). set! is not currently
>>implement for dynamic vars, but due to some recent changes to the way
>>dynamic environments are implemented should be trivial to support.
>>- Since with CPS we explicitly pass the continuation around, it is
>>easy to expose the current continuation to the user. This is accomplished
>>via the function call-cc and its macro analog let-cc.
>>- Exceptions are not currently implemented. However, they are
>>actively being worked on. The expectation here is that exceptions will 
>> work
>>pretty much seamlessly with native exceptions, and you will be able to use
>>the same forms (throw, try, catch, finally) as you would in regular
>>Clojure code.
>>- The ability to override native functions with a CPS implementation,
>>in order to provide an optimal experience. For example,
>>clojure.core/apply is overridden to provide an optimized
>>implementation when invoked from CPS code. So if you call apply with
>>a CPS function, continuations, TCO, etc. will still work.
>>
>>  Overall, the goal is to be able to automatically transform as much
>> "regular clojure code" into CPS while maintaining seamless interoperation
>> with "native" Clojure code. The one area I don't think we'll manage to do a
>> satisfactory job on are forms that create Java types (reify, deftype,
>> genclass, etc.). These forms are currently completely unsupported, and
>> any potential future support will most likely consist of simply escaping
>> the transformation process when these forms are encountered. Other than
>> that, once exception support is completed, I think this goal will be within
>> reach.
>>
>> Near-term development goals are first to implement exceptions. Then I'd
>> like to explore expanding platform support beyond the JVM, namely
>> ClojureCLR and ClojureScript.
>>
>> Anyway, feel free to give things a try. I greatly treasure your feedback,
>> including bug reports and if you have trouble navigating the documentation.
>>
>> Have fun,
>>
>> Nathan Davis
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsu

Re: Current best-of-breed JDBC libraries?

[Erik Price]

We tried Korma but found it too limiting for our needs. Later, I saw this
tweet:

https://twitter.com/ibdknox/status/557236505639665664

We are currently using HoneySQL to generate SQL which then gets passed to
clojure.java.jdbc.

e
​

On Tue, Feb 24, 2015 at 9:04 AM, Colin Yates  wrote:

> Hi all,
>
> What are you all using for interacting with an RDBMS? In the past I looked
> at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just
> rocks). I have lost touch a bit - any recommendations?
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Current best-of-breed JDBC libraries?

[Colin Yates]

+1 to all of that. We are using honeysql to serve our ad-hoc reporting
engine. Composing data structures for the win.

On 24 February 2015 at 15:12, Niels van Klaveren
 wrote:
> I've done a fair bit of complex SQL with honeysql, and must say it rocks. It
> could use a bit more documentation where extending it with new clauses is
> concerned, though.
>
> For my latest project being able to manipulate the datastructures that are
> rendered to SQL was crucial, and honeysql was the only one that fitted that
> bill. Basically, it generates SQL scripts to relink foreign key references
> to clean up duplicates in a database. It takes a honeysql select query with
> (at least) a from table, a group-by and an order-by clause as a base
> definition what are to be considered doubles, and in which order records
> should be preserved. In combination with JDBC metadata that query
> effectively gets rewritten to generate:
>
> A temporary replacement table
> Queries to unify unique indexes, to prevent clashes when foreign key
> references are updated
> Queries to update all foreign key references
> Delete statements to remove all duplicates
>
> To create the best performing, but still database independent SQL, I had to
> extend honeysql with extra clauses like OVER and PARTITION BY. I wouldn't
> say it was a breeze, but seemed to work very well.
> Compared to the previous version I wrote in Ruby (without these clauses),
> the SQL now only scales with the amount of unique / foreign key constraints,
> instead of the amount of doubled sets.
>
> That cut down SQL to (sometimes) GB's of script to around a few 100 lines of
> SQL, and on one occasion, a runtime from 19 hours to 1.5 minutes.
>
> All in all, pretty impressed with Clojure and HoneySQL.
>
>
> On Tuesday, February 24, 2015 at 3:04:36 PM UTC+1, Colin Yates wrote:
>>
>> Hi all,
>>
>> What are you all using for interacting with an RDBMS? In the past I looked
>> at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just
>> rocks). I have lost touch a bit - any recommendations?
>>
>> Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: Current best-of-breed JDBC libraries?

[Niels van Klaveren]

I've done a fair bit of complex SQL with honeysql, and must say it rocks. 
It could use a bit more documentation where extending it with new clauses 
is concerned, though.

For my latest project being able to manipulate the datastructures that are 
rendered to SQL was crucial, and honeysql was the only one that fitted that 
bill. Basically, it generates SQL scripts to relink foreign key references 
to clean up duplicates in a database. It takes a honeysql select query with 
(at least) a from table, a group-by and an order-by clause as a base 
definition what are to be considered doubles, and in which order records 
should be preserved. In combination with JDBC metadata that query 
effectively gets rewritten to generate:

A temporary replacement table
Queries to unify unique indexes, to prevent clashes when foreign key 
references are updated
Queries to update all foreign key references
Delete statements to remove all duplicates

To create the best performing, but still database independent SQL, I had to 
extend honeysql with extra clauses like OVER and PARTITION BY. I wouldn't 
say it was a breeze, but seemed to work very well.
Compared to the previous version I wrote in Ruby (without these clauses), 
the SQL now only scales with the amount of unique / foreign key 
constraints, instead of the amount of doubled sets.

That cut down SQL to (sometimes) GB's of script to around a few 100 lines 
of SQL, and on one occasion, a runtime from 19 hours to 1.5 minutes.

All in all, pretty impressed with Clojure and HoneySQL.


On Tuesday, February 24, 2015 at 3:04:36 PM UTC+1, Colin Yates wrote:
>
> Hi all,
>
> What are you all using for interacting with an RDBMS? In the past I looked 
> at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just 
> rocks). I have lost touch a bit - any recommendations?
>
> Thanks.
>

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

Re: Current best-of-breed JDBC libraries?

[Andrey Antukh]

I'm currently using and maintaining this two:

https://github.com/niwibe/clojure.jdbc - A clojure.java.jdbc alternative.
https://github.com/niwibe/suricatta - High level Sql toolkit (slightly
higher level abstraction over plain jdbc and includes sql dsl)

Cheers.
Andrey

2015-02-24 15:11 GMT+01:00 Colin Yates :

> Actually, https://github.com/krisajenkins/yesql, now that it supports
> named parameters is probably just the ticket...
>
>
> On Tuesday, 24 February 2015 14:04:36 UTC, Colin Yates wrote:
>>
>> Hi all,
>>
>> What are you all using for interacting with an RDBMS? In the past I
>> looked at clojure.java.jdbc, honeysql and korma (and for querying, honeysql
>> just rocks). I have lost touch a bit - any recommendations?
>>
>> Thanks.
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
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: Current best-of-breed JDBC libraries?

[Colin Yates]

Actually, https://github.com/krisajenkins/yesql, now that it supports named 
parameters is probably just the ticket...

On Tuesday, 24 February 2015 14:04:36 UTC, Colin Yates wrote:
>
> Hi all,
>
> What are you all using for interacting with an RDBMS? In the past I looked 
> at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just 
> rocks). I have lost touch a bit - any recommendations?
>
> Thanks.
>

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

Current best-of-breed JDBC libraries?

[Colin Yates]

Hi all,

What are you all using for interacting with an RDBMS? In the past I looked 
at clojure.java.jdbc, honeysql and korma (and for querying, honeysql just 
rocks). I have lost touch a bit - any recommendations?

Thanks.

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

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support

[David Nolen]

:preamble will only be applied to the base module. When using :modules
there is not such thing as a main output file.

You cannot currently have a per module :preamble.

David

On Tue, Feb 24, 2015 at 6:25 AM, Max Gonzih  wrote:

> On Saturday, February 21, 2015 at 7:01:39 PM UTC+1, David Nolen wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > New release version: 0.0-2913
> >
> >
> > Leiningen dependency information:
> >
> >
> > [org.clojure/clojurescript "0.0-2913"]
> >
> >
> > This release comes with two very big enhancements.
> >
> >
> > The first is support for Google Closure Modules via the :modules build
> > option. Google Closure Modules permits splitting advanced compiled
> > builds into optimal smaller pieces for faster page
> > loads. ClojureScript's Google Closure Module support is fully
> > :foreign-libs aware. Source mapping for modules is also fully
> > supported.
> >
> >
> > The feature is described in more detail here:
> > https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules
> >
> >
> > The second big change is a fundamental rearchitecting of ClojureScript
> > REPLs. ClojureScript REPLs now support a set of options similar to
> > those taken by `clojure.main/repl` with small changes to account for
> > different JavaScript evaluation environments. Many third party REPLs
> > like Figwheel, Weasel, and Ambly are either unaffected or have already
> > accounted for these changes. However current tooling leveraging
> > Piggieback will likely present an inferior experience as Piggieback was
> > designed to work around the previous limitations of ClojureScript
> > REPLs. Now that ClojureScript REPLs are more like the standard Clojure
> > REPL it should be far simpler to add proper interruptible-eval and
> > load-file nREPL middleware so that existing tooling around nREPL can
> > more easily integrate ClojureScript REPLs as first class citizens.
> >
> >
> > Feedback on both of these enhancements is very welcome!
> >
> >
> >
> > There are also many smaller fixes around REPL command line behavior,
> > the Nashorn REPL, :foreign-libs resource finding issues, the full
> > list follows:
> >
> >
> > ## 0.0-2913
> > * Support custom :output-to for :cljs-base module
> >
> >
> > ## 0.0-2911
> >
> >
> > ### Enhancements
> > * CLJS-1042: Google Closure Modules :source-map support
> > * CLJS-1041: Google Closure Modules :foreign-libs support
> > * Google Closure Modules support via :modules
> > * CLJS-1040: Source-mapped script stack frames for the Nashorn repl
> >
> >
> > ### Changes
> > * CLJS-960: On carriage return REPLs should always show new REPL prompt
> > * CLJS-941: Warn when a symbol is defined multiple times in a file
> > * REPLs now support parameterization a la clojure.main/repl
> > * all REPLs analyze cljs.core before entering loop
> > * can emit :closure-source-map option for preserving JS->JS map
> > * REPLs can now merge new REPL/compiler options via -setup
> >
> >
> > ### Fixes
> > * CLJS-998: Nashorn REPL does not support require special fn
> > * CLJS-1052: Cannot require ns from within the ns at the REPL for
> reloading purposes
> > * CLJS-975: preserve :reload & :reload-all in ns macro sugar
> > * CLJS-1039: Under Emacs source directory watching triggers spurious
> recompilation
> > * CLJS-1046: static vars do not respect user compile time metadata
> > * CLJS-989: ClojureScript REPL loops on EOF signal
> > * fix DCE regression for trivial programs
> > * CLJS-1036: use getResources not findResources in get-upstream-deps*
>
> Nice! I played a bit with modules support. Good stuff! It is still not
> very clear for me where should I put my preamble stuff in that case. Will
> it be stored in cljs-base or in main output file? Can I have per module
> preamble? (probably per module preamble does not make any sense, right?)
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

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

Re: Advice on core.async and (JDBC) transactions

[Colin Yates]

It seems like it is worthwhile to brush up my knowledge then, this
looks quite hopeful - thanks!

On 24 February 2015 at 10:39, Andrey Antukh  wrote:
>
>
> 2015-02-24 10:15 GMT+01:00 Colin Yates :
>>
>> Hi Andrey - thanks for responding. Asciidoctor looks great!
>>
>> I think I understand the sucriata approach which serialises access to
>> the connection (via the agent). But this doesn't ensure that all
>> operations using the connection are done in the same thread does it (I
>> didn't think agents were thread-locked)?. In not then it looks like a
>> no go.
>
>
> Yes, the agent does not ensures that all operations using a connection are
> done in the same thread. Using agent only ensures that all actions
> are done in serialized way and only one thread uses the connection at time.
>>
>>
>> To be clear, my understanding (which is from a while ago admittedly)
>> is that JDBC transaction implementations tend to use thread locals to
>> store a bunch of stuff so it isn't so much the concurrent access which
>> is a problem (nicely solved by the agent approach) it is ensuring it
>> is ensuring the same thread is used.
>
>
> I'm not expert in jdbc, but I have see the source of postgresql jdbc, and
> the transaction state is bind to the connection, nothing related
> to thread locals.
>
> Thread locals are often used for "transaction mangers" like spring tx, maybe
> hibernate (I'm not sure because I have never used it), and other lightweight
> implementations like that https://github.com/witoldsz/ultm ...
>
> But in case of plain jdbc transactions, as far as I know, no thread local
> state is involved.
>
> Cheers.
> Andrey
>
>>
>>
>> On 23 February 2015 at 23:41, Andrey Antukh  wrote:
>> > Hi Colin.
>> >
>> > You are talking about suricatta documentation? Is build with
>> > asciidoctor.
>> >
>> > And, about core.async and transactions, suricatta comes with an async
>> > abstraction that internally uses a clojure agent for serialize all
>> > access to
>> > one connection from different threads (managed by core.async internal
>> > thread
>> > pool). Nothing special is used from jooq for handle it.
>> >
>> > A suricatta context encapsulates the standard jdbc connection and
>> > additional
>> > state. As far as I know, JDBC connection is not fully thread safe
>> >
>> > (http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe),
>> > and the general opinion is avoid use the same connection instance from
>> > different threads concurrently. But the suricata approach is share a
>> > connection instance between threads but ensuring that only one thread
>> > can
>> > use it at same time (as I said previously) using serialization semantics
>> > of
>> > clojure agents.
>> >
>> > I hope it has been helpful.
>> >
>> > Cheers
>> > Andrey
>> >
>> >
>> > 2015-02-23 22:26 GMT+01:00 Colin Yates :
>> >>
>> >> Thanks Christian, that looks interesting.
>> >>
>> >> By the way, any idea what tool was used to generate the documentation?
>> >>
>> >> On 23 February 2015 at 21:22, Christian Weilbach
>> >>  wrote:
>> >> > -BEGIN PGP SIGNED MESSAGE-
>> >> > Hash: SHA1
>> >> >
>> >> > On 23.02.2015 18:20, Colin Yates wrote:
>> >> >> Currently each request gets serviced in its own thread (web
>> >> >> container) and I am thinking of integrating core.async and I wonder
>> >> >> how core.async and a JDBC transactional "unit of work" get on.
>> >> >>
>> >> >> Conceptually, this model (thread-per-request) is trivial however
>> >> >> the problems are well known. Replacing this with core.async right
>> >> >> at the front is trivial but I can see the benefit of sprinkling
>> >> >> asynchronous behaviour throughout the (still very trivial)
>> >> >> pipeline. Or rather I can see the beauty of decomposed components
>> >> >> communicating via channels.
>> >> >>
>> >> >> My question is about transactionality. I am used to JDBC
>> >> >> transactions being thread local and I understand core.async
>> >> >> utilises a thread-pool, so how does one implement a "unit of work"
>> >> >> that spans multiple channels?
>> >> >>
>> >> >> I want to do something like:
>> >> >>
>> >> >> - request comes in - the appropriate handler/service consumes it
>> >> >> (either through request mapping, defmethod whatever) - TX starts -
>> >> >> in parallel some logging happens (and DB is updated) - the message
>> >> >> is handled (and DB is updated) - performance metrics are stored
>> >> >> (and DB is updated) - all work on all channels gets finished - TX
>> >> >> commits
>> >> >>
>> >> >> The point is that channels are used only to communicate between
>> >> >> disconnected components but they should all participate in the same
>> >> >> TX.
>> >> >>
>> >> >> Is anyone else using channels like this?
>> >> > I have done it in IndexedDB in JavaScript and had to use the proper
>> >> > callback API (1), because otherwise transactions break. I guess you
>> >> > cannot do channel operations inside a JDBC operation since they are
>> >> > executed in the threadpool

Re: can binary arithmetic guru help improve these "bitmasking" ops?

[danle...@gmail.com]

Lief you have a really valid point here.   I was definitely aware that there 
are only about a dozen actual masks that get used, 
so I had been looking for a good way to unroll that computation.  So, you 
definitely have showed me something useful
with your macro approach.  I think doing that though is something I will want 
to revisit a little bit down the line -- ldb and dpb
Have proven themselves useful enough to try to first look at ways to optimize 
them for the "general use" case.  The 
.countTrailingZeros code seems to take a much more efficient approach to 
"mask-offset" and IIRC may completely eliminate
"mask-width".  I'm going to play with it today and I'll report back any 
interesting results.

This group is really a fantastic resource.  You guys are awesome.

-- 
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: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support

[Max Gonzih]

On Saturday, February 21, 2015 at 7:01:39 PM UTC+1, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> New release version: 0.0-2913
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2913"]
> 
> 
> This release comes with two very big enhancements.
> 
> 
> The first is support for Google Closure Modules via the :modules build
> option. Google Closure Modules permits splitting advanced compiled
> builds into optimal smaller pieces for faster page
> loads. ClojureScript's Google Closure Module support is fully
> :foreign-libs aware. Source mapping for modules is also fully
> supported.
> 
> 
> The feature is described in more detail here:
> https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules
> 
> 
> The second big change is a fundamental rearchitecting of ClojureScript
> REPLs. ClojureScript REPLs now support a set of options similar to
> those taken by `clojure.main/repl` with small changes to account for
> different JavaScript evaluation environments. Many third party REPLs
> like Figwheel, Weasel, and Ambly are either unaffected or have already
> accounted for these changes. However current tooling leveraging
> Piggieback will likely present an inferior experience as Piggieback was
> designed to work around the previous limitations of ClojureScript
> REPLs. Now that ClojureScript REPLs are more like the standard Clojure
> REPL it should be far simpler to add proper interruptible-eval and
> load-file nREPL middleware so that existing tooling around nREPL can
> more easily integrate ClojureScript REPLs as first class citizens.
> 
> 
> Feedback on both of these enhancements is very welcome!
> 
> 
> 
> There are also many smaller fixes around REPL command line behavior,
> the Nashorn REPL, :foreign-libs resource finding issues, the full
> list follows:
> 
> 
> ## 0.0-2913
> * Support custom :output-to for :cljs-base module
> 
> 
> ## 0.0-2911
> 
> 
> ### Enhancements
> * CLJS-1042: Google Closure Modules :source-map support
> * CLJS-1041: Google Closure Modules :foreign-libs support
> * Google Closure Modules support via :modules
> * CLJS-1040: Source-mapped script stack frames for the Nashorn repl
> 
> 
> ### Changes
> * CLJS-960: On carriage return REPLs should always show new REPL prompt
> * CLJS-941: Warn when a symbol is defined multiple times in a file
> * REPLs now support parameterization a la clojure.main/repl
> * all REPLs analyze cljs.core before entering loop
> * can emit :closure-source-map option for preserving JS->JS map
> * REPLs can now merge new REPL/compiler options via -setup
> 
> 
> ### Fixes
> * CLJS-998: Nashorn REPL does not support require special fn
> * CLJS-1052: Cannot require ns from within the ns at the REPL for reloading 
> purposes
> * CLJS-975: preserve :reload & :reload-all in ns macro sugar
> * CLJS-1039: Under Emacs source directory watching triggers spurious 
> recompilation
> * CLJS-1046: static vars do not respect user compile time metadata
> * CLJS-989: ClojureScript REPL loops on EOF signal
> * fix DCE regression for trivial programs
> * CLJS-1036: use getResources not findResources in get-upstream-deps*

Nice! I played a bit with modules support. Good stuff! It is still not very 
clear for me where should I put my preamble stuff in that case. Will it be 
stored in cljs-base or in main output file? Can I have per module preamble? 
(probably per module preamble does not make any sense, right?)

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

New scientific article out on plague and climate, using clojure, quil and incanter for data analysis, and lighttable as IDE.

[Boris V. Schmid]

Hi all,

Published a new paper, using clojure, quil, and incanter to do some custom 
statistics (permutation testing) and data exploration, and lighttable as 
IDE Aim was to discover the wildlife reservoirs of plague in medieval 
Europe, but we ended up finding evidence for repeated reintroductions of 
the bacterium into Europe from Asia, over the course of 4 centuries. I 
continue to use clojure today, although I am switching from incanter/charts 
to https://github.com/JonyEpsilon/gg4clj to have access to ggplot2. ggplot2 
is just more powerful than the JfreeChart-based charting of Incanter.

Thanks all for making the tools I use every day :-).
@BorisVSchmid

Background on the article:
https://theconversation.com/plague-outbreaks-that-ravaged-europe-for-centuries-were-driven-by-climate-change-in-asia-37933

Article is open access, and available from PNAS
http://www.pnas.org/content/early/2015/02/20/1412887112

Source code and datasets available here: 
https://zenodo.org/record/14973#.VOxH5vnF9vo

-- 
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: Advice on core.async and (JDBC) transactions

[Andrey Antukh]

2015-02-24 10:15 GMT+01:00 Colin Yates :

> Hi Andrey - thanks for responding. Asciidoctor looks great!
>
> I think I understand the sucriata approach which serialises access to
> the connection (via the agent). But this doesn't ensure that all
> operations using the connection are done in the same thread does it (I
> didn't think agents were thread-locked)?. In not then it looks like a
> no go.
>

Yes, the agent does not ensures that all operations using a connection are
done in the same thread. Using agent only ensures that all actions
are done in serialized way and only one thread uses the connection at time.

>
> To be clear, my understanding (which is from a while ago admittedly)
> is that JDBC transaction implementations tend to use thread locals to
> store a bunch of stuff so it isn't so much the concurrent access which
> is a problem (nicely solved by the agent approach) it is ensuring it
> is ensuring the same thread is used.
>

I'm not expert in jdbc, but I have see the source of postgresql jdbc, and
the transaction state is bind to the connection, nothing related
to thread locals.

Thread locals are often used for "transaction mangers" like spring tx,
maybe hibernate (I'm not sure because I have never used it), and other
lightweight implementations like that https://github.com/witoldsz/ultm ...

But in case of plain jdbc transactions, as far as I know, no thread local
state is involved.

Cheers.
Andrey


>
> On 23 February 2015 at 23:41, Andrey Antukh  wrote:
> > Hi Colin.
> >
> > You are talking about suricatta documentation? Is build with asciidoctor.
> >
> > And, about core.async and transactions, suricatta comes with an async
> > abstraction that internally uses a clojure agent for serialize all
> access to
> > one connection from different threads (managed by core.async internal
> thread
> > pool). Nothing special is used from jooq for handle it.
> >
> > A suricatta context encapsulates the standard jdbc connection and
> additional
> > state. As far as I know, JDBC connection is not fully thread safe
> > (
> http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe
> ),
> > and the general opinion is avoid use the same connection instance from
> > different threads concurrently. But the suricata approach is share a
> > connection instance between threads but ensuring that only one thread can
> > use it at same time (as I said previously) using serialization semantics
> of
> > clojure agents.
> >
> > I hope it has been helpful.
> >
> > Cheers
> > Andrey
> >
> >
> > 2015-02-23 22:26 GMT+01:00 Colin Yates :
> >>
> >> Thanks Christian, that looks interesting.
> >>
> >> By the way, any idea what tool was used to generate the documentation?
> >>
> >> On 23 February 2015 at 21:22, Christian Weilbach
> >>  wrote:
> >> > -BEGIN PGP SIGNED MESSAGE-
> >> > Hash: SHA1
> >> >
> >> > On 23.02.2015 18:20, Colin Yates wrote:
> >> >> Currently each request gets serviced in its own thread (web
> >> >> container) and I am thinking of integrating core.async and I wonder
> >> >> how core.async and a JDBC transactional "unit of work" get on.
> >> >>
> >> >> Conceptually, this model (thread-per-request) is trivial however
> >> >> the problems are well known. Replacing this with core.async right
> >> >> at the front is trivial but I can see the benefit of sprinkling
> >> >> asynchronous behaviour throughout the (still very trivial)
> >> >> pipeline. Or rather I can see the beauty of decomposed components
> >> >> communicating via channels.
> >> >>
> >> >> My question is about transactionality. I am used to JDBC
> >> >> transactions being thread local and I understand core.async
> >> >> utilises a thread-pool, so how does one implement a "unit of work"
> >> >> that spans multiple channels?
> >> >>
> >> >> I want to do something like:
> >> >>
> >> >> - request comes in - the appropriate handler/service consumes it
> >> >> (either through request mapping, defmethod whatever) - TX starts -
> >> >> in parallel some logging happens (and DB is updated) - the message
> >> >> is handled (and DB is updated) - performance metrics are stored
> >> >> (and DB is updated) - all work on all channels gets finished - TX
> >> >> commits
> >> >>
> >> >> The point is that channels are used only to communicate between
> >> >> disconnected components but they should all participate in the same
> >> >> TX.
> >> >>
> >> >> Is anyone else using channels like this?
> >> > I have done it in IndexedDB in JavaScript and had to use the proper
> >> > callback API (1), because otherwise transactions break. I guess you
> >> > cannot do channel operations inside a JDBC operation since they are
> >> > executed in the threadpool (by the state-machine) while each JDBC
> >> > connection seems to be pinned to a thread, so you cannot participate
> >> > in the same transaction from another thread of the threadpool. But if
> >> > you can wrap your blocking JDBC stuff in a singular thread call, you
> >> > might be able to use asy

[ANN] semantic-csv 0.1.0-alpha2 released

[Christopher Small]

Semantic CSV is a library for taking you the extra mile with CSV parsing -

https://github.com/metasoarous/semantic-csv

This release will hopefully be the last 0.1.0-alpha release, as long as no 
major issues come up in the next week or two. Till then, please take it for 
a spin and leave any feedback you might have on the github issues page.

Some (abridged) notes from the changelog:

* simplified casting functionality to just a single function
* smarter casting error handling options
* except-first macro for leaving header columns unaltered in threading 
macro forms
* can specify :header to mappify, so it doesn't consume the first column
* mappify now supports using structs instead of array- or hash-maps, for a 
nice performance boost (with thanks to @MichaelBlume)
* greatly improved testing coverage (thanks in part to @ballPointPenguin)
* some more flexible numerics casting helpers (thanks in part to 
@JonyEpsilon)

For updated documentation and examples, see

http://metasoarous.github.io/semantic-csv/


With gratitude,

Christopher Small

-- 
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: Advice on core.async and (JDBC) transactions

[Colin Yates]

Hi Andrey - thanks for responding. Asciidoctor looks great!

I think I understand the sucriata approach which serialises access to
the connection (via the agent). But this doesn't ensure that all
operations using the connection are done in the same thread does it (I
didn't think agents were thread-locked)?. In not then it looks like a
no go.

To be clear, my understanding (which is from a while ago admittedly)
is that JDBC transaction implementations tend to use thread locals to
store a bunch of stuff so it isn't so much the concurrent access which
is a problem (nicely solved by the agent approach) it is ensuring it
is ensuring the same thread is used.

On 23 February 2015 at 23:41, Andrey Antukh  wrote:
> Hi Colin.
>
> You are talking about suricatta documentation? Is build with asciidoctor.
>
> And, about core.async and transactions, suricatta comes with an async
> abstraction that internally uses a clojure agent for serialize all access to
> one connection from different threads (managed by core.async internal thread
> pool). Nothing special is used from jooq for handle it.
>
> A suricatta context encapsulates the standard jdbc connection and additional
> state. As far as I know, JDBC connection is not fully thread safe
> (http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe),
> and the general opinion is avoid use the same connection instance from
> different threads concurrently. But the suricata approach is share a
> connection instance between threads but ensuring that only one thread can
> use it at same time (as I said previously) using serialization semantics of
> clojure agents.
>
> I hope it has been helpful.
>
> Cheers
> Andrey
>
>
> 2015-02-23 22:26 GMT+01:00 Colin Yates :
>>
>> Thanks Christian, that looks interesting.
>>
>> By the way, any idea what tool was used to generate the documentation?
>>
>> On 23 February 2015 at 21:22, Christian Weilbach
>>  wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 23.02.2015 18:20, Colin Yates wrote:
>> >> Currently each request gets serviced in its own thread (web
>> >> container) and I am thinking of integrating core.async and I wonder
>> >> how core.async and a JDBC transactional "unit of work" get on.
>> >>
>> >> Conceptually, this model (thread-per-request) is trivial however
>> >> the problems are well known. Replacing this with core.async right
>> >> at the front is trivial but I can see the benefit of sprinkling
>> >> asynchronous behaviour throughout the (still very trivial)
>> >> pipeline. Or rather I can see the beauty of decomposed components
>> >> communicating via channels.
>> >>
>> >> My question is about transactionality. I am used to JDBC
>> >> transactions being thread local and I understand core.async
>> >> utilises a thread-pool, so how does one implement a "unit of work"
>> >> that spans multiple channels?
>> >>
>> >> I want to do something like:
>> >>
>> >> - request comes in - the appropriate handler/service consumes it
>> >> (either through request mapping, defmethod whatever) - TX starts -
>> >> in parallel some logging happens (and DB is updated) - the message
>> >> is handled (and DB is updated) - performance metrics are stored
>> >> (and DB is updated) - all work on all channels gets finished - TX
>> >> commits
>> >>
>> >> The point is that channels are used only to communicate between
>> >> disconnected components but they should all participate in the same
>> >> TX.
>> >>
>> >> Is anyone else using channels like this?
>> > I have done it in IndexedDB in JavaScript and had to use the proper
>> > callback API (1), because otherwise transactions break. I guess you
>> > cannot do channel operations inside a JDBC operation since they are
>> > executed in the threadpool (by the state-machine) while each JDBC
>> > connection seems to be pinned to a thread, so you cannot participate
>> > in the same transaction from another thread of the threadpool. But if
>> > you can wrap your blocking JDBC stuff in a singular thread call, you
>> > might be able to use async/thread (probably less than you want).
>> >
>> > There is also https://github.com/niwibe/suricatta, but I have no
>> > experience with it. jooq seems to solve the the thread per request
>> > problem decoupling into async operations you have in mind.
>> >
>> > Cheers,
>> > Christian
>> >
>> > (1)
>> >
>> > https://github.com/ghubber/konserve/blob/master/src/cljs/konserve/indexeddb.cljs
>> > -BEGIN PGP SIGNATURE-
>> > Version: GnuPG v1
>> >
>> > iQEcBAEBAgAGBQJU65n6AAoJEKel+aujRZMkwaAH/1Eq2/vr84WqNq6u2rcG4ly+
>> > xkByy602oMy9/ScK1/ytv/kFdPG+qAYmtQ4EHq/LGUma3zLjpPdrf49A1RUGfVii
>> > fbwIUiRgUJWdigrGiSf/2zIn972MgIfc4qKFj/+/2hJNZIAwlAKiPQSvG2VPrHo7
>> > dskeQZeCZI4yGSz4+dQFGmKvjiAum+UConkzn0T/N2XGknerFsLonXyvpbTv/SCC
>> > NwNoRJzI39kjIyhfUuwbwHoy0/DtbxjvkbrLHeyGIKGOJ75QutWY6gvkRsSlzS5g
>> > A2jVtZo/hw02di3mxrD1vwSZ2PWads2juKjCmmOQrIPofSBWyVmoGeQ/qyD/Dgw=
>> > =Wi7E
>> > -END PGP SIGNATURE-
>> >
>> > --
>> > You rece

Re: [ANN] Introducing pulley.cps

[Vladimir Bokov]

Hi, Nathan

Would you like to describe shortly, why one would need such transformation.
What are the benefits and what prevents to write code in CPS style by hand?

p.s. sorry, I'm far from being expert in this field :)

четверг, 19 февраля 2015 г., 23:45:10 UTC+6 пользователь Nathan Davis 
написал:
>
> Dear Fellow Clojurians, 
>
> I'm pleased to annouce release 0.1.0 of pulley.cps, a tool for 
> transforming Clojure code into Continuation-Passing-Style. You can find it 
> at http://github.com/positronic-solutions/pulley.cps. 
>
> While this is not the first attempt at such a tool, to the best of my 
> knowledge it is the most complete to date. The rather lengthy Readme (which 
> for now also doubles as User Guide, API Documentation, and design document) 
> goes into more detail, but here's a quick run-down of features: 
>
>- Two macros, cps and cps-fn, serve as primary entry points for 
>transforming code. 
>- Transformed code can call native code (non-transformed functions and 
>Java methods) and vice versa. 
>- Due to the nature of CPS, we get tail-call optimization for free 
>(i.e., all tail-calls within transformed code are naturally TCO'd). Of 
>course, calls from CPS to native code still consume Java stack space, and 
>non-tail calls within transformed code will consume *heap* space. 
>- Dynamic bindings are fully supported, and do not interfere with TCO (
>binding is fully tail-call optimizable). set! is not currently 
>implement for dynamic vars, but due to some recent changes to the way 
>dynamic environments are implemented should be trivial to support. 
>- Since with CPS we explicitly pass the continuation around, it is 
>easy to expose the current continuation to the user. This is accomplished 
>via the function call-cc and its macro analog let-cc. 
>- Exceptions are not currently implemented. However, they are actively 
>being worked on. The expectation here is that exceptions will work pretty 
>much seamlessly with native exceptions, and you will be able to use the 
>same forms (throw, try, catch, finally) as you would in regular 
>Clojure code. 
>- The ability to override native functions with a CPS implementation, 
>in order to provide an optimal experience. For example, 
>clojure.core/apply is overridden to provide an optimized 
>implementation when invoked from CPS code. So if you call apply with a 
>CPS function, continuations, TCO, etc. will still work. 
>
>  Overall, the goal is to be able to automatically transform as much 
> "regular clojure code" into CPS while maintaining seamless interoperation 
> with "native" Clojure code. The one area I don't think we'll manage to do a 
> satisfactory job on are forms that create Java types (reify, deftype, 
> genclass, etc.). These forms are currently completely unsupported, and 
> any potential future support will most likely consist of simply escaping 
> the transformation process when these forms are encountered. Other than 
> that, once exception support is completed, I think this goal will be within 
> reach. 
>
> Near-term development goals are first to implement exceptions. Then I'd 
> like to explore expanding platform support beyond the JVM, namely 
> ClojureCLR and ClojureScript. 
>
> Anyway, feel free to give things a try. I greatly treasure your feedback, 
> including bug reports and if you have trouble navigating the documentation. 
>
> Have fun, 
>
> Nathan Davis 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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.