Re: [ANN] Clojure 1.7.0-RC1 now available
Marshall, I'm unable to test at the moment, but if you replace
(java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
with
(iterator-seq (.iterator (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit)))
will it work then?
On Tuesday, May 26, 2015 at 6:25:04 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
The difference is that the original behavior allowed room to transform the
mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller al...@puredanger.com
javascript: wrote:
In what way is it broken? Both before and after wrapped a mutable
iterator into a caching seq. The new one is different in that it chunks so
reads 32 at a time instead of 1. However combining either with other
chunking sequence operations would have the same effect which is to say
that using that mutable iterator with anything else, or having expectations
about its rate of consumption was as dubious before as it is now.
Unless of course I misunderstand your intent, which possible because I am
on a phone without easy access to look further at the commit and am going
by memory.
On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift
lla...@gmail.com javascript: wrote:
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to producing seqs over iterators as
chunked iterators. This would appear to break seq-based traversal of any
iterator implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation.
I'm unable to find an existing ticket for this apparent-regression.
Should I create one, or did I miss the existing ticket, or is there some
mitigating issue which makes this a non-problem?
Thanks.
-Marshall
On Thu, May 21, 2015 at 12:31 PM Alex Miller al...@puredanger.com
javascript: wrote:
Clojure 1.7.0-RC1 is now available.
Try it via
- Download:
https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
- Leiningen: [org.clojure/clojure 1.7.0-RC1]
The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
conditional splicing an error at the top level (previously it would
silently drop all but the first spliced element).
For a full list of changes since 1.6.0, see:
https://github.com/clojure/clojure/blob/master/changes.md
Please give it a try and let us know if things are working (or not). The
more and quicker feedback we get, the sooner we can release 1.7.0 final!
- Alex
--
You received this message because you are subscribed to the Google
Groups Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure-dev...@googlegroups.com javascript:.
To post to this group, send email to cloju...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure-dev...@googlegroups.com javascript:.
To post to this group, send email to cloju...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure-dev...@googlegroups.com javascript:.
To post to this group, send email to cloju...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/clojure-dev.
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
Re: [ANN] Clojure 1.7.0-RC1 now available
I just ported an app with significant CLJX usage (55 files) to reader conditionals and it works perfectly! It looks like there is a small issue related to map literal containing comments but I am not sure if it has been reported yet. Julien Le jeudi 21 mai 2015 13:31:16 UTC-3, Alex Miller a écrit : Clojure 1.7.0-RC1 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/ - Leiningen: [org.clojure/clojure 1.7.0-RC1] The only change since 1.7.0-beta3 is CLJ-1706, which makes reader conditional splicing an error at the top level (previously it would silently drop all but the first spliced element). For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-RC1 now available
Ugh -- looks like the iterator value re-use behavior for EnumMap entrySet
was fixed post Java 1.6 (my example was under Java 1.6, which I believe
is still a Clojure-supported version of Java?). I can throw together a
synthetic example, but I think the people following this thread get what's
happening. The point isn't whether this pattern is a good idea or not
(it certainly isn't) but whether existing Java APIs people want to interop
with use it (they certainly do).
I presently depend on no less than 3 separate Java library APIs I currently
know for a fact depend on this behavior:
- Hadoop ReduceContextImpl$ValueIterator
- Mahout DenseVector$AllIterator/NonDefaultIterator
- LensKit FastIterators
It is an option to explicitly construct `IteratorSeq` instances (I actually
had verified that approach this afternoon for the Hadoop API in Parkour),
but I'm not happy about it. That approach places a definite burden on
integration library maintainers to implement the change, and on end-users
to realize they need to upgrade for Clojure 1.7 compatibility. The
`Iterator` interface just fundamentally in no way guarantees that the
`next()` yielded values are functional-safe in the sense necessary to
support chunking. I understand the desire to increase performance, but I
don't think it's worth the potential silent and bewildering breakage in
interop.
On Tue, May 26, 2015 at 9:18 PM Alex Miller a...@puredanger.com wrote:
That's not what I see with 1.7.0-RC1 (or any of the betas). I tried with
both Java 1.7.0_25 and 1.8.0-b132.
user= *clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier RC1}
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3 MINUTES=4
HOURS=5 DAYS=6]
Re implementing the not-uncommon Java pattern of mutating and re-yielding
the same object on each `next()` invocation. I'm assuming that you're
somehow expecting to traverse one seq node, then having an opportunity to
mutate something (the source, the iterator, the return object) in between
each new advancement of the seq node? That seems a) not common at all, b) a
bad idea even in Java and c) dangerous even before this change. In either
case you end up with a seq that points to a succession of the same repeated
(mutable and mutating) object - this violates most expectations we as
Clojure users have of sequences. Any sort of chunking (map, filter, etc)
over the top of that seq would force realization up to 32 elements beyond
the head causing the same issue.
The original one-at-a-time IteratorSeq is still there (for now) and you
can still make one if you want via (clojure.lang.IteratorSeq/create iter)
but I would consider it deprecated. I think a custom lazy-seq or a
loop-recur would be a better way to handle this case, which in my opinion
is highly unusual. That said, my ears are open if this is an issue for a
large number of people.
On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
The difference is that the original behavior allowed room to transform
the mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller a...@puredanger.com wrote:
In what way is it broken? Both before and after wrapped a mutable
iterator into a caching seq. The new one is different in that it chunks so
reads 32 at a time instead of 1. However combining either with other
chunking sequence operations would have the same effect which is to say
that using that mutable iterator with anything else, or having expectations
about its rate of consumption was as dubious before as it is now.
Unless of course I misunderstand your intent, which possible because I
am on a phone without easy access to look further at the commit and am
going by memory.
On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift
llas...@gmail.com wrote:
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to
Re: [ANN] Clojure 1.7.0-RC1 now available
And to further explicate bewildering -- I mean that I only figured out
what was happening because I was explicitly testing a library against
1.7.0-RC1 and even then had to `git bisect` *Clojure* to find the offending
commit. Otherwise the resulting behavior is just that values generated via
the deep guts of a complex Java API suddenly became nonsensical.
On Tue, May 26, 2015 at 9:45 PM Marshall Bockrath-Vandegrift
llas...@gmail.com wrote:
Ugh -- looks like the iterator value re-use behavior for EnumMap entrySet
was fixed post Java 1.6 (my example was under Java 1.6, which I believe
is still a Clojure-supported version of Java?). I can throw together a
synthetic example, but I think the people following this thread get what's
happening. The point isn't whether this pattern is a good idea or not
(it certainly isn't) but whether existing Java APIs people want to interop
with use it (they certainly do).
I presently depend on no less than 3 separate Java library APIs I
currently know for a fact depend on this behavior:
- Hadoop ReduceContextImpl$ValueIterator
- Mahout DenseVector$AllIterator/NonDefaultIterator
- LensKit FastIterators
It is an option to explicitly construct `IteratorSeq` instances (I
actually had verified that approach this afternoon for the Hadoop API in
Parkour), but I'm not happy about it. That approach places a definite
burden on integration library maintainers to implement the change, and on
end-users to realize they need to upgrade for Clojure 1.7 compatibility.
The `Iterator` interface just fundamentally in no way guarantees that the
`next()` yielded values are functional-safe in the sense necessary to
support chunking. I understand the desire to increase performance, but I
don't think it's worth the potential silent and bewildering breakage in
interop.
On Tue, May 26, 2015 at 9:18 PM Alex Miller a...@puredanger.com wrote:
That's not what I see with 1.7.0-RC1 (or any of the betas). I tried with
both Java 1.7.0_25 and 1.8.0-b132.
user= *clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier RC1}
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Re implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation. I'm assuming that
you're somehow expecting to traverse one seq node, then having an
opportunity to mutate something (the source, the iterator, the return
object) in between each new advancement of the seq node? That seems a) not
common at all, b) a bad idea even in Java and c) dangerous even before this
change. In either case you end up with a seq that points to a succession of
the same repeated (mutable and mutating) object - this violates most
expectations we as Clojure users have of sequences. Any sort of chunking
(map, filter, etc) over the top of that seq would force realization up to
32 elements beyond the head causing the same issue.
The original one-at-a-time IteratorSeq is still there (for now) and you
can still make one if you want via (clojure.lang.IteratorSeq/create iter)
but I would consider it deprecated. I think a custom lazy-seq or a
loop-recur would be a better way to handle this case, which in my opinion
is highly unusual. That said, my ears are open if this is an issue for a
large number of people.
On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall
Bockrath-Vandegrift wrote:
The difference is that the original behavior allowed room to transform
the mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller a...@puredanger.com wrote:
In what way is it broken? Both before and after wrapped a mutable
iterator into a caching seq. The new one is different in that it chunks so
reads 32 at a time instead of 1. However combining either with other
chunking sequence operations would have the same effect which is to say
that using that mutable iterator with anything else, or having expectations
about its rate of consumption was as dubious before as it is now.
Re: [ANN] Clojure 1.7.0-RC1 now available
Got where I could try it and instantly became very confused.
Just...take a look. http://imgur.com/4LgBdCY
On Tuesday, May 26, 2015 at 6:25:04 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
The difference is that the original behavior allowed room to transform the
mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller al...@puredanger.com
javascript: wrote:
In what way is it broken? Both before and after wrapped a mutable
iterator into a caching seq. The new one is different in that it chunks so
reads 32 at a time instead of 1. However combining either with other
chunking sequence operations would have the same effect which is to say
that using that mutable iterator with anything else, or having expectations
about its rate of consumption was as dubious before as it is now.
Unless of course I misunderstand your intent, which possible because I am
on a phone without easy access to look further at the commit and am going
by memory.
On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift
lla...@gmail.com javascript: wrote:
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to producing seqs over iterators as
chunked iterators. This would appear to break seq-based traversal of any
iterator implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation.
I'm unable to find an existing ticket for this apparent-regression.
Should I create one, or did I miss the existing ticket, or is there some
mitigating issue which makes this a non-problem?
Thanks.
-Marshall
On Thu, May 21, 2015 at 12:31 PM Alex Miller al...@puredanger.com
javascript: wrote:
Clojure 1.7.0-RC1 is now available.
Try it via
- Download:
https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
- Leiningen: [org.clojure/clojure 1.7.0-RC1]
The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
conditional splicing an error at the top level (previously it would
silently drop all but the first spliced element).
For a full list of changes since 1.6.0, see:
https://github.com/clojure/clojure/blob/master/changes.md
Please give it a try and let us know if things are working (or not). The
more and quicker feedback we get, the sooner we can release 1.7.0 final!
- Alex
--
You received this message because you are subscribed to the Google
Groups Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure-dev...@googlegroups.com javascript:.
To post to this group, send email to cloju...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure-dev...@googlegroups.com javascript:.
To post to this group, send email to cloju...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure-dev...@googlegroups.com javascript:.
To post to this group, send email to cloju...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/clojure-dev.
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
Re: [ANN] Clojure 1.7.0-RC1 now available
Problem only arises with Clojure 1.7 + Java 1.6.
/usr/lib/jvm/*java-8-oracle*/jre/bin/java -jar
~/.m2/repository/org/clojure/clojure/1.7.0-beta3/*clojure-1.7.0-beta3*.jar
Clojure 1.7.0-beta3
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3 MINUTES=4
HOURS=5 DAYS=6]
/usr/lib/jvm/*java-7-oracle*/jre/bin/java -jar
~/.m2/repository/org/clojure/clojure/1.7.0-beta3/*clojure-1.7.0-beta3*.jar
Clojure 1.7.0-beta3
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3 MINUTES=4
HOURS=5 DAYS=6]
/usr/lib/jvm/*java-6-oracle*/bin/java -jar
~/.m2/repository/org/clojure/clojure/1.7.0-beta3/*clojure-1.7.0-beta3*.jar
Clojure 1.7.0-beta3
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
--Leif
On Tuesday, May 26, 2015 at 8:39:14 PM UTC-4, Daniel wrote:
Got where I could try it and instantly became very confused.
Just...take a look. http://imgur.com/4LgBdCY
On Tuesday, May 26, 2015 at 6:25:04 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
The difference is that the original behavior allowed room to transform
the mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller al...@puredanger.com wrote:
In what way is it broken? Both before and after wrapped a mutable
iterator into a caching seq. The new one is different in that it chunks so
reads 32 at a time instead of 1. However combining either with other
chunking sequence operations would have the same effect which is to say
that using that mutable iterator with anything else, or having expectations
about its rate of consumption was as dubious before as it is now.
Unless of course I misunderstand your intent, which possible because I
am on a phone without easy access to look further at the commit and am
going by memory.
On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift
lla...@gmail.com wrote:
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to producing seqs over iterators as
chunked iterators. This would appear to break seq-based traversal of any
iterator implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation.
I'm unable to find an existing ticket for this apparent-regression.
Should I create one, or did I miss the existing ticket, or is there some
mitigating issue which makes this a non-problem?
Thanks.
-Marshall
On Thu, May 21, 2015 at 12:31 PM Alex Miller al...@puredanger.com
wrote:
Clojure 1.7.0-RC1 is now available.
Try it via
- Download:
https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
- Leiningen: [org.clojure/clojure 1.7.0-RC1]
The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
conditional splicing an error at the top level (previously it would
silently drop all but the first spliced element).
For a full list of changes since 1.6.0, see:
https://github.com/clojure/clojure/blob/master/changes.md
Please give it a try and let us know if things are working (or not).
The more and quicker feedback we get, the sooner we can release 1.7.0
final!
- Alex
--
You received this message because you are subscribed to the Google
Groups Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure Dev group.
To
Re: [ANN] Clojure 1.7.0-RC1 now available
Object Pooling Considered Harmful?
I'd be willing to bet more libraries than just Hadoop are using object
pooling like this, especially older libraries written before object
instantiation was as fast as it is now.
So, if you are doing a lot of Java interop with libraries using object
pooling, it's probably advisable to test against 1.7-RC.
--Leif
On Tuesday, May 26, 2015 at 9:19:00 PM UTC-4, Alex Miller wrote:
That's not what I see with 1.7.0-RC1 (or any of the betas). I tried with
both Java 1.7.0_25 and 1.8.0-b132.
user= *clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier RC1}
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3 MINUTES=4
HOURS=5 DAYS=6]
Re implementing the not-uncommon Java pattern of mutating and re-yielding
the same object on each `next()` invocation. I'm assuming that you're
somehow expecting to traverse one seq node, then having an opportunity to
mutate something (the source, the iterator, the return object) in between
each new advancement of the seq node? That seems a) not common at all, b) a
bad idea even in Java and c) dangerous even before this change. In either
case you end up with a seq that points to a succession of the same repeated
(mutable and mutating) object - this violates most expectations we as
Clojure users have of sequences. Any sort of chunking (map, filter, etc)
over the top of that seq would force realization up to 32 elements beyond
the head causing the same issue.
The original one-at-a-time IteratorSeq is still there (for now) and you
can still make one if you want via (clojure.lang.IteratorSeq/create iter)
but I would consider it deprecated. I think a custom lazy-seq or a
loop-recur would be a better way to handle this case, which in my opinion
is highly unusual. That said, my ears are open if this is an issue for a
large number of people.
On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
The difference is that the original behavior allowed room to transform
the mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller al...@puredanger.com
javascript: wrote:
In what way is it broken? Both before and after wrapped a mutable
iterator into a caching seq. The new one is different in that it chunks so
reads 32 at a time instead of 1. However combining either with other
chunking sequence operations would have the same effect which is to say
that using that mutable iterator with anything else, or having expectations
about its rate of consumption was as dubious before as it is now.
Unless of course I misunderstand your intent, which possible because I
am on a phone without easy access to look further at the commit and am
going by memory.
On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift
lla...@gmail.com javascript: wrote:
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to producing seqs over iterators as
chunked iterators. This would appear to break seq-based traversal of any
iterator implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation.
I'm unable to find an existing ticket for this apparent-regression.
Should I create one, or did I miss the existing ticket, or is there some
mitigating issue which makes this a non-problem?
Thanks.
-Marshall
On Thu, May 21, 2015 at 12:31 PM Alex Miller al...@puredanger.com
javascript: wrote:
Clojure 1.7.0-RC1 is now available.
Try it via
- Download:
https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
- Leiningen: [org.clojure/clojure 1.7.0-RC1]
The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
conditional splicing an error at the top level (previously it would
silently drop all but the first spliced element).
For a full list of changes since 1.6.0,
[ANN] Clojure 1.7.0-RC1 now available
I can see in Git several areas where the compiler now catches exceptions thrown and re throws them wrapped in this exception type. I've been out of town and unable to make a small example yet. I will soon. -- 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.
Education on Dynamic Binding
This page on Jira says that dynamic binding should be documented as The Clojure Way to do error handling. Was this ever done? I managed to find a few blog posts discussing approach but nothing official. http://dev.clojure.org/display/design/Error+Handling Cheers, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-RC1 now available
That's not what I see with 1.7.0-RC1 (or any of the betas). I tried with
both Java 1.7.0_25 and 1.8.0-b132.
user= *clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier RC1}
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3 MINUTES=4
HOURS=5 DAYS=6]
Re implementing the not-uncommon Java pattern of mutating and re-yielding
the same object on each `next()` invocation. I'm assuming that you're
somehow expecting to traverse one seq node, then having an opportunity to
mutate something (the source, the iterator, the return object) in between
each new advancement of the seq node? That seems a) not common at all, b) a
bad idea even in Java and c) dangerous even before this change. In either
case you end up with a seq that points to a succession of the same repeated
(mutable and mutating) object - this violates most expectations we as
Clojure users have of sequences. Any sort of chunking (map, filter, etc)
over the top of that seq would force realization up to 32 elements beyond
the head causing the same issue.
The original one-at-a-time IteratorSeq is still there (for now) and you can
still make one if you want via (clojure.lang.IteratorSeq/create iter) but I
would consider it deprecated. I think a custom lazy-seq or a loop-recur
would be a better way to handle this case, which in my opinion is highly
unusual. That said, my ears are open if this is an issue for a large number
of people.
On Tuesday, May 26, 2015 at 6:24:54 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
The difference is that the original behavior allowed room to transform the
mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller a...@puredanger.com wrote:
In what way is it broken? Both before and after wrapped a mutable
iterator into a caching seq. The new one is different in that it chunks so
reads 32 at a time instead of 1. However combining either with other
chunking sequence operations would have the same effect which is to say
that using that mutable iterator with anything else, or having expectations
about its rate of consumption was as dubious before as it is now.
Unless of course I misunderstand your intent, which possible because I am
on a phone without easy access to look further at the commit and am going
by memory.
On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift
llas...@gmail.com wrote:
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to producing seqs over iterators as
chunked iterators. This would appear to break seq-based traversal of any
iterator implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation.
I'm unable to find an existing ticket for this apparent-regression.
Should I create one, or did I miss the existing ticket, or is there some
mitigating issue which makes this a non-problem?
Thanks.
-Marshall
On Thu, May 21, 2015 at 12:31 PM Alex Miller a...@puredanger.com wrote:
Clojure 1.7.0-RC1 is now available.
Try it via
- Download:
https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
- Leiningen: [org.clojure/clojure 1.7.0-RC1]
The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
conditional splicing an error at the top level (previously it would
silently drop all but the first spliced element).
For a full list of changes since 1.6.0, see:
https://github.com/clojure/clojure/blob/master/changes.md
Please give it a try and let us know if things are working (or not). The
more and quicker feedback we get, the sooner we can release 1.7.0 final!
- Alex
--
You received this message because you are subscribed to the Google
Groups Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure-dev+unsubscr...@googlegroups.com.
To post to this group, send email to
Re: [ANN] Clojure 1.7.0-RC1 now available
Seems like this could certainly be an issue with any interaction with Hadoop's infamous reduce-side iterable object reuse. I will have to test further where I may be affected similarly. -- 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: Managing database schema
One problem we found with ragtime is that if multiple developers are working on a schema simultaneously, it's quite easy to get into a state where `lein ragtime migrate` will complain about finding a migration it doesn't expect. I think you can work around this by rolling back to the nearest common ancestor and then going forward again but it's just a bit of a speed bump to be aware of. On Thursday, 14 May 2015 02:19:01 UTC-7, Gadzhi Musaev wrote: Have you looked at ragtime? Particularly it's sql.files library. As far as I see, it will suit your needs. https://github.com/weavejester/ragtime On 14 May 2015 at 11:45, Colin Yates colin...@gmail.com javascript: wrote: Is there a lib that will allow me to have my sql defined in a file which I can reference from Clojure? I cannot use one of the existing migration libraries as I need to do more than just manipulate SQL on a version upgrade. I am aware of yesql which would be great but it didn't work out for DDL. Specifically yesql seems to associate one block of sql for each name. I want to have multiple blocks (e.g. a 'create table ...' as well as a number of 'alter table create index idx_'). I have tried embedding the sql as a string in the .clj file. This isn't as painful as it might sound but is still painful enough. Any suggestions? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-RC1 now available
No, please report if so. On Tuesday, May 26, 2015 at 8:39:32 PM UTC-5, Julien wrote: I just ported an app with significant CLJX usage (55 files) to reader conditionals and it works perfectly! It looks like there is a small issue related to map literal containing comments but I am not sure if it has been reported yet. Julien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-RC1 now available
On Tuesday, May 26, 2015 at 8:45:25 PM UTC-5, Marshall Bockrath-Vandegrift
wrote:
Ugh -- looks like the iterator value re-use behavior for EnumMap entrySet
was fixed post Java 1.6 (my example was under Java 1.6, which I believe
is still a Clojure-supported version of Java?).
Java 1.6 is still supported in Clojure 1.7 (but will likely be removed in
the next release or two).
I can throw together a synthetic example, but I think the people following
this thread get what's happening. The point isn't whether this pattern is
a good idea or not (it certainly isn't) but whether existing Java APIs
people want to interop with use it (they certainly do).
The point I was getting at is really whether you should consider this to be
broken with the old behavior too.
I presently depend on no less than 3 separate Java library APIs I
currently know for a fact depend on this behavior:
- Hadoop ReduceContextImpl$ValueIterator
- Mahout DenseVector$AllIterator/NonDefaultIterator
- LensKit FastIterators
Can you point to code for the original behavior allowed room to transform
the mutated object into an object which *could* be safely cached in a
'downstream' seq? By what means does this transformation occur? It sounds
to me like you are starting with an Iterator, creating a seq, then walking
the seq exactly once, one element at a time, and producing a new
transformed seq or other output.
If you did reuse that IteratorSeq, all of the elements of the sequence
would point to the same object which would be in the last state like the
java 1.6 example you gave. Thus, the caching capability of the seq can't
possibly be something you're using. And if that's true, then why are you
paying the allocation and synchronization costs of making the seq at all?
Why not just use the iterator directly, thus skipping all the extra
allocation that these object-reusing high-performance iterators are working
so hard to avoid in the first place? In 1.7, transducers would give you
exactly the capability to walk the source iterator, apply a transducer
version of your transformation, and output to a collection (via into), a
value (via transduce), or a lazy sequence (via sequence). I think you would
find this faster as well due to reduced allocation (possibly greatly
reduced depending on the transformation).
It is an option to explicitly construct `IteratorSeq` instances (I
actually had verified that approach this afternoon for the Hadoop API in
Parkour), but I'm not happy about it. That approach places a definite
burden on integration library maintainers to implement the change, and on
end-users to realize they need to upgrade for Clojure 1.7 compatibility.
The `Iterator` interface just fundamentally in no way guarantees that the
`next()` yielded values are functional-safe in the sense necessary to
support chunking. I understand the desire to increase performance, but I
don't think it's worth the potential silent and bewildering breakage in
interop.
It would be possible to restore the non-chunking IteratorSeq behavior but
retain it for eduction and the other places where we first made the swap.
I'm not quite ready yet to concede that that's necessary. It seems like the
only constraints under which this usage makes sense is exactly the case
where it's unnecessary and even harmful.
On Tue, May 26, 2015 at 9:18 PM Alex Miller a...@puredanger.com wrote:
That's not what I see with 1.7.0-RC1 (or any of the betas). I tried with
both Java 1.7.0_25 and 1.8.0-b132.
user= *clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier RC1}
user= (- (map vector (java.util.EnumSet/allOf
java.util.concurrent.TimeUnit) (range)) (into {}) (java.util.EnumMap.)
(.entrySet) (map str) (into []))
[NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Re implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation. I'm assuming that
you're somehow expecting to traverse one seq node, then having an
opportunity to mutate something (the source, the iterator, the return
object) in between each new advancement of the seq node? That seems a) not
common at all, b) a bad idea even in Java and c) dangerous even before this
change. In either case you end up with a seq that points to a succession of
the same repeated (mutable and mutating) object - this violates most
expectations we as Clojure users have of sequences. Any sort of chunking
(map, filter, etc) over the top of that seq would force realization up to
32 elements beyond the head causing the same issue.
The original one-at-a-time IteratorSeq is still there (for now) and you
can still make one if you want via (clojure.lang.IteratorSeq/create iter)
but I would consider it deprecated. I think a custom lazy-seq or a
loop-recur would be a better way to handle this case, which in my opinion
is highly unusual. That
Re: [ANN] Clojure 1.7.0-RC1 now available
My bad I was using an older beta. With latest RC1 the issue goes away. Julien Le mardi 26 mai 2015 23:24:41 UTC-3, Alex Miller a écrit : No, please report if so. On Tuesday, May 26, 2015 at 8:39:32 PM UTC-5, Julien wrote: I just ported an app with significant CLJX usage (55 files) to reader conditionals and it works perfectly! It looks like there is a small issue related to map literal containing comments but I am not sure if it has been reported yet. Julien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] data.int-map 0.2.0
https://github.com/clojure/data.int-map The 0.1.0 release of this library was a faithful Clojure implementation of Okasaki's Fast Mergeable Integer Maps paper [1]. While it was much faster than Clojure's sorted-maps, it was in some cases slower than hash-maps, which was mostly due to the int-maps being a binary tree, and hash-maps being a 32-ary tree. It also could only take non-negative integers, which was a limitation of the approach used in the paper. In the 0.2.0 release, I reimplemented the core data structure in Java, but more importantly adapted the data structure to use 16-ary trees under the covers. This has greatly improved performance (by a factor of 2-5x, depending on the benchmark), and has also allowed the map to have negative integers for keys. I recommend anyone using an earlier version of this library upgrade to the latest, which will be a drop-in replacement. Zach [1] http://ittc.ku.edu/~andygill/papers/IntMap98.pdf -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: what demonstrates Stuart Sierra's State/Event Pattern
Yes, you can use this pattern to define a mini-interpreter for a stream of events or commands, where each event is represented as a data structure. For example, I've used this pattern to write little scripts, a a collection of maps, for driving an integration test. –S On Monday, May 25, 2015 at 10:57:22 PM UTC+1, piastkrakow wrote: Stuart Sierra, Thank you for the response. I won't take that talk as encyclopedic. The 'chain-consequences' function is very interesting, though it is unfamiliar to me. I am still learning about Clojure. You mention that the State/Event pattern is a common one. If you were talking about architectures, I would say your description reminds me of Kafka (events are data structures, replaying events can replay the whole history of state in the app, etc) but I am curious where you feel this pattern shows up as a design pattern? I assume you mean to broadly define this to include those situations where we might use pure functions in loop or reduce to iterate over a message where the message is some data structure, perhaps a JSON document, or some other kind of seq generated by an event? -- 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 to add headers to a clojure.java.io/resource response
I have a GET route returning the result of this: (io/resource public/html/confirm.html) but I need to add Cache-Control headers. Since the `resource` function returns a java.net.URL object, how can I add headers? The normal Ring way with ring.util.response/header only operates on a Ring response. -- 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 when running java -jar rather than a managed server like tomcat?
I use procrun as a service wrapper on Windows. https://commons.apache.org/proper/commons-daemon/procrun.html It is configured by the command-line used to install it, and generally works with little fuss. I use InnoSetup to create a windows installer. For the runtime class path, I just use something like, java -cp conf;myuberjar.jar mypackage.main On Tue, May 26, 2015 at 12:38 PM, Colin Yates colin.ya...@gmail.com wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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.
Advice when running java -jar rather than a managed server like tomcat?
Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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: How to add headers to a clojure.java.io/resource response
Compojure uses the compojure.response/render protocol method to turn values like URLs into Ring responses. So you could write: (- (io/resource public/html/confirm.html) (compojure.response/render) (response/header X-Foo Bar)) Or you could use some middleware, if the header is standard across your application. Or since you know that you're delivering a HTML file, you could also write: (- (response/resource-response public/html/confirm.html) (response/content-type text/html; charset=utf-8) (response/header X-Foo Bar)) That should result in the same thing, as the only thing Compojure does that Ring doesn't is try to make an educated guess about the content type. - James On 26 May 2015 at 13:22, Jonathon McKitrick jmckitr...@gmail.com wrote: I have a GET route returning the result of this: (io/resource public/html/confirm.html) but I need to add Cache-Control headers. Since the `resource` function returns a java.net.URL object, how can I add headers? The normal Ring way with ring.util.response/header only operates on a Ring response. -- 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.
lein uberjar with prep tasks of cljx once, garden once and cljsbuild once loops forever
This looks similar to https://github.com/lynaghk/cljx/issues/60 but I am running 0.6.0. I have tried lein do clean, cljx once, garden once, cljsbuild once, uberjar but uberjar seems to clear the target directory thus making the previous tasks pointless. Any suggestions or pointers which are managing to do this successfully? 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: Advice when running java -jar rather than a managed server like tomcat?
Thanks for those links David. On 26 May 2015 at 14:06, David Powell djpow...@djpowell.net wrote: I use procrun as a service wrapper on Windows. https://commons.apache.org/proper/commons-daemon/procrun.html It is configured by the command-line used to install it, and generally works with little fuss. I use InnoSetup to create a windows installer. For the runtime class path, I just use something like, java -cp conf;myuberjar.jar mypackage.main On Tue, May 26, 2015 at 12:38 PM, Colin Yates colin.ya...@gmail.com wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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. -- 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 when running java -jar rather than a managed server like tomcat?
I'm doing some of those things at work (http-kit, logback+slf4j+MDC+clojure.tools.logging, config via property files). My entry point (main) is a Java class that reads properties file, sets system properties to hoist logging config variables, then uses reflection to load other Java/Clojure initializers that may be referring to SLF4j in some fashion. We're yet to settle on a way to run Java JAR as a system service, but we are looking at http://supervisord.org/ and https://mmonit.com/wiki/Monit/FAQ Shantanu On Tuesday, 26 May 2015 17:08:30 UTC+5:30, Colin Yates wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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: Advice when running java -jar rather than a managed server like tomcat?
We were using http://wrapper.tanukisoftware.com/doc/english/download.jsp for deploying uberjars as a service under linux (AWS), and were quite satisfied with it. On Tue, May 26, 2015 at 3:15 PM, Shantanu Kumar kumar.shant...@gmail.com wrote: I'm doing some of those things at work (http-kit, logback+slf4j+MDC+clojure.tools.logging, config via property files). My entry point (main) is a Java class that reads properties file, sets system properties to hoist logging config variables, then uses reflection to load other Java/Clojure initializers that may be referring to SLF4j in some fashion. We're yet to settle on a way to run Java JAR as a system service, but we are looking at http://supervisord.org/ and https://mmonit.com/wiki/Monit/FAQ Shantanu On Tuesday, 26 May 2015 17:08:30 UTC+5:30, Colin Yates wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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: [ANN] Clojure 1.7.0-RC1 now available
Some of my code is broken by commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in 1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy since). The culprit is the switch to producing seqs over iterators as chunked iterators. This would appear to break seq-based traversal of any iterator implementing the not-uncommon Java pattern of mutating and re-yielding the same object on each `next()` invocation. I'm unable to find an existing ticket for this apparent-regression. Should I create one, or did I miss the existing ticket, or is there some mitigating issue which makes this a non-problem? Thanks. -Marshall On Thu, May 21, 2015 at 12:31 PM Alex Miller a...@puredanger.com wrote: Clojure 1.7.0-RC1 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/ - Leiningen: [org.clojure/clojure 1.7.0-RC1] The only change since 1.7.0-beta3 is CLJ-1706, which makes reader conditional splicing an error at the top level (previously it would silently drop all but the first spliced element). For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - Alex -- You received this message because you are subscribed to the Google Groups Clojure Dev group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscr...@googlegroups.com. To post to this group, send email to clojure-...@googlegroups.com. Visit this group at http://groups.google.com/group/clojure-dev. 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: clarity on binding and thread local
If you always access *callbacks* as a thread-local, IE in the same thread,
why do you need it to be an atom? You can just rebind it using set! instead
of swap!.
Beyond that, I think that using thread locals this way is very useful when
you want to limit the need for implementations to know your specific
implementation. The other way would be to pass the transaction, or a
generic environment, around, which tends to be ugly and sometimes confusing.
Just make sure not to use it a lot and to document well.
Disclaimer - while I have many years of development experience, I am
relatively new to Clojure, but I read a lot of Clojure code at this point.
On Saturday, May 23, 2015 at 6:16:15 AM UTC-4, Colin Yates wrote:
Hi,
My use-case is that I need to have a bunch of state which differs for each
(web) request but is accessible via a var. Specifically I need to allow
code to access the current transaction and register one or callbacks that
are executed if/after that transaction is committed.
In Java I would store these as thread locals as each web request comes in
as a new thread. In Clojure, the equivalent seems to be dynamic binding.
Am I right in thinking that the following infrastructure is correct,
specifically the use of thread-bound?. And when would I use bound? rather
than thread-bound?
To be clear, the outer 'service' will call 'do-in-tx', code evaluated as a
result of 'do-in-tx' will access the current tx by calling 'with-tx'.
(def ^:dynamic *tx*)
(def ^:dynamic *callbacks*)
(defn- execute-in-tx [db f]
(jdbc/with-db-transaction
[tx db]
(binding [*tx* tx]
(f tx
(defn- execute-callbacks []
(doseq [[id cb] @*callbacks*] (cb)))
(defn do-in-tx [db f]
(when (thread-bound? #'*tx*)
(throw (IllegalArgumentException. Nested transactions are not
supported!.)))
(binding [*callbacks* (atom {})]
(execute-in-tx db f)
(execute-callbacks)))
(defn with-tx
Call back the specified function providing the current transaction.
If there is no current transaction then an (IllegalArgument)Exception is
thrown.
[f]
(when-not (thread-bound? #'*tx*)
(throw (IllegalArgumentException. No transaction found!)))
(f *tx*))
(defn register-cb [id cb]
(when-not (thread-bound? #'*callbacks*)
(throw (IllegalArgumentException. No transaction found!)))
(swap! *callbacks* assoc id cb))
--
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.
prose - a minimal language, inspired by Io/Ioke, that compiles to Clojure and ClojureScript
Hi, I wanted to show a little project I've been working on. It is called prose, the syntax is heavily inspired by Io and Ioke. It is not object-oriented, though. It does compiles to readable Clojure/Clojurescript. A quick comparison of syntax: prose: sum = reduce partial(+) [1, 2, 3] sum + 1 println Clojure: (def sum (partial reduce +)) (println (+ 1 (sum [1 2 3]))) I used Instaparse for it, which was incredible. https://github.com/aaron-lebo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clarity on binding and thread local
Hi Omri, I guess I could, using an atom to indicate multiple disparate chunks
of code will update it (all within the same thread) felt idiomatic. - the
initial (binding) is at the transaction level, subject updates are within the
transaction.
On 26 May 2015, at 17:38, Omri Hurvitz o...@vastseas.com wrote:
If you always access *callbacks* as a thread-local, IE in the same thread,
why do you need it to be an atom? You can just rebind it using set! instead
of swap!.
Beyond that, I think that using thread locals this way is very useful when
you want to limit the need for implementations to know your specific
implementation. The other way would be to pass the transaction, or a generic
environment, around, which tends to be ugly and sometimes confusing.
Just make sure not to use it a lot and to document well.
Disclaimer - while I have many years of development experience, I am
relatively new to Clojure, but I read a lot of Clojure code at this point.
On Saturday, May 23, 2015 at 6:16:15 AM UTC-4, Colin Yates wrote:
Hi,
My use-case is that I need to have a bunch of state which differs for each
(web) request but is accessible via a var. Specifically I need to allow code
to access the current transaction and register one or callbacks that are
executed if/after that transaction is committed.
In Java I would store these as thread locals as each web request comes in as
a new thread. In Clojure, the equivalent seems to be dynamic binding.
Am I right in thinking that the following infrastructure is correct,
specifically the use of thread-bound?. And when would I use bound? rather
than thread-bound?
To be clear, the outer 'service' will call 'do-in-tx', code evaluated as a
result of 'do-in-tx' will access the current tx by calling 'with-tx'.
(def ^:dynamic *tx*)
(def ^:dynamic *callbacks*)
(defn- execute-in-tx [db f]
(jdbc/with-db-transaction
[tx db]
(binding [*tx* tx]
(f tx
(defn- execute-callbacks []
(doseq [[id cb] @*callbacks*] (cb)))
(defn do-in-tx [db f]
(when (thread-bound? #'*tx*)
(throw (IllegalArgumentException. Nested transactions are not
supported!.)))
(binding [*callbacks* (atom {})]
(execute-in-tx db f)
(execute-callbacks)))
(defn with-tx
Call back the specified function providing the current transaction.
If there is no current transaction then an (IllegalArgument)Exception is
thrown.
[f]
(when-not (thread-bound? #'*tx*)
(throw (IllegalArgumentException. No transaction found!)))
(f *tx*))
(defn register-cb [id cb]
(when-not (thread-bound? #'*callbacks*)
(throw (IllegalArgumentException. No transaction found!)))
(swap! *callbacks* assoc id cb))
--
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
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com
mailto:clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout
https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: How can I remove this nil? check from my code?
Your two functions can be written more succinctly (and with fewer explicit
conditionals) like these, but they will be harder for a beginner to
understand. (The nested update-in with fnil in particular may cause
confusion.)
(defn add-placeholder-to-history [users]
(reduce-kv (fn [users uk {:keys [history]}]
(assoc-in users [uk :history]
(into [{}] (take 2 history
users users))
(defn update-history [users {:keys [category prize-money winner]}]
(update-in users [winner]
(fnil update-in {:history [{}]}) [:history 0 category]
(fnil + 0) prize-money))
You may have a good pedagogical reason for your current implementation, but
I would take a different approach: build the new history entries first,
then add them to the users.
(defn winnings-by-user [contests]
(reduce
(fn [user+winning {:keys [category winner prize-money]}]
(update-in user+winning [winner category] (fnil + 0) prize-money))
{} contests))
(defn update-histories [users new-winnings]
(let [all-user-keys (set (concat (keys users) (keys new-winnings)))]
(reduce (fn [users ukey]
(update-in users [ukey :history]
#(into [(get new-winnings ukey {})] (take 2 %
users all-user-keys)))
(update-histories users (winnings-by-user contests))
On Tuesday, May 26, 2015 at 12:37:34 AM UTC-5, Chris Freeman wrote:
It seems like, if you don't mind doing the assoc all the time, you could
replace the whole if with something like:
(assoc nu (:winner c) (or ((:winner c) nu) {:history [{}]}))
You might want to wrap that in a let so you don't repeat (:winner c).
Also, it looks like add-placeholder-to-history could be a map over an
update-in instead of a loop, like:
(defn prepend-hash [x]
(into [{}] x))
(defn add-placeholder-to-history [us]
(into {} (map #(update-in % [1 :history] prepend-hash) us)))
Chris
On Mon, May 25, 2015 at 5:07 PM, lawr...@waleup.com javascript: wrote:
I started to write an essay, aimed at those programmers who are
experienced with highly mutable languages such as Javascript, Ruby, PHP,
etc, to demonstrate how one's code style changes when one switches to a
mostly immutable language such as Clojure. However, my Clojure code is not
nearly as terse as I wanted. In particular, I have this nil check:
(if (nil? ((:winner c) nu))
(assoc nu (:winner c) {:history [{}]})
nu)
which I assume I am writing because I am ignorant. I'm guessing there
might be something clever I can do to avoid this?
For my code examples, I'm working with these 2 data structures:
(def users {
:henry {
:history
[
{:housing 25, :restaurants 40, :theater 930},
{:restaurants 30, :crisis 220}
]
},
:lisa {
:history
[
{:theater 80},
{:housing 445, :restaurants 15, :theater 35}
]
},
:pasha {
:history
[
{:restaurants 5},
{:restaurants 40, :theater 60}
]
},
:eli {
:history
[
{:crisis 135, :restaurants 440, :theater 65},
{:theater 95}
]
}
})
(def contests [{:category :housing, :prize-money 100, :winner :eli},
{:category :housing, :prize-money 30, :winner :henry},
{:category :housing, :prize-money 340, :winner :henry},
{:category :housing, :prize-money 45, :winner :susan},
{:category :housing, :prize-money 15, :winner :henry},
{:category :housing, :prize-money 10, :winner :pasha},
{:category :housing, :prize-money 25, :winner :pasha},
{:category :crisis, :prize-money 100, :winner :eli},
{:category :crisis, :prize-money 2330, :winner :henry},
{:category :crisis, :prize-money 90, :winner :henry},
{:category :restaurants, :prize-money 1130, :winner :eli},
{:category :restaurants, :prize-money 130, :winner :pasha},
{:category :theater, :prize-money 60, :winner :eli},
{:category :theater, :prize-money 90, :winner :pasha},
{:category :theater, :prize-money 130, :winner :pasha},
{:category :theater, :prize-money 830, :winner :susan},
{:category :theater, :prize-money 90, :winner :susan},
{:category :theater, :prize-money 270, :winner :eli}])
Presumably users shows past winnings from 2 rounds of some contest,
whereas contests shows the winnings from the 3rd round, which need to be
added to users. So I wrote:
(defn
Re: [ANN] Pedestal 0.4.0 and doc updates
The roadmap for Pedestal has been saying for a while that the focus going forward is on various forms of documentation, yet most of the files in the documentation folder haven't been touched for quite some time. When I last wanted to take a closer look at Pedestal this put me off, because I figured the documentation was both out of date (tons of commits, yet none to the docs) and that more and/or better documentation was coming shortly. Is this stuff still coming, or is this as good a time as any to take a closer look at Pedestal? On Tuesday, May 26, 2015 at 4:56:46 PM UTC+2, Paul deGrandis wrote: Hi all, Pedestal https://github.com/pedestal/pedestal 0.4.0 has been released, featuring: - A very fast and efficient prefix-tree router - The ability to plug-in new routers - A simplified and improved Interceptor API - Advanced error handling capabilities for async systems - and more! For a list of all changes, please see the release notes https://github.com/pedestal/pedestal/releases. Additionally, the README https://github.com/pedestal/pedestal#notable-capabilities has been updated to highlight why Pedestal is a compelling option when building Clojure web services. I encourage everyone to give Pedestal another look! Cheers, Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] Pedestal 0.4.0 and doc updates
Hi all, Pedestal https://github.com/pedestal/pedestal 0.4.0 has been released, featuring: - A very fast and efficient prefix-tree router - The ability to plug-in new routers - A simplified and improved Interceptor API - Advanced error handling capabilities for async systems - and more! For a list of all changes, please see the release notes https://github.com/pedestal/pedestal/releases. Additionally, the README https://github.com/pedestal/pedestal#notable-capabilities has been updated to highlight why Pedestal is a compelling option when building Clojure web services. I encourage everyone to give Pedestal another look! Cheers, Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-RC1 now available
In what way is it broken? Both before and after wrapped a mutable iterator into a caching seq. The new one is different in that it chunks so reads 32 at a time instead of 1. However combining either with other chunking sequence operations would have the same effect which is to say that using that mutable iterator with anything else, or having expectations about its rate of consumption was as dubious before as it is now. Unless of course I misunderstand your intent, which possible because I am on a phone without easy access to look further at the commit and am going by memory. On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift llas...@gmail.com wrote: Some of my code is broken by commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in 1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy since). The culprit is the switch to producing seqs over iterators as chunked iterators. This would appear to break seq-based traversal of any iterator implementing the not-uncommon Java pattern of mutating and re-yielding the same object on each `next()` invocation. I'm unable to find an existing ticket for this apparent-regression. Should I create one, or did I miss the existing ticket, or is there some mitigating issue which makes this a non-problem? Thanks. -Marshall On Thu, May 21, 2015 at 12:31 PM Alex Miller a...@puredanger.com wrote: Clojure 1.7.0-RC1 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/ - Leiningen: [org.clojure/clojure 1.7.0-RC1] The only change since 1.7.0-beta3 is CLJ-1706, which makes reader conditional splicing an error at the top level (previously it would silently drop all but the first spliced element). For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - Alex -- You received this message because you are subscribed to the Google Groups Clojure Dev group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscr...@googlegroups.com. To post to this group, send email to clojure-...@googlegroups.com. Visit this group at http://groups.google.com/group/clojure-dev. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure Dev group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscr...@googlegroups.com. To post to this group, send email to clojure-...@googlegroups.com. Visit this group at http://groups.google.com/group/clojure-dev. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN]: Matcha, a library for composable test assertions with human readable error messages
This looks pretty cool! One thing I wonder, though, why am I seeing all
these \n values rather than actual newlines in the actual value, which
would make the output so much easier to read? Is there any way to configure
or use it differently that would avoid this issue? (This is with lein test
right after adding the dependency to my project.clj and changing one test
to use matcha). Also, the expected message looks a little broken, should
it not instead say something like expected: a map with entry :status that
equals 201? (there is no word between that and 201):
FAIL in (starting-and-stopping-production-server-works-as-expected)
(httpkit_test.clj:17)
start-production-server causes HttpKit and Hazelcast to start
expected: a map with entry :status that 201
actual: a map with 200\n class java.lang.Integer\ndiff:\n +:
201\n\n -: 200\n at key :status (was {:orig-content-encoding nil,
:trace-redirects [\http://localhost:12081/idp/status\;], :request-time
355, :status 200, :headers {\Date\ \Tue, 26 May 2015 21:36:11 GMT\,
\Server\ \http-kit\, \Content-Length\ \319\, \Content-Type\
\application/json\}, :body \{\\n \\\status\\\ : \\\up\\\,\\n
\\\database\\\ : \\\READ FAILED\\\,\\n \\\build\\\ :
\\\DEV\\\,\\n \\\time\\\ : \\\2015-05-26T21:36:11Z\\\,\\n
\\\loadAverage\\\ : 1.82666015625,\\n \\\heap\\\ : {\\n
\\\committed\\\ : 476053504,\\n\\\max\\\ : 3817865216,\\n
\\\used\\\ : 277027488\\n },\\n \\\nonHeap\\\ : {\\n
\\\committed\\\ : 75104256,\\n\\\max\\\ : -1,\\n\\\used\\\ :
71632504\\n }\\n}\})
On Monday, May 25, 2015 at 3:27:13 PM UTC-5, tcrayford wrote:
Matcha lets you write flexible, composable test assertions with human
friendly error messages. It's modeled after the excellent Java Hamcrest
library.
As a quick example, you might build up a matcher that says this map has 5
elements, and the :foo key must be greater than 10 like so:
```
(require '[matcha :as m])
(deftest my-map-test
(m/is (m/and (m/has-entry-that :foo (m/ 10)) (m/has-count 5))
my-map))
```
If that ever returns false, you'll get an *excellently* readable error
message, detailing exactly why it failed.
Matcha is completely test framework independent, though it does ship with
clojure.test support out of the box. Wiring it up to your test framework of
choice should take only a few minutes.
Read more examples here
http://yellerapp.com/posts/2015-25-05-matcha.html, grab the code on
github https://github.com/yeller/matcha or checkout the api docs
http://yeller.github.io/matcha/doc/matcha.html.
--
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]: Matcha, a library for composable test assertions with human readable error messages
Oh, sorry, here is my actual test: (m/is (m/has-entry-that :status (m/= 200)) (http/get http://localhost:12081/idp/status;)) -- 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 when running java -jar rather than a managed server like tomcat?
Thanks all for your excellent tips - keep it coming :). On 26 May 2015, at 15:57, Henrik Lundahl henrik.lund...@gmail.com wrote: Hi For Logback you can set a system property (logback.configurationFile) that points to the location of your logback.xml. See http://logback.qos.ch/manual/configuration.html http://logback.qos.ch/manual/configuration.html. BR -- Henrik On Tue, May 26, 2015 at 1:38 PM, Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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 mailto: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 mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: Advice when running java -jar rather than a managed server like tomcat?
http://circus.readthedocs.org/en/0.11.1/ We are using it not only for deploy java, also: python and nodejs applications. Is a generc process monitor in a userspace with good comand line interface, with web interface, ... and works pretty well! Andrey On Tue, May 26, 2015 at 3:24 PM, Jozef Wagner jozef.wag...@gmail.com wrote: We were using http://wrapper.tanukisoftware.com/doc/english/download.jsp for deploying uberjars as a service under linux (AWS), and were quite satisfied with it. On Tue, May 26, 2015 at 3:15 PM, Shantanu Kumar kumar.shant...@gmail.com wrote: I'm doing some of those things at work (http-kit, logback+slf4j+MDC+clojure.tools.logging, config via property files). My entry point (main) is a Java class that reads properties file, sets system properties to hoist logging config variables, then uses reflection to load other Java/Clojure initializers that may be referring to SLF4j in some fashion. We're yet to settle on a way to run Java JAR as a system service, but we are looking at http://supervisord.org/ and https://mmonit.com/wiki/Monit/FAQ Shantanu On Tuesday, 26 May 2015 17:08:30 UTC+5:30, Colin Yates wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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. -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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.
[Component] - Remove (dissoc) component from system
Hi everyone, I am using componente framework https://github.com/stuartsierra/component, I have the follow system: (def system (let [config (get envs :dev)] (component/system-map :db (db-connection (get (get config :db) :host) (get (get config :db) :db-name) (get (get config :db) :port)) :http-server (s/new-http-server 8080) :confs config :receivers receivers))) There is some way to remove some component after it start? I tried use disassoc, but without success. Any idea how to I can do this? Thanks in advance for any help. Édipo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: lein uberjar with prep tasks of cljx once, garden once and cljsbuild once loops forever
Adding :auto-clean false to project.clj *might* do the trick. BR -- Henrik On Tue, May 26, 2015 at 1:54 PM, Colin Yates colin.ya...@gmail.com wrote: This looks similar to https://github.com/lynaghk/cljx/issues/60 but I am running 0.6.0. I have tried lein do clean, cljx once, garden once, cljsbuild once, uberjar but uberjar seems to clear the target directory thus making the previous tasks pointless. Any suggestions or pointers which are managing to do this successfully? 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: Advice when running java -jar rather than a managed server like tomcat?
Hi For Logback you can set a system property (logback.configurationFile) that points to the location of your logback.xml. See http://logback.qos.ch/manual/configuration.html. BR -- Henrik On Tue, May 26, 2015 at 1:38 PM, Colin Yates colin.ya...@gmail.com wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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: [ANN] Clojure 1.7.0-RC1 now available
The difference is that the original behavior allowed room to transform the
mutated object into an object which *could* be safely cached in a
downstream seq, while the new behavior pumps the iterator through 32
mutations before user-level code has a chance to see it. Contrived example
using the Java standard libary:
Clojure 1.6.0:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [NANOSECONDS=0 MICROSECONDS=1 MILLISECONDS=2 SECONDS=3
MINUTES=4 HOURS=5 DAYS=6]
Clojure 1.7.0-RC1:
(- (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit)
(range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
#= [DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6 DAYS=6]
IMHO the latter behavior demonstrates a mismatch where chunked seqs and
iterators are simple incompatible.
On Tue, May 26, 2015 at 5:33 PM Alex Miller a...@puredanger.com wrote:
In what way is it broken? Both before and after wrapped a mutable iterator
into a caching seq. The new one is different in that it chunks so reads 32
at a time instead of 1. However combining either with other chunking
sequence operations would have the same effect which is to say that using
that mutable iterator with anything else, or having expectations about its
rate of consumption was as dubious before as it is now.
Unless of course I misunderstand your intent, which possible because I am
on a phone without easy access to look further at the commit and am going
by memory.
On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift
llas...@gmail.com wrote:
Some of my code is broken by
commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in
1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy
since). The culprit is the switch to producing seqs over iterators as
chunked iterators. This would appear to break seq-based traversal of any
iterator implementing the not-uncommon Java pattern of mutating and
re-yielding the same object on each `next()` invocation.
I'm unable to find an existing ticket for this apparent-regression.
Should I create one, or did I miss the existing ticket, or is there some
mitigating issue which makes this a non-problem?
Thanks.
-Marshall
On Thu, May 21, 2015 at 12:31 PM Alex Miller a...@puredanger.com wrote:
Clojure 1.7.0-RC1 is now available.
Try it via
- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
- Leiningen: [org.clojure/clojure 1.7.0-RC1]
The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
conditional splicing an error at the top level (previously it would
silently drop all but the first spliced element).
For a full list of changes since 1.6.0, see:
https://github.com/clojure/clojure/blob/master/changes.md
Please give it a try and let us know if things are working (or not). The
more and quicker feedback we get, the sooner we can release 1.7.0 final!
- Alex
--
You received this message because you are subscribed to the Google Groups
Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure-dev+unsubscr...@googlegroups.com.
To post to this group, send email to clojure-...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure-dev+unsubscr...@googlegroups.com.
To post to this group, send email to clojure-...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Clojure Dev group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure-dev+unsubscr...@googlegroups.com.
To post to this group, send email to clojure-...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN]: Matcha, a library for composable test assertions with human readable error messages
The API docs need a little love too... It seems that the examples for has-nth are actually for has-count; the second example for both has-denominator and has-numerator are actually about nil?, the examples for has-key appear to actually be testing the values, not the keys, the examples for not are reversed... Actually, rather than make you wade through and figure out what I mean, I will just submit a pull request, and suggest some improved wording and more disambiguation while I am at it. Someone will need to double check the examples I came up with for has-nth because I came up with them by inspecting the code, and I am new to this package. Also, for clarity, I proposed adding the following example for matcha/every? (matcha/run-match (matcha/every? (matcha/= 1)) []) ; = passes Is this true? An empty sequence does not have any items which fail, so I would expect so. I am not sure if the isa? documentation is correct. It looks backwards to me, but I may just not understand what isa? is trying to test. Which suggests it could and should be clarified, at least! Anyway, please take my suggestions and questions in the spirit in which I intend them: Excitement about this new package, and a desire to help it get even better! -James On Monday, May 25, 2015 at 3:27:13 PM UTC-5, tcrayford wrote: Matcha lets you write flexible, composable test assertions with human friendly error messages. It's modeled after the excellent Java Hamcrest library. As a quick example, you might build up a matcher that says this map has 5 elements, and the :foo key must be greater than 10 like so: ``` (require '[matcha :as m]) (deftest my-map-test (m/is (m/and (m/has-entry-that :foo (m/ 10)) (m/has-count 5)) my-map)) ``` If that ever returns false, you'll get an *excellently* readable error message, detailing exactly why it failed. Matcha is completely test framework independent, though it does ship with clojure.test support out of the box. Wiring it up to your test framework of choice should take only a few minutes. Read more examples here http://yellerapp.com/posts/2015-25-05-matcha.html, grab the code on github https://github.com/yeller/matcha or checkout the api docs http://yeller.github.io/matcha/doc/matcha.html. -- 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.
repost (bad url): prose is a minimal language that is inspired by Io and Ioke that compiles down to Clojure and ClojureScript
Hi, I wanted to show a little project I've been working on. It is called prose, the syntax is heavily inspired by Io and Ioke. It is not object-oriented, though. It does compiles to readable Clojure/Clojurescript. A quick comparison of syntax: prose: sum = reduce partial(+) [1, 2, 3] sum + 1 println Clojure: (def sum (partial reduce +)) (println (+ 1 (sum [1 2 3]))) I used Instaparse for it, which was incredible. https://github.com/aaron-lebo/prose -- 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: prose - a minimal language, inspired by Io/Ioke, that compiles to Clojure and ClojureScript
Sorry, the url is https://github.com/aaron-lebo/prose On Tuesday, May 26, 2015 at 11:49:13 AM UTC-5, Aaron Lebo wrote: Hi, I wanted to show a little project I've been working on. It is called prose, the syntax is heavily inspired by Io and Ioke. It is not object-oriented, though. It does compiles to readable Clojure/Clojurescript. A quick comparison of syntax: prose: sum = reduce partial(+) [1, 2, 3] sum + 1 println Clojure: (def sum (partial reduce +)) (println (+ 1 (sum [1 2 3]))) I used Instaparse for it, which was incredible. https://github.com/aaron-lebo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clarity on binding and thread local
Yeh - I'm struggling with this myself. My intuition is 'atom signifies
multithreaded access', but I did not see a lot of rebinding in idiomatic
Clojure.
On Tuesday, May 26, 2015 at 12:47:05 PM UTC-4, Colin Yates wrote:
Hi Omri, I guess I could, using an atom to indicate multiple disparate
chunks of code will update it (all within the same thread) felt idiomatic.
- the initial (binding) is at the transaction level, subject updates are
within the transaction.
On 26 May 2015, at 17:38, Omri Hurvitz om...@vastseas.com javascript:
wrote:
If you always access *callbacks* as a thread-local, IE in the same thread,
why do you need it to be an atom? You can just rebind it using set! instead
of swap!.
Beyond that, I think that using thread locals this way is very useful when
you want to limit the need for implementations to know your specific
implementation. The other way would be to pass the transaction, or a
generic environment, around, which tends to be ugly and sometimes confusing.
Just make sure not to use it a lot and to document well.
Disclaimer - while I have many years of development experience, I am
relatively new to Clojure, but I read a lot of Clojure code at this point.
On Saturday, May 23, 2015 at 6:16:15 AM UTC-4, Colin Yates wrote:
Hi,
My use-case is that I need to have a bunch of state which differs for
each (web) request but is accessible via a var. Specifically I need to
allow code to access the current transaction and register one or callbacks
that are executed if/after that transaction is committed.
In Java I would store these as thread locals as each web request comes in
as a new thread. In Clojure, the equivalent seems to be dynamic binding.
Am I right in thinking that the following infrastructure is correct,
specifically the use of thread-bound?. And when would I use bound? rather
than thread-bound?
To be clear, the outer 'service' will call 'do-in-tx', code evaluated as
a result of 'do-in-tx' will access the current tx by calling 'with-tx'.
(def ^:dynamic *tx*)
(def ^:dynamic *callbacks*)
(defn- execute-in-tx [db f]
(jdbc/with-db-transaction
[tx db]
(binding [*tx* tx]
(f tx
(defn- execute-callbacks []
(doseq [[id cb] @*callbacks*] (cb)))
(defn do-in-tx [db f]
(when (thread-bound? #'*tx*)
(throw (IllegalArgumentException. Nested transactions are not
supported!.)))
(binding [*callbacks* (atom {})]
(execute-in-tx db f)
(execute-callbacks)))
(defn with-tx
Call back the specified function providing the current transaction.
If there is no current transaction then an (IllegalArgument)Exception is
thrown.
[f]
(when-not (thread-bound? #'*tx*)
(throw (IllegalArgumentException. No transaction found!)))
(f *tx*))
(defn register-cb [id cb]
(when-not (thread-bound? #'*callbacks*)
(throw (IllegalArgumentException. No transaction found!)))
(swap! *callbacks* assoc id cb))
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com javascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: prose - a minimal language, inspired by Io/Ioke, that compiles to Clojure and ClojureScript
I'm sorry, but for some reason I can't seem to view the contents of this thread. In fact, even the reply button on it isn't working correctly (just does nothing) so I'm having to create a new thread with the appropriate subject line. Google seems to have effed something up here so perhaps you should repost both posts about prose so that we can read them. -- 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] Pedestal 0.4.0 and doc updates
Effort was invested in updating the `samples https://github.com/pedestal/pedestal/tree/master/samples` over the docs, since it seemed like more people used those and we knew there were architectural changes coming down the roadmap. We added the API docs http://pedestal.github.io/pedestal/ which we update with every version. The prose-oriented documentation will be updated immediately after the 0.5.0 releases (which have the last significant change - Pedestal will no longer be Servlet-specific, but rather Servlet-optional). Given the API docs, the updated samples, and the wealth of information and help on the mailing list https://groups.google.com/forum/#!forum/pedestal-users, now is a great time to take another look. The APIs have gotten smaller and simpler, the performance and default security have greatly improved, and there are unique, compelling features within Pedestal that make it clearly stand out from the pack. Cheers, Paul -- 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: prose - a minimal language, inspired by Io/Ioke, that compiles to Clojure and ClojureScript
It isn't Google, I just don't use mailing lists often. I gave a bad URL and I figured deleted the original messages would delete the thread. Here is the repost: https://groups.google.com/forum/?hl=en#!topic/clojure/NV8ujk4L8MI On Tuesday, May 26, 2015 at 11:59:14 AM UTC-5, Fluid Dynamics wrote: I'm sorry, but for some reason I can't seem to view the contents of this thread. In fact, even the reply button on it isn't working correctly (just does nothing) so I'm having to create a new thread with the appropriate subject line. Google seems to have effed something up here so perhaps you should repost both posts about prose so that we can read them. -- 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.
