Re: Immutable names of things?

[Chas Emerick]

No, this is an excellent idea.

Joe Armstrong is probably the most notable modern figure to have written 
and talked about making code content-addressable, with chunks of code (I 
forget the granularity he proposed, probably top-levels?) having names as 
metadata. IIRC, first at https://www.youtube.com/watch?v=lKXe3HUG2l4, then 
here: https://joearms.github.io/published/2015-03-12-The_web_of_names.html

There have been a variety of very niche programming tools that implement 
some variant of this (a single authoritative identifier for a patch of code 
or verse or other data structure, with display names being assigned and 
manipulated separately), but this brings us to the key passage in your 
message IMO:

> The problem is I'm not sure how to do this with a text based programming 
language

And here's the rub: no scheme like this will work or scale in the 80xN grid 
to which we've confined ourselves. That's IMO of course; I'll save you from 
opining further, I guess. :-)

Projectional / structural editors are absolutely a thing though, so you'll 
find a lot if you search along those terms. A dedicated (but quiet) 
subreddit actually popped up on the topic not too long ago:

https://www.reddit.com/r/nosyntax/

Have fun,

- Chas

On Thursday, December 7, 2017 at 12:37:10 AM UTC-5, Didier wrote:
>
> Warning: This is the spawn of an idea, not very well refined, and that is 
> little extravagant.
>
> I've been doing some hammock time, and I've been thinking that names in a 
> programming language are kind of a complecting of two things, the human 
> readable form, and the machine identifier. What if a function always had 
> the same name, which never changed, from the moment the function was 
> created. This would be fine, until a human finds it didn't like the name 
> anymore, and thus a refactor of the name would occur, requiring to change 
> all references to the function. This is also true say of a spec, if you 
> want to change the name of the spec, its a big refactor to update all usage 
> of it. So var names and spec names are troubling in that if humans want to 
> refer to it differently, they also break all machine reference to them.
>
> So I thought, how awesome would it be if each named things in a 
> programming language would be given a unique machine name, which can be 
> used everywhere, and the name you saw was just meta-data for the programmer 
> to have a more human readable/descriptive name.
>
> The problem is I'm not sure how to do this with a text based programming 
> language. I can imagine a language where constructs would be first class, 
> not based on text, and thus all construct could be assigned a unique id and 
> a name, and the IDEs could easily hide the unique ids and project a view of 
> the construct with the human name instead. Code would be stored in a 
> structured format, and obviously a standard editor would not work, and an 
> IDE of some form would be required.
>
> So right now, my idea is that maybe you can compromise. If you added 
> support for Vars and specs, so that they can have like a doc-name. It would 
> be like a doc-string a bit, but it expects a name instead. That name could 
> be the human readable name, you could change it freely. The normal var name 
> or spec name would continue to be used as normal to refer to this var/spec 
> from other code. At its most basic it means you can have the normal name be 
> anything, maybe a name you don't like that much, or you could go further 
> and make it a guid if you want. Then you could make the doc-name the name 
> you want to use when talking to other people, or when people read the code. 
> Now IDEs could support this doc-name, so they could show the doc-name in 
> place everywhere you have code referring to the normal name. They could 
> auto-complete from doc-name to normal name, etc.
>
> So an IDE could still kind of hide this for you, and make it appear like 
> everything is just doc-name pointing to each other, and refactoring would 
> not require changing all code that refers to it, but actually its just a 
> change of the doc-name on the var or spec being pointed to, but the IDE 
> could quickly replace the new doc-name in place of the normal name 
> everywhere else.
>
> Where it would be maybe a bit more confusing, is when using an editor that 
> would not support doc-names to that extent. In those cases, you can ignore 
> doc-name, consider it just like one more piece of documentation.
>
> Doc-name could be optional too, so if you plan on working by yourself, or 
> just in a simple editor, you can ignore this whole thing and work as normal.
>
> Now maybe this whole thing is solved by having a powerful renaming 
> refactoring tool that can hunt for all usage and update the name everywhere 
> in a sound way, but that's harder to do in Clojure, and still breaks when 
> its a library for example, as you can't just refactor all consumers without 
> having both access to their code base, and even if you do, 

Re: Migrating nREPL out of Clojure Contrib

[Chas Emerick]

A final update:

https://github.com/cemerick/nREPL has been reconstituted as described
previously, and a release candidate has been deployed to maven central
with contents effectively identical to the latest tools.nrepl release
(only difference is an ipv6-related bugfix that was encountered in the
process of setting up travis ci).

This is all to say that things are underway! I'll stop posting updates
here, so if you're interested, you can continue to track
https://github.com/cemerick/nREPL/issues/1 for the final first release,
and the issue tracker on github is also now populated with things from
JIRA that will get burned down prior to a 1.0.0 release.

All the best,

- Chas

On 10/9/2017 14:59, Chas Emerick wrote:
> I have opened two issues on the original nREPL repo:
>
> 1. Describing the background and rationale for the work to be done:
> https://github.com/cemerick/nREPL/issues/1
>
> 2. Enumerating the nREPL contributors to obtain explicit permission for
> their commits to be distributed under the terms of EPL only (i.e. absent
> the terms of the CA that governed their contribution to the tools.nrepl
> project): https://github.com/cemerick/nREPL/issues/2
>
> Once #2 is complete, then the list of tasks in #1 will be burned down.
> We'll then have a 100% compatible nREPL release out the door with
> different maven coordinates, etc., and those that are interested in
> contributing will be able to do so straightforwardly.
>
> Cheers,
>
> - Chas
>
> On 8/3/2017 00:36, Bozhidar Batsov wrote:
>> So, what's the next step here?
>


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

Re: Migrating nREPL out of Clojure Contrib

[Chas Emerick]

I have opened two issues on the original nREPL repo:

1. Describing the background and rationale for the work to be done:
https://github.com/cemerick/nREPL/issues/1

2. Enumerating the nREPL contributors to obtain explicit permission for
their commits to be distributed under the terms of EPL only (i.e. absent
the terms of the CA that governed their contribution to the tools.nrepl
project): https://github.com/cemerick/nREPL/issues/2

Once #2 is complete, then the list of tasks in #1 will be burned down.
We'll then have a 100% compatible nREPL release out the door with
different maven coordinates, etc., and those that are interested in
contributing will be able to do so straightforwardly.

Cheers,

- Chas

On 8/3/2017 00:36, Bozhidar Batsov wrote:
> So, what's the next step here?


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

Re: Migrating nREPL out of Clojure Contrib

[Chas Emerick]

Of course, my aim would be to gather as much consensus as possible
around a single nREPL vector; this thread is the first effort in service
of that, with presumably much more ahead. An obvious move for example
would be to shim out the legacy namespaces until a major version number
change, so that migrating would involve only swapping some
project.clj/pom.xml coordinateswhere things go from there would be
as much up to the community as anything else.

- Chas

On 7/18/2017 17:30, Phil Hagelberg wrote:
> Thanks for continuing to maintain this lib, Chas; I'm glad to see this
> move to make it more accessible to potential contributors.
>
> I believe the original choice of the EPL was made specifically to
> support this kind of scenario. Personally I see a reboot as being a
> lot of effort for little gain, but then again it's neither my effort
> going into it nor my gain coming out of it. Besides, everyone's doing
> reboots these days.
>
> I do suspect that a reboot will lead to a longer transition time in
> which both org.clojure/tools.nrepl and com.cemerick/nrepl are in
> active use by greenfield projects, so perhaps if you do a reboot you
> could cut an 0.2.12 release under the new group-id which has a stable
> known-good version and then do the reboot under a 1.x series or
> something. This might help alleviate the concerns raised by Colin more
> quickly.
>
> -Phil
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/6SX7q39lK90/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

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

Re: Migrating nREPL out of Clojure Contrib

[Chas Emerick]

On 7/18/2017 14:40, Alex Miller wrote:
>
> If all of the nontrivial contributors to the project decide they
> want to change the license later, do we also need to obtain Rich's
> assent?
>
>
> This has nothing to do with Rich or the contributors. The project is
> available as open source under a license and you may only modify and
> distribute the code under the terms of the license. In this case, EPL
> requires that derivative code be released under EPL afaik.

My point was that the license under which code is distributed can be
changed, with the assent of all contributors. (One of the practical
rationales of CAs is that the assignee then has ultimate latitude to
change the license, without having to clear that administrative hurdle.)
If in some future where project X is forked to be independent of an
entity that previously was a (yes, joint) copyright assignee, do the
project leads for X have to obtain that entity's agreement in order to
change the license? Questions about relicensing are sort of comical IMO
in the context of a project the size and importance of nREPL, but they
and everything else related to licensing questions come up on a regular
basis in the context of having a CA, and the answers end up mattering to
contributors.

>  
>
> (Parenthetically, it strikes me as very strange for a project to
> have a
> copyright assignment to an individual that hasn't lodged any
> commits, at
> least insofar as the project gone "solo". It's interesting that I
> don't
> have that intuition if the assignee is an org like Apache or
> whatever, a
> discrepancy that I'll have to think on.)
>
>
> Afaik, this is not at all strange and is (legally) the exact same
> thing. Note that the copyright assignment in the Clojure Contributor
> Agreement is a *joint* copyright ownership. While rights are granted
> to Rich, they are also fully retained by the original author, which
> may imply that a "reboot" could include your original work and make
> derivatives of it without being pursuant to whatever the contrib
> version is doing. That would not automatically to other authors
> changes, but presumably they could make the same determination. Again,
> this is not legal advice, and this may not be correct - please read
> the CA and pursue better advice to make that judgement.

Yes, it's legally the same thing, but I don't think it'd be
controversial to say that assigning copyright to an individual has very
different practical and qualitative consequences compared to an
organization like Apache or FSF or Linux Foundation. Reams more could be
written about CAs and foundations (or not) and all that, but this is
already treading too far OT. :-)

FWIW, I had intended my legal questions previously to be rhetorical
(though I appreciate the qualified answers that confirmed my
intuitions); I think the broader point is that, insofar as an
independent project isn't going to benefit from being in contrib any
longer, if it's possible, I see no reason to carry that legacy. For
better or worse, the commit history of nREPL is such that a reboot is
quite reasonable as you describe, i.e. taking my commits, re-forming a
project, and applying all of the changes from other contributors that
agree to come along. Any differential is going to be relatively trivial
to straighten out.

(Sorry for any duplicate mails. I'm out of practice w.r.t. ML reply-all
habits!)

- Chas

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

[Chas Emerick]

To be clear ("well ACTUALLY" :-P), development hasn't ceased, just
slowed to a trickle. (There are commits this year, so there?) Part of
that is nREPL being intentionally a slow-moving bit of bedrock for other
people to build on. That's not to discount my original stipulations (1)
and (2) ofc.

Forking is obviously easiest. Like I said, anyone can do that anytime.

The benefit to rebooting is to shake off whatever responsibilities or
constraints are associated with the (eventually prior) copyright
assignment. What happens to a codebase that is subject to a CA that is
forked elsewhere? Are future contributions subject to that CA? I assume
not, but IANAL. Does the "Copyright (c) Rich Hickey" banner that's
supposed to be on all files stay there permanently? Pretty sure, but
IANAL. If all of the nontrivial contributors to the project decide they
want to change the license later, do we also need to obtain Rich's
assent? I have no idea. Do I want to maintain explanations of the right
answers to these kinds of questions for a (fork of a) project that's no
longer within contrib? Most definitely not.

(Parenthetically, it strikes me as very strange for a project to have a
copyright assignment to an individual that hasn't lodged any commits, at
least insofar as the project gone "solo". It's interesting that I don't
have that intuition if the assignee is an org like Apache or whatever, a
discrepancy that I'll have to think on.)

That was a good question! Answering helped clarify things for me:
specifically, if I'm going to maintain the project outside of contrib, I
will reboot it as previously described.

Thanks,

- Chas

On 7/18/2017 13:19, Dan Larkin wrote:
> Hi Chas!
>
> This is great news, I'm glad to hear development will resume. What's the 
> downside to just forking? aka why bother rebooting from scratch?
>
>
>> On Jul 18, 2017, at 05:48, Chas Emerick <c...@cemerick.com> wrote:
>>
>> Hi all,
>>
>> I've been approached many, many times over the years (and more frequently 
>> since the development and inclusion of socket-repl) about the potential of 
>> moving nREPL[1] out of clojure contrib…either back to its original 
>> location[2], or under one of the various Clojure community organizations. 
>> I've generally demurred or ghosted on these suggestions, sometimes out of a 
>> lack of time/attention, and often out of just not wanting to stir the pot. 
>> The pace of them has quickened somewhat lately though, and I'd like to put 
>> the whole topic to bed and hopefully get the project to a better footing in 
>> the process.
>>
>> First, to stipulate a few things:
>>  • nREPL is an essential bit of infrastructure in Clojure tooling
>>  • On balance, I have neglected the project in recent years, to the 
>> detriment of all of the users of the aforementioned tooling.
>>  • On balance, contributors and potential contributors have been less 
>> involved (or turned away entirely) because of the well-known friction that 
>> comes with the contrib process and requirements. (tbh, this is a factor in 
>> #2, though not the majority)
>>  • No one (least of all me) would object to nREPL having its 
>> contribution process managed through github or gitlab.
>> So basically everyone wants nREPL to be a "regular" project, and subject to 
>> and beneficiary of the same expectations as 99.9% of all of the other OSS 
>> projects we all interact with daily. How does that happen?
>>
>>
>>
>> The only routes AFAICT are:
>>
>>  • to fork back elsewhere, which would require keeping the EPL license 
>> and copyright assignment of the current codebase. Literally anyone can do 
>> this at any time, without any coordination with anyone else.
>>  • for me to reboot the project. This would not be difficult given I 
>> "own" the vast majority of the project's commits. This would allow for the 
>> elimination of the copyright assignment, and potentially a different license 
>> (I'm partial to MPLv2, but we'll see). If this route is taken, we could set 
>> up a project issue where the other contributors of nontrivial patches could 
>> agree (or not) to the reconstitution of their code w/o the copyright 
>> assignment, etc.
>> In either case, this "new" nREPL project's artifacts would end up being 
>> distributed under a different maven groupId (`com.cemerick`, if I'm to 
>> continue deploying, etc). The clojure-contrib nREPL project remain, and any 
>> releases that are done from it after the fork/reboot would continue to be 
>> under the `org.clojure` coordinates. Downstream projects need to choose 
>> whether or not to change dependencies; I'd expec

Migrating nREPL out of Clojure Contrib

[Chas Emerick]

Hi all,

I've been approached many, many times over the years (and more frequently 
since the development and inclusion of socket-repl) about the potential of 
moving nREPL[1] out of clojure contrib…either back to its original 
location[2], or under one of the various Clojure community organizations. 
I've generally demurred or ghosted on these suggestions, sometimes out of a 
lack of time/attention, and often out of just not wanting to stir the pot. 
The pace of them has quickened somewhat lately though, and I'd like to put 
the whole topic to bed and hopefully get the project to a better footing in 
the process.

First, to stipulate a few things:

   1. nREPL is an essential bit of infrastructure in Clojure tooling
   2. On balance, I have neglected the project in recent years, to the 
   detriment of all of the users of the aforementioned tooling.
   3. On balance, contributors and potential contributors have been less 
   involved (or turned away entirely) because of the well-known friction that 
   comes with the contrib process and requirements. (tbh, this is a factor in 
   #2, though not the majority)
   4. No one (least of all me) would object to nREPL having its 
   contribution process managed through github or gitlab.

So basically everyone wants nREPL to be a "regular" project, and subject to 
and beneficiary of the same expectations as 99.9% of all of the other OSS 
projects we all interact with daily. How does that happen?


The only routes AFAICT are:

   1. to fork back elsewhere, which would require keeping the EPL license 
   and copyright assignment of the current codebase. Literally anyone can do 
   this at any time, without any coordination with anyone else.
   2. for me to reboot the project. This would not be difficult given I 
   "own" the vast majority of the project's commits. This would allow for the 
   elimination of the copyright assignment, and potentially a different 
   license (I'm partial to MPLv2, but we'll see). If this route is taken, we 
   could set up a project issue where the other contributors of nontrivial 
   patches could agree (or not) to the reconstitution of their code w/o the 
   copyright assignment, etc.

In either case, this "new" nREPL project's artifacts would end up being 
distributed under a different maven groupId (`com.cemerick`, if I'm to 
continue deploying, etc). The clojure-contrib nREPL project remain, and any 
releases that are done from it after the fork/reboot would continue to be 
under the `org.clojure` coordinates. Downstream projects need to choose 
whether or not to change dependencies; I'd expect the vast majority of 
future motion to gravitate to the reboot, but that's just speculation at 
this point.


I would like to hear *here* (no more private mails, please! :-) from any 
nREPL users, contributors, etc. As much as possible, I would like *not *to 
debate/re-litigate the merits of contrib and its process here; let's focus 
on what steps will yield the best outcome for nREPL and its stakeholders.


Thanks!


- Chas

[1] https://github.com/clojure/tools.nrepl/
[2] https://github.com/cemerick/nrepl

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

[Chas Emerick]

I only became aware of this conversation yesterday; hopefully no one was 
looking for my reply earlier…

Anthony was a friend, but our project activity was quite separate. I think 
we had a couple of PRs on each other's projects, but that's about it. I 
don't think I have any particular authority in this area, either. In any 
case, I don't have any bandwidth atm for increasing my involvement in 
general-purpose OSS stuff.

I'd suggest that anyone with an important dependency on one of Anthony's 
projects push them forward independently. At least, don't wait for or rely 
upon other volunteers to coordinate these sorts of things. If there end up 
being multiple forks, etc., that'll work out over time. Especially if you 
represent a ~trusted organization (CircleCI being a reasonable example), 
and are accommodating of others' use cases within reason (i.e. act like a 
sane maintainer), then I suspect others will follow your lead.

The clojars/maven coordinate question is stickier. The clojars folks might 
have general policy, and maybe they've addressed this particular situation 
elsewhere. But, this is an excellent object lesson in how the 
organization/project-name convention is a *good thing*, in contrast to 
effectively single-level namespace coordinates like tentacles/tentacles. 
IMO, a com.circleci/tentacles artifact in clojars would be a far better 
direction; it puts multiple forks (if they end up being necessary) on equal 
footing, and properly reflects the divergence in maintenance.

Thanks for picking up where Anthony left off,

- Chas

On Thursday, January 26, 2017 at 7:41:46 PM UTC-5, Alex Miller wrote:
>
> I have no authority to speak on this, but I think it would be nice to see 
> a consensus fork managed by some one or ones with a vested interest in it. 
> (I also have used tentacles off and on.)
>
> Maybe another option would be to create a github org of some people that 
> can act as admins. I'd nominate Chas as someone to act in that capacity 
> given his relationship with raynes.
>

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

RIP Anthony Grimes (Raynes)

[Chas Emerick]

As some may have already seen on Twitter or other channels, our friend 
Anthony Grimes (Raynes in #clojure IRC and elsewhere, @StRaynes on 
Twitter) has passed away.


The most immediate announcement of this came via Lance Bradley, one of 
Anthony's closer friends from the Clojure community:


https://www.facebook.com/lancepantz/posts/10104155686547809?pnref=story

Anthony's family set up a fundraiser to help with his final expenses, 
but people are going well beyond the target set there; in any case, the 
family would certainly appreciate any help you can offer:


https://www.gofundme.com/32m55h4

If you don't know of Anthony, he was a constant inspiration and helping 
hand in Clojure's earlier days, especially in #clojure IRC where he 
tutored and encouraged people daily for years. He was also the creator 
or a significant contributor to dozens of Clojure projects, some of 
which I guarantee you still rely upon every day.


Anthony himself wrote about some of his history in the Clojure 
community, and also happened to recount at length the most significant 
memory I'll have of him, when we all helped to get a kind 16-year-old to 
the first Clojure Conj in 2010: 
http://blog.raynes.me/blog/2011/11/27/the-clojure-community-and-me/


I have other memories of and about Anthony that I'd like to share, but 
not now, not yet. Of course, the family will be having a local service 
for him in their time and way. ABecause so many people around the world 
knew, worked with, and called Anthony a friend, I'm hoping we can all 
have an online/remote memorial (maybe an any-comers Hangout or 
something). That's just an idea at the moment, details TBD.


If you'd like to talk a bit about how Anthony influenced or inspired 
you, please feel free to, here. Some people are also using the 
#RIPRaynes hashtag, if that's your game.


Rest easy, dude.

love,

- Chas

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Chas Emerick]

Hi all; here to satisfy the quarterly quota to maintain my status as 
"that guy".


This is a questionable proposal. It:

* introduces completely orthogonal, transient concerns (presentation) 
into code, ideally a canonical, long-lived source-of-truth

* sets up a bikeshed at the top of every def* form
* adopts idiosyncratic implementation details of a particular editor's 
language support (the defrecord example's :indent is particularly obtuse 
IMO, even if you are aware of how clojure-mode is implemented)


I *think* I coined the "always two spaces" shorthand for the 
(admittedly, minority) position that list forms should be formatted 
completely regularly, so as to:


* make formatting a trivial operation, not requiring any "real" reading
* eliminate this entire topic

Here's the first time I talked about this IIRC: 
https://groups.google.com/forum/#!msg/clojuredev-users/NzKTeY722-I/3hmNvJulcksJ


Best,

- Chas

On 09/13/2015 06:06 AM, Artur Malabarba wrote:


Hi everyone,


Over at CIDER we're adding a feature where the author of a macro (or 
function) can specify how that macro should be indented by adding an 
|:indent| metadata to its definition. This way the editor (and other 
tools, like cljfmt) will know what's the proper way of indenting any 
macro (even those custom-defined) without having to hardcode a 
bajillion names.


Here's an example of how you specify the indent spec for your macros


|(defmacro with-out-str "[DOCSTRING]" {:indent 0} [& body] ...cut for 
brevity...) (defmacro defrecord "[DOCSTRING]" {:indent [2 nil nil 
[1]]} [name fields & opts+specs] ...cut for brevity) (defmacro 
with-in-str "[DOCSTRING]" {:indent 1} [s & body] ...cut for brevity...) |



We'd like to hear any opinions on the practicality of this (specially 
from authors of other editors).
Below, I'll be saying “macros” all the time, but this applies just the 
same to functions.




*Special arguments*


Many macros have a number of “special” arguments, followed by an 
arbitrary number of “non-special” arguments (sometimes called the 
body). The “non-special” arguments have a small indentation (usually 2 
spaces). These special arguments are usually on the same line as the 
macro name, but, when necessary, they are placed on a separate line 
with additional indentation.


For instance, |defrecord| has two special arguments, and here's how it 
might be indented:


|(defrecord TheNameOfTheRecord [a pretty long argument list] SomeType 
(assoc [_ x] (.assoc pretty x 10))) |



Here's another way one could do it:

|(defrecord TheNameOfTheRecord [a pretty long argument list] SomeType 
(assoc [_ x] (.assoc pretty x 10))) |


/
/

/The point of the indent spec is *not* to specify how many spaces to 
use./



The point is just to say “a defrecord has *2* special arguments”, and 
then let the editor and the user come to an agreement on how many 
spaces they like to use for special and non-special arguments.




*Internal indentation*


The issue goes a bit deeper. Note the last argument in that 
|defrecord|. A regular function call would be internally indented as


|(assoc [_ x] (.assoc pretty x 10)) |

But this is not a regular function call, it's a definition. So we want 
to specify this form internally has 1 special argument (the arglist 
vector), so that it will be indented like this:


|(assoc [_ x] (.assoc pretty x 10)) |

The indent spec we're working on does this as well. It lets you 
specify that, for each argument beyond the 2nd, if it is a form, it 
should be internally indented as if it had 1 special argument.




*The spec*


An indent spec can be:

  * |nil| (or absent), meaning /“indent like a regular function call”/.
  * A vector (or list) meaning that this function/macro takes a number
of special arguments, and then all other arguments are non-special.
  o The first element of this vector is an integer indicating how
many special arguments this function/macro takes.
  o Each following element is an indent spec on its own, and it
applies to the argument on the same position as this element.
So, when that argument is a form, this element specifies how
to indent that form internally (if it's not a form the spec is
irrelevant).
  o If the function/macro has more aguments than the vector has
elements, the last element of the vector applies to all
remaining arguments.
  * If the whole spec is just an integer |n|, that is shorthand for |[n]|.



  *Examples*


So, for instance, if I specify the |defrecord| spec as |[2 nil nil 
[1]]|, this is saying:


  * |defrecord| has 2 special arguments
  * The first two arguments don't get special internal indentation
  * All remaining arguments have an internal indent spec of |[1]|
(which means only the arglist is indented specially).

Another example, |reify| is |[1 nil [1]]| (which should be easy to see 
now).


|(reify Object (toString [this] (something) else "here")) |


For 

Re: JSON authentication with cemerick/friend?

[Chas Emerick]

Friend requires some ring middleware, including the keyword params 
middleware. Not having it included in your app will produce this. If you 
are using Compojure's handler middlewares, this is done for you.


This particular example is broken because you're applying the middleware 
in the wrong order. Try:


(- app-routes
  (friend/authenticate ...)
  handler/api)

Any Friend questions can be posted to the clojure-sec ML, where they'll 
get more attention.


Thanks,

- Chas

On 04/23/2014 06:27 PM, Ivan Schuetz wrote:

Hi,

I'm trying to get a simple use case running - send a login request to 
/login and get success or fail response, preferably in JSON format.


I followed the example in https://github.com/cemerick/friend#workflows


(def users {root {:username root
:password (creds/hash-bcrypt admin_password)
:roles #{::admin}}
jane {:username jane
:password (creds/hash-bcrypt test)
:roles #{::user}}})


(defroutes app-routes

  (GET /test [] {:body {:my-map helo}})
  (route/resources /)
  (route/not-found Not found))

(def app
  (-
  (handler/api app-routes)
  (middleware/wrap-json-body)
  (middleware/wrap-json-response)

   (friend/authenticate {:credential-fn (partial 
creds/bcrypt-credential-fn users)

:workflows [
(workflows/interactive-form)]})
  )
  )



I'm testing with curl:

curl -v --data username=janepassword=test http://localhost:3000/login

Or:

curl -v --request POST 
 http://localhost:3000/login?username=janepassword=test;


And I get:

* About to connect() to localhost port 3000 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 3000 (#0)
 POST /login?username=janepassword=test HTTP/1.1
 User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 
OpenSSL/0.9.8y zlib/1.2.5

 Host: localhost:3000
 Accept: */*

 HTTP/1.1 302 Found
 Date: Wed, 23 Apr 2014 22:25:15 GMT
 Location: http://localhost:3000/login?login_failed=Yusername=
 Content-Length: 0
 Server: Jetty(7.6.8.v20121106)

* Connection #0 to host localhost left intact
* Closing connection #0


This looks like authentication failed, but the data is correct. I 
reviewed the curl request, and this seems to be the correct way to 
send a POST. But username= gives me the impression it's not being 
parsed correctly.


Also, how can I get a JSON response instead of a header?

Thanks.

P.S. Maybe it would be positive if this library has an own Google Group.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com 
mailto:clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: cljsbuild hooks + rsync/ssh

[Chas Emerick]

That does sound very questionable, but you should be able to wire this 
up using :notify-command:


https://github.com/emezeske/lein-cljsbuild/blob/master/sample.project.clj#L73

- Chas

On 03/22/2014 07:06 AM, t x wrote:

Hi,

   This sounds sorta silly:

   I'm already running lein cljsbuild auto

   Now, whenver the build completes (definitely when it succeeds; I
don't care what happens when it fails), I would like to trigger an
rsync or ssh to copy the resources/release/*.js files to a remote
machine.

   Is there a standard way to setup these hooks?

Thanks!

My situation is as follows:

   *.cljs files are on my laptop
   lein is on my laptop

   actual webserver is a weak digital ocean droplet

   whenever my (relatively powerful) laptop finishes compiling, I want
my *.js files sent over to the droplet



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

To unsubscribe from this group 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: rant / cljs in cljs ? :-)

[Chas Emerick]

Despite numerous requests, I have so far resisted integrating cljsbuild, 
cljx, and clojurescript.test.  I noted my sentiments on this topic in a 
comment here some time ago:


https://github.com/lynaghk/cljx/issues/25

I haven't thought about it much since then, but I suspect I will relent 
at some point.  That said, any integration amongst these various tools 
will need to be open enough that alternatives can be used as desired 
(e.g. surely clojurescript.test is not the last word in ClojureScript 
testing??).


- Chas

On 03/22/2014 05:26 AM, t x wrote:

I stopped using cljx, and lein cljsbuild auto is amazingly fast.

It does look like timing issues / how cljx/cljsbuild auto triggers
work is the issue.

Someone (that happens to be suffering more from this issue) please fix it. :-)

On Fri, Mar 21, 2014 at 4:31 PM, Moritz Ulrich mor...@tarn-vedra.de wrote:

I really hope that a small plugin to coordinate cljx/cljsbuild will show
up in the near future. I found cljsbuild's crossovers much better
integrated and easier to use (but still far inferior to cljx).

I agree that a REPL based workflow is much superior, especially with
tools like Om which remove the need to coordinate DOM updates.

Chas Emerick writes:


This particular trick is a clever one (that I'm afraid I've had some
hand in propagating, for the benefit of those that like an  auto +
browser refresh workflow), but it's never going to be particularly
efficient.  By its very nature, pdo sets up cljx and cljsbuild off and
running without any coordination; it's equivalent to running the two
tasks in separate processes.

It's possible that some hooks may become available in cljsbuild so that
things like cljx can do what they like prior to each compile, but that's
speculative.

IMO, a REPL-based workflow is far superior to anything involving
reloading your app's page, insofar as you can (nearly always) apply the
changes you're working on without blowing away the state of the app.  In
this context, cljx's nREPL middleware excels (but unfortunately cannot
be used with the stock ClojureScript browser-REPL; check out Austin).

Note that cljx has not been optimized _at all_.  It's fast enough for
my purposes (i.e. reasonable when doing a clean rebuild, and snappy when
doing the small changes typical in a REPL). I'd be happy to merge
reasonable patches that make the actual cljx transformation faster.

- Chas

On 03/21/2014 01:23 PM, t x wrote:

I'm using:

lein pdo cljx auto,cljsbuild auto dev'

However, maybe perhaps it's weird timing interaction between cljx and
cljsbuild that's making the lag appear more than it actually is.

On Fri, Mar 21, 2014 at 8:27 AM, David Nolen dnolen.li...@gmail.com wrote:

Unless you're compiling a very large file - with auto :optimizations :none
you should always get sub-second compile times under auto.

David


On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge tbaldri...@gmail.com
wrote:

are you using lein cljsbuild auto ? That's what I use, and I get about
1-3 sec recompile times for stuff that uses core.async.

Timothy


On Fri, Mar 21, 2014 at 12:48 AM, t x txrev...@gmail.com wrote:

Hi,

*  I'm already using:

:incremental true
:compiler { :optimizations :none }

* I'm also aware of cljs brepl


However:

1) the cljs compiler is still too slow for my liking (even though it's
not calling closure)

2) I don't like the cljs repl nearly as much as I like the clj repl


Now, my dumb/stupid question:

Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
with an interpreter that runs 10x slower, if, in exchange, I get to
hit refresh and my new code starts running.

Furthermore, I'm _okay_ with their being a big delay every time I
introduce a new macro from clj land.


I realize this sounds spoiled -- but -- the cljs compiler delays are
really really breaking my flow.


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.



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

--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send

Re: rant / cljs in cljs ? :-)

[Chas Emerick]

This particular trick is a clever one (that I'm afraid I've had some 
hand in propagating, for the benefit of those that like an  auto + 
browser refresh workflow), but it's never going to be particularly 
efficient.  By its very nature, pdo sets up cljx and cljsbuild off and 
running without any coordination; it's equivalent to running the two 
tasks in separate processes.


It's possible that some hooks may become available in cljsbuild so that 
things like cljx can do what they like prior to each compile, but that's 
speculative.


IMO, a REPL-based workflow is far superior to anything involving 
reloading your app's page, insofar as you can (nearly always) apply the 
changes you're working on without blowing away the state of the app.  In 
this context, cljx's nREPL middleware excels (but unfortunately cannot 
be used with the stock ClojureScript browser-REPL; check out Austin).


Note that cljx has not been optimized _at all_.  It's fast enough for 
my purposes (i.e. reasonable when doing a clean rebuild, and snappy when 
doing the small changes typical in a REPL). I'd be happy to merge 
reasonable patches that make the actual cljx transformation faster.


- Chas

On 03/21/2014 01:23 PM, t x wrote:

I'm using:

lein pdo cljx auto,cljsbuild auto dev'

However, maybe perhaps it's weird timing interaction between cljx and
cljsbuild that's making the lag appear more than it actually is.

On Fri, Mar 21, 2014 at 8:27 AM, David Nolen dnolen.li...@gmail.com wrote:

Unless you're compiling a very large file - with auto :optimizations :none
you should always get sub-second compile times under auto.

David


On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge tbaldri...@gmail.com
wrote:

are you using lein cljsbuild auto ? That's what I use, and I get about
1-3 sec recompile times for stuff that uses core.async.

Timothy


On Fri, Mar 21, 2014 at 12:48 AM, t x txrev...@gmail.com wrote:

Hi,

*  I'm already using:

   :incremental true
   :compiler { :optimizations :none }

* I'm also aware of cljs brepl


However:

1) the cljs compiler is still too slow for my liking (even though it's
not calling closure)

2) I don't like the cljs repl nearly as much as I like the clj repl


Now, my dumb/stupid question:

   Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
with an interpreter that runs 10x slower, if, in exchange, I get to
hit refresh and my new code starts running.

   Furthermore, I'm _okay_ with their being a big delay every time I
introduce a new macro from clj land.


   I realize this sounds spoiled -- but -- the cljs compiler delays are
really really breaking my flow.


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.




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

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


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

Re: CLJX CLJS problem

[Chas Emerick]

This isn't really right.  :source-paths are for your _sources_, not a 
place to drop in whatever paths you want either on the classpath or 
included in jar files, etc.  Also, all generated content should go into 
`target/*`, so that `lein clean` will have its intended effect 
(eliminating all artifacts of previous build / project mgmt activities).


(Some tools [definitely Counterclockwise, perhaps other IDE plugins as 
well?] also use the value of :source-paths to configure go-to-definition 
operations and such, so including non-source directories in 
:source-paths will generally yield undesirable effects there.)


When it builds jars, Leiningen includes resources from :source-paths, 
:resource-paths, and :compile-path; the latter is almost never 
customized, and defaults to target/classes.


So, you should put your cljx sources in :source-paths.  You should have 
cljx generate transformation results into some directory under 
`target/`. If you want to redistribute the results, you should either 
generate cljx results into `target/classes`, or investigate Leiningen's 
(plethora of) options for customizing jar contents; see e.g. 
https://github.com/technomancy/leiningen/blob/stable/sample.project.clj#L331


FWIW, that isn't cljx-specific at all; the same applies to Clojure 
sources that are being AOT-compiled, and with a tweak, to Java sources 
to be javac-compiled.


cljsbuild produces *JavaScript* output, so its configuration is never 
going to be relevant to whether or not ClojureScript resources produced 
by cljx can be consumed by downstream projects.


Dave, thanks for the PR; I'll reply separately to that on github.

- Chas

On 02/13/2014 10:06 PM, Dave Della Costa wrote:

Hi Karsten,

Strangely, I was doing the exact same thing as you yesterday and
struggled for a bit until I found settings that work.

I achieved success when I used the configuration from Cornice as a template:

https://github.com/rkneufeld/cornice/blob/master/project.clj

...with one exception, my cljsbuild config contained only

:cljsbuild {:builds [{:source-paths [target/generated/cljs]}]}

vs. all the extra jar config and one not.  If I recall correctly, I was
getting the java.util.zip.ZipException: duplicate entry you mention
until I removed the extra settings in cljsbuild.

Looking at your config I also suspect you want


:source-paths [src-cljs]

instead of


:source-paths [src-clj src-cljs]

in your cljsbuild config.

However, when I leave the cljsbuild configuration out completely, it
seems to have no bearing on whether or not I can use the generated cljs
files when including the library in another project.  I suspect the
:jar true setting is only relevant if you have strictly cljs files
that need to be included--it seems like cljx has its own orthogonal
build process which automatically includes cljs files in the jar file
but I haven't dug into the code yet to confirm.  This is just based on
testing what happens when I tweak config settings (Kevin or Chas please
let me know if I'm off-base here).

What does seem to make all the difference is the sourcepaths settings,
which it doesn't seem you have:

:source-paths [src target/generated-src/clj target/generated-src/cljs]

I needed this before I could see the clj/cljs files getting included in
my library jar.

Obviously, adjust all paths to fit your specific configuration.

I've made a pull request to add a bit of further explanation on using
cljx in libraries, as it would be helpful if this didn't require looking
up how others had done it to figure it out!

https://github.com/lynaghk/cljx/pull/30

Hope this helps--

Best,
Dave

(2014/02/13 20:22), Karsten Schmidt wrote:

I've been busy working on a few libraries targetting both Clojure 
ClojureScript, however so far have only tested the CLJ side and now that
it comes to addressing CLJS am running in circles (and on fumes)
unsuccessfully trying to tweak my project settings to make things work.

All my source is using CLJX stored in the the src-cljx folder. My
rules then trigger generated sources into src-clj (for all Clojure and
shared macros) and src-cljs for CLJS parts only.

My project.clj is as follows:

(defproject foo 0.1.0-SNAPSHOT
   :dependencies [[org.clojure/clojure 1.5.1]
  [org.clojure/clojurescript 0.0-2156]]
  
   :jar-exclusions [#\.cljx|\.DS_Store|\.js|\.html]


   :cljx {:builds [{:source-paths [src-cljx]
:output-path src-clj
:rules :clj}
   {:source-paths [src-cljx]
:output-path src-cljs
:rules :cljs}]}

   :cljsbuild {:builds
   [{:id dev
 :source-paths [src-clj src-cljs]
 :compiler
 {:pretty-print true
  :output-to foo-0.1.0-SNAPSHOT.js
  :optimizations :simple}
 :jar true}]}

   :plugins [[com.keminglabs/cljx 0.3.2]
 [lein-cljsbuild 1.0.2]]
   :hooks [cljx.hooks 

Re: CLJX CLJS problem

[Chas Emerick]

I've added a sample.project.clj file to the cljx repo and pointed to it 
from the README.  I can see how the confusion may have gotten started 
due to a particular detail in the example configuration snippet that was 
in the README, which is also fixed.


If someone wants to submit a patch so that `lein cljx sample` dumps that 
to stdout (similar to `lein cljsbuild sample`), I'd be interested in that.


Thanks,

- Chas

On 02/14/2014 05:26 AM, Dave Della Costa wrote:

Hi Chas, thanks for the clarification--it was definitely not clear to me
how this worked so I appreciate the explanation.

Regarding the PR, I suppose the same points you brought up here are
relevant there, since I proposed including my (mistaken) notion of how
source-paths work for cljx-based libs in the documentation there.

So really the problem is a lack of knowledge about how leiningen works
when packaging up a jar.  However, despite the fact that this
information is not cljx-specific, it may be useful simply to re-state
what you've described in this email somewhere in the cljx docs for
clueless folks like myself, since obvious it's not clear what is
necessary configuration and what isn't...or else just provide a pointer
to the relevant leiningen docs (if they exist).

In any case, thanks!

DD

(2014/02/14 19:14), Chas Emerick wrote:

This isn't really right.  :source-paths are for your _sources_, not a
place to drop in whatever paths you want either on the classpath or
included in jar files, etc.  Also, all generated content should go into
`target/*`, so that `lein clean` will have its intended effect
(eliminating all artifacts of previous build / project mgmt activities).

(Some tools [definitely Counterclockwise, perhaps other IDE plugins as
well?] also use the value of :source-paths to configure go-to-definition
operations and such, so including non-source directories in
:source-paths will generally yield undesirable effects there.)

When it builds jars, Leiningen includes resources from :source-paths,
:resource-paths, and :compile-path; the latter is almost never
customized, and defaults to target/classes.

So, you should put your cljx sources in :source-paths.  You should have
cljx generate transformation results into some directory under
`target/`. If you want to redistribute the results, you should either
generate cljx results into `target/classes`, or investigate Leiningen's
(plethora of) options for customizing jar contents; see e.g.
https://github.com/technomancy/leiningen/blob/stable/sample.project.clj#L331


FWIW, that isn't cljx-specific at all; the same applies to Clojure
sources that are being AOT-compiled, and with a tweak, to Java sources
to be javac-compiled.

cljsbuild produces *JavaScript* output, so its configuration is never
going to be relevant to whether or not ClojureScript resources produced
by cljx can be consumed by downstream projects.

Dave, thanks for the PR; I'll reply separately to that on github.

- Chas

On 02/13/2014 10:06 PM, Dave Della Costa wrote:

Hi Karsten,

Strangely, I was doing the exact same thing as you yesterday and
struggled for a bit until I found settings that work.

I achieved success when I used the configuration from Cornice as a
template:

https://github.com/rkneufeld/cornice/blob/master/project.clj

...with one exception, my cljsbuild config contained only

:cljsbuild {:builds [{:source-paths [target/generated/cljs]}]}

vs. all the extra jar config and one not.  If I recall correctly, I was
getting the java.util.zip.ZipException: duplicate entry you mention
until I removed the extra settings in cljsbuild.

Looking at your config I also suspect you want


:source-paths [src-cljs]

instead of


:source-paths [src-clj src-cljs]

in your cljsbuild config.

However, when I leave the cljsbuild configuration out completely, it
seems to have no bearing on whether or not I can use the generated cljs
files when including the library in another project.  I suspect the
:jar true setting is only relevant if you have strictly cljs files
that need to be included--it seems like cljx has its own orthogonal
build process which automatically includes cljs files in the jar file
but I haven't dug into the code yet to confirm.  This is just based on
testing what happens when I tweak config settings (Kevin or Chas please
let me know if I'm off-base here).

What does seem to make all the difference is the sourcepaths settings,
which it doesn't seem you have:

:source-paths [src target/generated-src/clj
target/generated-src/cljs]

I needed this before I could see the clj/cljs files getting included in
my library jar.

Obviously, adjust all paths to fit your specific configuration.

I've made a pull request to add a bit of further explanation on using
cljx in libraries, as it would be helpful if this didn't require looking
up how others had done it to figure it out!

https://github.com/lynaghk/cljx/pull/30

Hope this helps--

Best,
Dave

(2014/02/13 20:22), Karsten Schmidt wrote:

I've been busy working

Re: [ClojureScript] ANN: ClojureScript 0.0-2067, regressions, type inference numeric checks

[Chas Emerick]

Gah, my bad, was running the tests with an old rev.  Too many projects 
in flight at once. :-/


In any case, [lein-cljsbuild 1.0.1-SNAPSHOT] is available that picks 
up your local :jvm-opts setting.


- Chas

On 11/22/2013 12:09 PM, David Nolen wrote:
0.0-2069 released, the only change is not caching AST nodes in the 
compiler environment. Should address the memory issues people are 
experiencing.


David


On Fri, Nov 22, 2013 at 11:59 AM, David Nolen dnolen.li...@gmail.com 
mailto:dnolen.li...@gmail.com wrote:


Can everyone please try master and verify the memory issue no
longer exists?

Thanks!
David


On Fri, Nov 22, 2013 at 11:54 AM, Mimmo Cosenza
mimmo.cose...@gmail.com mailto:mimmo.cose...@gmail.com wrote:

David,
I know you're a super master, but if you're going to use my
repo, just remember to exclude the tools.reader from the
org.clojars.magomimmo/shoreleave-remote-ring dependency which
uses the 0.7.10 release.

hih

mimmo

On Nov 22, 2013, at 5:36 PM, Chas Emerick c...@cemerick.com
mailto:c...@cemerick.com wrote:

 https://github.com/emezeske/lein-cljsbuild/issues/271 has a
reproducible case provided by Mimmo that doesn't involve
source maps.  (The error emitted by JDK 7 — GC overhead limit
exceeded — *can* be significant, i.e. just bumping -Xmx
doesn't always work, if the program in question is allocating
in such a way that the GC simply can't keep up.)

 Anyway, bumping the heap to 512m does work for Mimmo's test
case.  I'll get a hack into cljsbuild shortly that will allow
you to control the heap of the compilation subprocess via
:jvm-opts, but it seems like there's something else going on
if 512m is needed.  That the compilation will succeed after
some part of the work is done definitely points to a leak (or,
over-aggressive caching) of some kind.

 - Chas

 On Fri 22 Nov 2013 11:16:18 AM EST, Mimmo Cosenza wrote:
 Hi David,
 some problem here.

 If I switch to cljsbuild 0.3.4 it works, but it use a lot
of memory.
 With r2060 (even if there is a dependency on jvm7) the
compilation
 works with cljsbuild 1.0.0 too (not the r2030).

 I'm start to think (but I did not investigated) that it's not a
 cljsbuild 1.0.0 bug (aside from limiting the heap to 256M,
which is
 not so small).

 mimmo



 On Nov 22, 2013, at 5:01 PM, David Nolen
dnolen.li...@gmail.com mailto:dnolen.li...@gmail.com
 mailto:dnolen.li...@gmail.com
mailto:dnolen.li...@gmail.com wrote:

 I've tested by building core.async itself already no
problems. What
 memory settings are you giving to the JVM and are they
actually being
 respected (i.e. a lein-cljsbuild bug) ?

 David


 On Fri, Nov 22, 2013 at 10:40 AM, Moritz Ulrich
mor...@tarn-vedra.de mailto:mor...@tarn-vedra.de
 mailto:mor...@tarn-vedra.de
mailto:mor...@tarn-vedra.de wrote:


Small addition: All intermediate files are generated
just fine. It's
just the main.js that fails with OOM. Incremental
compilation doesn't
seem to help either.

Moritz Ulrich writes:

 Exciting news!

 Feedback to speed/memory: With :optimizations
:whitespace (my
default,
 for convenience reasons) the generation of the final
result
(main.js)
 takes forever and eventually dies with an OOM
exception: GC
overhead
 limit exceeded.

 I'm running lein-cljsbuild-1.0 and 0.0.2067 of
Clojurescript.

 This isn't a big project, just some tests with
core.async and
Prismatic's dommy.

 On Fri, Nov 22, 2013 at 4:16 PM, David Nolen
dnolen.li...@gmail.com mailto:dnolen.li...@gmail.com
mailto:dnolen.li...@gmail.com
mailto:dnolen.li...@gmail.com wrote:
 ClojureScript, the Clojure compiler that emits
JavaScript
source code.

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

 New release version: 0.0-2067

 Leiningen dependency information:

 [org.clojure/clojurescript 0.0-2067]

 This release fixes issues introduced by the source
map checks, the
 checks have been relaxed.

 This release also include a fairly significant

ANN: double-check, a Clojure/ClojureScript-portable fork of simple-check

[Chas Emerick]

Reid Draper's simple-check[1] is a generative/property-based testing 
library for Clojure that implements (and improves upon IMO) the 
shrinking of failing test cases seen in e.g. quickcheck in the Haskell 
and Erlang lands.


simple-check has totally changed how I do certain kinds of testing. From 
the beginning, I've wanted to use it when testing ClojureScript 
libraries and apps as well, since most of my ClojureScript code is 
portable to Clojure, or made that way with cljx[2].


The result is double-check, a fork of simple-check that provides the 
same API and generator semantics for Clojure and ClojureScript:


https://github.com/cemerick/double-check

double-check will fast-follow the development of simple-check, aiming to 
provide nothing more than a portable API; there should never be anything 
novel or interesting in double-check, except for the recasting of the 
simple-check codebase into a portable form.


Naturally, double-check adds support/integration for 
clojurescript.test[3] where simple-check supports/integrates clojure.test.


I've discovered (and reported and/or fixed) a number of issues in 
ClojureScript itself solely by making simple-check's own tests portable, 
and running them on ClojureScript.  I suspect you'll have the same 
experience with your own Clojure/ClojureScript projects once you apply 
double-check to them.


Cheers,

- Chas

[1] https://github.com/reiddraper/simple-check
[2] https://github.com/lynaghk/cljx
[3] https://github.com/cemerick/clojurescript.test

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: double-check, a Clojure/ClojureScript-portable fork of simple-check

[Chas Emerick]

simple-check is planning on remaining Clojure-only, at least for the 
foreseeable future.  This non-fork fork is the best alternative Reid 
and I could come up with to enable people to use it on both Clojure and 
ClojureScript.  Hopefully double-check will be unnecessary at some 
point. :-)


- Chas

On Thu 21 Nov 2013 02:01:02 PM EST, Max Penet wrote:

Looks good!

I am wondering though, why not merging your work on the parent project
instead of creating a new one (with a new name etc), you seemed to be
on your way of doing just this?

On Thursday, November 21, 2013 5:38:16 PM UTC+1, Chas Emerick wrote:

Reid Draper's simple-check[1] is a generative/property-based testing
library for Clojure that implements (and improves upon IMO) the
shrinking of failing test cases seen in e.g. quickcheck in the
Haskell
and Erlang lands.

simple-check has totally changed how I do certain kinds of
testing. From
the beginning, I've wanted to use it when testing ClojureScript
libraries and apps as well, since most of my ClojureScript code is
portable to Clojure, or made that way with cljx[2].

The result is double-check, a fork of simple-check that provides the
same API and generator semantics for Clojure and ClojureScript:

https://github.com/cemerick/double-check

https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcemerick%2Fdouble-checksa=Dsntz=1usg=AFQjCNGMdmXeOnf3w2MMaq09pIO9XEqONw


double-check will fast-follow the development of simple-check,
aiming to
provide nothing more than a portable API; there should never be
anything
novel or interesting in double-check, except for the recasting of the
simple-check codebase into a portable form.

Naturally, double-check adds support/integration for
clojurescript.test[3] where simple-check supports/integrates
clojure.test.

I've discovered (and reported and/or fixed) a number of issues in
ClojureScript itself solely by making simple-check's own tests
portable,
and running them on ClojureScript.  I suspect you'll have the same
experience with your own Clojure/ClojureScript projects once you
apply
double-check to them.

Cheers,

- Chas

[1] https://github.com/reiddraper/simple-check

https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Freiddraper%2Fsimple-checksa=Dsntz=1usg=AFQjCNENCgO1ktV_VfKH71w4oza6yEE0xw

[2] https://github.com/lynaghk/cljx

https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Flynaghk%2Fcljxsa=Dsntz=1usg=AFQjCNErrEPQTKkQAd-ma4oaCPVdW8BUJQ

[3] https://github.com/cemerick/clojurescript.test

https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcemerick%2Fclojurescript.testsa=Dsntz=1usg=AFQjCNGiV-NGOk4wuDpgDkZolznHF5c1Dg


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


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: 2013 State of Clojure ClojureScript survey results

[Chas Emerick]

One note on the ordering questions: each of them were constructed to 
present a randomized ordering to each new respondent, so there was no 
bias introduced by a default ordering.


Cheers,

- Chas

On 11/18/2013 03:09 PM, kovas boguta wrote:

Great job Chas.

Some notes on methodology and then some general comments

- That the survey was not featured on HN this time without a doubt
alone accounts for the slight dip in responses
- The 'missing' people are more likely fall into the 'hobbyist' camp,
which might explain the increased % of people using clojure at work in
this year's survey
- The increased # of questions probably also reduces survey conversion
(I wonder how many people viewed versus completed the survey)
- There is some bias inherent to the initial ordering in the
reordering-based questions; I for one dragged the most important items
to the top, and didn't carefully think about changing the ordering
beneath that.

I find it impressive that 76% of respondents report using clojure for
web development. This, in spite of a lack of a unified web framework
stretching from the DB to the client, and general confusion in the
masses about what the best solution to use is.




On Mon, Nov 18, 2013 at 2:32 PM, Chas Emerick c...@cemerick.com wrote:

Results of this year's survey are available here:

http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/

Thank you to all that participated!

Best,

- Chas

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


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

2013 State of Clojure ClojureScript survey results

[Chas Emerick]

Results of this year's survey are available here:

http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/

Thank you to all that participated!

Best,

- Chas

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Last chance 2013 State of Clojure ClojureScript survey

[Chas Emerick]

This is the final call to participate in the 2013 State of Clojure  
ClojureScript survey; no more responses will be accepted after noon EST 
*tomorrow*.


http://cemerick.com/2013/11/05/2013-state-of-clojure-clojurescript-survey/

Please take 5 minutes to participate: doing so is very important in 
assessing the Clojure/ClojureScript community on a number of important 
topics, and in guiding the efforts of all of the contributors to the 
languages, tools, and libraries that support it.


Cheers,

- Chas

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

The 2013 State of Clojure ClojureScript survey is now open

[Chas Emerick]

As in years past, I am running a 'State of Clojure' survey, which this 
year also includes a full section on ClojureScript:


http://cemerick.com/2013/11/05/2013-state-of-clojure-clojurescript-survey/

Your participation is most welcome.  And, please do what you can to 
spread the above link around to anyone who is using Clojure or 
ClojureScript.


Cheers,

- Chas

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] Friend 0.2.0 released

[Chas Emerick]

Hi all,

Friend is an extensible authentication and authorization library for 
Clojure Ring web applications and services. [com.cemerick/friend 
0.2.0] has been released to Clojars.


You can find the changelog here:

https://github.com/cemerick/friend/blob/master/CHANGES.md

Aside from the bump to Ring 1.2.0 final and a bunch of bugfixes/minor 
features, the big change is an internal refactoring of Friend and its 
included workflows to follow the interceptor style adopted by other Ring 
middlewares, which makes Friend play nicely with frameworks like 
Pedestal, Servlet v3, and so on.


Thanks to everyone who helped since the 0.1.5 release, especially 
Gabriel Horner for the heroic interceptor refactoring.


Cheers,

- Chas

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: with-redefs vs. constant folding

[Chas Emerick]

No; functions with :inline-* metadata (go look at the source for +, for 
example) are...inlined, thus eliminating var lookups, and any effect of 
binding, with-redefs, etc.  The workaround for this is to call through 
the var:


user= (with-redefs [+ list] (#'+ 1 2))
(1 2)

Cheers,

- Chas

On 08/14/2013 03:50 PM, Ben Wolfson wrote:

Is this a bug?

user (with-redefs [list +] (list 1 2)) ;; expected: 3
3 ;; huzzah

user (with-redefs [+ list] (+ 1 2)) ;; expected: (1 2)
3 ;; blast!



--
Ben Wolfson
Human kind has used its intelligence to vary the flavour of drinks, 
which may be sweet, aromatic, fermented or spirit-based. ... Family 
and social life also offer numerous other occasions to consume drinks 
for pleasure. [Larousse, Drink entry]


--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Question on `cljx` and `lein-dalap`

[Chas Emerick]

On Aug 11, 2013, at 5:19 PM, Shantanu Kumar wrote:

 Hi,
 
 I am thinking about how to use Cljx correctly in my projects (for 
 portability); I have few questions:
 
 1. I understand the Cljx plugin generates .clj and .cljs source code in 
 target/classes destination. Does that mean, when I generate a JAR for 
 distribution it again must be processed by Cljx to generate variant specific 
 code at runtime? (Is my assumption correct?)
 
 2. Does Cljx support ClojureCLR yet? I noticed one mention of `clr` on the 
 Cljx README but haven't heard anybody using yet.
 
 3. On what occasion should I consider lein-dalap instead of Cljx?

Hi Shantanu,

Some answers:

1. Yes, cljx implies a transformation step each time you need to package 
Clojure or ClojureScript code, whatever the context.  The Leiningen plugin, 
hooks, and nREPL middleware (so as to make loading code from .cljx files 
directly into REPL sessions, whether they be Clojure- or 
ClojureScript-flavoured [via piggieback]) are all provided to make this as 
painless as possible.

2. No, cljx does not support ClojureCLR (yet?).  Doing this would be quite 
straightforward: add a clr-rules map (similar to those found @ 
https://github.com/lynaghk/cljx/blob/master/src/cljx/rules.clj#L71), and a 
suitable shortcut for it in the plugin itself (around 
https://github.com/lynaghk/cljx/blob/master/src/cljx/core.clj#L78).  (The 
latter can probably be generalized into a map lookup once there's three default 
rulesets.)  That will take care of emitting the right code when `lein cljx` is 
run.  nREPL middleware for ClojureCLR (do such things exist yet?) is another 
matter; that may be a reason for at least some parts of cljx to be written in 
cljx. ;-)

I think some uncontroversial points of contrast between cljx and lein-dalap 
might be:

* cljx does not privilege any particular target; lein-dalap assumes/requires 
Clojure code as its primary representation
* cljx's transformations are completely static (i.e. they are made long before 
any of your code is touched by the Clojure runtime, including the reader); 
lein-dalap uses either reader or runtime metadata (I can't recall at the 
moment) to inform its transformations.

I contribute and use cljx, so I hope my preference/bias is clear.

Cheers,

- Chas

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

[ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Chas Emerick]

As you might know, I've been tinkering with an easier-to-use variant of 
ClojureScript's browser-REPL for some time.  I've finally wrapped that up into 
its own project, Austin:

https://github.com/cemerick/austin

Everything you need to know is there.  The tl;dr is:

1. You can have a ClojureScript REPL running for your project in ~10 seconds 
(backed by phantomjs by default, but it's easy to wire up any other browser 
runtime, headless or GUI).

2. Setting up a ClojureScript REPL where your app's front-end initiates the 
REPL connection is _nearly_ as easy, and the same mechanism works whether 
you're running one REPL or ten across one or many projects without touching or 
worrying about :port configuration, etc.

I've only just started documenting and adding higher-level convenience features 
and APIs to Austin, so your feedback and contributions are most welcome.

Have fun!

Cheers,

- Chas

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

Re: [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Chas Emerick]

On Aug 5, 2013, at 9:21 AM, Chas Emerick wrote:

 As you might know, I've been tinkering with an easier-to-use variant of 
 ClojureScript's browser-REPL for some time.  I've finally wrapped that up 
 into its own project, Austin:
 
   https://github.com/cemerick/austin
 
 Everything you need to know is there.  The tl;dr is:
 
 1. You can have a ClojureScript REPL running for your project in ~10 seconds 
 (backed by phantomjs by default, but it's easy to wire up any other browser 
 runtime, headless or GUI).
 
 2. Setting up a ClojureScript REPL where your app's front-end initiates the 
 REPL connection is _nearly_ as easy, and the same mechanism works whether 
 you're running one REPL or ten across one or many projects without touching 
 or worrying about :port configuration, etc.
 
 I've only just started documenting and adding higher-level convenience 
 features and APIs to Austin, so your feedback and contributions are most 
 welcome.
 
 Have fun!
 
 Cheers,
 
 - Chas

BTW, I put a screencast demonstrating Austin over here:

http://www.youtube.com/watch?v=a1Bs0pXIVXc

- Chas

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

Re: Interest in a Full Featured Clojure Blog Engine

[Chas Emerick]

On Jul 19, 2013, at 2:46 PM, Timothy Washington wrote:

 I've deliberately proposed a small core, so that you can use only the pieces 
 you absolutely need. Additionally, I think it encourages a clean design, 
 forcing explicit interaction semantics between system components. If we 
 accept this premise, the only question then, is what mechanism we should use 
 to separate the core of stefon, from the rest of its plug-in components. Now, 
 I was looking into the nrepl protocol. I think it conceptually gives us the 
 separation we need, with the added bonus that a stefon service, and it's 
 plug-ins, could be in separate locations. But while I like the concept, I 
 think the host would need a way to i) declare the stefon service (nrepl 
 versioning?), ii) list / publish actions (??) iii) pass around binary data 
 (base64 encoding?). Also, I saw that there was a discussion around updating 
 the nrepl protocol (nRepl.Next), and don't know if that's been implemented. 

Only barely following along, but FYI: the nREPL.Next page you linked to is 
quite old, and described the state of affairs a couple of years ago.  One of 
the paths described therein was taken, and is represented in nREPL releases 
starting with 0.2.0.  There are no plans currently for changing the default 
nREPL transport's wire protocol.  

I've updated the wiki page to note this to avoid further confusion, thanks for 
mentioning it. :-)

- Chas

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

Re: OAuth2

[Chas Emerick]

Hi Steven,

I'm sorry to hear you didn't find Friend easy to use.  FWIW, you (and whoever 
is following along) might find this helpful:

https://friend-demo.herokuapp.com/

There are live examples of apps using OpenID, OAuth (via github), and more 
pedestrian stuff like forms and HTTP Basic, with code linked from each.

If anyone has suggestions on how friend and its accompanying libraries could be 
made easier to use (beyond more better docs faster), or would like to 
contribute in any way, that door is always open. :-)

Cheers,

- Chas

On Jul 16, 2013, at 11:24 AM, Steven Degutis wrote:

 I heard good things about friend, so I tried to use it for OpenID (to sign-in 
 with Google). But I couldn't figure out how, so I just used openid4java.
 
 
 On Mon, Jul 15, 2013 at 8:57 PM, Plínio Balduino pbaldu...@gmail.com wrote:
 Hi there
 
 What are you using to authenticate with Google, Facebook, GitHub or Twitter?
 
 Thanks
 
 Plínio
 
 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: test.generative and data.generators

[Chas Emerick]

Shrinking is a key requirement for me as well (1000-line-long data literals 
that produce a failure are better than nothing, but not quite as nice as its 
shrunken 40-character literal that provokes the same failure).  You might be 
interested in simple-check, which is a Clojure property-based testing tool 
inspired by QuickCheck, and so its support for shrinking is essential:

https://github.com/reiddraper/simple-check/

I've been using it for some weeks now with good results.

Cheers,

- Chas

On Jul 15, 2013, at 7:35 AM, Andreas Liljeqvist wrote:

 So, I find that what they provide are absolutely fantastic.
 But I don't see much action around them, are they considered maintained?
 
 Things on my wishlish: 
 Shrinking of failing inputs.
 More readable reports.
 A couple of blogs or videos discussing them, I think that most people don't 
 know what they are used for.
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: Doc about auto-namespaced keywords (e.g. ::user)?

[Chas Emerick]

Hi Bastien,

We talked about namespaced keywords in 'Clojure Programming'.  A brief 
introduction to them can be found on page 14, which you can get for free @ 
http://clojurebook.com (look for the first chapter link on the right).  
They're used for more than e.g. unambiguously keying slots in a map, but those 
cases are described later in the book.

Cheers,

- Chas

On Jul 9, 2013, at 4:57 PM, Bastien Guerry wrote:

 Hi all,
 
 while reading the documentation for friend, I stumbled upon 
 auto-namespaced keywords -- how can I find more doc about
 them?
 
 I'm trying to use friend within a luminus templated webapp,
 and lein ring server returns this error when I use ::user:
 
  CompilerException: java.lang.RuntimeException: Invalid
  token: ::users/user, compiling:(kickhub/routes/auth.clj:141:37)
 
 Thanks in advance for any pointer!
 
 -- 
 Bastien
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

cljx 0.3.0 released

[Chas Emerick]

Earlier today, we released [com.keminglabs/cljx 0.3.0], which brings a bunch 
of significant changes and improvements:

https://github.com/lynaghk/cljx

Existing users should review the changelog entry, as this is a breaking release:

https://github.com/lynaghk/cljx/blob/master/CHANGES.md

cljx is a way to statically rewrite Clojure (or ClojureScript) to be portable 
to ClojureScript (or Clojure).  This means that you can target both languages 
with a single codebase.  To do this, you write code in .cljx files, and use 
annotations to elide language/runtime-specific forms from the output intended 
for different targets.  There's better examples in the README (and some handful 
of projects using cljx out in the wild, like 
https://github.com/cemerick/pprng), but you should get the flavour from this 
snippet:

(defn x
  []
  (throw (#+clj Exception. #+cljs js/Error. WTF)))

cljx will produce two files from this input: a .clj file containing the 
`Exception.` symbol but not the `js/Error.` symbol, and a .cljs file containing 
the inverse.  In short, cljx is an s-expression preprocessor (intentionally 
very limited — this is all you really need to write practical, portable 
Clojure[Script]).

Thanks to Kevin Lynagh for cutting releases and allowing me to play in his 
sandbox, and all the others noted in the README that inspired or helped in the 
effort.

Happy Clojure[Script]-ing!

- Chas

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

Re: [ANN] 16th tutorial of the modern-cljs series

[Chas Emerick]

Looks like another great installment in the series!

One note: I've been working on giving cljx a bit of a facelift of late to 
address some pitfalls of it using Clojure's reader.  The result is in the 
'sjacket' branch of cljx here:

https://github.com/lynaghk/cljx/tree/sjacket

As the branch name indicates, this remix of cljx is using Christophe Grand's 
sjacket library (packaged and patched by Colin Jones).  A summary of the 
changes are available in the changelog here:

https://github.com/lynaghk/cljx/blob/sjacket/CHANGES.md

In short, it's all good news. :-)  I've been using this for some weeks now with 
good results; you can see a small real-world new-style cljx project here:

https://github.com/cemerick/pprng/

I suspect the sjacket branch will be merged to master Real Soon Now.

Cheers,

- Chas

On Jul 8, 2013, at 11:01 AM, Giacomo Cosenza wrote:

 Hi all,
 I just pushed the 16th tutorial of the modern-cljs series. By using the 
 clojurescript.test lib and the cljx lein plugin I was able to make the unit 
 tests portable on both the client-side and the server-side of a web app. To 
 me this is very important, because allows to potentially move a complete lib 
 where you want (i.e. write one run on both sides of the web).
 
 I dedicated this tutorial to Chas Emerick for his amazing work (and the book 
 too) that helped me a lot in each step ahead I do with this wonderful 
 unifying language. Thanks so much Chas!
 
 Here is the link of the series
 
 https://github.com/magomimmo/modern-cljs
 
 and here is the link of the last tutorial
 
 https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-16.md
 
 HIH
 
 My best
 
 Mimmo
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: Detecting login and logout using friend

[Chas Emerick]

Rather than looking at session changes (which may not capture all 
authentications, e.g. requests carrying HTTP Basic creds), why not a utility 
that composes workflow fns, squirting authentication events out the side?  Your 
app is entirely responsible for logouts (you're either calling friend/logout*, 
or using friend/logout middleware), so that should be trivial to do without 
touching the session as well.

Cheers,

- Chas

On Jun 28, 2013, at 4:25 AM, Steve Buikhuizen wrote:

 I'll answer my own question here for future reference value.
 
 I found a much cleaner way was to create a wrapper type (deftype) for the 
 ring session store impl. It is a simple delegating wrapper but it sees the 
 correct cookies, regardless of the servlet container.
 
 It has the disadvantage of not having access to the ring request so recording 
 user-agent etc is not possible. I solved this by using middleware to record 
 that in a subsequent request. 
 
 Here's what the wrapper looks like, feedback is welcome if you have it...
 
 (deftype SessionStoreWrapper [store]
 
   rss/SessionStore
 
   (read-session [_ session-key]
 
 (rss/read-session store session-key))
 
   (write-session [_ session-key data]
 
 (let [key-written (rss/write-session store session-key data)]
 
   ;; ::session-recorded means middleware below has upserted user-agent, 
 ip-address etc
 
   (when (and (not (::session-attributes-recorded data)) 
 (:cemerick.friend/identity data))
 
 (let [current-auth (get-in data [:cemerick.friend/identity :current])
 
   user-id (get-in data [:cemerick.friend/identity 
 :authentications current-auth :id])] 
 
   (debug upserting session:  key-written  -  user-id)
 
   (try 
 
 (session/upsert-session user-id key-written nil nil :logged-in)
 
   (catch Throwable t
 
 (error t record login failed)
 
   key-written))
 
   (delete-session [_ session-key]
 
 (debug logging out:  session-key)
 
 (try 
 
   (session/logout-session session-key)
 
   (catch Throwable t
 
 (error t record logout failed)))
 
 (rss/delete-session store session-key)))
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

[ANN] core.incubator 0.1.3

[Chas Emerick]

FYI, [org.clojure/core.incubator 0.1.3] has been released:

https://github.com/clojure/core.incubator/

The only change was to note that two of the macros it provides (-? and -?) 
are now deprecated, having been effectively promoted into Clojure itself in 
v1.5.0 (as some- and some-, respectively).

Cheers,

- Chas

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

Re: Why aim for repeatability of specification / generative testing?

[Chas Emerick]

Well, if *that's* all it is, I'll feel like quite the heel for putting so much 
thought into it! ;-)

Assuming failures are rarer, then starting with a just-previously-failed seed 
would be better as an explicit action, rather than defaulting to a constant?

- Chas

On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote:

 i always thought it was basically solely for letting you re-run the
 test that just/previously failed, nothing more weird or silly than
 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/groups/opt_out.

Re: Why aim for repeatability of specification / generative testing?

[Chas Emerick]

Thanks for that perspective, Andy!

It sounds like one ends up looking for canaries in the coal mine, perhaps just 
borderline behaviour or results, odd sideband emissions, etc. that indicate 
that it'd be worthwhile to turn the debug knobs up to 11.  It's interesting to 
think of cases where the same dynamic might apply with software where the test 
data in question isn't readily captured.  I can't think of any right off the 
top of my head (assuming we're always talking about purely functional 
properties under test), but I'm sure they exist.

Back in the weeds, it does sound like the analogous default would be to vary 
the seed for every test run, but always capturing it for replay if necessary.

- Chas

On Jun 6, 2013, at 3:52 PM, Andy Fingerhut wrote:

 I've worked on hardware logic design, where the time and effort required to 
 create good tests that find subtle bugs rivals the complexity of the hardware 
 being designed itself.  In this context, much of the testing has often been 
 generated using pseudo-random streams similar to test.generative and the 
 simulation approach being advocated for software.  I think that is a great 
 idea for improving software quality.
 
 In hardware testing via simulation, reproducible tests are important because 
 most of the testing cycles are run with a low amount of logging enabled -- 
 just enough logging to look for signs of incorrect behavior.  When a hardware 
 designer wants to debug the problem, the test can be re-run with very 
 detailed logs enabled (basically amounting to recording the logic 0/1 value 
 of every wire in the hardware being designed at every instant in simulated 
 time).  These are much slower and require a lot more temporary disk space to 
 record the logs.
 
 So you end up using a large variety of different seed values to increase test 
 coverage, and if any of them fails, you can turn on the extra logging and 
 re-run it, knowing that you will hit the same problem as before.
 
 Andy
 
 
 On Thu, Jun 6, 2013 at 12:30 PM, Chas Emerick c...@cemerick.com wrote:
 Well, if *that's* all it is, I'll feel like quite the heel for putting so 
 much thought into it! ;-)
 
 Assuming failures are rarer, then starting with a just-previously-failed seed 
 would be better as an explicit action, rather than defaulting to a constant?
 
 - Chas
 
 On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote:
 
  i always thought it was basically solely for letting you re-run the
  test that just/previously failed, nothing more weird or silly than
  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/groups/opt_out.
 
 
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: Why aim for repeatability of specification / generative testing?

[Chas Emerick]

Sure; just to clarify, I was definitely talking about capturing test *input*, 
not output.

BTW, if anyone with a hardware testing background have pointers to good 
literature on the topic that might be accessible to lowly software twiddlers, 
fire away... :-)

- Chas

On Jun 6, 2013, at 6:16 PM, Philip Potter wrote:

 I can quite imagine seeing a failure from a Travis ci run which can't be 
 explained by the test output; being able to reproduce it locally is the first 
 step towards diagnosis.
 
 (warning: thread drift ahead...)
 
 I also have a hardware background - specifically, xilinx FPGAs. The xilinx 
 synthesis tools have an interesting phenomenon where they use PRNGs in their 
 place and route algorithms, which map logical netlists to physical slices  
 configure the routing to minimize critical path delay.
 
 A different PRNG seed could result in a different place  route result, with 
 different maximum clock speed  hence different performance. Hence having a 
 repeatable build was necessary to ensure uniform performance from the same 
 source code.
 
 On Jun 6, 2013 10:38 PM, Chas Emerick c...@cemerick.com wrote:
 Thanks for that perspective, Andy!
 
 It sounds like one ends up looking for canaries in the coal mine, perhaps 
 just borderline behaviour or results, odd sideband emissions, etc. that 
 indicate that it'd be worthwhile to turn the debug knobs up to 11.  It's 
 interesting to think of cases where the same dynamic might apply with 
 software where the test data in question isn't readily captured.  I can't 
 think of any right off the top of my head (assuming we're always talking 
 about purely functional properties under test), but I'm sure they exist.
 
 Back in the weeds, it does sound like the analogous default would be to vary 
 the seed for every test run, but always capturing it for replay if necessary.
 
 - Chas
 
 On Jun 6, 2013, at 3:52 PM, Andy Fingerhut wrote:
 
 I've worked on hardware logic design, where the time and effort required to 
 create good tests that find subtle bugs rivals the complexity of the 
 hardware being designed itself.  In this context, much of the testing has 
 often been generated using pseudo-random streams similar to test.generative 
 and the simulation approach being advocated for software.  I think that is a 
 great idea for improving software quality.
 
 In hardware testing via simulation, reproducible tests are important because 
 most of the testing cycles are run with a low amount of logging enabled -- 
 just enough logging to look for signs of incorrect behavior.  When a 
 hardware designer wants to debug the problem, the test can be re-run with 
 very detailed logs enabled (basically amounting to recording the logic 0/1 
 value of every wire in the hardware being designed at every instant in 
 simulated time).  These are much slower and require a lot more temporary 
 disk space to record the logs.
 
 So you end up using a large variety of different seed values to increase 
 test coverage, and if any of them fails, you can turn on the extra logging 
 and re-run it, knowing that you will hit the same problem as before.
 
 Andy
 
 
 On Thu, Jun 6, 2013 at 12:30 PM, Chas Emerick c...@cemerick.com wrote:
 Well, if *that's* all it is, I'll feel like quite the heel for putting so 
 much thought into it! ;-)
 
 Assuming failures are rarer, then starting with a just-previously-failed 
 seed would be better as an explicit action, rather than defaulting to a 
 constant?
 
 - Chas
 
 On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote:
 
  i always thought it was basically solely for letting you re-run the
  test that just/previously failed, nothing more weird or silly than
  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/groups/opt_out.
 
 
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails

Re: Making things go faster

[Chas Emerick]

Hi David,

It's odd/interesting that you're finding yourself restarting the JVM regularly. 
 For many years, I've developed Clojure with very rare restarts; especially if 
my baseline project configuration is stable, I often have REPL sessions that 
last days.

(Random thought: it'd be cute if various development environments regularly 
plinged `(.. java.lang.management.ManagementFactory getRuntimeMXBean 
getUptime)` so as to show uptime of your REPL/runtime.)

Stuart's clojure.tools.namespace patches over a couple of long-standing 
trapdoors around code loading, but I've always preferred simply loading 
files/expressions into the REPL, much as we described in the 'REPL-oriented 
Programming' chapter in the book.  I generally prefer to have as complete an 
understanding as possible of what's being loaded / being done to my REPL, and 
so various automated tools have never appealed to me.

As for testing, I've always used `clojure.test`, so re-running tests after 
changing them or the code under test has always been just a `(test-ns *ns*)` 
away.  This was actually a primary objective of mine in porting `clojure.test` 
to [clojurescript.test](https://github.com/cemerick/clojurescript.test), which 
carries forward all of the former's dynamic-runtime facilities like `test-ns` 
and `run-all-tests`, despite the lack of first-class namespaces and the static 
nature of ClojureScript compilation and Closure optimization.

In any case, whatever you do, any workflow that results in your bouncing the 
JVM is a broken one, and any tools/libraries/frameworks/whatever that push you 
in that direction are to be avoided IMO.

Cheers,

- Chas

On Jun 4, 2013, at 4:51 PM, David Pollak wrote:

 Folks,
 
 I've been doing Clojure coding for the last couple of weeks and really love 
 the language... and the community is fantastic.
 
 But the development cycle is slow.
 
 I'm coming from mostly Scala and a little Java.
 
 In Java, there's no REPL or anything... but the compile/test cycle is very 
 fast. So, I can make a few changes to code, type mvn test and see the 
 results typically in less than 2 seconds (my MacBook Pro and my Linux 
 desktop).
 
 In Scala, the compile cycles are slower than in Java because the Scala 
 compiler is doing a whole ton more. But in sbt (Simple [ha ha] Built Tool), 
 one is always building/testing in the same JVM instance so the JVM is warmed 
 up. A change code and run tests cycle is typically as fast as it is in 
 Java. For example, Changing something significant in the net.liftweb.util 
 package and doing a recompile and test takes about 9 seconds. This is running 
  450 tests.
 
 My Clojure development cycle is much slower. On my MacBook Pro (3rd gen i7 
 quadcore processor, 16GB of ram), each time I make a change and re-run the 
 test for Plugh ( https://github.com/projectplugh/plugh ) it takes about 20 
 second and there are only 4 tests. On my desktop Linux box (i7-3770 with 32gb 
 of RAM) it takes about 4 seconds to run the 4 tests. I also ran stuff on a 
 very old ThinkPad (core 2 duo with 4GB ram running Linux Mint 15) and the 
 test cycle takes 12 second.
 
 So... the questions:
 
 * Is there a faster cycle than to change code, change tests and type lein 
 test to see the results?
 * Is there a way to keep everything in a hot JVM (I've done a little research 
 on Nailgun... but it seems to be out of vogue) so there's no JVM start-up 
 penalty?
 * Is there a reason for the huge disparity between my MacBook Pro and my 
 desktop box?
 
 Thanks,
 
 David
 
 
 -- 
 Telegram, Simply Beautiful CMS https://telegr.am
 Lift, the simply functional web framework http://liftweb.net
 Follow me: http://twitter.com/dpp
 Blog: http://goodstuff.im
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: login with friend, but username blank, despite keyword-params middleware in place

[Chas Emerick]

There's too much here for me to comb through.  A couple of things:

https://friend-demo.herokuapp.com/interactive-form is a complete demo 
application that uses Friend's interactive-form workflow.  You might have seen 
this already; if not, it's a good starting point.

Second, try adding a verbose logging middleware to your - form, e.g.

(defn wrap-verbose
  [h]
  (fn [req]
(println  req)
(h req))

(- ...
wrap-verbose)

You can move that wrap-verbose application around in your stack to see the 
state of the request map at different points.

Hope that helps,

- Chas

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

Re: Securing Clojure + Clojurescript Web App

[Chas Emerick]

I think different people are asking different questions here.

Authenticating via an XHR or similar is very straightforward if you are using a 
single-step authentication method like the username/password interactive 
workflow.  Just POST to the right URL with username/password data, and carry on 
based on a successful vs. unsuccessful response.

Authorization within a single-page application is a totally separate question.  
Now that I've read Ari's question again fresh, I think he's asking How do I 
enforce authorization policies when my RPC mechanism (in this case, 
shoreleave-remote) 'binds' on a single URI, when it looks like all the Friend 
authorization examples establish policy on a per-URI basis?

(Apologies to Ari if that's *not* what he's asking, but I'll answer that 
question if anyone's interested…)

The answer is that you can use `cemerick.friend/authorize`, 
`cemerick.friend/authorized?`,  `cemerick.friend/throw-unauthorized` in various 
combinations whereever you need to enforce authorization policy.  It does not 
have to be applied only once, just within the boundary of routing, and it does 
not even have to be role-based.  So, if you expose N functions via shoreleave's 
RPC mechanism, each of those (or dedicated `defremote`s that delegate to other 
fns) can contain any arbitrary authorization checks, each potentially changing 
application behaviour or throwing an authorization failure as your needs demand.

That's today, and should suffice for building effectively any application you 
need.  Someday soon however, it will be possible to back into a singular 
routing+authorization policy table for your entire application, which could 
include e.g. multiple shoreleave RPC endpoints, each with their own delimited 
bag of remote-available fns, each potentially guarded by their own 
authorization criteria.  This will hopefully allow for declarative policy 
specifications, automated reporting of effective policy outside of runtime, 
allow you to disentangle authorization policy from the rest of your codebase, 
and altogether make audits less invasive and therefore less costly.

I hope the above clarifies more than it confuses.

Cheers,

- Chas

On Apr 1, 2013, at 1:12 PM, albert cortez wrote:

 In the same boat here. Trying to make a SPA and now am trying to figure out 
 the easiest way to have ajax authentification.
 
 On Tuesday, February 26, 2013 5:24:09 PM UTC+1, Ari wrote:
 Hi,
 
 I'd appreciate suggestions on how I can/should secure my 
 clojure/clojurescript single page web app that relies heavily on 
 shoreleave-remote. With other frameworks, upon authentication I've created a 
 roles cookie that the clientside uses to determine access rights to views, 
 while on the serverside I use a roles session variable to determine access 
 rights to GET/POST data. But Shoreleave side-steps the serverside 
 authentication/authorization (via friend), so I'm not sure how to proceed. 
 
 Thanks.
 
 -Ari
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: Invoke a specific multimethod

[Chas Emerick]

Just copy/paste from my Counterclockwise REPL. :-)

- Chas

On Mar 30, 2013, at 11:54 PM, JvJ wrote:

 Also, nice syntax highlighting!  How'd you do that?
 
 On Saturday, 30 March 2013 23:54:03 UTC-4, JvJ wrote:
 get-method.  Thanks, that was exactly what I was looking for!
 
 On Saturday, 30 March 2013 07:20:54 UTC-4, Chas Emerick wrote:
 On Mar 30, 2013, at 12:00 AM, George Oliver wrote:
 
 
 
 On Friday, March 29, 2013 6:19:19 PM UTC-7, JvJ wrote:
 Is it possible to invoke a particular multimethod and bypass the dispatch 
 function?
 
 For instance, suppose that I have a multimethod with a dispatch value of 
 ::foo, and it's a really complex method.
 
 Now, I want all cases where the dispatch function returns nil to use the 
 same multimethod.  Is there a way I can intercept the nil and
 pass it directly on to the ::foo multimethod?
 
 You could use the default multimethod to catch nil, and then call the multi 
 with ::foo. 
 
 That will only work if the dispatch fn is identity or similar.
 
 If you control the dispatch fn, then you don't need to intercept nil -- 
 just returning ::foo from the dispatch fn when it might otherwise return nil 
 will get you to the method you want.
 
 If you *don't* control the dispatch fn, but you're providing the methods for 
 :foo and nil, then you can use `get-method` to obtain the method associated 
 with a particular dispatch value:
 
 = (defmulti foo :bar)
 #'user/foo
 = (defmethod foo :baz
  [x]
  (str x))
 #MultiFn clojure.lang.MultiFn@6194a872
 = (defmethod foo :default
  [x]
  ((get-method foo :baz) x))
 #MultiFn clojure.lang.MultiFn@6194a872
 = (foo {:bar :baz})
 {:bar :baz}
 = (foo {:some :other :value :here})
 {:some :other, :value :here}
 
 Of course, if the functionality you need is available as a separate top-level 
 fn, and you can avoid the extra effective dispatch through the multimethod, 
 all the better.
 
 Cheers,
 
 - Chas
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: Invoke a specific multimethod

[Chas Emerick]

On Mar 30, 2013, at 12:00 AM, George Oliver wrote:

 
 
 On Friday, March 29, 2013 6:19:19 PM UTC-7, JvJ wrote:
 Is it possible to invoke a particular multimethod and bypass the dispatch 
 function?
 
 For instance, suppose that I have a multimethod with a dispatch value of 
 ::foo, and it's a really complex method.
 
 Now, I want all cases where the dispatch function returns nil to use the same 
 multimethod.  Is there a way I can intercept the nil and
 pass it directly on to the ::foo multimethod?
 
 You could use the default multimethod to catch nil, and then call the multi 
 with ::foo. 

That will only work if the dispatch fn is identity or similar.

If you control the dispatch fn, then you don't need to intercept nil -- just 
returning ::foo from the dispatch fn when it might otherwise return nil will 
get you to the method you want.

If you *don't* control the dispatch fn, but you're providing the methods for 
:foo and nil, then you can use `get-method` to obtain the method associated 
with a particular dispatch value:

= (defmulti foo :bar)
#'user/foo
= (defmethod foo :baz
 [x]
 (str x))
#MultiFn clojure.lang.MultiFn@6194a872
= (defmethod foo :default
 [x]
 ((get-method foo :baz) x))
#MultiFn clojure.lang.MultiFn@6194a872
= (foo {:bar :baz})
{:bar :baz}
= (foo {:some :other :value :here})
{:some :other, :value :here}

Of course, if the functionality you need is available as a separate top-level 
fn, and you can avoid the extra effective dispatch through the multimethod, all 
the better.

Cheers,

- Chas

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

Re: clojureans in Boston and NYC

[Chas Emerick]

The Boston Clojure group is very healthy, engaging, and enjoyable:

http://www.meetup.com/Boston-Clojure-Group/

And, if you get out further my way, we'd love to have you as a guest at the 
Functional Programmer Connoisseurs:

http://www.meetup.com/Functional-Programming-Connoisseurs/

Cheers,

- Chas

On Mar 11, 2013, at 10:06 AM, Giacomo Cosenza wrote:

 Hello everyone,
 on march 29th I'm moving from Milan (Italy) to Boston and I'm going to stay 
 there for a month. During that month I'm pretty sure I'm going to visit NYC 
 for few days. It would be an honor for me to have the opportunity to meet any 
 clojurean living in Boston and NYC. There few italian clojureans and most of 
 them live abroad and the only italian clojureans that I personally know are 
 the ones working in my small sw company. 
 
 If someone is interested to meet me, just let me know. I'll appreciate a lot.
 
 Thanks so much for your attention.
 
 Mimmo
 
 
 
 
 
 
 
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

Re: how does one embed nrepl in his own application?

[Chas Emerick]

See https://github.com/clojure/tools.nrepl#embedding-nrepl-starting-a-server

Cheers,

- Chas

--
http://cemerick.com
[Clojure Programming from O'Reilly](http://www.clojurebook.com)

On Mar 5, 2013, at 10:03 AM, Jim - FooBar(); wrote:

 Hi all,
 
 I am intrigued about the idea of communicating with my application 
 remotely...The book 'Clojure Programming' says that nrepl comes with a 
 consumer lib and is easily embeddable to your apps. Can anyone point me to a 
 direction where I can find more? perhaps someone ha already done that or 
 something...I know leiningen uses it (DUH!) but I'd like to start with 
 something small if possible...
 
 
 alternatively, how does one use rlwrap with the socket-based repl from 
 contrib? It seems like a reasonable repl-server but the fact that you can't 
 use backspace, arrows etc makes the bare repl a rather horrific experience...
 
 thanks in advance, :)
 
 Jim
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

Re: Wrong clojure version depending on lein dependencies (was: ANN: Clojure 1.5)

[Chas Emerick]

On Mar 4, 2013, at 7:36 AM, Meikel Brandmeyer (kotarak) wrote:

 Hi,
 
 Am Montag, 4. März 2013 13:00:31 UTC+1 schrieb Wolodja Wentland:
 
 It is up to a community to fix things that are broken in their toolset and 
 Do 
 not use version ranges is IMHO the wrong answer. 
 
 
 Huge +1.
 
 I was about to blog in favour of version ranges. As I'm a toolmaker myself, I 
 wanted to first spike a proof-of-concept of a saner dependency resolution 
 library (it can't be thaaat hard, right? kind of run-up-a-wall-soon 
 project). However now I will blog anyway and get to code later on.
 
 Having detailed dependency reports with sane information as they were added 
 lately to leiningen and gradle are a first step. A sane resolution strategy 
 is the next. (Funnily ivy already seems to provide that...)

FWIW, contributors to Pomegranate and Leiningen are working on general 
solutions to this sort of madness, but the use of version ranges will always be 
largely unwarranted, especially in published libraries.

There are a lot of reasons for this, but #1 for me is that few people 
understand the implications of version ranges, either downstream of their 
published libraries or when they are consuming a library and place a range 
around its resolution.  If you do, and your team does, then by all means, go 
hog-wild with version ranges in your in-house libraries and applications, where 
you can control versioning schemes, correspondences between APIs and versions, 
and so on.  However, none of those standards apply in the commons, so ranges 
like the one that provoked the problem in this case ([org.clojure/clojure 
[1.2,1.5)]) are counterproductive (i.e. there is no reason to prospectively 
exclude an unreleased version unless you're certain that API changes will break 
the library in question).  Granted, the fallback resolution of the 
Leiningen/Pomegranate/Aether triad fall down badly, which exacerbates the 
problem; again, that's being worked on, but the solution still won't help in 
this situation where a library blocks out e.g. 1.5.0, but a downstream 
user/library explicitly specifies 1.5.0.

I feel like I'm light-years OT, so I won't wade into the Ivy vs. Aether morass; 
suffice it to say, if there were a silver bullet — and there's not — Ivy 
wouldn't be it.

Cheers,

- Chas

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

Re: Wrong clojure version depending on lein dependencies (was: ANN: Clojure 1.5)

[Chas Emerick]

On Mar 4, 2013, at 9:01 AM, Meikel Brandmeyer (kotarak) wrote:

 Hi Chas,
 
 Am Montag, 4. März 2013 14:33:29 UTC+1 schrieb Chas Emerick:
 There are a lot of reasons for this, but #1 for me is that few people 
 understand the implications of version ranges, either downstream of their 
 published libraries or when they are consuming a library and place a range 
 around its resolution.  If you do, and your team does, then by all means, go 
 hog-wild with version ranges in your in-house libraries and applications, 
 where you can control versioning schemes, correspondences between APIs and 
 versions, and so on.  However, none of those standards apply in the commons, 
 so ranges like the one that provoked the problem in this case 
 ([org.clojure/clojure [1.2,1.5)]) are counterproductive (i.e. there is no 
 reason to prospectively exclude an unreleased version unless you're certain 
 that API changes will break the library in question).  Granted, the fallback 
 resolution of the Leiningen/Pomegranate/Aether triad fall down badly, which 
 exacerbates the problem; again, that's being worked on, but the solution 
 still won't help in this situation where a library blocks out e.g. 1.5.0, but 
 a downstream user/library explicitly specifies 1.5.0.
 
 Ok. So instead of the range I specify [org.clojure/clojure 1.2]. What 
 does that mean? Now I either excluded *all* clojure versions not= 1.2 or the 
 version number doesn't mean anything. Then we should get rid of it completely 
 and just specify the dependency without it. (It seems there maven poms which 
 do exactly that? o.O)
 
 The range [1.2;1.5) means that the library was tested with 1.2 up to 1.4 and 
 - believing in semver - their patchlevel children. 1.5 (was at that time) not 
 released, yet. So compatibility couldn't be guaranteed. For me this is a 
 reasonable approach. Sure. It might work with 1.5. Everyone is free to place 
 an exclusion to help the system resolve the conflict. But you must be aware 
 you might run into trouble.
 
 If I follow your approach I must provide 4 branches of a library which 
 basically consists of a single function: one branch per supported clojure 
 version (so far). This is ridiculous. Or - as I said - we let all hope go and 
 don't specify the version, only the dependency on the library itself.
 
 I see we have a different basic idea of what a version range should mean. For 
 me it's a promise that my library will work with the versions specified. If 
 one wants to use a version outside the range, that *might* be ok, but one 
 should be aware and pointed to that fact and the decision to do so should be 
 explicit!
 
 I'm probably just a pessimist, while you are an optimist.

AFAICT, the vast majority of Leiningen users (same goes for Maven users as 
well) expect the dependency vector [org.clojure/clojure 1.2.0] to establish a 
lower bound, the equivalent of [1.2.0,).  Further, people expect the maximum 
of all overlapping requirements to be taken (so transitive dependencies 
requiring e.g. 1.2.0, 1.3.0, and 1.4.0 would resolve to 1.4.0), and for 
the dependencies specified in the root of the tree (i.e. the current 
project.clj) to override everything else, so specifying 1.3.1 in the current 
project would be the equivalent of [1.3.1] (this is equivalent to having 
implicit dependencyManagement in Maven, for those that know/care what that 
means).

That's just my personal observation, but others that have done work in this 
area seem to agree on the general outline.  Further, it *should* be compatible 
with the existing Aether/Maven ecosystem that we're playing in; there, bare 
version numbers are purely advisory, so constraining them to set a lower bound 
is sane.  We'll see what happens when such a dependency resolution scheme is 
tested against the current defaults.

Re: what version numbers *should* mean, etc., at least when it comes to 
publicly-published libraries: I don't think it's a matter of optimism vs. 
pessimism.  A minor point is that, if you release a library with a constraint 
of [1.2.0,1.5.0), then to get an updated version that has an updated 
constraint, users may (will inevitably) have to swallow API or semantic changes 
that are orthogonal to the notion of tested with.  More importantly, users of 
libraries are always going to upgrade their dependencies faster than those 
dependencies' authors can qualify new releases against *their* dependencies.  
Indeed, given the way things work these days, projects constantly rely upon 
others' rarely-maintained work: people's interests and priorities shift, but if 
their libraries continue to work, then requiring everyone else to either wait 
for a new release (and for all intervening transitive dependencies to update 
accordingly) or manually override version ranges is counterproductive.  Signal 
re: breakage caused by some version X of a library will always propagate faster 
(and probably more accurately) by users bumping into things than by a careful 
author

Re: Securing Clojure + Clojurescript Web App

[Chas Emerick]

On Feb 26, 2013, at 11:24 AM, Ari wrote:

 Hi,
 
 I'd appreciate suggestions on how I can/should secure my 
 clojure/clojurescript single page web app that relies heavily on 
 shoreleave-remote. With other frameworks, upon authentication I've created a 
 roles cookie that the clientside uses to determine access rights to views, 
 while on the serverside I use a roles session variable to determine access 
 rights to GET/POST data. But Shoreleave side-steps the serverside 
 authentication/authorization (via friend), so I'm not sure how to proceed. 

What do you mean by sidesteps the auth?  If you're using 
shoreleave-remote-ring, then the handler produced by its wrap-rpc middleware is 
subject to whatever access controls you define via Friend.

- Chas

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

Re: Redefinition of datatypes

[Chas Emerick]

On Feb 23, 2013, at 11:35 AM, Stuart Sierra wrote:

 Furthermore, according to the policy of the Maven Central Repository, we 
 cannot deploy anything which depends on third-party repositories. Therefore 
 we cannot deploy core.typed to the Central Repository unless all its 
 dependencies are also deployed there.

Straying further off-topic, but: FWIW, unless they've changed the verification 
of POMs being promoted recently, that's not so.  The official guide to OSS 
deployment only says it's strongly discouraged 
(https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide),
 and links to blog posts that indicate that Sonatype is (was?) planning on 
rewriting POMs to remove external repository definitions, but tons of artifacts 
in central still contain them, e.g.:

http://repo1.maven.org/maven2/org/openid4java/openid4java-nodeps/0.9.6/openid4java-nodeps-0.9.6.pom

(…which refers to a now-defunct Guice repository, thus highlighting the 
rationale for the proposed no-external-repositories policy.)

Cheers,

- Chas

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

Re: does lein2 use repositories defined in ~/.m2/settings.xml?

[Chas Emerick]

On Feb 21, 2013, at 4:28 AM, Michael Klishin wrote:

 2013/2/21 James Xu xumingming64398...@gmail.com
 Thanks! But it sounds odd to me that lein does not use ~/.m2/settings.xml, 
 why this decision?
 
 I wasn't the one who's made this decision but here's my understanding.
 
 Leiningen 2 uses Aether for dependency management. Aether doesn't use 
 ~/.m2/settings.xml
 by default.

Aether actually has no facilities for consuming settings.xml AFAIK — that's 
entirely part of the mvn toolchain, not the underlying libraries.

- Chas

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

Re: *read-eval* vulnerability

[Chas Emerick]

Hi all,

It looks like Rich has selected an approach to addressing *read-eval*, #=, and 
related issues.  The sands may still be shifting a bit, but far less than e.g. 
earlier this week.  With that in mind, I thought it might be helpful to point 
to three authoritative messages from the clojure-dev ML that describe various 
relevant changes and additions coming in 1.5.0.  The first one contains a 
summary of the general principles involved, but note that the default mode 
described therein didn't last, as described in the second message:

http://groups.google.com/group/clojure-dev/msg/786c689b596bb6a3
http://groups.google.com/group/clojure-dev/msg/f299efc525f096e2
http://groups.google.com/group/clojure-dev/msg/8b572b8ebaba2ff5

Most relevant to the tactical concern of this thread (the default value of 
*read-eval* and its implications) is the new ability to set that default via a 
Java system property.

Hopefully the above satiates anyone yearning for news on this topic until the 
1.5.0 changelog is updated to reflect the relevant changes.

Finally, I just wanted to thank everyone, for your attention, energy, 
enthusiasm, and brilliance.  It's an honor to be among you.

Cheers,

- Chas

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

Re: *read-eval* vulnerability

[Chas Emerick]

Hi Baishampayan,

I got such errors when I first started working on the patch; they were caused 
by the compiler using print-dup'd strings to create namespaces instead of 
emitting bytecode (which the patched build includes).  Is it possible that you 
have both an org.clojure/clojure jar and the patched com.cemerick/clojure jar 
on your classpath?

FWIW, such metadata happens to exist in some nREPL namespaces, and some of my 
projects as well, so I presume that that's not the actual problem.

Just out of curiosity, do things work well if you use e.g. inferior-lisp or 
ritz?

Thanks for testing!

- Chas

On Feb 1, 2013, at 11:10 PM, Baishampayan Ghose wrote:

 Just did some testing with our code-base and Clojure 1.5.0-RC4 (with
 and without Chas' read-eval patch).
 
 There is definitely something strange going on. Things worked just
 fine with 1.5.0-RC4 but with the read-eval patch `lein swank` is
 completely broken but more than that, our code is failing to compile
 with this weird error -
 
 eval-reader: (clojure.lang.PersistentArrayMap/create {:author Joe Dev
 j...@helpshift.com, :doc Some doc here.})
 RuntimeException EvalReader not allowed when *read-eval* is false.
 clojure.lang.Util.runtimeException (Util.java:219)
 
 Almost all our namespaces have documentation attached via metadata like this -
 
 (ns ^{:doc Some doc here.
  :author Joe Dev j...@helpshift.com}
  com.helpshift.some.ns
  (:require [com.helpshift.other.ns :as chon])
  (:use clojure.test
midje.sweet))
 
 FWIW, the file that will fail to compile is random and I couldn't
 reproduce this error on a fresh project with just a couple of files.
 
 It's quite clear that the eval-reader is getting used from inside
 Clojure and we need to test out the edge cases a bit more.
 
 This is clearly not a low-impact fix, but IMHO we should take the time
 and get it right before 1.5.0
 
 Regards,
 BG
 
 
 On Sat, Feb 2, 2013 at 4:01 AM, Chas Emerick c...@cemerick.com wrote:
 I have added a patch to CLJ-1153 that appears to address the *read-eval* 
 problem:
 
 http://dev.clojure.org/jira/browse/CLJ-1153?focusedCommentId=30523#comment-30523
 
 code on github: 
 https://github.com/cemerick/clojure/commit/1f5c19c07443d2535ede4ff71d23b40c195d617f
 
 artifact on Clojars: [com.cemerick/clojure 1.5.0-SNAPSHOT]
 
 The Leiningen dependency above is 1.5.0-RC4 + the patch on the ticket.  Note 
 that you'll need to set your project's global :exclusions to 
 [org.clojure/clojure] in order for the com.cemerick/clojure artifact to 
 supersede it.
 
 It tests well for me, but needs to be exercised as much as possible.  Some 
 have already done so (there's an ongoing discussion on the clojure-dev ML 
 with some initial test experiences: 
 http://groups.google.com/group/clojure-dev/browse_frm/thread/cc6f747919db6c94),
  but I'm hoping that we can get as many eyes as possible on this — doing 
 both testing as well as code/patch examination — so as to ensure correctness 
 and maximize the chances of 1.5.0 final going out with this vulnerability 
 buttoned up.
 
 Thanks,
 
 - Chas
 
 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 
 
 
 
 -- 
 Baishampayan Ghose
 b.ghose at gmail.com
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

Re: *read-eval* vulnerability

[Chas Emerick]

Ah, I didn't grok that you were reporting two separate breakages (one in swank, 
one in your app).

I think the problem is in how the lein-swank plugin sets up dependencies (or, 
how Leiningen itself applies :exclusions).  If you don't have an 
org.clojure/clojure dependency in your project, then lein-swank will add one, 
its default (v1.2.1).  In this case, I found I did have two clojure jars; my 
1.5.0-SNAPSHOT, and [org.clojure/clojure 1.2.1].  This explains the bizarre 
message of No
matching ctor found for class clojure.lang.Compiler$CompilerException.  In my 
verification of swank, I ended up just temporarily swapping the 
com.cemerick/clojure build in where the official RC4 sits in ~/.m2/repository; 
once I did that, swank was happy.

I haven't yet been able to duplicate the other fault you saw.  If it was really 
due to namespace metadata, then `lein repl` wouldn't ever start, given 
clojure.tools.nrepl.server's namespace metadata 
(https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj).
  I wonder if you could produce a cut-down example that exhibits the issue 
repeatably?

Thanks,

- Chas

On Feb 2, 2013, at 9:22 AM, Baishampayan Ghose wrote:

 I put the canonical clojure artefact in a global exclusions vector in
 my project.clj. The classpath doesn't have any duplicate clojure jar
 in it. I was testing it out with `lein repl`, since swank-clojure is
 broken in different ways.
 
 Regards,
 BG
 
 On Sat, Feb 2, 2013 at 7:43 PM, Chas Emerick c...@cemerick.com wrote:
 Hi Baishampayan,
 
 I got such errors when I first started working on the patch; they were 
 caused by the compiler using print-dup'd strings to create namespaces 
 instead of emitting bytecode (which the patched build includes).  Is it 
 possible that you have both an org.clojure/clojure jar and the patched 
 com.cemerick/clojure jar on your classpath?
 
 FWIW, such metadata happens to exist in some nREPL namespaces, and some of 
 my projects as well, so I presume that that's not the actual problem.
 
 Just out of curiosity, do things work well if you use e.g. inferior-lisp or 
 ritz?
 
 Thanks for testing!
 
 - Chas
 
 On Feb 1, 2013, at 11:10 PM, Baishampayan Ghose wrote:
 
 Just did some testing with our code-base and Clojure 1.5.0-RC4 (with
 and without Chas' read-eval patch).
 
 There is definitely something strange going on. Things worked just
 fine with 1.5.0-RC4 but with the read-eval patch `lein swank` is
 completely broken but more than that, our code is failing to compile
 with this weird error -
 
 eval-reader: (clojure.lang.PersistentArrayMap/create {:author Joe Dev
 j...@helpshift.com, :doc Some doc here.})
 RuntimeException EvalReader not allowed when *read-eval* is false.
 clojure.lang.Util.runtimeException (Util.java:219)
 
 Almost all our namespaces have documentation attached via metadata like 
 this -
 
 (ns ^{:doc Some doc here.
 :author Joe Dev j...@helpshift.com}
 com.helpshift.some.ns
 (:require [com.helpshift.other.ns :as chon])
 (:use clojure.test
   midje.sweet))
 
 FWIW, the file that will fail to compile is random and I couldn't
 reproduce this error on a fresh project with just a couple of files.
 
 It's quite clear that the eval-reader is getting used from inside
 Clojure and we need to test out the edge cases a bit more.
 
 This is clearly not a low-impact fix, but IMHO we should take the time
 and get it right before 1.5.0
 
 Regards,
 BG
 
 
 On Sat, Feb 2, 2013 at 4:01 AM, Chas Emerick c...@cemerick.com wrote:
 I have added a patch to CLJ-1153 that appears to address the *read-eval* 
 problem:
 
 http://dev.clojure.org/jira/browse/CLJ-1153?focusedCommentId=30523#comment-30523
 
 code on github: 
 https://github.com/cemerick/clojure/commit/1f5c19c07443d2535ede4ff71d23b40c195d617f
 
 artifact on Clojars: [com.cemerick/clojure 1.5.0-SNAPSHOT]
 
 The Leiningen dependency above is 1.5.0-RC4 + the patch on the ticket.  
 Note that you'll need to set your project's global :exclusions to 
 [org.clojure/clojure] in order for the com.cemerick/clojure artifact to 
 supersede it.
 
 It tests well for me, but needs to be exercised as much as possible.  Some 
 have already done so (there's an ongoing discussion on the clojure-dev ML 
 with some initial test experiences: 
 http://groups.google.com/group/clojure-dev/browse_frm/thread/cc6f747919db6c94),
  but I'm hoping that we can get as many eyes as possible on this — doing 
 both testing as well as code/patch examination — so as to ensure 
 correctness and maximize the chances of 1.5.0 final going out with this 
 vulnerability buttoned up.
 
 Thanks,
 
 - Chas
 
 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more

Re: *read-eval* vulnerability

[Chas Emerick]

One thing that hasn't been mentioned so far is that AOT-compiled classfiles 
generated using prior builds of Clojure will not load using a build of Clojure 
that includes a patch like this.  Just something to consider for those of you 
taking the time to test, etc.

- Chas

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

Re: *read-eval* vulnerability

[Chas Emerick]

On Jan 31, 2013, at 8:03 PM, Chas Emerick wrote:

 
 On Jan 30, 2013, at 5:59 PM, Michał Marczyk wrote:
 
 On 30 January 2013 23:32, Chas Emerick c...@cemerick.com wrote:
 On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote:
 
 RuntimeException EvalReader not allowed when *read-eval* is false.
 
 The problem is that the second eval gets (the actual + function 1 2
 3) which invokes the right pathway triggering the exception.  You can
 trigger the same exception by:
 
 (binding [*read-eval* false] (eval (list + 1 2 3)))
 
 Re-reading this, I'm clearly not grokking something here.  Maybe I'm having 
 a slow afternoon; send help. :-P
 
 This obviously ends up running through EvalReader — but why?  How is 
 LispReader ever involved at all?
 
 I believe the story goes like so:
 
 The eval call here compiles a list of a function object and three
 numbers. The function object gets compiled to code which effectively
 calls readString on #=(clojure.core$_PLUS_. ). (It so happens that
 print-dup knows how to handle functions; if it didn't, an exception
 would be thrown during compilation with the message Can't embed
 object in code, maybe print-dup not defined: ) When the compiled
 code is executed, readString gets called to reconstruct the function,
 and since *read-eval* is false, this fails.
 
 Whoo, sneaky.  If only fns carried (most of) the metadata that their 
 originating vars were defined with, print-dup would be able to emit a 
 fully-qualified symbol instead of that bonkers ctor call...I think.
 
 This explains why my plan for a nuclear option for fixing *read-eval*'s 
 default doesn't work when outside of a bare `java -cp ... clojure.main` REPL:
 
   https://gist.github.com/4674181
 
 Much of the initialization of the nREPL / Leiningen / Reply toolchain 
 involves evaluating code that's been prn'ed, and there may very well be a 
 couple of nested `eval` usages lurking in there similar to what Fogus raised.
 
 So, getting *read-eval* to a safe default is going to require more than just 
 setting its default to false; all usages of #= in 
 https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_print.clj 
 need to be eliminated.  Will be peeking at that next...

It looks like print-dup is actually significantly relied upon by the compiler 
when emitting constants (e.g. keyword and symbol literals, namespaces, vars, 
etc) for generated classes.  (There might be other usages that I haven't 
uncovered yet, but I don't *think* so.)  I think that that print-dup usage will 
need to be replaced with corresponding asm method emits if we are to default 
*read-eval* to false without introducing eval-related limitations that will 
appear to nearly all users to be arbitrary and capricious.

Per usual, I'm in over my head around compiler issues, but we'll see what next 
week brings.  I suspect others that have done more compiler hacking than I 
would have an easier time of it...

Cheers,

- Chas

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

Re: *read-eval* vulnerability

[Chas Emerick]

I have added a patch to CLJ-1153 that appears to address the *read-eval* 
problem:

http://dev.clojure.org/jira/browse/CLJ-1153?focusedCommentId=30523#comment-30523

code on github: 
https://github.com/cemerick/clojure/commit/1f5c19c07443d2535ede4ff71d23b40c195d617f

artifact on Clojars: [com.cemerick/clojure 1.5.0-SNAPSHOT]

The Leiningen dependency above is 1.5.0-RC4 + the patch on the ticket.  Note 
that you'll need to set your project's global :exclusions to 
[org.clojure/clojure] in order for the com.cemerick/clojure artifact to 
supersede it.

It tests well for me, but needs to be exercised as much as possible.  Some have 
already done so (there's an ongoing discussion on the clojure-dev ML with some 
initial test experiences: 
http://groups.google.com/group/clojure-dev/browse_frm/thread/cc6f747919db6c94), 
but I'm hoping that we can get as many eyes as possible on this — doing both 
testing as well as code/patch examination — so as to ensure correctness and 
maximize the chances of 1.5.0 final going out with this vulnerability buttoned 
up.

Thanks,

- Chas

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

multicore list processing (was Re: abysmal multicore performance, especially on AMD processors)

[Chas Emerick]

Keeping the discussion here would make sense, esp. in light of meetup.com's 
horrible discussion board.

I don't have a lot to offer on the JVM/Clojure-specific problem beyond what I 
wrote in that meetup thread, but Lee's challenge(s) were too hard to resist:

 Would your conclusion be something like 'Intensive list processing can't 
 currently be done in Java (or Clojure/JVM) in a way that takes reasonable 
 advantage of multiple cores.'?


 I see that rewrite without lists might be the only way out, but that'd be 
 a bummer. Clojure is a multicore Lisp; if you can't use it for multicore list 
 processing then... sigh.

The nature of the `burn` program is such that I'm skeptical of the ability of 
any garbage-collected runtime (lispy or not) to scale its operation across 
multiple threads.  It generates a huge amount of garbage that is held for a 
very long time (in GC terms), thus producing a great deal of contention on the 
heap between the active job threads and the GC implementation constantly having 
to clean up after them, compact the results, etc.  The workload is not 
CPU-bound, so I don't see it being parallelized effectively.

I'd be very interested in seeing an implementation for a runtime that proves me 
wrong, i.e. can attain significant performance benefits by running the e.g. 8 
`burn` jobs across multiple threads.

In an attempt to do just that (prove myself wrong), I thought I'd golf the 
`burn` program (again; onlookers can go look at the Java implementation I 
knocked out a few days ago here: https://gist.github.com/4682554) on Racket, 
presumably as well-suited to multicore list processing as any other.  The 
results:

https://gist.github.com/4682453

Please forgive my perhaps pitiful Racket-fu.  I'm sure there's threadpool and 
CAS libraries available, but it was entertaining to hack away with the 
threading and semaphore primitives.  If I've goofed something up badly (it's 
been some time since I've schemed), please speak up.

The Racket and Java implementations are effectively equivalent:

`java -server -Xmx2g cemerick.burn $THREAD_COUNT`  (oracle java 1.7.0_09)
1 thread: 61s
2 threads: 126s

`java -server -Xmx2g cemerick.burn $THREAD_COUNT`  (oracle java 1.7.0_09)
1 thread: 47s
2 threads: 92s

`time ./racket -t ~/burn.scm -m $THREAD_COUNT`  (racket 5.3.1)
1 thread: 45s
2 threads: 126s

The above was run on OS X 10.7.5 with 4GB of physical memory.  If someone knows 
of ways to get better perf on racket, let me know.  I tried running from the 
results of `raco make` and such, but saw no improvements; I guess it is 
strictly producing bytecode that is later JIT'ed, and not doing any kind of 
additional AOT optimizations...

It'd be interesting to see timings from different operating systems, and very 
interesting to see timings from running burn.scm on other schemes, or a Common 
Lisp implementation and timings.

Cheers,

- Chas

On Jan 30, 2013, at 9:20 PM, Lee Spector wrote:

 
 FYI we had a bit of a discussion about this at a meetup in Amherst MA 
 yesterday, and while I'm not sufficiently on top of the JVM or system issues 
 to have briefed everyone on all of the details there has been a little of 
 followup since the discussion, including results of some different 
 experiments by Chas Emerick, at: 
 http://www.meetup.com/Functional-Programming-Connoisseurs/messages/boards/thread/30946382
 
 -Lee
 
 On Jan 30, 2013, at 8:39 PM, Marshall Bockrath-Vandegrift wrote:
 
 Apologies for my very-slow reply here.  I keep thinking that I’ll have
 more time to look into this issue, and keep having other things
 requiring my attention.  And on top of that, I’ve temporarily lost the
 many-way AMD system I was using as a test-bed.
 
 I very much want to see if I can get my hands on an Intel system to
 compare to.  My AMD system is in theory 32-way – two physical CPUs, each
 with 16 cores.  However, Linux reports (via /proc/cpuinfo) the cores in
 groups of 8 (“cpu cores : 8” etc).  And something very strange happens
 when extending parallelism beyond 8-way...  I ran several experiments
 using a version of your whole-application benchmark I modified to
 control the level of parallelism.  At parallelism 9+, the real time it
 takes to complete the benchmark hardly budges, but the user/CPU time
 increases linearly with the level of parallelism!  As far as I can tell,
 multi-processor AMD *is* a NUMA architecture, which might potentially
 explain things.  But enabling the JVM NUMA options doesn’t seem to
 affect the benchmark.
 
 I think next steps are two-fold: (1) examine parallelism vs real  CPU
 time on an Intel system, and (2) attempt to reproduce the observed
 behavior in pure Java.  I’m keeping my fingers crossed that I’ll have
 some time to look at this more soon, but I’m honestly not very hopeful.
 
 In the mean time, I hope you’ve managed to exploit multi-process
 parallelism to run more efficiently?
 
 -Marshall
 
 -- 
 -- 
 You received this message because you are subscribed

Re: multicore list processing (was Re: abysmal multicore performance, especially on AMD processors)

[Chas Emerick]

On Jan 31, 2013, at 9:23 AM, Marshall Bockrath-Vandegrift wrote:

 Chas Emerick c...@cemerick.com writes:
 
 The nature of the `burn` program is such that I'm skeptical of the
 ability of any garbage-collected runtime (lispy or not) to scale its
 operation across multiple threads.
 
 Bringing you up to speed on this very long thread, I don’t believe the
 original `burn` benchmark is a GC issue, due to results cameron first
 reported here:
 
https://groups.google.com/d/msg/clojure/48W2eff3caU/83uXZjLi3iAJ
 
 I that narrowed to what I still believe to be the explanation here:
 
https://groups.google.com/d/msg/clojure/48W2eff3caU/jd8dpmzEtEYJ
 
 And have more compact demonstration benchmark results here:
 
https://groups.google.com/d/msg/clojure/48W2eff3caU/tCCkjXxTUMEJ
 
 I haven’t been able to produce those results in a minimal Java-only test
 case, though.
 
 Then Wm. Josiah posted a full-application benchmark, which appears to
 have entirely different performance problems from the synthetic `burn`
 benchmark.  I’d rejected GC as the cause for the slowdown there too, but
 ATM can’t recall why or what I tested, so GC may definitely be a
 candidate to re-examine:
 
https://groups.google.com/d/msg/clojure/48W2eff3caU/K224Aqwkn5YJ
 
 Quite looking forward to additional insight...

Yeah, the thread is far too large for me to reasonably digest (and there's 
inevitably a lot of noise in rounds of microbenchmarking golf ;-)

BTW, I just realized I copy/pasted the wrong command for the faster of the Java 
implementation benchmarks in the previous mail; it used -XX:-UseParallelGC:

`java -server -Xmx2g -XX:-UseParallelGC cemerick.burn $THREAD_COUNT`

I've not looked at clojush at all; it is AFAICT a complex application in its 
own right, and I wouldn't know where to start.  My understanding is that the 
`burn` function is considered representative of the bulk of operations in 
clojush, but I'm happy to assume that that's not the case.  There's likely a 
number of things that go into the results of the `burn` benchmark, nevermind 
the apparent performance of clojush.

Here's what I know:

* Two separate implementations (Java and Racket) exhibit very similar multicore 
performance characteristics.  In particular, the Java implementation would not 
suffer from any particular megamorphic inefficiencies, since no such calls are 
made in that program.  Racket is far more of a black box to me than the JVM, 
but it does not provide much of any polymorphism at all, so JIT-related issues 
are presumably not in scope there.

* Broadly speaking, heap allocation and its evil twin, GC, sabotages 
parallelism and performance in general.  Functional programming with immutable 
values has been made possible in large part by the gains registered by 
persistent data structures, structural sharing, lazy evaluation, and so on; 
without them, we're back to copy-on-write, which is roughly what `burn` 
represents in grand style.

Now, all this digital ink spilled, and just for kicks, I go back to run the 
Clojure `burn` again (https://gist.github.com/4683413 in a 1.5.0-RC2 REPL 
started with jvm args of `-Xmx2g -XX:-UseParallelGC`):

1 thread: 38s
2 threads: 32s
4 threads: 23s

Hardly a 2x or 4x improvement, but I had previously obtained badly degrading 
timings corresponding to those in my previous mail.  Microbenchmarking sucks.   
At least I got to twiddle with Racket again.  :-P

Cheers,

- Chas

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

Re: *read-eval* vulnerability

[Chas Emerick]

On Jan 30, 2013, at 5:59 PM, Michał Marczyk wrote:

 On 30 January 2013 23:32, Chas Emerick c...@cemerick.com wrote:
 On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote:
 
 RuntimeException EvalReader not allowed when *read-eval* is false.
 
 The problem is that the second eval gets (the actual + function 1 2
 3) which invokes the right pathway triggering the exception.  You can
 trigger the same exception by:
 
 (binding [*read-eval* false] (eval (list + 1 2 3)))
 
 Re-reading this, I'm clearly not grokking something here.  Maybe I'm having 
 a slow afternoon; send help. :-P
 
 This obviously ends up running through EvalReader — but why?  How is 
 LispReader ever involved at all?
 
 I believe the story goes like so:
 
 The eval call here compiles a list of a function object and three
 numbers. The function object gets compiled to code which effectively
 calls readString on #=(clojure.core$_PLUS_. ). (It so happens that
 print-dup knows how to handle functions; if it didn't, an exception
 would be thrown during compilation with the message Can't embed
 object in code, maybe print-dup not defined: ) When the compiled
 code is executed, readString gets called to reconstruct the function,
 and since *read-eval* is false, this fails.

Whoo, sneaky.  If only fns carried (most of) the metadata that their 
originating vars were defined with, print-dup would be able to emit a 
fully-qualified symbol instead of that bonkers ctor call...I think.

This explains why my plan for a nuclear option for fixing *read-eval*'s 
default doesn't work when outside of a bare `java -cp ... clojure.main` REPL:

https://gist.github.com/4674181

Much of the initialization of the nREPL / Leiningen / Reply toolchain involves 
evaluating code that's been prn'ed, and there may very well be a couple of 
nested `eval` usages lurking in there similar to what Fogus raised.

So, getting *read-eval* to a safe default is going to require more than just 
setting its default to false; all usages of #= in 
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_print.clj 
need to be eliminated.  Will be peeking at that next...

- Chas

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

Re: *read-eval* vulnerability

[Chas Emerick]

This is exactly the thread that I meant to start a couple of weeks ago.  Thanks 
for giving me the kick in the pants, Takahiro. :-)

What brought the issue to the fore for me:

* a greatly increased interest in security issues due to my own work's 
requirements
* the most recent arbitrary code execution issues that the Rails community has 
had to weather
* Building and maintaining Friend (http://github.com/cemerick/friend) has 
gradually brought me into contact with a handful of suitably experienced people 
that have done security reviews (none formal or published, BTW) of the Clojure 
web stack.

In each of the three times I've been fortunate to discuss those reviews with 
their instigators, the first thing that comes up is *read-eval*.  Perhaps not 
surprising — we've all known that its default is an open barn door.  The sole 
thread I could dig up that discusses this is 
http://groups.google.com/group/clojure/browse_frm/thread/1bd6b66b51406ec9?tvc=1,
 where the common refrain is simply you should bind *read-eval* to false when 
reading data from unknown sources.  Despite this not being news, recent events 
and certain changes in my foci have made it a newly-important issue, at least 
to me.

Takahiro is exactly right that the growing usage of Clojure data / edn as a 
common serialization format for e.g. web service APIs makes the default of 
*read-eval* very, very relevant; IMO, despite any concerns re: breaking 
existing code.  On that front, *read-eval* affects only the #= construction, a 
facility that is, IIRC, purposefully undocumented.  This lack of documentation 
is good insofar as few people have used #=, but it has also left undocumented 
an implementation detail of the reader that ships with a dangerous default (see 
http://dev.clojure.org/jira/browse/CLJ-904).

The advice and necessity to tighten up *read-eval* as good practice is a 
design fault.  There are things that authors of certain key Clojure libraries 
can do to fix this up as a side effect of using those libraries, but it would 
obviously be ideal for Clojure/core to address the policy proactively.  
Otherwise, I'm certain that a time will come when people not steeped in Clojure 
arcana will be deploying vulnerable applications and services.  Unfortunately, 
I suspect that time has long since arrived...we just don't (yet?) have the 
eyeballs and juice that the Rails community has to produce controversy.

Cheers,

- Chas

On Jan 30, 2013, at 2:02 AM, Takahiro Hozumi wrote:

 As more and more projects are using edn format for config,
 communication and etc, I think that default value of *read-eval*,
 which is true, is source of vulnerability such as recently reported
 ring issue [1].
 And I don't understand why read-string depends on *read-eval* instead
 of argument.
 I believe optional argument is more preferable.
 What do you think?
 
 [1] Ring 1.0.3 / 1.1.7 released to fix security flaw
 https://groups.google.com/group/clojure/browse_thread/thread/7b0fe662867b9124
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

Re: *read-eval* vulnerability

[Chas Emerick]

I think the objective is to make read, read-string, etc. safe.  Explicit use of 
eval is what it is...short of sandboxing, you're opting into all that eval 
implies.

- Chas

Michael Fogus mefo...@gmail.com wrote:

 RuntimeException EvalReader not allowed when *read-eval* is false.

The problem is that the second eval gets (the actual + function 1 2
3) which invokes the right pathway triggering the exception.  You can
trigger the same exception by:

(binding [*read-eval* false] (eval (list + 1 2 3)))

People are not sending actual functions across the wire, so the only
way to trigger this is to do some kind of pre-processing of symbols to
functions or perhaps:

(binding [*read-eval* false] (eval '(eval (quote (+ 1 2 3)
;;= 6

Whoops!

Maybe setting *read-eval* to false is not enough.

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

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

Re: *read-eval* vulnerability

[Chas Emerick]

On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote:

 RuntimeException EvalReader not allowed when *read-eval* is false.
 
 The problem is that the second eval gets (the actual + function 1 2
 3) which invokes the right pathway triggering the exception.  You can
 trigger the same exception by:
 
 (binding [*read-eval* false] (eval (list + 1 2 3)))

Re-reading this, I'm clearly not grokking something here.  Maybe I'm having a 
slow afternoon; send help. :-P

This obviously ends up running through EvalReader — but why?  How is LispReader 
ever involved at all?

Thanks,

- Chas

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

Re: do background threads sometimes swallow exceptions?

[Chas Emerick]

On Jan 29, 2013, at 4:56 PM, Michael Klishin wrote:

 
 2013/1/30 larry google groups lawrencecloj...@gmail.com
 That is good to know. I have the top level function call wrapped in a 
 try/catch block, but I suppose I'll get better results if I do more of the 
 try/catch at a lower level, closer to the problem.
 
 Wrap the entire new thread body in a try/catch, it should reveal any 
 exceptions there may be.

Also, if you're actually revving up new Threads, this sometimes comes in handy:


http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler%28java.lang.Thread.UncaughtExceptionHandler%29

- Chas

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

Re: Error on redirect when attempting unauthorized entry to Friend route

[Chas Emerick]

If you're being redirected to:

http://localhost:4/login?login_failed=Yusername=lawrence

Then the problem is that you're not using the credentials for one of the users 
you've specified (e.g. root or jane).

- Chas

On Jan 17, 2013, at 1:43 PM, larry google groups wrote:

 
 How should I debug this? What questions should I ask?
 
 At this point, for the sake of debugging, I have everything in one
 file, in one name space. I have recreated the dummy users database:
 
 
 (def users {root{:username lawrence
   :password (creds/hash-bcrypt admin_password)
   :roles #{::admin}
   :created_at 2013-01-08 14:00:00
   :telephone-numbers [{:country USA :number 434
 825 7694}
   {:country USA :number 732
 364 3640}]}
jane {:username jane
:password (creds/hash-bcrypt user_password)
:roles #{::user}
:created_at 2013-01-10 16:40:34
:telephone-numbers []}})
 
 
 And, as far as I know, I have set up the routes with Compojure and
 Friend correctly:
 
 (defroutes app-routes
  (GET / request (index request))
  (GET /search-results request (search-results request))
  (GET /schema request (schema request))
  (GET /account request (friend/authorize #{::user} {} (account
 request)))
  (GET /admin request (friend/authorize #{::admin} {} (admin
 request)))
  (friend/logout (ANY /logout request (ring.util.response/redirect
 /)))
  (GET /login request (login request))
  (route/not-found Page not found))
 
 (def app
(- app-routes
(friend/authenticate {:credential-fn (partial creds/bcrypt-
 credential-fn users)
  :workflows [(workflows/interactive-
 form)]})
(wrap-resource public)
(wrap-session {:cookie-name discovery-session :cookie-attrs
 {:max-age 1 }})
(wrap-cookies)
(wrap-keyword-params)
(wrap-nested-params)
(wrap-params)))
 
 (defn -main [ args]
  (let [port (Integer/parseInt (first args))]
(try
  (run-jetty #'app {:port (or port 8080) :join? false})
  (catch Exception e (debug/print-error-info e)
 
 When I go here:
 
 http://localhost:4/admin
 
 I get redirected to here:
 
 http://localhost:4/login
 
 So far, so good.
 
 But when I try to log in, I end up with this for an URL:
 
 http://localhost:4/login?login_failed=Yusername=lawrence
 
 I am wondering how I should debug this?
 
 The admin function looks like this:
 
 (defn admin [request]
  (let [page-with-banner (add-banner-image-to-page)
page-with-result (enlive/at page-with-
 banner
[:#trips]
(enlive/content
 (apply str (dashboard)))
page-string (apply str (enlive/emit* page-with-result))]
(response page-string)))
 
 How should I debug this? How do I find out what is not working? What
 questions should I ask?
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: Unexpected failure (split function)

[Chas Emerick]

Looks like a reply issue.  The expression in question evals fine in ccw with 
the latest nREPL, and in lein 2.0.0-beta10 (which used some beta of reply 
0.1.0) with the latest nREPL.  Lein 2.0.0-RC2 with reply 0.1.6 is affected, 
though.

- Chas

On Jan 18, 2013, at 3:13 PM, Andy Fingerhut wrote:

 This issue appears to be unique to using a Leiningen version 2 REPL.
 
 It does not occur if using java -cp clojure.jar clojure.main to get a REPL, 
 nor with Leiningen version 1.7.1.
 
 CCing nrepl developer Chas Emerick in case this might be an issue with nrepl, 
 but I haven't attempted to localize the problem any further than mentioned 
 above.
 
 Andy
 
 On Jan 18, 2013, at 11:32 AM, Thomas wrote:
 
 Hi,
 
 When I run this in my REPL I get an exception and the REPL exits:
 
 user= (clojure.string/split asdfsa;asdf;asdf #; )
 Exception Ambiguous match for ;\ ) by #Object[] 
 [Ljava.lang.Object;@77237723
  net.cgrand.parsley.lrplus/array-union/fn--4060 (lrplus.clj:91)
  net.cgrand.parsley.lrplus/matchers-union/fn--4072 (lrplus.clj:118)
  net.cgrand.parsley.lrplus/step1 (lrplus.clj:166)
  net.cgrand.parsley.lrplus/step (lrplus.clj:190)
  net.cgrand.parsley/stepper/self--4854 (parsley.clj:39)
  net.cgrand.parsley/stepper/self--4854 (parsley.clj:36)
  reply.eval-modes.nrepl/parsed-forms (nrepl.clj:72)
  reply.eval-modes.nrepl/parsed-forms (nrepl.clj:66)
  reply.eval-modes.nrepl/run-repl (nrepl.clj:103)
  reply.eval-modes.nrepl/main (nrepl.clj:189)
  reply.main/launch-nrepl/fn--5375 (main.clj:60)
  clojure.core/with-redefs-fn (core.clj:6585)
 Bye for now!
 
 If I do use #\; (note the \ in there) it works as expected.
 
 Surely this is unexpected (the REPL ending that is), but what about escaping 
 the ; It is after all in a string and I wouldn't expect it to be seen as a 
 comment.
 
 REPL-y 0.1.6
 Clojure 1.4.0
 
 Are my versions.
 
 TIA,
 Thomas
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: Error on redirect when attempting unauthorized entry to Friend route

[Chas Emerick]

On Jan 16, 2013, at 1:45 AM, larry google groups wrote:

 For anyone else who might make the same mistake I did, I changed this:
 
  (GET /admin request (friend/authorize #{::admin}  (admin
 request)))
 
 to this:
 
  (GET /admin request (friend/authorize #{::admin} {} (admin
 request)))
 
 adding an empty map before the string that is my actual HTML page.
 That resolved the error in the stack trace.
 
 However, my login still fails. I copy and paste both the username and
 password, very carefully, into the login form, and hit submit, only to
 get redirected to:
 
 http://localhost:3/login?login_failed=Yusername=
 
 I have not idea why this fails. I thought I had followed the
 documentation carefully, but I suppose there is always something that
 I miss.

Are you using the keyword-params middleware?  It's not in the code you 
initially provided, and you don't mention adding it after seeing the note about 
it being required.  If you are submitting a value for the `username` parameter 
to /login, but the failure redirect does not echo that username, then a lack of 
keyword-params is indicated.

- Chas

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

Re: Error on redirect when attempting unauthorized entry to Friend route

[Chas Emerick]

On Jan 16, 2013, at 9:07 AM, larry google groups wrote:

 
 I define a var with user info like this:
 
 (ns kiosks-clojure.fake-data-for-development
  (:require [cemerick.friend :as friend]
(cemerick.friend [workflows :as workflows]
 [credentials :as creds])))
 (def fake-data
  {
   :users {:root {:username la...@wonderful.com
  :password (creds/hash-bcrypt admin_password)
  :roles #{::admin}
  :created_at 2013-01-08 14:00:00
  :telephone-numbers [{:country USA :number 434 825
 7694}
  {:country USA :number 732 364
 3640}]}
   :jane {:username j...@wonderful.com
  :password (creds/hash-bcrypt user_password)
  :roles #{::user}
  :created_at 2013-01-10 16:40:34
  :telephone-numbers []}}
 })
 
 Then in my core namespace, I add this to an atom:
 
 (def interactions (atom fd/fake-data))
 
 
 And then later I fetch this and add this to the authentication of
 friend:
 
 (def app
(- app-routes
(friend/authenticate {:credential-fn (partial creds/bcrypt-
 credential-fn (:users @interactions))
  :workflows [(workflows/interactive-
 form)]})
(wrap-resource public)
(wrap-session {:cookie-name discovery-session :cookie-attrs
 {:max-age 1 }})
(wrap-cookies)
(wrap-params)))
 
 
 
 Any thoughts about where I should try to debug this?

You're still not using wrap-keyword-params.

- Chas

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

Re: Error on redirect when attempting unauthorized entry to Friend route

[Chas Emerick]

On Jan 16, 2013, at 12:03 PM, larry google groups wrote:

 I am ignorant about the implications of using :: to namespace vars.
 The fact that I have ::admin in one namespace:
 
:users {root{:username lawrence
   :password (creds/hash-bcrypt admin_password)
   :roles #{::admin}
   :created_at 2013-01-08 14:00:00
   :telephone-numbers [{:country USA :number 434 825
 7694}
   {:country USA :number 732 364
 3640}]}
jane {:username jane
   :password (creds/hash-bcrypt user_password)
   :roles #{::user}
   :created_at 2013-01-10 16:40:34
   :telephone-numbers []}}
 
 but then in the core name space I have:
 
 (derive ::admin ::user)
 
 and:
 
  (GET /account request (friend/authorize #{::user} {} (account
 request)))
  (GET /admin request (friend/authorize #{::admin} {} (admin
 request)))
 
 I assume I need to change this. What are the implications? These
 declarations of roles all need to reference the same namespace, yes?


::foo is unrelated to vars; that's just a keyword that happens to have a 
namespace component of *ns*.  If you use `::foo` in namespace A, that is 
namespaced as `:A/foo`, whereas the same `::foo` in B is equivalent to 
`:B/foo`.  For further understanding, I suggest taking a look at 
http://clojure.org/multimethods, or the hierarchy/multimethod/namespaced 
keyword section of your local Clojure book.

The roles you use don't all have to be identically namespaced; that would 
defeat the point of using hierarchies to model relationships among independent 
sets of roles.  However, if you want to refer to a given namespace's ::user, 
then you do need to refer to it that way, e.g. :ns-alias/user or 
:full.ns.name/user.

Cheers,

- Chas

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

Re: How do I install guice?

[Chas Emerick]

Please change your Friend dependency to [com.cemerick/friend 0.1.3].

Prior versions transitively depended upon a Guice artifact that was hosted on a 
now-404 Maven repository via Google Code's svn.  Friend = 0.1.3 depends only 
on artifacts available in Clojars and Maven Central, and will remain that way.

Sorry for the inconvenience,

- Chas

On Jan 14, 2013, at 10:23 AM, larry google groups wrote:

 I am building a web app. I just included Compojure and Friend as
 dependencies, and one of these, in turn, relies on Google Guice. I
 type:
 
 lein uberjar
 
 and I get a whole lot of output which includes:
 
 Could not find artifact com.google.code.guice:guice:pom:2.0 in central
 (http://repo1.maven.org/maven2)
 Could not find artifact com.google.code.guice:guice:pom:2.0 in clojars
 (https://clojars.org/repo/)
 Could not transfer artifact com.google.code.guice:guice:pom:2.0 from/
 to guice (http://guice-maven.googlecode.com/svn/trunk): Not
 authorized, ReasonPhrase:Authorization Required.
 Could not find artifact com.google.code.guice:guice:pom:2.0 in
 alchim.snapshots (http://alchim.sf.net/download/snapshots)
 Check :dependencies and :repositories for typos.
 It's possible the specified jar is not in any repository.
 If so, see Free-floating Jars under http://j.mp/repeatability
 Uberjar aborting because jar/compilation failed: Could not resolve
 dependencies
 
 
 I find instructions for installing guice here:
 
 http://code.google.com/p/roboguice/issues/detail?id=38
 
 I download guice from here:
 
 http://code.google.com/p/google-guice/downloads/list
 
 On my Mac, at the command line, I then run:
 
 mvn install:install-file -DgroupId=com.google.android.maps -
 DartifactId=maps -Dversion=3_r3 -Dpackaging=jar -Dfile=/Users/lkrubner/
 Downloads/guice-2.0/guice-2.0.jar
 
 and I get:
 
 [INFO] Scanning for projects...
 [INFO]
 [INFO]
 
 [INFO] Building Maven Stub Project (No POM) 1
 [INFO]
 
 [INFO]
 [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @
 standalone-pom ---
 [INFO] Installing /Users/lkrubner/Downloads/guice-2.0/guice-2.0.jar
 to /Users/lkrubner/.m2/repository/com/google/android/maps/maps/3_r3/
 maps-3_r3.jar
 [INFO]
 
 [INFO] BUILD SUCCESS
 [INFO]
 
 [INFO] Total time: 0.718s
 [INFO] Finished at: Mon Jan 14 10:18:44 EST 2013
 [INFO] Final Memory: 4M/92M
 [INFO]
 
 
 
 I then again run:
 
 lein uberjar
 
 and again I get:
 
 lein uberjar
 Could not find artifact com.google.code.guice:guice:pom:2.0 in central
 (http://repo1.maven.org/maven2)
 Could not find artifact com.google.code.guice:guice:pom:2.0 in clojars
 (https://clojars.org/repo/)
 Could not transfer artifact com.google.code.guice:guice:pom:2.0 from/
 to guice (http://guice-maven.googlecode.com/svn/trunk): Not
 authorized, ReasonPhrase:Authorization Required.
 Could not find artifact com.google.code.guice:guice:pom:2.0 in
 alchim.snapshots (http://alchim.sf.net/download/snapshots)
 Check :dependencies and :repositories for typos.
 It's possible the specified jar is not in any repository.
 If so, see Free-floating Jars under http://j.mp/repeatability
 Uberjar aborting because jar/compilation failed: Could not resolve
 dependencies
 
 What am I doing wrong?
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: How do I install guice?

[Chas Emerick]

Instead of this:

[friend-oauth2 0.0.2]

Use this:

[friend-oauth2 0.0.2 :exclusions [com.cemerick/friend]]
[com.cemerick/friend 0.1.3]

That will keep lein from attempting to resolve the now-gone Guice artifact 
transitively referred to by the older revs of friend.

- Chas

On Jan 14, 2013, at 11:48 AM, larry google groups wrote:

 Thank you for the fast reply. That helped. But do you (or anyone else
 here) know of a workaround for friend-oauth2? I get:
 
 lein uberjar
 Could not find artifact friend-oauth2:friend-oauth2:pom:0.0.2 in
 central (http://repo1.maven.org/maven2)
 Retrieving friend-oauth2/friend-oauth2/0.0.2/friend-oauth2-0.0.2.pom
 (4k)
from https://clojars.org/repo/
 Could not find artifact com.google.code.guice:guice:pom:2.0 in central
 (http://repo1.maven.org/maven2)
 Could not find artifact com.google.code.guice:guice:pom:2.0 in clojars
 (https://clojars.org/repo/)
 Could not find artifact com.google.code.guice:guice:pom:2.0 in stuart
 (http://stuartsierra.com/maven2)
 Could not transfer artifact com.google.code.guice:guice:pom:2.0 from/
 to guice (http://guice-maven.googlecode.com/svn/trunk): Not
 authorized, ReasonPhrase:Authorization Required.
 Could not find artifact com.google.code.guice:guice:pom:2.0 in
 alchim.snapshots (http://alchim.sf.net/download/snapshots)
 
 
 
 
 On 14 Sty, 11:12, Chas Emerick c...@cemerick.com wrote:
 Please change your Friend dependency to [com.cemerick/friend 0.1.3].
 
 Prior versions transitively depended upon a Guice artifact that was hosted 
 on a now-404 Maven repository via Google Code's svn.  Friend = 0.1.3 
 depends only on artifacts available in Clojars and Maven Central, and will 
 remain that way.
 
 Sorry for the inconvenience,
 
 - Chas
 
 On Jan 14, 2013, at 10:23 AM, larry google groups wrote:
 
 
 
 
 
 
 
 I am building a web app. I just included Compojure and Friend as
 dependencies, and one of these, in turn, relies on Google Guice. I
 type:
 
 lein uberjar
 
 and I get a whole lot of output which includes:
 
 Could not find artifact com.google.code.guice:guice:pom:2.0 in central
 (http://repo1.maven.org/maven2)
 Could not find artifact com.google.code.guice:guice:pom:2.0 in clojars
 (https://clojars.org/repo/)
 Could not transfer artifact com.google.code.guice:guice:pom:2.0 from/
 to guice (http://guice-maven.googlecode.com/svn/trunk):Not
 authorized, ReasonPhrase:Authorization Required.
 Could not find artifact com.google.code.guice:guice:pom:2.0 in
 alchim.snapshots (http://alchim.sf.net/download/snapshots)
 Check :dependencies and :repositories for typos.
 It's possible the specified jar is not in any repository.
 If so, see Free-floating Jars underhttp://j.mp/repeatability
 Uberjar aborting because jar/compilation failed: Could not resolve
 dependencies
 
 I find instructions for installing guice here:
 
 http://code.google.com/p/roboguice/issues/detail?id=38
 
 I download guice from here:
 
 http://code.google.com/p/google-guice/downloads/list
 
 On my Mac, at the command line, I then run:
 
 mvn install:install-file -DgroupId=com.google.android.maps -
 DartifactId=maps -Dversion=3_r3 -Dpackaging=jar -Dfile=/Users/lkrubner/
 Downloads/guice-2.0/guice-2.0.jar
 
 and I get:
 
 [INFO] Scanning for projects...
 [INFO]
 [INFO]
 
 [INFO] Building Maven Stub Project (No POM) 1
 [INFO]
 
 [INFO]
 [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @
 standalone-pom ---
 [INFO] Installing /Users/lkrubner/Downloads/guice-2.0/guice-2.0.jar
 to /Users/lkrubner/.m2/repository/com/google/android/maps/maps/3_r3/
 maps-3_r3.jar
 [INFO]
 
 [INFO] BUILD SUCCESS
 [INFO]
 
 [INFO] Total time: 0.718s
 [INFO] Finished at: Mon Jan 14 10:18:44 EST 2013
 [INFO] Final Memory: 4M/92M
 [INFO]
 
 
 I then again run:
 
 lein uberjar
 
 and again I get:
 
 lein uberjar
 Could not find artifact com.google.code.guice:guice:pom:2.0 in central
 (http://repo1.maven.org/maven2)
 Could not find artifact com.google.code.guice:guice:pom:2.0 in clojars
 (https://clojars.org/repo/)
 Could not transfer artifact com.google.code.guice:guice:pom:2.0 from/
 to guice (http://guice-maven.googlecode.com/svn/trunk):Not
 authorized, ReasonPhrase:Authorization Required.
 Could not find artifact com.google.code.guice:guice:pom:2.0 in
 alchim.snapshots (http://alchim.sf.net/download/snapshots)
 Check :dependencies and :repositories for typos.
 It's possible the specified jar is not in any repository.
 If so, see Free-floating Jars underhttp://j.mp/repeatability
 Uberjar aborting because jar/compilation failed: Could not resolve
 dependencies
 
 What am I doing wrong?
 
 --
 You received this message

Friend 0.1.3 released

[Chas Emerick]

I released [com.cemerick/friend 0.1.3] to Clojars this afternoon.  Friend is 
an extensible authentication and authorization library for Clojure Ring web 
applications and services:

https://github.com/cemerick/friend

This release has a mix of fixes and minor enhancements; the changelog is here:

https://github.com/cemerick/friend/blob/master/CHANGES.md

Of immediate interest is a change in the transitive Guice dependency, required 
by the openid4java toolchain that inexplicably continues to refer to a build of 
Guice that was only available via a now-404 Maven repo hosted on Google Code.  
The disappearance of that repo means that projects using Friend  0.1.3 likely 
will not build at all, since `lein deps` will not succeed (unless you already 
have the affected dependencies in your local .m2 cache).

Friend 0.1.3 now only requires dependencies from Maven Central and Clojars; 
this will not change in the future, so this problem should never reoccur.  
Beyond that, the OpenID workflow will be split out of Friend proper into its 
own project circa Friend 0.2.0

I hope you find Friend useful for your sites and services.

Cheers,

- Chas

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

tools.nrepl 0.2.0 released

[Chas Emerick]

I released [org.clojure/tools.nrepl 0.2.0] this morning.

The plan (AFAIK) is for this to be transitively rolled into Leiningen 2.0.0 
final, which will thus flow through to a variety of toolchains.

Thank you to everyone that has helped get nREPL to this point.  I am 
particularly grateful to all the toolmakers and contributors that put their 
trust in nREPL as a common foundation for great tools like Reply, Leiningen, 
Counterclockwise, foreplay, ritz, nrepl.el, and all the rest.

Cheers,

- Chas

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

Re: tools.nrepl 0.2.0 released

[Chas Emerick]

Hah, I suppose a URL might help for those that aren't familiar with
nREPL:

http://github.com/clojure/tools.nrepl

- Chas

On Jan 12, 12:25 pm, Chas Emerick c...@cemerick.com wrote:
 I released [org.clojure/tools.nrepl 0.2.0] this morning.

 The plan (AFAIK) is for this to be transitively rolled into Leiningen 2.0.0 
 final, which will thus flow through to a variety of toolchains.

 Thank you to everyone that has helped get nREPL to this point.  I am 
 particularly grateful to all the toolmakers and contributors that put their 
 trust in nREPL as a common foundation for great tools like Reply, Leiningen, 
 Counterclockwise, foreplay, ritz, nrepl.el, and all the rest.

 Cheers,

 - Chas

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

nREPL 0.2.0-RC2

[Chas Emerick]

I released [org.clojure/tools.nrepl 0.2.0-RC2] last night.  Thanks to Tim 
Pope for raising a couple of issues he encountered through the course of his 
integrating nREPL into foreplay last month.

This will be 0.2.0 final later this week, barring any jarring new bug reports.

Also note that nREPL documentation has been significantly refreshed since RC1:

* More comprehensive, updated README detailing usage, architecture, etc: 
https://github.com/clojure/tools.nrepl/blob/master/README.md

* Central listing of known nREPL middleware and transports: 
https://github.com/clojure/tools.nrepl/wiki/Extensions

Cheers,

- Chas

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

core.match gotcha

[Chas Emerick]

I've recently started using core.match, which has been quite pleasant and 
successful; thank you to David Nolen, and all others that have contributed.

The only hiccup I've had has been around how core.match incorporates bindings 
from local scope into pattern rows.  A stupid example demonstrating the 
(potential) confusion:

= (match [[:k]]
 [[x]] x)
:k

vs.

= (let [x 12]
 (match [[:k]]
   [[x]] x))
nil

I was assuming that bindings established by the wildcards in pattern rows 
shadowed any other local bindings.  It took me a while to realize that, e.g. in 
the example above, `x` was being interpolated into `[[x]]` to yield a pattern 
row of `[[12]]`.  Now that I know that, all's well; but, it took me perhaps 
longer than it should have to figure it out.

All this is to say, perhaps a relevant note in the (really excellent) overview 
wiki page[1] might be helpful.

Thanks,

- Chas

[1] https://github.com/clojure/core.match/wiki/Overview

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

Re: core.match gotcha

[Chas Emerick]

On Jan 6, 2013, at 10:48 AM, Ambrose Bonnaire-Sergeant wrote:

 On a related note, combining a quoted symbol and a named wildcard pattern 
 seems to be buggy.
 
 clojure.core.match= (match 'my-sym a a)
 #CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
 ocr-3612 in this context, compiling:(REPL:79)
 clojure.core.match= (macroexpand-1 '(match 'my-sym a a))
 (clojure.core/let [a ocr-3620] a)

Yeah, I've hit that, but presumed I was just doing something wrong. :-)

 I included a section on how symbols work as patterns.

Perfect, reads very well.  I'm glad I didn't just add something, it would not 
have been as clear or succinct.

 Interestingly, the old design page still has some good stuff, including an 
 explanation of this particular issue.
 I'm not sure how much is still relevant.
 
 https://github.com/clojure/core.match/wiki/Design-Wiki

Ach, I hadn't thought to look at what else might be lurking in the wiki!  The 
'Local Bindings' section on the design page would have made it all obvious.

Thanks!

- Chas

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

Re: core.match gotcha

[Chas Emerick]

On Jan 6, 10:48 am, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
 On a related note, combining a quoted symbol and a named wildcard pattern
 seems to be buggy.

 clojure.core.match= (match 'my-sym a a)
 #CompilerException java.lang.RuntimeException: Unable to resolve symbol:
 ocr-3612 in this context, compiling:(REPL:79)
 clojure.core.match= (macroexpand-1 '(match 'my-sym a a))
 (clojure.core/let [a ocr-3620] a)

Ticket opened here FWIW:

   http://dev.clojure.org/jira/browse/MATCH-66

- Chas

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

Re: Writing a simple nrepl middleware and client

[Chas Emerick]

Tim,

Your middleware never sends a response.  Each request message can produce 
multiple response messages, sent at some later time (i.e. the request/response 
cycle is fundamentally asynchronous).  Handler return values are ignored.

So, assoc'ing the result into the request message as the return value of the 
handler function won't do anything.  You need to construct a response message 
and send it on the transport hanging off of the request message; here's a 
concise real-world example from ritz:


https://github.com/pallet/ritz/blob/develop/nrepl-middleware/src/ritz/nrepl/middleware/doc.clj

And, be a mensch, and send a done status in the response, too, so 
message-scoped response seqs terminate properly without waiting for the read 
timeout to expire. :-)

Cheers,

- Chas

On Dec 26, 2012, at 5:55 PM, Timothy Washington wrote:

 Hi all, 
 
 I'm trying to put together some nrepl middleware. To get a basic 
 understanding, I thought I would implement some simple nrepl middleware in a 
 test project as seen in A). I can execute `M-x nrepl-jack-in`. But executing 
 the client, gives me an empty result (`repl/response-values` pulls nil out of 
 ()). So I tried a bare bones communication example in the middleware page 
 (see B), but am still getting an error.  
 
 I like the example given in the leiningen sample project. But it seems I need 
 to get the basics working in A) and B), first. 
 
 Any insights here? Ultimately, I would like to create nrepl middleware for i) 
 Clojurescript compilation (cljsbuild auto (yes, I've already looked at 
 hiredman/nrepl-cljs-middleware)) and ii) a browser-connected repl (cljsbuild 
 repl-listen). I want to have these facilities in a `M-x nrepl-jack-in` 
 session. 
 
 
 A) basic nrepl middleware
 
 project.clj (https://www.refheap.com/paste/7875) 
 middleware.clj (https://www.refheap.com/paste/7874) 
 client.clj (https://www.refheap.com/paste/7876)
 
 B) lein repl
 
 $ lein new thing
 ...
 $ cd thing/
 $ lein repl
 
 nREPL server started on port 38789
 ...
 user= (require '[clojure.tools.nrepl :as repl])
 nil
 
 user= 
 user= (with-open [conn (repl/connect :port 38789)]
   #_=  (- (repl/client conn 1000)
   #_=(repl/message {:op eval :code (+ 2 3)})
   #_=repl/response-values))
 
 Exception in thread nREPL-worker-2 nil 
 user= java.net.SocketException: Broken pipe
   at java.net.SocketOutputStream.socketWrite0(Native Method)
   at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
   at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
   at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
   at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
   at clojure.tools.nrepl.transport$bencode$fn__214.invoke(transport.clj:81)
   at clojure.tools.nrepl.transport.FnTransport.send(transport.clj:27)
   at 
 clojure.tools.nrepl.middleware.pr_values$pr_values$fn$reify__479.send(pr_values.clj:23)
   at 
 clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__536$fn__538.invoke(interruptible_eval.clj:171)
   at clojure.core$comp$fn__4034.invoke(core.clj:2278)
   at 
 clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__529.invoke(interruptible_eval.clj:137)
   at clojure.lang.AFn.run(AFn.java:24)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)
 
 
 
 Thanks in advance 
 
 Tim Washington 
 Interruptsoftware.ca 
 
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: Need help in geeting cemerick/friend working with openid

[Chas Emerick]

Your Clojure code is correct.  However, whatever you're using to produce the 
POST to /openid (i.e. this 'ng-click=signin('google')' stuff) isn't behaving 
as you're expecting.  I didn't dig into what it's actually doing, but a simple 
form posting to /openid starts that workflow with Google without a problem:

diff --git a/public/landing.html b/public/landing.html
index 68c4618..88bfa59 100644
--- a/public/landing.html
+++ b/public/landing.html
@@ -94,7 +94,10 @@
 
 hr class=soften
 
-   
+form method=POST action=/openid
+  input type=hidden name=identifier 
value=https://www.google.com/accounts/o8/id/
+  input type=submit value=login with google/
+/form 
   /div

Note that the :realm you provide to OpenId needs to correspond to the domain 
that the site is running on; so, locally, you'll have to set that to e.g. 
http://localhost:8080, and then to http://mydomainname.com in production, etc.

- Chas

On Dec 19, 2012, at 9:56 PM, Murtaza Husain wrote:

 
 I have changed the parameter name to 'identifier', however I am still hitting 
 the NPE, any ideas? 
 
 I have placed the code on github - https://github.com/murtaza52/cfaiz.git, if 
 you would like to take a look. 
 
 Thanks,
 Murtaza
 
 On Thursday, December 20, 2012 12:12:27 AM UTC+5:30, Chas Emerick wrote:
 The parameter name is 'identifier' (not 'openid_identifier') by default 
 (which you can customize if you want by specifying a :user-identifier-param 
 option in openid/workflow).
 
 That said, the NPE you just hit has drawn my attention to an (unrelated) bug 
 in the openid workflow.  Thanks! :-)
 
 - Chas
 
 On Dec 19, 2012, at 1:20 PM, Murtaza Husain wrote:
 
 
 Thanks for catching that Aaron !
 
 The app currently redirects to the login page now. However I get an error 
 when I try to post to the /openid url with 
 {openid_identifier:https://www.google.com/accounts/o8/id} as post data.
 
 Here is the updated code - 
 
 (ns faiz.handler
   (:use compojure.core)
   (:require [compojure.handler :as handler]
 [compojure.route :as route]
 [ring.util.response :as resp]
 [me.shenfeng.mustache :as mustache]
 [cemerick.friend :as friend]
 (cemerick.friend [workflows :as workflows]
  [credentials :as creds]
  [openid :as openid])))
 
 (mustache/deftemplate index (slurp public/index-async.html))
 
 (def index-data {:title Invoize. :brand Faiz :links [{:url #/students 
 :text Students} {:url #/thaalis :text Thaalis}]})
 
 (defroutes app-routes
   (GET / [] (resp/redirect /login))
   (ANY /login [] (resp/file-response landing.html {:root public}))
   (GET /landing [] (resp/file-response landing.html {:root public}))
   (GET /index [] (friend/authenticated (index index-data)))
   (route/files / {:root public})
   (route/not-found Not Found))
 
 (def app-routes-with-auth
   (- app-routes
   (friend/authenticate
{:workflows [(openid/workflow :openid-uri /openid :realm 
 http://invoize.com; :credential-fn identity)]})))
 
 (def app
   (handler/site app-routes-with-auth))
 
 
 Below is the stacktrace -
 
 java.lang.NullPointerException
 
 openid.clj:124   cemerick.friend.openid/workflow[fn]
 friend.clj:174   cemerick.friend/authenticate*[fn]
 core.clj:2432clojure.core/map[fn]
 LazySeq.java:42  clojure.lang.LazySeq.sval
 
 
 Thanks,
 Murtaza
 
 
 
 
 On Wednesday, December 19, 2012 7:37:04 PM UTC+5:30, Aaron Cohen wrote:
 
 
 
 On Wed, Dec 19, 2012 at 8:40 AM, Murtaza Husain murtaza...@sevenolives.com 
 wrote:
 (defroutes app-routes
   (GET / [] (resp/redirect /landing))
   (GET /landing [] (resp/file-response landing.html {:root public}))
   (GET /index [] (index index-data))
   (route/files / {:root public})
   (route/not-found Not Found))
 
 (def mock-app
   (- app-routes
   (friend/authenticate
{:allow-anon? false
 :login-uri? /landing
 :workflows [(openid/workflow :openid-uri /openid :realm 
 http://invoize.com;)]})))
 
 
 
 I'm not fully conversant with all the libraries, but don't you actually need 
 to use mock-app somewhere?
  
 (def app
   (handler/site app-routes))
 
 
 -- 
 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 post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http

Re: Need help in geeting cemerick/friend working with openid

[Chas Emerick]

Yes; see the friend/identity and friend/current-authentication functions.

- Chas

On Dec 20, 2012, at 2:15 PM, Murtaza Husain wrote:

 
 I think this seems to be the one - Under :session and the following key 
 :cemerick.friend/identity there is - :identity 
 https://www.google.com/accounts/o8/id?id=AItOawlvddewdedwddrft56gt  
 
 Thanks,
 Murtaza
 
 On Thursday, December 20, 2012 11:56:53 PM UTC+5:30, Murtaza Husain wrote:
 Hi,
 
 Once the user is authenticated, how do I get hold of unique user identifier 
 that was returned by openid provider.  
 
 I would like persist this user identifier with the user's authorization 
 details into the DB.
 
 Murtaza  
 
 On Thursday, December 20, 2012 8:06:04 PM UTC+5:30, Murtaza Husain wrote:
 Chas,
 
 It was the header being sent. A form post sends data as url encoded, with 
 header as url encoded form data, while the javascript library was posting 
 data as application/json, that is the reason it was failing. Also thanks for 
 the pointer on realm.
 
 Thanks,
 Murtaza 
 
 
 On Thursday, December 20, 2012 4:03:19 PM UTC+5:30, Chas Emerick wrote:
 Your Clojure code is correct.  However, whatever you're using to produce the 
 POST to /openid (i.e. this 'ng-click=signin('google')' stuff) isn't 
 behaving as you're expecting.  I didn't dig into what it's actually doing, 
 but a simple form posting to /openid starts that workflow with Google without 
 a problem:
 
 diff --git a/public/landing.html b/public/landing.html
 index 68c4618..88bfa59 100644
 --- a/public/landing.html
 +++ b/public/landing.html
 @@ -94,7 +94,10 @@
  
  hr class=soften
  
 -   
 +form method=POST action=/openid
 +  input type=hidden name=identifier 
 value=https://www.google.com/accounts/o8/id/
 +  input type=submit value=login with google/
 +/form 
/div
 
 Note that the :realm you provide to OpenId needs to correspond to the domain 
 that the site is running on; so, locally, you'll have to set that to e.g. 
 http://localhost:8080, and then to http://mydomainname.com in production, etc.
 
 - Chas
 
 On Dec 19, 2012, at 9:56 PM, Murtaza Husain wrote:
 
 
 I have changed the parameter name to 'identifier', however I am still 
 hitting the NPE, any ideas? 
 
 I have placed the code on github - https://github.com/murtaza52/cfaiz.git, 
 if you would like to take a look. 
 
 Thanks,
 Murtaza
 
 On Thursday, December 20, 2012 12:12:27 AM UTC+5:30, Chas Emerick wrote:
 The parameter name is 'identifier' (not 'openid_identifier') by default 
 (which you can customize if you want by specifying a :user-identifier-param 
 option in openid/workflow).
 
 That said, the NPE you just hit has drawn my attention to an (unrelated) bug 
 in the openid workflow.  Thanks! :-)
 
 - Chas
 
 On Dec 19, 2012, at 1:20 PM, Murtaza Husain wrote:
 
 
 Thanks for catching that Aaron !
 
 The app currently redirects to the login page now. However I get an error 
 when I try to post to the /openid url with 
 {openid_identifier:https://www.google.com/accounts/o8/id} as post data.
 
 Here is the updated code - 
 
 (ns faiz.handler
   (:use compojure.core)
   (:require [compojure.handler :as handler]
 [compojure.route :as route]
 [ring.util.response :as resp]
 [me.shenfeng.mustache :as mustache]
 [cemerick.friend :as friend]
 (cemerick.friend [workflows :as workflows]
  [credentials :as creds]
  [openid :as openid])))
 
 (mustache/deftemplate index (slurp public/index-async.html))
 
 (def index-data {:title Invoize. :brand Faiz :links [{:url #/students 
 :text Students} {:url #/thaalis :text Thaalis}]})
 
 (defroutes app-routes
   (GET / [] (resp/redirect /login))
   (ANY /login [] (resp/file-response landing.html {:root public}))
   (GET /landing [] (resp/file-response landing.html {:root public}))
   (GET /index [] (friend/authenticated (index index-data)))
   (route/files / {:root public})
   (route/not-found Not Found))
 
 (def app-routes-with-auth
   (- app-routes
   (friend/authenticate
{:workflows [(openid/workflow :openid-uri /openid :realm 
 http://invoize.com; :credential-fn identity)]})))
 
 (def app
   (handler/site app-routes-with-auth))
 
 
 Below is the stacktrace -
 
 java.lang.NullPointerException
 
 openid.clj:124  cemerick.friend.openid/workflow[fn]
 friend.clj:174  cemerick.friend/authenticate*[fn]
 core.clj:2432   clojure.core/map[fn]
 LazySeq.java:42 clojure.lang.LazySeq.sval
 
 
 Thanks,
 Murtaza
 
 
 
 
 On Wednesday, December 19, 2012 7:37:04 PM UTC+5:30, Aaron Cohen wrote:
 
 
 
 On Wed, Dec 19, 2012 at 8:40 AM, Murtaza Husain 
 murtaza...@sevenolives.com wrote:
 (defroutes app-routes
   (GET / [] (resp/redirect /landing))
   (GET /landing [] (resp/file-response landing.html {:root public}))
   (GET /index [] (index index-data))
   (route/files / {:root public})
   (route/not-found Not Found))
 
 (def mock-app
   (- app-routes
   (friend

Re: Need help in geeting cemerick/friend working with openid

[Chas Emerick]

Murtaza,

First, you need to either

(a) :allow-anon? false in the configuration map you provide to 
friend/authenticate — it is true by default, or
(b) Use an authorization guard (which can include friend/authenticated, which 
reuses the authorization mechanism to ensure that only authenticated users' 
requests can cause the enclosed code to be evaluated)

Either option will redirect to whatever you have configured as :login-uri 
(default /login).

Also, openid-uri is not where the provider's URI goes; that's what configures 
the URI that the OpenId workflow is bound to e.g. for receiving the redirect 
from the provider after the user has authenticated with them.  So, you'd want 
:openid-uri to be something like /openid.

It is generally the case that the OpenId workflow is initiated by the user by 
clicking on one of a couple of different buttons, or specifying their OpenId 
URL manually.  This is what you would put on the /login page.  You can see 
different takes on this this at http://www.clojureatlas.com/login and 
http://stackoverflow.com/users/login.

I suppose you *could* start the OpenId workflow automatically, but that might 
be a jarring experience for your users: because you can't control the 
presentation / branding of the OpenId provider's authentication flow, 
unauthenticated users may get confused, or think they've wandered into an 
attempt to obtain their e.g. Google credentials.  However, I can see use cases 
for this — maybe when the users know a particular site always uses credentials 
from a particular site, or for internal apps where an OpenId SSO is ubiquitous 
and expected.

FWIW, I'll add an example for that option (as well as the more common 
form-initiated style) to the set of example applications I'm slowly building 
for Friend:

https://friend-demo.herokuapp.com/

I haven't publicly announced that app/effort yet — mostly because I want to get 
a certain minimum number of example apps spiked out with non-hideous 
presentation before blowing the trumpets.

Anyway, I hope the content above is helpful.  Let me know if you have any other 
questions...

Cheers,

- Chas

On Dec 19, 2012, at 2:59 AM, Murtaza Husain wrote:

 Hi,
 
 I am trying to setup my authentication using cemerick/friend. I would like to 
 authenticate using openid with gmail. 
 
 Below is the code that I have - 
 
 (ns faiz.handler
   (:use compojure.core)
   (:require [compojure.handler :as handler]
 [compojure.route :as route]
 [ring.util.response :as resp]
 [me.shenfeng.mustache :as mustache]
 [cemerick.friend :as friend]
 (cemerick.friend [workflows :as workflows]
  [credentials :as creds]
  [openid :as openid])))
 
 (mustache/deftemplate index (slurp public/index-async.html))
 
 (def index-data {:title Invoize. :brand Faiz :links [{:url #/students 
 :text Students} {:url #/thaalis :text Thaalis}]})
 
 
 
 
 (defroutes app-routes
   (GET / [] (resp/redirect /landing))
   (GET /landing [] (resp/file-response landing.html {:root public}))
   (GET /index [] (index index-data))
   (route/files / {:root public})
   (route/not-found Not Found))
 
 (def mock-app
   (- app-routes
   (friend/authenticate
{:workflows [(openid/workflow :openid-uri 
 https://www.google.com/accounts/o8/id; :realm http://invoize.com;)]})))
 
 (def app
   (handler/site app-routes))
 
 My expectation is that when I try to access the /index or /landing url, 
 it should not allow me as I am not authenticated and redirect to the 
 openid-url,however this does not happen. How do I achieve it ?
 
 Thanks,
 Murtaza
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: Need help in geeting cemerick/friend working with openid

[Chas Emerick]

The parameter name is 'identifier' (not 'openid_identifier') by default (which 
you can customize if you want by specifying a :user-identifier-param option in 
openid/workflow).

That said, the NPE you just hit has drawn my attention to an (unrelated) bug in 
the openid workflow.  Thanks! :-)

- Chas

On Dec 19, 2012, at 1:20 PM, Murtaza Husain wrote:

 
 Thanks for catching that Aaron !
 
 The app currently redirects to the login page now. However I get an error 
 when I try to post to the /openid url with 
 {openid_identifier:https://www.google.com/accounts/o8/id} as post data.
 
 Here is the updated code - 
 
 (ns faiz.handler
   (:use compojure.core)
   (:require [compojure.handler :as handler]
 [compojure.route :as route]
 [ring.util.response :as resp]
 [me.shenfeng.mustache :as mustache]
 [cemerick.friend :as friend]
 (cemerick.friend [workflows :as workflows]
  [credentials :as creds]
  [openid :as openid])))
 
 (mustache/deftemplate index (slurp public/index-async.html))
 
 (def index-data {:title Invoize. :brand Faiz :links [{:url #/students 
 :text Students} {:url #/thaalis :text Thaalis}]})
 
 (defroutes app-routes
   (GET / [] (resp/redirect /login))
   (ANY /login [] (resp/file-response landing.html {:root public}))
   (GET /landing [] (resp/file-response landing.html {:root public}))
   (GET /index [] (friend/authenticated (index index-data)))
   (route/files / {:root public})
   (route/not-found Not Found))
 
 (def app-routes-with-auth
   (- app-routes
   (friend/authenticate
{:workflows [(openid/workflow :openid-uri /openid :realm 
 http://invoize.com; :credential-fn identity)]})))
 
 (def app
   (handler/site app-routes-with-auth))
 
 
 Below is the stacktrace -
 
 java.lang.NullPointerException
 
 openid.clj:124cemerick.friend.openid/workflow[fn]
 friend.clj:174cemerick.friend/authenticate*[fn]
 core.clj:2432 clojure.core/map[fn]
 LazySeq.java:42   clojure.lang.LazySeq.sval
 
 
 Thanks,
 Murtaza
 
 
 
 
 On Wednesday, December 19, 2012 7:37:04 PM UTC+5:30, Aaron Cohen wrote:
 
 
 
 On Wed, Dec 19, 2012 at 8:40 AM, Murtaza Husain murtaza...@sevenolives.com 
 wrote:
 (defroutes app-routes
   (GET / [] (resp/redirect /landing))
   (GET /landing [] (resp/file-response landing.html {:root public}))
   (GET /index [] (index index-data))
   (route/files / {:root public})
   (route/not-found Not Found))
 
 (def mock-app
   (- app-routes
   (friend/authenticate
{:allow-anon? false
 :login-uri? /landing
 :workflows [(openid/workflow :openid-uri /openid :realm 
 http://invoize.com;)]})))
 
 
 
 I'm not fully conversant with all the libraries, but don't you actually need 
 to use mock-app somewhere?
  
 (def app
   (handler/site app-routes))
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: Tail call in multi method?

[Chas Emerick]

`recur` throws control flow to the nearest `loop` head or fn body, and each 
method is itself a function, so `recur` within a method body will simply jump 
to the start of the method, _not_ tail-call the multimethod.  e.g.:

= (defmulti foo type)
#'user/foo
= (defmethod foo Long
 [x]
 (assert (integer? x) (str x isn't an integer!  (pr-str x)))
 (recur (str x)))
#MultiFn clojure.lang.MultiFn@4f0ab3f2
= (foo 5)
AssertionError Assert failed: x isn't an integer! 4
(integer? x)  user/eval1831/fn--1832 (NO_SOURCE_FILE:3)

What you're trying to do is really a special case of mutual recursion: because 
Clojure's methods are separate functions, calling back through the multimethod 
(and its dispatch fn) will always consume stack space.  The general solution 
for this is to use `trampoline`, which will continuously call through functions 
returned from calling a function until a non-function value is returned.  This 
would allow you to make your multimethod mutually-recursive, as long as those 
recursive calls are made by returning a function (that the user of the 
multimethod would `trampoline` through):

= (defmethod foo String
 [x]
 (str got  x !))
#MultiFn clojure.lang.MultiFn@4f0ab3f2
= (defmethod foo Long
 [x]
 #(foo (str x)))
#MultiFn clojure.lang.MultiFn@4f0ab3f2
= (foo 5)
#user$eval1888$fn__1889$fn__1890 user$eval1888$fn__1889$fn__1890@3852fdeb
= (trampoline foo 5)
got 5!

From an API standpoint, you would presumably name the multimethod itself 
something like `trans*`, and expose only a helper function `trans` that would 
implicitly trampoline through any functions returned by `trans*`.  There is a 
cost associated with trampolining isn't zero, but won't swamp actual work as 
long as the methods are doing something nontrivial anyway.

Another option you might consider is using agents.  I see your methods already 
take a single state argument; this would then make it really easy to lift the 
automata onto an agent (or set of agents).  That state would become the agents' 
state, and recursive calls would become a `send` (or `send-off` if you're 
doing IO or other blocking things) to the same agent (e.g. `(send *agent* 
trans)`).  

Cheers,

- Chas

--
http://cemerick.com
[Clojure Programming from O'Reilly](http://www.clojurebook.com)

On Dec 17, 2012, at 11:56 AM, juan.facorro wrote:

 What about recur? 
 
 It's a special form used for tail call optimizations.
 
 Juan
 
 On Monday, December 17, 2012 1:32:31 PM UTC-3, bruce li wrote:
 Hello, everyone.
 
 I'm currently trying to model an automata using multi-method. So in my code, 
 I have something like:
 
 (defmethod trans :state
  [state]
  ; ...
  (trans ..
 
 In the last line, the trans will be called with some different state.
 
 However, it seems that such call still consumes stack and I quickly come to a 
 stack overflow error when the states are reached multiple times.
 
 I'm wondering if there is some ways to optimize the code.
 
 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Tail call in multi method?

[Chas Emerick]

On Dec 17, 2012, at 12:39 PM, Ben Wolfson wrote:

 On Mon, Dec 17, 2012 at 9:32 AM, Chas Emerick c...@cemerick.com wrote:
 
 What you're trying to do is really a special case of mutual recursion:
 because Clojure's methods are separate functions, calling back through the
 multimethod (and its dispatch fn) will always consume stack space.  The
 general solution for this is to use `trampoline`, which will continuously
 call through functions returned from calling a function until a non-function
 value is returned.  This would allow you to make your multimethod
 mutually-recursive, as long as those recursive calls are made by returning a
 function (that the user of the multimethod would `trampoline` through):
 
 Also as long as you don't want to return a function from the multimethod, no?

Correct.  As noted in the docs for `trampoline`:

...if you want to return a fn as a final value, you must wrap it in 
some data structure and unpack it after trampoline returns.

I can't say I've ever needed to write mutually-recursive higher-order 
functions.  I can only presume that doing so while needing to meet trampoline's 
contract for that corner case would be fairly cumbersome.

IIRC, `trampoline` predated functions supporting metadata by some time.  If it 
were written again now, it might specify that metadata should be used to 
indicate that a function should be called-through, rather than returned as a 
non-intermediate value.  e.g.:

(defn meta-trampoline
  ([f]
 (let [ret (f)]
   (if (and (fn? ret) (- ret meta :trampoline))
 (recur ret)
 ret)))
  ([f  args]
 (meta-trampoline #(apply f args

With this, you can return whatever you want/need to, as long as you mark the 
self- or mutually-recursive calls with {:trampoline true} metadata:

= (defmethod foo String
 [x]
 #(str I got  x , you gave me  %))
#MultiFn clojure.lang.MultiFn@4f0ab3f2
= (defmethod foo Long
 [x]
 ^:trampoline #(foo (str x)))
#MultiFn clojure.lang.MultiFn@4f0ab3f2
= (meta-trampoline foo 5)
#user$eval1992$fn__1993$fn__1994 user$eval1992$fn__1993$fn__1994@7466a008
= (*1 6)
I got 5, you gave me 6

Cheers,

- Chas

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

[ANN] clojure-sec

[Chas Emerick]

Some recent discussions related to my development of Friend have prompted me to 
create a new group:

https://groups.google.com/group/clojure-sec
Dedicated to discussing security issues affecting those building applications 
with Clojure and its variants.

I'm sure many of us are building applications that have security 
considerations.  I think it would be helpful at this point if there were a 
dedicated place for discussions around addressing those considerations; thus, 
clojure-sec.

We'll see what people actually want to talk about, but I'd be happy if any of 
these classes of topics become common:

* usage and design of particular security-related libraries and tools
* security-related tech available in the various host environments that we can 
leverage from Clojure(Script/.CLR/-py/c/etc)
* Clojure-specific concerns (e.g. untrusted code evaluation / jailing)
* issues or weaknesses in particular Clojure implementations, libraries, etc.
* discussion of more general-interest security topics that nevertheless impinge 
upon our work in Clojure
* more, more, more

I'm looking forward to learning.

Cheers,

- Chas

--
http://cemerick.com
[Clojure Programming from O'Reilly](http://www.clojurebook.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

Re: A Working nrepl-ritz Setup?

[Chas Emerick]

On Dec 8, 2012, at 6:37 PM, Charles Comstock wrote:

 I still encounter some sort of issue where it appears that the documentation 
 querying functions, find-doc, and doc and the like are not being properly 
 brought into the repl namespace, which breaks ctrl-d d until I manually bring 
 that into the namespace. I'm not quite certain what was causing that problem 
 and have yet to find a permanent fix.

Are you using a recent Clojure 1.5.0 beta build?  A change went in recently to 
fix some behaviour where nREPL would inadvertently refer all of the REPL 
utilities (doc, find-doc, pp, etc.) into *every* namespace.  When used with 
Clojure 1.5.0, nREPL now only refers those vars into the user ns, matching the 
default Clojure REPL defaults.

(I actually got used to the old behaviour myself, but it can cause serious 
problems, e.g.: http://code.google.com/p/counterclockwise/issues/detail?id=443)

This all said, it's definitely the case that some piece of the toolchain 
(probably clients like reply and nrepl.el, based on project.clj / profile 
config) should instigate global namespace refers so that these vars, or some 
subset, in addition to whatever vars you use most often in your 
workflow/project/application are always available.  Meditation on this topic 
continues. :-)

Cheers,

- Chas

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

Re: STM - a request for war stories

[Chas Emerick]

On Dec 10, 2012, at 5:39 AM, Marko Topolnik wrote:

 The very fact that there has been no reply to this for five days may mean 
 something. I can personally attest to STM being very difficult to put to 
 real-life use because there is always that one thing you absolutely need for 
 your problem, that is mutable and not transactional. Most of the time it will 
 have to do with an existing Java library, JDK not excluded. The property of 
 STM that it is an all-or-nothing commitment has been a show-stopper for me 
 every time I tried to use it.

I'd be surprised if Paul doesn't hear from people directly; people aren't 
always keen to talk about their work publicly (and in many cases, they are 
simply barred from doing so), so one shouldn't presume that on-list responses 
(or not) are representative.

I personally have never used STM in nontrivial ways (AFAIC), but that's due 
more to the demands of the problems I run into more than anything else.  On the 
other hand, I have used, abused, and benefitted from agents in umpteen ways.  
Actually, I have often done things using agents that might otherwise been done 
using STM or other similar approaches, simply to ensure that:

(a) the processing involved can be readily parallelized, and
(b) if necessary, the system can be partitioned/distributed with minimal impact 
to the architecture, since — if you're careful about things — it doesn't matter 
whether a send is evaluated in an in-process agent or one housed in a different 
server/VM/whatever

Yes, only a subset of the things you can do with STM can be done safely with 
agents, etc.  (See: monotonic logic, and the increasingly-popular concepts of 
lattices, semilattices, and CRDTs.)  But, I've been lucky to be able to 
characterize many problems within that subset.

It's true that STM is all or nothing, but it is so over the scope of refs you 
choose.  If there's some side-effecting bit you need to do somewhere, then 
clearly that's not going to fit within a transaction…but that bit will often 
fit just fine in a send-off to an agent provoked _by_ a transaction.  And, if 
you can implement e.g. 2 of the 5 parts of your system using refs and STM, you 
just cut your thread-and-locking problems by 40%. :-P

 My guess is, if your task is something purely computational and amenable to 
 massive parallelization, you may have a go with STM; if it's just about 
 business logic accessible concurrently by many clients, you won't find it 
 workable.

If your task is purely computational and amenable to massive parallelization, 
you _should_ use agents whenever possible.  STM provides for coordination in 
order to enforce consistency; unless all of your operations are commutative (in 
which case, you should probably be using agents anyway), a program using STM 
_will_ provoke retries and other means to route around ref contention.  This is 
acceptable because STM is all about maintaining correctness in the face of 
concurrent mutation, and not necessarily about performance, aggregate 
throughput, and so on.  On the other hand, ref readers are _never_ blocked 
(regardless of what's going on on the write side), so the data in such refs is 
always accessible.  This sounds like an ideal combination for business logic 
(as nebulous a term as that is) to me.

Cheers,

- Chas

--
http://cemerick.com
[Clojure Programming from O'Reilly](http://www.clojurebook.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

Re: STM - a request for war stories

[Chas Emerick]

On Dec 10, 2012, at 8:37 AM, Marko Topolnik wrote:

 It's true that STM is all or nothing, but it is so over the scope of refs 
 you choose.  If there's some side-effecting bit you need to do somewhere, 
 then clearly that's not going to fit within a transaction…but that bit will 
 often fit just fine in a send-off to an agent provoked _by_ a transaction.
 
 send-off fails to be useful whenever you need the results within the 
 transaction (quite often, that is).

I'm not aware of any system that provides transactional semantics in the face 
of in-transaction side-effecting actions.  If you can refer me to any, that'd 
be great.

  My guess is, if your task is something purely computational and amenable to 
  massive parallelization, you may have a go with STM; if it's just about 
  business logic accessible concurrently by many clients, you won't find it 
  workable. 
 
 If your task is purely computational and amenable to massive parallelization, 
 you _should_ use agents whenever possible.  STM provides for coordination in 
 order to enforce consistency; unless all of your operations are commutative 
 (in which case, you should probably be using agents anyway), a program using 
 STM _will_ provoke retries and other means to route around ref contention.  
 This is acceptable because STM is all about maintaining correctness in the 
 face of concurrent mutation, and not necessarily about performance, aggregate 
 throughput, and so on.  
 
 But concurrency is all about performance and throughput. So where is the 
 benefit of using correct, slow concurrent mutation? I guess in a 
 write-seldom, read-often scenario.

Fundamentally, concurrency is about simultaneous independent computation.  
Depending on the domain and computations involved, single-thread performance 
and aggregate throughput can vary significantly.

Anyway, read-heavy applications are still the norm in most industrial settings, 
despite the rise in popularity of write-scalable architectures.

 On the other hand, ref readers are _never_ blocked (regardless of what's 
 going on on the write side), so the data in such refs is always accessible.  
 This sounds like an ideal combination for business logic (as nebulous a 
 term as that is) to me. 
  
 Business logic almost always involves communication with outside systems 
 (since it's usually about integration of many existing systems). Even if not, 
 a scalable solution must be stateless (a prerequisite for cluster deployment) 
 and any durable state must go into a single datasource common to all cluster 
 nodes. Again, these datasources don't participate in an STM transaction. 
 Maybe this would be a major route of improvement: integrate the STM with 
 external datasource transactions. But this is still quite removed from the 
 present.

I'm certain that particular set of requirements holds in certain settings, but 
they are hardly universal.

If I may make a tenuous inference, it sounds like you're trying to fit every 
state transition within an application into a transaction.  If so, I'd 
recommend the opposite: decomposing applications and their processes into 
modular bags of state and treating them separately will lead to big wins — 
including potentially being able to use e.g. STM in one place, and agents in 
another, each interacting with the other as necessary.

Re: getting disparate datasources to participate in transactions, you might 
want to take a look at Avout:

http://avout.io  

I can't say I've used it, but it is at least an existence proof of the ability 
of the Clojure STM model to be distributable.

Cheers,

- Chas

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

Re: class loaders stack constant grow in REPL

[Chas Emerick]

Good catch, guys.

Interesting that I never noticed this; likely because Pomegranate's 
`classloader-hierarchy` function ends up starting its walk from (RT/baseLoader) 
(which will be changing to the context classloader shortly):


https://github.com/cemerick/pomegranate/blob/master/src/main/clojure/cemerick/pomegranate.clj#L54

I'm open to suggestions.  I'm not keen on having yet another divergence in 
nREPL behaviour between 1.5.0 and all prior revs of Clojure, so an nREPL-local 
fix would be great.

My first impulse right now is to boot clojure.main/repl entirely and groom a 
replacement in-house, as it were (which I probably should have done from day 
1).

- Chas

On Dec 10, 2012, at 11:32 AM, Colin Jones wrote:

 Right, this is because nREPL uses clojure.main/repl each time it does an 
 evaluation. See http://dev.clojure.org/jira/browse/NREPL-31 for a related 
 issue that was addressed by modifying clojure.main/repl.
 
 I'm not sure where a fix for this would belong (nREPL or clojure.main), but I 
 went ahead and opened an nREPL JIRA issue to track it: 
 http://dev.clojure.org/jira/browse/NREPL-36
 
 - Colin
 
 
 
 
 On Monday, December 10, 2012 2:46:10 AM UTC-6, Vladimir Tsichevski wrote:
 Hi,
 
 just found that every interaction with Clojure REPL causes one more 
 DynamicClassLoader put on the Thread context class loader chain.
 
 Here is how clojure.main/repl beginning looks like:
 
   (let [cl (.getContextClassLoader (Thread/currentThread))]
 (.setContextClassLoader (Thread/currentThread) 
 (clojure.lang.DynamicClassLoader. cl)))
 
 And this is how to observe it:
 
 nREPL server started on port 19987
 REPL-y 0.1.0-beta10
 Clojure 1.4.0
 Exit: Control+D or (exit) or (quit)
 Commands: (user/help)
 Docs: (doc function-name-here)
   (find-doc part-of-name-here)
   Source: (source function-name-here)
   (user/sourcery function-name-here)
  Javadoc: (javadoc java-object-or-class-here)
 Examples from clojuredocs.org: [clojuredocs or cdoc]
   (user/clojuredocs name-here)
   (user/clojuredocs ns-here name-here)
 user= (defn print-class-loader-stack
   ([]
  (print-class-loader-stack (.getContextClassLoader 
 (Thread/currentThread
   ([cl]
  (if cl
(do
  (pprint cl)
  (print-class-loader-stack (.getParent cl)))
(println *Top*
   #_=   #_=   #_=   #_=   #_=   #_=   #_=   #_= 
 #'user/print-class-loader-stack
 user= (print-class-loader-stack)
 #DynamicClassLoader clojure.lang.DynamicClassLoader@26a0c73f
 #DynamicClassLoader clojure.lang.DynamicClassLoader@6f603bdc
 #DynamicClassLoader clojure.lang.DynamicClassLoader@2f368c5d
 #DynamicClassLoader clojure.lang.DynamicClassLoader@5b31fd9
 #AppClassLoader sun.misc.Launcher$AppClassLoader@4aad3ba4
 #ExtClassLoader sun.misc.Launcher$ExtClassLoader@3326b249
 *Top*
 nil
 user= 1
 1
 user= 1
 1
 user= 1
 1
 user= 1
 1
 user= (print-class-loader-stack)
 #DynamicClassLoader clojure.lang.DynamicClassLoader@5be04861
 #DynamicClassLoader clojure.lang.DynamicClassLoader@7481933a
 #DynamicClassLoader clojure.lang.DynamicClassLoader@273f212a
 #DynamicClassLoader clojure.lang.DynamicClassLoader@4178feba
 #DynamicClassLoader clojure.lang.DynamicClassLoader@5323961b
 #DynamicClassLoader clojure.lang.DynamicClassLoader@26a0c73f
 #DynamicClassLoader clojure.lang.DynamicClassLoader@6f603bdc
 #DynamicClassLoader clojure.lang.DynamicClassLoader@2f368c5d
 #DynamicClassLoader clojure.lang.DynamicClassLoader@5b31fd9
 #AppClassLoader sun.misc.Launcher$AppClassLoader@4aad3ba4
 #ExtClassLoader sun.misc.Launcher$ExtClassLoader@3326b249
 *Top*
 nil
 user= 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

[ANN] New functional programming group (Western Massachusetts)

[Chas Emerick]

With help from some friends, I am starting a new FP group here in Western 
Massachusetts:

  http://www.meetup.com/Functional-Programming-Connoisseurs/

From the meetup.com description:

  Open to any and all that have functional and logical tastes in programming
  languages and data models. Clojure, Scala, Erlang, Schemes, Prologs, F#, MLs,
  concatenative (e.g. Factor), and so on. Many of us have experience and 
interest
  in building distributed, large-scale systems. Many of us also happen to be
  independent contractors, solo/entrepreneurs, business owners, and otherwise
  interested in building killer businesses as well as awesome software. 
Depending
  on the week/month, expect a mix of free-for-all conversation and hacking,
  lightning talks, and the occasional prepared presentation.

Our first meeting will be in January (date and location TBD).  If you're in the 
area and on this list, stop by and say 'hi'!  Of course, if you would like to 
give a relevant talk, presentation, or demonstration, by all means shoot me an 
email.

Cheers,

- Chas

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

Re: ANN: contrib-repl

[Chas Emerick]

On Dec 4, 2012, at 2:52 AM, Laurent PETIT wrote:

 2012/12/4 rob r.p.l...@gmail.com:
 That was my first thought, and considered also generating a project.clj, but
 after thinking about it I decided I didn't want to encourage this type of
 behavior beyond REPL experimentation, so I preferred to do it in a way that
 focuses on the REPL.

Good instincts.

This is all vaguely insane, but I suppose I am to blame... ;-)

If you like, you can add contrib-repl to the list of community-authored nREPL 
extensions here:

https://github.com/clojure/tools.nrepl/wiki/Community-managed-extensions

One thing: make sure tools.nrepl is never loaded dynamically (see below for 
why).

 - if some of the contrib dependencies are already marked as deps in
 the project, how does that work ? What about version conflicts ?

If a version of some dependency is already on the classpath (either has been 
there from the start, or was previously added via pomegranate), results are 
undefined if a different version of the same dependency is later added via 
pomegranate.  Sometimes you get lucky and nothing bad happens; other times, you 
can really hork the entire process.  It all depends on the specific differences 
between the versions in question, and how the code in question is being used.

(Thus my suggestion to Robert above to not add tools.nrepl in contrib-repl.)

At some point, I'd like to:

1. Make it possible for processes that start Clojure runtimes (i.e. Leiningen) 
to make Pomegranate aware of the dependencies that have been put on the initial 
classpath.
2. Make Pomegranate track which versions of which dependencies are available.
3. Make Pomegranate throw an exception if a dependency conflict will be created 
by an add-dependencies call.

#2 is particularly difficult for a variety of reasons.

Cheers,

- Chas

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

Re: Docs on standard protocols

[Chas Emerick]

Having a good Java IDE around (e.g. Eclipse or IntelliJ) certainly
helps, though not so much in developing a comprehensive mental model
of how everything fits together.

Some years ago, Chris Houser worked at building static visualizations
of the core Clojure interfaces and abstract implementations, and how
those fed into the concrete implementations of maps, seqs, etc. that
we use daily:

https://github.com/Chouser/clojure-classes/blob/master/graph-w-legend.png

I had similar objectives, but wanted to tie implementation details
(e.g. the Java interfaces that Clojure defined) together with related
functions, and the higher-level concepts that further related those
functions to others, etc.  Add in a dynamic visualization, and you get
Clojure Atlas:

http://www.clojureatlas.com

For example, here's the atlas focused on graph around
PersistentHashMap, the concrete implementation behind e.g. `{:a 1 :b 2}
`:


http://www.clojureatlas.com/org.clojure:clojure:1.4.0?guest=t#clojure.lang.PersistentHashMap

Cheers,

- Chas

On Nov 26, 5:53 pm, Dmitry Groshev lambdadmi...@gmail.com wrote:
 Is there any reference of standard protocols in which one can participate?
 When working with Java code and building bindings to complex Java classes,
 it's sometimes handy to define instances of Seq (for example) for them. But
 it's horribly troublesome to look up protocols in source code every time.
 Can you please point me to appropriate documentation, if such exists?

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

Re: refer-clojure seems to have no effect.

[Chas Emerick]

The user namespace is implicitly created with a blanket refer for clojure.core; 
removing the mapping for e.g. '== in user would require using ns-unmap.

Just use a different namespace.

- Chas

On Nov 22, 2012, at 8:40 AM, Frederik De Bleser wrote:

 Hi,
 
 I'm trying to use core.logic using the following namespace expression 
 (modelled on core.logic's own test file):
 
 (ns user
   (:refer-clojure :exclude [==])
   (:use clojure.core.logic))
 
 However, this gives the following warning:
 
 WARNING: == already refers to: #'clojure.core/== in namespace: user, 
 being replaced by: #'clojure.core.logic/==
 
 It seems that the refer-clojure line has no effect. What am I doing wrong?
 
 Kind regards,
 
 Frederik
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Removing URLClasspath from Pomegranate

[Chas Emerick]

Tobias Crawley rightly suggested that Pomegranate's URLClasspath protocol 
should be factored out into a separate project, so as to provide a common 
abstraction for interacting with dynamic classloaders.  The new project 
(dynapath @ https://github.com/tobias/dynapath) is already being used by other 
Clojure projects, and he has a pull request into Pomegranate now that would 
make the necessary changes there:

https://github.com/cemerick/pomegranate/pull/43

Using dynapath should be a total win; aside from participating in what looks to 
be the emerging standard for the protocol for this purpose, dynapath's protocol 
supersets Pomegranate's and dynapath includes a couple of handy utilities that 
pomegranate does not.

I'm sending this message now as an early heads-up to anyone who is using 
Pomegranate and has already extended its URLClasspath protocol.  The change to 
Pomegranate will be a breaking one, and I'd like to make sure people have 
sufficient time to look at the proposed changes, potentially suggest 
alternatives, and otherwise make appropriate plans.

FWIW, I plan on merging the pull request soon, whatever that means.  Pipe up 
if you'll be negatively affected, etc.

Cheers,

- Chas

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

nREPL status

[Chas Emerick]

FYI, an updated cut of high-level nREPL documentation is now available:

https://github.com/clojure/tools.nrepl

There's a fair bit more I plan on adding, but I think some reorganization into 
different pages for different topics is warranted at this point before the 
README gets any more unwieldy.

Of particular interest to some on this list would be this:

https://github.com/clojure/tools.nrepl/blob/master/doc/ops.md

...a generated page collecting all documentation included in nREPL's default 
middlewares' descriptors.  You can see how this page is generated by starting 
here:


https://github.com/clojure/tools.nrepl/blob/master/src/test/clojure/clojure/tools/nrepl/describe_test.clj#L34

If you have implemented your own nREPL middleware, you may want to document the 
operations it supports/implements in a similar way, and the above might be a 
reasonable starting point (though hardly a polished one, yet) for generating 
those docs.

This closes the last open issue associated with the 0.2.0 milestone.  That 
release will be hitting the wires at some point in between Thanksgiving 
festivities.

Cheers,

- Chas

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

Re: Run Counterclockwise nREPL on specific port

[Chas Emerick]

On Nov 20, 2012, at 3:22 PM, Vladimir Tsichevski wrote:

 CCW has a 'connect to repl' option under  'Window'. It asks doe an IP 
 and a port number...is this what you're looking for? 
 Exactly! The menu location is quite unusual for Eclipse :-(

Heh, this one's on me; I put it in the Window menu.  I honestly couldn't find a 
good place for it.  Eclipse is deeply wedded to operations being related to a 
project, so this project-insensitive operation didn't naturally slot in 
anywhere.  Suggestions welcome, of course.

- Chas

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

Re: ANN concerto 0.1.0-SNAPSHOT

[Chas Emerick]

Bravo.  I suspect there's lots of fertile ground for supporting alternative 
topologies using custom middlewares and transports.  Carry on. :-)

- Chas

On Nov 13, 2012, at 2:24 PM, Jamie Brandon wrote:

 Concerto extends nrepl (and nrepl.el) with a broadcast mechanism so
 that multiple users can colloborate within a single repl.
 
 Just an experiment, I'm curious to see whether anyone has a use for
 this. My eventual goal is to use it for collaborative ovetone sessions
 but for now I have to get back to other work.
 
 https://github.com/jamii/concerto/
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: Interactive form workflow with Friend, can't log in

[Chas Emerick]

Looks like you're not using the keyword-params middleware, which Friend 
requires (among others).  Please check the last paragraph in the 
'Authentication' section here:

https://github.com/cemerick/friend/#authentication

Once you add that, then the interactive-form middleware will pick up the form 
data you're submitting.

Cheers,

- Chas

--
http://cemerick.com
[Clojure Programming from O'Reilly](http://www.clojurebook.com)

On Nov 12, 2012, at 7:59 AM, Thorsten Wilms wrote:

 Hi!
 
 I'm trying to use Friend with the interactive form workflow. Whenever I try 
 to login, I get a redirect to
 http://localhost:8080/login?login_failed=Yusername=
 
 The body of the POST my form generates does include username and password.
 
 My code:
 https://www.refheap.com/paste/6569
 
 This version does not specify encoding and thus falls back to some windows 
 encoding, but a later version with a full html5 body with utf-8 shows the 
 same result.
 
 Where's my mistake, or what can I do to further diagnose the problem?
 
 
 -- 
 Thorsten Wilms
 
 thorwil's design for free software:
 http://thorwil.wordpress.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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Some Friend documentation and regarding documentation in general

[Chas Emerick]

On Oct 28, 2012, at 2:57 PM, Patrik Sundberg wrote:

 I've looked at this for a bit now. It seems there are some slight 
 inconsistencies in how the redirect info is used:
 
 Where the redirect-on-autth? is being set up for the interactive-form 
 workflow it looks to me to be assumed to be a boolean flag.
 https://github.com/sundbp/friend/blob/master/src/cemerick/friend/workflows.clj#L79
 
 At that point it's given as an argument when setting up the workflow 
 (defaulting to true). 
 
 Then when it's being used in the generic code it's first picked out - looking 
 like boolean flag still:
 https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L145
 
 but then all of a sudden assumed to be a string containing the url to 
 redirect to:
 https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L149
 
 Given that, for the interactive-form workflow, it can only be set at the time 
 of creating the workflow, it seems impossible to actually achieve the flow 
 where friend remembers which page under authentication that user tried to 
 access, then do auth, and finally return user to the originally requested 
 page in a dynamic fashion. Since given at workflow creation time it can't 
 dynamically reflect things properly I'd have assumed. I'd have expected it to 
 not be an argument at workflow creation time, but the originally requested 
 url being dynamically kept track of at the point friend realizes it needs to 
 redirect the user to do authentication, then that url being used on L149 up 
 there when the workflow sets redirect-on-auth? to true.
 
 Am I misunderstanding the flow or is there a mixup here? The tests only tests 
 for boolean state, not as a string url.

You're misunderstanding.  If ::redirect-on-auth? is any truthy value (which 
includes strings), then `redirect-new-auth` will either:

(a) send a redirect to the ::unauthorized-uri as captured in the session, which 
is only ever set if the user previously requested a resource for which they 
were not authorized (see 
https://github.com/cemerick/friend/blob/master/src/cemerick/friend.clj#L200), or

(b) redirect to the value of ::redirect-on-auth? if it is a string, or

(c) redirect to the :default-landing-url specified in the configuration 
provided to `authenticate`.

You're right that (b) will never be the case for the interactive-form workflow, 
fundamentally because `cemerick.friend.workflows/make-auth` merges the 
`auth-meta` defaults in last, rather than first.  That's a valid point of 
enhancement; ticket/patch welcome. :-)

Note that ::redirect-on-auth? _is_ poorly named: it was originally expected to 
only be a boolean, thus the '?'.  Its name will need to change in the future to 
reflect its actual role.

- Chas

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