ANN: Kibit 0.1.2 is released

[Daniel Compton]

I'm incredibly excited to announce that Kibit 0.1.2 has been released.
Kibit is a Leiningen plugin that inspects your code and suggests more
idiomatic ways of expression the same thing, e.g.

(+ 1 num) can be rewritten as (inc num)

The headlining features of this release are:
* Clojurescript/Cljx support (cljc support coming soon). This just works *™*,
kibit will pick up your source paths from your project.clj's :source-paths,
[:cljsbuild :builds], and [:cljx :builds].
* Non-zero exit codes. Kibit now exits non-zero when one or more
suggestions are made. This is particularly useful for those running checks
in a CI environment.
* You can now run kibit on any Clojure project without a project.clj file.
Just call `lein kibit` with any number of files and folders and it will
inspect the Clojure files contained within.

There are also a number of bug fixes, and new suggestions in this release.

You can install kibit by adding [lein-kibit "0.1.2"] to your :plugins
vector in your :user profile. More instructions and details are available
at https://github.com/jonase/kibit.

--
Daniel Compton.

-- 
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 needs a web framework with more momentum

[Daniel Compton]

The Clojure community has a knack for looking at things and distilling them
to their essence. I think the discussion on whether Clojure needs a web
framework is another opportunity for that.

I don't think Clojure doesn't need a web framework, because Clojure is a
programming language and doesn't need anything except a nice, warm JVM.
Even if you reframe the question, "Do people need a Clojure web
framework?", I still don't think its the right question. People don't need
a web framework, they need what a web framework provides for them, and
different people have very different needs.

If we use the Jobs To Be Done
 theory we can see
what job different groups of people 'hire' a framework for:

"The Business"

The business hires a popular framework because
* It offers the promise of quick development on features, with less time
spent on the unimportant parts.
* They want the security that their development team are working with
something popular that will be supported, maintained, and used by lots of
people for a long time.
* They also like the benefit that there will be a relatively large hiring
pool of people able to step into their codebase and get up to speed quickly.

"Recruiters"

Recruiters like to be able to pick out a particular technology and match
you to their clients requirements. Like it or not, thats the world that we
live in. If there was a common framework that people used, this part would
be easier for them and the developer trying to get hired.

"The CTO"

The CTO shares many of the same concerns with the business, she also
* Finds the shared conventions (from the framework and the community)
useful for eliminating bikeshedding.
* The shared conventions let developers understand each others code more
easily.
* Using a popular framework means that they are able to pull in battle
tested libraries for critical things like auth, and be fairly confident in
their quality.
* Common concerns that every webapp needs, like templating and
pluralisation are also built in.

"The junior developer"

A popular framework is great for a junior developer, they hire it for
* A scaffold of how to build a web application.
* The ability to get a quick win and get a real web application running
without spending 10 hours banging their head against the keyboard.
* Lots of standard functionality and third party libraries that they can
pull in without necessarily understanding how to do it themselves (i.e.
login and authorisation).
* A large amount of documentation to learn from, and a community that is
well set up for teaching beginners.
* The ability to slot into a larger development team because the work they
are doing can be well defined and matched to their skill level.

"The senior developer"

A framework is least useful to the senior developer, as they are often
capable of combining libraries with the functionality they need to build
their own webapp. They may find themselves restricted by the framework if
they want to step outside of the bounds that the framework provides.

If you agree with my characterisations then you can see that a framework
provides many different things to many different people. Clojure doesn't
necessarily need a web framework, but in my opinion it does need to satisfy
each of the parties involved with the development process if it wants to be
used more commonly in web app development.

What this may look like for Clojure in 2015 is probably very different than
what it looked like for Ruby in 2004. It may be a traditional framework, a
lein template, a standard pattern of code, a set of conventions and loosely
coupled protocols, pretty much exactly what we have now, or something
entirely different.

On Tue, May 5, 2015 at 12:53 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

>
> > My guess is that over the next 2-3 years we will see some clojure
> frameworks emerge but
> > they will not be like "traditional" frameworks.
>
> Or the space for "web framework" will always default to Rails. Clojure
> certainly has some great frameworks in other areas, such as distributed
> data processing:
>
> Avout
>
> tessers
>
> Onyx
>
> Storm
>
> Pulsar
>
> Quassar
>
> (Some of these are more Java than Clojure, but Java interop is one of
> Clojure's strengths.)
>
>
>
>
>
> On Monday, May 4, 2015 at 3:00:54 PM UTC-4, Gregg Reynolds wrote:
>>
>>
>> On May 4, 2015 7:16 AM, "Eric MacAdie"  wrote:
>> >
>> > I think what Clojure needs is a default. It doesn't matter if it is a
>> "web framework" like Rails, or "libraries strung together" like Luminus.
>> >
>>
>> What Clojure needs is, well nothing. What the market MAY need is an
>> entrepreneur who will produce the framework the OP craves.  No takers so
>> far.  Conclusion: not a genuine unmet need.   But in the long run simple
>> economics say the Clojure approach will win.  You can't make your product
>> stand out by using the same framework everybody else uses.  The inevitable
>> trend, driv

Testing strategies for cljc files

[Daniel Compton]

I'm wanting to migrate some files to cljc so a library can be used in
Clojure and ClojureScript. I want to be able to run the same test suite
against the Clojure and ClojureScript versions. What is the testing story
for cljc files?

If I made my test files cljc files as well, could I run clojure.test and
clojurescript.test against the same test files? Or is there another more
appropriate way of doing 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: Multimethod or protocol or...? Clojure design feedback

[Daniel Compton]

Alex Miller's recent blog post on this is quite relevant
http://insideclojure.org/2015/04/27/poly-perf/
On Fri, 15 May 2015 at 12:00 pm Max Countryman  wrote:

> I personally prefer multimethods, generally speaking—I think they feel
> more idiomatic. Although it does depend on the context of what you’re
> doing. In some cases a protocol may be the correct choice. Here the
> multimethod seems fine.
>
>
> On May 14, 2015, at 16:34, Jason Marmon  wrote:
>
> I'm working on a tool to orchestrate the migration from mongodb to
> datomic, and i'm looking for a bit of design feedback as i'm new to
> clojure.
>
>
> The user needs to provide functions that transform mongodb documents into
> datomic txes. Do y'all prefer the top or bottom style, or think there's a
> different way to implement this design that might be better?
> 12345678910111213141516171819
>
> ;; Multimethod for transforming data based on the name of the source mongodb 
> collection
> (defmulti transform identity)
>
> (defmethod transform "events" [data]
>;; do something with data
>  )
>
> (defmethod transform "users" [data]
>;; do something with data
>  )
>
> ;;
>
> (defprotocol Collection-Transformer
>(transform [mongo-db document]))
>
> (def user-transformer
>  (reify Collection-Transformer
>   (transform [m d] "do stuff")))
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Using :refer 'sparingly'

[Daniel Compton]

I'm not sure if this is idiomatic, but I often like to refer any def*
functions or macros, and :as alias the rest. I just prefer the visual look
of a bare def without a prefix. There's usually only a couple of those in a
codebase so it doesn't add too much overhead.
On Mon, 18 May 2015 at 4:05 am John Wiseman  wrote:

> There's a close parallel in Python, where the same issue comes up of
> typically using several modules or packages in a source file and the
> language offers a way to import the functions and classes of those modules
> in such a way that they can be used without any syntactic marker of their
> origin.  For years I've used the Google style guideline
> 
> which says "Use imports for packages and modules only", as distinct from
> functions, classes, etc., and the justification is "The source of each
> identifier is indicated in a consistent way; x.Obj says that object Obj is
> defined in module x".
>
> I've found that when reading code that I haven't written it lowers the
> friction for understanding just a little bit but that's multiplied by
> roughly the number of names in the source code.  It makes it (mostly)
> self-evident whether an identifier names a concept from the file I'm
> looking at, or somewhere else.  And if it's from somewhere else, it says
> right there where that other place is.  It's a significant advantage and I
> think the same advantage applies to clojure source code.
>
>
>
>
> On Sun, May 17, 2015 at 8:28 AM, Colin Yates 
> wrote:
>
>> As stated in the article, I find the extra context of using :as aids
>> maintenance more than you might expect. The only time I use refer is
>> if the referred vars are conceptually owned, or the context is
>> implicit by the name space using them. For me it is about
>> responsibility and ignorance. :as implies distance/ignorance, :refer
>> implies closeness/knowledge.
>>
>> A concrete example, in my use-case tests I refer most vars from
>> clojure.test for convenience but the thing being tested is aliased as
>> 'sut'. I could swallow referring the forms being tested in the test
>> case as well but I am used to the convention of 'sut' (subject under
>> test).
>>
>>
>> On 17 May 2015 at 16:23, Akiva  wrote:
>> > Makes sense. I guess my other question then would be if there are any
>> > benefits to using :refer along with :as.
>> >
>> > :A.
>> >
>> > Stuart Sierra
>> > May 17, 2015 at 10:21 AM via Postbox
>> > Just like the rest of the article, it's about readability. With
>> `:refer` you
>> > don't know where a symbol came from when you encounter it in the middle
>> of
>> > the code.
>> >
>> > –S
>> >
>> >
>> >
>> > On Sunday, May 17, 2015 at 4:05:14 PM UTC+1, Akiva Schoen wrote:
>> > --
>> > 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.
>> > Akiva
>> > May 17, 2015 at 10:04 AM via Postbox
>> > In Stuart Sierra's article here
>> > (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he
>> > recommends to use :refer sparingly but doesn't explain why this is a
>> good
>> > idea. Only thing I could think of without putting too much effort into
>> it is
>> > that it makes it slightly more tedious when you want to use a function
>> from
>> > a namespace that hasn't been already explicitly referred.
>> >
>> > Are there no benefits other than possibly excluding function names that
>> > might otherwise suffer a namespace clash (assuming their namespace isn't
>> > being aliased already)?
>> >
>> > Thanks,
>> > Akiva
>> >
>> >
>> > --
>> > Sent from Postbox
>> >
>> > --
>> > 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.
>> > 

Re: [ANN] Demo of the Holy Grail workflow

[Daniel Compton]

Same issues here. I'm guessing there may be some copyrighted material which
isn't approved for viewing in some regions?
On Fri, 22 May 2015 at 12:30 pm Daniel Szmulewicz <
daniel.szmulew...@gmail.com> wrote:

> I really don' know what to say. Works fine here. Including from my mobile.
> Anyone else has a problem accessing the video?
>
>
> On Friday, May 22, 2015 at 2:54:06 AM UTC+3, Daniel wrote:
>>
>> "this video is not available"
>>
>> I am attempting to view on a mobile.
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.7.0-RC1 now available

[Daniel Compton]

One of the most significant features of 1.7 are Reader Conditionals. I'm
pretty confident after all the discussion that has gone on that we have a
good design. However I haven't seen many or any libraries which have gone
through the porting process to use Reader Conditionals.

I've worked on porting a few libraries and everything has gone mostly
smoothly. However I'd feel more confident that we've got the right design
if we had more people trying to port their libraries/projects to cljc and
reporting their experiences.

Is this a reasonable concern, or am I missing something and this isn't
necessary?
On Fri, 22 May 2015 at 7:35 pm Jason Wolfe  wrote:

> We haven't shipped it to production yet, but I just verified that our full
> test suite at Prismatic passes on RC1 after fixing a few tests that were
> erroneously depending on hash ordering.   Thanks everyone for all the hard
> work on this release!
>
> On Thursday, May 21, 2015 at 9:31:08 AM UTC-7, Alex Miller wrote:
>>
>> Clojure 1.7.0-RC1 is now available.
>>
>> Try it via
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
>> - Leiningen: [org.clojure/clojure "1.7.0-RC1"]
>>
>> The only change since 1.7.0-beta3 is CLJ-1706, which makes reader
>> conditional splicing an error at the top level (previously it would
>> silently drop all but the first spliced element).
>>
>> For a full list of changes since 1.6.0, see:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>> Please give it a try and let us know if things are working (or not). The
>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>
>> - Alex
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Project structure when using reader conditionals

[Daniel Compton]

When porting a library to reader conditionals, I found that I only needed
one source directory for all my cljc and .clj files. Cljsbuild just picks
up the ones it needs and leaves the .clj ones.

So in some cases it may not be necessary to have a clj/, cljs/, and cljc/
folder, although in applications this structure might make more sense.
On Fri, 29 May 2015 at 10:31 pm Robin Heggelund Hansen 
wrote:

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

-- 
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: Adding a simple hook to lein build process without writing a plugin

[Daniel Compton]

Hi Jonathon

Some combination of https://github.com/hyPiRion/lein-shell and
https://github.com/technomancy/leiningen/blob/master/doc/DEPLOY.md#releasing-simplified
may be what you need, though it depends how you want to use the results of
`git describe`.

On Tue, Jun 2, 2015 at 7:27 AM Jonathon McKitrick 
wrote:

> I'd like my build and/or deployment process to suck in the output of `git
> describe` for use as a build version in the app.  What's the simplest way
> to do that without writing a leiningen plugin?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Handling exceptions with Reader Conditionals

[Daniel Compton]

On the Reader Conditionals
 dev discussion
page at one part it talks about exception handling:

"Exception handling, catching "all" - see issue below on why this is not a
complete solution in either case."

I looked further down the page and couldn't see a discussion of why this
isn't a complete solution. The only mentions of exceptions talked about
them at read time, but not in this context at run time. Is this mentioned
somewhere, on this page or elsewhere?

If it's not mentioned elsewhere, what are the caveats to using Reader
Conditionals for exception handling, and how can we work around it?
-- 
--
Daniel

-- 
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: Handling exceptions with Reader Conditionals

[Daniel Compton]

Looking closer, it looks like this was carried over from the Feature
Expressions design page, and related to the inability in ClojureScript to
catch all. However with http://dev.clojure.org/jira/browse/CLJS-661, it is
now possible to use :default, so it looks like this comment no longer
applies.

On Wed, Jun 3, 2015 at 10:12 PM Herwig Hochleitner 
wrote:

> 2015-06-02 23:57 GMT+02:00 Daniel Compton 
> :
>
>> On the Reader Conditionals
>> <http://dev.clojure.org/display/design/Reader+Conditionals> dev
>> discussion page at one part it talks about exception handling:
>>
>> "Exception handling, catching "all" - see issue below on why this is not
>> a complete solution in either case."
>>
>> I looked further down the page and couldn't see a discussion of why this
>> isn't a complete solution. The only mentions of exceptions talked about
>> them at read time, but not in this context at run time. Is this mentioned
>> somewhere, on this page or elsewhere?
>>
>
> You're right, there doesn't seem to be any further discussion of this on
> the page. Probably a Copy&Paste error. I assume, it talks about the issue
> that in javascript, anything can be thrown, even stuff that doesn't inherit
> from js/Object.
> Therefore, to catch really everything, you need to (catch :default ..) in
> clojurescript.
> Likewise, in java you need to catch java.lang.Throwable in order to catch
> everything, though, in most code this is not advisable, since Throwables
> that are not Exception are used for fatal errors, like OOM conditions.
>
> --
> 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.
>
-- 
--
Daniel

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

[Daniel Compton]

Hi Alex

Has Cognitect had any further discussion on this/do you have anything to 
share?

Thanks, Daniel.

On Monday, May 4, 2015 at 3:04:17 PM UTC+12, Alex Miller wrote:
>
> Re gsoc, last year Cognitect was a receiving organization for the funds 
> and distributed them to students for travel to Clojure conferences. This 
> incurs some cost on Cognitect for the accounting effort but overall seemed 
> worth it. We also offer free tickets to all gsoc students for any Clojure 
> conf we run. We are happy to keep doing this but would be happier to be 
> more out of the loop on money issues if there was some org that could act 
> in this capacity. 
>
> Re the Cognitect position on this stuff, I forwarded it to the appropriate 
> people - I don't yet have anything to share. 
>
> Alex

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

Clojars Private/Commercial Repos

[Daniel Compton]

Hi folks

I wondered if one possible solution for ensuring Clojars long-term
viability and maintenance would be to use it to host private repositories
for paying users as well? For many people, the thought of setting up and
maintaining Nexus or Archiva isn't an appealing one. I'm aware of the S3
wagon, and perhaps that's what people use if they don't want Nexus.

I'd be interested to hear what other people are doing, and whether Clojars
would be a good middle ground between simplicity and functionality. Many
Clojure users already have Clojars accounts and will have setup Lein to
deploy here already. Additionally, many people would support Clojars for
the goodwill factor.

On the other hand I'm aware this would require more development effort,
there may not be much demand for this, and the infrastructure costs may not
be large enough that it's worth going down this route.

Just a thought,

Daniel.
-- 
--
Daniel

-- 
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 don't support .clj source code file by utf-8.

[Daniel Compton]

Hi Alex

You'll need to give us some more information about this to help us
troubleshoot what's going on. Can you share the file with us?
On Fri, 10 Jul 2015 at 3:59 AM Alex Woods  wrote:

> clojure don't support .clj source code file by utf-8.
> it's ok when the .clj source code files by  ascii
>
> env:
> windows7,jdk1.8u45,lein2.5.0
>
>  --
> 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.
>
-- 
--
Daniel

-- 
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: clj-rethinkdb 0.10.1

[Daniel Compton]

I'm pleased to announce the release of clj-rethinkdb
 version 0.10.1, an idiomatic
driver for RethinkDB . This release brings a number
of new features including:

* Explicit, tested support for RethinkDB 2.0, including changefeeds.
* Use an implicit database connection so you don't need to specify the
database for every query.
* New arities for table queries which no longer require a database to be
specified.
* General cleaning up in preparation for future work, e.g. fixing
reflection warnings, more descriptive error messages, better docstrings,
refactoring tests, e.t.c.

There is also a full CHANGELOG

with release notes on these features and more.

*Of particular note, the 0.10.x branch will be the last branch to support
Clojure 1.6 and below.* 0.11 and onwards will use Clojure 1.7 in order to
take advantage of reader conditionals and generating queries on the client.

There are two really neat features of RethinkDB:
1. It uses a functional composable query language built on s-expressions
which dovetails nicely with Clojure.
2. It supports real-time, streaming, change feeds for documents, tables,
and (some) arbitrary queries.

If you haven't looked at it before, I encourage you to check out the 30-second
quick start .

Thanks, Daniel.
-- 
--
Daniel

-- 
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] suchwow: a grab-bag library with some twists

[Daniel Compton]

cljs.info have also done a heap of work on improving docstrings too.
On Mon, 13 Jul 2015 at 9:15 AM Brian Marick  wrote:

>
>
> Colin Fleming wrote:
> > I just saw this the other day, in particular the better docstrings are
> > great. See also Andy Fingerhut's Thalia
> >  project. I'm planning to provide
> > doc from both of these in Cursive soon.
>
> That does look nice. Wish I'd known of it earlier. I should probably
> merge my stuff in, if it's even needed.
>
> --
> 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.
>
-- 
--
Daniel

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

[Daniel Compton]

Is this a good candidate area for adding generative tests? It seems like
they may have been able to catch this regression.

On Mon, Jul 20, 2015 at 1:40 AM Alex Miller  wrote:

> Seems like a bug to me.
>
>
> On Sunday, July 19, 2015 at 3:10:37 AM UTC-5, Peter Taoussanis wrote:
>>
>> Hey Alex,
>>
>> Looks terrific, thank you! Particularly excited about CLJ-703 and tuples.
>>
>> Quick question: are tuples intended to implement :kv-reduce?
>>
>> Currently (with 1.8.0-alpha2):
>> (reduce-kv (fn [acc idx in] acc) nil [1 2 3 4 5 6 7]) ; => nil
>> (reduce-kv (fn [acc idx in] acc) nil [1 2])
>> ;; =>  No implementation of method: :kv-reduce of protocol:
>> ;; #'clojure.core.protocols/IKVReduce found for class:
>> clojure.lang.Tuple$T2
>>
>> Cheers :-)
>>
>>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
--
Daniel

-- 
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: Paper on Immutable Persistent Data Structures

[Daniel Compton]

 Jean Niklas L'orange has some posts about it at
http://hypirion.com/musings/understanding-persistent-vector-pt-1 (there's
more throughout his blog if you search).

On Tue, Jul 21, 2015 at 11:44 AM JvJ  wrote:

> Does anyone know if there exists a paper/web page describing in detail how
> each of Clojure's data structures are implemented?
>
> --
> 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.
>
-- 
--
Daniel

-- 
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: Tool authors: ClojureScript support in tools.namespace?

[Daniel Compton]

Kibit uses a vendored copy of file/clojure-file? and
find/find-clojure-sources-in-dir, to support other possible Clojure
extensions like cljx. Without the ability to add more extensions like cljx
we couldn't switch back, however even if they were added, it's probably not
worth adding the dep for two functions.

--
Daniel Compton
On Sat, 25 Jul 2015 at 2:48 PM Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> In core.typed I use *parse* and *file* to parse Clojure files and
> probably ClojureScript files eventually.
>
> I resolve the files myself so I don't have strong opinions on 3).
>
> Thanks,
> Ambrose
>
> On Sat, Jul 25, 2015 at 5:14 AM, Stuart Sierra <
> the.stuart.sie...@gmail.com> wrote:
>
>> Hello to anyone and everyone writing tools for working with Clojure and
>> ClojureScript source files …
>>
>> I've been looking into adding better support for ClojureScript in
>> tools.namespace.
>>
>> It's not a trivial problem. Lots of places in tools.namespace assume
>> there is only one kind of source file. For Clojure 1.7 it got updated to
>> include .cljc files as well, but it's still hard-coded. I've collected some
>> of my notes in TNS-35: http://dev.clojure.org/jira/browse/TNS-35
>>
>> My question to you: if you maintain a tool or library which uses
>> tools.namespace:
>>
>>1. Do you need/want ClojureScript support?
>>
>>2. What namespaces (repl, find, dir, file, parse) do you call in
>> tools.namespace?
>>
>>3. How would you like to distinguish between "get me Clojure sources"
>> and "get me ClojureScript sources"?
>>
>> Note: I am **not** proposing a full port of tools.namespace to
>> ClojureScript. Something like c.t.n.repl/refresh is too tightly coupled
>> to JVM Clojure, and equivalent tools already exist for ClojureScript.
>>
>> This is just about using tools.namespace to parse and analyze the
>> dependencies of ClojureScript source files, statically, the same way it now
>> does for Clojure source files.
>>
>> Thanks,
>> –S
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
--
Daniel

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

[Daniel Compton]

I think this is pretty unlikely. While megarefs look very cool, I'm not
sure what the benefit to having these directly in Clojure would be over
having them in a library.

Anecdotally, everyone I have talked to about Clojure's reference types have
said that they have never needed to use ref's or agents in real world code
(I'm sure some people have to good effect though).

That being said, you can always open a JIRA or design doc about this if you
feel strongly about it to start a discussion.

--
Daniel.

On Tue, 28 Jul 2015 at 9:05 AM Lawrence Krubner 
wrote:

> Off topic, but I wonder if there was ever any discussion of megarefs being
> added to Clojure?
>
> https://github.com/cgrand/megaref
>
>
> On Tuesday, July 21, 2015 at 3:30:46 PM UTC-4, Rangel Spasov wrote:
>>
>> Ok, I think someone already mentioned this - sorry. Got it to compile by
>> bumping to [potemkin "0.4.1"] - thanks Zach + all : )
>>
>> On Tuesday, July 21, 2015 at 12:24:43 PM UTC-7, Rangel Spasov wrote:
>>>
>>> Hey guys,
>>>
>>> Getting this error with 1.8.0-alpha2, I think related to aleph (using
>>> 0.4.0, latest version at the moment).
>>>
>>> #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 6798]}
>>>
>>>   {: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 7815]
>>>
>>>   [clojure.lang.Compiler$NewInstanceExpr build Compiler.java 7680]
>>>
>>>   [clojure.lang.Compiler$NewInstanceExpr$DeftypeParser parse
>>> Compiler.java 7590]
>>>
>>>   [clojure.lang.Compiler analyzeSeq Compiler.java 6791]
>>>
>>>   [clojure.lang.Compiler analyze Compiler.java 6592]
>>>
>>>   [clojure.lang.Compiler analyze Compiler.java 6553]
>>>
>>>   [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]
>>>
>>>   [clojure.lang.Compiler$LetExpr$Parser parse Compiler.java 6247]
>>>
>>>   [clojure.lang.Compiler analyzeSeq Compiler.java 6791]
>>>
>>>   [clojure.lang.Compiler analyze Compiler.java 6592]
>>>
>>>   [clojure.lang.Compiler analyze Compiler.java 6553]
>>>
>>>   [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]
>>>
>>>   [clojure.lang.Compiler$FnMethod parse Compiler.java 5359]
>>>
>>>   [clojure.lang.Compiler$FnExpr parse Compiler.java 3959]
>>>
>>>   [clojure.lang.Compiler analyzeSeq Compiler.java 6789]
>>>
>>>   [clojure.lang.Compiler analyze Compiler.java 6592]
>>>
>>>   [clojure.lang.Compiler eval Compiler.java 6847]
>>>
>>>   [clojure.lang.Compiler eval Compiler.java 6839]
>>>
>>>   [clojure.lang.Compiler load Compiler.java 7295]
>>>
>>>   [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__5448 invoke core.clj 5866]
>>>
>>>   [clojure.core$load doInvoke core.clj 5865]
>>>
>>>   [clojure.lang.RestFn invoke RestFn.java 408]
>>>
>>>   [clojure.core$load_one invoke core.clj 5671]
>>>
>>>   [clojure.core$load_lib$fn__5397 invoke core.clj 5711]
>>>
>>>   [clojure.core$load_lib doInvoke core.clj 5710]
>>>
>>>   [clojure.lang.RestFn applyTo RestFn.java 142]
>>>
>>>   [clojure.core$apply invoke core.clj 632]
>>>
>>>   [clojure.core$load_libs doInvoke core.clj 5749]
>>>
>>>   [clojure.lang.RestFn applyTo RestFn.java 137]
>>>
>>>   [clojure.core$apply invoke core.clj 632]
>>>
>>>   [clojure.core$require doInvoke core.clj 5832]
>>>
>>>   [clojure.lang.RestFn invoke RestFn.java 551]
>>>
>>>   [aleph.http.server$eval9251$loading__5340__auto9252 invoke
>>> server.clj 1]
>>>
>>>   [aleph.http.server$eval9251 invoke server.clj 1]
>>>
>>>   [clojure.lang.Compiler eval Compiler.java 6850]
>>>
>>>   [clojure.lang.Compiler eval Compiler.java 6839]
>>>
>>>   [clojure.lang.Compiler load Compiler.java 7295]
>>>
>>>   [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__5448 invoke core.clj 5866]
>>>
>>>   [clojure.core$load doInvoke core.clj 5865]
>>>
>>>   [clojure.lang.RestFn invoke RestFn.java 408]
>>>
>>>   [clojure.core

Re: Rethinkdb problem with clojure

[Daniel Compton]

Hemant, it looks like you're using clj-rethinkdb as your driver. Can you
open an issue on GitHub and we can help diagnose the issue from there?
On Wed, 29 Jul 2015 at 8:36 PM hemant gautam  wrote:

> Hi All--
>
> I am trying to use RethinkDb for the first time. My rethinkDb server
> available at some IP addr: XYZ. I have made changes into instance
> configuration file in order to access it through browser on my local
> machine and I am able to access it at http://XYZ:8080
>
> In order to connect to RethinkDB from a clojure program residing in my
> local machine. I am creating connection as (connect :host "XYZ" :port 28015
> :db "test"). This "test" is present.
> On running a program it gives exception saying cannot connect to DB. I
> tried to check on instance configuration file and tried some steps but it
> didn't helped.
>
> Can anyone suggest me what I am missing in the connect statement.
> Thanks in advance :)
>
> --
> 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.
>
-- 
--
Daniel

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

[Daniel Compton]

For those wondering like me what "Direct Linking" is, here are a few links 
I could find. This seems to be a very old possible improvement to Clojure 
which is being looked at again.

http://dev.clojure.org/display/design/Build+Profiles
https://groups.google.com/forum/#!msg/clojure-dev/guT3QBEg5w0/9deJ5E0AW9sJ
https://groups.google.com/forum/#!msg/clojure-dev/guT3QBEg5w0/e6m0RZ0yk4gJ

On Thursday, July 30, 2015 at 10:51:18 AM UTC+12, Alex Miller wrote:
>
> Clojure 1.8.0-alpha3 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha3
> - Leiningen: [org.clojure/clojure "1.8.0-alpha3"]
>
> Tuples have been disabled after further analysis of performance impacts.
>
> This alpha has initial support for direct linking which you can enable 
> with -Dclojure.compiler.direct-linking=true
>
> Direct linking allows functions compiled with direct linking on to make 
> direct static method calls to most other functions, instead of going 
> through the var and the Fn object. This can enable further optimization by 
> the jit, at a cost in dynamism. In particular, directly-linked calls will 
> not see redefinitions.
>
> In alpha3, clojure.core is compiled with direct linking by default and 
> therefore other namespaces cannot redefine core fns and have those 
> redefinitions seen by core code.
>
> Functions declared as dynamic will never be linked to directly.
>
> As with all alphas, this represents ongoing work-in-progress that is 
> subject to change.
>

-- 
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] Grimoire: up to date Clojure web docs

[Daniel Compton]

What is the status of Clojuredocs? It has lots of good examples and Google 
juice but is out of date. It would be great if we could update it to 1.6. I'd 
be happy to help in whatever way is needed. 

Is this possible/feasible?

Daniel.

> On 2/07/2014, at 12:22 pm, Francesco Bellomi  
> wrote:
> 
> Very nice work.
> 
> I've recently done something similar, by adding to http://crossclj.info the 
> ability to navigate auto-generated docs from docstrings and metadata.
> 
> The user interface balance is a bit different, the navigation is by namespace 
> or by project, for example:
> 
> http://crossclj.info/doc/org.clojure/clojure/1.6.0/clojure.string.html
> 
> you see all the docs for the whole namespace, and you can jump to the source 
> of a function (within the whole namespace source).
> 
> you can navigate the namespace hierarchy and switch from source to docs view 
> using the control on the top left 
> 
> There is no way to add examples, but you can search for usages from all the 
> indexed open source projects, which is usually pretty effective (you can try 
> by clicking on one of the Usages link in the page above).
> 
> The auto generated doc is available and cross-referenced not only for the 
> clojure standard lib, but also for all the indexed open-source projects (you 
> can search them from the home page, or by navigating the references in the 
> sources), although with different quality and coverage levels, due to some 
> practical issues in working with arbitrary sources.
> 
> Other examples:
> http://crossclj.info/doc/instaparse/1.3.2/instaparse.core.html
> http://crossclj.info/doc/clj-time/0.7.0/clj-time.core.html
> 
> Overall, I think it's useful and enriching to see different UI approaches at 
> work.
> 
> Francesco
> 
> 
> 
> 
>> On Wednesday, July 2, 2014 1:34:38 AM UTC+2, Reid McKenzie wrote:
>> Hey guys, 
>> 
>> If you're like me while using clojure.repl/doc works for the most part 
>> there are just times that you need to send someone a link to the 
>> official docs and navigating the docstrings in the core Clojure 
>> repository is a pain. 
>> 
>> After several months of being frustrated that clojuredocs is out of 
>> date, I finally sat down and built an alternative which I'm pleased to 
>> present here: http://www.arrdem.com/grimoire/ 
>> 
>> Grimoire is still alpha and subject to change, especially with regards 
>> to the example contribution process which needs streamlining beyond the 
>> current "click a link, edit on github and submit a PR". 
>> 
>> I'd like to give a shout out to César for porting clojure.repl/source 
>> into the doc generation script and to Nicola for his random usability 
>> criticisms. 
>> 
>> Reid McKenzie
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: map output to string

[Daniel Compton]

Hi Glen

One thing to keep in mind with lazy sequences is that running them at the
REPL will force them to be fully realised, whereas a lazy sequence may not
be realised in other contexts. I didn't understand where 'clojure-lazy-seq'
is coming from in your question so I'm not sure if that's your issue or not.


On 8 July 2014 09:49, Glen Rubin  wrote:

> my-fn takes a number and a string as argument and outputs a string.  I am
> using map-indexed and my-fn to comprehend a list of items with numbered
> index as follows,
>
>
> (map-indexed (fn [idx itm]  (my-fn idx itm)) '(list-of-crap))
>
> When i run this on the repl everything works well and I get a single long
> string of output. But, I am trying to use the output of this function in a
> report and it is not working in that context.
>
> The code to generate report looks something like this:
>
>  (str
>   string1
>   string2
>   string3
> (map-indexed (fn [idx itm] (my-fn idx itm)) '(listofcrap))
>   string4etc...
> )
>
> The code above will just print out 'clojure-lazy-seq' instead of the
> string output.  If I try:
>
> (apply str  (map-indexed (fn [idx itm] (my-fn idx itm)) '(listofcrap)))
>
> Then I get the last item from my list properly formated in the report, but
> that's all.  How do I print out everything?  Thanks
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: map output to string

[Daniel Compton]

To force realisation of a sequence, use one of the do* forms. 
https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/do

If you post a gist of your code then someone may be able to give more specific 
guidance. 

Daniel.

> On 8/07/2014, at 2:15 pm, Glen Rubin  wrote:
> 
> yes, that is exactly my issue. i am trying to get the lazy sequence fully 
> realized as you say, but it's not happening in the context i put it in.  
> 
>> On Monday, July 7, 2014 6:04:00 PM UTC-7, Daniel Compton wrote:
>> Hi Glen
>> 
>> One thing to keep in mind with lazy sequences is that running them at the 
>> REPL will force them to be fully realised, whereas a lazy sequence may not 
>> be realised in other contexts. I didn't understand where 'clojure-lazy-seq' 
>> is coming from in your question so I'm not sure if that's your issue or not.
>> 
>> 
>>> On 8 July 2014 09:49, Glen Rubin  wrote:
>>> my-fn takes a number and a string as argument and outputs a string.  I am 
>>> using map-indexed and my-fn to comprehend a list of items with numbered 
>>> index as follows, 
>>>  
>>>  
>>> (map-indexed (fn [idx itm]  (my-fn idx itm)) '(list-of-crap))
>>>  
>>> When i run this on the repl everything works well and I get a single long 
>>> string of output. But, I am trying to use the output of this function in a 
>>> report and it is not working in that context.
>>>  
>>> The code to generate report looks something like this:
>>>  
>>>  (str
>>>   string1
>>>   string2
>>>   string3
>>> (map-indexed (fn [idx itm] (my-fn idx itm)) '(listofcrap))
>>>   string4etc...
>>> )
>>>  
>>> The code above will just print out 'clojure-lazy-seq' instead of the string 
>>> output.  If I try:
>>>  
>>> (apply str  (map-indexed (fn [idx itm] (my-fn idx itm)) '(listofcrap)))
>>>  
>>> Then I get the last item from my list properly formated in the report, but 
>>> that's all.  How do I print out everything?  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
>>> 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.

-- 
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: Tools for cleaning namespaces?

[Daniel Compton]

There’s also a lein plugin, ns-dep-graph which will generate a graphviz file 
for your namespace dependencies. https://github.com/hilverd/lein-ns-dep-graph

Daniel.


On Tuesday, 29 July 2014 at 2:38 am, Andy Fingerhut wrote:

> You can try Eastwood's :unused-namespaces linter for #2.  It is disabled by 
> default, so you need to give an option on the command line to enable it.  If 
> you want to try *only* that linter, and none of the other warnings, first 
> follow the simple install instructions in the README, then change to the home 
> dir of your project and type:
>  
> lein eastwood '{:linters [:unused-namespaces]}'
>  
> Eastwood will not currently help you with your request #1, but it would not 
> be difficult to add such a feature to it, since it determines dependencies 
> between namespaces already using tools.namespace.  There are other tools that 
> can do this for you, e.g. nephila [2] will create a graphics image of your 
> project's namespace dependencies, but you must have graphviz installed.  I 
> don't know of a similar tool that only creates text dependency output.
>  
> Andy
>  
> [1] https://github.com/jonase/eastwood
>  
> [2] https://github.com/timmc/nephila
>  
>  
> On Mon, Jul 28, 2014 at 4:58 AM, Bertrand Dechoux  (mailto:decho...@gmail.com)> wrote:
> > Hello,
> >  
> > I am trying to tidy up a project and I have two actions that could be 
> > somehow be automatized.  
> >  
> > 1) Display the dependencies between the namespace of my project as a graph 
> > (text graph being good enough).
> > One would want to break dependencies which do not make sense and sometimes 
> > to create indirection in order to lessen the impact of changes.
> >  
> > 2) Find out which dependencies are not required.
> > Splitting a namespace might be quite easy (the complex part is on the 
> > consumer side) but often I find out that dependencies were not pruned 
> > correctly.
> > And so there are useless remaining dependencies that were not removed.  
> >  
> > I understand that a 100% bullet proof solution might be really hard to do.
> > But I was wondering, is there any tools that allows to do these tasks for 
> > common cases?
> >  
> > Regards
> >  
> > Bertrand Dechoux  
> >  
> > --  
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com 
> > (mailto:clojure@googlegroups.com)
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com 
> > (mailto:clojure%2bunsubscr...@googlegroups.com)
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---  
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com 
> > (mailto:clojure+unsubscr...@googlegroups.com).
> > For more options, visit https://groups.google.com/d/optout.
>  
> --  
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> (mailto:clojure@googlegroups.com)
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> (mailto:clojure+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 
> (mailto: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.

ANN: Auckland, NZ Clojure Meetup

[Daniel Compton]

I'm pleased to re-announce the Auckland Clojure Meetup. After a dormant period 
it has been restarted. We've had a great couple of nights so far and I realised 
I hadn't let the list know about it. The goal is to do a mix of practical 
session so, as well as talks and presentations from speakers. We've got a wide 
range of skill levels from absolute beginner to very advanced, so come along 
even if you don't know a lot (or anything) about Clojure.

Our next session is on Thursday, August 28. We'll be discussing some real world 
Clojure code and the Clojure features that make it tick. More details are 
available at http://www.meetup.com/Auckland-Clojure/events/194070262/ and the 
group details are at http://www.meetup.com/Auckland-Clojure. 

---
Daniel

-- 
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 do I clojure.string/replace regex characters? Escaping gives me StringIndexOutOfBoundsException

[Daniel Compton]

Hi Larry

>From the scheme you described you will run into problems if your field name 
>actually contains a *. When you go to reconvert the string, it would replace 
>genuine *'s  with $'s that aren't there. 

Daniel.

> On 5/08/2014, at 6:50 pm, Andy Fingerhut  wrote:
> 
> Or even more simply, since the thing you want to replace is a single 
> character, you do not need a regex to match it, but can match a string that 
> is not a regex at all, e.g.:
> 
> (st/replace "**username" "*" "$")
> 
> The doc string for clojure.string/replace is fairly explicit on this.
> 
> Andy
> 
> 
>> On Mon, Aug 4, 2014 at 11:30 PM, Vincent H  wrote:
>>> On Tuesday, August 5, 2014 7:49:21 AM UTC+2, larry google groups wrote:
>>> I'm working on a website with a frontender who asked to be able to save 
>>> JSON maps that contain field names such as: 
>>> 
>>> "$$hashKey" : "00C"
>>> 
>>> The dollar signs are a violation of MongoDB limits on field names, so i 
>>> need to convert to something else and then convert back. So I thought I 
>>> would convert to * or !. Converting is no problem, but converting back is 
>>> not working. I walk the deeply nested JSON objects with: 
>>> 
>>> (defn walk-deep-structure [next-item function-to-transform-values]
>>>   (walk/postwalk
>>>(fn [%]
>>>  (if (and (vector? %) (= (count %) 2) (keyword? (first %)))
>>>[(function-to-transform-values %) (second %)]
>>>%))
>>>next-item))
>>> 
>>> which I call like: 
>>> 
>>> results (walk-deep-structure @future-data-return (fn [%] 
>>> (st/replace (name (first %)) #"\*" "$")))]
>>> 
>>> which doesn't work. 
>>> 
>>> I switch to the repl to test this:
>>> 
>>> => (def f  (fn [%] (st/replace (name (first %)) #"!" "$")))
>>> 
>>> => (f [:!!username "michael"])
>>> 
>>>  StringIndexOutOfBoundsException String index out of range: 1  
>>> java.lang.String.charAt (String.java:695)
>>> 
>>> or: 
>>> 
>>> =>  (def f  (fn [%] (st/replace (name (first %)) #"\*" "$")))
>>> 
>>> => (f [:**username "michael"])
>>> 
>>>  StringIndexOutOfBoundsException String index out of range: 1  
>>> java.lang.String.charAt (String.java:695)
>>> 
>>> What am I doing wrong? 
>> 
>> 
>> If you use a regex as the second parameter of clojure.string/replace, then a 
>> $ character followed by a number in the third argument is interpreted as a 
>> reference to a captured sub-sequence in the regex ($0, $1, etc.). In your 
>> case the $ is not followed by a number as expected, which leads to the 
>> exception. To use a literal $ you have to escape it by preceding with a \ 
>> (which has to be escaped itself!), or by using re-quote-replacement:
>> 
>> user=> (clojure.string/replace "**username" #"\*" "\\$")
>> "$$username"
>> user=> (clojure.string/replace "**username" #"\*" 
>> (clojure.string/re-quote-replacement "$"))
>> "$$username"
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] www.core-async.info: a new web resource for core.async

[Daniel Compton]

http://www.core-async.info doesn't load for me in Safari 8.0 (Yosemite), it
just sits at "Get going with core.async Please wait, loading page…". It
loads fine in Chrome on the same machine, and I couldn't see anything
obviously wrong in the console.

On 21 September 2014 03:21, Daniel Solano Gómez  wrote:

> On Fri Sep 19 13:14 2014, Wilker wrote:
> > One suggestion, on the menus, like on this page:
> > http://www.core-async.info/reference
> >
> > Set the cursor for "pointer" on those root menu elements, so the users
> know
> > that it's supposed to be clickable, I took a few to realize because of
> the
> > missing pointer arrow, hehe.
> >
> > Also, I find it a kind hard to navigate, on the first page you have to go
> > all the way on a small link to continue to the next step, would be nice
> to
> > have a general full index (like a book) and consistent buttons to
> navigate
> > back/forward.
> >
> > Besides that, nice job, thanks for taking the effort to make it :)
>
> Thanks for the suggestions.  I'll definitely implement the arrow
> pointer.  The front page definitely needs a bit of work.  Currently,
> it's a bit more oriented for workshop use, but it doesn't work as well
> as a web resource.
>
> Again, i appreciate the feedback.  Thanks!
>
> Sincerely,
>
> Daniel
>
> >
> > ---
> > Wilker Lúcio
> > http://about.me/wilkerlucio/bio
> > Woboinc Consultant
> > +55 81 82556600
> >
> > On Thu, Sep 18, 2014 at 5:22 PM, Daniel Solano Gómez <
> cloj...@sattvik.com>
> > wrote:
> >
> > > On Thu Sep 18 12:14 2014, Ashton Kemerling wrote:
> > > > That looks really nice! My only feedback is that it doesn't load at
> all
> > > on my iPhone.
> > >
> > > Thanks for the information.  I haven't yet taken the time to make it
> > > entirely mobile-friendly, but it is however on my list of things to do.
> > >
> > > Sincerely,
> > >
> > > Daniel
> > >
> > >
> > >
> > >
> > > >
> > > > On Thu, Sep 18, 2014 at 1:01 PM, Daniel Solano Gómez <
> > > cloj...@sattvik.com>
> > > > wrote:
> > > >
> > > > > Hello, all,
> > > > > Over the past few months I have been working on creating some
> resources
> > > > > to help people learn to use core.async.  My goal is make this the
> best
> > > > > resource available to help people get started with core.async and
> to
> > > > > document best practices for composing applications with core.async.
> > > > > It is still a work in progress, but it currently includes the
> > > following:
> > > > > 1. An introduction to channels, buffers, and basic channel
> operations
> > > > > 2. A tutorial/workshop that introduces core.async using both
> Clojure
> > > and
> > > > >ClojureScript
> > > > > 3. A reference section of the core.async API, including both the
> > > > >Clojure and ClojureScript sources
> > > > > Please check it out at .
> > > > > I will continue to add more reference and tutorial material in the
> > > > > future.  Please let me know if there is anything you would think
> would
> > > > > be useful to add.
> > > > > Thanks,
> > > > > Daniel
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "Clojure" group.
> > > > > To post to this group, send email to clojure@googlegroups.com
> > > > > Note that posts from new members are moderated - please be patient
> > > with your first post.
> > > > > To unsubscribe from this group, send email to
> > > > > clojure+unsubscr...@googlegroups.com
> > > > > For more options, visit this group at
> > > > > http://groups.google.com/group/clojure?hl=en
> > > > > ---
> > > > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > > > To unsubscribe from this group and stop receiving emails from it,
> send
> > > an email to clojure+unsubscr...@googlegroups.com.
> > > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Clojure" group.
> > > > To post to this group, send email to clojure@googlegroups.com
> > > > Note that posts from new members are moderated - please be patient
> with
> > > your first post.
> > > > To unsubscribe from this group, send email to
> > > > clojure+unsubscr...@googlegroups.com
> > > > For more options, visit this group at
> > > > http://groups.google.com/group/clojure?hl=en
> > > > ---
> > > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
> send
> > > an email to clojure+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > > your first post.
> > > To unsubscribe from this gro

Re: [ANN] Amazonica: Clojure client for the entire AWS api

[Daniel Compton]

Regarding releases, the lein release function gives you good defaults for 
releasing Clojure projects, it handles tagging, commit messages, and 
versioning. 
https://github.com/technomancy/leiningen/blob/master/doc/DEPLOY.md#releasing-simplified
 has details. 

--
Daniel

> On 21/11/2014, at 1:08 pm, Michael Cohen  wrote:
> 
> Hi Greg,
> 
> I think all of your criticisms are very valid, and I think I've seen
> most of them voiced by others at various times. I wrote it in about 3
> weeks in March of 2013, when I was very new to Clojure, so I'm sure I
> made lots of mistakes. I was using some Java with AWS and some
> Clojure, with James Weaver's rotary library, and when you look at the
> Javadocs, it almost seems like the Java SDK could be generated. So
> that leads one to thinkand off I went.
> 
> As far as the problem areas you identified:
> 
> - shitty docs
> What can I say, guilty as charged. Sorry. I tried to do a decent job
> with the examples, although I laughed when I heard Stu Halloway slag
> off "documentation by example" in some tech talk. Oops. What else
> could I do? I looked at trying to generate some more codox type docs
> from the Java SDK, but I just wasn't going to endure that pain. So,
> yeah, I hear you. It's a trade off though. I'm sure there's a few
> folks out there that would have to use Java interop and the Java SDK
> (and pour through those same Javadocs) in order to use one of the less
> popular AWS services if Amazonica didn't exist, because nothing else
> would exist in the Clojure world for that particular AWS service. Man,
> when I wrote this I don't even think there was a decent Clojure lib
> for ec2.
> 
> - dynamically generated api
> Yeah, the code is not as straightforward and reflection is expensive.
> The counterpoint to that I guess would be, once you have it well
> sorted, you don't really need to edit core.clj too much. And with most
> of the AWS api, the cost of reflection is negligible compared to the
> network hop. You're also probably not that concerned with latency at
> all for those use cases. But again, it's a trade off. Buy one get 20
> was worth a little reflection to me.
> 
> - Functions are both variadic and dispatch on argument type
> Again, guilty as charged. I would do things differently today.
> 
> - There are no releases or tags on github
> Again, I didn't really know what I was doing here, and never really
> changed the approach. What do people expect, a snapshot release for
> current development, and periodic version bumps and releases (less
> frequently than Amazonica currently bumps the version numer)?
> 
> Mike
> 
> 
>> On 11/20/14, Greg Mitchell  wrote:
>> Thanks for creating this library, Michael. Your solutions for writing the
>> library are creative for sure, and this library has helped with developing
>> with AWS. However, I've been using the amazonica library to communicate
>> with AWS components in an enterprise-scale project for about a year now,
>> and I've come to believe that some of the design choices in the library and
>> 
>> its maintenance are big anti-patterns. All of these are things I've
>> struggled with in developing against Amazonica:
>> 
>> * The documentation is sparse and the code is not self-documenting.
>> Clojure in general tends to have worse and less documentation than Java.
>> This is usually mitigated in well-designed Clojure libraries by being able
>> to break into the source and read short, comprehensible functions with
>> descriptive names. Amazonica is in the worst of both worlds by having no
>> documentation in source, sparse documentation on github, and using
>> dynamically generated code. Specific improvements to documentation I'd love
>> 
>> to see: a comprehensive list of keys that credential maps and functions
>> take as well as their valid values. The one or two examples per API on
>> Github are insufficient for different combinations of functionality in
>> real-world use cases. Pointing to AWS javadoc is not sufficient because
>> Amazonica does name-munging and unwrapping - in order to understand the
>> Amazonica input/output, you have to be an expert with the library and look
>> at the implementation for name-munging. It is effectively a new API. A
>> comprehensive list of functions would be nice, but finding them at the repl
>> 
>> is a reasonable work around.
>> 
>> * Dynamically generating an API doesn't save anyone time
>> This is an extension of the previous point. You have almost 800 lines of
>> code, mostly dedicated to reflection and interning methods. It's impressive
>> 
>> that the whole thing works as well as it does, but doesn't actually save
>> time vs. explicitly targeting an API with small wrapper functions. That has
>> 
>> the benefit of being very obvious and easy to understand (as described
>> above). It does mean you have to do some work when the Java SDK changes or
>> you add a client, but I see there is already some nasty logic to switch on
>> the client class if it has a differen

Re: [ANN] Amazonica: Clojure client for the entire AWS api

[Daniel Compton]

There is already a default release script included with recent versions of 
Leiningen. To do a release, simply run lein release :major, :minor, or :patch 
depending on the version bump that you want.

--
Daniel

> On 23/11/2014, at 1:06 pm, Sam Ritchie  wrote:
> 
> If you guys feel strongly, I'm sure the Amazonica maintainers would love a 
> pull req that adds a small release script that handles this for them. I'm 
> sure it'd get merged, and it'd be a nice, constructive way to move the 
> discussion forward.
> 
>> Gary Verhaegen  November 20, 2014 at 
>> 7:58 PM
>> On Thursday, 20 November 2014, Michael Cohen  wrote:
>> 
>> No idea about the rest, but for the github part I usually expect a tag for 
>> each release on Clojars, so if I want to read the actual code of the release 
>> I'm using it is easy to find it.
>> 
>> This should have a very minimal impact on your workflow: it should be 
>> limited to running git tag  once right after each release 
>> (or before; point is, if the unit of time is the git commit, it should be 
>> simultaneous).
>> 
>> Note that it is possible that you have created these tags and they are 
>> simply not on github because git does not push tags by default. You have to 
>> run git push --tags to push them.
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> Michael Cohen   November 20, 2014 at 
>> 5:08 PM
>> Hi Greg,
>> 
>> I think all of your criticisms are very valid, and I think I've seen
>> most of them voiced by others at various times. I wrote it in about 3
>> weeks in March of 2013, when I was very new to Clojure, so I'm sure I
>> made lots of mistakes. I was using some Java with AWS and some
>> Clojure, with James Weaver's rotary library, and when you look at the
>> Javadocs, it almost seems like the Java SDK could be generated. So
>> that leads one to thinkand off I went.
>> 
>> As far as the problem areas you identified:
>> 
>> - shitty docs
>> What can I say, guilty as charged. Sorry. I tried to do a decent job
>> with the examples, although I laughed when I heard Stu Halloway slag
>> off "documentation by example" in some tech talk. Oops. What else
>> could I do? I looked at trying to generate some more codox type docs
>> from the Java SDK, but I just wasn't going to endure that pain. So,
>> yeah, I hear you. It's a trade off though. I'm sure there's a few
>> folks out there that would have to use Java interop and the Java SDK
>> (and pour through those same Javadocs) in order to use one of the less
>> popular AWS services if Amazonica didn't exist, because nothing else
>> would exist in the Clojure world for that particular AWS service. Man,
>> when I wrote this I don't even think there was a decent Clojure lib
>> for ec2.
>> 
>> - dynamically generated api
>> Yeah, the code is not as straightforward and reflection is expensive.
>> The counterpoint to that I guess would be, once you have it well
>> sorted, you don't really need to edit core.clj too much. And with most
>> of the AWS api, the cost of reflection is negligible compared to the
>> network hop. You're also probably not that concerned with latency at
>> all for those use cases. But again, it's a trade off. Buy one get 20
>> was worth a little reflection to me.
>> 
>> - Functions are both variadic and dispatch on argument type
>> Again, guilty as charged. I would do things differently today.
>> 
>> - There are no releases or tags on github
>> Again, I didn't really know what I was doing here, and never really
>> changed the approach. What do people expect, a snapshot release for
>> current development, and periodic version bumps and releases (less
>> frequently than Amazonica currently bumps the version numer)?
>> 
>> Mike
>> 
>> 
>> Greg Mitchell   November 20, 2014 at 
>> 1:32 PM
>> Thanks for creating this library, Michael. Your solutions for writing the 
>> library are creative for sure, and this library has helped with developing 
>> with AWS. However, I've been using the amazonica library to communicate with 
>> AWS components in an enterprise-scale project for about a year now, and I've 
>> come to believe that some of the design choices in the library and its 
>> maintenance are big anti-patterns. All of these are things I've struggled 
>> with in developing against Amazonica:
>> 
>> * The d

Clojurists Together wants to fund you to work on your open source Clojure project from August-October 2020

[Daniel Compton]

Hi folks

Clojurists Together  is about to award
another round of funding to support open source Clojure projects. *Applications
 close on Tuesday 28th
July.*

Clojurists Together is an organisation, dedicated to funding and supporting
open source software, infrastructure, and documentation that is important
to the Clojure and ClojureScript community.

*We plan to fund three projects at $3,000 USD/month for 3 months ($9,000
USD total).*

Previously we have supported projects
 like Neanderthal, Aleph,
Fireplace, cljdoc, Shadow CLJS, CIDER, Figwheel, clj-http and several more.

We encourage open source maintainers to apply
 for funding, especially
if you work on one of the projects or areas that our members highlighted in
the survey.

If you work at a company that uses Clojure, talk to your engineering
manager about supporting Clojurists Together. We've been able to support
projects thanks to the generosity of our developer and company members
. The more support we have,
the more that we can do to improve things for the entire Clojure community.

Thanks, Daniel.

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

Clojurists Together board elections - we want you to stand for election!

[Daniel Compton]

Hi folks

Clojurists Together is having board elections

to elect four new board members. We'd like you to consider standing for
election.

Anyone can stand for election, not just Clojurists Together members,
although Clojurists Together members are definitely encouraged to stand for
election. You don’t need to be an experienced Clojure dev to apply, we’re
looking for people from a wide range of backgrounds and skill levels.

You'll have a big impact on the Clojure community and help steer where
Clojurists Together puts our funds and our focus.

Nominations close March 31st and voting will close on April 28th. All
current Clojurists Together members will be eligible to vote.

Let me know if you have any questions either here, off-list, or in
#cljtogether on the Clojurians Slack.

Thanks, Daniel.

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

Clojurists Together Open Source Community Survey

[Daniel Compton]

Hi folks

Clojurists Together is surveying the open source Clojure community. We want 
to hear how we can best serve the needs of open source Clojure developers.

If you write OSS Clojure, please look at filling out this survey with your 
thoughts. The more people we can hear from, the better our decision making 
will be.

https://www.clojuriststogether.org/news/listening-to-maintainers-for-the-next-phase-of-clojurists-together/

Clojurists Together members are welcome to fill out this survey, they'll 
also get a private link to a members survey too.

Thanks, Daniel.

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

Clojurists Together funding applications are open for Q3 2020

[Daniel Compton]

Hi folks

You know the drill, Clojurists Together  
is funding open source Clojure tools, libraries, and documentation. 
Applications are open until 6th August, 2021, midnight PST.

Our members would like us 
 to focus 
on developer tools, so if you work on Clojure developer tools, please apply 
!

There's a few changes this time around. You can see the full details on the 
announcement 
,
 
but briefly:

   - People now apply for $1k/$2k experimental/small projects, or $9k 
   larger projects
   - Funding can now be taken over 1-12 months, instead of only over 3 
   months
   - You have 2 months to start after you get selected to give you time to 
   prepare

We're also doing a new type of long-term funding where our members will 
vote on developers to receive $1.5k/month for 12 months. The recipients 
won't have any specific requirements, they'll just keep doing the great 
work they're already doing.

We currently have the funds to support 3 developers for long-term 
fellowships, but we'd like to get to 6. To do so we’ll need new developer 
and company members to help support this. If you’re a company that relies 
on Clojure, please consider joining Clojurists Together.

Thanks, Daniel.

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

Re: [ClojureScript] Re: ANN: ClojureScript 1.9.14, clojure.spec port

[Daniel Compton]

Would it be good to change the namespace for spec from cljs.spec to
clojure.spec? This will make CLJC files nicer to write as you won’t need to
have reader conditionals for requiring cljs.spec in CLJS and clojure.spec
in CLJ.

It seems like spec is going to be used by lots of projects, so the choices
made now will affect lots of code, and be hard to change later.

More generally, what are the guidelines for deciding if a ClojureScript
file gets written as cljs.* or clojure.*?

On Thu, Jun 2, 2016 at 9:19 AM Walter van der Laan <
waltervanderl...@fincite.nl> wrote:

> It's like magic. I added some specs to cljc namespaces and it just works!
>
> I'm making domain specific error messages with just a few lines of code.
> This is a huge leap forward.
>
> Thank you, and all involved, so much.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>
-- 
—
Daniel

-- 
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: cljsbuild hangs with foreign-libs using letsencrypt

[Daniel Compton]

AFAICT cljsbuild doesn’t do anything special with the :foreign-libs key and
passes it straight to the compiler. Can you reproduce this issue against
the bare ClojureScript compiler?

On Tue, Jun 14, 2016 at 4:58 AM Elric Erkose  wrote:

> Recently I switched my local cdn from http to https with letsencrypt. I
> had to provide a trust store ( :jvm-opts ["-Djavax.net.ssl.trustStore=...)
> because java won't support letsencrypt until "JDK 8u102 is scheduled to be
> released in July 2016". After changing the protocol from "http" to "https"
> and adding the "jvm-opts" to my project.clj, lein cljsbuild auto hangs. I
> verified it fetches the foreign-libs. Also, if I change the foreign-libs
> protocol to "file" everything works. Has anyone experienced 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.
>
-- 
—
Daniel

-- 
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] cljsee 0.1.0

[Daniel Compton]

Awesome work Alex. If you wanted, you could add a PR to update
http://clojure.org/guides/reader_conditionals#_backwards_compatibility with
your plugin?

On Wed, Jun 15, 2016 at 1:24 AM Herwig Hochleitner 
wrote:

> +1 thanks for releasing that.
>
> I've been thinking about doing this also as a maven plugin. That might
> help finally getting .cljc accepted in contrib projects.
> ​
>
> --
> 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.
>
-- 
—
Daniel

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

[Daniel Compton]

Bumping this too. What was the context for this change? I don’t see any
JIRA tickets linked in the commits

with
a rationale for why 8 was picked as the thread pool size. This has the
potential for breaking or reducing efficiency for apps that were relying on
the 42 + 2 * cores behaviour. I’m happy that this is now configurable, but
puzzled as to why the default wasn’t kept as 42 + 2 * cores?

Also, because this needs to be passed as a java property, if we want our
applications to be able to handle differing core counts (e.g. running on
heterogenous servers) it seems like we will need to write a bash script to
calculate our threadpool size before starting up.

Perhaps I’m missing something really obvious here, if so, please let me
know :)

Tim Ewald, can you help with this?

On Tue, Jun 14, 2016 at 9:10 AM Fluid Dynamics  wrote:

> On Monday, June 13, 2016 at 4:14:25 PM UTC-4, Alex Miller wrote:
>>
>> core.async 0.2.382 is now available.
>>
>> Try it via:  [org.clojure/core.async "0.2.382"]
>>
>> 0.2.382 includes the following changes:
>>
>> - Change default dispatch thread pool max size to 8.
>> - Add Java system property clojure.core.async.pool-size to override the
>> dispatch thread pool max size
>>
>
> Why 8, rather than, say, (.availableProcessors (Runtime/getRuntime))?
>
> --
> 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.
>
-- 
—
Daniel

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

[Daniel Compton]

I knew I must be missing something. You can also set the core.async
threadpool size with

(System/setProperty "clojure.core.async.pool-size" "42")

as long as that runs before any core.async code tries to use the
threadpool. Some context on why the change was made to 8 would be good, but
it is easy to set this value yourself.

On Thu, Jun 23, 2016 at 9:13 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Bumping this too. What was the context for this change? I don’t see any
> JIRA tickets linked in the commits
> <https://github.com/clojure/core.async/compare/07e70e47a0d2f3f6b606fe2ed3a993b83cf2c29f...503b597a46a49f7d86cfb9afbe1d92798de8e2fa>
>  with
> a rationale for why 8 was picked as the thread pool size. This has the
> potential for breaking or reducing efficiency for apps that were relying on
> the 42 + 2 * cores behaviour. I’m happy that this is now configurable, but
> puzzled as to why the default wasn’t kept as 42 + 2 * cores?
>
> Also, because this needs to be passed as a java property, if we want our
> applications to be able to handle differing core counts (e.g. running on
> heterogenous servers) it seems like we will need to write a bash script to
> calculate our threadpool size before starting up.
>
> Perhaps I’m missing something really obvious here, if so, please let me
> know :)
>
> Tim Ewald, can you help with this?
>
> On Tue, Jun 14, 2016 at 9:10 AM Fluid Dynamics  wrote:
>
>> On Monday, June 13, 2016 at 4:14:25 PM UTC-4, Alex Miller wrote:
>>>
>>> core.async 0.2.382 is now available.
>>>
>>> Try it via:  [org.clojure/core.async "0.2.382"]
>>>
>>> 0.2.382 includes the following changes:
>>>
>>> - Change default dispatch thread pool max size to 8.
>>> - Add Java system property clojure.core.async.pool-size to override the
>>> dispatch thread pool max size
>>>
>>
>> Why 8, rather than, say, (.availableProcessors (Runtime/getRuntime))?
>>
>> --
>> 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.
>>
> --
> —
> Daniel
>
-- 
—
Daniel

-- 
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 there a way to use drip to speed up the running of unit tests?

[Daniel Compton]

I would recommend looking at bolth . It’s
an extremely fast test runner, has nice stacktraces, diffs, e.t.c.

On Mon, Jun 27, 2016 at 6:28 AM Alan Thompson  wrote:

> I also highly recommend test-refersh!
> Alan
>
> On Sat, Jun 25, 2016 at 8:47 AM, Jake McCrary 
> wrote:
>
>> Hi Fenton,
>>
>> In my experience the way to get faster feedback from your tests is to
>> have them run in a way that doesn’t require stopping and starting a
>> process. This can be done by either evaluating your tests in a REPL or
>> using one of the Clojure testing tools that reload your code and run your
>> tests on changes. My preference is using a tool to manage reloading my code
>> and rerunning my tests.
>>
>> If you’re using clojure.test there are a few such tools but I’ll
>> recommend lein-test-refresh
>>  (I’m biased given that it
>> is the one I wrote). If you scroll to the bottom of this article
>> 
>> you’ll see my recommended settings for turning on some of
>> lein-test-refresh's advanced settings. Some more information can be found
>> in this
>> 
>> Clojure mailing list message.
>>
>> If you’re using expectations 
>> then there is also lein-autoexpect
>>  for running your tests on
>> code change. Midje and speclj have their own autotest runners.
>>
>> On Thursday, June 23, 2016 at 4:13:34 PM UTC-5, Fenton Travers wrote:
>>
>> is there a way to use drip to speed up the running of unit tests?
>>>
>>> I'm not sure if there is way to use drip to speed up the launching and
>>> running of tests, but that would be great if there was.
>>>
>> ​
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
—
Daniel

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

[Daniel Compton]

I know these were just changed from map-of and coll-of, but the names every
and every-kv seem a little confusing. every and every-kv only sample from
collections, whereas the name implies that everything in the collection is
checked. Additionally, there is an every? in clojure.core which does check
a predicate for every value in the collection.

I (loosely) suggest sample and sample-kv as other names, but am not 100%
sure I like them.

Thoughts?

On Wed, Jun 29, 2016 at 10:13 AM Alex Miller  wrote:

> Clojure 1.9.0-alpha8 is now available.
>
> Try it via
>
> - Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha8
> - Dependency: [org.clojure/clojure "1.9.0-alpha8"]
>
> 1.9.0-alpha8 includes the following changes since 1.9.0-alpha7:
>
> The collection spec support has been greatly enhanced, with new controls
> for conforming, generation, counts, distinct elements and collection kinds.
> See the docs for every, every-kv, coll-of and map-of for details.
>
> instrumenting and testing has been streamlined and made more composable,
> with powerful new features for spec and gen overrides, stubbing, and
> mocking. See the docs for these functions in clojure.spec.test: instrument,
> test, enumerate-ns and summarize-results.
>
> Namespaced keyword reader format, printing and destructuring have been
> enhanced for lifting namespaces up for keys, supporting more succinct use
> of fully-qualified keywords. Updated docs will be added to clojure.org
> soon.
>
> Many utilities have been added, for keys spec merging, fn exercising, Java
> 1.8 timestamps, bounded-count and more.
>
> Changelog:
>
> clojure.spec:
>
> - [changed] map-of - now conforms all values and optionally all keys, has
> additional kind, count, gen options
> - [changed] coll-of - now conforms all elements, has additional kind,
> count, gen options. No longer takes init-coll param.
> - [added] every - validates a collection by sampling, with many additional
> options
> - [added] every-kv - validates a map by sampling, with many additional
> options
> - [added] merge
> - [changed] gen overrides can now be specified by either name or path
> - [changed] fspec generator - creates a function that generates return
> values according to the :ret spec and ignores :fn spec
> - [added] explain-out - produces an explain output string from an
> explain-data result
> - [changed] explain-data - output is now a vector of problems with a :path
> element, not a map keyed by path
> - [added] get-spec - for looking up a spec in the registry by keyword or
> symbol
> - [removed] fn-spec - see get-spec
> - [added] exercise-fn - given a spec'ed function, returns generated args
> and the return value
> - All instrument functions moved to clojure.spec.test
>
> clojure.spec.test:
>
> - [changed] instrument - previously took a var, now takes either a symbol,
> namespace symbol, or a collection of symbols or namespaces, plus many new
> options for stubbing or mocking. Check the docstring for more info.
> - [removed] instrument-ns - see instrument
> - [removed] instrument-all - see instrument
> - [changed] unstrument - previously took a var, now takes a symbol,
> namespace symbol, or collection of symbol or namespaces
> - [removed] unstrument-ns - see unstrument
> - [removed] unstrument-all - see unstrument
> - [added] instrumentable-syms - syms that can be instrumented
> - [added] with-instrument-disabled - disable instrument's checking of
> calls within a scope
> - [changed] check-var renamed to test and has a different signature, check
> docs
> - [changed] run-tests - see test
> - [changed] run-all-tests - see test
> - [changed] check-fn - renamed to test-fn
> - [added] abbrev-result - returns a briefer description of a test
> - [added] summarize-result - returns a summary of many tests
> - [added] testable-syms - syms that can be tested
> - [added] enumerate-namespace - provides symbols for vars in namespaces
>
> clojure.core:
>
> - [changed] - inst-ms now works with java.time.Instant instances when
> Clojure is used with Java 8
> - [added] bounded-count - if coll is counted? returns its count, else
> counts at most first n elements of coll using its seq
>
> --
> 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.
>
-- 
—
Daniel

-- 
You received this message because you are subscribed to the Google
Groups "Cloj

Re: Rationale for `keys` not supporting vectors?

[Daniel Compton]

keys is implemented here

against
the abstract class APersistentMap. That it doesn’t work against vectors is
an implementation detail, but I could imagine that the reason it was done
this way was a design choice.

On Sat, Jul 9, 2016 at 4:50 PM Michael Gardner  wrote:

> I've looked around, but couldn't find any discussion on the topic. Is it
> purely an implementation thing, or a design choice?
>
> (Yes, I realize you can just do (range (count v)).)
>
> --
> 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.
>
-- 
—
Daniel

-- 
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 it possible / is support planned to add docstrings to clojure.spec specs?

[Daniel Compton]

There’s a ticket for this at http://dev.clojure.org/jira/browse/CLJ-1965 if
you want to vote/watch/comment.

On Wed, Jul 13, 2016 at 8:07 AM Nils Grunwald 
wrote:

> I would find this very interesting, especially for generating easily
> shareable documentation...
>
>
> Nils
>
>
> On Thursday, June 2, 2016 at 8:39:12 AM UTC+2, Russell wrote:
>>
>> Just been trying out clojure.spec for the first time, looks really nice.
>> It would be good to be able to do something like the following:
>>
>> (clojure.spec/def
>>   "The name of the stage, which API Gateway uses as the first path
>> segment in the invoke Uniform Resource Identifier (URI)."
>>   :aws.apigateway.stage/StageName string?)
>>
>> ...so useful information not expressible in the spec itself can be
>> included in a docstring so that it can be picked up by tooling,
>> clojure.repl/doc etc. From what I can see of the code it doesn't look
>> like this is currently possible: is this something that is likely to be
>> added?
>>
>> Thanks,
>>
>> Russell
>>
> --
> 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.
>
-- 
—
Daniel

-- 
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: The REPL, a weekly Clojure/Script newsletter

[Daniel Compton]

Hi folks

I’ve started a weekly Clojure and ClojureScript newsletter called The REPL.
It covers what’s new (and old) in Clojure, as well as related topics (Lisp,
JVM, e.t.c.).

You can sign up at http://therepl.net, and see a copy of the latest issue
here

.

Thanks, Daniel.
-- 
—
Daniel

-- 
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: Obtaining the call graph of a clojure project

[Daniel Compton]

This is a slightly adjacent issue, but you can see namespace usage ordering
with lein-ns-dep-graph .

On Thu, Jul 28, 2016 at 11:42 AM Gary Fredericks 
wrote:

> I have a very hacky bunch of code here
> 
> that uses tools.analyzer to try to do this. It works okay and I would love
> for somebody to make it better.
>
>
> On Wednesday, July 27, 2016 at 5:51:03 PM UTC-5, Matan Safriel wrote:
>>
>> Hi,
>>
>> Is it possible to get information about the call graph of a project from
>> the clojure compiler?
>> For example in Scala, one can use a compiler plugin, to tap into the AST.
>> This in turn permits deriving more or less the entire call graph of the
>> project, directly through the compiler, rather than by picking inside the
>> byte code produced by the compiler.
>>
>> What can be said about this aspect in Clojure?
>>
>> Thanks!
>> Matan
>>
> --
> 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.
>
-- 
—
Daniel

-- 
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 this behavior of clojure.core/pr a bug?

[Daniel Compton]

> Can anyone think of a good reason why pr should *not* throw an exception
on
> (pr (keyword “foo bar"))
> since there’s no way of expressing that keyword as valid EDN?

This would break backwards compatibility, something Clojure rarely does.

On Thu, Aug 4, 2016 at 1:16 PM Blake Miller  wrote:

> Er, I mean "built-in reader macro dispatch".
>
>
> On Thursday, August 4, 2016 at 1:14:16 AM UTC, Blake Miller wrote:
>>
>> You're right, Dan. Having mulled it over a little more, it's not clear to
>> me why there ought to be any pure Clojure data (no Java objects) that
>> cannot be serialized as EDN. Emitting a #keyword reader literal for this
>> edge case would make sense to me.
>>
> --
> 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.
>
-- 
—
Daniel

-- 
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: Multi-OS Engine | Intel(R) Software

[Daniel Compton]

I had a look at this a few weeks ago, and it seemed like it would only work
with Java code, not JVM bytecode?

Internal Overview:

Multi-OS Engine facilitates Java* support on iOS* through

   - Auto Java binding generation from ObjectiveC and C header files from
   existing libraries or 3rd party packages
   - Java* annotations and NatJ* runtime library
   - Eliminating the need to write JNI functions
   - Prebuilt jar files interfacing iOS* API are provided in the Multi-OS
   Engine, so you can start coding iOS* app in Java* immediately.

I looked around and couldn’t find any lower level details of what they were
doing, but all of the documentation seems to suggest you need to write
Java. I’d be very happy to be proven wrong though :)

On Sat, Aug 6, 2016 at 7:47 AM Gregg Reynolds  wrote:

> For those interested in mobile clojure, I just discovered this.  Haven't
> tried it but it sounds good:
>
>
> https://software.intel.com/en-us/multi-os-engine?utm_source=Develop+Blog+http://www.develop-online.net/&utm_medium=Text+Link&utm_campaign=Android_EMEA_Q2-16_Developer-Blog_Blog-Page?29062016
>
> --
> 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.
>
-- 
—
Daniel

-- 
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: Multi-OS Engine | Intel(R) Software

[Daniel Compton]

Following up, it seems like it may be possible to use Clojure with MOSE,
but it doesn’t look like a well worn path. Also, I suspect if you went down
this route you may end up writing mostly Java in a funny domain specific
language with lots of parentheses. All that being said, I’d be happy to be
proven wrong :)

https://groups.google.com/forum/#!topic/robovm/b3jbTcpq1Xo
https://software.intel.com/en-us/forums/multi-os-engine/topic/640308
https://github.com/moe-java-samples/moe-kotlin-samples


On Wed, Aug 10, 2016 at 8:09 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> I had a look at this a few weeks ago, and it seemed like it would only
> work with Java code, not JVM bytecode?
>
> Internal Overview:
>
> Multi-OS Engine facilitates Java* support on iOS* through
>
>- Auto Java binding generation from ObjectiveC and C header files from
>existing libraries or 3rd party packages
>- Java* annotations and NatJ* runtime library
>- Eliminating the need to write JNI functions
>- Prebuilt jar files interfacing iOS* API are provided in the Multi-OS
>Engine, so you can start coding iOS* app in Java* immediately.
>
> I looked around and couldn’t find any lower level details of what they
> were doing, but all of the documentation seems to suggest you need to write
> Java. I’d be very happy to be proven wrong though :)
>
> On Sat, Aug 6, 2016 at 7:47 AM Gregg Reynolds  wrote:
>
>> For those interested in mobile clojure, I just discovered this.  Haven't
>> tried it but it sounds good:
>>
>>
>> https://software.intel.com/en-us/multi-os-engine?utm_source=Develop+Blog+http://www.develop-online.net/&utm_medium=Text+Link&utm_campaign=Android_EMEA_Q2-16_Developer-Blog_Blog-Page?29062016
>>
>> --
>> 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.
>>
> --
> —
> Daniel
>
-- 
—
Daniel

-- 
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] beta.clojars.org: new Clojars infrastructure that needs testing

[Daniel Compton]

Hi folks

We’re moving the Clojars infrastructure from Linode to the very kind folks
at Rackspace. We’re getting close, and have a test server setup at
beta.clojars.org. It has a copy of the live database as of a day ago, and
is mirroring JARs from the live server. We’ve done testing of what we can,
and everything looks ok, but there may be something we’ve missed.

*N.B.* All state on this server is temporary and will be wiped at the end
of the testing period. Make sure to do any real deploys to clojars.org

*What we need from you:*
We need testing from people running different setups, to make sure this
isn’t going to break things for you. If you’re running any kind of unusual
setup (OS, JDK, environment, network), we especially need you to test it.
To test this, follow the instructions at Mirrors
:

In a nutshell, update your ~/.lein/profiles.clj to have this:

:user {:repositories [["clojars" {:url "https://beta.clojars.org/repo/"}]]
   ;; deploy-repositories is optional
   :deploy-repositories [["clojars" {:url
"https://beta.clojars.org"; :username :gpg :password :gpg}]]

   ;; other :user profile settings...
   }


(You can always see the canonical Clojars mirrors at
https://github.com/clojars/clojars-web/blob/master/MIRRORS)

If you have issues, either reply to this email, or open an issue on GitHub
.

This is the first in a series of infrastructure enhancements coming over
the next few months to improve the speed, stability, and security of
Clojars.

A special thanks goes to all of the people supporting Clojars at
Bountysource , we really
appreciate your support.

Thanks,

Your friendly neighbourhood Clojars caretakers.
Toby and Daniel.
-- 
—
Daniel

-- 
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] beta.clojars.org: new Clojars infrastructure that needs testing

[Daniel Compton]

>
> Thanks, sounds like a lot of work. Any particular reasons for the switch?
>
> Yep it was :)

One more reason for moving is that we’re not comfortable with Linode’s
security.
-- 
—
Daniel

-- 
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] [ANN] beta.clojars.org: new Clojars infrastructure that needs testing

[Daniel Compton]

Hi Andy

Good spotting, thanks!

We needed to regenerate the Lucene search index. Normally it is updated
incrementally, so there was no Ansible automation to rebuild it. I’m
rebuilding the index now, it should be updated soon.

Thanks!

On Fri, Sep 23, 2016 at 3:14 AM Andy Fingerhut 
wrote:

> Should searches for packages give results on beta.clojars.org ?
>
> I went to the web page and searched for a couple of packages using search
> strings that give results on clojars.org, but give no results on
> beta.clojars.org.
>
> Andy
>
> On Tue, Sep 20, 2016 at 4:17 PM, Daniel Compton <
> daniel.compton.li...@gmail.com> wrote:
>
>> Hi folks
>>
>> We’re moving the Clojars infrastructure from Linode to the very kind
>> folks at Rackspace. We’re getting close, and have a test server setup at
>> beta.clojars.org. It has a copy of the live database as of a day ago,
>> and is mirroring JARs from the live server. We’ve done testing of what we
>> can, and everything looks ok, but there may be something we’ve missed.
>>
>> *N.B.* All state on this server is temporary and will be wiped at the
>> end of the testing period. Make sure to do any real deploys to
>> clojars.org
>>
>> *What we need from you:*
>> We need testing from people running different setups, to make sure this
>> isn’t going to break things for you. If you’re running any kind of unusual
>> setup (OS, JDK, environment, network), we especially need you to test it.
>> To test this, follow the instructions at Mirrors
>> <https://github.com/clojars/clojars-web/wiki/Mirrors>:
>>
>> In a nutshell, update your ~/.lein/profiles.clj to have this:
>>
>> :user {:repositories [["clojars" {:url "https://beta.clojars.org/repo/"}]]
>>;; deploy-repositories is optional
>>:deploy-repositories [["clojars" {:url "https://beta.clojars.org"; 
>> :username :gpg :password :gpg}]]
>>
>>;; other :user profile settings...
>>}
>>
>>
>> (You can always see the canonical Clojars mirrors at
>> https://github.com/clojars/clojars-web/blob/master/MIRRORS)
>>
>> If you have issues, either reply to this email, or open an issue on
>> GitHub <https://github.com/clojars/clojars-server-config/issues/new>.
>>
>> This is the first in a series of infrastructure enhancements coming over
>> the next few months to improve the speed, stability, and security of
>> Clojars.
>>
>> A special thanks goes to all of the people supporting Clojars at
>> Bountysource <https://salt.bountysource.com/teams/clojars>, we really
>> appreciate your support.
>>
>> Thanks,
>>
>> Your friendly neighbourhood Clojars caretakers.
>> Toby and Daniel.
>>
> --
>> —
>> Daniel
>>
>> --
>>
> Note that posts from new members are moderated - please be patient with
>> your first post.
>>
> ---
>> You received this message because you are subscribed to the Google Groups
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescr...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/clojurescript.
>>
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>
-- 

Daniel

-- 
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: Correcting a docstring mistake in clojure.core/filter

[Daniel Compton]

Opening a ticket on dev.clojure.org, and providing a docstring patch is the
standard (and fastest) way to do this.

On Sun, Sep 25, 2016 at 1:15 PM Alan Thompson  wrote:

> Hi Alex - What is the best way to correct a mistake in the docstring for
> clojure.core/filter?
>
> The existing docstring is:
>
> ​​
> Returns a lazy sequence of the items in coll for which
> (pred item) returns true. pred must be free of side-effects.
> Returns a transducer when no collection is provided.
>
> ​I would like to correct it to read:
>
> ​
> Returns a lazy sequence of the items in coll for which
> (pred item)
> ​ ​
> ​
> ​returns a
> truthy
> ​
> value
> (neither false nor nil). pred must be
> free of side-effects.
> ​
> Returns a transducer when no collection is provided.
>
>
> ​The need for this is illustrated by a quick check:
>
> > (filter identity [:a 1 true false nil "done"])
> (:a 1 true "done")
>
>
> Alan
>
> --
> 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.
>
-- 

Daniel

-- 
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] [ANN] beta.clojars.org: new Clojars infrastructure that needs testing

[Daniel Compton]

Hi folks

We have completed migration of the production server (clojars.org) from
Linode to Rackspace. Everything seems to have transferred across smoothly.
Please let us know if you have any issues.

Thanks

On Fri, Sep 23, 2016 at 9:26 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi Andy
>
> Good spotting, thanks!
>
> We needed to regenerate the Lucene search index. Normally it is updated
> incrementally, so there was no Ansible automation to rebuild it. I’m
> rebuilding the index now, it should be updated soon.
>
> Thanks!
>
>
> On Fri, Sep 23, 2016 at 3:14 AM Andy Fingerhut 
> wrote:
>
>> Should searches for packages give results on beta.clojars.org ?
>>
>> I went to the web page and searched for a couple of packages using search
>> strings that give results on clojars.org, but give no results on
>> beta.clojars.org.
>>
>> Andy
>>
>> On Tue, Sep 20, 2016 at 4:17 PM, Daniel Compton <
>> daniel.compton.li...@gmail.com> wrote:
>>
>>> Hi folks
>>>
>>> We’re moving the Clojars infrastructure from Linode to the very kind
>>> folks at Rackspace. We’re getting close, and have a test server setup at
>>> beta.clojars.org. It has a copy of the live database as of a day ago,
>>> and is mirroring JARs from the live server. We’ve done testing of what we
>>> can, and everything looks ok, but there may be something we’ve missed.
>>>
>>> *N.B.* All state on this server is temporary and will be wiped at the
>>> end of the testing period. Make sure to do any real deploys to
>>> clojars.org
>>>
>>> *What we need from you:*
>>> We need testing from people running different setups, to make sure this
>>> isn’t going to break things for you. If you’re running any kind of unusual
>>> setup (OS, JDK, environment, network), we especially need you to test it.
>>> To test this, follow the instructions at Mirrors
>>> <https://github.com/clojars/clojars-web/wiki/Mirrors>:
>>>
>>> In a nutshell, update your ~/.lein/profiles.clj to have this:
>>>
>>> :user {:repositories [["clojars" {:url "https://beta.clojars.org/repo/"}]]
>>>;; deploy-repositories is optional
>>>:deploy-repositories [["clojars" {:url "https://beta.clojars.org"; 
>>> :username :gpg :password :gpg}]]
>>>
>>>;; other :user profile settings...
>>>}
>>>
>>>
>>> (You can always see the canonical Clojars mirrors at
>>> https://github.com/clojars/clojars-web/blob/master/MIRRORS)
>>>
>>> If you have issues, either reply to this email, or open an issue on
>>> GitHub <https://github.com/clojars/clojars-server-config/issues/new>.
>>>
>>> This is the first in a series of infrastructure enhancements coming over
>>> the next few months to improve the speed, stability, and security of
>>> Clojars.
>>>
>>> A special thanks goes to all of the people supporting Clojars at
>>> Bountysource <https://salt.bountysource.com/teams/clojars>, we really
>>> appreciate your support.
>>>
>>> Thanks,
>>>
>>> Your friendly neighbourhood Clojars caretakers.
>>> Toby and Daniel.
>>>
>> --
>>> —
>>> Daniel
>>>
>>> --
>>>
>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>>
>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ClojureScript" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojurescript+unsubscr...@googlegroups.com.
>>> To post to this group, send email to clojurescr...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/clojurescript.
>>>
>>
>> --
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescr...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/clojurescript.
>>
> --
>
> Daniel
>
-- 

Daniel

-- 
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] [ANN] beta.clojars.org: new Clojars infrastructure that needs testing

[Daniel Compton]

Oh, one more thing, a big thanks to lvh <https://www.lvh.io>, and Rackspace
for sponsoring Clojars. We really appreciate it!

On Mon, Sep 26, 2016 at 4:24 PM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> We have completed migration of the production server (clojars.org) from
> Linode to Rackspace. Everything seems to have transferred across smoothly.
> Please let us know if you have any issues.
>
> Thanks
>
> On Fri, Sep 23, 2016 at 9:26 AM Daniel Compton <
> daniel.compton.li...@gmail.com> wrote:
>
>> Hi Andy
>>
>> Good spotting, thanks!
>>
>> We needed to regenerate the Lucene search index. Normally it is updated
>> incrementally, so there was no Ansible automation to rebuild it. I’m
>> rebuilding the index now, it should be updated soon.
>>
>> Thanks!
>>
>>
>> On Fri, Sep 23, 2016 at 3:14 AM Andy Fingerhut 
>> wrote:
>>
>>> Should searches for packages give results on beta.clojars.org ?
>>>
>>> I went to the web page and searched for a couple of packages using
>>> search strings that give results on clojars.org, but give no results on
>>> beta.clojars.org.
>>>
>>> Andy
>>>
>>> On Tue, Sep 20, 2016 at 4:17 PM, Daniel Compton <
>>> daniel.compton.li...@gmail.com> wrote:
>>>
>>>> Hi folks
>>>>
>>>> We’re moving the Clojars infrastructure from Linode to the very kind
>>>> folks at Rackspace. We’re getting close, and have a test server setup at
>>>> beta.clojars.org. It has a copy of the live database as of a day ago,
>>>> and is mirroring JARs from the live server. We’ve done testing of what we
>>>> can, and everything looks ok, but there may be something we’ve missed.
>>>>
>>>> *N.B.* All state on this server is temporary and will be wiped at the
>>>> end of the testing period. Make sure to do any real deploys to
>>>> clojars.org
>>>>
>>>> *What we need from you:*
>>>> We need testing from people running different setups, to make sure this
>>>> isn’t going to break things for you. If you’re running any kind of unusual
>>>> setup (OS, JDK, environment, network), we especially need you to test it.
>>>> To test this, follow the instructions at Mirrors
>>>> <https://github.com/clojars/clojars-web/wiki/Mirrors>:
>>>>
>>>> In a nutshell, update your ~/.lein/profiles.clj to have this:
>>>>
>>>> :user {:repositories [["clojars" {:url "https://beta.clojars.org/repo/"}]]
>>>>;; deploy-repositories is optional
>>>>:deploy-repositories [["clojars" {:url "https://beta.clojars.org"; 
>>>> :username :gpg :password :gpg}]]
>>>>
>>>>;; other :user profile settings...
>>>>}
>>>>
>>>>
>>>> (You can always see the canonical Clojars mirrors at
>>>> https://github.com/clojars/clojars-web/blob/master/MIRRORS)
>>>>
>>>> If you have issues, either reply to this email, or open an issue on
>>>> GitHub <https://github.com/clojars/clojars-server-config/issues/new>.
>>>>
>>>> This is the first in a series of infrastructure enhancements coming
>>>> over the next few months to improve the speed, stability, and security of
>>>> Clojars.
>>>>
>>>> A special thanks goes to all of the people supporting Clojars at
>>>> Bountysource <https://salt.bountysource.com/teams/clojars>, we really
>>>> appreciate your support.
>>>>
>>>> Thanks,
>>>>
>>>> Your friendly neighbourhood Clojars caretakers.
>>>> Toby and Daniel.
>>>>
>>> --
>>>> —
>>>> Daniel
>>>>
>>>> --
>>>>
>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>>
>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ClojureScript" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojurescript+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to clojurescr...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/clojurescript.
>>>>
>>>
>>> --
>>> Note that pos

Re: Clojure + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[Daniel Compton]

Hi Ray

We have a ClojureScript + Electron + Re-Frame application that we run.
Those three work together quite nicely. I’m not totally clear what it would
look like for Clojure + Boot + ProtoRepl to co-exist with the first three?
Can you explain what you’re envisioning some more?

On Wed, Oct 5, 2016 at 11:41 PM Mathias De Wachter <
mathias.dewach...@gmail.com> wrote:

> Hi Ray,
>
> I'm in a pretty much identical situation, except that I'm using re-frame
> for the gui that connects to the websocket the local clojure app provides.
> I haven't gotten as far as you yet, since I haven't yet started the "port"
> of the gui from browser to electron. I also have two code bases, but am
> wondering if the merge makes sense. So, I would be very interested to see
> read about your experience!
>
> --
> 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.
>
-- 

Daniel

-- 
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] Advanced Martian usage

[Daniel Compton]

Nice work Oliy. I especially liked the re-frame section as I work at Day8
on re-frame. I liked what you did with the HTTP handler, much cleaner :)

On Fri, Nov 11, 2016 at 1:15 AM Oliver Hine  wrote:

> Hi Erik,
>
> One of the philosophies of Martian was that it was not a "closed" system
> so that it made no demands on the server, and you can use it with servers
> that aren't yours and can't be changed. What you're describing is very much
> server-side testing, so Martian doesn't help directly there.
>
> However, the description of endpoints using metadata is exactly how
> pedestal-api  works using Schema.
> In pedestal your routes are just a data structure so it would be easy to
> walk them, pull out the schema for the parameters of each handler and
> exercise them using test.check.
> This is quite an interesting idea that would work well for "pure" handlers
> with no side effects, but once you add databases and things to the mix it
> could get trickier.
>
> Let me know if you need any pointers on how to go about this.
>
> Oliy
>
>
>
> On Thursday, 10 November 2016 10:20:01 UTC, Erik Assum wrote:
>
> Hi Oliy,
>
> In some ways this resonates with a thought I’ve had for a while, which
> sort of appeared while working on a spring-boot application in java.
>
> So in Spring-boot, you have classes annotated as controllers, methods
> annotated as request handlers which indicate what params and such they take.
> What I’d like (and which might very well exist, I haven’t researched this
> yet) was a tool that exercised the methods in the controllers, directly
> without involving http.
>
> So given something like this:
>
> @Controller
> public class MyController {
>
>   @RequestMapping(…)
>   public String helloWorld(@RequestParam(“name”) String name) {
> return “Hello “ + name;
>   }
> }
>
> I’d like something that found all the controllers, invoked the methods
> annotated @RequestMethod with random data a la test.check
> and just verify that they returned “okish”, where I will not define
> “okish” for now.
>
> And of course, I’d like to do some of the same with my ring app, e.g.
> inspect all the routes in compojure, call the handlers (which I should have
> spec’ed)
> and have them called with random test.check data and verify that return
> “okish”
>
> I am aware of this being a huge oversimplification, with lots of pitfalls
> and undefined behaviours, but I still find it an interesting idea.
>
> Erik.
>
> On 10 Nov 2016, at 10:56, Oliver Hine  wrote:
>
> Hi all,
>
> I wrote a blog post on some more advanced use of Martian, a library for
> abstracting HTTP integration with other systems.
>
> All these use cases leverage the fact that Martian separates your data
> (the *what*) from the HTTP implementation details (the *how*) and lets
> you get on with connecting systems in valuable ways.
>
> The blog post includes the following topics:
>
>- Generative testing of HTTP integration
>- Integration with non-swagger APIs
>- REST as a side effect: integrating Martian with re-frame
>
> You can read it all here: http://juxt.pro/blog/posts/advanced-martian.html
>
> Thanks,
> Oliy
>
> https://github.com/oliyh/martian
>
> --
> 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.
>
-- 

Daniel

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

[ANN] Kibit 0.1.3

[Daniel Compton]

Kibit 0.1.3 is out.

 The headlining feature is that Kibit can now read sets without crashing
(thanks to Reid McKenzie). There are some other changes in the release notes
 also.
-- 

Daniel

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

Clojars Mirrors mailing list

[Daniel Compton]

Hi folks

>From time to time, Clojars needs to make changes that affect people that
mirror or proxy Clojars. Some examples of people affected by these changes
would be:

   - People who run an internal Nexus archive that proxies Clojars
   - CI companies that run a mirror to cut down on external traffic and
   speed up build times

There is a new ultra low traffic mailing list for these communications at
https://groups.google.com/forum/#!forum/clojars-mirrors. This mailing list
does not publicly display membership, so you can join without revealing you
or your companies usage of Clojars (though replying to messages would of
course spill the beans).

Major announcements like moving to a CDN or deprecating old versions of
Java will be posted to the Clojure and Clojars-Maintainers lists, but as
these are higher traffic lists, we recognise not everyone wants to
subscribe to them.

Thanks!
-- 

Daniel

-- 
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] trapperkeeper 1.4.1

[Daniel Compton]

The JIRA

still
looks fairly active.

On Mon, Jan 30, 2017 at 11:22 AM Timothy Washington 
wrote:

> Is trapperkeeper still actively being developed and maintained? I'm having
> trouble using trapperkeeper with the core specs in Clojure 1.9. And these
> are the last 2 substantive commits that I see.
>
>- Dec 8 2016
>
> 
>- Oct 19 2016
>
> 
>
>
> Is this something we can still use and build on, for our underlying
> services?
>
>
> Thanks
> Tim
>
>
> On Mon, May 23, 2016 at 4:22 PM, Joe Pinsonault  > wrote:
>
> Today we released puppetlabs/trapperkeeper v1.4.1 to clojars.
>
> There is a single bugfix in this release: TK-375
> .
>
> TK-375 resolves startup issues for users that use a bootstrap.cfg inside
> their project's jar file.
>
> For more info see the CHANGELOG and docs
>
> CHANGELOG: https://github.com/puppetlabs/trapperkeeper
> /blob/master/CHANGELOG.md#140
> Trapperkeeper github wiki: https://github.com/puppetlabs/trapperkeeper
> /wiki
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Daniel

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

ANN: clojure-postmark 1.4.0

[Daniel Compton]

Hi folks

clojure-postmark  is a
library for talking to postmarkapp.com, a transactional email service.

I’ve taken over maintenance from Steve Losh, big thanks to him for creating
it. It has a new release out with a bunch of small improvements quality of
life improvements.

You can see all of the changes at
https://github.com/danielcompton/clojure-postmark/blob/master/CHANGES.md.
-- 

Daniel

-- 
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: s3-wagon-private 1.3.0

[Daniel Compton]

Hi folks

s3-wagon-private  is
a Maven wagon that lets you use a private S3 bucket to store your Maven
dependencies. 1.3.0 has been released with a long awaited feature
thanks to Sheel
Choksi : native AWS authentication support. This
lets you use IAM roles and all of the other unique AWS authentication
features. Because we are now tracking the official Java SDK, we will be
able to easily support new authentication methods as they become available.

There is the possibility that due to the changes, you may have a conflict
between different Jackson versions on the classpath or in your lein/boot
uberjar. If so, please open an issue and we’ll get it straightened out.
-- 

Daniel

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

What’s next for Clojars in 2017?

[Daniel Compton]

Hi folks

In 2016, thanks to the generous sponsors on our Bountysource program and
open source contributors, Clojars was able to:

* Move our hosting from Linode to servers sponsored by Rackspace
* Define the server on Rackspace with Ansible so it is easy to rebuild
* Validate deploys are correct and complete
* Store JARs in Rackspace Cloudfiles for greater reliability
* Serve JARs from a Fastly CDN (sponsored). This takes the Clojars servers
completely out of the critical path of serving files, and should result in
Clojars being very highly available
* Switch from Yeller to Sentry for exception tracking
* Make many smaller improvements as well

As we look towards 2017, there are a number of issues on the Clojars issue
tracker, but most of them are of low priority. We're interested in feedback
from you the community as to where you see problems or room for
improvements to Clojars.

There is one major issue which I think has the potential to greatly improve
security in the Clojure community: JAR signing. Previously Clojars required
JAR signing to promote releases into a special repository. This only served
to confuse most people, not many people promoted their artifacts, and there
were minimal security benefits from signing the JARs, as people didn't have
a web of trust to validate that the GPG signatures actually chained to
people that they trusted.

Clojars is in a very privileged position in your infrastructure, as many of
you use it to directly download JARs to run on your production machines and
developer infrastructure. It would be great if there was an option for
security conscious organisations to be able to validate that all of the
JARs they are using came from developers that they trusted. It would also
be a goal that even if Clojars was compromised, clients would reject
malicious code that didn't come from their expected sources.

I feel that this would be useful for the Clojure (and wider JVM) ecosystem.
However doing this will require a fair amount of time and effort, and it's
only worth doing if people are interested and want a higher security option
available to them. If you are interested, I encourage you to contribute to
https://github.com/clojars/clojars-web/issues/562,
https://github.com/clojars/clojars-web/issues/560, or this thread to share
your perspective, requirements, and threat models that you think we should
be working with.

We're also interested in hearing what else you think is valuable for
Clojars to focus on in 2017. Please reply on this thread with your thoughts.

Thanks, Toby and Daniel.
-- 

Daniel

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

Re: What’s next for Clojars in 2017?

[Daniel Compton]

Hi Alex

> How is your signing proposal different than the signing process already
available in Maven and in use in (for example) Maven Central repository
(and in use for Clojure itself and contrib releases)?

The mechanical part of GPG signing is likely to be exactly the same, it’s
the surrounding verification and distribution of keys that would be
improved. I’ve never published anything to Maven Central, but when Clojars
was verifying GPG signing, anyone who had a user’s Clojars credentials to
upload a JAR could change the authorised GPG key to their own. Without a
set of trusted GPG keys, signing JARs on upload and verifying signatures on
download doesn’t buy you very much security.

One option I am looking at is using The Update Framework (TUF) to help
manage these trust relationships. TUF is used by Docker and Pip.

The high level overview of TUF applied to Clojars would be:

   - There is a root (offline) key of trust managed by Clojars used for
   signing other keys
   - A publisher (library developer) has an offline master key and online
   keys for signing releases. When they deploy a new release, they sign their
   new JAR with an online key.
   - When a user downloads a JAR or metadata from Clojars, the tooling
   (e.g. leiningen), verifies a freshness timestamp signed by Clojars. This
   ensures that the view of the world being presented is current, *and
   protects against replay attacks.*
   - The first time a user downloads a JAR, leiningen would keep a record
   of the association between the signing key identity, and that artifact. Any
   future downloads of the same artifact would need to be signed by the same
   key. This is Trust on first use
   <https://en.wikipedia.org/wiki/Trust_on_first_use>. Also, nothing would
   stop very security conscious users from preloading keys obtained directly
   from the developer, e.g. served over GitHub.
   - Even if an attacker gained a privileged position on Clojars
   infrastructure, they would have no way to sign JARs, so clients would
   detect a signing problem. *This protects against infrastructure
   compromise.*
   - The publisher’s online tagging keys can be rotated without disruption
   to users, but not the offline master key. If that was lost then they would
   need to communicate out of band to people what happened and which key to
   trust. *This enables protection against key compromise.*

See https://blog.docker.com/2015/08/content-trust-docker-1-8/ and
https://docs.docker.com/engine/security/trust/content_trust/ for a better
explanation than mine.

Thanks, Daniel.

On Tue, Feb 7, 2017 at 8:32 AM Chad Stovern  wrote:

Daniel and Toby,

I do DevOps-y things for a living and would be more than willing to help
with ansible stuff or potentially anything else.  Feel free to contact me
directly.

- Chad


On Thursday, February 2, 2017 at 1:47:00 PM UTC-6, Daniel Compton wrote:

Hi folks

In 2016, thanks to the generous sponsors on our Bountysource program and
open source contributors, Clojars was able to:

* Move our hosting from Linode to servers sponsored by Rackspace
* Define the server on Rackspace with Ansible so it is easy to rebuild
* Validate deploys are correct and complete
* Store JARs in Rackspace Cloudfiles for greater reliability
* Serve JARs from a Fastly CDN (sponsored). This takes the Clojars servers
completely out of the critical path of serving files, and should result in
Clojars being very highly available
* Switch from Yeller to Sentry for exception tracking
* Make many smaller improvements as well

As we look towards 2017, there are a number of issues on the Clojars issue
tracker, but most of them are of low priority. We're interested in feedback
from you the community as to where you see problems or room for
improvements to Clojars.

There is one major issue which I think has the potential to greatly improve
security in the Clojure community: JAR signing. Previously Clojars required
JAR signing to promote releases into a special repository. This only served
to confuse most people, not many people promoted their artifacts, and there
were minimal security benefits from signing the JARs, as people didn't have
a web of trust to validate that the GPG signatures actually chained to
people that they trusted.

Clojars is in a very privileged position in your infrastructure, as many of
you use it to directly download JARs to run on your production machines and
developer infrastructure. It would be great if there was an option for
security conscious organisations to be able to validate that all of the
JARs they are using came from developers that they trusted. It would also
be a goal that even if Clojars was compromised, clients would reject
malicious code that didn't come from their expected sources.

I feel that this would be useful for the Clojure (and wider JVM) ecosystem.
However doing this will require a fair amount of time and effort, and it's
only worth doing if people are interested and 

Re: How to disable (or limit) test.check shrinking

[Daniel Compton]

If the 503 is only returned by failures not relating to what you are
testing (e.g. load), then one option might be to catch the exception and
retry that request?

On Thu, Feb 9, 2017 at 6:48 AM 'Matt Bossenbroek' via Clojure <
clojure@googlegroups.com> wrote:

> I'm using test.check to test a live service. Occasionally it gets a 503
> from the service and spends hours trying to shrink the input & reproduce
> the error.
>
> Is there a way to limit the shrinking process to n iterations? Or disable
> it entirely for some tests?
>
> Is there a better approach for using test.check against a live service
> where transient issues are expected? Should I just retry the actual service
> call many times before allowing test.check to see it?
>
> Thanks,
> Matt
>
> --
> 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.
>
-- 

Daniel

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

Users of the Commander Pattern?

[Daniel Compton]

At work, we’re looking at using the Commander Pattern
 for our applications.
The reference
implementation

is in Clojure, but could be written in anything that can read and write to
Kafka. Has anyone else adopted the Commander Pattern or a similar CQRS +
Kafka architecture? If so, could you talk about your experience and
pros/cons?
-- 

Daniel

-- 
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: Handling dependency conflicts

[Daniel Compton]

One option to help with this is OSGi which does have support in Clojure.
https://github.com/talios/clojure.osgi

As Stuart alluded to in his message, the cure to dependency conflicts
(OSGi) may be worse than the disease. I’d guess that the venn diagram of
people using both Clojure and OSGi is pretty thin. There is also
Jigsaw/JPMS in the upcoming Java 9 which is another take on modularity:
https://www.infoq.com/articles/java9-osgi-future-modularity.

On Fri, Mar 17, 2017 at 5:20 AM  wrote:

> Howard, thanks for posting that library. I've passed on the info to some
> of the other developers at work. That kind of tool is highly valuable, I'll
> likely start using it soon.
>
> Gary, the MrAnderson approach sounds similar to shading; I'll take a look
> today.
>
> Stuart, the most common approach boils down to trust and hope, and I don't
> think it's good enough. As projects grow larger the likelihood of running
> into incompatibilities also grows, regardless of community etiquette. Thank
> you for suggesting :pendantic.
>
>
> On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship wrote:
>
> We have some very, very complex projects that bring in boat-loads of
> dependencies, some of which will have version conflicts, if left
> unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to
> see the artifact tree, identify and repair conflicts, and determine why any
> particular artifacts are in the build.
>
> https://github.com/walmartlabs/vizdeps
>
> On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra 
> wrote:
>
> This is a well-known problem in the JVM world, not just Clojure.
>
> The most common approach is: Always use the latest versions, and don't
> break backwards-compatibility.
>
> Most open-source Java and Clojure libraries are careful about not breaking
> backwards-compatibility. So in general, you're safe choosing the latest
> version of any library.
>
> Leiningen has the `:pedantic` option which can be set to warn or fail when
> there are possible dependency conflicts.
>
> Neither Clojure nor the JVM has explicit support for linking to specific
> versions of a library. Work-arounds exist, but they often increase overall
> complexity and lead to conflicts which are harder to debug.
>
> –S
>
>
> On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>
> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in
> Clojure projects and how they affect applications at runtime. I believe
> this is a common problem faced by many languages in this day and age where
> we try not to reinvent the wheel by depending on the work of others.
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*.
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us
> depend on *different versions* of library *A.* Leiningen thankfully warns
> us in many of these situations by suggesting exclusions. However, how can I
> possibly know that something hasn't broken? Stringent testing can give a
> certain degree of confidence that things are still working, but it would
> seem to me that to ensure correctness, we should include *all* versions
> of the dependencies and have the functions link to their respective
> *versioned* identites. Does anyone have advice on how they solve these
> kinds of problems on their codebases in the wild? Thankfully nothing has
> broken yet (to my knowledge), but it seems we have very few assurances here
> and the best we can do is *hope* nothing is broken. Any advice is much
> appreciated.
>
> Thanks,
>
> Arthur
>
> --
> 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.
>
>
>
>
> --
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> 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 unsubs

Re: How do I just use AOT compiled class files over clj(c) source with a leiningen uberjar?

[Daniel Compton]

Zach Tellman talked
 about
making Clojure work better with Proguard in August 2016. I couldn’t find
any open JIRA tickets about this though.

https://www.deepbluelambda.org/programming/clojure/creating-android-applications-with-clojure--slimming-things-down-with-proguard
 and
https://github.com/sattvik/Clojure-Android-Examples/blob/master/slimmed/proguard.cfg
are
from an old post about Proguard on Android which looks like it might have
what you need to get started, though I’m not sure about core_instant18.clj.
Possibly something like this might help?

-keep class clojure.core_instant18__init { public static void load(); }

On Sun, Apr 2, 2017 at 6:49 AM lvh ‌ <_...@lvh.cc> wrote:

> Hi,
>
>
> Context: I'm using Proguard to try to minimize an uberjar produced with
> lein uberjar. This is failing, because when I run the resulting jar with
> java -jar minimized.jar, I get errors about missing classes while trying to
> load/compile .clj files.  proguard is renaming classes and removing unused
> ones. In this case, the class is still in the jar, but under another name.
> As long as the _class_ files are loaded, this should be fine (it's
> proguard's job to rename all references). But proguard doesn't know about
> Clojure, so the Clojure files don't get the same treatment. I understand
> that Clojure generally imports source files as resources, but I was hoping
> with an :aot :all uberjar, that wouldn't be the (primary) case. Removing
> clj[csx]? files from the jar (via :uberjar-exclusions) (which I was hoping
> would force it to try the class files), breaks:
>
> Caused by: java.io.FileNotFoundException: Could not locate
> clojure/core_instant18__init.class or clojure/core_instant18.clj on
> classpath. Please check that namespaces with dashes use underscores in the
> Clojure file name.
>
> This appears to be due to this source file:
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_instant18.clj
> ; and the lack of matching class file can be explained because it is in the
> clojure.core namespace.
>
> Do I misunderstand how :aot :all works? Are clj files always going to
> exist in the resulting uberjar if I want Clojure to work?
>
>
> lvh
>
> --
> 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.
>
-- 

Daniel

-- 
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: Kibit 0.1.5

[Daniel Compton]

Hi folks

Kibit 0.1.5  is out
now.

Kibit is a static analyzer for Clojure and ClojureScript which looks for
patterns of code that could be rewritten more idiomatically.

The major new feature is automatic and interactive replacements. You can
run

lein kibit --replace --interactive

To interactively apply Kibit suggestions, or if you’re very trusting, just
apply them automatically with

lein kibit --replace

This is the first release since consolidating the lein plugin into the main
kibit repository, I think we’ve got everything working correctly, but let
me know if there are any problems.

Happy kibiting!
-- 

Daniel

-- 
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] huffman-keybindings 0.0.1

[Daniel Compton]

Hi Edouard

This is very cool, thanks for sharing!

On Tue, May 9, 2017 at 3:11 AM Edouard KLEIN  wrote:

> huffman-keybindings is a small library to balance a 26-ary huffman tree,
> typically to associate shorter keybindings to the most often used UI
> components.
>
> The code is here https://github.com/edouardklein/huffman-keybindings/
>
> This is my first time disclosing clojure code. Any comments or suggestions
> are welcome.
>
> Cheers,
>
> Edouard.
>
> --
> 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.
>
-- 

Daniel

-- 
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: regarding writing unit tests in clojure for existing java code

[Daniel Compton]

Hi Manas

I haven't used it, and it's quite old, but this may help for writing JUnit
tests in Clojure:
https://github.com/clojurebook/ClojureProgramming/tree/master/ch09-annotations.
It shows how to add JUnit annotations in Clojure, and how to run those
tests with Maven.

On Sat, May 27, 2017 at 9:46 AM  wrote:

> Hello All,.
>
>   We have a large java code base. Junits are not keeping in pace with the
> code base changes and quite a number are outdated.
>   I was wondering if I can use clojure to write unit tests and run them
> using Junit Runner so that the unit tests pass inside eclipse as part of
> compilation of Junit test suite execution.
>   Please can someone advise if there is any library already for achieving
> this
>
> regards
>
> --
> 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.
>
-- 

Daniel

-- 
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 call Clojure from Java?

[Daniel Compton]

Hi thelmuth

Here's a fully worked example. It calls the Clojure function
myco.dashed-namespace.app.core/start!. Save it to
src/myco/dashed_namespace/app/Main.java.

package myco.dashed_namespace.app;

import clojure.java.api.Clojure;
import clojure.lang.IFn;

public class Main {
public static void main(String[] args) {
try {
IFn require = Clojure.var("clojure.core", "require");
require.invoke(Clojure.read("myco.dashed-namespace.app.core"));

Clojure.var("myco.dashed-namespace.app.core", "start!").invoke();
}
catch (Throwable e) {
System.out.println(e.getMessage());
}
}
}


On Fri, Jun 2, 2017 at 1:24 PM James Reeves  wrote:

> There's a brief section on this on the Clojure website:
>
> https://clojure.org/reference/java_interop#_calling_clojure_from_java
>
> On 2 June 2017 at 01:35, thelmuth  wrote:
>
>> What is the best way to call a Clojure function from Java?
>>
>> Most of the resources I have found are either very old or don't go into
>> enough detail. I am a Clojure programmer with very little Java background,
>> and have been having trouble with the methods I've found, especially
>> classpath issues.
>>
>> --
>> 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.
>>
>
>
>
> --
> James Reeves
> booleanknot.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.
>

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

defn with inline specs?

[Daniel Compton]

Currently I don't think it's possible to include a spec inline with a
function definition. If you want to spec a function, it needs to come
afterwards in an s/fdef.

Is it planned for defn to have an extension to allow inline specs, similar
to how pre and postconditions are defined in defn? I think the answer is no
from memory, but I'm not sure why.

As a side note, I thought that this question, and other common questions
could go well in the spec guide under a new spec FAQ section.

Thanks, Daniel.

-- 
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: defn with inline specs?

[Daniel Compton]

> We think there is a lot of value in having them independent.

I agree that there's value in having them independent, and I'm not
suggesting that fdef is taken away, but it seems like there's also value in
having the ability to make them inline? It makes the code more concise and
readable, and avoids typos between the defn name and the fdef name.

On Tue, Jun 20, 2017 at 10:23 AM Alex Miller  wrote:

> No, we don't plan to add that. We think there is a lot of value in having
> them independent.
>
> Rather than add it to the guide, I would prefer to add a section to the
> FAQ page. I've been to do so, but haven't gotten around to it yet.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Simultaneous development of a clojure project and an internal util library

[Daniel Compton]

By the way, if you do use checkouts with Figwheel, be aware of
https://github.com/bhauman/lein-figwheel/issues/9. Currently you need to
add the path to the checkout project into your cljsbuild :source-paths.

On Tue, Jul 4, 2017 at 8:16 AM Vitalie Spinu  wrote:

>
> Leningen has checkout dependencies for this purpose:
>
>
> https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
>
>
>
>   Vitalie
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ClojureScript] [ANN] Orchestra 2017.07.04-1 (now supporting ClojureScript)

[Daniel Compton]

Thanks Jeaye, I'm really happy to see this for CLJS too!

Orchestra has been an excellent development time addition to our apps.
Checking the :ret specs is very helpful for finding the error in code as
close as possible to the problem, rather than further downstream when a
further spec fails.

On Sun, Jul 9, 2017 at 6:06 AM Jeaye  wrote:

> Folks,
>
> I'm happy to announce that a new version of Orchestra has been released
> this past week.
>
> # Where to find it?
> https://github.com/jeaye/orchestra
> [orchestra "2017.07.04-1"]
>
> # What is it?
> Orchestra is a Clojure(Script) library made as a drop-in replacement for
> clojure.spec.test.alpha, which provides custom instrumentation that
> validates all aspects of function specs. By default, clojure.spec will only
> instrument :args. This leaves out :ret and :fn from automatic validation;
> Orchestra checks all of them for you.
>
> # What changed since 0.3.0?
> ClojureScript support!
>
> # Any more info?
> You can read my call to arms for instrumentation here:
> https://blog.jeaye.com/2017/05/31/clojure-spec/ Also, some notes on
> porting Orchestra to ClojureScript, which extend to porting Clojure
> projects to ClojureScript in general, here:
> https://blog.jeaye.com/2017/06/30/orchestra-cljs/
>
> # When should I use it?
> I strongly believe we can benefit from this instrumentation throughout the
> entire development cycle, so I recommend both your tests and your
> developments builds use instrumentation by default. If any functions
> misbehave, you'll know immediately and you'll have the context to find out
> why.
>
> Cheers,
> Jeaye
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://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: bots in closure

[Daniel Compton]

Hi Frank

https://github.com/wit-ai/duckling_old is a text parsing library that
returns structured data. You might find that useful?

On Tue, Jul 11, 2017 at 1:10 PM Alex Walker  wrote:

> Hi Frank,
>
> Chatbot is a bit of a loaded term, so could you please give a bit of
> clarification?
>
>1. Are you expecting natural language (spoken or text), or
>rigid/regex-based commands for user input?
>   - If NL,
>  - do you want to leverage an existing service for intent
>  classification and entity extraction, like Alexa, Wit.ai, Luis, 
> Api.ai, etc
>  - or are you looking to build your own models using the
>  Clojure/JVM ecosystem?
>   - Else,
>  - are you after a hubot equivalent in clojure?
>   2. Do you want your bot to talk to various chat platforms (slack,
>facebook, etc) or do you have a specific one in mind?
>
>
> On Monday, July 10, 2017 at 11:06:45 AM UTC-5, ureal frank wrote:
>>
>> Hi,
>>
>> Is anyone building chatbots in Clojure?
>> OR can someone point me something to start with?
>>
>> Clojure newbie here :)
>>
>> thanks 🙏
>> Frank
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ClojureScript] [ANN] Orchestra 2017.07.04-1 (now supporting ClojureScript)

[Daniel Compton]

> It might be worth including a discussion about when to use this library,
and perhaps indicating that using it might not be a best-practice.

I'm using it to instrument a running development system as I'm working with
it, via an API, REPL, and tests. I've found it handy in all three places
for my :ret specs to be checked when the function runs, and quickly
detecting problems in my spec or function. I can see how :ret and :fn are
invaluable for generative tests, but in my experience it is also very
useful to check them in other places. As far as I can tell, the only
downside to checking :fn and :ret specs while in development is that it
takes marginally more CPU to check them. Maybe I'm missing something though?

On Tue, Jul 11, 2017 at 7:40 AM Didier  wrote:

> I find it funny that Clojure strongly believes that static types aren't
> worth the effort in most cases, but somehow the effort of adding generative
> testing is.
>
> I think it's great to encourage people to use generative testing, but I'd
> rather it be à la carte, like most other things in Clojure. Orchestra
> allows that. If you want your :fn and :ret spec validated only on your
> manual tests, or on your regression tests, it lets you do that.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Unnamed Types - What Am I Doing Wrong?

[Daniel Compton]

Hi Kevin

For something like an account, a more idiomatic way to model this in
Clojure might be with maps:

{:account-name "John Smith"
 :account-number "125-1290"}

or

{:account/name "John Smith"
 :account/number "125-1290"}

If you then want to refactor your usage/naming of map keys then you can
search for usages of the keyword (Cursive has this built-in, I'm not sure
about other editors).

Clojure also has records  which
you can use to model your system. They are similar to maps, but have some
extra features. Alex Miller has a good explanation

about
the tradeoffs between records and maps, and there's more discussion here
, and here

.

On Wed, Jul 26, 2017 at 1:52 PM Kevin Kleinfelter <
kleinfelter.gro...@gmail.com> wrote:

> I ran into the 'refactoring an unnamed type' problem.  I'd like to know
> how experienced Clojurists avoid it.
>
> I've got an account record/structure.  It has things like an account name,
> account number, etc.  I started off storing it in a vector, because it had
> just two elements.  Account name was (first v).  Account number was (second
> v).  And that worked up to a point.  Over time, it has acquired enough
> pieces and rules that I really need to change its implementation.  I need
> to refactor it.
>
> When it was only a few hundred lines long, in a couple of files, I could
> examine each line.  Now that it's a dozen files and several thousand lines,
> I just don't have the attention span.
>
> In a language with named types, I could search for AccountRecord.  I
> could thoroughly find all the places I used it and refactor it.  Or I could
> change the name of the type to tAccountRecord, and the compiler would
> identify all the places where I used it (with error messages).
>
> In an OO language, I'd be accessing all of its pieces via getters and
> setters, and I wouldn't have to find all of the places where I used it,
> because the implementation would be a black box.
>
> But in a language with unnamed types, it's just a vector and I've just got
> first and second and nth to search for.  That's going to find lots of
> irrelevant stuff.  It's enough to make me pine for Java and a refactoring
> IDE.  =:-o
>
> So how do developers who work with un-typed (or un-named type) languages
> avoid this sort of problem?  Or, failing to avoid it, how do they clean up
> afterward?
> tnx
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[ANN] kibit 0.1.6 - featuring namespaced keyword support!

[Daniel Compton]

Hi folks

I'm excited to announce that kibit 0.1.6-beta1 has been released.

Kibit  is a static analysis tool that
looks at your code and suggests ways it could be more idiomatic.

In the most recent beta release, Kibit supports reading files with
namespaced keywords! A massive thanks to Alex Redington for putting this
together, and Reid McKenzie for providing feedback on this fix.

Up until now Kibit couldn't read namespaced keywords and would skip the
rest of the file, which meant that large portions of your codebase wouldn't
be checked. With the increasing use of namespaced keywords from
clojure.spec, this was becoming a larger and larger problem for people.

You can try it today by adding `[lein-kibit "0.1.6-beta1"]` to your
Leiningen :plugins, either in your user.clj, or in your project.clj.

Please report any wonkiness you find with this version. We're particularly
interested in people running this on projects which do funky things with
switching namespaces, or manually manipulating namespace aliases (in-ns,
alias, e.t.c.). A word of warning, as always don't blindly accept Kibit
suggestions. It is possible that it may get confused on files doing tricky
namespace stuff, and make suggestions with incorrect namespace aliases (but
we'd like to fix that if we can).

Thanks, Daniel.

-- 
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: Java learning resources for Clojurists?

[Daniel Compton]

Eric Normand has a course "JVM Fundamentals for Clojure" which might be
useful? https://purelyfunctional.tv/courses/jvm-clojure/

On Wed, Aug 16, 2017 at 2:20 PM Paul Gowder  wrote:

> Hi there,
>
> Can anyone recommend decent resources for learning Java for experienced
> Clojurists who don't do enough interop?
>
> After writing Clojure for about a year and a half, I find that the most
> continuous barrier I encounter is in understanding how to drop down to the
> JVM.  And it's even a barrier in using some core CLJ libraries.
>
> Here's an illustration of the problem I often have.  I was writing a web
> application using Reagent/Immutant, and I wanted to pass data from frontend
> to backend over a websocket in transit format. But the only example in the
> github readme for Transit-CLJ involves dealing with data as a Java
> bytestream.  And it was just too daunting to try to figure out what flavor
> of JVM string the stuff being received over the websocket was under the
> hood, how to cast it into a bytearrayinputstream or whatever else can fit
> into a transit "writer," etc. Or even just like where to start translating
> from "here, I have a Clojure string" to "oh god, now it has to turn into
> some kind of low-level object that isn't a string and isn't a file but is
> something in between and maybe it has to be a stream and maybe it doesn't
>
> Yet almost all "how to learn java" materials I can turn up seem to be
> directed at total beginner programmers, and start with stuff like "here's
> what a for loop is" rather than practical stuff like "here's how to sort
> out the different kinds of array-whatsits and byte-whatsats" or "here's how
> the entry point of a java library works" or whatnot.
>
> I'm hoping there's something out there (that goes a bit deeper than the
> wonderful-but-not-quite-what-i-need interop chapter in Brave and True) that
> someone can recommend.
>
> thanks!
>
> -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.
>

-- 
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: CPU & platform for best compilation performance

[Daniel Compton]

Hi Maarten

Once https://github.com/bhauman/lein-figwheel/pull/586 is released, that
should improve your browser load time somewhat, as you won't need to do
empty your cache and do a hard reload.

On Thu, Aug 24, 2017 at 4:27 AM  wrote:

> Shot in the dark, but dependent namespace compilation may be the source of
> your CLJS compiler slowdowns if you have tons of namespaces. Try seeing
> what happens when you set :recompile-dependents to false in the CLJS
> compiler options.
>
>
> On Wednesday, August 23, 2017 at 11:54:44 AM UTC-4, Maarten Truyens wrote:
>>
>> Hi all,
>>
>> My codebase (mix of CLJ, CLJS and CLJS) is about fifty thousand lines of
>> code, and compilation times are starting to interfere with my workflow
>> happiness. In addition, Chrome Devtools is becoming somewhat sluggish due
>> to the high number of separate namespaces loaded through Figwheel.
>>
>> My current machine is a 6-core Mac Pro 3.5 Ghz Xeon ("late 2013"). For
>> quite a while I have been investigating whether a switch to another machine
>> and/or platform would be interesting from a workflow speed point of view.
>> However, aside from Timothy Pratley's article on the AMD Ryzen 1800x (
>> http://timothypratley.blogspot.in/2017/03/ryzen-is-for-programmers.html),
>> I have trouble finding information that is relevant for us Clojure
>> programmers.
>>
>> I would summarize my research as follows:
>> * single-core performance is most important, so that it is probably the
>> case that a 4-core CPU with a higher single-thread speed is preferable to
>> an 6/8/10-core CPU with a slower single-thread speed;
>> * as from 4 cores, there are hardly any speedups to be expected for
>> having more cores in CLJ or even (parallel) CLJS builds;
>> * the Ryzens are great value, but their single-core performance is
>> usually 10-20% below the top of the line Intels;
>> * according to the many Phoronix benchmarks, Linux and OSX have about the
>> same performance, although there are some interesting deviations for some
>> workflows (even up to 30 - 40%);
>> * the single-core performance difference between my current CPU and the
>> single-core top of the line (i7700K, i7-7800X or i7-7820X) seems to be
>> between 20-40%
>>
>> While a 50% performance increase would be enough to warrant the time
>> investment & cost of switching, my fear is that the real-world speed-up
>> will probably be more like a meager 20%.
>>
>> Ignoring cost considerations and performance outside CLJ development:
>> what CPU and platform would you recommend?
>>
>> Many thanks!
>>
>> Maarten
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: CPU & platform for best compilation performance

[Daniel Compton]

Ah right, I missed that 0.5.13 was released. I've opened
https://github.com/bhauman/lein-figwheel/issues/597 to discuss the caching
issue further.

On Fri, Aug 25, 2017 at 8:44 AM Maarten Truyens <
maarten.truy...@siteffects.be> wrote:

> Thanks for the response!
>
> Isn't that change already active in I noticed the change in 0.5.13? I
> actually tried that release, but it did not make a difference for me. I
> still need to have the DevTools visible, with "Disable cache" flagged in
> the Network Panel, to avoid situations where a modification that was
> correctly picked up by Figwheel, would suddenly get lost again when I
> perform a hard refresh of the page. (I never fully investigated this issue,
> because I assumed that it was perhaps linked to the fact that I have to
> disable the "reload-clj-files" for CLJC-files, to avoid that a single
> change in a CLJC would cause a full recompile of all CLJS files — which is
> unmanageable if half your codebase consists of CLJC files...).
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Deserialization "gadget chain" in clojure

[Daniel Compton]

I saw that this issue was fixed in Clojure 1.9-alpha20. It's tracked in
https://dev.clojure.org/jira/browse/CLJ-2204. If you immediately wrote it
off as not affecting you because you never use clojure.inspector, it looks
like it also affects APersistentMap which is used by everyone. You still
need to be accepting serialized objects from an untrusted source (!) for
this to affect you AFAICT, but I thought it worth bringing up again.

--
Daniel.

On Thu, Jul 20, 2017 at 5:33 AM Ian Haken  wrote:

> Hey Alex,
>
> Thanks for digging and the quick reply. I missed your reply originally
> (apparently I have much to learn about properly subscribing to google
> groups), so sorry about the delay.
>
> Your understanding is completely correct and your assessment around the
> best way to mitigate this issue also seems spot on. I took a look at the
> comments in CLJ-2204 and it seems like you've got a good handle on a
> holistic approach to mitigating the issue as well.
>
> If you end up having any questions, let me know, but it seems like you're
> totally on top of it! Thanks again for digging into it and offering up a
> fix!
>
> Ian
>
> On Wednesday, July 12, 2017 at 5:15:20 AM UTC-7, Alex Miller wrote:
>>
>> Thanks dropping a line Ian. I dug into this a little to understand it
>> better, would be happy for any corrections.
>>
>> It seems the prerequisite for an attack like this is to have a server
>> that deserializes objects from an untrusted source. It should be obvious
>> that this is a bad idea. The attack boils down to crafting a serialized
>> object that, when deserialized, can run arbitrary code.
>>
>> The serialized class being constructed in the attack
>> is clojure.inspector.proxy$javax.swing.table.AbstractTableModel$ff19274a.
>> The Clojure inspector is a Swing app that ships inside the Clojure jar that
>> can be used from the repl to inspect Clojure data structures.
>> AbstractTableModel implements Serializable. The class in question is a
>> proxied subclass of AbstractTableModel (which is thus also Serializable).
>> Clojure proxies contain a field (__clojureFnMap) that is a map of method
>> names to proxy methods. Clojure AOT compiles the clojure.inspector code and
>> includes this proxied, serializable class inside the clojure jar.
>>
>> The attack constructs an instance of this proxy class and adds a
>> "hashCode" proxy method to the proxy's table. The method is a Clojure
>> function that can run arbitrary code. This instance is then put inside a
>> HashMap and the whole thing is serialized. On deserialization, the HashMap
>> will invoke hashCode() on the proxy object and cause the execution of the
>> arbitrary code.
>>
>> I have looked at all uses of proxy in the Clojure code base, and as far
>> as I can tell, this is the only case of a proxy of a Serializable class. A
>> quick and effective way to address this particular case is to stop AOT
>> compiling the clojure.inspector namespace. This removes the serializable
>> class from the Clojure jar. Users have no impact other than making the
>> Clojure inspector (which almost no one uses) slightly longer to start. So
>> this is an easy fix with little impact on users. I have filed an issue at
>> https://dev.clojure.org/jira/browse/CLJ-2204 with a patch modifying the
>> build for this purpose for the next Clojure release. We may also consider
>> releasing Clojure 1.8.1 with this change.
>>
>> Stepping back, it may also be worth considering ways to protect proxies
>> in general, either by detecting and forbidding the proxying of a
>> Serializable/Externalizable class without further steps or by reworking how
>> proxies are implemented in the first place. That's likely to be a bigger
>> change requiring a lot more analysis. I've logged a placeholder issue for
>> this at https://dev.clojure.org/jira/browse/CLJ-2205.
>>
>> Thanks,
>> Alex
>>
>>
>>
>> On Tuesday, July 11, 2017 at 11:37:30 PM UTC-5, Ian Haken wrote:
>>>
>>> Dear Clojure community,
>>>
>>> First off, apologies for directing this at the general clojure mailing
>>> list. I was looking for a better destination, but I couldn't find any
>>> obvious person or private mailing list to direct this to; hopefully from
>>> here this can get in front of anyone who may be interested.
>>>
>>> I recently identified a means to exploit an application performing
>>> unsafe deserialization by utilizing a "gadget chain" contained entirely in
>>> Clojure classes. What this means is that any application which is
>>> deserializing untrusted data and has Clojure on the classpath (whether or
>>> not it is actually using Clojure) is subject to a remote code execution
>>> exploit. Some more information on this form of vulnerability is available
>>> on the OWASP wiki
>>> ,
>>> which also has a number of useful links for deeper discussion.
>>>
>>> Details of the specific gadget chain I found can be seen here
>>> 

Re: How to try/catch Let bindings?

[Daniel Compton]

Hi Didier

The interceptor pattern is pretty tiny, certainly small enough to copy from
project to project if you wanted. You can see re-frame's implementation
here:
https://github.com/Day8/re-frame/blob/master/src/re_frame/interceptor.cljc
which
is only around 100 SLOC. That doesn't handle exceptions like Pedestal, but
shows the core of the idea.

On Mon, Oct 2, 2017 at 5:22 PM Didier  wrote:

> I can't emphasize enough the utility of the interceptor chain pattern, as
>> employed heavily in pedestal.
>>
>
> Interesting... Its almost like a workflow framework, but for simpler in
> code workflows. I'm reluctant to have a dependency on pedestal just for
> this though.
>
> On Sunday, 1 October 2017 21:00:31 UTC-7, Luke Burton wrote:
>
>>
>> On Sep 30, 2017, at 3:14 PM, Didier  wrote:
>>
>> Is there another way to execute a set of complex steps which does not
>> rely on let and can be try/catched in the manner I describe?
>>
>>
>> I can't emphasize enough the utility of the interceptor chain pattern, as
>> employed heavily in pedestal.
>>
>> I use this *everywhere* now. I have code that interleaves interceptors
>> into a chain to augment them with timing information, audit logs, and more.
>> I have written code that maps a subset of an interceptor chain over a
>> cluster of machines, then reduces the results back down locally. Most
>> importantly, they are fantastically useful when it comes time to debug a
>> complex business process … you can swap interceptors in and out easily,
>> isolate stateful interceptors to enable better mocking during tests, and
>> more.
>>
>> Here's a basic application of interceptors. It's really not much code
>> considering what you get. This doesn't even scratch the surface of what
>> they can do.
>>
>> (ns interceptor.test
>>   (:require
>> [io.pedestal.interceptor.chain :as chain]))
>>
>> (def step1
>>   {:name  :step1
>>:enter (fn [ctx]
>> (let [x "sheep"]
>>   (assoc ctx :result x)))})
>>
>> (def step2
>>   {:name  :step2
>>:error (fn [ctx ex-info]
>> (println "so much for step2:" (:exception-type (ex-data
>> ex-info
>>:enter (fn [{:keys [result] :as ctx}]
>>
>> (println "time to transform" result "into a number")
>> (update ctx :result #(Long/parseLong %)))})
>>
>> (defn run []
>>   (chain/execute {} [step1 step2]))
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: possibly a Clojure question or possibly an AWS question: slow writes to durable-queue

[Daniel Compton]

Without more information it's hard to tell, but this looks a like it could
be a garbage collection issue. Can you run your test again and add some
logging/monitoring to show each garbage collection? If my hunch is right,
you'll see garbage collections getting more and more frequent until they
take up nearly all the CPU time, preventing much forward progress writing
to the queue.

If it's AWS based throttling, then CloudWatch monitoring
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html#using_cloudwatch_ebs
might
show you some hints. You could also test with an NVMe drive attached, just
to see if disk bandwidth is the issue.

On Thu, Oct 12, 2017 at 11:58 AM Justin Smith  wrote:

> a small thing here, if memory usage is important you should be building
> and running an uberjar instead of using lein on the server (this also has
> other benefits), and if you are doing that your project.clj jvm-opts are
> not used, you have to configure your java command line in aws instead
>
> On Wed, Oct 11, 2017 at 3:52 PM  wrote:
>
>> I can't figure out if this is a Clojure question or an AWS question. And
>> if it is a Clojure question, I can't figure out if it is more of a general
>> JVM question, or if it is specific to some library such as durable-queue. I
>> can redirect my question elsewhere, if people think this is an AWS
>> question.
>>
>> In my project.clj, I try to give my app a lot of memory:
>>
>>   :jvm-opts ["-Xms7g" "-Xmx7g" "-XX:-UseCompressedOops"])
>>
>> And the app starts off pulling data from MySQL and writing it to
>> Durable-Queue at a rapid rate. ( https://github.com/Factual/durable-queue
>> )
>>
>> I have some logging set up to report every 30 seconds.
>>
>> :enqueued 370137,
>>
>> 30 seconds later:
>>
>> :enqueued 608967,
>>
>> 30 seconds later:
>>
>> :enqueued 828950,
>>
>> It's a dramatic slowdown. The app is initially writing to the queue at
>> faster than 10,000 documents a second, but it slows steadily, and after 10
>> minutes it writes less than 1,000 documents per second. Since I have to
>> write a few million documents, 10,000 a second is the slowest speed I can
>> live with.
>>
>> The queues are in the /tmp folder of an AWS instance that has plenty of
>> disk space, 4 CPUs, and 16 gigs of RAM.
>>
>> Why does the app slow down so much? I had 4 thoughts:
>>
>> 1.) the app struggles as it hits a memory limit
>>
>> 2.) memory bandwidth is the problem
>>
>> 3.) AWS is enforcing some weird IOPS limit
>>
>> 4.) durable-queue is misbehaving
>>
>> As to possibility #1, I notice the app starts like this:
>>
>> Memory in use (percentage/used/max-heap): (\"66%\" \"2373M\" \"3568M\")
>>
>> but 60 seconds later I see:
>>
>> Memory in use (percentage/used/max-heap): (\"94%\" \"3613M\" \"3819M\")
>>
>> So I've run out of allowed memory. But why is that? I thought I gave this
>> app 7 gigs:
>>
>>   :jvm-opts ["-Xms7g" "-Xmx7g" "-XX:-UseCompressedOops"])
>>
>> As to possibility #2, I found this old post on the Clojure mailist:
>>
>> Andy Fingerhut wrote, "one thing I've found in the past on a 2-core
>> machine that was achieving much less than 2x speedup was memory bandwidth
>> being the limiting factor."
>>
>>
>> https://groups.google.com/forum/#!searchin/clojure/xmx$20xms$20maximum%7Csort:relevance/clojure/48W2eff3caU/HS6u547gtrAJ
>>
>> But I am not sure how to test this.
>>
>> As to possibility #3, I'm not sure how AWS enforces its IOPS limits. If
>> people think this is the most likely possibility, then I will repost my
>> question in an AWS forum.
>>
>> As to possibility #4, durable-queue is well-tested and used in a lot of
>> projects, and Zach Tellman is smart and makes few mistakes, so I'm doubtful
>> that it is to blame, but I do notice that it starts off with 4 active slabs
>> and then after 120 seconds, it is only using 1 slab. Is that expected? If
>> people think this is the possible problem then I'll ask somewhere specific
>> to durable-queue
>>
>> Overall, my log information looks like this:
>>
>> ("\nStats about from-mysql-to-tables-queue: " {"message" {:num-slabs
>> 3, :num-active-slabs 2, :enqueued 370137, :retried 0, :completed 369934,
>> :in-progress 10}})
>>
>> ("\nResource usage: " "Memory in use (percentage/used/max-heap):
>> (\"66%\" \"2373M\" \"3568M\")\n\nCPU usage (how-many-cpu's/load-average):
>>  [4 5.05]\n\nFree memory in jvm: [1171310752]")
>>
>> 30 seconds later
>>
>> ("\nStats about from-mysql-to-tables-queue: " {"message" {:num-slabs
>> 4, :num-active-slabs 4, :enqueued 608967, :retried 0, :completed 608511,
>> :in-progress 10}})
>>
>> ("\nResource usage: " "Memory in use (percentage/used/max-heap):
>> (\"76%\" \"2752M\" \"3611M\")\n\nCPU usage (how-many-cpu's/load-average):
>>  [4 5.87]\n\nFree memory in jvm: [901122456]")
>>
>> 30 seconds later
>>
>> ("\nStats about from-mysql-to-tables-queue: " {"message" {:num-slabs
>> 4, :num-active-slabs 3, :enqueued 828950, :retried 0, :completed 828470,
>> :in-progress 10}})
>>
>>

Re: why java version in 10 times faster?

[Daniel Compton]

Hi Mike

A few thoughts

* In my experience it is not unusual that idiomatic Clojure could be 10x
slower than the equivalent Java.
* Where did you do your timing on the ref calculation? In the Clojure
version it calculates distinct at the end.
* How did you do your benchmarking? JVM benchmarking is very tricky, and
could easily overwhelm all other results.
* Have you verified that your Java code is correct under all situations?

Overall I think this is a good illustration of a tradeoff that Clojure
makes against Java. Idiomatic Clojure code is often slower than the Java
that one might write. However (to my eyes) it is far easier to read,
understand, and crucially to verify correctness even on the small example
of swapping numbers. Most of the time, for most systems this is a good
tradeoff. Ensuring correctness and performance with locks in a larger
concurrent system becomes even more difficult.

However if performance is critical, and you have the time and skill to
verify that your locking algorithm is correct, then you can always use
locks. Either through direct calls to Java interop, or writing your locking
code in Java and calling that via Java interop.

For more info on this, you can read the conversation between Rich Hickey
and Cliff Click about STMs vs Locks

.

--
Daniel.

On Mon, Oct 16, 2017 at 7:44 PM Mike <145...@gmail.com> wrote:

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

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

ANN: Kibit 0.1.6

[Daniel Compton]

Hi folks

Kibit 0.1.6  is out now.

There are a few fixes you can see in the release notes, but the big one by
far is that Kibit now supports reading namespaced keywords correctly, just
in time for Clojure 1.9. This has been an open issue
 since 2012(!). A massive thanks
to Alex Redinger who put together the PR
 for this, and to Reid McKenzie
who is sharing the maintainership duties with me.

You can find the new release at your friendly neighbourhood Clojars
.

Happy kibiting, and let me know here or in the GitHub issues if you have
any issues.

--
Daniel.

-- 
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: Deps Versions - Add badges to spot when your dependencies are out of date

[Daniel Compton]

Hi folks

I’m pleased to announce Deps Versions (https://versions.deps.co/). Deps
Versions is a service that shows you when your dependencies are outdated.
You can add badges to your OSS Clojure/ClojureScript GitHub projects that
will check if your dependencies are up to date.

I hope to add support for more languages and tools (like tools.deps) soon,
and for users to be able to subscribe to notifications when new versions
are available.

I wrote a blog post  at
the Deps blog explaining the background a bit more.

Deps Versions is open source  on
GitHub, so you can open issues and pull requests there for improvements and
bug fixes.

Thanks, Daniel.

-- 
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: Clojurists Together - Funding critical Clojure open source projects

[Daniel Compton]

Hi folks

Today we are incredibly excited to announce Clojurists Together
<https://clojuriststogether.org/>. The goal of Clojurists Together is to
support important Clojure projects, by pooling donations from companies and
individuals in the Clojure community and then funding project maintainers.

The Clojurists Together model is based off the successful Ruby Together
<https://rubytogether.org> project, which has been running for 2.5 years
now. It is run by a committee <https://clojuriststogether.org/team/> of
Clojure community members and lives under the Clojars organisation. Being
part of Clojars allows us to accept 501(c)3 charitable donations via the SFC
<https://sfconservancy.org/>. We’ve been (slowly) working on this for more
than a year now, and are looking forward to getting your feedback on it.

The announcement post
<https://clojuriststogether.org/news/introducing-clojurists-together/> has
more details, but briefly, there are two sides to Clojurists Together:
Companies
and individuals, and open source maintainers.

*Companies and individuals*

Companies and individuals sign up for a monthly donation to support
Clojurists Together at a tier they choose. Different tiers afford different
benefits. Company tiers are here <https://clojuriststogether.org/companies/>,
individual tiers are here <https://clojuriststogether.org/developers/>.
Every quarter, companies are surveyed to find out which tools, libraries,
and areas of the Clojure ecosystem they think could be improved, or are
important to them. We then compile that information and use it to help us
pick projects that will have the biggest impact.

*Open Source Maintainers*

Every quarter open source maintainers can submit their project for funding
for the next quarterly funding period. You can see more on the application
here <https://clojuriststogether.org/open-source/>. We look through the
applications, and pick the projects that can make the biggest impact. We
fund projects based on the amount of support we get. The more support we
get from companies and individuals, the more projects we can support, and
the more hours we can pay them for.

*What now?*

   - Encourage your managers to sign up for a company membership
   <https://clojuriststogether.org/companies/>. For the next month, any
   company or person that signs up will be marked as a founding member.
   - If you are an open source maintainer, consider applying for funding
   <https://clojuriststogether.org/open-source/>.
   - If you are an individual developer, consider signing up for a developer
   membership <https://clojuriststogether.org/open-source/>.
   - Spread the word to other people you know that use Clojure commercially.
   - If you're a designer, and have some time to help us improve the site
   design, logo, e.t.c. that would be incredible. Please contact us off list
   for more on this.

*Questions?*

There may be some mistakes or things that don’t look right in there. Please
let us know if you have any questions, either here, or off-list at
h...@clojuriststogether.org. This project is for the Clojure community, so we
want your input on this. What works well, what doesn’t work for you, what
would you like to see?

Thanks, from the Clojurists Together Committee
<https://clojuriststogether.org/team/>:
Toby Crawley, Bridget Hilyer, Maria Geller, Devin Walters, Daniel Solano
Gómez, Larry Staton Jr., Daniel Compton.

-- 
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.spec] Stricter map validations?

[Daniel Compton]

> I think so too. I'm still finding it hard to come up with a single
example of why allowing extra keys to validate would ever be useful even
for non-breakage. I can't see how it would break anything.
>
> I believe the only advantage of allowing extra keys, is to allow partial
specs. So say you never had specs, and your API takes a ton of keys, and
you start by only speccing half the keys it takes. That's the only use case
I could think of.

This is my core concern as well. It seems like it is going to lead to bugs
from typos or people expecting specs to have been defined for keywords that
weren't defined. It also is incongruous with other parts of spec like
s/cat, which does require specs to be registered at check time. I
understand there is a technical/implementation detail for the reasons here,
but it strikes me as a rough edge that people are likely to continually run
into. I've hit it myself already in projects where I spec'ed a map, but
didn't have some of the keys spec'ed. I discovered later my mistake, but
like Didier, I can't see any time that I would actually want this feature.

Because spec's information model is all about namespaced keywords that have
a unique unambiguous meaning (at least I think that's the idea?), allowing
specing of a map with keywords that don't exist because they may be defined
by some other part of the system doesn't make a lot of sense to me. Even if
this is a valid use case, it seems like a niche one that would be better
served by defining a new function that allows it (perhaps in another
library), rather than it being part of the behaviour of the more general
purpose s/keys.

On Wed, Nov 15, 2017 at 8:53 AM Eric Normand  wrote:

> 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.
>
>
> Isn't this precisely why you should use namespaced keywords?
>>
>
>
> Yes! Great point.
>
> That sounds like a great thing to document in your API. Something like:
> "all keys in com.xyz namespace are reserved and could be restricted at
> any time. Please don't use them." You could send a warning back in your API
> if they use any that don't validate.
>
> Are there any resources that document these best practices? It seems like
> Clojure is trying to push us down this road but there's no map yet at the
> moment.
>
>
>
>>
>>
>> tirsdag 14. november 2017 19.43.55 UTC+1 skrev Sean Corfield følgende:
>>
> Eric does raise an interesting question tho’:
>>>
>>>
>>>
>>>
>>>
>> (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 yo

Re: EPL 2.0

[Daniel Compton]

Hi Aspasia

Clojars and the Software Freedom Conservancy have been looking at the EPL
2.0 license and the impact of Clojure libraries adopting it, particularly
around GPL compatibility. However I suspect that even if all Clojure
libraries adopt the GPL compatibility clause, it would still need Clojure
itself to adopt it for people to be able to use GPL software compliantly.

You can see a little bit of discussion around this at
http://dev.eclipse.org/mhonarc/lists//epl-discuss/msg00158.html. However
the CliffsNotes that came out of that conversation and the EPL-2.0 FAQ
 were:

Q: What is the impact of adding a secondary GPL license?

A: It is almost the same as dual licensing EPL/GPL

Q: How can I upgrade a project from EPL-1.0 to EPL-2.0?

A: The EPL allows new versions of the license to be adopted by projects
with little work. A project can use the new version by simply updating the
file headers and notices. It would be good practice to discuss this before
relicensing though.

Q: How can I upgrade a project to EPL-2.0 with GPL secondary license?

A: You must gain permission from all copyright holders to re-license the
content (Ed: Projects with a CLA would allow you to do this, as you have
already gotten approval from contributors.)

Q: Some organizations do not use GPL-licensed content. What are the impacts
of licensing a project with EPL-2.0 + GPL secondary license?

A: While the EPL-2.0 has a concept called "Secondary Licenses", should an
adopter not want to use the Secondary License, then the entire construct
can simply be ignored. The code can be consumed purely under the EPL-2.0
without any concerns.

You should check the original sources for these questions and answers for
their full context, as I've edited them here for brevity, hopefully with
little loss in precision.

Alex: it looks like this was your email about concerns
 you and
Rich had. I can see Mike Milinkovich had some followups with answers, do
they satisfy your concerns about the definition of derivative works?

I've created issues for Leiningen
 and Clojars
 to discuss the EPL-2.0
license in the context of new project templates, and also whether and how
Clojars could help projects migrate to EPL-2.0 + GPL.

Thanks, Daniel.

On Wed, Nov 22, 2017 at 7:22 AM Alex Miller  wrote:

> Hi Aspasia,
>
> We provided some feedback in the early discussions around EPL 2.0. I
> haven't looked closely at the final result, but I don't think a lot of
> those concerns were addressed and it's unlikely that Clojure will switch to
> EPL 2.0.
>
> Alex
>
>
> On Tuesday, November 21, 2017 at 11:56:35 AM UTC-6, Aspasia Beneti wrote:
>>
>> Hi there,
>>
>> are there any plans of licensing Clojure with EPL 2.0 in the future? I am
>> interested in terms of GPL compatibility which as stated here
>>  :
>>
>> *In terms of GPL compatibility, the new license allows the initial
>> contributor to a new project to opt in
>>  to a secondary license that
>> provides explicit compatibility with the GNU General Public License
>>  version 2.0, or
>> any later version.*
>>
>> Thanks in advance
>> Aspasia
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Git Deps for Clojure!

[Daniel Compton]

> git deps go to .gitlibs.

Would you consider not putting them in the root of the user's home
directory? All the major OS's (and probably the minor ones too) have
dedicated folders to put caches. I've opened
https://dev.clojure.org/jira/browse/TDEPS-30 with more details on this.

--
Daniel

On Sun, Jan 7, 2018 at 3:25 AM Alex Miller  wrote:

>
>
> > On Jan 6, 2018, at 5:43 AM, Khalid Jebbari 
> wrote:
> >
> > Great news, great work ! Soon running Clojure will be dead easy.
> >
> > 2 questions :
> > - where do dependencies get downloaded ? `~/.m2` ? It depends on the
> procurer (mvn/git/etc.)
>
> It depends. Maven deps go to .m2, git deps go to .gitlibs.
>
> > - does it work for Cljs ? What does it mean for Cljs ?
>
> This is targeted at launching Clojure programs. ClojureScript itself is a
> Clojure program, so it’s relevant in that 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.
>

-- 
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: Comparing and selecting web API libraries

[Daniel Compton]

If you're looking at Liberator because of how it lets you write
applications that implement much of the HTTP spec then I would suggest also
looking at Yada. It was written by Malcolm Sparks (who also contributed to
Liberator), and takes HTTP spec compliance very seriously. It gives you a
lot of leverage for providing a small resource definition.

On Sat, Mar 10, 2018 at 6:18 AM Oliver Hine  wrote:

> Pedestal also has support for Swagger (along with coercion, validation,
> serialisation and more) via pedestal-api
> https://github.com/oliyh/pedestal-api
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Clojurists Together Q2 2018 Call for Proposals

[Daniel Compton]

Hi folks

Clojurists Together is an organisation dedicated to funding critical open
source Clojure projects. We fund projects on a 3-month cycle. Funding
varies based on member support, but in our current cycle we were able to
fund clj-http and Figwheel $1800USD/mo each for three months. Both projects
have made amazing progress, you can read more about them in our Feb
 and March
 updates.

We're gearing up for our next cycle and are soliciting proposals from the
Clojure/ClojureScript community. We recently surveyed
 our members
to see what they wanted us to fund. The main areas they were focused on
were documentation, build tooling, and libraries. *If you maintain a
Clojure project that is important to some or all of the Clojure community
please apply  for our second
funding round.*

*If you run or manage a company that relies on the Clojure open source
ecosystem, we'd encourage you to consider joining as a company member
. *We've had a great response from
individual developers, but only a handful of companies have joined as
sponsors. A very special thanks to all of our members
, we couldn't do any of this
without your support.

Let us know if you have any questions/concerns, either here or at
h...@clojuriststogether.org

Thanks, Daniel.

-- 
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: Clojurists Together Q2 2018 Call for Proposals

[Daniel Compton]

Hi folks

Clojurists Together Q2 funding applications close on 22 April, so if you
were thinking of applying <https://www.clojuriststogether.org/open-source/>,
now is the time. We haven't had too many applications yet, it would be
great to get some more from library and tool maintainers.

Thanks, Daniel.

On Wed, Apr 11, 2018 at 9:16 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> Clojurists Together is an organisation dedicated to funding critical open
> source Clojure projects. We fund projects on a 3-month cycle. Funding
> varies based on member support, but in our current cycle we were able to
> fund clj-http and Figwheel $1800USD/mo each for three months. Both projects
> have made amazing progress, you can read more about them in our Feb
> <http://clojuriststogether.org/news/february-2018-monthly-update/> and
> March <http://clojuriststogether.org/news/march-2018-monthly-update/>
> updates.
>
> We're gearing up for our next cycle and are soliciting proposals from the
> Clojure/ClojureScript community. We recently surveyed
> <https://clojuriststogether.org/news/q2-2018-survey-results/> our members
> to see what they wanted us to fund. The main areas they were focused on
> were documentation, build tooling, and libraries. *If you maintain a
> Clojure project that is important to some or all of the Clojure community
> please apply <https://clojuriststogether.org/open-source/> for our second
> funding round.*
>
> *If you run or manage a company that relies on the Clojure open source
> ecosystem, we'd encourage you to consider joining as a company member
> <https://clojuriststogether.org/news/>. *We've had a great response from
> individual developers, but only a handful of companies have joined as
> sponsors. A very special thanks to all of our members
> <https://clojuriststogether.org/members/>, we couldn't do any of this
> without your support.
>
> Let us know if you have any questions/concerns, either here or at
> h...@clojuriststogether.org
>
> Thanks, Daniel.
>

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

Clojurists Together is funding CIDER and ClojureScript from May-July

[Daniel Compton]

Hi folks

Clojurists Together is funding Bozhidar Batsov and Mike Fikes $5,400USD
each to work on CIDER and ClojureScript (respectively) from May-July. You
can read more about the work they're doing at in the announcement
.

We couldn't have done any of this without the support of our company and
developer members . If you
like the projects that we've been funding, consider joining as a company
 or developer
 member so we can keep
funding projects that are important to the Clojure ecosystem.

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] greenlight 0.1.0 - a integration testing framework

[Daniel Compton]

Hi Jeff

This looks very cool. Can you describe a little bit more about how/where
you would use this vs. other kinds of Clojure testing frameworks? The
examples show tests all running within a single process, some using
Component to build up a system map. Do you also use this for inter-process
integration tests?

Thanks, Daniel.

On Mon, Jul 2, 2018 at 6:45 AM Jeff Stokes  wrote:

> Hi,
>
> We've just released a 0.1.0 of our testing framework greenlight
> . Greenlight provides an
> integration testing framework for systems to give you the confidence to
> greenlight your code to production. This is the first public release of
> this library.
>
> https://github.com/amperity/greenlight
>
> Thanks,
> Jeff
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: What is the minimal Emacs config for practical Clojure development?

[Daniel Compton]

Not sure exactly how minimal you're looking for but I like Prelude
. It's maintained by Bozhidar Batsov,
who also maintains CIDER, so it works well for Clojure development.

On Tue, Jul 3, 2018 at 5:42 PM Łukasz Korecki 
wrote:

> Hi!
>
> I've recently switched to Monroe - https://github.com/sanel/monroe
> Its feature set is quite limited, and it boils down to:
>
> - start a nREPL server
> - connect to it
> - a REPL buffer is created inside of Emacs
> - evaluate forms
>
> I've added a tiny bit of config on my side which adds a Clojure scratch
> buffer
> https://github.com/lukaszkorecki/cult-leader/blob/master/settings/lk/clojure.el#L26-L44
> and that's pretty much it.
>
>
> Łukasz
>
>
> On Monday, July 2, 2018 at 4:41:23 AM UTC+1, Austin Haas wrote:
>>
>> I don't want to use a package manager with Emacs.
>>
>> Should I launch a REPL outside of Emacs, then connect to it? Using the
>> CLI tools (i.e., from the command line: clojure
>> -J-Dclojure.server.repl="{:port  :accept clojure.core.server/repl}")?
>>
>> Can I launch a REPL from within Emacs?
>>
>> I've been using inf-clojure and clojure-mode with the following elisp in
>> my .emacs:
>>
>> (add-to-list 'load-path "~/.emacs.d/site-lisp/third-party/clojure-mode/")
>> (require 'clojure-mode)
>> (add-to-list 'load-path "~/.emacs.d/site-lisp/third-party/inf-clojure/")
>> (load-file "~/.emacs.d/site-lisp/third-party/inf-clojure/inf-clojure.el")
>> (add-hook 'clojure-mode-hook #'inf-clojure-minor-mode)
>> (setf inf-clojure-lein-cmd "lein run -m clojure.main")
>>
>> and C-c C-z to start a REPL, but I get noise in the REPL, including
>> repeated prompts, and (seemingly) random linebreaks in large output.
>>
>> What's the state of the art for a simple, practical Emacs setup for
>> Clojure?
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Clojurists Together Q3 2018 Call for Proposals (Closes July 20)

[Daniel Compton]

Hi folks

Clojurists Together is an organisation dedicated to funding critical open
source Clojure projects. We fund projects on a 3-month cycle. Funding
varies based on member support, but in our previous cycles we have been
able to fund clj-http, Figwheel, ClojureScript, and CIDER $1800USD/mo each
for three months.

We're gearing up for our next cycle and are soliciting proposals from the
Clojure/ClojureScript community. We recently surveyed
 our
members to see what they wanted us to fund. Error messages, documentation,
developer experience, and IDE support featured highly. *If you maintain a
Clojure project that is important to some or all of the Clojure community,
especially in one of these areas please apply
 for funding. Applications
close July 20.*

*If you run or manage a company that relies on the Clojure open source
ecosystem, we'd encourage you to consider joining as a company member
. *We've had a great response from
individual developers, but not as many companies have joined as sponsors. A
very special thanks to all of our members
, we couldn't do any of this
without your support.

Let us know if you have any questions/concerns, either here or at
h...@clojuriststogether.org

Thanks, Daniel.

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