Re: [core.spec] Stricter map validations?

[Robin Heggelund Hansen]

Isn't this precisely why you should use namespaced keywords?

tirsdag 14. november 2017 19.43.55 UTC+1 skrev Sean Corfield følgende:
>
> Eric does raise an interesting question tho’:
>
>  
>
> If you have an API that cares about ‘a’, ‘b’, and ‘c’ and you later 
> specify that ‘d’ is optional and should be an ‘int?’, does that qualify as 
> breakage or growth? If clients were sending ‘d’ as a string before but you 
> ignored it, it will break those clients. Clients that were not sending ‘d’ 
> will not be affected by the change. The old spec – allowing ‘d’ to be 
> ‘any?’ essentially – won’t fail on any data that omits ‘d’ or passes it as 
> ‘int?’ so it passes your compatibility test.
>
>  
>
> (we actually ran into this at work because a client app was passing a 
> field we didn’t care about and we later decided that was an optional field 
> but couldn’t be an empty string and it broke that client)
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Seth Verrinder  >
> *Sent:* Tuesday, November 14, 2017 8:45:30 AM
> *To:* Clojure
> *Subject:* Re: [core.spec] Stricter map validations? 
>  
> I took part of the goal to be that specs themselves would remain 
> compatible, so an old set of specs wouldn't start failing on data that 
> conforms to a new but compatible set of specs. That sort of compatibility 
> isn't possible when you go from disallowing something to allowing it.
>
> On Tuesday, November 14, 2017 at 10:15:23 AM UTC-6, Eric Normand wrote: 
>>
>> Hey everybody! 
>>
>> I'm chiming in after seeing this linked to in The Repl (
>> https://therepl.net/).
>>
>> On Alex's suggestion, I rewatched Spec-ulation last night. The parts 
>> about negation and evolution are towards the end. I was struck (once again) 
>> by how clearly he picked apart changes. Relaxing a requirement is growth. 
>> And adding requirements is breakage. But it left me with a question:
>>
>> Isn't disallowing a key and then allowing it (as optional) growth 
>> (instead of breakage)? All of the old clients are still fine, and new 
>> clients can use the key if they choose. You're relaxing the requirements. 
>> Taking the opposite approach, I require some keys plus allow anything else. 
>> Some clients will inevitably send me something with extra keys, which is 
>> okay, they pass my specs. Later, I add in an optional key with a defined 
>> spec. So I'm now restricting what used to be completely open. Isn't that 
>> breakage? I feel like I'm seeing it exactly opposite as Rich Hickey. He 
>> says if you disallow things, it's forever, because if you need to allow it 
>> later, that's breakage. But there's not enough explanation for me to 
>> understand. It seems like relaxing requirements. I feel like I'm missing 
>> something. In short: why is it forever?
>>
>> He does mention is that logic engines don't have negation. Does this hint 
>> that we will want to be using logic engines to reason over our specs?
>>
>> Thanks
>> Eric
>>
> -- 
> 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 
> 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 
> 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 .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Robin Heggelund Hansen]

Been running with this in production for two days now. Working fine.

onsdag 16. desember 2015 22.45.21 UTC+1 skrev Alex Miller følgende:
>
> Clojure 1.8.0-RC4 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. 
>
> Of particular note, CLJ-1861 removes the interning of unused vars. This 
> change reduces compiled class size (clojure jar is 8% smaller), which 
> reduces classloading time, and thus improves startup time (in some tests 
> ~10-15% faster). Code that uses direct linking (like Clojure core) sees the 
> greatest benefits as most direct-linked vars are unused, but you may also 
> see some benefits with code that is not direct linked as well.  Feedback 
> on startup time or other impacts in actual projects (with or without direct 
> linking) is appreciated.
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC4
>- Leiningen: [org.clojure/clojure "1.8.0-RC4"]
>
> Below are the changes since 1.8.0-RC3. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1861  - Remove 
>unused var interning
>- CLJ-1161  - Clojure 
>-sources.jar includes a bad properties file in release builds
>- Commit ae7ac 
>
> 
>  - 
>Unrolls the remainder of the Tuple changes from earlier in the release 
>cycle, most significantly rolling back the addition of IMapEntry to 
>APersistentVector
>
>

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

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

[Robin Heggelund Hansen]

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

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

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

[ANN] hugsql-adapter-postgres-async 0.3.0

[Robin Heggelund Hansen]

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

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

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

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

Re: [ANN] 0.3.0 HugSQL release

[Robin Heggelund Hansen]

Fantastic release Curtis. This is an awesome work!

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

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

[Robin Heggelund Hansen]

I got an exception when compiling with this RC (exception below). Seems it 
have trouble compiling aleph, so I've added an issue there. I assume you 
will be contacted if the bug is found to be an error in Clojure itself, and 
not Aleph.

#error {
 :cause IllegalName: compile__stub.aleph.http.core.aleph.http.core/HeaderMap
 :via
 [{:type clojure.lang.Compiler$CompilerException
   :message java.lang.NoClassDefFoundError: IllegalName: 
compile__stub.aleph.http.core.aleph.http.core/HeaderMap, 
compiling:(aleph/http/core.clj:81:1)
   :at [clojure.lang.Compiler analyzeSeq Compiler.java 6861]}
  {:type java.lang.NoClassDefFoundError
   :message IllegalName: 
compile__stub.aleph.http.core.aleph.http.core/HeaderMap
   :at [java.lang.ClassLoader preDefineClass ClassLoader.java 654]}]
 :trace
 [[java.lang.ClassLoader preDefineClass ClassLoader.java 654]
  [java.lang.ClassLoader defineClass ClassLoader.java 758]
  [java.lang.ClassLoader defineClass ClassLoader.java 642]
  [clojure.lang.DynamicClassLoader defineClass DynamicClassLoader.java 46]
  [clojure.lang.Compiler$NewInstanceExpr compileStub Compiler.java 7880]
  [clojure.lang.Compiler$NewInstanceExpr build Compiler.java 7745]
  [clojure.lang.Compiler$NewInstanceExpr$DeftypeParser parse Compiler.java 
7655]
  [clojure.lang.Compiler analyzeSeq Compiler.java 6854]
  [clojure.lang.Compiler analyze Compiler.java 6655]
  [clojure.lang.Compiler analyze Compiler.java 6611]
  [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5987]
  [clojure.lang.Compiler$LetExpr$Parser parse Compiler.java 6305]
  [clojure.lang.Compiler analyzeSeq Compiler.java 6854]
  [clojure.lang.Compiler analyze Compiler.java 6655]
  [clojure.lang.Compiler analyze Compiler.java 6611]
  [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5987]
  [clojure.lang.Compiler$FnMethod parse Compiler.java 5368]
  [clojure.lang.Compiler$FnExpr parse Compiler.java 3971]
  [clojure.lang.Compiler analyzeSeq Compiler.java 6852]
  [clojure.lang.Compiler analyze Compiler.java 6655]
  [clojure.lang.Compiler eval Compiler.java 6910]
  [clojure.lang.Compiler eval Compiler.java 6902]
  [clojure.lang.Compiler load Compiler.java 7360]
  [clojure.lang.RT loadResourceScript RT.java 372]
  [clojure.lang.RT loadResourceScript RT.java 363]
  [clojure.lang.RT load RT.java 453]
  [clojure.lang.RT load RT.java 419]
  [clojure.core$load$fn__5673 invoke core.clj 5895]
  [clojure.core$load invokeStatic core.clj 5894]
  [clojure.core$load_one invokeStatic core.clj 5694]
  [clojure.core$load_one invoke core.clj -1]
  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]
  [clojure.core$load_lib invokeStatic core.clj 5738]
  [clojure.core$load_lib doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 142]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$load_libs invokeStatic core.clj 5776]
  [clojure.core$load_libs doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 137]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$require invokeStatic core.clj 5798]
  [clojure.core$require doInvoke core.clj -1]
  [clojure.lang.RestFn invoke RestFn.java 551]
  [aleph.http.server$eval18258$loading__5565__auto18259 invoke 
server.clj 1]
  [aleph.http.server$eval18258 invokeStatic server.clj 1]
  [aleph.http.server$eval18258 invoke server.clj -1]
  [clojure.lang.Compiler eval Compiler.java 6913]
  [clojure.lang.Compiler eval Compiler.java 6902]
  [clojure.lang.Compiler load Compiler.java 7360]
  [clojure.lang.RT loadResourceScript RT.java 372]
  [clojure.lang.RT loadResourceScript RT.java 363]
  [clojure.lang.RT load RT.java 453]
  [clojure.lang.RT load RT.java 419]
  [clojure.core$load$fn__5673 invoke core.clj 5895]
  [clojure.core$load invokeStatic core.clj 5894]
  [clojure.core$load_one invokeStatic core.clj 5694]
  [clojure.core$load_one invoke core.clj -1]
  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]
  [clojure.core$load_lib invokeStatic core.clj 5738]
  [clojure.core$load_lib doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 142]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$load_libs invokeStatic core.clj 5780]
  [clojure.core$load_libs doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 137]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$require invokeStatic core.clj 5798]
  [clojure.core$require doInvoke core.clj -1]
  [clojure.lang.RestFn invoke RestFn.java 457]
  [aleph.http$eval16931$loading__5565__auto16932 invoke http.clj 1]
  [aleph.http$eval16931 invokeStatic http.clj 1]
  [aleph.http$eval16931 invoke http.clj -1]
  [clojure.lang.Compiler eval Compiler.java 6913]
  [clojure.lang.Compiler eval Compiler.java 6902]
  [clojure.lang.Compiler load Compiler.java 7360]
  [clojure.lang.RT loadResourceScript RT.java 372]
  [clojure.lang.RT loadResourceScript RT.java 363]
  [clojure.lang.RT load RT.java 453]
  [clojure.lang.RT load RT.java 419]
  [clojure.core$load$fn__5673 invoke core.clj 

Re: [ANN] a HugSQL adapter for postgres.async

[Robin Heggelund Hansen]

The author of HugSQL is working on documentation now, and I believe he will 
include a decent comparison to YeSQL in the process.

-- 
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] a HugSQL adapter for postgres.async

[Robin Heggelund Hansen]

The basic principle is the same, but the api is a little different, 
especially after YeSQL 0.5.

The biggest things for me:
- HugSQL allows you to replace jdbc-backend (which is what allows my async 
package). YeSQL is hardcoded to clojure.java.jdbc
- HugSQL allows you to specify if one or many values are returned from a 
query, in YeSQL, a list is always returned.
- YeSQL differentiates commands based on name convention (transactions has 
names that end with !), in HugSQL you configure it in the sql file.
- YeSQL takes options (with db) as the last argument to a 
query/transaction. HugSQL takes the db(!) as the first argument.
- HugSQL is easier to use with stuart sierra's component library due to 
previous statement.
- HugSQL is easier to use with jdbc-transactions due to the same reason 
(don't have to wrap/unwrap db from YeSQL options).
- HugSQL is more flexible, as it allows different quoting and insertion 
strategies, allowing you to create more flexible SQL functions.

onsdag 4. november 2015 18.42.30 UTC+1 skrev chepprey følgende:
>
> Is there anything that compares/contrasts HugSQL and YesQL?
>
> On Sunday, October 25, 2015 at 9:36:40 PM UTC-4, Robin Heggelund Hansen 
> wrote:
>>
>> You can now have async communication with your postgres database and 
>> HugSQL over plain core.async channels.
>>
>> https://github.com/Skinney/hugsql-async
>>
>

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

Re: [ANN] core.async-0.2.371

[Robin Heggelund Hansen]

Great work Miller & Team :D

onsdag 28. oktober 2015 22.06.41 UTC+1 skrev Alex Miller følgende:
>
> I am happy to announce a long-overdue core.async release.
>
> Dependency info:  [org.clojure/core.async "0.2.371"]
>
> There are a few new features in this release:
>
> 1) *promise-chan* is a function that returns a new kind of channel (with 
> a custom buffer) with promise semantics. Specifically, channels make a 
> one-time transition to having a deliverable value. *promise-chan* takes 
> an optional transducer, and an optional exception-handler (like chan). A 
> promise channel can take exactly one value that consumers will receive. 
> Once full, puts complete but val is dropped (no transfer).
> Consumers will block until either a value is placed in the channel or the 
> channel is closed (and nil will be delivered). 
>
> 2) *offer!* and *poll!* are two new non-blocking functions available on 
> channels.
>
> offer! puts a val into a channel if it can do so immediately and will 
> never block. Returns true if offer succeeds.
> poll! takes a val from a channel if it can do so immediately and will 
> never block. Return a value if successful, nil otherwise.
>
> All changes:
>
>- ASYNC-103  - NEW 
>promise-chan
>- ASYNC-104  - NEW 
>non-blocking offer!, poll!
>- ASYNC-124  - dispatch 
>multiple pending takers resulting from expanding transducer
>- ASYNC-101  - 
>async/reduce now respects reduced
>- ASYNC-112  - replace 
>"transformer" with "transducer" in deprecation messages
>- ASYNC-6  - alts! docs 
>updated to explicitly state ports is a vector
>- Support (try (catch :default)) in CLJS exception handling
>- Use cljs.test
>- Updated tools.analyzer.jvm version (and other upstream deps) - fixes 
>various analyzer errors
>
>
>

-- 
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: Examples of core.async usage in production?

[Robin Heggelund Hansen]

I have used core.async in production on the backend. Works great, but it 
does involve a bit more work, as you need to make sure that all io 
(database) and middleware supports core.async. But it works well. There are 
postgres.async for async db, and fink-nottle for sending sms/push 
notifications/email etc. using core.async.

mandag 26. oktober 2015 17.26.19 UTC+1 skrev juan.facorro følgende:
>
> Hi all,
>
> From what I've seen/heard/understand core.async has been mostly used in 
> production on the *client side* or UI programming, since it frees us from 
> the dreaded callback hell. There are some instances where *core.async* is 
> used on the *server side* to provide asynchronous communication between 
> client and server [1][2]; and I wonder how many are using those 
> libraries/features and how. 
>
> I'm sure there are a lot more libraries built on top of *core.async* to 
> be used on the server, but my question/survey is related to *how many of 
> those are used in production today*. I have also found some comments 
> about using Pulsar  as an 
> alternative for asynchronous message passing scenarios [3][4]. How many of 
> you have gone that way instead?
>
> Looking forward to your comments & replies.
>
> Cheers!
> Juan
>
> [1] https://github.com/ptaoussanis/sente
> [2] https://github.com/bguthrie/async-sockets
> [3] https://groups.google.com/d/msg/clojure/m6bqGd8vQZQ/hR5rxE4oHSMJ
> [4] 
> http://stackoverflow.com/questions/32299299/is-it-safe-to-use-clojure-core-async-in-production-even-though-its-alpha
>

-- 
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] a HugSQL adapter for postgres.async

[Robin Heggelund Hansen]

You can now have async communication with your postgres database and HugSQL 
over plain core.async channels.

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

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

Re: [ANN] HugSQL 0.1.1 - Embrace SQL

[Robin Heggelund Hansen]

This looks great, seems to solve all the problems I have with YeSQL. Great 
work :D

-- 
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: recombining results from clojure.data/diff

[Robin Heggelund Hansen]

You can also take a look at patchin or differ (differ is my project) for 
this usecase.

torsdag 15. oktober 2015 23.26.01 UTC+2 skrev JvJ følgende:
>
> I just discovered clojure.data/diff, and it's great.  However, I'm not 
> sure how to recombine the results to get back the original.
>
> For instance, if (diff a b) = c, then how can I combine b and c to get 
> back to a?
>
>

-- 
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] Yesql 0.5.1 Released.

[Robin Heggelund Hansen]

If you pass the db connection to defqueries, you are essentially storing 
global state. The point of component is to not have global state. So yeah, 
you shouldn't pass the db-connection to defqueries, but pass the connection 
to every db-call.

fredag 9. oktober 2015 03.01.29 UTC+2 skrev Charles Harvey III følgende:
>
> That's what I have now and I was wondering if it could/should change now 
> that I can pass the connection into defqueries. It seems like it could 
> change. But, component is just a place to keep state/global values. The 
> connection being one of them. defqueries must be storing it somewhere (an 
> atom?) but if component already has it than I do not need to give it to 
> yesql to hold as well.
>
> Does this all sound right?
>
> Thanks.
>
>
>
>
> On Thursday, October 8, 2015 at 3:48:33 PM UTC-4, Robin Heggelund Hansen 
> wrote:
>>
>> For a component-based workflow, you wouldn't send in the db-spec with the 
>> defqueries. You would do it when calling a query.
>>
>> (defqueries "somepath")
>>
>> (defn code [component]
>>   (some-query {:name "Robin", :age 6} {:db (:db-spec component)}))
>>
>> torsdag 8. oktober 2015 15.34.09 UTC+2 skrev Charles Harvey III følgende:
>>>
>>> I have a question that I hope you can answer about using Yesql with 
>>> Component.
>>>
>>> Currently I pass the db-spec into my endpoint and then pass it into each 
>>> call to a query. Now that I can call defqueries with the db-spec, how do I 
>>> send that in from component? Sorry for asking, I am new to both libraries 
>>> and am still learning.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Wednesday, October 7, 2015 at 5:55:11 PM UTC-4, Kris Jenkins wrote:
>>>>
>>>> Yesql - the Clojure library for using SQL - has just released v0.5.1.
>>>>
>>>> The API is much improved - especially if you're using queries with many 
>>>> arguments - so see the migration guide if you're upgrading:
>>>>
>>>> My thanks to everyone who has contributed to this release, and for all 
>>>> the users who've been patiently waiting for v0.5 to go official. :-)
>>>>
>>>> Kris
>>>>
>>>

-- 
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] Yesql 0.5.1 Released.

[Robin Heggelund Hansen]

For a component-based workflow, you wouldn't send in the db-spec with the 
defqueries. You would do it when calling a query.

(defqueries "somepath")

(defn code [component]
  (some-query {:name "Robin", :age 6} {:db (:db-spec component)}))

torsdag 8. oktober 2015 15.34.09 UTC+2 skrev Charles Harvey III følgende:
>
> I have a question that I hope you can answer about using Yesql with 
> Component.
>
> Currently I pass the db-spec into my endpoint and then pass it into each 
> call to a query. Now that I can call defqueries with the db-spec, how do I 
> send that in from component? Sorry for asking, I am new to both libraries 
> and am still learning.
>
> Thanks.
>
>
>
> On Wednesday, October 7, 2015 at 5:55:11 PM UTC-4, Kris Jenkins wrote:
>>
>> Yesql - the Clojure library for using SQL - has just released v0.5.1.
>>
>> The API is much improved - especially if you're using queries with many 
>> arguments - so see the migration guide if you're upgrading:
>>
>> My thanks to everyone who has contributed to this release, and for all 
>> the users who've been patiently waiting for v0.5 to go official. :-)
>>
>> Kris
>>
>

-- 
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: Smallest Heroku slug size?

[Robin Heggelund Hansen]

I'm just trying to optimize, so it isn't vital to my app.
How do I use the builtin openjdk 7? My app makes no use of Java 8 anyway.

onsdag 7. oktober 2015 03.56.26 UTC+2 skrev Joe Kutner følgende:
>
> The slug will also include the JDK, which is ~50mb compressed. It is 
> possible to exclude the JDK and use the cedar-14 stack's JVM, which is 
> currently openjdk7 because that's what Canonical supports. But then you 
> don't get the all the goodness of Java 8, which is probably better for your 
> app than a little boost to started up time.
>
> Are you having problems with boot timeouts, or just trying to optimize? 
>
> On Tuesday, October 6, 2015 at 6:54:08 AM UTC-5, Robin Heggelund Hansen 
> wrote:
>>
>> A low heroku slug size is good for improving startup of heroku 
>> applications. Because of that I've spent some time lately trying to get as 
>> small a slug size as possible. I eventually found a plugin called 
>> lein-heroku, which allows you to just upload a single uberjar file. When 
>> the build system is set up correctly, this should give you the tiniest slug 
>> size possible. Yet, even though I have 20ish MB less in the repository 
>> (checked with heroku run bash && du -h), the difference in slug size is a 
>> mere 3MB.
>>
>> I'm consistently getting around 70-80MB in slug size. Is this as low as I 
>> can go? Have anyone else done better?
>>
>

-- 
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: Smallest Heroku slug size?

[Robin Heggelund Hansen]

Thanks. I've added an issue now :)

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

Smallest Heroku slug size?

[Robin Heggelund Hansen]

A low heroku slug size is good for improving startup of heroku 
applications. Because of that I've spent some time lately trying to get as 
small a slug size as possible. I eventually found a plugin called 
lein-heroku, which allows you to just upload a single uberjar file. When 
the build system is set up correctly, this should give you the tiniest slug 
size possible. Yet, even though I have 20ish MB less in the repository 
(checked with heroku run bash && du -h), the difference in slug size is a 
mere 3MB.

I'm consistently getting around 70-80MB in slug size. Is this as low as I 
can go? Have anyone else done better?

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

[Robin Heggelund Hansen]

Basically, I use stuart sierra's tools.namespace and component libraries to 
write an application that can be easily reloaded. So I write my code in 
regular files, then i tell the repl to reload my application with the 
latest changes from disk. I can also test the application while it's 
running, because I have access to every function. Hot-replacement is a 
matter of calling 'reset. Although that does technically shut down the 
application, so maybe it can't be called "hot".

Anyway, you can read more here: https://github.com/stuartsierra/component

-- 
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] com.stuartsierra/component 0.3.0 now with ClojureScript

[Robin Heggelund Hansen]

Great stuff! Have been waiting on this :)

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

Re: [ANN] Clojure 1.8.0-alpha2

[Robin Heggelund Hansen]

Are tuples used for small maps 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: How to exclude compile-time dependencies from uberjar?

[Robin Heggelund Hansen]

All suggestions made the dependencies unavailable when running `lein 
uberjar` which means the project won't build :/

-- 
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 exclude compile-time dependencies from uberjar?

[Robin Heggelund Hansen]

I'm trying to get the smallest uberjar as possible. Currently I have a 
bunch of dependencies for compiling server resources (clojurescript, 
garden...) that are required at compile-time, but don't have to be in the 
uberjar. How can I create an uberjar without bundling these resources?

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 exclude compile-time dependencies from uberjar?

[Robin Heggelund Hansen]

I tried the following, but didn't seem to have any effect: 
[org.clojure/clojurescript 0.0-3211 :scope provided]

tirsdag 30. juni 2015 16.02.50 UTC+2 skrev Alex Miller følgende:

 You could try setting the :scope for the dependencies - I'm not sure if 
 uberjar does the right thing there or not but seems like it should.

 On Tuesday, June 30, 2015 at 3:56:31 AM UTC-5, Robin Heggelund Hansen 
 wrote:

 I'm trying to get the smallest uberjar as possible. Currently I have a 
 bunch of dependencies for compiling server resources (clojurescript, 
 garden...) that are required at compile-time, but don't have to be in the 
 uberjar. How can I create an uberjar without bundling these resources?

 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: [ANN] superstring - A string manipulation library

[Robin Heggelund Hansen]

CLJS outputs valid ES3 code, but string.prototype.normalizer is API, and 
can be added with a polyfill. That said, I don't really like code that 
depends on polyfills to function, so another solution would be preferred, 
especially since ES6 isn't that supported yet.

søndag 21. juni 2015 17.23.37 UTC+2 skrev Lars Andersen følgende:

 I thought about writing a cljs port, but I don't write much cljs so I 
 thought better of it.  Software quality usually suffers when it isn't used 
 by the author, I think.

 I'd love to find a collaborator to work on the cljs port of this library.

 ES6 actually adds string.prototype.normalizer but IIRC cljs usually 
 targets ES3.

 On Sunday, June 21, 2015 at 4:05:23 PM UTC+2, Karsten Schmidt wrote:

 That's ++great, Lars! Would you be open to convert this into CLJC so 
 it can all be used from CLJS as well? I guess the main stumbling block 
 is the use of java.text.Normalizer in strip-accents, but that could be 
 replaced with a hardcoded regexp solution for CLJS... 

 Thanks! 

 On 21 June 2015 at 13:45, Lars Andersen ex...@expez.com wrote: 
  I'm happy to announce the first release of superstring, a string 
  manipulation library for clojure. 
  
  Read more about why I wrote superstring here: 
  https://github.com/expez/superstring 
  
  Or check out the api docs for a quick overview of what's provided: 
  http://expez.github.io/superstring/doc/superstring.core.html 
  
  -- 
  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 
  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 
  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. 
  For more options, visit https://groups.google.com/d/optout. 



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



-- 
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: Project structure when using reader conditionals

[Robin Heggelund Hansen]

Take a look at my project.clj file.

https://github.com/Skinney/oslo-programmene/blob/development/project.clj

fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende:

 In the vein of there are no stupid questions :), how does one structure 
 a combined clj and cljs project that uses reader conditionals? At the 
 moment I am using cljx and have:
  - src/clj for clojure files
  - src/cljs for clojurescript files
  - src/cljx for cljx 
  - target/cljx/clj for clojure files compiled (transpiled?) from cljx
  - target/cljx/cljs for clojurescript files compiled (transpiled?) from 
 clix

 On the source path in cljsbuild for example I have src/cljs and 
 /target/cljx/cljs

 To remove cljx and use reader conditionals is it sufficient to:
  - replace src/cljx with src/cljc 
  - remove target/cljx from cljsbuild source path
  - add src/cljc to cljsbuild source path
  - add src/cljc to leiningen source path

 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: Project structure when using reader conditionals

[Robin Heggelund Hansen]

No, it doesn't. I update with `lein ancient update :all` and committed 
without checking if it worked. It's fixed locally :)

fredag 29. mai 2015 12.01.32 UTC+2 skrev Colin Yates følgende:

 Thanks Robin, that was helpful. I notice that you are using garden 1.2.6 - 
 that throws a CNF for garden.core and the garden page recommends not using 
 it - does it work for you?

 On 29 May 2015, at 10:49, Robin Heggelund Hansen skinn...@gmail.com 
 javascript: wrote:

 Take a look at my project.clj file.

 https://github.com/Skinney/oslo-programmene/blob/development/project.clj

 fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende:

 In the vein of there are no stupid questions :), how does one structure 
 a combined clj and cljs project that uses reader conditionals? At the 
 moment I am using cljx and have:
  - src/clj for clojure files
  - src/cljs for clojurescript files
  - src/cljx for cljx 
  - target/cljx/clj for clojure files compiled (transpiled?) from cljx
  - target/cljx/cljs for clojurescript files compiled (transpiled?) from 
 clix

 On the source path in cljsbuild for example I have src/cljs and 
 /target/cljx/cljs

 To remove cljx and use reader conditionals is it sufficient to:
  - replace src/cljx with src/cljc 
  - remove target/cljx from cljsbuild source path
  - add src/cljc to cljsbuild source path
  - add src/cljc to leiningen source path

 Thanks!


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

[Robin Heggelund Hansen]

Hmm... In Clojurescript you can do the following

(try
  ;; throw something
  (catch :default e
 e))

When I try the same thing in Clojure, it seems to not be supported. Is 
there any plans to support this syntax in Clojure 1.7?

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

Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released

[Robin Heggelund Hansen]

Ahh ok, makes sense.

mandag 13. april 2015 12.45.35 UTC+2 skrev David Nolen følgende:

 The only reason :default exists is because *anything* in JavaScript can be 
 thrown and there needs to be some way to catch non-Error derived values. 
 This is not the case for Java of course. :default could probably be aliased 
 to Throwable, but in the meantime differences like this are now handleable 
 via conditional reading.

 David

 On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen 
 skinn...@gmail.com javascript: wrote:

 Hmm... In Clojurescript you can do the following

 (try
   ;; throw something
   (catch :default e
  e))

 When I try the same thing in Clojure, it seems to not be supported. Is 
 there any plans to support this syntax in Clojure 1.7?

 -- 
 Note that posts from new members are moderated - please be patient with 
 your first post.
 --- 
 You received this message because you are subscribed to the Google Groups 
 ClojureScript group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojurescrip...@googlegroups.com javascript:.
 To post to this group, send email to clojur...@googlegroups.com 
 javascript:.
 Visit this group at http://groups.google.com/group/clojurescript.




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

Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times

[Robin Heggelund Hansen]

It says analysis caching is enabled when optimizations is :none. Do we have 
to enable to explicitly on other optimization levels?

tirsdag 10. mars 2015 00.42.28 UTC+1 skrev David Nolen følgende:

 ClojureScript, the Clojure compiler that emits JavaScript source code.

 README and source code: https://github.com/clojure/clojurescript

 New release version: 0.0-3058

 Leiningen dependency information:

 [org.clojure/clojurescript 0.0-3058]

 This is a significant enhancement release around REPLs and compile times.

 All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now
 support the helper functions normally available via clojure.repl,
 these include: doc, find-doc, apropos, dir, source, and pst.  All of the
 builtins REPL now also support source mapped stacktraces.

 This release also includes many enhancements around compile times.

 ClojureScript now ships with a default :optimizations setting of
 :none. Implicit now when using :none is source map generation and analysis
 caching. Analysis caching significantly speeds up compile times.

 The standard library (cljs.core) is now AOTed compiled to JavaScript
 along with an AOTed analysis dump and an AOTed source map. This
 dramatically cuts down on cold start compile times. The standard
 library is never actually ever analyzed or compiled in your own
 builds. The result is particularly dramatic for REPLs.

 ClojureScript is also now available for the first time as a standalone
 AOTed JAR. The Quick Start introduction has been rewritten in terms of
 the standalone JAR:
 https://github.com/clojure/clojurescript/wiki/Quick-Start

 The new Quick Start is essential reading even if you are a relatively
 experienced ClojureScript developer.

 As usual feedback welcome!

 ## 0.0-3058

 ### Enhancements
 * browser REPL source mapping for Firefox, Safari, Chrome
 * macro support in REPL special functions
 * CLJS-897: AOT core.cljs CLJS-899: AOT cache core.cljs analysis
 * CLJS-1078: Nashorn REPL should use persistent code cache
 * CLJS-1079: add way to execute arbitrary fn upon watch build completion
 * CLJS-1034: Support REPL-defined functions in stacktrace infrastructure
 * source mapping for Rhino
 * CLJS-1071: support symbol keys in :closure-defines
 * CLJS-1014: Support Closure Defines under :none
 * CLJS-1068: node target define
 * CLJS-1069: Generic :jsdoc support
 * CLJS-1030: add `cljs.repl/pst`
 * add `cljs.repl/apropos`, `cljs.repl/find-doc`, `cljs.repl/dir`
 * fix `cljs.analyzer.api/all-ns` docstring
 * add `cljs.analyzer.api/ns-publics`
 * CLJS-1055: cljs.repl/doc should support namespaces and special forms
 * Add ClojureScript special form doc map
 * CLJS-1054: add clojure.repl/source functionality to cljs.repl
 * CLJS-1053: REPLs need import special fn

 ### Changes
 * move :init up in cljs.repl/repl
 * CLJS-1087: with-out-str unexpectedly affected by *print-newline*
 * CLJS-1093: Better compiler defaults
 * Bump deps latest Closure Compiler, Rhino 1.7R5, data.json 0.2.6, 
 tool.reader 0.8.16
 * more sensible error if cljs.repl/repl arguments after the first 
 incorrectly supplied
 * default REPLs to :cache-analysis true
 * default :output-dir for Nashorn and Node REPLs
 * change ES6 Map `get` support to take additional `not-found` parameter
 * deprecate clojure.reflect namespace now that REPLs are significantly 
 enhanced, static vars, etc.

 ### Fixes
 * stop blowing away cljs.user in browser REPL so REPL fns/macros remain 
 available
 * CLJS-1098: Browser REPL needs to support :reload and :reload-all
 * CLJS-1097: source map url for AOTed cljs.core is wrong
 * CLJS-1094: read option not used by cljs.repl/repl*
 * CLJS-1089: AOT analysis cache has bad :file paths
 * CLJS-1057: Nashorn REPL should not use EDN rep for errors
 * CLJS-1086: Keyword constants should have stable names
 * CLJS-964: Redefining exists? does not emit a warning like redefining 
 array? does.
 * CLJS-937: local fn name should be lexically munged
 * CLJS-1082: analysis memoization bug
 * CLJS-978: Analysis caching doesn't account for constants table
 * CLJS-865: remove `cljs.js-deps/goog-resource` hack
 * CLJS-1077: analyze-deps infinite recursive loop
 * manually set *e in Rhino on JS exception
 * REPL options merging needs to be more disciplined
 * CLJS-1072: Calling .hasOwnProperty(source) in Clojurescript's 
 string/replace will break with ES6
 * CLJS-1064: ex-info is not printable
 * Fix REPLs emitting code into .repl directory
 * CLJS-1066: Rhino REPL regression
 * be more disciplined about ints in murmur3 code
 * Node.js REPL should work even if :output-dir not supplied
 * Nashorn environment doesn't supply console, setup printing correctly


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

core.async why 42 extra threads?

[Robin Heggelund Hansen]

From the source of core.async, I see that it is started with a threadpool 
of number of processors*2 + 42.

I can understand the number of processors * 2 part, erlang does the same 
thing. But Hitchicker's references aside, why add 42 to this? Won't that 
many threads do more harm than good, in terms of overhead related to 
context switching?

-- 
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: core.async why 42 extra threads?

[Robin Heggelund Hansen]

 Ahh ok, makes sense :)

-- 
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: Use core.async executor with aleph

[Robin Heggelund Hansen]

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.

Use core.async executor with aleph

[Robin Heggelund Hansen]

From what I can see, aleph allows me to set a executor to handle client 
requests. I'm already using core.async pretty heavily. Is there any reason 
why I shouldn't pass core.async's executor to aleph? I see I can also make 
every client request start on aleph's dispatch thread. Considering 
absolutely every request spawns a go-block, might it even be a good idea to 
not run aleph with an executor at all?

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: ANN: ClojureScript 0.0-2814, Nashorn REPL, async testing, and much more

[Robin Heggelund Hansen]

Does there exist a tutorial for how to setup a project using cljs.test? And 
some details on how the async testing works?

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: [ANN] cljfmt

[Robin Heggelund Hansen]

Looks cool. Is this somewhat inspired by go format?

lørdag 17. januar 2015 15.02.47 UTC+1 skrev James Reeves følgende:

 I've just released cljfmt 0.1.0, a code formatting library and Leiningen 
 plugin for Clojure.

 https://github.com/weavejester/cljfmt

 The library is useful for ensuring that the formatting is correct after 
 code transformations via tools like rewrite-clj.

 The plugin is useful for ensuring that pull requests and patches adhere to 
 coding standards.

 As a disclaimer, I should note that this library is inevitably going to 
 lacking some standard indentations, and I'm sure some are going to be 
 incorrect. I expect to be releasing a lot of patch versions as I fix issues!

 If you spot a bug, please open an issue or pull request for it. Pull 
 requests should include tests to prevent disclaimers.

 - James


-- 
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: TDD and lein

[Robin Heggelund Hansen]

The reason lein is initially slow, has to do with Clojures bootstrapping 
process, which is slow. People tend to avoid starting clojure programs 
repeatedly, and thus do alot of work from the repl, or using leiningen 
plugins which keeps running and listens for changes.

Take a look at lein-test-refresh for tdd:

https://github.com/jakemcc/lein-test-refresh

It detects when you change your code, incrementally compiles and re-runs 
the tests. It runs your tests everytime you save a file :)

kl. 12:32:44 UTC+1 torsdag 8. januar 2015 skrev Andrea Crotti følgende:

 Hi guys, 

 I'm starting to use Clojure a bit more seriously, I knew already Lisp a 
 bit and Haskell, in plus I've been using Emacs for a long time so 
 luckily it's not as hard, and it's a lot of fun. 

 I'm using Emacs + Cider for development and it works wonderfully, 
 however I have a few problems/questions trying to do TDD. 

 1. Isn't it possible to make Lein more verbose? 

It's often quite slow and it would be nice to know what is going 
on, I can stand the slowness but at least tell me something :D 

 2. When is exactly that I need to run again lein test (which is 
painfully slow) and when just rerunning the tests from the same REPL 
suffice? 

I thought only when changing dependencies, but I had different 
experiences so I'm not too sure about the rule. 

And what command exactly is Cider triggering when I run the tests? 
It would be nice to be able to see somewhere more information like: 
- compiling file x 
- running tests for y with command z 

  3. Does incremental compilation work well/make sense for Clojure? 
 I found something but the fact that it's not done straight away in 
 Leiningen makes me think it's maybe not much used? 

 Thanks a lot, and congratulations to all the developers for the great 
 language! 


-- 
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: A (foolish) plan to re-invent IO on top of core.async

[Robin Heggelund Hansen]

Thanks. This was very interesting, especially the part about back pressure.

kl. 18:52:53 UTC+1 onsdag 7. januar 2015 skrev Paul deGrandis følgende:

 There was another discussion on this list regarding async IO and web 
 servers.  It may be rather informative to you: 
 https://groups.google.com/d/msg/clojure/rKqT13Ofy4k/H9xvkZA9Yy4J

 To my knowledge, Pedestal is the only web library that let's you go async 
 all the way down to the wire (potentially the latest Aleph also allows for 
 this).  The benefit provided is that Pedestal manages the NIO integration 
 directly with the container for you - optimized to the specific container.  
 You may thumb through the implementation for some ideas.

 You also have to be very mindful about back-pressure when using core.async 
 in certain combinations.  Zach Tellman has covered the major points here: 
 https://groups.google.com/d/msg/clojure/TVMQJwaij1U/dQxyBxxbIjQJ

 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.

A (foolish) plan to re-invent IO on top of core.async

[Robin Heggelund Hansen]

I guess this post is mostly going to be a question, but one that could 
shape up to be a long open source project and contribution on my part, if 
it is warranted.

The Clojure community has been blessed with good language interoperability 
with Java, which has made it easy to use and wrap Java-libraries, which 
again I suspect is why Clojure is where it is today, a tool for 
professional development.

This has also, to some extent, been a curse, as we've relied on libraries 
made for a different language, instead of creating the world in our 
image, so to speak. I assume this is why core.async isn't as integrated in 
the Clojure ecosystem as I would like, because we already have libraries 
that works, and taking the time to make sure they scale well simply isn't 
worth it.

So I thought I would re-invent the wheel a little, but it depends on my 
premise being correct.

From what I understand, core.async basically creates state machines, that 
are run on a threadpool. Once you do something that blocks (like IO), you 
are kinda ruining the idea behind core.async, which is efficient 
concurrency at a large scale. I also assume, that having more than one 
threadpool, isn't really what you want. You want core.async to have the 
only threadpool running, and you want to run most things as go-blocks.

Today, way to many things block, like reading a file or reading from a 
database. Things that are async, mostly uses it's own threadpool. If I got 
this correctly, a standard web-app today will usually perform a blocking 
action for most DB-ops, requests will run in a http-server-specific 
threadpool, while agents or go-blocks has their own threadpool again.

Would I be correct that a clojure web-server, would be more efficient (at 
scale) if DB-ops and general request handling, ran entirely as go-blocks on 
the core.async threadpool alone?

I was thinking of creating a async.io library (core.async + NIO for file 
and socket ops), and after that perhaps create a socket-pool library before 
creating a core.async friendly SQL interface. Is there a point to this, or 
would I just be doing a lot of work for very little gain?

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: A (foolish) plan to re-invent IO on top of core.async

[Robin Heggelund Hansen]

But wouldn't those async interaces either use their own threads or 
threadpool, which would compete with core.async's threadpool for 
resources/cycles?

kl. 23:31:53 UTC+1 mandag 5. januar 2015 skrev tbc++ følgende:

 Many database APIs already contain async interfaces. Simply use those and 
 use core.async/put! and take! to allow them to operate on core.async 
 channels. You often don't need much more than that. 

 Timothy

 On Mon, Jan 5, 2015 at 3:18 PM, Robin Heggelund Hansen skinn...@gmail.com 
 javascript: wrote:

 I guess this post is mostly going to be a question, but one that could 
 shape up to be a long open source project and contribution on my part, if 
 it is warranted.

 The Clojure community has been blessed with good language 
 interoperability with Java, which has made it easy to use and wrap 
 Java-libraries, which again I suspect is why Clojure is where it is today, 
 a tool for professional development.

 This has also, to some extent, been a curse, as we've relied on libraries 
 made for a different language, instead of creating the world in our 
 image, so to speak. I assume this is why core.async isn't as integrated in 
 the Clojure ecosystem as I would like, because we already have libraries 
 that works, and taking the time to make sure they scale well simply isn't 
 worth it.

 So I thought I would re-invent the wheel a little, but it depends on my 
 premise being correct.

 From what I understand, core.async basically creates state machines, that 
 are run on a threadpool. Once you do something that blocks (like IO), you 
 are kinda ruining the idea behind core.async, which is efficient 
 concurrency at a large scale. I also assume, that having more than one 
 threadpool, isn't really what you want. You want core.async to have the 
 only threadpool running, and you want to run most things as go-blocks.

 Today, way to many things block, like reading a file or reading from a 
 database. Things that are async, mostly uses it's own threadpool. If I got 
 this correctly, a standard web-app today will usually perform a blocking 
 action for most DB-ops, requests will run in a http-server-specific 
 threadpool, while agents or go-blocks has their own threadpool again.

 Would I be correct that a clojure web-server, would be more efficient (at 
 scale) if DB-ops and general request handling, ran entirely as go-blocks on 
 the core.async threadpool alone?

 I was thinking of creating a async.io library (core.async + NIO for file 
 and socket ops), and after that perhaps create a socket-pool library before 
 creating a core.async friendly SQL interface. Is there a point to this, or 
 would I just be doing a lot of work for very little gain?

 Thanks!

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




 -- 
 “One of the main causes of the fall of the Roman Empire was that–lacking 
 zero–they had no way to indicate successful termination of their C 
 programs.”
 (Robert Firth) 
  

-- 
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: A (foolish) plan to re-invent IO on top of core.async

[Robin Heggelund Hansen]

Sure, the actual DB operation is not going to benefit from async io, but if 
you have a server using go-blocks to handle incoming requests, using 
blocking io would also block the threadpool running the go-blocks, limiting 
the number of requests you can handle.

If you have a threadpool of four threads, this means you would at most be 
able to process four requests if they are using blocking io, and those four 
requests would spend most of their time waiting on io. By using async io, 
requests waiting on io will park, so that you can use your processing time 
on other incoming requests (processing more than just four requests at a 
time).

kl. 00:14:54 UTC+1 tirsdag 6. januar 2015 skrev Thomas Heller følgende:

 I built a PostgreSQL Java client from scratch recently. Since it was not a 
 goal to support JDBC ever I thought about writing it with non-blocking 
 async IO. I played with some ideas but ultimately I decided not to. The 
 reason is quite simple. Async IO works well if you do enough IO to keep one 
 a more cores busy by just doing IO, which you get with something like a 
 server with many (100k+) connections for example. Threaded IO works equally 
 well or better if you only have a very few connections.

 You can't have many thousands connections to a postgresql server since a 
 connection is quite expensive and if you really stress the server you can 
 overload it with a handful of connections already. More connections won't 
 make anything any faster since they will basically slow each other down 
 more. So if you limit the connections anyway its alot simpler to do 
 blocking IO and API.

 That does not mean you can't interact with the database through core.async 
 channels, it's just not required to do in at the socket level.

 Async IO is not a magical solution to scalable servers, in fact many 
 servers probably won't benefit at all. Of course there are going to be some 
 that would benefit.

 Re-inventing the wheel is probably a huge waste of time. Stuff like Netty 
 already works pretty well and can be used from Clojure quite easily.

 Just my 2 cents,
 /thomas

 On Monday, January 5, 2015 11:18:42 PM UTC+1, Robin Heggelund Hansen wrote:

 I guess this post is mostly going to be a question, but one that could 
 shape up to be a long open source project and contribution on my part, if 
 it is warranted.

 The Clojure community has been blessed with good language 
 interoperability with Java, which has made it easy to use and wrap 
 Java-libraries, which again I suspect is why Clojure is where it is today, 
 a tool for professional development.

 This has also, to some extent, been a curse, as we've relied on libraries 
 made for a different language, instead of creating the world in our 
 image, so to speak. I assume this is why core.async isn't as integrated in 
 the Clojure ecosystem as I would like, because we already have libraries 
 that works, and taking the time to make sure they scale well simply isn't 
 worth it.

 So I thought I would re-invent the wheel a little, but it depends on my 
 premise being correct.

 From what I understand, core.async basically creates state machines, that 
 are run on a threadpool. Once you do something that blocks (like IO), you 
 are kinda ruining the idea behind core.async, which is efficient 
 concurrency at a large scale. I also assume, that having more than one 
 threadpool, isn't really what you want. You want core.async to have the 
 only threadpool running, and you want to run most things as go-blocks.

 Today, way to many things block, like reading a file or reading from a 
 database. Things that are async, mostly uses it's own threadpool. If I got 
 this correctly, a standard web-app today will usually perform a blocking 
 action for most DB-ops, requests will run in a http-server-specific 
 threadpool, while agents or go-blocks has their own threadpool again.

 Would I be correct that a clojure web-server, would be more efficient (at 
 scale) if DB-ops and general request handling, ran entirely as go-blocks on 
 the core.async threadpool alone?

 I was thinking of creating a async.io library (core.async + NIO for file 
 and socket ops), and after that perhaps create a socket-pool library before 
 creating a core.async friendly SQL interface. Is there a point to this, or 
 would I just be doing a lot of work for very little gain?

 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

Re: A (foolish) plan to re-invent IO on top of core.async

[Robin Heggelund Hansen]

So there are no benefits to having core.async being the only threadpool in 
the app?

kl. 03:12:15 UTC+1 tirsdag 6. januar 2015 skrev tbc++ følgende:

 And if you want async web frameworks, Pedestal supports core.async. You 
 just return a channel as a response body and it assumes that you will 
 eventually pipe your data down that channel. 

 Timothy

 On Mon, Jan 5, 2015 at 6:09 PM, David James david...@gmail.com 
 javascript: wrote:

 In case you are interested in a recent example, I wrote an NIO.2 based 
 Riak client in Clojure without Netty.
 https://github.com/bluemont/kria

 It uses callback functions, so the consumer can do whatever they want; 
 such as core.async.

 I agree with Timothy, above. My take-away from the experience is that 
 core.async does not need to be *baked into* a library. It is better if it 
 is not; for testing the library, I use atoms: 
 https://github.com/bluemont/kria/blob/master/test/kria/test_helpers.clj#L45

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




 -- 
 “One of the main causes of the fall of the Roman Empire was that–lacking 
 zero–they had no way to indicate successful termination of their C 
 programs.”
 (Robert Firth) 
  

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

Re: Can I use reduce here?

[Robin Heggelund Hansen]

(def sample [mytitle1 2015-02-01
 mytitle 2015-03-12
  2015-03-28
 mytitle3 2015-01-12])

;; Turns the map above into a map, skip this if you already have a map
(def working-set
  (- sample
   (partition 2) ;; Gives you [[mytitle1 2015-02-01] ]
   (group-by first))) ;; Gives you a map of title-list of dates

(- (fn [acc k v] (assoc acc {:title k, :events v}))
  (reduce-kv {} working-set))

kl. 11:07:58 UTC+1 fredag 12. desember 2014 skrev Mathias Picker følgende:

 Hi all,

 a short question from a newbie. I have a data structure like:

 mytitle1; 2015-02-01
 mytitle2; 2015-03-12
 ;2015-03-28
 mytitle3; 2015-01-12

 and want something like this

 [{:title mytitle1 :events [{:date 2015-02-01}]}
  {:title mytitle2 :events [{:date 2015-03-12} {:date 2015-03-28}]}
  {:title mytitle3 :events [{:date 2015-01-12}]}]

 I can recurse through the csv manually, but I have a dim feeling this 
 might be a job for reduce, but can't wrap my head around it...

 Can anyone give me a hint if and how this could be done? Or just tell me 
 that I'm mistaken?

 If I'm wrong about reduce, anything which uses part of the standard lib to 
 make this a more elegant solution would be interesting.


 Thanks,

 Mathias


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

Re: Can I use reduce here?

[Robin Heggelund Hansen]

If you want to turn the CSV text into a string, you can either find CSV 
decoders, or take a look at split-with

kl. 11:07:58 UTC+1 fredag 12. desember 2014 skrev Mathias Picker følgende:

 Hi all,

 a short question from a newbie. I have a data structure like:

 mytitle1; 2015-02-01
 mytitle2; 2015-03-12
 ;2015-03-28
 mytitle3; 2015-01-12

 and want something like this

 [{:title mytitle1 :events [{:date 2015-02-01}]}
  {:title mytitle2 :events [{:date 2015-03-12} {:date 2015-03-28}]}
  {:title mytitle3 :events [{:date 2015-01-12}]}]

 I can recurse through the csv manually, but I have a dim feeling this 
 might be a job for reduce, but can't wrap my head around it...

 Can anyone give me a hint if and how this could be done? Or just tell me 
 that I'm mistaken?

 If I'm wrong about reduce, anything which uses part of the standard lib to 
 make this a more elegant solution would be interesting.


 Thanks,

 Mathias


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

Re: Can I use reduce here?

[Robin Heggelund Hansen]

Wow, I made a lot of mistakes.

It should of course reduce into [] (not {}) and then it should be conj 
instead of assoc. I also made several spelling mistakes... Should 
probably sleep more I guess :P

kl. 11:57:00 UTC+1 fredag 12. desember 2014 skrev Mathias Picker følgende:

 Hi Robin, 

 thanks for the example of reduce above! That was what I was looking for. 
 I will try it out once I'm at my desk again. 


 / Mathias

-- 
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] differ 0.2.0 - Support for lists, vectors and sets

[Robin Heggelund Hansen]

https://github.com/Skinney/differ

Differ is a tool for creating and applying diffs on Clojure(script) 
datastructures.

Differ now has support for sequential types (vectors, seqs and lists) and 
sets.
Unfortunetly, differ can't detect changes in sets :/ Open for suggestions 
here.

-- 
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] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures

[Robin Heggelund Hansen]

https://github.com/Skinney/differ

I needed a way to send diffs of data from a cljs web-app to a clj backend, 
and I found clojure.data/diff to be a pain to work with, so i created my 
own solution. It currently only supports maps (and nested maps...), but 
support for lists, vectors and sets is on the roadmap for the next version. 
This version is mostly for me to test with my own app, which currently only 
uses maps.

-- 
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] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures

[Robin Heggelund Hansen]

Ahh, you're right, thats a typo and it should read person-map.

{:sex 0} is a map of keys removed. The reason I'm not using a set here is 
because I need to know the type of the datastructure to diff, and because 
it needs to work for nesting. For instance, this should also work.

(diff {:name Robin, :friends {:school #{Lars Jens Erika}}}) {:name 
Robin, :friends {:home #{Mom}, :school #{Lars}}})

Should return

[{:friends {:home #{Mom}}}
 {:friends {:school #{Jens, Erika}}}]

What I said about retaining type information becomes especially relevant 
when it comes to list/seq/vector, as all those structures support the same 
operations, but the result of patch should return the correct type.

kl. 07:42:30 UTC+1 tirsdag 18. november 2014 skrev Atamert Ölçgen følgende:

 Hi Robin,

 Thanks for adding a README. It might contain a couple of errors though.

 I can't make sense of this for example:

 (def person-map {:name Robin
  :age 25
  :sex :male})

 (def person-diff (differ/diff test-map {:name Robin Heggelund Hansen
 :age 26})
 ;; person-diff will now be [{:name Robin Heggelund Hansen, :age 26};;   
{:sex 0}]


 Where did test-map come from? I'm assuming it's person-map. Why is :sex 0? 
 Is he fat and bald? If that's a list of keys that's removed, I suggest 
 using a set there.

 (differ/patch {:specie :dog
:sex :female}
   person-diff)
 ;; Will return {:name Robin Heggelund Hansen;;  :age 26;;   
:specie :dog}


 Shouldn't the result contain [:sex :female] as well?


 On Tue, Nov 18, 2014 at 3:51 AM, Robin Heggelund Hansen 
 skinn...@gmail.com javascript: wrote:

 https://github.com/Skinney/differ

 I needed a way to send diffs of data from a cljs web-app to a clj 
 backend, and I found clojure.data/diff to be a pain to work with, so i 
 created my own solution. It currently only supports maps (and nested 
 maps...), but support for lists, vectors and sets is on the roadmap for the 
 next version. This version is mostly for me to test with my own app, which 
 currently only uses maps.

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




 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  

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

Re: [ANN] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures

[Robin Heggelund Hansen]

And no, the result shouldn't contain {:sex :female} because the :sex key is 
listed in the removals map, so it's correct that it's not included in the 
result.

kl. 07:42:30 UTC+1 tirsdag 18. november 2014 skrev Atamert Ölçgen følgende:

 Hi Robin,

 Thanks for adding a README. It might contain a couple of errors though.

 I can't make sense of this for example:

 (def person-map {:name Robin
  :age 25
  :sex :male})

 (def person-diff (differ/diff test-map {:name Robin Heggelund Hansen
 :age 26})
 ;; person-diff will now be [{:name Robin Heggelund Hansen, :age 26};;   
{:sex 0}]


 Where did test-map come from? I'm assuming it's person-map. Why is :sex 0? 
 Is he fat and bald? If that's a list of keys that's removed, I suggest 
 using a set there.

 (differ/patch {:specie :dog
:sex :female}
   person-diff)
 ;; Will return {:name Robin Heggelund Hansen;;  :age 26;;   
:specie :dog}


 Shouldn't the result contain [:sex :female] as well?


 On Tue, Nov 18, 2014 at 3:51 AM, Robin Heggelund Hansen 
 skinn...@gmail.com javascript: wrote:

 https://github.com/Skinney/differ

 I needed a way to send diffs of data from a cljs web-app to a clj 
 backend, and I found clojure.data/diff to be a pain to work with, so i 
 created my own solution. It currently only supports maps (and nested 
 maps...), but support for lists, vectors and sets is on the roadmap for the 
 next version. This version is mostly for me to test with my own app, which 
 currently only uses maps.

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




 -- 
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com
  

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

Re: Library to create/apply patches of clojure data

[Robin Heggelund Hansen]

Well, the diff would be arbitrary, and could be applied to any similar 
structure.


 16. nov. 2014 kl. 07.57 skrev Vladimir Bokov bokov.v...@gmail.com:
 
 Hi Robin,
 
 I'm also highly interested in the subject as I'm trying to do essentially the 
 same - reduce the client-server traffic using diffs over websocket.
 
 I think a diff solution is only the basis, I think we should look at some 
 VCS-like implementation to be able to merge some changes and to be able to 
 calculate arbitrary diff not only between previous and current state, but 
 comparing to some other state
 
 What do you think?
 
 четверг, 13 ноября 2014 г., 14:31:39 UTC+6 пользователь Robin Heggelund 
 Hansen написал:
 I'm in need of a library that is able to create a patch for some Clojure 
 datastructure, and apply it at a later time. This has to work in both Clojure 
 and Clojurescript.
 
 The use case is that I'm autosaving a datastructure (through repeatedly doing 
 ajax calls, could be done over websocket) that has 10-20kb of data, so I only 
 want to send the diffs to the server. I'm currently using a combination of 
 clojure.data/diff and some functions I've created myself to apply that diff. 
 I don't particular like the api of clojure.data/diff as it's confusing 
 (especially related to vectors) and, from my experience, doesn't always 
 respect type information.
 
 I'm currently in the process of creating my own library for this (will be 
 open-source, you can follow the process at github.com/Skinney/differ 
 http://github.com/Skinney/differ), but before I invest alot of effort into 
 this, I'm wondering if something like this already exists?
 
 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 
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/WBY5f3SVYxs/unsubscribe 
 https://groups.google.com/d/topic/clojure/WBY5f3SVYxs/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Library to create/apply patches of clojure data

[Robin Heggelund Hansen]

Thank you for the link. This doesn’t, from what I can tell, work on all Clojure 
datastructures, but a JSON-compatible subset.


 15. nov. 2014 kl. 23.09 skrev Karsten Schmidt i...@toxi.co.uk:
 
 Hi Robin, I just found a link to this library in the depths of the
 Liberator docs:
 
 https://github.com/daviddpark/clj-json-patch
 
 Maybe that's more helpful... (haven't tried it myself, but had to think of 
 you)
 
 On 14 November 2014 07:35, Robin Heggelund Hansen skinney...@gmail.com 
 wrote:
 If you look at the issues list, you'll see that I tried it already ;)
 
 kl. 06:51:14 UTC+1 fredag 14. november 2014 skrev Ruslan Prokopchuk
 følgende:
 
 May be this one will be helpful https://github.com/timothypratley/patchin
 
 четверг, 13 ноября 2014 г., 11:31:39 UTC+3 пользователь Robin Heggelund
 Hansen написал:
 
 I'm in need of a library that is able to create a patch for some Clojure
 datastructure, and apply it at a later time. This has to work in both
 Clojure and Clojurescript.
 
 The use case is that I'm autosaving a datastructure (through repeatedly
 doing ajax calls, could be done over websocket) that has 10-20kb of data, 
 so
 I only want to send the diffs to the server. I'm currently using a
 combination of clojure.data/diff and some functions I've created myself to
 apply that diff. I don't particular like the api of clojure.data/diff as
 it's confusing (especially related to vectors) and, from my experience,
 doesn't always respect type information.
 
 I'm currently in the process of creating my own library for this (will be
 open-source, you can follow the process at github.com/Skinney/differ), but
 before I invest alot of effort into this, I'm wondering if something like
 this already exists?
 
 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.
 
 
 
 -- 
 Karsten Schmidt
 http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/WBY5f3SVYxs/unsubscribe.
 To unsubscribe from this group and all its topics, 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.

Library to create/apply patches of clojure data

[Robin Heggelund Hansen]

I'm in need of a library that is able to create a patch for some Clojure 
datastructure, and apply it at a later time. This has to work in both 
Clojure and Clojurescript.

The use case is that I'm autosaving a datastructure (through repeatedly 
doing ajax calls, could be done over websocket) that has 10-20kb of data, 
so I only want to send the diffs to the server. I'm currently using a 
combination of clojure.data/diff and some functions I've created myself to 
apply that diff. I don't particular like the api of clojure.data/diff as 
it's confusing (especially related to vectors) and, from my experience, 
doesn't always respect type information.

I'm currently in the process of creating my own library for this (will be 
open-source, you can follow the process at github.com/Skinney/differ), but 
before I invest alot of effort into this, I'm wondering if something like 
this already exists?

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: Library to create/apply patches of clojure data

[Robin Heggelund Hansen]

If you look at the issues list, you'll see that I tried it already ;)

kl. 06:51:14 UTC+1 fredag 14. november 2014 skrev Ruslan Prokopchuk 
følgende:

 May be this one will be helpful https://github.com/timothypratley/patchin

 четверг, 13 ноября 2014 г., 11:31:39 UTC+3 пользователь Robin Heggelund 
 Hansen написал:

 I'm in need of a library that is able to create a patch for some Clojure 
 datastructure, and apply it at a later time. This has to work in both 
 Clojure and Clojurescript.

 The use case is that I'm autosaving a datastructure (through repeatedly 
 doing ajax calls, could be done over websocket) that has 10-20kb of data, 
 so I only want to send the diffs to the server. I'm currently using a 
 combination of clojure.data/diff and some functions I've created myself to 
 apply that diff. I don't particular like the api of clojure.data/diff as 
 it's confusing (especially related to vectors) and, from my experience, 
 doesn't always respect type information.

 I'm currently in the process of creating my own library for this (will be 
 open-source, you can follow the process at github.com/Skinney/differ), 
 but before I invest alot of effort into this, I'm wondering if something 
 like this already exists?

 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: [ANN] fast-zip 0.5.0 now with ClojureScript support

[Robin Heggelund Hansen]

Any reason this isn't a patch to clojure proper?

kl. 05:09:04 UTC+2 lørdag 4. oktober 2014 skrev Alexander Hudek følgende:

 Thanks to the wonderful work of Joel Holdbrooks, fast-zip now has 
 ClojureScript support.
 See the benchmarks below. The ClojureScript benchmark only uses simple 
 compiler 
 optimizations.

 Git: https://github.com/akhudek/fast-zip
 Clojars: [fast-zip 0.5.0]

 CLJS has ~ 1.7x speedup:

 :clojure.zip x 116 ops/sec ±0.65% (83 runs sampled)
 :fast-zip x 194 ops/sec ±0.85% (92 runs sampled)
 Fastest is :fast-zip 

 CLJ has ~ 5.2x speedup.

 ==
 WARNING: Final GC required 1.467359386689346 % of runtime
 Goal:  Benchmark vector zip.
 -
 Case:  :clojure.zip
 Evaluation count : 60480 in 60 samples of 1008 calls.
  Execution time mean : 1.002237 ms
 Execution time std-deviation : 7.317531 µs
Execution time lower quantile : 990.607677 µs ( 2.5%)
Execution time upper quantile : 1.015757 ms (97.5%)
Overhead used : 2.442790 ns

 Case:  :fast-zip
 Evaluation count : 316140 in 60 samples of 5269 calls.
  Execution time mean : 191.258856 µs
 Execution time std-deviation : 2.819942 µs
Execution time lower quantile : 188.802833 µs ( 2.5%)
Execution time upper quantile : 198.838310 µs (97.5%)
Overhead used : 2.442790 ns

 Found 8 outliers in 60 samples (13. %)
 low-severe   4 (6.6667 %)
 low-mild 4 (6.6667 %)
  Variance from outliers : 1.6389 % Variance is slightly inflated by outliers



-- 
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] Leiningen 2.3.4 released

[Robin Heggelund Hansen]

Same here =(

kl. 03:27:50 UTC+2 søndag 24. august 2014 skrev Dave Sann følgende:

 Do exclusions apply to plugins?

 if I have 

 :plugins [[com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]]]

 I get

 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [org.clojure/clojure [1.3.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)
 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [net.cgrand/regex 1.1.0] - [org.clojure/clojure [1.2.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)
 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [org.clojure/clojure 
 [1.2.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)
 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [net.cgrand/regex 1.1.0] - 
 [org.clojure/clojure [1.2.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)

 If it's a dependency, I don get the errors.

 Dave


 On Wednesday, 20 November 2013 05:41:07 UTC+11, Phil Hagelberg wrote:


 Hello folks. I'm happy to announce the release of Leiningen 2.3.4. 

 This one is primarily a bugfix release; though there are a few minor 
 enhancements. 

 ## 2.3.4 / 2013-11-18 

 * Suggest `:exclusions` to possibly confusing `:pedantic?` dependencies. 
 (Nelson Morris, Phil Hagelberg) 
 * Optionally look for snapshot templates in `new` task. (Travis Vachon) 
 * Allow task chains to be declared without commas in project.clj. (Jean 
 Niklas L'orange) 
 * Support extra configurability in `:pom-plugins`. (Dominik Dziedzic) 
 * Fix a bug where implicit :aot warning triggered incorrectly. (Jean 
 Niklas L'orange) 
 * Fix a bug where `lein repl connect` ignored port argument. (Toby 
 Crawley) 

 This brings all the functionality of the deprecated lein-pedantic plugin 
 into Leiningen itself. The snapshot template functionality allows 
 template developers to test their changes more easily, and the support 
 for improved task chaining allows us to express higher-order task 
 invocations in project.clj in a properly nested way without resorting to 
 commas, which are a hack to work around shell arguments' lack of 
 structuring. 

 As usual, running `lein upgrade` will pull in the latest stable release, 
 and if you run into any issues you can always run `lein downgrade 2.3.3` 
 to go back to the previous release. Please report any issues on the 
 Leiningen mailing list or the GitHub issue tracker. 

 Thanks to all the contributors and users who helped us get to this 
 release. 

 -Phil 



-- 
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: Core.logic for boardgames

[Robin Heggelund Hansen]

The idea was to implement the game rules (validating a move) using 
core.logic, but I take it that isn't something core.logic would be suited 
for?

kl. 11:42:18 UTC+2 mandag 11. august 2014 skrev puzzler følgende:

 I don't see how core.logic would apply here.

 You might be interested in a Java-based general game playing engine which 
 you can leverage from Clojure.  Many take logical descriptions of the game 
 rules in LISP form.

 http://www.ggp.org/



 On Sat, Aug 9, 2014 at 3:51 AM, Robin Heggelund Hansen skinn...@gmail.com 
 javascript: wrote:

 Hi.

 I'm starting a new project now, where users are presented with a set of 
 boardgames (chess, checkers, othello...) which they then can play together 
 online.
 Does it make sense to implement the game logic using core.logic, and does 
 it transfer well to cljs (i'd like to share logic between backend and 
 frontend if i can)?

 I don't know core.logic, but would like to learn if it is a good fit for 
 the problem I'm solving.

 Thanks!

 -- 
 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: Core.logic for boardgames

[Robin Heggelund Hansen]

Ok, thanks for all the answers :)

kl. 15:11:39 UTC+2 mandag 11. august 2014 skrev Moritz Ulrich følgende:

 Robin Heggelund Hansen skinn...@gmail.com javascript: writes: 

 Implementing non-trivial game-logic in core.logic or any other 
 logic-programming system is likely harder than implementing the 
 validation in Clojure, as you'd have to learn many new idioms and a 
 totally different programming style - but it's really mind-opening too. 

 You might just want to give it a try by learning some logic programming. 
 core.logic isn't well-suited nor ill-suited for such a task. 

  The idea was to implement the game rules (validating a move) using 
  core.logic, but I take it that isn't something core.logic would be 
 suited 
  for? 
  
  kl. 11:42:18 UTC+2 mandag 11. august 2014 skrev puzzler følgende: 
  
  I don't see how core.logic would apply here. 
  
  You might be interested in a Java-based general game playing engine 
 which 
  you can leverage from Clojure.  Many take logical descriptions of the 
 game 
  rules in LISP form. 
  
  http://www.ggp.org/ 
  
  
  
  On Sat, Aug 9, 2014 at 3:51 AM, Robin Heggelund Hansen 
 skinn...@gmail.com 
  javascript: wrote: 
  
  Hi. 
  
  I'm starting a new project now, where users are presented with a set 
 of 
  boardgames (chess, checkers, othello...) which they then can play 
 together 
  online. 
  Does it make sense to implement the game logic using core.logic, and 
 does 
  it transfer well to cljs (i'd like to share logic between backend and 
  frontend if i can)? 
  
  I don't know core.logic, but would like to learn if it is a good fit 
 for 
  the problem I'm solving. 
  
  Thanks! 
  
  -- 
  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 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. 

 -- 
 Moritz Ulrich 


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

Core.logic for boardgames

[Robin Heggelund Hansen]

Hi.

I'm starting a new project now, where users are presented with a set of 
boardgames (chess, checkers, othello...) which they then can play together 
online.
Does it make sense to implement the game logic using core.logic, and does 
it transfer well to cljs (i'd like to share logic between backend and 
frontend if i can)?

I don't know core.logic, but would like to learn if it is a good fit for 
the problem I'm solving.

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.

Clojure 1.7 and invokeStatic

[Robin Heggelund Hansen]

Just read this blog post about Oxen 
(http://arrdem.com/2014/08/05/of_oxen,_carts_and_ordering/?utm_source=dlvr.itutm_medium=twitter).
 
In it is mentioned that Rich is re-introducing invokeStatic to achieve a 
possible 10% performance increase for Clojure 1.7.

I couldn't find any information about this. Anyone know where I can find 
out more?

-- 
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 1.7 and invokeStatic

[Robin Heggelund Hansen]

Don't understand the compiler that well. Could you provide a short 
description of what is being done?

kl. 13:05:40 UTC+2 onsdag 6. august 2014 skrev Jozef Wagner følgende:

 See this WIP branch https://github.com/clojure/clojure/tree/direct

 On Wednesday, August 6, 2014 12:54:32 PM UTC+2, Robin Heggelund Hansen 
 wrote:

 Just read this blog post about Oxen (
 http://arrdem.com/2014/08/05/of_oxen,_carts_and_ordering/?utm_source=dlvr.itutm_medium=twitter).
  
 In it is mentioned that Rich is re-introducing invokeStatic to achieve a 
 possible 10% performance increase for Clojure 1.7.

 I couldn't find any information about this. Anyone know where I can find 
 out more?



-- 
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 1.7 and invokeStatic

[Robin Heggelund Hansen]

Perfect explination, thanks!

kl. 20:41:56 UTC+2 onsdag 6. august 2014 skrev Reid McKenzie følgende:

  Functions are objects implementing the IFn interface. This interface 
 defines a set of methods named invoke which return an object given up to 
 21 arguments.  Once the compiler is done emitting any given function, an 
 IFn object has been created. Def is a general operation which creates a 
 value and binds it to a var named by the current (*ns*, symbol) pair. So 
 for defn and an instance of this IFn object is what the bound var points 
 to. So as an example,

 user= (defn foo [x y] (+ x y 1))
 ; macroexpanded (def foo (fn* ([x y] (+ x y 1
 #'user/foo

 If you inspect the user namespace, you will find that the symbol foo now 
 maps to the var #'user/foo. Subsequent textual occurrences of the symbol 
 foo in this namespace will at compile time be mapped to the var #'user/foo, 
 and the emitted code will take the var #'user/foo and dereference it to get 
 an IFn object implementing the foo function which can be invoked.

 As there is overhead associated with dereferencing a var and some code 
 such as clojure.core/* is expected not to be redefined by users, the 
 ^:static annotation in Clojure 1.3 directed the compiler to emit `public 
 static invokeStatic` methods in addition to the normal `public invoke` 
 methods. This allowed potentially hot path functions to statically invoke 
 each other rather than using var indirection. This static linking of 
 function calls is how Oxcart achieves the reported 24% speedup, and the 
 linked direct branch is Rich implementing invokeStatic again, presumably 
 for Clojure 1.7.

 This static linking feature was introduced in Clojure 1.3 and removed in 
 Clojure 1.4 because as I mentioned in my linked blog post the downside of 
 static linking is that live development and code redefinition become harder 
 or impossible. My expectation is that, as 1.7 is projected to introduce 
 compilation profiles, this problem will be mitigated by different builds or 
 profiles of Clojure which may enable or disable static linking in a user 
 visible manner. So for an application deployment build you may choose 
 [org.clojure/clojure 1.7.0-static] which can use ^:static annotations for 
 a speedup while for development you may use [org.clojure/clojure 1.7.0] 
 which may ignore ^:static in exchange for a better REPL experience as 
 Clojure 1.6 and 1.5 do.

 Hope this helps,
 Reid

 On 08/06/2014 11:22 AM, Robin Heggelund Hansen wrote:
  
 Don't understand the compiler that well. Could you provide a short 
 description of what is being done?

 kl. 13:05:40 UTC+2 onsdag 6. august 2014 skrev Jozef Wagner følgende: 

 See this WIP branch https://github.com/clojure/clojure/tree/direct

 On Wednesday, August 6, 2014 12:54:32 PM UTC+2, Robin Heggelund Hansen 
 wrote: 

 Just read this blog post about Oxen (
 http://arrdem.com/2014/08/05/of_oxen,_carts_and_ordering/?utm_source=dlvr.itutm_medium=twitter).
  
 In it is mentioned that Rich is re-introducing invokeStatic to achieve a 
 possible 10% performance increase for Clojure 1.7.

 I couldn't find any information about this. Anyone know where I can find 
 out more?

   -- 
 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: Transducers are Coming

[Robin Heggelund Hansen]

I just want to check that I understand this. Instead of returning and 
manipulating lazy-seqs, you compose functions (sort of like they way you 
would in Haskell?) which return reqular seqs (non-lazy).

So I guess the upside is more flexibility, but you get eager-evaluation. Or 
am I misunderstanding something?

kl. 20:01:24 UTC+2 onsdag 6. august 2014 skrev Rich Hickey følgende:

 I pushed today the initial work on transducers. I describe transducers 
 briefly in this blog post: 

 http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming 

 This work builds on the work done for reducers, bringing 
 context-independent mapping, filtering etc to other areas, such as 
 core.async. 

 This is work in progress. We will be cutting alpha releases to help make 
 it easier to start using core's transducers together with core.async's new 
 support for them. 

 I am very excited about this powerful technique and how we all might use 
 it. 

 Please have a look. 

 Feedback welcome, 

 Rich 



-- 
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: Namespace browser for Emacs users

[Robin Heggelund Hansen]

Neat

kl. 04:48:20 UTC+2 mandag 28. juli 2014 skrev John Andrews følgende:

 Emacs users: I have put together a namespace browser which builds upon the 
 existing functionality of Cider. It is in early stages of development but I 
 find it quite useful.

 Check it out! https://github.com/jxa/cider-browse-ns
  

-- 
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 qarth 0.1.0, an OAuth library

[Robin Heggelund Hansen]

I was just looking for a OAuth library, this looks great!

kl. 19:15:11 UTC+2 torsdag 24. juli 2014 skrev Mike Thvedt følgende:

 Qarth is a simple interface to OAuth. Qarth's goal is to fix the problem 
 of Ring/Compojure and/or Friend apps reinventing the wheel for OAuth.

 Qarth features zero-effort Friend integration. The interactive auth flow 
 in friendless Qarth is two or three lines of code plus configuration. All 
 OAuth providers use the same interface, so that you can swap providers or 
 use multi providers (i.e. login with Facebook or Github) with little 
 additional effort.

 Qarth comes with out-of-the-box support for Facebook, Github, Twitter, 
 Google, and Yahoo!, and generic support for OAuth v2 and Scribe-Java.

 https://github.com/mthvedt/qarth

 Qarth is brand new, so please let me know about any issues or rough edges 
 you encounter.

 --Mike
 mike@gmail.com javascript:


-- 
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: Is Korma still a good current choice for DB backend?

[Robin Heggelund Hansen]

Don't know about SQL-based solutions, but Monger (MongoDB bindings) just 
released a 2.0 update and is great!

kl. 14:10:16 UTC+2 tirsdag 22. juli 2014 skrev Jonathon McKitrick følgende:

 Development and support seem to have slowed down.  Are there newer or 
 better choices out there with momentum right now?



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

Re: ANN: ClojureScript 0.0-2261

[Robin Heggelund Hansen]

Does murmur3 hashing effect performance?

kl. 04:42:39 UTC+2 onsdag 2. juli 2014 skrev David Nolen følgende:

 ClojureScript, the Clojure compiler that emits JavaScript source code. 

 README and source code: https://github.com/clojure/clojurescript 

 New release version: 0.0-2261 

 Leiningen dependency information: 

 [org.clojure/clojurescript 0.0-2261] 

 ### Changes 
 * Dependency on Clojure 1.6.0 
 * Dependency on latest Google Closure Compiler 

 ### Enhancements 
 * Murmur3 hashing for collections 

 ### Fixes 
 * CLJS-817: Warning on use of undeclared var when creating recursive 
 definition 
 * CLJS-819: cljs.reader cannot handle character classes beginning with 
 slashes in regex literals 
 * CLJS-820: Missing invoke without arguments in MetaFn 
 * CLJS-816: clojure.set/rename-keys accidentally deletes keys 


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

Datomic Pro Starter: limit per user or per app?

[Robin Heggelund Hansen]

Simple question, sorry if this is jotted down somewhere and I didn't read 
it :/

Regarding Datomic Pro Starter, is the limitation of 1 transactor+two peers 
per registered user, or per app? I would love to use datomic in my 
projects, but when free is recommended for dev and not prod, and I can only 
use datomic pro starter for one project, it kinda looses it's appeal :(

-- 
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: Datomic Pro Starter: limit per user or per app?

[Robin Heggelund Hansen]

Ahh, I didn't know there was a Datomic mailing list :P Will be watching 
your question then :)

kl. 13:59:38 UTC+2 torsdag 24. april 2014 skrev Jeroen van Dijk følgende:

 Coincidentally,  I was wondering the same today and I asked the same 
 question in different wording on the Datomic mailinglist 
 https://groups.google.com/forum/#!topic/datomic/gvP0ecJghd8




 On Thu, Apr 24, 2014 at 1:42 PM, Robin Heggelund Hansen 
 skinn...@gmail.com javascript: wrote:

 Simple question, sorry if this is jotted down somewhere and I didn't read 
 it :/

 Regarding Datomic Pro Starter, is the limitation of 1 transactor+two 
 peers per registered user, or per app? I would love to use datomic in my 
 projects, but when free is recommended for dev and not prod, and I can only 
 use datomic pro starter for one project, it kinda looses it's appeal :(
  
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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.

InvokeDynamic

[Robin Heggelund Hansen]

Hi!

Did someone ever look at supporting InvokeDynamic for Clojure? I've read a 
couple of blogs and it seemed interesting, would be cool to know if there 
actually were any advantages in practice.

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

[Robin Heggelund Hansen]

Yeah, those were the blog posts I've read, but I can't see that this is 
actually being worked on for Clojure?

4. apr. 2014 kl. 11:43 skrev Plínio Balduino pbaldu...@gmail.com:

 Hi, Hansen
 
 Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. 
 
 http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/
 
 http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1
 
 Plinio Balduino
 11 982 611 487
 
 On 04/04/2014, at 05:42, Robin Heggelund Hansen skinney...@gmail.com wrote:
 
 Hi!
 
 Did someone ever look at supporting InvokeDynamic for Clojure? I've read a 
 couple of blogs and it seemed interesting, would be cool to know if there 
 actually were any advantages in practice.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe.
 To unsubscribe from this group and all its topics, 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: InvokeDynamic

[Robin Heggelund Hansen]

Thank you!

4. apr. 2014 kl. 12:35 skrev Ragnar Dahlén r.dah...@gmail.com:

 You may find this thread enlightening:
 
 https://groups.google.com/d/msg/clojure-dev/PuV7XTps9vo/SkkNuiynKfUJ
 
 /Ragnar
 
 On Friday, 4 April 2014 10:44:42 UTC+1, Robin Heggelund Hansen wrote:
 Yeah, those were the blog posts I've read, but I can't see that this is 
 actually being worked on for Clojure?
 
 4. apr. 2014 kl. 11:43 skrev Plínio Balduino pbal...@gmail.com:
 
 Hi, Hansen
 
 Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. 
 
 http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/
 
 http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1
 
 Plinio Balduino
 11 982 611 487
 
 On 04/04/2014, at 05:42, Robin Heggelund Hansen skinn...@gmail.com wrote:
 
 Hi!
 
 Did someone ever look at supporting InvokeDynamic for Clojure? I've read a 
 couple of blogs and it seemed interesting, would be cool to know if there 
 actually were any advantages in practice.
 
 -- 
 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
 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
 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.
 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 clo...@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+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the 
 Google Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe.
 To unsubscribe from this group and all its topics, 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: InvokeDynamic

[Robin Heggelund Hansen]

Great to hear, I'm looking forward to progress :)

4. apr. 2014 kl. 14:45 skrev Alex Miller a...@puredanger.com:

 I agree that we cannot (yet) cut support for Java 6 but we continue to watch 
 polls and usage closely.  Java 6 has been EOL'ed for a while now and usage 
 continues to drop. However, there are a few minor JDK-specific bits already 
 in Clojure and it would be entirely possible to handle separate paths for 6 
 and 7.
 
 The major concern is with the stability and *predictability* of 
 invokedynamic. indy has undergone major revisions between Java 7 and 8 so it 
 may be that what needs to be done is substantially different between the two. 
 My impression from watching the work of people like Charles Nutter is that it 
 requires a lot of flag tweaking to make it work reliably. It also seems that 
 when you go off the fast path, you can go over a cliff with performance. 
 **These are my impressions - they could be wrong.** For these reasons, it has 
 not been high on the priority list, but having more work or data on this 
 would be great. I am not speaking for Rich here, but my guess is that this is 
 compatible with his thoughts.
 
 One of my first efforts for 1.7 is going to be working out how to support 
 multiple Clojure builds for different purposes (such as lean runtime, 
 Android, whatever) - this is foundational work that can open up the 
 possibility of specialized Clojure builds, such as an invokedynamic-aware 
 version.
 
 Alex
 
 On Friday, April 4, 2014 5:09:16 AM UTC-5, Plinio Balduino wrote:
 The guys from core team will correct me if I say any bs, but I think it's not 
 possible to keep Clojure compatible with Java 6, as Clojure 1.6 is, and use 
 InvokeDynamic bytecode in the same binary. DynJS, for example, is not 
 compatible with Java 6. 
 
 Anyway, it would be nice to see any experiment with that bytecode and 
 Clojure, maybe evolving to some form of Clojure 2.0. 
 
 It would be nice to hear the core team and/or Hickey's position about it. 
 
 Regards
 
 Plinio Balduino
 
 On 04/04/2014, at 06:44, Robin Heggelund Hansen skinn...@gmail.com wrote:
 
 Yeah, those were the blog posts I've read, but I can't see that this is 
 actually being worked on for Clojure?
 
 4. apr. 2014 kl. 11:43 skrev Plínio Balduino pbal...@gmail.com:
 
 Hi, Hansen
 
 Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. 
 
 http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/
 
 http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1
 
 Plinio Balduino
 11 982 611 487
 
 On 04/04/2014, at 05:42, Robin Heggelund Hansen skinn...@gmail.com wrote:
 
 Hi!
 
 Did someone ever look at supporting InvokeDynamic for Clojure? I've read a 
 couple of blogs and it seemed interesting, would be cool to know if there 
 actually were any advantages in practice.
 
 -- 
 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
 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
 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.
 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 clo...@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+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the 
 Google Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+u...@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 clo...@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+u...@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+u...@googlegroups.com

Re: ANN: Reagent 0.3.0 - now with async rendering

[Robin Heggelund Hansen]

Gotta ask, what's the difference between Om and  Reagent?

-- 
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/groups/opt_out.

Can't remember the name of that plugin

[Robin Heggelund Hansen]

Hi!

Just looked at the eastwood lint today, awesome project. It reminded me of 
another clojure plugin which analyzes your code and tells you how it could 
be written more idiomaticly. I can't remember the name of this plugin, does 
anyone know?

-- 
-- 
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/groups/opt_out.

Re: Can't remember the name of that plugin

[Robin Heggelund Hansen]

Great! Thanks :)

kl. 15:25:21 UTC+1 lørdag 11. januar 2014 skrev Baishampayan Ghose følgende:

 Kibit https://github.com/jonase/kibit ~BG 

 On Sat, Jan 11, 2014 at 7:39 PM, Robin Heggelund Hansen 
 skinn...@gmail.com javascript: wrote: 
  Hi! 
  
  Just looked at the eastwood lint today, awesome project. It reminded me 
 of 
  another clojure plugin which analyzes your code and tells you how it 
 could 
  be written more idiomaticly. I can't remember the name of this plugin, 
 does 
  anyone know? 
  
  -- 
  -- 
  You received this message because you are subscribed to the Google 
  Groups Clojure group. 
  To post to this group, send email to clo...@googlegroups.comjavascript: 
  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/groups/opt_out. 



 -- 
 Baishampayan Ghose 
 b.ghose at gmail.com 


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

Re: Is Clojure more functional then Scala?

[Robin Heggelund Hansen]

The reason Clojure supports you better is that Clojure doesn't really 
give you an alternative. Scala is BOTH OO and FP, Clojure is only FP.

The problem with Scala is that if you come from an OO language, Scala 
doesn't force you to use FP concepts, sure it's idiomatic, but there is 
nothing that forces you to write things in a functional way. Clojure forces 
you to do that, cause you don't really have an alternative. Because of 
that, you'll probably get better at FP faster with Clojure than with Scala. 
I write probably, because if someone really wants too, they'll learn FP 
regardless.

kl. 04:33:35 UTC+1 mandag 16. desember 2013 skrev John Kida følgende:

 I jumped on the FP bandwagon over a year ago and have been using Scala 
 both at work and for personal interest. Recently however I decided to take 
 a closer look at Clojure and see if it is something i actually like. I have 
 to admit at first the syntax form was awkward, but im starting to really 
 see the simplicity behind it.

 I have heard many people claim that Clojure sets you up and supports you 
 for FP more so then Scala does. However they never provide any examples of 
 something Clojure does that is more supporting of FP then the way idiomatic 
 Scala does it.

 Here are some things that I have heard people say when comparing Clojure 
 vs Scala in reference to FP
 Clojure has immutable persistance data structures. but so does Scala
 Scala also tries to get you to use its immutable collections, like 
 Vectors, and are also persistent data structures. However they are not as 
 uniform as Clojures Seq i agree with that.

 Also Scala recommends using vals and not vars, which gives you immutable 
 references points

 I am certainly learning towards dropping Scala for a bit and giving 
 Clojure a real shot. The reason i even picked up Scala was because i wanted 
 to learn more about FP, and if there is a better tool for both doing and 
 learning FP then i want it.

 So tell me, if you have used both Scala and Clojure, do you have some real 
 examples of some things where Clojure really does support you better when 
 doing FP, where Scala really leads you no way, or worse the imperative way?




-- 
-- 
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/groups/opt_out.

Re: Clojure can't import some Java classes

[Robin Heggelund Hansen]

Is this something that is fixable?

-- 
-- 
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/groups/opt_out.