[ANN] PGMig 0.3.0

[Kamil Toman]

Hi everyone,

The release 0.3.0 of PGMig is out.

PGMig is a standalone PostgreSQL Migration Runner using Migratus. It's
just like Migratus but it is compiled into a native binary. It can be used 
to
execute sql migrations while developing without a lein plugin but it is 
also useful a as blazing fast init container for apps that are deployed 
to Kubernetes.

What's new:
- The latest and greatest Migratus
- GraalVM updated to 20.1.0
- The docker build now uses the official graalvm-ce as a base image
- Pre-built x86_64 linux docker image is available at dockerhub 
(https://hub.docker.com/r/leafclick/pgmig)

Gihub: https://github.com/leafclick/pgmig

Enjoy,
Kamil

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

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Thomas Heller]

>
> None of these libraries are broken. They just include resources. Also, I 
> don't think it is realistic to tell library authors to please move certain 
> files out of the way because my build tool randomizes my classpath. That is 
> not going to happen. People will keep including things like 
> log4j.properties that are in potential conflict with a local file or files 
> in other JAR paths.
>

These packages should be cleaned up. They contain files they shouldn't 
contain. It mostly goes unnoticed and library authors often aren't even 
aware this is happening. I have reported this to a couple CLJS libraries 
over the years and all of them were fixed pretty much immediately, since it 
was always accidental. The burden is probably on the community to make 
people aware of this. Heck I'd even say all tools used for building library 
.jar files should even complain about certain files from the outset. While 
it is mostly harmless and usually goes unnoticed it is also a potential 
security risk. I don't know anyone that audits their dependencies properly 
and often people just serve "public" resources straight over HTTP. That 
means any dependency you don't audit may contain 
"public/some-exploit/foo.html" which then is often automatically available 
under "https://your-domain.com/some-exploit/foo.html";. Probably not 
something you want to have on your domain.

Regardless :paths should be first, just because of the options it enables I 
outlined earlier. IMHO dependencies otherwise can stay unordered since 
everything should be namespaced properly and unique anyways so order 
shouldn't matter.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/16ea6172-1d5c-4ac5-976c-3e5223aeee66o%40googlegroups.com.

[ANN] - tech.ml.dataset upgrades + memory map arrow blogpost

[Chris Nuernberger]

We have been busy here working with our little dataset library and I wanted
to talk about some of the upgrades that I think are important/interesting.

We have first class support of Apache Arrow now which means I took the time
to actually understand, byte-by-byte, the binary on-disk format. I also
found a memory mapping library that I think is great, larray
.

Arrow files are really sequences of datasets and we have a brand new
namespace

which will grow over time devoted to really large (multiple GB, out of
memory) reductions over sequences of datasets which have competitive
performance characteristics with anything out there.

Lastly, we have a (great!) blog post exploring memory mapping, apache
arrow, and the tech.datatype bindings

to larray. It specifically highlights how nice Clojure is for exploring
binary file formats — doing this brought back memories of doing similar
things in C++ and wow, with Clojure I get the same performance and I can
actually see what I am working with! Much appreciation to Alex, Rich, and
the team!

https://techascent.com/blog/memory-mapping-arrow.html

Enjoy!

Chris

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

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Sean Corfield]

I'd like to point out that tools.deps.alpha can build a differently-ordered
classpath from the exact same input files when run on a different machine
(i.e., the same source/deps, the same version of t.d.a./CLI).

This has bitten me a couple of times with depstar which I use for building
JARs/uberjars (and which I maintain) because a JAR built on one machine can
behave differently than a JAR built on another machine -- because of
classpath ordering of things that overlap on the classpath. This is
completely separate from the :paths issue (with which I have some sympathy).

The most recent "gotcha" for me was with log4j2 which has a
Log4J2Plugins.dat file containing a cache of the plugins that control
formatting in log files, so any library that includes formatter plugins
tends to have its own copy of this file. There have been a couple of
long-standing bug reports against Log4J2 because of this -- because people
in Maven-land keep tripping over classpath ordering issues and finding
logging breaks "randomly" in their applications. Years of complaints and
the official answer is "We'll stop doing the plugins cache thing in log4j
3". There is a Maven plugin that knows how to merge Log4J2Plugins.dat files
but, of course, it is specific to log4j2 and Maven. There is a Leiningen
plugin for it as well -- also specific to log4j2 code -- because Leiningen
is built on the same "reproducible" base as Maven...

So this _is_ an issue in Maven-land. It's an acknowledged problem with
libraries that contain overlapping files and has been for years. That
t.d.a/CLI makes this a bit more visible is a positive, in my opinion,
because you're more likely to realize that you have a problem upstream with
badly-behaved dependencies.

p.s., My "hack" for depstar was to have it overwrite Log4J2Plugins.dat in
the JAR until it found one bigger than ~10K and then ignore subsequent ones
(the plugin cache file in the main log4j2 JAR is 20K, the plugin cache
files in all the other libs I've seen are 5K or smaller). Sure, that means
you don't get _all_ the formatter plugins, you only get the core ones, but
in the real world that is almost always going to be the right choice.

On Tue, Aug 11, 2020 at 9:34 PM 'bed...@yahoo.com' via Clojure <
clojure@googlegroups.com> wrote:

> Ok, let's reset as we start talking about different things now.
>
> None of these libraries are broken. They just include resources. Also, I
> don't think it is realistic to tell library authors to please move certain
> files out of the way because my build tool randomizes my classpath. That is
> not going to happen. People will keep including things like
> log4j.properties that are in potential conflict with a local file or files
> in other JAR paths.
>
> The question remains: Should my build tool allow me control over the order
> of the classpath? I believe the answer is yes.
> (Even gradle gives you that control and/or offers ways to ensure that my
> chosen paths and libraries are first on the classpath.
> Regarding maven: Even if there would be no documentation at all, their
> algorithm has not changed since 2.0.9. It's the Normative Kraft des
> Faktischen at play. )
>
> If the build tool from version A to version B changes this order, it is
> not a usable tool. I can't make this point any clearer.
> We might agree to disagree here, but a build tool should not be at liberty
> to sort top-level dependencies at will.
>
> Note that this is completely independent from the thought that order
> *shouldn't* matter.
> When in fact it does matter. It is an unfortunate reality. That's simply
> how resource loading works in Java.
>
> I understand that building dependency trees is not trivial, but it is
> rather trivial to ensure :paths comes before everything else.
> Please define some stable order and establish a top-level order for
> explicit dependencies. That makes builds deterministic.
>
> Thanks for looking in this issue,
>  Jochen
>
> PS: happy to learn you got in touch with the homebrew team. That is
> excellent news.
>
>
>
>
> On Tuesday, August 11, 2020 at 6:01:18 PM UTC-7 Alex Miller wrote:
>
>> On Tue, Aug 11, 2020 at 6:41 PM 'bed...@yahoo.com' via Clojure <
>> clo...@googlegroups.com> wrote:
>>
>>> Just 2 quick points before I go back to migrate to shadow-cljs &
>>> leiningen ;)
>>>
>>> "just does not seem well defined "
>>> This is not a line of argument you want to pursue when we are talking
>>> about maven, who has had a stable order for what feels like decades now.
>>> If you need a current link:
>>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
>>> (search for "first")
>>>
>>
>> I understand it may feel like that to you, but I have been using Maven
>> for at least 15 years and have spent a lot of time fighting classpath
>> ordering issues while using it. That link says nothing about classpath
>> order and I spent some more time today looking for something like
>> that, without success. There are 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Alan Thompson]

Hi Alex,

1. Great news that the Homebrew team has responded to your request to point
only to stable versions.

2. The resources directory is the contains the path
`resources/public/index.html`.  The local one is definitely not the one
being served in my original example (2nd half) re 1.10.1.645 when the
`resources` dir was listed near the end. The `index.html` being found by
the Figwheel.Main server had different contents, and was pointing to a
different *.js executable file (possibly in a different *.jar file?).  That
is the source of the 2-word `Debux Test` webpage.

3. Unless I'm missing something, I believe we have already run your
suggested test. Using 1.10.1.561 from `brew install clojure/tools/clojure`,
I got the `resources` and `target` dirs as items #1 and #2 on the
classpath; everything worked as expected.  Using 1.10.1.645 from `brew
install clojure`, `resources` was near the end of the classpath and it
failed (I didn't track down where the `target` dir wound up in that
instance).

4. I could possibly try to replicate your proposed experiment explicitly,
but I no longer have easy access to 1.10.1.645 since Homebrew has been
fixed.  I did find the `brew-install` repo on GH, but am not certain how to
replicate the broken install of *.645.

Thank you for the attention you are giving to this issue.

Alan



On Tue, Aug 11, 2020 at 5:41 PM 'Alex Miller' via Clojure <
clojure@googlegroups.com> wrote:

> Can you change that resources file and see if what you're looking at
> changes to double check? I did actually check a bunch of jars from the
> prior message and did some searching for that message. Or you could even
> dump the classpath with -Spath, then move resources to the front, then use
> -Scp (which will force the classpath you say, ignoring everything else).
>
> Or could be that it's not the index.html but something it refers to
> getting picked up from elsewhere?
>
> On Tue, Aug 11, 2020 at 6:18 PM Alan Thompson  wrote:
>
>> Hi - I just tried your suggestion and no joy:
>>
>>
>> ~/work/tmp810/xanadu >   clj -e "((requiring-resolve '
>> clojure.java.io/resource) \"public/index.html\")"
>> DEPRECATED: Libs must be qualified, change deps-ancient =>
>> deps-ancient/deps-ancient (deps.edn)
>> DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
>> (deps.edn)
>> DEPRECATED: Libs must be qualified, change ns-tracker =>
>> ns-tracker/ns-tracker (deps.edn)
>> DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
>> camel-snake-kebab/camel-snake-kebab (deps.edn)
>> DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
>> DEPRECATED: Libs must be qualified, change orchestra =>
>> orchestra/orchestra (deps.edn)
>> DEPRECATED: Libs must be qualified, change cljs-ajax =>
>> cljs-ajax/cljs-ajax (deps.edn)
>> DEPRECATED: Libs must be qualified, change expound => expound/expound
>> (deps.edn)
>> DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
>> (deps.edn)
>> DEPRECATED: Libs must be qualified, change re-frame-utils =>
>> re-frame-utils/re-frame-utils (deps.edn)
>> DEPRECATED: Libs must be qualified, change cljs-bean =>
>> cljs-bean/cljs-bean (deps.edn)
>> #object[java.net.URL 0x6c345c5f
>> "file:/Users/alanthompson/work/tmp810/xanadu/resources/public/index.html"]
>>
>>
>> The call to `requiring-resolve` claims it is finding my local
>> `./resources/public/index.html`.  However, the error remains that it is
>> finding some other `index.html`, which also points to an incorrect JS
>> output file.
>>
>> Alan
>>
>>
>>
>>
>> On Tue, Aug 11, 2020 at 2:15 PM 'Alex Miller' via Clojure <
>> clojure@googlegroups.com> wrote:
>>
>>>
>>> On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
>>> clojure@googlegroups.com> wrote:
>>>
 Here's some maven-specific discussion:
 https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
 They have a defined order since 2.0.9. and declaration order is
 considered for transitive dependencies conflict.

>>>
>>> Unfortunately, neither that 11 year old SO answer nor the referenced
>>> jiras actually document, explain, or refer to any documentation about the
>>> ordering, or afaict commit to anything specific other than reproducibility.
>>> I'm not saying this is your fault or anything, just does not seem well
>>> defined to me other than as an artifact of implementation.
>>>
>>> For libs, Maven (and I presume lein which relies on Maven libs for this)
>>> uses the ordering of deps in the pom wrt the ordering in the classpath. clj
>>> intentionally does not include this ordering - the libs are in an unordered
>>> map, the version selection algorithm is completely different, etc. If this
>>> matters, then one of your deps is broken and should be fixed.
>>>
>>>
 Intellij's Dependencies tab in Module settings: You can re-order the
 dependencies and they reflect in the classpath.

>>>
>>> Not sure that has anything to do with Maven or lein, seems orthogonal to
>>> th

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Sean Corfield]

Alan,

> 4. I could possibly try to replicate your proposed experiment explicitly,
but I no longer have easy access to 1.10.1.645 since Homebrew has been
fixed.  I did find the `brew-install` repo on GH, but am not certain how to
replicate the broken install of *.645.

Per the clojure/homebrew-tools readme:
https://github.com/clojure/homebrew-tools#version-archive-tool-releases

brew install clojure/tools/clojure@1.10.1.645

You may also need:

brew link --overwrite clojure@1.10.1.645

This allows you to easily switch back and forth between different versions
for testing.

On Wed, Aug 12, 2020 at 2:09 PM Alan Thompson  wrote:

> Hi Alex,
>
> 1. Great news that the Homebrew team has responded to your request to
> point only to stable versions.
>
> 2. The resources directory is the contains the path
> `resources/public/index.html`.  The local one is definitely not the one
> being served in my original example (2nd half) re 1.10.1.645 when the
> `resources` dir was listed near the end. The `index.html` being found by
> the Figwheel.Main server had different contents, and was pointing to a
> different *.js executable file (possibly in a different *.jar file?).  That
> is the source of the 2-word `Debux Test` webpage.
>
> 3. Unless I'm missing something, I believe we have already run your
> suggested test. Using 1.10.1.561 from `brew install clojure/tools/clojure`,
> I got the `resources` and `target` dirs as items #1 and #2 on the
> classpath; everything worked as expected.  Using 1.10.1.645 from `brew
> install clojure`, `resources` was near the end of the classpath and it
> failed (I didn't track down where the `target` dir wound up in that
> instance).
>
> 4. I could possibly try to replicate your proposed experiment explicitly,
> but I no longer have easy access to 1.10.1.645 since Homebrew has been
> fixed.  I did find the `brew-install` repo on GH, but am not certain how to
> replicate the broken install of *.645.
>
> Thank you for the attention you are giving to this issue.
>
> Alan
>
>
>
> On Tue, Aug 11, 2020 at 5:41 PM 'Alex Miller' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> Can you change that resources file and see if what you're looking at
>> changes to double check? I did actually check a bunch of jars from the
>> prior message and did some searching for that message. Or you could even
>> dump the classpath with -Spath, then move resources to the front, then use
>> -Scp (which will force the classpath you say, ignoring everything else).
>>
>> Or could be that it's not the index.html but something it refers to
>> getting picked up from elsewhere?
>>
>> On Tue, Aug 11, 2020 at 6:18 PM Alan Thompson  wrote:
>>
>>> Hi - I just tried your suggestion and no joy:
>>>
>>>
>>> ~/work/tmp810/xanadu >   clj -e "((requiring-resolve '
>>> clojure.java.io/resource) \"public/index.html\")"
>>> DEPRECATED: Libs must be qualified, change deps-ancient =>
>>> deps-ancient/deps-ancient (deps.edn)
>>> DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
>>> (deps.edn)
>>> DEPRECATED: Libs must be qualified, change ns-tracker =>
>>> ns-tracker/ns-tracker (deps.edn)
>>> DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
>>> camel-snake-kebab/camel-snake-kebab (deps.edn)
>>> DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
>>> DEPRECATED: Libs must be qualified, change orchestra =>
>>> orchestra/orchestra (deps.edn)
>>> DEPRECATED: Libs must be qualified, change cljs-ajax =>
>>> cljs-ajax/cljs-ajax (deps.edn)
>>> DEPRECATED: Libs must be qualified, change expound => expound/expound
>>> (deps.edn)
>>> DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
>>> (deps.edn)
>>> DEPRECATED: Libs must be qualified, change re-frame-utils =>
>>> re-frame-utils/re-frame-utils (deps.edn)
>>> DEPRECATED: Libs must be qualified, change cljs-bean =>
>>> cljs-bean/cljs-bean (deps.edn)
>>> #object[java.net.URL 0x6c345c5f
>>> "file:/Users/alanthompson/work/tmp810/xanadu/resources/public/index.html"]
>>>
>>>
>>> The call to `requiring-resolve` claims it is finding my local
>>> `./resources/public/index.html`.  However, the error remains that it is
>>> finding some other `index.html`, which also points to an incorrect JS
>>> output file.
>>>
>>> Alan
>>>
>>>
>>>
>>>
>>> On Tue, Aug 11, 2020 at 2:15 PM 'Alex Miller' via Clojure <
>>> clojure@googlegroups.com> wrote:
>>>

 On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
 clojure@googlegroups.com> wrote:

> Here's some maven-specific discussion:
> https://stackoverflow.com/questions/793054/maven-classpath-order-issue
> .
> They have a defined order since 2.0.9. and declaration order is
> considered for transitive dependencies conflict.
>

 Unfortunately, neither that 11 year old SO answer nor the referenced
 jiras actually document, explain, or refer to any documentation about the
 ordering, or afaict commit to anything specific other than

Re: Accessing Record fields with keywords in ClojureScript not working as in Clojure

[Alan Thompson]

I verified the problem in the StackOverflow post.  For some reason keyword
lookup of record fields in CLJS doesn't work.
Alan

On Tue, Aug 4, 2020 at 12:05 PM Justin Smith  wrote:

> I don't think this is true, or if true is incidental to the real problem
>
> % cljs
> ClojureScript 1.10.758
> cljs.user=> (defrecord Attr [has-default default])
> cljs.user/Attr
> cljs.user=> (get (->Attr true 1) :default)
> 1
> cljs.user=> (:default (->Attr true 1))
> nil
> cljs.user=>
>
> On Tue, Aug 4, 2020 at 11:53 AM Mark Engelberg 
> wrote:
> >
> > You misspelled default in your defrecord.
> >
> > On Tue, Aug 4, 2020 at 7:42 AM 'clartaq' via Clojure <
> clojure@googlegroups.com> wrote:
> >>
> >> I originally posted this on StackOverflow.
> >>
> >> When I try this:
> >>
> >> ```clojure
> >> (defrecord Attr [has-default default])
> >> (def attr (->Attr true 1))
> >> (get attr :default) ;;=> 1
> >> (:default attr) ;;=> ClojureScript returns nil, Clojure returns 1
> >> ```
> >>
> >> Is the difference in behavior when using keyword access expected? I
> couldn't find anything about it in the [docs][1]  on the differences
> between Clojure and ClojureScript.
> >>
> >> **Update 2020-08-04**
> >>
> >> Well, this is getting weird. This morning, if I open a REPL with
> figwheel-main, or from CIDER, it sometimes works as expected -- `(:default
> attr)` returns 1.
> >>
> >> If I try it by opening the ClojureScript REPL using `clj`, it is still
> broken.
> >>
> >> ```clojure
> >> % clj --main cljs.main --repl
> >> ClojureScript 1.10.773
> >> cljs.user=> (defrecord Attr [has-default defaut])
> >> cljs.user/Attr
> >> cljs.user=> (def attr (->Attr true 1))
> >> #'cljs.user/attr
> >> cljs.user=> (get attr :default)
> >> nil
> >> cljs.user=> (:default attr)
> >> nil
> >> cljs.user=> (:has-default attr)
> >> true
> >> cljs.user=> (println "attr: " attr)
> >> attr:  #cljs.user.Attr{:has-default true, :defaut 1}
> >> nil
> >> ```
> >>
> >>
> >>   [1]: https://www.clojurescript.org/about/differences#_data_structures
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/5dd44871-3915-4d80-a959-28be44c8cc32o%40googlegroups.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAORbMON7N3ukBEn%3D%3DzX8pAz3tJg%2BjX32x4TTDDqYdCxbWDswbA%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAGokn9LpwPYku9606pYXXzLSGQp6aphtsvckjd%3DASG6JEQM2VA%40mail.gmail.com
> .
>

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