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

[tcrayford]

Hi,

I ran Yeller's very extensive benchmark suite against Clojure 1.8 RC1.
I saw no performance regressions, over 72 individual benchmarks.
There were no notable performance improvements either (all benchmarks were
comparatively equal to a benchmark run against 1.7 with a 95% confidence 
interval).

I've also ran Yeller's (extensive) test.check based suite (94 individual
test.check properties) for 24h on a CI machine against Clojure 1.8 RC1 and 
saw
no test failures at all. There were ~1 billion assertions made during that
test run.

So, from all my testing, Clojure 1.8 RC1 seems to be fine. Thumbs up on my 
end.

Thanks for all the hard work that goes into making Clojure so stable.

Tom Crayford
Founder, yellerapp.com

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

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

[ANN]: Matcha, a library for composable test assertions with human readable error messages

[tcrayford]

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 , 
grab the code on github  or checkout the api 
docs .

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

[tcrayford]

Java 7 is EOL as of last week, so pretty much everybody who runs stuff in 
production should be upgrading to Java 8 unless they have a support 
contract that lets them do otherwise. There won't be (as far as I know) 
more security updates/etc on the Java 7 line any more.

Yeller's (http://yellerapp.com) been on oracle jdk8 for quite a while now. 
It's been great - there were notable performance improvements when 
upgrading to java 8, and stability is just as good as ever. Quite a few 
folk I know have seen much better behavior out of the G1GC under Java 8.

```
java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
```

On Thursday, 7 May 2015 21:25:13 UTC+1, Pierre-Yves Ritschard wrote:
>
> Hi,
>
> There hasn't been a JDK version thread in a while and a few projects we 
> rely on will soon require a JDK8. Are people running large apps on JDK8 and 
> if so, which one ? I'd be intent on trying to stick with OpenJDK if at all 
> possible.
>
> Cheers,
>
>

-- 
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] Bolth: a humane, parallelized test runner for clojure.test

[tcrayford]

Hi there,

I've written a new test runner for clojure.test. It does 2 main new things: 
parallelization, and *much* better output, error reporting, and some 
surrounding formatting/running features.

All the features were extracted from stuff I've accumulated in my app's 
user namespace over the last year or so in an effort to improve my own 
development experience.

1. Much improved output

bolth uses the same output format as humane-test-output: it diff's data 
structures passed to = and reports the difference when reporting failing 
tests. This is a huge win for testing things in larger data structures 
(especially maps), it just tells you "yo, this key is different", not "yo 
this 30 line data structure isn't equal to the other one".

It uses aviso/pretty to pretty print exception stacktraces, removing a 
bunch of the noise, making them the right way up (i.e. latest frame at the 
bottom so you don't have to scroll up all the time to find the error 
message/causing frame). There's also a tiny tools.namespace wrapper that 
lets you invoke tools.namespace and get pretty exceptions printed out 
rather than the usual garbage from the compiler.

It can report the slowest N tests in the test suite, so you can debug why 
your test suite is slow easily (suites I've tried it on usually have test 
runtime dominated by a few tests, that can often be improved without too 
much effort).

It reports the number of tests run, and the runtime per test, which can 
give you a goal (I typically get about 0.25ms or so per test in my app).

It can clear the screen, which is useful for outputting to a repl, because 
you remove the noise from other test failures (see the gifs in the post for 
what that looks like).

It can call `System/exit` with an good exit code based on if the tests 
passed or not (this is off by default, because you'll only really want it 
in CI, definitely not in a repl). This stops you writing that wrapper once 
again.

2. Parallelization of test runs

Bolth parallelizes test runs. This means it's only suitable for test suites 
where each test is completely isolated from the others (the easiest way to 
achieve this is having a test suite that's purely in memory, but it's 
possible to isolate databases as well, just not a thing I've done).

You can read more about it 
here: http://yellerapp.com/posts/2015-04-23-bolth.html

Enjoy!

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

[tcrayford]

I've been running beta1 in production since about 1 day after it was 
announced. Everything's been smooth so far :D

On Friday, 17 April 2015 06:51:53 UTC+12, Sean Corfield wrote:
>
> We deployed beta1 to production this morning. I’ll report back if we 
> encounter any problems (generally we’ve found Clojure pre-release builds to 
> be very stable). We were previously running alpha5 in production.
>
> Sean
>
> On Apr 10, 2015, at 12:25 PM, Alex Miller  > wrote:
>
> Clojure 1.7.0-beta1 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta1/
> - Leiningen: [org.clojure/clojure "1.7.0-beta1"]
>
> Regression fixes since 1.7.0-alpha6:
>
> 1) CLJ-1692 - make iterate match prior laziness
> 2) CLJ-1694 - make cycle match prior laziness
> 3) CLJ-1685 - correctly handle :eof option in read and read-string
>
> One faster sequence and reduce path that didn't quite make it into alpha6 
> is now available - range is now faster for both the traditional sequence 
> use case (both chunked and unchunked traversal) and the fast reduce path.
>
> Also, since alpha6 was released, reader conditionals were ported to 
> tools.reader and the latest ClojureScript release now supports them, so now 
> is a great time to try them out!
>   
> For all changes new in beta1, see the issues marked "(beta1)" in the
> full changes below.
> …
>
>
>
>

-- 
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: Kwargs vs explicit parameter map for APIs?

[tcrayford]

Yep: that won't override the arg if the caller passes it to you as well.

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

[tcrayford]

Alex:

I'd bet heavily on the "slower" ones being measurement noise (they only 
differ by a few percent) - I typically see that much variation between 
runs. I probably shouldn't have reported them as "slower" - 1-5% is (in my 
experience) typically just noise, so don't think it's worth digging into.

On Thursday, 2 April 2015 21:39:54 UTC+9, Alex Miller wrote:
>
> Great to hear feedback like this! I'd be particularly interested if you 
> had any suspicions about the characteristics of the ones that are slower.
>
>
>
> On Apr 2, 2015, at 3:22 AM, tcrayford > 
> wrote:
>
> Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark 
> suite
> (using criterium, with a heck of a lot of work put into getting real and 
> good
> results). I've run Yeller's benchmark suite against clojure 1.7 alpha6 - 
> it's
> pretty comprehensive, and covers a wide range of things. Results are below.
>
> Mostly some things got very minorly slower (but not enough to make a real
> impact for the application), but quite a few benchmarks saw **dramatic**
> speedups.
>
> Given these promising results, I ran Yeller's `test.check` suite for 8 
> hours in
> CI, and didn't see any failures, so I've deployed 1.7 alpha6 to 
> production, and
> haven't seen any issues as of yet.
>
> Yeller's build also got ~24 seconds faster, which is super awesome (and it 
> no
> longer breaks under CLJ-1604 because that patch is in).
>
> Much love to all the folk who put time and work into this release.
>
> Benchmark names retracted because they're proprietary. Each line is a 
> seperate benchmark, recorded on production level hardware, with the same 
> jvm options/version used in production. Each benchmark is run in its own 
> JVM (because otherwise JIT path dependence will kill you).
>
> Benchmarks that were slower under 1.7 alpha6 vs 1.6.0 (with percentage 
> changed amounts):
> 3.12%
> 2.62%
> 2.27%
> 2.19%
> 2.17%
> 2.06%
> 1.97%
> 1.43%
> 1.29%
> 0.89%
> 0.74%
> 0.71%
> 0.58%
> 0.45%
> 0.42%
> 0.34%
> 0.27%
> 0.25%
> 0.21%
> 0.2%
> 0.08%
> 0.03%
>
> Benchmarks that were faster under 1.7 alpha6 vs 1.6.0 (with percentage 
> changed amounts):
> +0.0%
> +0.0%
> +0.01%
> +0.02%
> +0.03%
> +0.03%
> +0.03%
> +0.04%
> +0.04%
> +0.09%
> +0.12%
> +0.16%
> +0.31%
> +0.33%
> +0.52%
> +0.53%
> +0.85%
> +1.74%
> +1.84%
> +1.99%
> +2.14%
> +2.17%
> +2.42%
> +2.96%
> +3.0%
> +5.18%
> +5.36%
> +9.86%
> +11.93%
> +12.41%
> +14.36%
> +16.95%
> +24.71%
> +53.5%
> +53.62%
> +72.07%
>
> Thanks again! Super excited about this release.
>
> On Wednesday, 1 April 2015 01:51:13 UTC+9, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>
> Regression fixes from previous alphas (and one from 1.6):
>
> 1) CLJ-1544 was rolled back and will be investigated for a future release.
> 2) CLJ-1637 fixed regression with vec on MapEntry 
> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) 
> method
> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for 
> literal nil arg
> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that 
> prevented update
>
> Some highlights new in alpha6:
>
> ## Transducer-related changes:
>
> The LazyTransformer introduced to create lazy transforming sequences has 
> been 
> replaced with a TransformingIterator. This was done to simplify the code
> around transformations and to make certain use cases around eduction more 
> efficient.
>
> ## Faster reduce, iterator, and sequence paths
>
> A lot of work has been done across a set of tickets to improve the ability 
> of
> collections to provide more efficient reduce or iterator performance, and 
> also to
> make common sequence generators create faster sequence and reduce paths. 
> You
> should see significant performance in many reduce-related paths (this 
> includes 
> reduce, transduce, into, and anything else built on reduce). 
>
> Many of those changes also have beneficial sequence performance, so you 
> may see
> some benefits even in code that does not use transducers.
>
> * Most uses of SeqIterator have now been replaced with iterators that 
> directly walk
> the underlying source for improved efficiency. This includes maps, sets, 
> records, etc.
&g

Re: [ANN] Clojure 1.7.0-alpha6 released

[tcrayford]

Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark 
suite
(using criterium, with a heck of a lot of work put into getting real and 
good
results). I've run Yeller's benchmark suite against clojure 1.7 alpha6 - 
it's
pretty comprehensive, and covers a wide range of things. Results are below.

Mostly some things got very minorly slower (but not enough to make a real
impact for the application), but quite a few benchmarks saw **dramatic**
speedups.

Given these promising results, I ran Yeller's `test.check` suite for 8 
hours in
CI, and didn't see any failures, so I've deployed 1.7 alpha6 to production, 
and
haven't seen any issues as of yet.

Yeller's build also got ~24 seconds faster, which is super awesome (and it 
no
longer breaks under CLJ-1604 because that patch is in).

Much love to all the folk who put time and work into this release.

Benchmark names retracted because they're proprietary. Each line is a 
seperate benchmark, recorded on production level hardware, with the same 
jvm options/version used in production. Each benchmark is run in its own 
JVM (because otherwise JIT path dependence will kill you).

Benchmarks that were slower under 1.7 alpha6 vs 1.6.0 (with percentage 
changed amounts):
3.12%
2.62%
2.27%
2.19%
2.17%
2.06%
1.97%
1.43%
1.29%
0.89%
0.74%
0.71%
0.58%
0.45%
0.42%
0.34%
0.27%
0.25%
0.21%
0.2%
0.08%
0.03%

Benchmarks that were faster under 1.7 alpha6 vs 1.6.0 (with percentage 
changed amounts):
+0.0%
+0.0%
+0.01%
+0.02%
+0.03%
+0.03%
+0.03%
+0.04%
+0.04%
+0.09%
+0.12%
+0.16%
+0.31%
+0.33%
+0.52%
+0.53%
+0.85%
+1.74%
+1.84%
+1.99%
+2.14%
+2.17%
+2.42%
+2.96%
+3.0%
+5.18%
+5.36%
+9.86%
+11.93%
+12.41%
+14.36%
+16.95%
+24.71%
+53.5%
+53.62%
+72.07%

Thanks again! Super excited about this release.

On Wednesday, 1 April 2015 01:51:13 UTC+9, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>
> Regression fixes from previous alphas (and one from 1.6):
>
> 1) CLJ-1544 was rolled back and will be investigated for a future release.
> 2) CLJ-1637 fixed regression with vec on MapEntry 
> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) 
> method
> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for 
> literal nil arg
> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that 
> prevented update
>
> Some highlights new in alpha6:
>
> ## Transducer-related changes:
>
> The LazyTransformer introduced to create lazy transforming sequences has 
> been 
> replaced with a TransformingIterator. This was done to simplify the code
> around transformations and to make certain use cases around eduction more 
> efficient.
>
> ## Faster reduce, iterator, and sequence paths
>
> A lot of work has been done across a set of tickets to improve the ability 
> of
> collections to provide more efficient reduce or iterator performance, and 
> also to
> make common sequence generators create faster sequence and reduce paths. 
> You
> should see significant performance in many reduce-related paths (this 
> includes 
> reduce, transduce, into, and anything else built on reduce). 
>
> Many of those changes also have beneficial sequence performance, so you 
> may see
> some benefits even in code that does not use transducers.
>
> * Most uses of SeqIterator have now been replaced with iterators that 
> directly walk
> the underlying source for improved efficiency. This includes maps, sets, 
> records, etc.
> * repeat - now returns a faster sequence with a fast reduce path
> * cycle - now returns a faster sequence with a fast reduce path
> * iterate - now returns a faster sequence with a fast reduce path
> * range - (did not quite make it in, but coming soon...)
> * keys - iterates directly over the keys of a map, without seq or MapEntry 
> allocation
> * vals - iterates directly over the vals of a map, without seq or MapEntry 
> allocation
> * iterator-seq - now creates a chunked sequence when previously it was 
> unchunked
> * vec and set - were not changed in this release but were set up in a 
> previous alpha
>   to take advantage of the reduce and iterator changes above
>
> ## Reader conditionals
>
> Reader Conditionals is a new capability to support portable code that
> can run on multiple Clojure platforms with only small changes. In
> particular, this feature aims to support the increasingly common case
> of libraries targeting both Clojure and ClojureScript.
>
> Code intended to be common across multiple platforms should use a new
> supported file extension: ".cljc". When requested to load a namespace,
> the platform-specific file extension (.clj, .cljs) will be checked
> prior to .cljc.
>
> A new reader form can be used to specify "reader conditional" code in
> cljc files (and *only* cljc files). Each platfor

Re: Kwargs vs explicit parameter map for APIs?

[tcrayford]

Hi there,

I feel pretty strongly about this - I *much* prefer using APIs with 
explicit options maps. The community is pretty divided though. I wrote up 
the tradeoffs (which are well discussed here as well), as well as a list of 
libraries using each style: 
http://yellerapp.com/posts/2015-03-22-the-trouble-with-kwargs.html

To me, typing two extra characters ain't a big deal, but unrolling/rolling 
up maps and not being able to manipulate options easily is a bunch of pain, 
so I always choose explicit maps wherever possible.

On Tuesday, 17 March 2015 06:42:37 UTC+9, Leon Grapenthin wrote:
>
> Kwargs has clearly been designed for one purpose: A caller should have to 
> type less. 
>
> A simple rule to follow is to use kw args if the exposed thing is a 
> function not expected to be used in functional composition or a certain 
> DSLish kind of macro. 
>
> If your exposed function will be used in functional composition more often 
> than called in typed out code, with kwargs you are using the feature to its 
> opposite purpose: People have to type even more.
>
> For an example, if your thing is called "load-config-file!" and is used in 
> one or two places of code, use kwargs by all means. If your thing is called 
> path-for and resolves an URL for a map of parameters, kwargs is a very 
> unfortunate choice.
>
>
> On Saturday, April 26, 2014 at 12:41:22 AM UTC+2, Colin Fleming wrote:
>>
>> Hi all,
>>
>> I'm working on an API at the moment, and I'm balancing whether to use 
>> inline keyword args which I would destructure in the functions, or whether 
>> to just pass an explicit params map as the last parameter. Comparison of 
>> the two options in case I'm not explaining myself well:
>>
>> Kwargs:
>> (class/create-class :instancelist
>> :description "My description"
>> :implements  (keys class-methods)
>> :methods (calculate-my-methods))
>>
>> Map:
>> (class/create-class {:instancelist
>>  :description "My description"
>>  :implements  (keys class-methods)
>>  :methods (calculate-my-methods)})
>>
>> A lot of APIs I've seen have favoured kwargs, and it undeniably makes for 
>> some pretty code - Seesaw is the best example I've seen here, the API is a 
>> thing of beauty. However it seems to me to have some issues:
>>
>>1. If I want to delegate to another call from within an API function 
>>and use the same arguments, it's really awkward: (apply delegate 
>>(mapcat identity args)) or some similarly awful black juxt magic. Or 
>>of course writing out all the parameters again, but that's even worse.
>>2. It's more difficult to make parameters optional based on some 
>>runtime criteria since the params are baked into the function call. I 
>> guess 
>>this is usually dealt with by making the calls handle nil for a 
>> particular 
>>parameter. 
>>
>> Both of these are much easier when passing an explicit map. Any 
>> preferences here, from either writing or using APIs like this?
>>
>> Cheers, 
>>
>> Colin
>>
>

-- 
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: Workaround for CLJ-1604?

[tcrayford]

CLJ-1604 was just fixed (as far as I can see), by this 
commit: 
https://github.com/clojure/clojure/commit/59889fdeb7ef7f4f73e13fa6ecb627f62b7d2adb

On Friday, 20 February 2015 12:10:50 UTC+8, Adam Krieg wrote:
>
> I'm running into what appears to be the same issue described in CLJ-1604 
> , where a library that I'm 
> using (Korma) has a function that clashes with a new function in Clojure 
> core with 1.7, update.
>
> At the point of invocation, I get the compilation exception:
> Exception in thread "main" java.lang.RuntimeException: No such var: 
> korma.core/update, 
>
> Other than ripping out Korma or downgrading to 1.6, is there anything I 
> can do to avoid this issue?
>

-- 
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-Miniprofiler, a web application profiling tool

[tcrayford]

Sven,

As a followup, I have an example library that wraps liza (a key-value store 
library) in miniprofiler calls 
here: http://yellerapp.com/opensource/clojure-miniprofiler-liza.html

Similar could be accomplished for pretty much any other database library 
out there, though it depends on how good their abstractions are to whether 
that is feasible or not (I tried wrapping JDBC last night and gave up in 
horror - the API is super broad and complex).

Tom

On Sunday, 8 February 2015 19:57:26 UTC, Sven Richter wrote:
>
> That sounds really nice, exactly the way one wants it too I think :-)
>
>
> Am Sonntag, 8. Februar 2015 20:37:43 UTC+1 schrieb tcrayford:
>>
>> Hi Sven,
>>
>> Right, but you want to push miniprofiler further down the app than that. 
>> For example, with datomic I have a yeller.datomic.instrumented namespace 
>> that exports the same vars as datomic.api, but wraps them in miniprofiler 
>> tracing. From the point of view of my application code, the only thing that 
>> changes is that you require a different namespace, which is significantly 
>> easier than littering trace calls everywhere.
>>
>> Does that help?
>>
>> Tom
>>
>> On Sunday, 8 February 2015 08:57:12 UTC, Sven Richter wrote:
>>>
>>> Hi Tom,
>>>
>>> I am not arguing about the performance impact here, however, it's nice 
>>> to know there hardly is one. My only concern is that the code reader has to 
>>> mentally parse away the trace calls, which puts a small burden on him and 
>>> which might be less if it was in some kind of a macro, fn or metadata.
>>> However, I am still a clojure beginner and this was just one thing that 
>>> came to my mind when I saw it :-)
>>>
>>> Thanks,
>>> Sven
>>>
>>> Am Samstag, 7. Februar 2015 22:16:04 UTC+1 schrieb tcrayford:
>>>>
>>>> Hi Sven,
>>>>
>>>> So typically I'd put that stuff *much* lower in the database layer - 
>>>> ideally as a wrapper around whatever database driver you're using, but 
>>>> that 
>>>> kind of idea is roughly right.
>>>>
>>>> I am considering releasing a set of libraries for miniprofiler that let 
>>>> it wrap e.g. a jdbc driver, redis clients, and so on. This is a clear case 
>>>> where having an interface or a protocol at the low level of the database 
>>>> driver really helps. That way you'd just import the library, tell it to 
>>>> wrap the connection and use it yourself. Would that be useful? Which 
>>>> database are you using?
>>>>
>>>> When miniprofiler isn't on, it has pretty minimal performance impact 
>>>> (apart from the fact that you're adding more code to your methods which 
>>>> can 
>>>> have implications for the JIT) - it's just a binding load and a nil? 
>>>> check, 
>>>> which is pretty quick. I leave that code in production for my app, and 
>>>> have 
>>>> done since July.
>>>>
>>>> Pushing the profiling information as low in the stack as possible, and 
>>>> leaving it on in production is a powerful combination - typically you 
>>>> never 
>>>> think about profiling or tracing whilst writing your code, but it's always 
>>>> there, even in production where you need it.
>>>>
>>>> Hope that helps,
>>>>
>>>> Tom
>>>>
>>>> On Saturday, 7 February 2015 08:21:31 UTC, Sven Richter wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I just tried it and it looks really useful if one wants to track down 
>>>>> speed bumps in web apps.
>>>>>
>>>>> I wonder if I understand the usege correctly, right now I did 
>>>>> something like this:
>>>>>
>>>>> (defn admin-page [params]
>>>>>   (let [users (cjmp/trace "all users" (db/get-all-users (get params 
>>>>> :filter)))]
>>>>> (layout/render "user/admin.html" (merge {:users users :roles 
>>>>> available-roles}
>>>>>params
>>>>>
>>>>>
>>>>> I think this blows the code and one has to remove / add the trace 
>>>>> function everytime one wants to profile the code.
>>>>> Maybe it would be an improvement if one could add some metadata to 
>>>>> functions which then would be

Re: ANN: Clojure-Miniprofiler, a web application profiling tool

[tcrayford]

Hi Sven,

Right, but you want to push miniprofiler further down the app than that. 
For example, with datomic I have a yeller.datomic.instrumented namespace 
that exports the same vars as datomic.api, but wraps them in miniprofiler 
tracing. From the point of view of my application code, the only thing that 
changes is that you require a different namespace, which is significantly 
easier than littering trace calls everywhere.

Does that help?

Tom

On Sunday, 8 February 2015 08:57:12 UTC, Sven Richter wrote:
>
> Hi Tom,
>
> I am not arguing about the performance impact here, however, it's nice to 
> know there hardly is one. My only concern is that the code reader has to 
> mentally parse away the trace calls, which puts a small burden on him and 
> which might be less if it was in some kind of a macro, fn or metadata.
> However, I am still a clojure beginner and this was just one thing that 
> came to my mind when I saw it :-)
>
> Thanks,
> Sven
>
> Am Samstag, 7. Februar 2015 22:16:04 UTC+1 schrieb tcrayford:
>>
>> Hi Sven,
>>
>> So typically I'd put that stuff *much* lower in the database layer - 
>> ideally as a wrapper around whatever database driver you're using, but that 
>> kind of idea is roughly right.
>>
>> I am considering releasing a set of libraries for miniprofiler that let 
>> it wrap e.g. a jdbc driver, redis clients, and so on. This is a clear case 
>> where having an interface or a protocol at the low level of the database 
>> driver really helps. That way you'd just import the library, tell it to 
>> wrap the connection and use it yourself. Would that be useful? Which 
>> database are you using?
>>
>> When miniprofiler isn't on, it has pretty minimal performance impact 
>> (apart from the fact that you're adding more code to your methods which can 
>> have implications for the JIT) - it's just a binding load and a nil? check, 
>> which is pretty quick. I leave that code in production for my app, and have 
>> done since July.
>>
>> Pushing the profiling information as low in the stack as possible, and 
>> leaving it on in production is a powerful combination - typically you never 
>> think about profiling or tracing whilst writing your code, but it's always 
>> there, even in production where you need it.
>>
>> Hope that helps,
>>
>> Tom
>>
>> On Saturday, 7 February 2015 08:21:31 UTC, Sven Richter wrote:
>>>
>>> Hi,
>>>
>>> I just tried it and it looks really useful if one wants to track down 
>>> speed bumps in web apps.
>>>
>>> I wonder if I understand the usege correctly, right now I did something 
>>> like this:
>>>
>>> (defn admin-page [params]
>>>   (let [users (cjmp/trace "all users" (db/get-all-users (get params 
>>> :filter)))]
>>> (layout/render "user/admin.html" (merge {:users users :roles 
>>> available-roles}
>>>    params
>>>
>>>
>>> I think this blows the code and one has to remove / add the trace 
>>> function everytime one wants to profile the code.
>>> Maybe it would be an improvement if one could add some metadata to 
>>> functions which then would be profiled only in dev mode for example?
>>>
>>> Best Regards,
>>> Sven
>>>
>>>
>>> Am Mittwoch, 4. Februar 2015 14:21:28 UTC+1 schrieb tcrayford:
>>>>
>>>> Ack, minor date error there.
>>>>
>>>> I've been running Clojure Miniprofiler in production since July 2014, 
>>>> and it's proved both very stable, and extremely useful.
>>>>
>>>> On Wednesday, 4 February 2015 13:16:43 UTC, tcrayford wrote:
>>>>>
>>>>> Clojure Miniprofiler is a simple, but effective profiling tool for 
>>>>> your web application.
>>>>>
>>>>> It tells you what is slow about a web page both in production (for 
>>>>> admins only), and in development, as you load the page.
>>>>>
>>>>> It's a port of the original .Net library to Clojure, utilizing the 
>>>>> JavaScript and UI code that was originally written there.
>>>>>
>>>>> Read more about it here:
>>>>>
>>>>> http://yellerapp.com/opensource/clojure-miniprofiler.html
>>>>>
>>>>> And a sample performance debugging session is detailed here:
>>>>>
>>>>> http://yellerapp.com/posts/2015-02-04-miniprofiler.html
>>>>>
>>>>> I've been running Clojure Miniprofiler in production since July 2015, 
>>>>> and it's proved both very stable, and extremely useful.
>>>>>
>>>>

-- 
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-Miniprofiler, a web application profiling tool

[tcrayford]

Hi Sven,

So typically I'd put that stuff *much* lower in the database layer - 
ideally as a wrapper around whatever database driver you're using, but that 
kind of idea is roughly right.

I am considering releasing a set of libraries for miniprofiler that let it 
wrap e.g. a jdbc driver, redis clients, and so on. This is a clear case 
where having an interface or a protocol at the low level of the database 
driver really helps. That way you'd just import the library, tell it to 
wrap the connection and use it yourself. Would that be useful? Which 
database are you using?

When miniprofiler isn't on, it has pretty minimal performance impact (apart 
from the fact that you're adding more code to your methods which can have 
implications for the JIT) - it's just a binding load and a nil? check, 
which is pretty quick. I leave that code in production for my app, and have 
done since July.

Pushing the profiling information as low in the stack as possible, and 
leaving it on in production is a powerful combination - typically you never 
think about profiling or tracing whilst writing your code, but it's always 
there, even in production where you need it.

Hope that helps,

Tom

On Saturday, 7 February 2015 08:21:31 UTC, Sven Richter wrote:
>
> Hi,
>
> I just tried it and it looks really useful if one wants to track down 
> speed bumps in web apps.
>
> I wonder if I understand the usege correctly, right now I did something 
> like this:
>
> (defn admin-page [params]
>   (let [users (cjmp/trace "all users" (db/get-all-users (get params 
> :filter)))]
> (layout/render "user/admin.html" (merge {:users users :roles 
> available-roles}
>params
>
>
> I think this blows the code and one has to remove / add the trace function 
> everytime one wants to profile the code.
> Maybe it would be an improvement if one could add some metadata to 
> functions which then would be profiled only in dev mode for example?
>
> Best Regards,
> Sven
>
>
> Am Mittwoch, 4. Februar 2015 14:21:28 UTC+1 schrieb tcrayford:
>>
>> Ack, minor date error there.
>>
>> I've been running Clojure Miniprofiler in production since July 2014, and 
>> it's proved both very stable, and extremely useful.
>>
>> On Wednesday, 4 February 2015 13:16:43 UTC, tcrayford wrote:
>>>
>>> Clojure Miniprofiler is a simple, but effective profiling tool for your 
>>> web application.
>>>
>>> It tells you what is slow about a web page both in production (for 
>>> admins only), and in development, as you load the page.
>>>
>>> It's a port of the original .Net library to Clojure, utilizing the 
>>> JavaScript and UI code that was originally written there.
>>>
>>> Read more about it here:
>>>
>>> http://yellerapp.com/opensource/clojure-miniprofiler.html
>>>
>>> And a sample performance debugging session is detailed here:
>>>
>>> http://yellerapp.com/posts/2015-02-04-miniprofiler.html
>>>
>>> I've been running Clojure Miniprofiler in production since July 2015, 
>>> and it's proved both very stable, and extremely useful.
>>>
>>

-- 
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-Miniprofiler, a web application profiling tool

[tcrayford]

Ack, minor date error there.

I've been running Clojure Miniprofiler in production since July 2014, and 
it's proved both very stable, and extremely useful.

On Wednesday, 4 February 2015 13:16:43 UTC, tcrayford wrote:
>
> Clojure Miniprofiler is a simple, but effective profiling tool for your 
> web application.
>
> It tells you what is slow about a web page both in production (for admins 
> only), and in development, as you load the page.
>
> It's a port of the original .Net library to Clojure, utilizing the 
> JavaScript and UI code that was originally written there.
>
> Read more about it here:
>
> http://yellerapp.com/opensource/clojure-miniprofiler.html
>
> And a sample performance debugging session is detailed here:
>
> http://yellerapp.com/posts/2015-02-04-miniprofiler.html
>
> I've been running Clojure Miniprofiler in production since July 2015, and 
> it's proved both very stable, and extremely useful.
>

-- 
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: Clojure-Miniprofiler, a web application profiling tool

[tcrayford]

Clojure Miniprofiler is a simple, but effective profiling tool for your web 
application.

It tells you what is slow about a web page both in production (for admins 
only), and in development, as you load the page.

It's a port of the original .Net library to Clojure, utilizing the 
JavaScript and UI code that was originally written there.

Read more about it here:

http://yellerapp.com/opensource/clojure-miniprofiler.html

And a sample performance debugging session is detailed here:

http://yellerapp.com/posts/2015-02-04-miniprofiler.html

I've been running Clojure Miniprofiler in production since July 2015, and 
it's proved both very stable, and extremely useful.

-- 
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-alpha5 now available

[tcrayford]

I said this already on twitter, but I see heavy (5-10x slower) perf 
regressions on my benchmark suite from 1.7-alpha5 vs 1.6. I am trying the 
other alphas now - I have a comprehensive benchmark suite that takes 4 
hours or so to run, and it's a bit backed up right now (I only have one box 
to run it on). I'm also going to point YourKit at 1.7-alpha5 soon on the 
worst regressing benchmarks (not all of them have such heavy regressions, 
and a few benchmarks are dramatically faster) and see what happens - will 
report back here once I have something more to say.

On Saturday, 10 January 2015 15:37:04 UTC, Alex Miller wrote:
>
> Clojure 1.7.0-alpha5 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha5/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha5"]
>
> A few of the highlights in alpha5:
>
> 1) New transducer arities for map-indexed, distinct, and interpose.
> The transducer versions are generally faster than the sequence versions.
> See CLJ-1601 for more details.
>
> 2) The set and vec functions should now be faster in many cases. Some of 
> the
> vec improvements will not kick in until CLJ-1499 is committed in the 
> future.
> See CLJ-1546 and CLJ-1618 for more details.
>
> 3) Two particularly troublesome AOT classloading bugs have been addressed 
> - 
> CLJ-979 and CLJ-1544. Many other tickets were found to be duplicates of 
> one of
> these as well. Big thanks to Nicola Mometto for doing the hard work on 
> debugging and providing fixes for these.
>
> For all changes new in alpha5, see the issues marked "(alpha5)" in the
> full changes below.
>
> 
> Clojure 1.7.0-alpha5 has the changes below from 1.6.0:
>
> ## 1 New and Improved Features
>
> ### 1.1 Transducers
>
> Transducers is a new way to decouple algorithmic transformations from their
> application in different contexts. Transducers are functions that transform
> reducing functions to build up a "recipe" for transformation.
>
> Also see: http://clojure.org/transducers
>
> Many existing sequence functions now have a new arity (one fewer argument
> than before). This arity will return a transducer that represents the same
> logic but is independent of lazy sequence processing. Functions included 
> are:
>
> * conj (conjs to [])
> * map
> * mapcat
> * filter
> * remove
> * take
> * take-while
> * drop
> * drop-while
> * cycle
> * take-nth
> * replace
> * partition-by
> * partition-all
> * keep
> * keep-indexed
> * map-indexed (alpha5)
> * distinct (alpha5)
> * interpose (alpha5)
>
> Additionally some new transducer functions have been added:
>
> * cat - concatenates the contents of each input
> * de-dupe - removes consecutive duplicated values
> * random-sample - returns items from coll with random probability
>
> And this function can be used to make completing transforms:
>
> * completing
>
> There are also several new or modified functions that can be used to apply
> transducers in different ways:
>
> * sequence - takes a transformation and a coll and produces a lazy seq
> * transduce - reduce with a transformation (eager)
> * eduction - returns a reducible/seqable/iterable seq of applications of 
> the transducer to items in coll. Applications are re-performed with every 
> reduce/seq/iterator.
> * run! - run the transformation for side effects on the collection
>
> There have been a number of internal changes to support transducers:
>
> * volatiles - there are a new set of functions (volatile!, vswap!, 
> vreset!, volatile?) to create and use volatile "boxes" to hold state in 
> stateful transducers. Volatiles are faster than atoms but give up atomicity 
> guarantees so should only be used with thread isolation.
> * array iterators - added support for iterators over arrays
>
> Some related issues addressed during development:
> * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511)
> * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497)
> * [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549)
> * [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537)
> * [CLJ-1554](http://dev.clojure.org/jira/browse/CLJ-1554)
> * [CLJ-1601](http://dev.clojure.org/jira/browse/CLJ-1601) (alpha5)
> * [CLJ-1606](http://dev.clojure.org/jira/browse/CLJ-1606) (alpha5)
> * [CLJ-1621](http://dev.clojure.org/jira/browse/CLJ-1621) (alpha5)
> * [CLJ-1600](http://dev.clojure.org/jira/browse/CLJ-1600) (alpha5)
>
> ### 1.2 Keyword and Symbol Construction
>
> In response to issues raised in [CLJ-1439](
> http://dev.clojure.org/jira/browse/CLJ-1439),
> several changes have been made in symbol and keyword construction:
>
> 1) The main bottleneck in construction of symbols (which also occurs 
> inside keywords) was
> interning of the name and namespace strings. This interning has been 
> removed, resulting
> in a performance increase.
>
> 2) Keywords are cached and keyword construction includes a cache check. A 
> change was made
> to only clear th

Re: [ANN] stateful-check 0.1.0 - test stateful systems with test.check

[tcrayford]

Carlo,

Nice! I wrote a sketch of this idea the day after I watched the 
talk: https://github.com/tcrayford/laundromat, but never pursued it much 
further (though I do use it in my test suite).

Awesome to see some real work put into this idea.

On Friday, 28 November 2014 00:44:16 UTC, Carlo wrote:
>
> I've been working on a library for a little bit which I'm calling 
> stateful-check (at least for now). It's mainly my attempt to work 
> towards the sort of stateful testing that I first saw in John Hughes' 
> talk "Testing the Hard Stuff and Staying Sane"[1]. 
>
>   https://github.com/czan/stateful-check 
>   https://clojars.org/org.clojars.czan/stateful-check 
>
> Thus far I've only got it to perform single threaded operations, but I'm 
> hoping to enhance it in future to do the sort of concurrent tests that 
> are shown in the talk (although I'm not exactly sure how I'm going to do 
> that yet). 
>
> Anyway, I'm releasing this now in the hopes that somebody finds it 
> useful! 
>
> Carlo 
>
>
> [1]: https://www.youtube.com/watch?v=zi0rHwfiX1Q 
>

-- 
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: Question about test.check, and knossos

[tcrayford]

Hi Andy, All,

I wrote a tool like this: https://github.com/tcrayford/laundromat

it's super hacky, and the api is definitely in beta. I asked some folk 
about reviewing this api, got little feedback, and figured it wasn't that 
much of a wanted thing after all. I still use it internally, but it's 
pretty bad at what it does right now. I'd love to hear if more folk are 
interested or if anybody's interested in contributing.

Tom

On Thursday, 23 October 2014 01:04:24 UTC-5, Andy Chambers wrote:
>
> Hi All,
>
> Lately I've been exploring the world introduced to me by watching the John 
> Hughes' quickcheck video from
> clojure west. Awesome stuff!
>
> Eventually I found the "testing for fun and profit"[1] paper which left me 
> wanting to test my apps using
> a model based system like the paper describes. It looks like 
> test-check-knossos[2] takes a stab at applying
> knossos[3] to this problem.
>
> However the examples in that repo don't capture the the aspect of using 
> state to generate test commands to be
> executed against the system. It's just a random stream of :take/:reset 
> operations whereas the registry example
> in the paper seems to require that the function which generates the 
> sequence of test commands has access to
> the state of the system under test at the start of each command.
>
> So is there a missing clojure library here? Is anybody working on 
> something that allows this style of model
> testing? If not, would it make sense for someone writing one to leverage 
> knossos in any way?
>
> Cheers,
> Andy
>
> [1]: http://people.inf.elte.hu/center/fulltext.pdf
> [2]: https://github.com/philandstuff/test-check-knossos
> [3]: https://github.com/aphyr/knossos
>

-- 
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: [PSA] Clojars scp disabled until further notice

[tcrayford]

Phil,

I've used scp uploads in the past. They're much easier when e.g. you wanna 
upload a java library you've forked. Without scp uploads (or an easy 
copy/paste curl alternative), you have to go through getting the project to 
build with lein by itself. It's not *too* difficult to get a maven based 
project uploaded to clojars 
(https://github.com/ato/clojars-web/wiki/Pushing has an easy to follow 
section), but getting ant or other projects up there is painful.

Other than that, I've happily converted over to `lein deploy` for my 
lein-based projects.

Tom

On Wednesday, 24 September 2014 17:57:49 UTC-5, Phil Hagelberg wrote:
>
> Greetings, Clojure hackers. 
>
> Due to the recent vulnerability in Bash[1], the scp-based deploy 
> services on clojars.org has been disabled for the time being. 
>
> If you have been using this (as opposed to the HTTPS deploy used by 
> `lein deploy clojars` and `maven deploy`), we'd be interested in hearing 
> From you. In particular we would like to know reasons why you haven't 
> upgraded, assuming it's not just "I started on scp and it worked well, 
> so I never saw the need to change anything." 
>
> If you haven't tried HTTPS-based deploys, now would be a great time to 
> do so and see if they work for you. If not, let us know why, either here 
> or on the Leiningen issue tracker[2]. The HTTPS-based deploys are 
> definitely a superior implementation that we encourage. We would like to 
> bring scp deploys back online in the near future, but as you know 
> Clojars is a volunteer-run service without many resources, and we have 
> no immediate timeline for this. 
>
> -Phil 
>
> [1] - http://seclists.org/oss-sec/2014/q3/650 
> [2] - https://github.com/technomancy/leiningen/issues/new 
>

-- 
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: Best tools for profiling Clojure programs?

[tcrayford]

I like YourKit. It's commercial, but really quite good (free for open 
source if you promote them in your readme). I wrote a bit about the perf 
wins I got using yourkit on my app 
here: 
http://yellerapp.com/posts/2014-05-21-tuning-clojure-an-experience-report.html

On Friday, 20 June 2014 14:05:05 UTC+1, ru wrote:
>
> Hi all,
>
> What performance profiling instrument somebody can recommend for Clojure 
> programs and corresponding documents, articles or tutorials. Thanks in 
> advance.
>
> Sincerely,
>   Ru
>

-- 
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] immutable-int-map

[tcrayford]

Bonus: rename the library "immutable-long-map", then you can have a section 
in the readme titled "why the long map?"

On Monday, 21 April 2014 13:12:05 UTC+1, Alex Miller wrote:
>
> This is great stuff. Why not longs? Are you going for space savings? 

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

Re: clojure-mode bug in Emacs

[tcrayford]

I've seen this a bunch. Emacs has some hidden setting that vastly
increases sytax-highlighting performance, but messes up if you have a
line starting with an open paren inside a string in a lisp mode. (I
can't for the life of me remember what it is off the top of my head).

On Sep 30, 4:26 pm, ".Bill Smith"  wrote:
> Has anyone else noticed this?  In Emacs clojure-mode, indentation and
> syntax coloring can get out of whack after a string that contains an
> open parenthesis.
>
> In the example below, (+ 1 2) is indented incorrectly.
>
>  (defn f [x]
>    "Blah blah blah.
>  (parenthetical expression"
>  (+ 1 2))

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

Re: First Clojure Conj October 22-23

[tcrayford]

Are you guys interested in me presenting/speaking about my clojure
refactoring tool at this conference?

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