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.

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

Re: Clojurists Together wants to fund you to work on your open source Clojure project from May-July 2020

[Daniel Compton]

Hi folks

I'm happy to announce that this quarter Clojurists Together (with the help
of our members) are supporting re-frame with Isaac Johnston, Practicalli
with John Stevenson, CIDER/nREPL/Orchard with Bozhidar Batsov, and Figwheel
with Bruce Hauman.

You can see more details at
https://www.clojuriststogether.org/news/q2-2020-funding-announcement/.

Thanks to all of our members <https://www.clojuriststogether.org/members/> for
your support, we couldn't do it without you.

Daniel and the Clojurists Together committee

On Fri, Apr 3, 2020 at 8:37 PM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> Clojurists Together <https://www.clojuriststogether.org> is about to
> award another round of funding to support open source Clojure projects. 
> *Applications
> <https://www.clojuriststogether.org/open-source/> close on Thursday, April
> 9th at 11:59pm PST.*
>
> 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 four projects at $3,000 USD/month for 3 months ($9,000
> USD total).*
>
> Previously we have supported projects
> <https://www.clojuriststogether.org/projects/> like Neanderthal, Aleph,
> Fireplace, cljdoc, Shadow CLJS, CIDER, Figwheel, clj-http and several more.
>
> We surveyed
> <https://www.clojuriststogether.org/news/q2-2020-survey-results/> our
> members recently and asked them what they wanted us to focus on.
>
> The main things our members were interested in:
>
>- Error messages
>- Documentation
>- Developer experience tools
>- Build tooling
>- IDE support
>- Test tooling
>- Linters
>- Profilers
>- Data analysis/processing frameworks
>
> If you work on any of these kinds of projects, please look at applying for
> funding.
>
> Figwheel, clj-kondo, Kaocha, Reitit, Shadow CLJS, re-frame, Aleph,
> Manifold, Calva, Cloverage, Chlorine, Conjure, Malli, clj-goes-fast were
> all projects mentioned that our members were interested in supporting.
>
> We encourage open source maintainers to apply
> <https://www.clojuriststogether.org/open-source/> for funding, especially
> if you work on one of the projects or areas that our members highlighted.
>
> 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
> <https://www.clojuriststogether.org/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_iYhzJQ1j6pgEcG08de1Qy%3DNk5pf7QSfY4ky_H22VU%2B3A%40mail.gmail.com.

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

[Daniel Compton]

Hi folks

Clojurists Together  is about to award
another round of funding to support open source Clojure projects. *Applications
 close on Thursday, April
9th at 11:59pm PST.*

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 four 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 surveyed
 our
members recently and asked them what they wanted us to focus on.

The main things our members were interested in:

   - Error messages
   - Documentation
   - Developer experience tools
   - Build tooling
   - IDE support
   - Test tooling
   - Linters
   - Profilers
   - Data analysis/processing frameworks

If you work on any of these kinds of projects, please look at applying for
funding.

Figwheel, clj-kondo, Kaocha, Reitit, Shadow CLJS, re-frame, Aleph,
Manifold, Calva, Cloverage, Chlorine, Conjure, Malli, clj-goes-fast were
all projects mentioned that our members were interested in supporting.

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

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_hO5PZeucAo-MDBo47Ynt_t%2Bu-qO9X6%2B%2Bv4Rw5tQLvNOQ%40mail.gmail.com.

Re: Clojurists Together call for proposals (4 projects $9,000 each)

[Daniel Compton]

Hi folks

Clojurists Together is happy to announce that for Q1 of 2020
(February-April) we are funding four projects $9,000 each:

Reagent with Juho Teperi
fireplace.vim with Tim Pope
Ring with James Reeves
Calva with Brandon Ringe

You can see more detail on what they'll be working on at
https://www.clojuriststogether.org/news/q1-2020-funding-announcement/.

Thanks to all the Clojurists Together members
<https://www.clojuriststogether.org/members/> who helped make this
possible. If you or your company would like to join in the work that we're
doing, you can sign up as a company member
<https://www.clojuriststogether.org/companies/>, or a developer member
<https://www.clojuriststogether.org/developers/>. You can now use a credit
card instead of PayPal, and we can accept bank transfers for annual
memberships.

Thanks, Daniel.



On Wed, Jan 15, 2020 at 5:39 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> Applications for this close tomorrow. If you work on a Clojure open source
> project that is important to the community (or a subset of the community)
> we'd love to fund you. We haven't had many applications for this quarter
> yet (though we also consider projects that applied over the last 3 funding
> rounds).
>
> I'm happy to review application drafts if people want some guidance or are
> not sure if their application fits our funding structure.
>
> Thanks, Daniel.
>
> On Thu, Jan 9, 2020 at 8:26 PM Daniel Compton <
> daniel.compton.li...@gmail.com> wrote:
>
>> Hi folks
>>
>> Clojurists Together is going to be funding 4 Clojure open source projects
>> from February - April. If you maintain an open source project that could
>> use some funding, please consider applying.
>>
>> Applications close in a week on 15th January 11:59pm PST.
>>
>> The main things our members were interested
>> <https://www.clojuriststogether.org/news/q1-2020-survey-results/> in:
>>
>>- Error messages
>>- Documentation
>>- Developer experience tools
>>- Build tooling
>>- IDE support
>>- Test tooling
>>- Linters
>>- Profilers
>>- Data analysis/processing frameworks
>>
>> If you work on any of these kinds of projects, please look at applying
>> for funding. You can look at the survey results for more information on
>> which projects and kinds of projects our members are interested in.
>>
>> You can apply at https://www.clojuriststogether.org/open-source/.
>>
>> If you have any questions about applying or your application, please get
>> in touch. We're happy to talk about your application and answer any
>> questions you have.
>>
>> Thanks to all of the company and developer members
>> <https://www.clojuriststogether.org/members/> who have funded this work,
>> we couldn't do it without you.
>>
>> 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_h2%3DWVy%3DMYWSuL1wYpbhLCNFvQqCmGJpNchxA%3DUjHE_%3Dw%40mail.gmail.com.

Re: Clojurists Together call for proposals (4 projects $9,000 each)

[Daniel Compton]

Hi folks

Applications for this close tomorrow. If you work on a Clojure open source
project that is important to the community (or a subset of the community)
we'd love to fund you. We haven't had many applications for this quarter
yet (though we also consider projects that applied over the last 3 funding
rounds).

I'm happy to review application drafts if people want some guidance or are
not sure if their application fits our funding structure.

Thanks, Daniel.

On Thu, Jan 9, 2020 at 8:26 PM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> Clojurists Together is going to be funding 4 Clojure open source projects
> from February - April. If you maintain an open source project that could
> use some funding, please consider applying.
>
> Applications close in a week on 15th January 11:59pm PST.
>
> The main things our members were interested
> <https://www.clojuriststogether.org/news/q1-2020-survey-results/> in:
>
>- Error messages
>- Documentation
>- Developer experience tools
>- Build tooling
>- IDE support
>- Test tooling
>- Linters
>- Profilers
>- Data analysis/processing frameworks
>
> If you work on any of these kinds of projects, please look at applying for
> funding. You can look at the survey results for more information on which
> projects and kinds of projects our members are interested in.
>
> You can apply at https://www.clojuriststogether.org/open-source/.
>
> If you have any questions about applying or your application, please get
> in touch. We're happy to talk about your application and answer any
> questions you have.
>
> Thanks to all of the company and developer members
> <https://www.clojuriststogether.org/members/> who have funded this work,
> we couldn't do it without you.
>
> 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_jESh1YKzWeo%3Du%2BbvS7qaGxKaKm44uvDRwxf2%3Dg-Dqg%3DA%40mail.gmail.com.

Clojurists Together call for proposals (4 projects $9,000 each)

[Daniel Compton]

Hi folks

Clojurists Together is going to be funding 4 Clojure open source projects
from February - April. If you maintain an open source project that could
use some funding, please consider applying.

Applications close in a week on 15th January 11:59pm PST.

The main things our members were interested
 in:

   - Error messages
   - Documentation
   - Developer experience tools
   - Build tooling
   - IDE support
   - Test tooling
   - Linters
   - Profilers
   - Data analysis/processing frameworks

If you work on any of these kinds of projects, please look at applying for
funding. You can look at the survey results for more information on which
projects and kinds of projects our members are interested in.

You can apply at https://www.clojuriststogether.org/open-source/.

If you have any questions about applying or your application, please get in
touch. We're happy to talk about your application and answer any questions
you have.

Thanks to all of the company and developer members
 who have funded this work, we
couldn't do it without you.

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_hZUgKtOm3Q_q_B0Yzf6XnJV2MVhTM%2Bj33jLOc2NrtW2w%40mail.gmail.com.

Re: Clojure has been selected to participate in GSoC 2017!

[Daniel Compton]

Hi folks, I'm the secretary of Clojurists Together.

Thanks very much for the background on GSoC and the kind words Alex :)

Clojurists Together would be happy to help provide the backing admin
infrastructure (bank accounts, international payments, etc.) and oversight
to help run GSoC. However, I don't think anyone on the committee has the
bandwidth to be the primary person to lead the GSoC project; we'd need
someone from the community to volunteer to be that person.

If someone else wants to run this as part of a different organisation
that's also totally fine with us, don't consider this us calling "dibs".

Thanks, Daniel.

On Wed, Dec 4, 2019 at 9:34 AM Alex Miller  wrote:

> GSoC is an amazing opportunity if you get the right combination of an
> appropriately sized project, a motivated student, and a mentor that has
> both sufficient availability and expertise in guiding (like Ambrose's Typed
> Clojure work). If any of those aren't right, the project tends to fizzle
> out or go unused so a lot of the time and effort does not result in an
> effectual end result.
>
> To some degree, Clojurists Together is doing the same kind of work but
> prioritizing projects that people care about and developers that are
> already "in" the project rather than students starting fresh (and paying
> more for the work). I think CT has created way more total value for the
> community than GSoC ever did.
>
> But again, depends on goals. If your goal is to connect students more
> closely to Clojure, then GSoC is great for that.
>
>
> On Tuesday, December 3, 2019 at 2:06:13 PM UTC-6, Daniel Slutsky wrote:
>>
>> Ag, Alex, many thanks.
>>
>> These days some of us are trying to think where we should put our efforts
>> in the next few months. This might be one of the things we have to
>> consider. We'll update if we do.
>>
>>
>>
>> On Tuesday, 3 December 2019 17:20:47 UTC+2, Alex Miller wrote:
>>>
>>> Any "group" or organization can submit a project to GSoC as long as
>>> there are 2+ committers and there are existing releases under an OSI
>>> license (which includes EPL). The organization select projects, connects
>>> mentors to students, prods people about evaluations, and receives
>>> $500/completed student. Students submit proposals (usually these should
>>> happen under consultation with the project) and are directly paid stipends
>>> by Google for completed projects. I think the organization application is
>>> usually open in January.
>>>
>>> I think there are several groups in the Clojure ecosystem that would
>>> potentially be great orgs for this - CIDER, ClojureBridge, clj-commons, etc.
>>>
>>>
>>> On Tuesday, December 3, 2019 at 5:23:43 AM UTC-6, Ag Ibragimov wrote:


 Would you do it Daniel, would you apply? I apologize for if that sounds
 like I'm brazenly pushing you. If I had capacity to do that, I would
 volunteer, alas I'm afraid I don't even know how that works.
 It would be awesome if Clojure once again accepted in GSoC. How can we
 (ordinary Clojuristas) help to get there?

 On Sun 01 Dec 2019 at 15:12, Daniel Slutsky 
 wrote:

 > Thanks so much, that helps to know.
 >
 > On Sunday, 1 December 2019 06:36:33 UTC+2, Alex Miller wrote:
 >>
 >> We applied and were not accepted for a couple years. Having done
 some of
 >> the admin/org stuff in the past, I don't really want to do it again,
 but an
 >> organization like Clojurists Together would be great for that part
 >> (although I'm not looking to add any work to anyone else either).
 It's not
 >> really that hard, just a little tedious to deal with the money
 parts.
 >>
 >> On Saturday, November 30, 2019 at 1:37:14 PM UTC-6, Daniel Slutsky
 wrote:
 >>>
 >>> Hi all,
 >>> has there been thoughts about clojure activity in GSoC since 2017?
 >>>
 >>>
 >>> On Monday, 6 March 2017 11:35:41 UTC+2, Daniel Solano Gómez wrote:
 
  We are pleased to announce that Google has selected Clojure as a
  mentoring organisation for this year’s summer of code! This means
 that
  Google will sponsor students from around the world to work on
 projects that
  are part of the Clojure ecosystem. Now that we know that Clojure
 will be
  participating, what happens next?
 
  Getting involved
 
  The student application period will be open from the 20th of March
  through the 3rd of April. In the meantime, there are a number of
 ways to
  get involved:
 
  *Mentors*
 
  If you maintain an open source Clojure(Script) project and would
 like to
  grow it, you should consider becoming a mentor. You can find out
 more about
  what being a mentor is about out on the mentors page
  .
 
  *Students*
 
  While it is still to early 

Re: 100x startup for Clojure using GraalVM

[Daniel Compton]

> They are probably much less interested in using these methods for
long-running server processes.

At work, we were quite interested in making a native-image of our API
server recently. Having a fast boot would have opened a lot more
possibilities around where we could run it. Serverless environments like
AWS Lambda, Google Cloud Run, Google App Engine Standard, and other places
that boot in response to a request were not even close to workable with our
moderately sized Clojure API server. We did some experiments with making a
native-image, but there were too many libraries that needed to be updated
to do it now. We're going to chip away at making our dependencies
native-image compatible and then have another crack later.

Bruno Bonacci has a collection of sample apps at
https://github.com/BrunoBonacci/graalvm-clojure showing how to build
various libraries and highlighting where there are issues currently.

On Wed, Nov 13, 2019 at 7:06 PM Andy Fingerhut 
wrote:

> I believe at least some of the people working on this, and interested in
> these results, would like to use Clojure for command line utilities and
> such, which tend to have quite short run times when implemented in
> C/C++/Python/etc.  They are probably much less interested in using these
> methods for long-running server processes.
>
> Andy
>
> On Tue, Nov 12, 2019 at 8:46 PM 'Gerard Klijs' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> Hello world is fun, but doesn't say much. I would like to see benchmarks
>> on the actual application. Ideally it would take several jvm's so also
>> Graal and J9 and also use the commercial version of making a native image,
>> asses how much memory is needed when run on the JVM and limit that, since
>> otherwise it will might take upto a quarter of available memory. Measures
>> both the time to the first successful handled request from startup, the max
>> throughput after being warmed up properly, the .99 percentile latency after
>> being warmed up, and the memory use.
>> Only if you have those numbers you could decide if a native image is
>> worth it. For example if with the current load one instance with a native
>> image could always handle the load, it might save a lot, because you can
>> and to 0, where the total first request just take seconds. But if at loyal
>> moments with a native image you need 30 instances, while on the JVM you
>> need only 3 it might not.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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/bcc8f1d8-db0a-45f0-9d95-d280ae653fcc%40googlegroups.com
>> .
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAKvLtDYgqxifgtagXKr192Dozhq3tG8oN%3D%3DjTBjXPbDO41PAkg%40mail.gmail.com
> 
> .
>

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

Re: Clojurists Together funding round for Q4 2019

[Daniel Compton]

Sorry, this should have said *Applications
<https://www.clojuriststogether.org/open-source/> close on Saturday,
October 26th, 2019 at 11:59pm PST.*

On Tue, Oct 22, 2019 at 9:02 PM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> Clojurists Together <https://www.clojuriststogether.org/> is about to
> award another round of funding to support open source Clojure projects. 
> *Applications
> <https://www.clojuriststogether.org/open-source/> close on Saturday, July
> 26th, 2019 at 11:59pm PST.*
>
> 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 four projects at $3,000 USD/month for 3 months ($9,000
> USD total).*
>
> Previously we have supported projects
> <https://www.clojuriststogether.org/projects/> like Neanderthal, Aleph,
> Fireplace, cljdoc, Shadow CLJS, CIDER, Figwheel, clj-http and several more.
>
> We surveyed
> <https://www.clojuriststogether.org/news/q4-2019-survey-results/> our
> members recently and asked them what they wanted us to focus on.
>
> Highly ranked items were:
>
>- developer experience tools
>- IDE support
>- build tooling
>- documentation
>- error messages
>- test tooling
>- linters
>
> Our members also mentioned these projects specifically: ClojureScript,
> Cloverage, Duct/Integrant, Neanderthal, Reagent, clj-kondo, cljsjs,
> expound, leiningen, orchestra, re-frame, shadow-cljs, spec,
> test.chuck/test.check.
>
> We encourage open source maintainers to apply
> <https://www.clojuriststogether.org/open-source/> for funding, especially
> if you work on one of the projects or areas that our members highlighted.
> If you have any questions please reach out by email or Clojurians Slack.
>
> 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
> <https://www.clojuriststogether.org/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_hFDiFxdMvBqvf%3D%3DY9uaP3%2Bu8DcORHeEJ7a%3D0Gancz9%3DQ%40mail.gmail.com.

Clojurists Together funding round for Q4 2019

[Daniel Compton]

Hi folks

Clojurists Together  is about to award
another round of funding to support open source Clojure projects. *Applications
 close on Saturday, July
26th, 2019 at 11:59pm PST.*

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 four 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 surveyed
 our
members recently and asked them what they wanted us to focus on.

Highly ranked items were:

   - developer experience tools
   - IDE support
   - build tooling
   - documentation
   - error messages
   - test tooling
   - linters

Our members also mentioned these projects specifically: ClojureScript,
Cloverage, Duct/Integrant, Neanderthal, Reagent, clj-kondo, cljsjs,
expound, leiningen, orchestra, re-frame, shadow-cljs, spec,
test.chuck/test.check.

We encourage open source maintainers to apply
 for funding, especially
if you work on one of the projects or areas that our members highlighted.
If you have any questions please reach out by email or Clojurians Slack.

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_gVo0unRt0qwXa6WfqyKwDuvJBkQDfQ4cgKfiBMiX9WUQ%40mail.gmail.com.

Re: Clojurists Together wants to fund you to work on your open source Clojure project

[Daniel Compton]

Hi folks

I'm happy to announce that this quarter Clojurists Together is funding
Shadow CLJS with Thomas Heller, Meander with Joel Holdbrooks, Calva with
Peter Strömberg, and CIDER with Bozhidar Batsov. You can see more on the
announcement at
https://www.clojuriststogether.org/news/q3-2019-funding-announcement/.
Thanks to all of the Clojurists Together members who helped make this
happen.

-- Daniel.

On Fri, Jul 12, 2019 at 9:23 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> Clojurists Together <https://www.clojuriststogether.org> is about to
> award another round of funding to support open source Clojure projects. 
> *Applications
> <https://www.clojuriststogether.org/open-source/> close on Wednesday, July
> 17th, 2019 at 11:59pm PST.*
>
> 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 each project at $3,000 USD/month for 3 months ($9,000 USD
> total).* We're still working out exactly how many projects we will be
> able to fund this quarter, but it is likely to be at least 2.
>
> Previously we have supported projects
> <https://www.clojuriststogether.org/projects/> like Neanderthal, Aleph,
> Fireplace, cljdoc, Shadow CLJS, CIDER, Figwheel, clj-http and several more.
>
> We surveyed
> <https://www.clojuriststogether.org/news/news/q3-2019-survey-results/>
> our members recently and asked them what they wanted us to focus on.
>
> Highly ranked items were:
>
>- developer experience tools (49%)
>- build tooling (37%)
>- linters (34%)
>- error messages (33%)
>- IDE support (30%)
>- documentation (19%)
>- test tooling (24%)
>
> Our members also mentioned these projects specifically: shadow-cljs, Duct
> Framework, Core.typed, CIDER, Clojuredocs, clj-doc, Eastwood, Cloverage,
> buddy, clj-kondo, Reagent, re-frame, FIgwheel Main, Cursive, Leiningen,
> Calva, Chlorine, Sente, Nippy, Rum, core.async, incanter, clj-pdf.
>
> We encourage open source maintainers to apply
> <https://www.clojuriststogether.org/open-source/> for funding, especially
> if you work on one of the projects or areas that our members highlighted.
>
> 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
> <https://www.clojuriststogether.org/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_h-Siinj3EexsJgKY-Ktjy%3D3QFWxNzedhWK7BMP80%2B6kg%40mail.gmail.com.

Clojurists Together wants to fund you to work on your open source Clojure project

[Daniel Compton]

Hi folks

Clojurists Together  is about to award
another round of funding to support open source Clojure projects. *Applications
 close on Wednesday, July
17th, 2019 at 11:59pm PST.*

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 each project at $3,000 USD/month for 3 months ($9,000 USD
total).* We're still working out exactly how many projects we will be able
to fund this quarter, but it is likely to be at least 2.

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

We surveyed
 our
members recently and asked them what they wanted us to focus on.

Highly ranked items were:

   - developer experience tools (49%)
   - build tooling (37%)
   - linters (34%)
   - error messages (33%)
   - IDE support (30%)
   - documentation (19%)
   - test tooling (24%)

Our members also mentioned these projects specifically: shadow-cljs, Duct
Framework, Core.typed, CIDER, Clojuredocs, clj-doc, Eastwood, Cloverage,
buddy, clj-kondo, Reagent, re-frame, FIgwheel Main, Cursive, Leiningen,
Calva, Chlorine, Sente, Nippy, Rum, core.async, incanter, clj-pdf.

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

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_j5yApwOK3XDZy%2BXy6Dni7kX_XbLcZx7nuPujNVW6yiCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

ANN: ring-gzip-middleware 0.1.4 - adds async Ring middleware support

[Daniel Compton]

Hi folks

ring-gzip-middleware 0.1.4 has been released 
<https://github.com/clj-commons/ring-gzip-middleware/releases/tag/0.1.4>. 
This library lets you gzip your Ring responses, if the client supports it.

The main change in this release is the addition of async Ring middleware 
support. Project maintenance and releases has also moved from Alan Malloy 
to CLJ Commons <https://clj-commons.org>.

Thanks!
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/bef7be4e-d2da-426c-afae-2a0ce99818b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Clojurists Together Q2 2019 funding round - $9,000 over three months to work on your Clojure project

[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. In the past
we have funded projects like Figwheel, Shadow CLJS, Kaocha, Datascript,
cljdoc, and lots more . Thanks
to the growth in Clojurists Together members, we've been able to up our
payment from $5,400 over three months ($1,800/mo) in 2018 to $9,000 over
three months ($3,000/mo). A very special thanks to all of our members
, we couldn't do any of this
without your support.

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. Developer experience tools,
build tooling, documentation, error messages, IDE support, test tooling,
and linters all 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 15th Apr, midnight PST (end of day).*

*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 we have many fewer company members.

Let us know if you have any questions/concerns, either here or at
h...@clojuriststogether.org. We're also happy to review your application
before you submit it to check if everything is clear and it answers the
questions we will have.

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] defn-spec, define your specs inline with your function

[Daniel Compton]

Hi folks

I've released 0.1.0 of defn-spec
, a library that lets you
define your function specs inline with your function definitions.

A quick example, defn-spec lets you write:

(ds/defn to-zoned-dt :- ::zoned-date-time
  [instant :- ::instant
   zone-id :- ::zone-id]
  (ZonedDateTime/ofInstant instant zone-id))

instead of:

(defn to-zoned-dt
  [instant zone-id]
  (ZonedDateTime/ofInstant instant zone-id))

(s/fdef to-zoned-dt
:args (s/cat :instant ::instant :zone-id ::zone-id)
:ret ::zoned-date-time)

If you're thinking "that looks a lot like Schema's defn macro", then you'd
be right. defn-spec uses the same syntax and much of the implementation of
Schema's defn macro.

I wrote more background in the announcement post
, and there are
more details on GitHub . I hope
you find it useful!

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 Q1 2019 call for proposals

[Daniel Compton]

Hi folks

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. In the last 12 months we've funded 
 improvements to DataScript, 
Kaocha, cljdoc, Shadow CLJS, CIDER, ClojureScript, clj-http, and Figwheel.

We've just finished surveying our members on what they see 
as 
important for our next funding round. 

The main things people were interested in: developer experience tools 
(55%), build tooling (52%), documentation (49%), error messages (44%), IDE 
support (35%), test tooling (30%), linters (30%), and data 
analysis/processing frameworks (26%). 

Specific projects mentioned were CIDER, Clojure.spec, Re-frame, REPLs, 
Leiningen, Hiccup, Reagent, Aleph, Re-natal, Figwheel, LightTable, and 
Datahike.

If you maintain a Clojure project, especially one in the areas of focus, or 
a named project, please consider applying for funding.

One of the things Clojurists Together was designed to support is the work 
that isn't fun to do. These are things like tracking down hard to reproduce 
bugs, maintenance to follow upstream dependencies, reviewing large 
pull-requests, thinking about/tackling large thorny problems, and the other 
slog work which is important but not fun. If you've got a project with work 
like that that you've been putting off, we want to fund you to work on it. 
Of course we also want to fund projects to implement new features, but 
please don't think that just because you don't think your work isn't 
exciting that you shouldn't apply.

You can apply at https://www.clojuriststogether.org/open-source/. *Applications 
close on 15th Jan*, Midnight PST, and the Q1 funding round goes from 
February 1 - April 31.

If you'd like help preparing an application, or have any more questions, 
you can contact me or any of the team 
.

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.

Building a formatter like gofmt for Clojure

[Daniel Compton]

Hi folks

In the last ten years or so, source code formatters with limited/no
configuration have become popular. Go is the most well-known example,
shipping with gofmt, but there are similar tools in Rust, JavaScript,
Python, and Elixir.

Clojure and Lisps, in general, have historically allowed very flexible
formatting of s-expressions. This can aid readability but adds a cognitive
overhead for readers used to different styles. It can also be challenging
to match existing source code formatting if you are using a different
editor to the original author.

*I believe it would be useful for the Clojure community to be able to
develop (or adopt) a single source-code formatter which is able to format
Clojure source code to a canonical format.* It seems unlikely that 100%
(maybe not even 50%) of the community would want such a tool, but I feel
like there is enough desire for a common formatting tool that this could
still be valuable.

I've created a discussion thread

on ClojureVerse about building a Clojure/ClojureScript source code
formatter as part of CLJ Commons . There are a
few differences in goals between this tool and the existing ones that
exist. I go into more detail in the thread, but I'm proposing the creation
of

* A fairly canonical format for Clojure code, e.g. reindenting code,
reformatting namespace declarations. A format that has idiomatic opinions.
* A formatting spec and test suite that multiple different tools and
editors can implement, not a spec defined by the implementation of a single
tool.
* The creation of a reference implementation formatter.
* A formatter with few (maybe zero?) options

It's possible that 10 years after Clojure's creation, it's going to be too
difficult for the community to coalesce around a canonical format, and it
will be necessary to add some configuration options. I'm not really sure,
which is why I'm asking for community members to join in the discussion.

I realise that I'm touching the third rail
 here, and lots of
people have strong opinions about formatting. I don't expect that everyone
would like or want to adopt such a strict formatting tool, and that's
totally ok! For those of you that *do* like the idea of building/having
such a tool, please jump in on the discussion on ClojureVerse, and on a
GitHub repo discussing the different aspects of formatting at
https://github.com/clj-commons/formatter.

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] Ordered 1.5.7, Useful 0.11.6 , and Ring Buffer 1.2.2

[Daniel Compton]

Hi folks

I'm pleased to announce new releases of Ordered
, Useful
, and Ring Buffer
. These releases are fairly
minor but add support for JDK 11. The test suites have also been updated to
test against the latest versions of Clojure (all passing on 1.10.0-RC3!)
and current and future versions of the JDK. The releases are also GPG
signed by me .

*Releases:*

*Ordered 1.5.7 *
* Type hint toArray to be compatible with JDK 11

*Ring Buffer 1.2.2
*
* Type hint toArray to be compatible with JDK 11

*Useful 0.11.6 *
* Fix lazy-loop's support for destructured bindings

There are two open PRs against useful, one which would raise
 the minimum JDK version to
8, the other about a fix  to
a function which would be a breaking change, but implements the expected
behaviour. Please put comments in there if you have strong feelings about
either of these issues.

*Migration:*

Alan Malloy (amalloy) owned these projects (along with ring-gzip-middleware
), some of them under
the Flatland group. They have been moved to CLJ Commons for continued
maintenance and improvements. CLJ Commons  is a
community-led project to build up the supporting infrastructure around
Clojure.

If you have maintained a fork of any of these libraries, I'd encourage you
to open PRs/issues for fixes/features you've made, so we can centralise
efforts. I'm also very happy to provide commit access to people who have
maintained forks.

*Thanks:*

I want to publicly thank Alan for his years of service to the Clojure
community. There is a very high chance that you have used some of the code
that he has created, in these libraries, or his many other contributions to
Clojure.

*Getting involved:*

If you're interested in getting involved with maintaining these projects,
or any of the others in the CLJ Commons stable
, get in touch. We're also open to taking
over maintenance of other widely used projects where the maintainer is no
longer interested/available in maintaining them. If you know of libraries
that fit those criteria, open an issue on the wishlist
, and we can start a conversation
with the maintainer to get their thoughts.

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.

Announcing The REPL podcast

[Daniel Compton]

Hi folks

I've started a podcast "The REPL" about Clojure and ClojureScript to
accompany the weekly newsletter. I've written a little bit about the
background of starting it on my personal site
, and you can
subscribe to the podcast or listen online at https://www.therepl.net.

The REPL focuses on diving into Clojure programs and libraries in a
discussion with their creators. I've talked with a bunch
 of awesome people already, and have
some great episodes in the pipeline too.

If you like podcasts, then give it a try, perhaps on your way
 to The Conj
this week?

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 elections for 2018

[Daniel Compton]

Hi folks, just a reminder that nominations are closing in a few days
(November 14th). We've got several nominations already (thanks folks!), but
are still taking applications.

Thanks, Daniel.

On Tue, Nov 6, 2018 at 3:51 PM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> Clojurists Together are going to be holding elections in November. This
> will elect people that will run the Clojurists Together program, steer its
> future direction, and help pick which projects to fund. Nominations are
> open to anyone, you don't have to be a Clojurists Together member to stand
> for election. You also don't have to have lots of experience with Clojure
> to apply. We want a committee made up of a cross-section of the Clojure
> community so that we have a wide range of perspectives when making
> decisions on which projects to fund. If you're looking for a way to give
> back to the Clojure community, Clojurists Together is one way you could do
> so.
>
> There's more details and the nomination form at
> https://www.clojuriststogether.org/news/2018-committee-nominations/.
>
> Nominations close end of day November 14th, Pacific Time.
>
> If you have any questions, please get in touch and I'll try to help.
>
> 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.

Clojurists Together elections for 2018

[Daniel Compton]

Hi folks

Clojurists Together are going to be holding elections in November. This 
will elect people that will run the Clojurists Together program, steer its 
future direction, and help pick which projects to fund. Nominations are 
open to anyone, you don't have to be a Clojurists Together member to stand 
for election. You also don't have to have lots of experience with Clojure 
to apply. We want a committee made up of a cross-section of the Clojure 
community so that we have a wide range of perspectives when making 
decisions on which projects to fund. If you're looking for a way to give 
back to the Clojure community, Clojurists Together is one way you could do 
so.

There's more details and the nomination form at 
https://www.clojuriststogether.org/news/2018-committee-nominations/.

Nominations close end of day November 14th, Pacific Time.

If you have any questions, please get in touch and I'll try to help.

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 Call For Funding Proposals: November 2018 - January 2019

[Daniel Compton]

Hi folks

Clojurists Together is soon going to be evaluating proposals for our Q4
funding round of November 2018 - January 2019. If you maintain a
Clojure/Script open source project/service/something else, please consider
applying  for funding.

We recently surveyed
 our
members and error messages, documentation, build tools, IDE support, test
tooling, and linters were things people wanted to see supported. Tools and
documentation targeting beginners to Clojure or to programming, in general,
were mentioned by quite a few people. Projects people specifically named
were: Shadow CLJS, Figwheel, CIDER, Rum, Datascript, Reagent, Protorepl,
Neanderthal, LightTable, Leiningen, Fulcro, Expound, and Eastwood.

If you work on a project named as a focus or a specific project, then we
would really love to have you apply.

Previous projects we have funded include Figwheel, clj-http, CIDER,
ClojureScript, and the two current projects we are funding: cljdoc and
Shadow CLJS. Two successful projects will each be funded $1,800 USD/mo for
three months ($5,400 total).

Application details are at
https://www.clojuriststogether.org/open-source/. *Applications
close on October 9th* (midnight end of day Pacific Time). If you have any
questions or would like help with your project proposal, please contact me
and I'll be happy to help.

If you work for a company that depends on Clojure staying viable, *please*
encourage your management to sign up for a company membership
. We have had a lot of
support from individual developer members (around 150), but only 18 company
members. If you're in management and Clojurists Together isn't pushing your
buttons, let me know what kinds of things would make a membership more
valuable for you.

Lastly, thanks to all of our company and developer members
. Without your support, none
of this could have happened.

Thanks, Daniel and the rest of the team
.

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

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.

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.

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

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

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 

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.

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

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.

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, 

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

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

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

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

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

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

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

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 

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

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 <c...@stovern.me> 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 an

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.

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.

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.

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.

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.

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

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 

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: [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 <andy.finger...@gmail.com>
>> 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.
>>>>
>>>
>>> --
&g

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 <andy.finger...@gmail.com>
> 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: 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 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 <andy.finger...@gmail.com>
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: [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.

[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: 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 <d...@mobileink.com> 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/_medium=Text+Link_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.

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/_medium=Text+Link_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: 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: 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.

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

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

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] 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 <a2093...@trbvm.com> 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: [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] 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: 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: [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: [ClojureScript] Re: ANN: ClojureScript 1.8.34

[Daniel Compton]

I may be way off on this, but I would expect :compiler-env, special-fns,
warn-on-undeclared to be in figwheel config, not in the compiler config,
hence to cause no issues?

https://github.com/bhauman/lein-figwheel/tree/v0.5.0-5#client-side-configuration-options

On Sat, Mar 19, 2016 at 12:48 PM David Nolen  wrote:

> Thanks for the report! Will need to think about how to deal with other
> tooling possibly including additional options we don't understand - we now
> warn on options we don't support to avoid unnecessary confusion.
>
> David
>
> On Fri, Mar 18, 2016 at 7:01 PM, Rangel Spasov  wrote:
>
>> Thanks, David!
>>
>> I get those warnings when compiling via "lein figwheel":
>>
>> WARNING: Unknown option ':compiler-env'.
>>
>> WARNING: Unknown option ':special-fns'.
>>
>> WARNING: Unknown option ':warn-on-undeclared'.
>>
>>
>> Otherwise, everything seems fine.
>>
>> Rangel
>>
>
>> On Friday, March 18, 2016 at 11:04:46 AM UTC-7, David Nolen wrote:
>>>
>>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>>
>>> README and source code: https://github.com/clojure/clojurescript
>>>
>>> Leiningen dependency information:
>>>
>>> [org.clojure/clojurescript "1.8.34"]
>>>
>>> There are many minor fixes in this release around bootstrapped
>>> ClojureScript. This release also fixes a subtle bug with the
>>> new :parallel-build feature.
>>>
>>> As always feedback welcome!
>>>
>>> ## 1.8.34
>>>
>>> ### Changes
>>> * CLJS-1582: Type-hint extend-type first arg for primitives
>>> * CLJS-1590: split, split-lines differs from Clojure on empty string
>>> * CLJS-1594: NaN and both infinities cannot be elements of a set
>>> * CLJS-1597: Redundant IPrintWithWriter test in pr-writer-impl
>>> * CLJS-1583: (hash (symbol "/")) does not match (hash '/)
>>> * bump tools reader
>>> * CLJS-1492: Warn when using :optimisations instead of :optimizations
>>> * less cryptic error if :main doesn't correspond to any file
>>> * CLJS-744: ISequential types should implement JS indexOf, lastIndexOf
>>> * CLJS-1411: make-array signature differs from clojure
>>>
>>> ### Fixes
>>> * CLJS-1589: Self-host: case fail with nil
>>> * CLJS-1596: Self-host: :load-macros and :analyze-deps don't work in
>>> cljs.js
>>> * CLJS-1420: get-in behavior differs from Clojure by always deferring to
>>> the 3 arity fn
>>> * CLJS-1585: Self-host: Alias-scoped keywords
>>> * CLJS-1577: Self-host: syntax-quote resolves on dot forms
>>> * CLJS-1564: Self-host: cached macro *loaded* update
>>> * CLJS-1584: Self-host: core/str error with condp
>>> * CLJS-1521: Self-host: Macro namespaces cannot be aliased
>>> * CLJS-1573: Self-host: Invalid UTF escaping in cljs-in-cljs
>>> * CLJS-1570: :parallel-build causes invalid truth check in
>>> cljs.reader/read-number
>>> * CLJS-1568: LazyTransformer doesn't implement IMeta
>>> * CLJS-1578: Corrupted Analysis Files Break Compilation
>>> * CLJS-1579: cljs.source-map/invert-reverse-map discards gcol
>>> * CLJS-1580: Self-host: goog.provide offsets source-maps
>>> * CLJS-1569: IndexedSeq doesn't implement IWithMeta / IMeta
>>> * CLJS-1567: make-array macro missing > 2 arg arity
>>> * CLJS-1571: Make special-symbol? true for 'var
>>> * CLJS-1555: make-array macro missing 2 arg arity
>>> * CLJS-970: generate assert message when compiling
>>> * CLJS-1565: Self-host: whitespace optimization is broken
>>> * CLJS-1541: Self-host: Cannot require 'cljs.js using cljs.jar
>>> * CLJS-1550: Enhance docstring for extend-type wrt type-sym
>>> * CLJS-1551: Self-host: assert-args dormant in macros
>>> * CLJS-1552: doc for & should match fn
>>> * CLJS-1488: cljs.repl/source Cannot read source of cljs functions that
>>> use #js reader
>>> * CLJS-1557: Make special-symbol? return true for catch and finally
>>> * CLJS-1542: Self-host: cljs/compile-str not handling errors properly
>>> * CLJS-1318: Fix typo in documentation of `specify`
>>> * CLJS-620: Warnings are generated when using a macro in argument
>>> position
>>> * CLJS-1547: Wrong output encoding when compile with goog.LOCALE
>>> * CLJS-1546: cljs.core/run! does not always return nil
>>>
>>> --
>>
> You received this message because you are subscribed to the Google
>>
> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>
>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>>
> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> 

Clojars Christmas outage - One month on

[Daniel Compton]

 

Hi folks


Over the Christmas/New Year period, Clojars experienced significant 
downtime due to a DDoS on our hosting provider 
 Linode. 
This exposed a number of weaknesses in the Clojars service, and related 
tooling. Toby published a retrospective 
 on 
the Clojars Maintainers list 
 a few days 
later, which I recommend you read for all the gory details. This email will 
describe what we’ve done since to improve Clojars resilience, and what 
we’re still doing.


*# What we’ve done:*


*## Additional administrator*


First, we’ve increased the number of volunteer administrators by 100% (from 
1 to 2). I’ve joined the team, and as I’m in the NZ timezone, we are better 
equipped to respond to incidents at any time of the day.


*## Sponsorships*


Second, we've gained a few service sponsors that will reduce costs and 
allow us to be more robust:


DNSimple : they are providing free DNS for us

Rackspace : they are providing us free server 
and cloud file usage. We're not yet taking advantage of this, but hope to 
move in the near future. Thanks lvh  for 
advocating for us!

StatusPage.io : they are providing us a free status 
page (located at http://status.clojars.org)

Pingometer : they are providing us with website 
uptime monitoring.

Those are in addition to the free account we were already receiving from 
Yeller , and some of Toby's admin time that is 
donated by Red Hat .


## *Monitoring and status*


Thanks to StatusPage, Yeller, and Pingometer, we’re able to identify and 
respond to issues quickly, and keep the community updated when there are 
issues.


*# What we’re doing*


*## Major work*


There are a few major pieces of work we’ve identified to make Clojars more 
resilient (they were all created before the Linode outage, but haven’t been 
completed yet):

   - Move the Clojars repo off the server [#433] 
    
   - Put the Clojars repo behind a CDN [#434] 
    
   - Use config automation to build and maintain the server [#432] 
    

*## Moving to Rackspace*


Once we have config automation available to recreate the server, we plan to 
move to Rackspace. We expect that Rackspace will be able to provide better 
resiliency and security.


*## Becoming a non-profit*


We've applied to be a member of the Software Freedom Conservancy. We're 
doing that for a few reasons:

   - It will allow us to take corporate donations 
   - Donations would be tax-deductible (at least in the US, tax law may 
   vary in your country) 
   - We'll have legal protection in the case of a DMCA or other legal 
   entanglement (currently, the liability is on the administrators) 
   - If we succeed in gaining non-profit status, we plan to use excess 
   funds to support other Clojure community projects, and will have a 
   (eventually community elected) committee to determine how those funds will 
   be distributed. 

We hope to know if our application has been accepted within the next couple 
of months.


*# How you can help*

   - Clojars is an open source project, and anyone can contribute. There 
   are a number of issues tagged ‘ready’ 
    which are ready 
   for anyone to pick up and run with. If you’re looking to start contributing 
   to open source, Toby and I are happy to work with you to help shepherd pull 
   requests through the process. 
   - I have some issues tagged ‘help wanted’ 
   

 on 
   the server config project 
    where another pair of 
   eyes would be very helpful. Also, if you have experience with Ansible, it 
   would be great to have feedback on how we’re using it overall, and 
   suggestions for improvements. 
   - There are some issues for Leiningen related to offline support that 
   need patches, [#2059] 
   , [#2058] 
   , [#2055] 
   . 
   - Join the maintainers list 
   . This is 
   where issues related to Clojars changes are discussed. 
   - Donate to the Bountysource 
    project. People have been 
   incredibly generous donating to Clojars. Thanks so much to everyone! 


Thanks!


Toby & Daniel

Re: Clojure beyond Java 6 ?

[Daniel Compton]

Just a reminder that Cursive needs to support Java 6, as there are still
issues with OpenJDK8 on Mac OS X 10.11. So not all people using Java 6 can
be written off as enterprise laggards.
On Wed, 20 Jan 2016 at 8:52 PM, Bozhidar Batsov  wrote:

> Even Java 1.7 already reached its end of life. I get it that some
> companies are slow to update their infrastructures, but being constrained
> to legacy unsupported systems adds both a security risk and some
> development overhead. It's high time for Java 1.6 to be laid down to rest
> and for people stuck to it to move forward. I'm guessing Cognitect's
> enterprise customers are the primary reason 1.6 is still supported.
>
> On 20 January 2016 at 08:58, Max Penet  wrote:
>
>> I doubt it such a big deal actually.
>>
>> You can run multiple versions of the java on the same machine. The
>> only issue would be for legacy projects that are frozen to java 6 and
>> would like to upgrade to a lib (like clojure) relying java8.  But I
>> doubt such projects are the norm, and the few that are probably do not
>> care about upgrading to the latest clojure.
>>
>> There are a lot of very large projects (such as Jetty, Cassandra, etc)
>> that just made java8 a requirement for their next/current releases, and I
>> don't see much complaining about it (quite the opposite).
>>
>> Also the fact that clojure itself is not getting an avalanche of new
>> feature at every release makes upgrading not so critical.
>>
>>
>>
>>
>> On Tuesday, January 19, 2016 at 8:33:56 PM UTC+1, Sean Corfield wrote:
>>>
>>> Didier wrote on Tuesday, January 19, 2016 at 11:08 AM:
>>>
>>> Why not make new versions of Clojure support the latest Java version and
>>> JDK features
>>>
>>>
>>> Since Clojure 1.7 (and 1.8) run on Java 8 quite happily, I assume you
>>> mean "Why not drop support for earlier Java versions with each new version
>>> of Clojure"?
>>>
>>> The answer — for any situation like this — is that many companies are
>>> slow to upgrade fundamental infrastructure like the JVM because they have
>>> so many things that rely on it, so it is a major exercise. For Clojure to
>>> be adopted by such companies, it needs to run on their existing JVM
>>> infrastructure.
>>>
>>> Dropping support for older JVM versions is therefore a Big Deal(™) and
>>> can not be undertaken lightly. A lot of software generally tries to support
>>> current plus two versions back which would mean Java 6 support should
>>> likely stay until Java 9 is GA (although it’s true that there is also a lot
>>> of software that only supports current plus one version back).
>>>
>>> Bear in mind that there are many companies still running Windows XP
>>> because upgrading is such an expensive business (in time and effort, as
>>> well as any actual costs)!
>>>
>>> Sean Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "Perfection is the enemy of the good."
>>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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 

Re: [ANN] Clojure.Java-Time 0.2.0

[Daniel Compton]

There are few differences between java.time and Joda time for most people's
usage (I think), so a wrapper to support both would probably be possible.

http://stackoverflow.com/questions/24631909/differences-between-java-8-date-time-api-java-time-and-joda-time
On Fri, 15 Jan 2016 at 11:56 PM, Mikera 
wrote:

> Looks awesome, I'd definitely like to use this whenever I can guarantee
> running on Java 8 or above.
>
> Question: is there any change of having a unified time API in Clojure?
> That supports both Joda time and Java time? And works with cljs? It is a
> bit frustrating to have to hard-code to specific time libraries rather
> using a good abstraction
>
>
> On Wednesday, 13 January 2016 20:29:25 UTC+8, platon...@gmail.com wrote:
>>
>> Hello all,
>>
>> I've released a Java 8 Date-Time API wrapper some time ago but never
>> bothered to make a formal announcement. So here it is: Clojure.Java-Time.
>> 
>> Please, feel free to check out the readme
>>  and
>> maybe even try using it :)
>>
>> Dependency vector: [clojure.java-time "0.2.0"]
>>
>> Have fun!
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Reducing the pain of a clojars outage

[Daniel Compton]

IntelliJ 15 (the new version), bundles JDK8 for Mac OS X so the concern about 
Java 6 will get less over time. 

It could be helpful to extend https://github.com/clojars/clojars-web/issues/432 
to support these third party mirrors so people just need to point an Ansible 
script at a server and it will be set up for them. 

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

Re: Clojure community organisation

[Daniel Compton]

Hi Alex

Following up on this, is there anything else you can share?

Thanks, Daniel.

On Tue, Jun 23, 2015 at 9:01 AM Alex Miller <a...@puredanger.com> wrote:

> Thanks for the ping - I don't think I ever heard anything back but I will
> ping again.
>
> Alex
>
>
> On Monday, June 22, 2015 at 3:26:57 PM UTC-5, Daniel Compton wrote:
>>
>> 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.
>
-- 
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: Flow control in Clojure

[Daniel Compton]

Hi Ditlev

I'm answering a question you're not quite asking, but have you tried
looking at http://clojure-liberator.github.io/liberator/? It is built
around the kind of flow control you're trying to apply to HTTP requests,
but is much richer and designed to follow RFC2616.

With respect to your questions:

> 1) decompose functions into smaller functions, regardless of these helper
functions being of no use anywhere else.
> 2) define a bunch of helper functions in a top-level let-expression -
again to avoid having functions which are too heavily indented?

Decomposing your functions into smaller function is good for more than just
code reuse. It is also helpful for testing smaller chunks of code,
isolating pure functions from impure functions, and abstracting out
implementation details. This means when you look at the central function,
you can read through the logic of the code, rather than the implementation
details being mixed in there.

I'd personally split the functions out into smaller functions to make
testing and grokkability easier, but putting them in a let binding isn't a
bad choice either.


On Wed, Dec 9, 2015 at 9:18 AM Ditlev Tøjner  wrote:

> In designing our (by now) two clojure-based REST services we are
> struggling with managing flow-control.
>
> (Disclaimer: earlier backgrounds are with Python, C, Javascript and once
> upon a time Java/C# etc)
>
> What we'd like is to accomplish a series of steps which we feel are
> universal to REST-services.
> In the context of PUT/POST that is:
> ---
> 1. ensure that the content is of a given format (application/json)
>
> 2. receive & validate input
> 2a. if the input is invalid, return error output (in our case describing
> what went wrong)
>
> 3. create a new entry / update an existing entry
> (Note if you know the entire URI, then using PUT for both
> updating/creating is acceptable)
>
> 4. format a response (typically containing the created/updated object)
> ---
>
> Fig1 details how, after several passes, we're dealing with this. The
> approach is heavily inspired
> by Ref1 and essentially executes each step outlined above with the
> understanding that failure might
> occur. If a failure occurs, an error message is returned (of course).
>
> We chose an approach similar to Ref1 because we wanted to abort on errors,
> occasionally recover
> (such as update becoming create if no record is found) and we wanted
> detailed errors which
> precludes the use of (and ...).
>
> The astute observer may note that our model fails to capture the concept
> of recoverable failures
> - update-record* may fail for more reasons than simply not having a row
> (transient errors, actual
> logic-related errors etc) some of which are non-recoverable.
>
> As it stands, this means the function needs refactoring, *again*.
> What all this boils down to is this: given the unique interplay of
> immutability with LISP-style
> (AST) syntax - which techniques are successfully employed to avoid heavily
> indented code ? Is
> the only solution really to either:
>
> 1) decompose functions into smaller functions, regardless of
> these helper functions being of no use anywhere else.
>
> 2) define a bunch of helper functions in a top-level let-expression -
> again to avoid having
>functions which are too heavily indented?
>
>
> Does it ever get easier ? Are we missing something ? It seems extreme to
> reach for monads for
> something of this nature.
>
> References
> 1. https://brehaut.net/blog/2011/error_monads (Ref1)
>
> Fig. 1. - a PUT endpoint
> 
> (defn update*
>   "create/update a pin."
>   [cid source rq]
>   (err/attempt-all
>[_ (chk/mediatype-in? (get rq :content-type) ["application/json"])
> rq (clojure.walk/keywordize-keys rq)
> ;; data which can come from the user
> input (merge {:method "app"
>   :seen_at (-> (at/now-utc) (at/->dt-utc-str))}
>  (get rq :body)
>  {:source_type (get source :type) :source_id (get source :
> id)})
> _ (av/input-valid? validate-pin-params input)
>
>
> ;; additional data extracted from URI & token
> record-data (merge input
>{:cid cid
> :uid (rq->uid* rq)})
> record (err/any (update-record* record-data)
> (new-record* record-data))]
>;; Success
>(rsp/created
> (url cid source)
> {:key-name "pinid"
>  :body {:request (model/transform record)}})
>;; Failure
>err/handle-failure))
>
> 
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> 

Re: [ANN] Clojure 1.8.0-RC3

[Daniel Compton]

Has the case for Direct Linking been well established yet? I've seen a lot
of concerns about it and most benchmarks show marginal at best performance
increases. Tom Crayford ran it against his extensive performance
benchmarking suite and didn't find
 much benefit.

On Thu, Dec 3, 2015 at 5:40 AM Alex Miller  wrote:

> "regularly" == once per week
>
> Additionally, I do a full rebuild for each release.
>
>
> On Wednesday, December 2, 2015 at 10:21:45 AM UTC-6, Nicola Mometto wrote:
>>
>> all the clojure contrib libraries are regularly tested against new
>> clojure versions
>> http://build.clojure.org/
>>
>> > On 2 Dec 2015, at 16:17, Sreenivas Reddy T <
>> thatiparthysreeni...@gmail.com> wrote:
>> >
>> > I would love a project where the tool runs all  test cases of libraries
>> against new release candidate.
>> >
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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-RC1 is now available

[Daniel Compton]

Tom, would you be able to run your performance regression suite against 1.8
with direct linking enabled and share the performance changes?

On Mon, Nov 16, 2015 at 1:19 PM Andy Fingerhut 
wrote:

> With updates I have made in the latest release of Eastwood 0.2.2
> (announced in a separate message), I am seeing pretty much identical
> linting results running Eastwood on about 80 Clojure contrib and 3rd party
> libraries when using Clojure 1.8.0-RC1 as I see with Clojure 1.7.0.  The
> run time is nearly the same -- about 2% longer with 1.8.0-RC1, but I only
> ran each set of tests once, and that could be within the range of
> variability across runs.
>
> Andy
>
>
> On Wed, Nov 11, 2015 at 12:02 PM, Andy Fingerhut  > wrote:
>
>> Results of some testing done on 1.8.0-RC1:
>>
>> Ran 'mvn clean test' on a few OS/JDK combos that are not tested as
>> often.  Reason: there have been (or still are) build or test failures with
>> some of them.  All JDKs listed below were 64-bit.
>>
>> Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_80-b15: ok 3/3 trials
>> Ubuntu 14.04.3 LTS + OpenJDK 1.7.0_85: ok 3/3 trials
>> Ubuntu 14.04.3 LTS + IBM JDK 1.7.0: ok 10/10 trials, as long as failing
>> tests mentioned in http://dev.clojure.org/jira/browse/CLJ-1678 are
>> commented out
>> Ubuntu 14.04.3 LTS + IBM JDK 1.8.0 (based on jdk8u51-b15): same as for
>> IBM JDK 1.7.0
>> Mac OS X 10.11.1 + Oracle JDK 1.8.0_11: ok 631/631 trials
>>
>> There were some JVM crashes during 'mvn test' that I have seen with an
>> earlier version of IBM JDK 1.8.0 (based on jdk8u45-b13), but with the
>> version mentioned above those seem to be gone.  The older one failed 5 out
>> of 10 trials.  The newer one gave passing test results with no JVM crash 10
>> out of 10 trials.
>>
>> I plan to, but haven't yet, compared Eastwood results with 1.8.0-RC1 vs.
>> 1.7.0.  That will take some work before I can give those results, primarily
>> updating Eastwood to work with 1.8.0-RC1.  Eastwood makes some assumptions
>> about the structure of ASTs (abstract syntax trees) that 1.8.0-RC!'s
>> :rettag addition changed.  I don't think it is much work, but not sure when
>> I will be able to get to it.  Until then, I have the following message near
>> the beginning of Eastwood's README:
>>
>> It has been tried with some of the Clojure 1.8.0-alpha versions, but
>> there are known problems there (e.g. incorrect warning about misplaced
>> docstrings, perhaps incorrect warnings about wrong tags, etc.)
>>
>> Andy
>>
>>
>> On Tue, Nov 10, 2015 at 9:30 AM, Alex Miller  wrote:
>>
>>> Clojure 1.8.0-RC1 is now available. *This build is a "release
>>> candidate"!* We would appreciate any and all testing you can do on your
>>> own libraries or internal projects to find problems. If no problems are
>>> found, we expect to make this the 1.8.0 final release!
>>>
>>> Try it via
>>>
>>>- Download:
>>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>>>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>>>
>>> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
>>> here: https://github.com/clojure/clojure/blob/master/changes.md.
>>>
>>>- CLJ-1845  Make
>>>clojure.core/load dynamic so it can be redef'ed even with direct linking
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 

Re: Automate Lein-Exec Deployment

[Daniel Compton]

Hi Asim

You can add the lein-exec plugin to the :plugins section in your
project.clj, people who don't have it in their m2 will download it like any
other dependency.

Your use case may be better handled by building an Uberjar. What you're
describing is one of the primary use cases for using JARs, and you may find
it easier to handle in the long run. However I understand that there is a
bit more overhead going this route.

On Sat, Oct 31, 2015 at 7:09 AM Asim Jalis  wrote:

> I have been using lein-exec a lot for writing quick Clojure scripts. I
> like it because:
>
> - It lets me use deps to pull in dependencies from the REPL.
> - It makes it easy to get started without creating a lot of stuff.
>
> The problem I am running into is this.
>
> I want to share these scripts with people who are not Clojure programmers
> and don't have lein or lein-exec installed on their machines. I can
> automate installing lein using wget.
>
> But there is no similar automated way to install lein-exec. Currently I
> have to tell people to manually add lein-exec to their .lein/profiles.clj.
>
> Is there a way to automate this?
>
> Thanks.
>
> Asim
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.