Re: [ANN] Clojure 1.10.0-alpha7

[Stuart Halloway]

Hi Erik,

That does seem like a good idea. Thanks!

Stu

On Thu, Sep 6, 2018 at 4:39 AM Erik Assum  wrote:

> Would it be an idea to include something like
>
> ```
> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-alpha7"’
> ```
>
> in such announcements so the lazy of us could just copy/paste it into our
> shells to try it out?
>
> Erik.
>
> On 5 Sep 2018, at 14:39, Stuart Halloway 
> wrote:
>
> org.clojure/clojure {:mvn/version "1.10.0-alpha7"}
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[ANN] Clojure 1.10.0-alpha7

[Stuart Halloway]

deps.edn dependency:

  org.clojure/clojure {:mvn/version "1.10.0-alpha7"}

1.10.0-alpha7 includes the following changes since 1.10.0-alpha6:

   - Update deps to latest spec.alpha (0.2.176) and core.specs.alpha
   (0.2.44)
   - CLJ-2373  - categorize
   and overhaul printing of exception messages at REPL
   - CLJ-1279  - report
   correct arity count for function arity errors inside macros
   - CLJ-2386  - omit ex-info
   construction stack frames
   - CLJ-2394  - warn in pst
   that stack trace for syntax error failed before execution
   - CLJ-2396  - omit :in
   clauses when printing spec function errors if using default explain printer

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

Re: [ANN] Datomic Cloud

[Stuart Halloway]

Hi Nando,

Datomic Cloud is deeply integrated with AWS. Our recommended approach for
dev is to provision a Solo system and enable the bastion server [1], then
you can use it directly from your dev/staging/CI environment [2].

Cheers,
Stu

[1]
https://docs.datomic.com/cloud/getting-started/configuring-access.html#authorize-bastion
[2]
https://docs.datomic.com/cloud/getting-started/connecting.html#socks-proxy

On Wed, Jan 17, 2018 at 3:46 PM, Nando Breiter <na...@aria-media.com> wrote:

> Is it / how is it possible to develop locally against the cloud version
> (or close enough to the cloud version) of datomic?
>
> My Datomic Pro Starter Edition license expired some 8 months ago. I don't
> remember if local development is allowed for subsequent versions released.
>
> thanks,
>
> Nando
>
>
>
> Aria Media Sagl
> +41 (0)76 303 4477 <+41%2076%20303%2044%2077> cell
> skype: ariamedia
>
> On Wed, Jan 17, 2018 at 4:59 PM, Alan Thompson <clooj...@gmail.com> wrote:
>
>> Cool.
>>
>> On Wed, Jan 17, 2018 at 6:25 AM, Jeroen van Dijk <
>> jeroentjevand...@gmail.com> wrote:
>>
>>> Congrats!
>>>
>>> On Wed, Jan 17, 2018 at 3:06 PM, Stuart Halloway <
>>> stuart.hallo...@gmail.com> wrote:
>>>
>>>> Datomic Cloud is now available! http://blog.datomic
>>>> .com/2018/01/datomic-cloud.html
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clojure@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+unsubscr...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojure+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[ANN] Datomic Cloud

[Stuart Halloway]

Datomic Cloud is now available!
http://blog.datomic.com/2018/01/datomic-cloud.html

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

[Stuart Halloway]

Hi Tim,

You suggested a great reason yourself: "peoples approach to doc strings are
as varied as people are". To the extent that is true, someone would need to
propose a design considerate of that variety of needs (and tradeoffs!).
Without such planning, Clojure would evolve as a semi-random-walk of
itch-scratching. I have worked with tools that evolve this way and I am
thrilled that Clojure isn't one.

That said, Clojure is flexible enough that you could experiment with this
idea on your own and create a proof-of-concept requiring no change to core.
I am pretty sure you will encounter problems along the way. :-)

Cheers,
Stu



On Sun, Nov 5, 2017 at 10:24 AM, Tim  wrote:

> I expected a code smell response, but I simply don't agree with that. I
> believe peoples approach to doc strings are as varied as people are. I tend
> to be specific and want to add more context (do not read 'more content') in
> my doc string(s) than others might, but at the same time it's not like
> there's a shortage of poorly documented code in the world. So maybe we
> should consider other people's approach too. A simple solution might be to
> put the doc-string before the name:
>
> i.e. Instead of:
>
> defmulti the-name multi-fn
>
> use:
>
> defmulti "brevity matters in a doc-string" the-name multi-fn
>
> Or
>
> (defn
> "doc-string"
> ([x]...)
> "doc-string"
> ([x y] ...))
>
> Or is there a reason not to consider adding this?
>
> Cheers,
> Tim
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [core.spec] Stricter map validations?

[Stuart Halloway]

Hi Leon,

I think it would be a mistake to introduce temporal coupling to prevent
typos. Here is an alternative that lets you identify "missing" keys specs at
the time and place of your choosing, and then handle them as you deem
appropriate, without imposing those decisions on other users of spec:

https://gist.github.com/stuarthalloway/f4c4297d344651c99827769e1c3d34e9

Regards,
Stu




On Tue, Oct 10, 2017 at 12:33 PM, Leon Grapenthin 
wrote:

> In terms of code loading, acyclic dependencies turned out to be a great
> design choice in Clojure - why its benefits shouldn't apply to or be
> justified for spec loading is totally unclear to me.
>
> To make my point more clear let me recap. I am simply asking for s/keys to
> throw if provided specs aren't registered. Because my colleagues and I
> myself made costly mistakes that would have been prevented. The most common
> scenario is a typo like the one I have illustrated above.
>
> I have asked what benefits justify current behavior?
>
> The only justification comes from Sean saying that it helps him
> prototyping. While I agree I also observe that this is simultaneously the
> trapdoor leading to such silently passing specs. And why prototyping needs
> should not be a primary concern in how s/keys behaves.
>
> I have tried to make a case for current behavior: It allows to say a key
> is there, without saying anything about its value. I have pointed out (s.
> a.) why this IMO has too little utility to justify anything.
>
> Regarding Clojure being a dynamic lanugage this doesn't really make a
> difference here: There is not much dynamic going on about registration and
> spec in general. Registration etc. is evaluated at compile time.  Note that
> s/def, s/keys etc. are all macros whose expansion is evaluated at compile
> time.
>
> On Monday, October 9, 2017 at 7:20:42 PM UTC+2, Beau Fabry wrote:
>>
>> > The argument that existence of specs provided to s/keys can only be
>> checked at runtime is false.
>>
>> > The argument that that recursive specs are impossible if existence of
>> specs provided to s/keys was checked at compile time is also false.
>>
>> Could you explain to us why this is false? Clojure is a dynamic language,
>> as such I don't see how you could define a time when all specs need to be
>> present. How would I enter this spec at the repl if spec definition was
>> required at s/keys invocation time?
>>
>
>
>>
>> On Friday, October 6, 2017 at 4:32:41 PM UTC-7, Leon Grapenthin wrote:
>>>
>>> The argument that existence of specs provided to s/keys can only be
>>> checked at runtime is false.
>>>
>>> The argument that that recursive specs are impossible if existence of
>>> specs provided to s/keys was checked at compile time is also false.
>>>
>>> The usecase for libraries is not convincing: If the libraries author
>>> states "the map has to have a key K" nobody can spec K further since that
>>> would be a race condition among consumers (who s/defs K first?). Requiring
>>> the libraries author to declare K as any? would at least require him to
>>> decide and convey his intent.
>>>
>>> The argument that not checking a value associated with a key is
>>> corresponding to a guding design principle of map specs being based on a
>>> keyset is not stating enough to justify discussed behavior. The utility of
>>> knowing that a keyset is present is close to none, which should be the main
>>> reasons why s/keys validates values. Again: Saying "A map that has a key
>>> called ::foo" is pretty pointless in Clojure. If every map in every Clojure
>>> program I wrote had a key ::foo they would all produce the exact same
>>> results as if they didn't and I bet yours would, too.
>>>
>>> Prototyping is indeed a bit more easy if one does not have to to declare
>>> every spec used in a s/keys. However, that is particularly damning if you
>>> forget to add that spec later or mistype its name when doing so. Which
>>> happens, and which is why I'm unhappy with this design letting such typical
>>> human errors pass compilation. It would also help my prototyping needs if I
>>> could reference symbols that are not declared, but I prefer the compiler
>>> errors before going live.
>>>
>>> On Saturday, October 7, 2017 at 12:01:34 AM UTC+2, Sean Corfield wrote:

 As one of the (apparently pretty uncommon) users who actually does
 happily define s/keys specs without correspondingly speccing the leaves as
 an "incrementally lock down/validate" approach, I wouldn't be too upset if
 I lost that ability and it started throwing an error. I mean it throws an
 error if I go to generate it anyway.



 **puts hand up!**



 I don’t want to have to write (s/def ::some-key any?) all over the
 place as I’m developing specs, just to satisfy an overly eager checker (in
 my mind). Worse, since the check would need to be deferred until validation
 time, as Beau notes, the omission of an “any?” key spec 

Re: Releasing scope-capture, a library for easing REPL-based debugging

[Stuart Halloway]

Very cool, Val!

It should be possible to recreate the original scope as a let (instead of
defs) so you don't have to worry about the names cluttering up your
namespace.

Cheers,
Stu

On Sun, Oct 8, 2017 at 10:17 PM, Jiacai Liu  wrote:

> Wow, what a good idea. Thanks for sharing.
>
> On Mon, Oct 9, 2017 at 7:05 AM, Mike <145...@gmail.com> wrote:
>
>> Cool! Thanks, Val!
>>
>> воскресенье, 8 октября 2017 г., 10:09:19 UTC+3 пользователь Val
>> Waeselynck написал:
>>
>>> Hi, I'm happy to release a tiny Clojure/Script library called
>>> scope-capture .
>>>
>>> https://github.com/alvalval/scope-capture
>>>
>>> Loosely speaking, scope-capture makes it trivial to reproduce from the
>>> REPL the context of a piece of code after it executed.
>>>
>>> It was inspired by Stuart Halloway's article *REPL Debugging: no
>>> stacktrace required
>>> *.
>>> Thanks Stu!
>>>
>>> I've been using it professionally for a few weeks now, and it's been a
>>> significant productivity boost for me. In my view the benefits are:
>>>
>>>- easier debugging
>>>- making Clojure code / projects more accessible to beginners
>>>- easier ad-hoc exploration
>>>
>>> Please let me know what you think!
>>>
>>> Valentin Waeselynck
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Help ship Clojure 1.9!

[Stuart Halloway]

Hi Mark,

I think this approach totally makes sense, and the alpha naming exists to
inform this kind of decision-making.

For libraries where the use of spec does not have to be user-facing, I am
putting specs in separate (Clojure) namespaces, and loading them in such a
way that they can coexist with non (or maybe different) spec environments.
But that is extra work for sure.

Stu

On Mon, Oct 2, 2017 at 3:35 PM, Mark Engelberg <mark.engelb...@gmail.com>
wrote:

> On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway <stuart.hallo...@gmail.com
> > wrote:
>
>> Hi David,
>>
>> Spec will be in alpha for a while. That is part of the point of it being
>> a separate library. Can you say more about what problems this is causing?
>>
>> Stu
>>
>>
> As a library maintainer, I am forced to upgrade and release my library any
> time something I depend upon makes a breaking change.  I don't get paid for
> maintaining open source libraries, it's something I do in my spare time, so
> I prefer to do it on my own schedule.  When an underlying library makes a
> breaking change, I get dozens of urgent requests from people who need me to
> cut a new release ASAP, and by Murphy's Law, that often happens when I have
> very little time to do it.  It's a nuisance.
>
> Clojure is pretty good about not making breaking changes, but it happens
> from time to time.  Clojurescript is less good about not making breaking
> changes, and therefore, maintaining Clojurescript libraries is more of a
> headache.  On the plus side, Clojurescript users seem to care very little
> about backwards compatibility (most keep up with the latest version), so
> sometimes it is easier to make a change to keep up with a change in
> Clojurescript than one in Clojure, where I am expected to not only support
> the latest breaking change, but also the last several releases.
>
> Anything that is labeled as "alpha" is waving a big red flag that there
> could be breaking changes at any time with little warning.  For my
> libraries which depend on spec, there's no way I'm going to bring them out
> of alpha status until spec comes out of alpha status.  If I make an
> official release of something that depends on spec, then I'm going to be on
> the hook to rapidly cut a new release every time spec changes, which could
> be at any time.  I don't want that hassle.  I don't want to make a promise
> to the community to maintain a stable product if the thing I depend upon
> has not made a similar promise.  When spec reaches a point where the API
> will not be changing, or rather, when we know that new changes will only be
> additive, I can begin to trust that it won't be a huge maintenance headache
> to release something based on spec.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Help ship Clojure 1.9!

[Stuart Halloway]

Hi David,

Spec will be in alpha for a while. That is part of the point of it being a
separate library. Can you say more about what problems this is causing?

Stu

On Sat, Sep 30, 2017 at 4:52 AM, David Bürgin <dbuer...@gluet.ch> wrote:

> On 28/09/17 16:00, Stuart Halloway wrote:
> > Clojure 1.9 has been quite stable throughout the alpha period, and we
> > now hope to release after a very short beta. Please test your existing
> > programs on the latest beta (see below), and respond on this thread ASAP
> > if you discover anything you believe to be a regression.
>
> Will there be a non-alpha release of spec together with Clojure 1.9?
>
> Some newer libraries have statements like ‘in alpha while Clojure 1.9 is
> in alpha’, but what they actually seem to mean is that they’re in alpha
> while spec is in alpha. I think a proper release of spec (namespaces
> without the word ‘alpha’) sometime soon would be very welcome.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Help ship Clojure 1.9!

[Stuart Halloway]

And to maybe answer my own question, I guess it is
https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L988-L990
.

On Fri, Sep 29, 2017 at 1:45 PM, Stuart Halloway <stuart.hallo...@gmail.com>
wrote:

> To be clear: we can certainly cut a new release of CLJS, I just want to
> understand other options, if any.
>
> On Fri, Sep 29, 2017 at 1:38 PM, Stuart Halloway <
> stuart.hallo...@gmail.com> wrote:
>
>> Hi Aleš, Mark,
>>
>> Thanks for the reports! It isn't clear to me how a change to tools.reader
>> can fix a problem with the core hash function. Can somebody point me to the
>> place in the Clojurescript code where this happens?
>>
>> Stu
>>
>> On Fri, Sep 29, 2017 at 11:13 AM, Aleš Roubíček <rar...@gmail.com> wrote:
>>
>>> The Cljs problem is easily solvable by referencing latest tools.reader:
>>>
>>>  [org.clojure/clojurescript "1.9.908" :exclusions 
>>> [org.clojure/tools.reader]]
>>>  [org.clojure/tools.reader "1.1.0"]
>>>
>>>
>>>
>>>
>>> On Thursday, September 28, 2017 at 8:37:11 PM UTC+2, puzzler wrote:
>>>>
>>>> And to be clear, it doesn't only affect people who try to use ##Inf or
>>>> ##NaN in their Clojurescript code.  It affects all existing Clojurescript
>>>> code, because running the Clojurescript compiler in a new version of
>>>> Clojure causes all Clojurescript code to emit these ## characters directly
>>>> into the javascript for its definition of the core hash function, which is
>>>> nonsensical javascript.  So all Clojurescript code is broken by running the
>>>> new release.
>>>>
>>>> On Thu, Sep 28, 2017 at 11:34 AM, Mark Engelberg <mark.en...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Thu, Sep 28, 2017 at 11:02 AM, Jeaye <con...@jeaye.com> wrote:
>>>>>
>>>>>> This has been the only issue we've run into with 1.9.0-beta1 ( ticket
>>>>>> is here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our
>>>>>> back-end, all tests are good, but we can't currently use beta1 (or 
>>>>>> alpha20)
>>>>>> on the front-end, since this issue causes CLJS to choke. I'm hoping that 
>>>>>> a
>>>>>> new version of CLJS comes out before Clojure 1.9.0 so that people don't 
>>>>>> get
>>>>>> the false impression that the latest of each is compatible with the 
>>>>>> other.
>>>>>>
>>>>>> J
>>>>>>
>>>>>>
>>>>> Agreed.  It is currently not possible to use Clojure 1.9.0 later than
>>>>> alpha19 with Clojurescript.  Clojurescript as it currently stands can't
>>>>> handle the new ## tags like ##Inf, ##NaN.  Like a number of people, I got
>>>>> burned by this when I tried to upgrade and spent some time tracking it
>>>>> down, only to realize it was already a known incompatibility.  There will
>>>>> be a lot more confused people if you release Clojure 1.9.0 prior to
>>>>> releasing a new version of Clojurescript that is compatible.
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

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

Re: Help ship Clojure 1.9!

[Stuart Halloway]

To be clear: we can certainly cut a new release of CLJS, I just want to
understand other options, if any.

On Fri, Sep 29, 2017 at 1:38 PM, Stuart Halloway <stuart.hallo...@gmail.com>
wrote:

> Hi Aleš, Mark,
>
> Thanks for the reports! It isn't clear to me how a change to tools.reader
> can fix a problem with the core hash function. Can somebody point me to the
> place in the Clojurescript code where this happens?
>
> Stu
>
> On Fri, Sep 29, 2017 at 11:13 AM, Aleš Roubíček <rar...@gmail.com> wrote:
>
>> The Cljs problem is easily solvable by referencing latest tools.reader:
>>
>>  [org.clojure/clojurescript "1.9.908" :exclusions [org.clojure/tools.reader]]
>>  [org.clojure/tools.reader "1.1.0"]
>>
>>
>>
>>
>> On Thursday, September 28, 2017 at 8:37:11 PM UTC+2, puzzler wrote:
>>>
>>> And to be clear, it doesn't only affect people who try to use ##Inf or
>>> ##NaN in their Clojurescript code.  It affects all existing Clojurescript
>>> code, because running the Clojurescript compiler in a new version of
>>> Clojure causes all Clojurescript code to emit these ## characters directly
>>> into the javascript for its definition of the core hash function, which is
>>> nonsensical javascript.  So all Clojurescript code is broken by running the
>>> new release.
>>>
>>> On Thu, Sep 28, 2017 at 11:34 AM, Mark Engelberg <mark.en...@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Sep 28, 2017 at 11:02 AM, Jeaye <con...@jeaye.com> wrote:
>>>>
>>>>> This has been the only issue we've run into with 1.9.0-beta1 ( ticket
>>>>> is here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our
>>>>> back-end, all tests are good, but we can't currently use beta1 (or 
>>>>> alpha20)
>>>>> on the front-end, since this issue causes CLJS to choke. I'm hoping that a
>>>>> new version of CLJS comes out before Clojure 1.9.0 so that people don't 
>>>>> get
>>>>> the false impression that the latest of each is compatible with the other.
>>>>>
>>>>> J
>>>>>
>>>>>
>>>> Agreed.  It is currently not possible to use Clojure 1.9.0 later than
>>>> alpha19 with Clojurescript.  Clojurescript as it currently stands can't
>>>> handle the new ## tags like ##Inf, ##NaN.  Like a number of people, I got
>>>> burned by this when I tried to upgrade and spent some time tracking it
>>>> down, only to realize it was already a known incompatibility.  There will
>>>> be a lot more confused people if you release Clojure 1.9.0 prior to
>>>> releasing a new version of Clojurescript that is compatible.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Help ship Clojure 1.9!

[Stuart Halloway]

Hi Aleš, Mark,

Thanks for the reports! It isn't clear to me how a change to tools.reader
can fix a problem with the core hash function. Can somebody point me to the
place in the Clojurescript code where this happens?

Stu

On Fri, Sep 29, 2017 at 11:13 AM, Aleš Roubíček  wrote:

> The Cljs problem is easily solvable by referencing latest tools.reader:
>
>  [org.clojure/clojurescript "1.9.908" :exclusions [org.clojure/tools.reader]]
>  [org.clojure/tools.reader "1.1.0"]
>
>
>
>
> On Thursday, September 28, 2017 at 8:37:11 PM UTC+2, puzzler wrote:
>>
>> And to be clear, it doesn't only affect people who try to use ##Inf or
>> ##NaN in their Clojurescript code.  It affects all existing Clojurescript
>> code, because running the Clojurescript compiler in a new version of
>> Clojure causes all Clojurescript code to emit these ## characters directly
>> into the javascript for its definition of the core hash function, which is
>> nonsensical javascript.  So all Clojurescript code is broken by running the
>> new release.
>>
>> On Thu, Sep 28, 2017 at 11:34 AM, Mark Engelberg 
>> wrote:
>>
>>> On Thu, Sep 28, 2017 at 11:02 AM, Jeaye  wrote:
>>>
 This has been the only issue we've run into with 1.9.0-beta1 ( ticket
 is here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our
 back-end, all tests are good, but we can't currently use beta1 (or alpha20)
 on the front-end, since this issue causes CLJS to choke. I'm hoping that a
 new version of CLJS comes out before Clojure 1.9.0 so that people don't get
 the false impression that the latest of each is compatible with the other.

 J


>>> Agreed.  It is currently not possible to use Clojure 1.9.0 later than
>>> alpha19 with Clojurescript.  Clojurescript as it currently stands can't
>>> handle the new ## tags like ##Inf, ##NaN.  Like a number of people, I got
>>> burned by this when I tried to upgrade and spent some time tracking it
>>> down, only to realize it was already a known incompatibility.  There will
>>> be a lot more confused people if you release Clojure 1.9.0 prior to
>>> releasing a new version of Clojurescript that is compatible.
>>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Help ship Clojure 1.9!

[Stuart Halloway]

Thanks Beau!

On Thu, Sep 28, 2017 at 1:06 PM, Beau Fabry <imf...@gmail.com> wrote:

> Identified an issue with prismatic/schema https://
> github.com/plumatic/schema/pull/399
>
> On Thursday, September 28, 2017 at 9:18:52 AM UTC-7, Nathan Fisher wrote:
>>
>> Hi Stuart,
>>
>> Looks like any project using lein-cljsbuild will be affected.
>>
>> I forked and bumped the Clojure and ClojureScript version to latest and
>> got the same error with their simple project:
>>
>> See Commit:
>> https://github.com/nfisher/lein-cljsbuild/commit/5df5d3c5bb4
>> 47b51a75abbbccdc72447814883a0
>>
>> STR
>>
>> 1. git clone https://github.com/nfisher/lein-cljsbuild
>> 2. cd lein-cljsbuild/example/projects/simple
>> 3. lein cljsbuild once
>>
>> Patch attached if you want to apply directly to
>> https://github.com/emezeske/lein-cljsbuild
>>
>> Cheers,
>> Nathan
>>
>> On Thu, 28 Sep 2017 at 16:13 Stuart Halloway <stuart@gmail.com>
>> wrote:
>>
>>> Hi Nathan,
>>>
>>> I suspect that is the same as https://github.com/clojure/clo
>>> jurescript/commit/89914d2ead964122f99e638edda0cd96d330cb66.  I don't
>>> have a sense of how many CLJS project this is going to cascade into, or
>>> what all will be needed. Anyone?
>>>
>>> Stu
>>>
>>> On Thu, Sep 28, 2017 at 10:44 AM, Nathan Fisher <nfi...@junctionbox.ca>
>>> wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> Working to create a minimal test case but upgrading from alpha19 to
>>>> beta1 seems to have broken lein-cljsbuild.
>>>>
>>>> I get the following error:
>>>>
>>>> >>>>>> snip >>>>>>
>>>>
>>>> *SEVERE:
>>>> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js:3579:
>>>> ERROR - Parse error. primary expression expected*
>>>>
>>>> *case ##Inf:*
>>>>
>>>> *  ^*
>>>>
>>>>
>>>> *Sep 28, 2017 3:23:10 PM
>>>> com.google.javascript.jscomp.LoggerErrorManager printSummary*
>>>>
>>>> *WARNING: 1 error(s), 0 warning(s)*
>>>>
>>>> *ERROR: JSC_PARSE_ERROR. Parse error. primary expression expected at
>>>> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js
>>>> line 3579 : 6*
>>>> <<<<<< snip <<<<<<
>>>>
>>>> Changes in my project.clj deps are as follows:
>>>>
>>>> *- [org.clojure/clojure "1.9.0-alpha19" :scope "provided"]*
>>>>
>>>> *+ [org.clojure/clojure "1.9.0-beta1" :scope "provided"]*
>>>>
>>>> A revert on my project.clj to alpha19 eliminates the error.
>>>>
>>>> Cheers!
>>>>
>>>> Nathan
>>>>
>>>> On Thu, 28 Sep 2017 at 15:00 Stuart Halloway <stuart@gmail.com>
>>>> wrote:
>>>>
>>>>> Clojure 1.9 has been quite stable throughout the alpha period, and we
>>>>> now hope to release after a very short beta. Please test your existing
>>>>> programs on the latest beta (see below), and respond on this thread ASAP 
>>>>> if
>>>>> you discover anything you believe to be a regression.
>>>>>
>>>>> Thanks!
>>>>> Stu
>>>>>
>>>>> ;; Clojure deps.edn
>>>>> org.clojure/clojure {:mvn/version "1.9.0-beta1"}
>>>>>
>>>>> ;; lein & boot
>>>>> [org.clojure/clojure "1.9.0-beta1"]
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To post to this group, send email to clo...@googlegroups.com
>>>>> Note that posts from new members are moderated - please be patient
>>>>> with your first post.
>>>>> To unsubscribe from this group, send email to
>>>>> clojure+u...@googlegroups.com
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/clojure?hl=en
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To unsubscribe from

Re: Help ship Clojure 1.9!

[Stuart Halloway]

Hi Nathan,

I suspect that is the same as
https://github.com/clojure/clojurescript/commit/89914d2ead964122f99e638edda0cd96d330cb66.
I don't have a sense of how many CLJS project this is going to cascade
into, or what all will be needed. Anyone?

Stu

On Thu, Sep 28, 2017 at 10:44 AM, Nathan Fisher <nfis...@junctionbox.ca>
wrote:

> Hi Stuart,
>
> Working to create a minimal test case but upgrading from alpha19 to beta1
> seems to have broken lein-cljsbuild.
>
> I get the following error:
>
> >>>>>> snip >>>>>>
>
> *SEVERE:
> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js:3579:
> ERROR - Parse error. primary expression expected*
>
> *case ##Inf:*
>
> *  ^*
>
>
> *Sep 28, 2017 3:23:10 PM com.google.javascript.jscomp.LoggerErrorManager
> printSummary*
>
> *WARNING: 1 error(s), 0 warning(s)*
>
> *ERROR: JSC_PARSE_ERROR. Parse error. primary expression expected at
> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js
> line 3579 : 6*
> <<<<<< snip <<<<<<
>
> Changes in my project.clj deps are as follows:
>
> *- [org.clojure/clojure "1.9.0-alpha19" :scope "provided"]*
>
> *+ [org.clojure/clojure "1.9.0-beta1" :scope "provided"]*
>
> A revert on my project.clj to alpha19 eliminates the error.
>
> Cheers!
>
> Nathan
>
> On Thu, 28 Sep 2017 at 15:00 Stuart Halloway <stuart.hallo...@gmail.com>
> wrote:
>
>> Clojure 1.9 has been quite stable throughout the alpha period, and we now
>> hope to release after a very short beta. Please test your existing programs
>> on the latest beta (see below), and respond on this thread ASAP if you
>> discover anything you believe to be a regression.
>>
>> Thanks!
>> Stu
>>
>> ;; Clojure deps.edn
>> org.clojure/clojure {:mvn/version "1.9.0-beta1"}
>>
>> ;; lein & boot
>> [org.clojure/clojure "1.9.0-beta1"]
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> - sent from my mobile
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Help ship Clojure 1.9!

[Stuart Halloway]

Clojure 1.9 has been quite stable throughout the alpha period, and we now
hope to release after a very short beta. Please test your existing programs
on the latest beta (see below), and respond on this thread ASAP if you
discover anything you believe to be a regression.

Thanks!
Stu

;; Clojure deps.edn
org.clojure/clojure {:mvn/version "1.9.0-beta1"}

;; lein & boot
[org.clojure/clojure "1.9.0-beta1"]

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

Re: Clojure core documentation

[Stuart Halloway]

Clojure has great data, and great metadata. Documentation strings are *not*
great data, they are strings.

If you want to provide more structured support than docstrings to help
someone use Clojure, look at specs for inspiration. They are made of data,
and they live in a registry separate from Clojure's var system. This kind
of decoupling supports composition and tooling without requiring any
addition or change to Clojure.

I would also echo Matching Socks: Having more and better guides at
clojure.org would be great. The contribution process is described at
https://github.com/clojure/clojure-site/blob/master/content/community/contributing_site.adoc
.

Regards,
Stu

On Mon, Sep 11, 2017 at 5:23 AM, Matching Socks 
wrote:

> I am not convinced I would have found the API docs on reducers or zippers
> more informative if all references had been tidily markdown'ed.
>
> The new clojure.org welcomes contributions of topical overviews.  That's
> helpful.
>
> But, to interpret docstrings, nothing helps like perspective.  The thing
> about perspective is that there could be so many.  I like "Clojure
> Programming" by Emerick, Carper & Grand.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: AOT classes with clj files on classpath causing ClassNotFoundException

[Stuart Halloway]

Hi Piotr,

Yes, the limitation is how the Java classpath works.  If you AOT your app,
you need to AOT compile other Clojure code your app uses.

See e.g.
http://dev.clojure.org/jira/browse/CLJ-1544?focusedCommentId=43558=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-43558

Cheers,
Stu

On Wed, Oct 12, 2016 at 2:22 PM, Piotr Bzdyl  wrote:

> Hello,
>
> I am trying to solve an issue in my project where I have the following
> setup. My application modules are AOT-compiled into several jars and then
> packaged with their 3rd party dependencies into an uberjar. As a result my
> uberjar contains my project's namespaces compiled to class files and
> dependencies (in this case clojure.java.jdbc) source clj files.
>
> When I try to start the application it fails with the following
> stacktrace. Is there any limitation that prevents me running AOT-compiled
> namespaces using other namespaces available as clj on classpath?
>
> java.lang.reflect.InvocationTargetException: null
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_102]
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_102]
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_102]
>at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_102]
>at com.example.Launcher$ThreadLauncher.run(Launcher.java:42) ~[na:na]
>at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> Caused by: java.lang.NoClassDefFoundError: clojure/java/jdbc/Connectable
>at com.example.db.common.database__init.load(Unknown Source) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at com.example.db.common.database__init.(Unknown Source) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at java.lang.Class.forName0(Native Method) ~[na:1.8.0_102]
>at java.lang.Class.forName(Class.java:348) ~[na:1.8.0_102]
>at clojure.lang.RT.classForName(RT.java:2154) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.classForName(RT.java:2163) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.loadClassForName(RT.java:2182) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.load(RT.java:436) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.load(RT.java:412) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load$fn__5448.invoke(core.clj:5866) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load.doInvoke(core.clj:5865) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.invoke(RestFn.java:408) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_one.invoke(core.clj:5671) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_lib$fn__5397.invoke(core.clj:5711) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_lib.doInvoke(core.clj:5710) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.applyTo(RestFn.java:142) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$apply.invoke(core.clj:632) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_libs.doInvoke(core.clj:5749) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.applyTo(RestFn.java:137) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$apply.invoke(core.clj:632) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$require.doInvoke(core.clj:5832) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.invoke(RestFn.java:421) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at 
> com.example.db.auth.password$loading__5340__auto1250.invoke(password.clj:1)
>  ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at com.example.db.auth.password__init.load(Unknown Source) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at com.example.db.auth.password__init.(Unknown Source) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at java.lang.Class.forName0(Native Method) ~[na:1.8.0_102]
>at java.lang.Class.forName(Class.java:348) ~[na:1.8.0_102]
>at clojure.lang.RT.classForName(RT.java:2154) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.classForName(RT.java:2163) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.loadClassForName(RT.java:2182) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.load(RT.java:436) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.load(RT.java:412) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load$fn__5448.invoke(core.clj:5866) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load.doInvoke(core.clj:5865) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.invoke(RestFn.java:408) 
> 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Stuart Halloway]

Hi Gary,

Re the documentation: A lot of people have worked to make clojure.org
better, including changing the contribution model to be both easier and
more familiar.

That said, I don't doubt that is could be a lot better.  In particular, the
guides section could expand to cover a lot of the "convention"-type topics
you allude to. You can contribute here:
https://github.com/clojure/clojure-site.  And now also here:
https://github.com/clojure/clojurescript-site.

Stu

On Thu, Aug 25, 2016 at 11:54 AM, Gary Trakhman 
wrote:

> Over the years I've kind of started agreeing with what Brian's saying.
> Much as I love/know clojure and the philosophy that bears its fruit, I
> think spec's sideband error-handling is a great low-risk opportunity to
> build in some 'easy'.
>
> My team is moving from rails towards elixir after having seriously
> considered clojure (and hiring me recently under that premise), and I'm
> having to apologize for the general lack of novice guardrails,
> 'conventions' and documentation that people from other communities expect.
> I think it looks pretty good if you're used to java (java conservatism
> notwithstanding), but not so good if you've been in dynlangs (particularly
> ruby) or other FP languages besides lisp.
>
> I'm concerned the current approach will lead to too many half-baked
> error-reporters.  Alternatively, if there's a canonical human-facing
> error-reporter built on top of the more stable data representation, I think
> it would be generally acceptable to break 'contracts' there as we find
> better ways to show the errors.
>
> On Thu, Aug 25, 2016 at 11:18 AM Brian Marick 
> wrote:
>
>>
>> On Aug 24, 2016, at 9:28 PM, adrian.med...@mail.yu.edu wrote:
>>
>> I do not think your tone and lack of constructive feedback to Alex's (and
>> others) thoughtful responses is helping your case.
>>
>>
>> Probably not(*), though I would characterize the responses differently.
>> They are polite, and they are intended to be helpful to someone who already
>> agrees with axioms like “good error-handling is a nail for which core.spec
>> is the hammer” and “it is wise to push the responsibility for error
>> understanding to third-party libraries or diligent study”. They do a
>> service in that they lay out the rules under which Clojure users should
>> expect to live. But they are largely reiterations rather than engagement. I
>> find that rather frustrating.
>>
>>
>> Let me point to an essential book on business/community management,
>> Hirschman’s /Exit, Voice, and Loyalty/. https://en.
>> wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and to a clever take on
>> group behavior, “Evaporative Cooling of Group Beliefs”, http://lesswrong.
>> com/lw/lr/evaporative_cooling_of_group_beliefs/. I think there is much
>> to learn from reflecting on those and the direction of Clojure design and
>> the Clojure community over the past few years. (I’m not a huge fan of the
>> application of Satir’s family counseling theory to software management -
>> Gerald Weinberg and the like - but it’s hard not to read books like the
>> /Quality Software Management/ series and see people in the Clojure
>> community - including me! - playing out stereotypical dysfunctional roles.)
>>
>> Read me as someone who’s publicly and self-destructively giving up on
>> Voice and is on the way to Exit. As someone who tends to Loyalty (though
>> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s
>> rather agonizing. That is, I still think Clojure is the best raw language
>> out there for broad-spectrum work. However, its design has been doubling
>> down on long-unfortunate tendencies, and - I’d argue - new languages like
>> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community
>> management and “peripheral” concerns like documentation and error handling.
>> In the meantime, the Clojure ideology - reinforced by memes like
>> “complecting” - has been getting more rigid.
>>
>> The result is that what seem to me bizarre decisions are treated as
>> normal. We have an `any?` in clojure.core that always returns `true`. This
>> deviance from probably every other programming language is justified as
>> obvious for a feature - clojure.spec - that is largely unproven, certainly
>> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and
>> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is
>> completely dismissed, with the justification that people complain about
>> every new name. (Think about what that decision criterion entails, broadly
>> applied.)
>>
>> Also bizarre: the idea that error messages that amount to essentially
>> dumping a parse tree + BNF-ish grammar clause (possibly twice with a
>> vomitous stack trace between) is a *good* thing. Not a “we wish we could do
>> better, but software development is about constraints and tradeoffs” thing.
>> Not a “yeah, but Rich Hickey doesn’t want to bother with 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Stuart Halloway]

Hi Brian,

Not crazy at all!  Spec errors are maps at the bottom, and IMO these maps
should flow anywhere we are making exceptions.  This is already true for
the exceptions coming from spec.test, and we should make it true for the
macroexpand exceptions as well. (I actually prefer reading the map format,
IIRC it is what I show in most places in the screencasts.)

Thank you for pointing this out.

Regards,
Stu

On Wed, Aug 24, 2016 at 9:34 PM, Brian Marick 
wrote:

>
> > On Aug 24, 2016, at 7:46 PM, Brian Marick 
> wrote:
> > So why not do it in the bottom layer? Is there some deep reason why only
> an unserious programmer would want information in anything other than the
> current clojure.spec order? (We’re talking here about reordering a list.)
>
> An even crazier idea: given that there are N difference pieces of
> information, they could be presented in a map, with keys that described
> each of them.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Stuart Halloway]

Brian,

The tone of your previous post is not constructive. Let's keep the
discussion about ideas, not people.

Thanks,
Stu


On Wed, Aug 24, 2016 at 8:46 PM, Brian Marick <mar...@roundingpegs.com>
wrote:

>
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway <stuart.hallo...@gmail.com>
> wrote:
>
> 3. "Follow the inverted pyramid so people see what is most important."
>  This kind of thing is easily done in a layer above spec, e.g. a custom
> REPL printer for spec macro errors. Worth working on but not critical to
> getting spec right.
>
>
> So why not do it in the bottom layer? Is there some deep reason why only
> an unserious programmer would want information in anything other than the
> current clojure.spec order? (We’re talking here about reordering a list.)
>
> There has been a notable lack of “yeah, we might have made a sub-optimal
> decision” in this discussion. It looks bad, in my opinion. Has looked bad
> for a long time.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Stuart Halloway]

Hi Beau,

Yes. Nevermind and everyone should learn to read spec. :-)

That said, such customizations allow people to experiment and flesh out a
bunch different ideas in parallel.

Best,
Stu


On Wed, Aug 24, 2016 at 1:17 PM, Beau Fabry  wrote:

> Just specifically on a custom REPL printer, wouldn't that negate the
> benefits Alex sees in people becoming accustomed to reading spec error
> messages? If every error report from each different environment potentially
> looks different? Also, from the position of a community maintainer Brian is
> most commonly going to be seeing the lowest common denominator error
> messages in bug reports filed, and it probably wouldn't be helpful for him
> to be getting multiple representations of the same error in different
> reports.
>
> On Wednesday, August 24, 2016 at 6:39:51 AM UTC-7, stuart@gmail.com
> wrote:
>>
>> Brian originally raised 5 points that were concrete & specific, and
>> therefore potentially actionable. That is usefully-shaped feedback, thanks
>> Brian!  My take on those points, which I will recast in my own words:
>>
>> 1. "Loosen rules about ns form to match what people have actually done."
>>  This is pretty unlikely, for reasons already covered.
>>
>> 2. "You can tailor a much better specific message for 'require should be
>> a keyword' than what spec makes today." There are several possible things
>> to explore here. The most interesting one is "can spec come closer to a
>> bespoke message while maintaining its simplicity and composability?"  We
>> want to make all errors better, not one error awesome. Ideas welcome!
>>
>> 3. "Follow the inverted pyramid so people see what is most important."
>>  This kind of thing is easily done in a layer above spec, e.g. a custom
>> REPL printer for spec macro errors. Worth working on but not critical to
>> getting spec right.
>>
>> 4. "Name the problem namespace."  Spec does way better than this already,
>> finding the precise file and line.  If there are places where this is
>> busted we should fix them.
>>
>> 5. "I don't want to see the stack trace."  Then filter it out of your
>> REPL.  Intermediaries should never discard telemetry, but end consumers can
>> choose to.
>>
>> Cheers,
>> Stu
>>
>>
>>
>> On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming 
>> wrote:
>>
>>> Sure, at the end of the day I don't really care about thre
>>> require/:require issue, it just seems a little incongruent with previous
>>> decisions which have promoted backwards compatibility. I generally prefer
>>> increased strictness, so I'm fine with the change. I do care about the
>>> error messages, though.
>>>
>>> On 24 August 2016 at 21:32, Mond Ray  wrote:
>>>
 I agree Colin, this feels more like the beatings shall continue until
 morale improves ;-)

 More seriously, I understand the point of the musical instruments
 analogy to be a reminder to programmers that learning a language and
 understanding it in depth will increase your power and expressivity with
 that language. That should not be used as a reason to increase the
 difficulties caused by obscure error reporting. My initial understanding of
 the sales pitch for specs was that it would serve to improve error messages
 as the macro expansions / transformations would be more tractable in the
 compiler. I get that it is a work in progress but let's retain that
 original goal.

 Unlike you however, I would prefer correctness and the consequent
 ripples over the continuing acceptance of incorrect expressions. My
 reasoning is that code which has fewer compatibility style branches will be
 easier to equip with the necessary instrumentation for generating more
 human friendly error messages.

 Ray

 PS I think this require vs :require thing comes from the way that
 novices confuse the ns macro with the function that pulls dependencies in
 at the REPL. Cutting / pasting between the REPL and the file can allow that
 to bleed in. I know it confused me.

 On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote:
>
> But creating error messages that are optimal for a user with no
>> knowledge or Clojure or spec is just not the goal.
>
>
> This is a totally false dichotomy. No-one in this thread is asking for
> that. This thread has several examples of expert Clojure users for whom 
> the
> error messages are incomprehensible.
>
> I am equally unapologetic about thinking that the musical instrument
> analogy is mostly bogus here. There are things that will always be
> difficult about learning Clojure because they're conceptual, such as
> functional programming. I think the analogy is fair there, they are just
> things that will require effort and practice to learn. But the error
> messages are about giving people the information they need *so that
> 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Stuart Halloway]

Brian originally raised 5 points that were concrete & specific, and
therefore potentially actionable. That is usefully-shaped feedback, thanks
Brian!  My take on those points, which I will recast in my own words:

1. "Loosen rules about ns form to match what people have actually done."
 This is pretty unlikely, for reasons already covered.

2. "You can tailor a much better specific message for 'require should be a
keyword' than what spec makes today." There are several possible things to
explore here. The most interesting one is "can spec come closer to a
bespoke message while maintaining its simplicity and composability?"  We
want to make all errors better, not one error awesome. Ideas welcome!

3. "Follow the inverted pyramid so people see what is most important."
 This kind of thing is easily done in a layer above spec, e.g. a custom
REPL printer for spec macro errors. Worth working on but not critical to
getting spec right.

4. "Name the problem namespace."  Spec does way better than this already,
finding the precise file and line.  If there are places where this is
busted we should fix them.

5. "I don't want to see the stack trace."  Then filter it out of your
REPL.  Intermediaries should never discard telemetry, but end consumers can
choose to.

Cheers,
Stu



On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming 
wrote:

> Sure, at the end of the day I don't really care about thre
> require/:require issue, it just seems a little incongruent with previous
> decisions which have promoted backwards compatibility. I generally prefer
> increased strictness, so I'm fine with the change. I do care about the
> error messages, though.
>
> On 24 August 2016 at 21:32, Mond Ray  wrote:
>
>> I agree Colin, this feels more like the beatings shall continue until
>> morale improves ;-)
>>
>> More seriously, I understand the point of the musical instruments analogy
>> to be a reminder to programmers that learning a language and understanding
>> it in depth will increase your power and expressivity with that language.
>> That should not be used as a reason to increase the difficulties caused by
>> obscure error reporting. My initial understanding of the sales pitch for
>> specs was that it would serve to improve error messages as the macro
>> expansions / transformations would be more tractable in the compiler. I get
>> that it is a work in progress but let's retain that original goal.
>>
>> Unlike you however, I would prefer correctness and the consequent ripples
>> over the continuing acceptance of incorrect expressions. My reasoning is
>> that code which has fewer compatibility style branches will be easier to
>> equip with the necessary instrumentation for generating more human friendly
>> error messages.
>>
>> Ray
>>
>> PS I think this require vs :require thing comes from the way that novices
>> confuse the ns macro with the function that pulls dependencies in at the
>> REPL. Cutting / pasting between the REPL and the file can allow that to
>> bleed in. I know it confused me.
>>
>> On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote:
>>>
>>> But creating error messages that are optimal for a user with no
 knowledge or Clojure or spec is just not the goal.
>>>
>>>
>>> This is a totally false dichotomy. No-one in this thread is asking for
>>> that. This thread has several examples of expert Clojure users for whom the
>>> error messages are incomprehensible.
>>>
>>> I am equally unapologetic about thinking that the musical instrument
>>> analogy is mostly bogus here. There are things that will always be
>>> difficult about learning Clojure because they're conceptual, such as
>>> functional programming. I think the analogy is fair there, they are just
>>> things that will require effort and practice to learn. But the error
>>> messages are about giving people the information they need *so that
>>> they can actually learn from their mistakes*. Clojure has historically
>>> been appallingly bad at that, and no-one should expect their users to flail
>>> around randomly trying things to see what works. I've spoken to various
>>> smart people who have described their experience of using Clojure as
>>> exactly that, even after a non-trivial amount of time using it. I hope spec
>>> can improve on that experience.
>>>
>>>
>>> On 24 August 2016 at 02:45, Alex Miller  wrote:
>>>
 I do not have an idea of what the final end point will look like
 exactly. I don't get the feeling that there is any answer that you will
 find satisfying, so I'm not sure what else I can do for you. We expect
 Clojure users to become familiar with spec and its output as it is (now) an
 essential part of the language. You will see specs in error messages.

 The focus in Clojure has always been biased towards building a powerful
 and expressive tool that is rewarding for experts vs optimizing for
 novices. Rich has talked at length 

Re: Is this behavior of clojure.core/pr a bug?

[Stuart Halloway]

Has anybody written a pr-edn that enforces the rules of
https://github.com/edn-format/edn, refusing to print anything nonconformant?

This would solve the original problem on this thread without requiring any
changes to Clojure.

On Fri, Aug 5, 2016 at 9:42 PM, Blake Miller  wrote:

> I agree with Herwig in principal ... even though EDN is not meant to cover
> the whole set of possible pure Clojure data, if it can be made to cover
> more (all other things being equal) that would be a Good Thing.
>
> I think it would be possible to fix these edge cases with reader macro
> dispatches without breaking compatibility. The major snag though is
> that performance would suffer ... every single keyword or symbol being
> `pr`d would have to be tested, even those in the vast majority that don't
> need to be emitted in any special way. So my conclusion is it's not worth
> trying ...
>
> It sucks that the docstring for pr https://github.com/clojure/
> clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L3552-L3555 fails to
> mention that the function may succeed and produce a string that the reader
> will barf on, but I think we're pretty much stuck with it.
>
> For posterity: I switched to using Transit for the Clojure(Script) app
> that had me run across this issue.
>
> On Thu, Aug 4, 2016 at 2:23 PM, Herwig Hochleitner  > wrote:
>
>> 2016-08-04 13:56 GMT+02:00 Timothy Baldridge :
>>
>>> The problem is that many do not understand that Clojure data is a
>>> superset of EDN. The two were never meant to be completely compatible.
>>> There are many things, especially when dealing with keywords and symbols,
>>> where its possible to have data that doesn't properly round-trip.
>>>
>>
>> Then fressian and transit are supersets of edn as well. Are those, at
>> least, meant to be the same set as clojure data?
>> Also, reader tags are a fantastic opportunity to make arbitrary data
>> round-trippable.
>>
>> An added problem when dealing with EDN is that there is only really one
>>> or two languages that properly parse it: Clojure and Clojurescript. So it's
>>> also a poor choice to use in cases where you desire any sort of interop.
>>>
>>
>> There many edn libraries for various languages: https://github.com/
>> edn-format/edn/wiki/Implementations
>> It is true, that there is a lack of compatibility, especially in the
>> handling of symbols and keywords and the community is hurting for it (I
>> remember a couple of tedious discussions on the matter)
>>
>> see http://dev.clojure.org/jira/browse/CLJ-1527 https://gith
>> ub.com/edn-format/edn/issues/67 ...
>>
>> Add on top of all that that EDN parsing is really slow compared to other
>>> approaches, and you have a lot of compelling reasons to, as Herwig put it,
>>> "abandon edn, except for hand-written data".
>>>
>>
>> My view is, that those reasons should be eliminated, starting with
>> interoperability concerns. I still think edn is a fantastic idea and to me
>> it still holds the promise of being a replacement for json and xml, but
>> only if we can get our act together and develop it towards that goal.
>>
>> Please note, that my "except for hand-written data" was meant to be
>> hyperbole. Every data is eventually machine-written.
>>
>> Abandoning edn would send a fatal signal not just to people in the
>> community. Especially if we let it slowly die instead of declaring it a
>> failed experiment in data exchange.
>>
>> Imagine if pr wouldn't handle embedded " quotes in strings and the
>> inofficial recommendation would be to just avoid that use case or use a
>> different encoding.
>>
>> And yes, the original problem that caused the creation of Transit was
>>> "how do we get data from language A to language B while still staying fast,
>>> not implementing a ton of code, and keeping rich data (dates should be
>>> dates, not strings)."
>>>
>>
>> I like the idea of having various encodings for different uses, but we
>> should strife towards compatibility.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 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/to
>> pic/clojure/Rc_b4_Da-KU/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, 

Re: Frustrations so far

[Stuart Halloway]

Hi Peter,

The latest release of Datomic (0.9.5390) includes the addition of the Log
API for memory-backed databases.
https://groups.google.com/d/topic/datomic/QLdZ_WePR5A/discussion.

Hope this and some of other items on this thread will combine to improve
your experience with Clojure.

Regards,
Stu

On Wed, Jul 20, 2016 at 8:49 AM, Peter Romfeld 
wrote:

> I really love clojure over all, it makes maintenance/collaboration of code
> such a breeze. its easy to get new employees start to work on it even
> without any previous clojure knowledge!
>
> I do hate the JVM startup shit, i hate how you it takes forever to fetch
> deps on a aws medium instance (you probably can fix it with uberjars)
> Im frustrated with `empty?` throwing exceptions for Long and Keyword
> Not complete clojure, but i hate datomic.api/log since you cant put into
> your tests with a in-mem db
> I had some issues understanding that maps of certain size are not in order
> anymore because of the underlying java functions and optimizations
> Im a bit upset about development reload with defrecords
> most of the things that are not documented by the community are documented
> very cryptic and hard to understand
> the api docs are almost useless! - to get the arrity and stuff.. wtf i
> still have no clue how to use this new function i never used before...
> security features in most frameworks are just smoke and mirrors, functions
> that dont actually do what they should do...
>
> anyways, if i remember more i can add...
> just wanted to give you guys some input, and looking forward to make
> development experience even better!
>
> cheers,
> peter
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Clojure spec screencast: Testing

[Stuart Halloway]

Yes.  Short answer: Make a model of the input space. Coming in a future
screencast. :-)

Stu

On Wed, Jul 27, 2016 at 2:13 PM, Beau Fabry  wrote:

> With the passing test of `my-index-of`, is there any way to be confident
> that test.check generated inputs that checked the branch of the :fn spec
> where a return other than nil happened? All of the invocations of
> `exercise-fn` in the screencast only managed to get nil as a result.
>
>
> On Wednesday, July 27, 2016 at 9:22:27 AM UTC-7, Alex Miller wrote:
>>
>> Check out the 2nd screencast about spec, this time on testing with check
>> and instrument:
>>
>> http://blog.cognitect.com/blog/2016/7/26/clojure-spec-screencast-testing
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[ANN] Clojure 1.9.0-alpha4

[Stuart Halloway]

Clojure 1.9.0-alpha4 is now available.

Try it via

- Download: https://repo1.maven.org/maven3/org/clojure/clojure/1.9.0-alpha4
- Leiningen: [org.clojure/clojure "1.9.0-alpha4"]

1.9.0-alpha4 includes the following changes since 1.9.0-alpha3:

- fix describe empty cat
- improve update-in perf
- optimize seq (&) destructuring

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

[Stuart Halloway]

Everyone: let's keep the tone civil.  

Andrey: thanks for your workflow suggestions.  I politely re-decline all of 
them, having considered all your points multiple times over several years and 
having chosen approaches that I believe are better matched with my objectives.

The objective of Clojure contributions is Clojure, not contribution.  The proof 
is in the pudding.

Sent from my iPad

 On Jul 18, 2015, at 1:32 PM, Andrey Antukh n...@niwi.nz wrote:
 
 
 
 On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine 
 lprefonta...@softaddicts.ca wrote:
 Aaah ! The pull request looms again :)
 
 A bug tracking system is essentialy to coordinate efforts, pull request are 
 not a mechanism to track fixes/improvements and discuss about
 them. That may work for a very small team. The # of clojure contributors far 
 excess that size.
 
 
  
 
 Pull requests/gitbhub issues are used by Clojure library maintainers outside 
 of the core,
  their respective contributor team size makes this usable.
 
 Choosing one tracking system is a feat by itself, Jira does everything 
 albeit it may be a beast to configure.
 I think that the choice of Jira predates moving the Clojure code from google 
 to github but I may be wrong.
 The github tracking system was not at par with Jira features at that time 
 anyway.
 
 Once that choice is done, moving out to something else requires a 
 significant effort, you need to pull all this history you built about
 your software into your new bug tracking solution. You can't loose this, 
 it's your software collective memory.
 
 All this discussion around pull request IMO is more an expression of human 
 lazyness. Having to document is always seen as a
 chore by most developpers. ‎This is not an arcane human trait, it has been 
 known for decades.
 
 Anything else requires a discussion forum if you want to maintain a minimal 
 level of quality and allow some discussions around the issue being fixed
 in a large team effort/critical piece of software. A mailing list is not at 
 par with a bug tracking system in this regard.
 
 Curiously, linux has a bug tracking system and people submit patches or 
 links are made to patches.
 Take a walk on launchpad.
 
 No serious software business would drive their dev without a tracking 
 system. Open source projects are no
 different if they want to attain some level of success. If critical open 
 source is to be used by businesses, it has to
 play with similar tools. Clojure too me is critical to my business and to 
 many others. It cannot fail on us.
 It would be like building pyramids on moving sand.
 
 Again there's no Kumbaya song playing here.
 
 As a last note, Alex Miller must dream about the emails exchanged on the 
 mailing list.
 Suggestions are certainly looked upon and discussed upstream. It does not 
 mean that they will be considered
 worth to investigate/implement or they may come out differently (that ego 
 thing looming again).
 
 +1 for Jira and patches.
 
 The django community works with both tools. Pull request are just for code 
 review and patch attachment mechanism, and bug tracking system for coordinate 
 the efforts. Both them are not incompatible. 
 And django core team is not precisely small.
 
 The Pull-Request is not about laziness, is about eliminate friction. And 
 allow better and more human friendly code review
 process.
 
 I'm only try improve the contribution process and IMHO your tone is a little 
 bit out of place.
 
 
 Luc P.
 
 
 
 On Sat, 18 Jul 2015 19:05:16 +0300
 Andrey Antukh n...@niwi.nz wrote:
 
  On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com
  wrote:
 
   +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since
   when did software design by committee work; anyone remember J2EE?
   (and yes, that does deserve my mocking tone).
  
   I have no idea about the details being discussed here/why people’s
   noses are out of joint, but I can think of as many success with a
   single overlord in place as there are failures caused by political
   infighting.
  
 
  In general, I'm pretty happy with the benevolent dictator approach.
  But some openness would be awesome. As first think that comes in my
  mind is: have a clear roadmap for Clojure and its core libraries such
  as core.async.
 
  Some channel for requesting features, and the ability to know a
  opinion of the clojure core team about the possibility of the
  inclusion of some requested feature.
 
  Also would be awesome have more painless contribution process. I'm ok
  for signing CA, but using patches instead of something like pull
  requests (with or without additional review tool) is very arcane and
  uncomfortable process.
 
  I don't suggest to change to something similar to design by
  committee. I only suggest that make some facilities for contribute
  may attract more interesting people. And will make more happy
  excellent contributors like Zach Tellman or Aphyr.
 
  I think that things like this are not very complicated 

Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code

[Stuart Halloway]

Thanks Colin, that is exactly it.


On Thu, Jul 2, 2015 at 2:27 AM, Colin Fleming colin.mailingl...@gmail.com
wrote:

 I may be putting words in Stuart's mouth here, but what I believe he meant
 is that it would be great if Yagni were just a Clojure library with a
 function you could call passing it everything it needs (probably source
 paths and entry point details), and ideally returning the results as data.
 Then the lein plugin could just call that function and print the results,
 but other tooling which might not use lein could also take advantage of
 Yagni.

 Great work BTW, Yagni looks very cool. I'm planning to implement something
 similar in Cursive but I'll be using the IntelliJ infrastructure to do it.
 The idea is the same, though.

 On 2 July 2015 at 06:31, W. David Jarvis venant...@gmail.com wrote:

 Hey Stuart -

 Could you clarify what you meant your comment? I'm not sure I understand
 what you mean by a pure function in this context.

  - David

 On Tue, Jun 30, 2015 at 8:10 AM, Stuart Halloway 
 stuart.hallo...@gmail.com wrote:

 Nice.

 It would be really cool if run-yagni was a pure function of source-paths
 and mains.  This would make the dependency on lein optional and allow
 adoption on e.g. mainland Java projects.

 Stu

 On Tue, Jun 30, 2015 at 5:44 AM, Yehonathan Sharvit vie...@gmail.com
 wrote:

 Yagni ignore `cljs` files.

 I have opened an issue here:
 https://github.com/venantius/yagni/issues/26




 On Thu, Jun 25, 2015 at 1:53 AM, W. David Jarvis venant...@gmail.com
 wrote:

 Indeed. I'd argue it's better not to have unused code in the codebase
 in the first place, regardless of what the Closure compiler does to help
 when it comes to compiling assets.

 I haven't tested this with cljs projects, but on the face of it I
 don't see why Yagni's methodology wouldn't work. If you get a chance to
 give it a try I'd love the feedback :)

 On Wednesday, June 24, 2015 at 2:58:14 PM UTC-7, juan.facorro wrote:

 That's a good point.

 On Wednesday, June 24, 2015 at 6:53:43 PM UTC-3, Fluid Dynamics wrote:

  FMIIW, but I think they serve orthogonal purposes. Google Closure
 finds code (mostly library parts your program doesn't use) that your
 particular program doesn't need and omits it from the build to save disk
 and bandwidth. Yagni finds obsolete code that is no longer reached in 
 your
 program or from *any* public entry point to your library (whether a
 particular program uses that entry point or not) and issues warnings, so
 you know that either something is maintenance deadweight or you have a 
 bug
 because you *meant* to call it somewhere but forgot, or it's become
 accidentally shadowed or something.

   --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient
 with your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 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/fGhjG70w0_U/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.


  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 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/fGhjG70w0_U/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

Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code

[Stuart Halloway]

Nice.

It would be really cool if run-yagni was a pure function of source-paths
and mains.  This would make the dependency on lein optional and allow
adoption on e.g. mainland Java projects.

Stu

On Tue, Jun 30, 2015 at 5:44 AM, Yehonathan Sharvit vie...@gmail.com
wrote:

 Yagni ignore `cljs` files.

 I have opened an issue here: https://github.com/venantius/yagni/issues/26




 On Thu, Jun 25, 2015 at 1:53 AM, W. David Jarvis venant...@gmail.com
 wrote:

 Indeed. I'd argue it's better not to have unused code in the codebase in
 the first place, regardless of what the Closure compiler does to help when
 it comes to compiling assets.

 I haven't tested this with cljs projects, but on the face of it I don't
 see why Yagni's methodology wouldn't work. If you get a chance to give it a
 try I'd love the feedback :)

 On Wednesday, June 24, 2015 at 2:58:14 PM UTC-7, juan.facorro wrote:

 That's a good point.

 On Wednesday, June 24, 2015 at 6:53:43 PM UTC-3, Fluid Dynamics wrote:

  FMIIW, but I think they serve orthogonal purposes. Google Closure
 finds code (mostly library parts your program doesn't use) that your
 particular program doesn't need and omits it from the build to save disk
 and bandwidth. Yagni finds obsolete code that is no longer reached in your
 program or from *any* public entry point to your library (whether a
 particular program uses that entry point or not) and issues warnings, so
 you know that either something is maintenance deadweight or you have a bug
 because you *meant* to call it somewhere but forgot, or it's become
 accidentally shadowed or something.

   --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 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/fGhjG70w0_U/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.


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

[Stuart Halloway]

A man walks into a bar and says I used lazy evaluation and things were
confusing. Bartender says You mixed it with I/O without bothering to
look at the code.  :-)

Your experiment uses pr-str, which uses a dynamically scoped resource *out*
in order to create its result.  Your observation uses println, which uses
the same dynamically scoped resource.  Mix in different evaluation
strategies, and races can lead to different outcomes. Here is a much
smaller example:

(pr-str [1 2])
(pr-str (map #(doto % println) [1 2]))

So this result is expected.  Beware I/O, and in the presence of I/O be very
careful in concluding that something is a value.  Your quoted-pr-str is not
a pure function, and so it does not make values.

Regards,
Stu


On Sat, Sep 13, 2014 at 4:41 AM, cees van Kemenade 
cees.van.kemen...@gmail.com wrote:


 By watching (println) the experiment we influence the outcome.
 Is the Schrodinger's cat present in Clojure?

 This example program that shows how printing a value can change the value
 under
 specific circumstances. It seems the case that it has to do with the lazy
 evaluation
 that happen in Clojure. Basically I map a pr-str over a list. When I print
 the list
 before realization it seems that println is modifies the value.
 Doing a doall or turning the lazy-list into a vector makes the circumvents
 the issue.

 The code showing this behavior is is attached. Loading the file will show
 the issue.
 I've tested it in Clojure 1.5.1, Clojure 1.6.0.
 I also tested it in Clojure-clr 1.5.0, and observed the same issue.

 Please let me know whether this is expected behavior, a known issue, or a
 new one.

 Cees.

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

time sensitive: need a Clojure rep for JavaOne Script Bowl

[Stuart Halloway]

Hi Clojurians,

I need to get someone to represent Clojure for this year's ScriptBowl at
JavaOne, which will be in San Francisco Wednesday, Oct 1, 1:00 PM - 2:00 PM
- Hilton - Continental Ballroom 7/8/9.

If you haven't heard of this before, it is basically a demo contest, with
reps from Scala, Groovy, JRuby, and Nashorn also present.  You do not need
much material--last year the slots were seven minutes long, with a little
more time later to respond to the other demos.

The conference does not cover travel, but you will get a pass to attend the
other sessions.

Overtone has *not* been used as a demo in previous years, so that might be
a good way to rock the house.

If you are interested, please ping me off-list.

Thanks!
Stu

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

Re: [ANN] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Stuart Halloway]

Hi Jony,

Is there a path for using Gorilla REPL from a maven or gradle project?

Thanks,
Stu


On Mon, Sep 1, 2014 at 7:11 AM, Jony Hudson jonyepsi...@gmail.com wrote:

 Hi all,

  there's a new version of Gorilla REPL out :-) The headline feature is
 that the autocomplete UI now shows the docs for the function you're
 typing/lets you browse the docs. It's really handy! Autocomplete itself is
 also much improved, courtesy of the compliment library.

 This version also adds compatibility with the latest version of CIDER, and
 a number of other smaller fixes and features (see changelog below).

 I must give credit here to the CIDER team, who have done a great job of
 writing CIDER's back-end code in a way that it can be re-used by other
 editors. It must have taken some work to do that, and it's a very useful
 contribution to Clojure tooling. Gorilla now uses CIDER's back-end for
 autocompletion and documentation. Hats off to them!

 From the changelog:

 ## Version 0.3.3

 - Look up symbol in ClojureDocs.
 - Inline documentation in auto-complete.
 - Much better auto-complete, thanks to compliment and cider-nrepl.
 - Autoselects a free port by default.
 - Upgrade to CodeMirror 4.5.
 - Interoperable with Emacs/CIDER  v.0.7.0 i.e. auto-adds cider-nrepl
 middleware.
 - Hopefully fix an odd intermittent dependency bug (thanks to @jococo).
 - App routes now a var for easier hacking on the server (thanks to
 @ticking).
 - Write out web-app port to file on startup to enable other tools to
 interoperate.
 - Fix version range warning.



 Jony

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


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

Re: [ANN] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Stuart Halloway]

Hi Jony,

A feature allowing connection to an external nREPL server would be great,
and totally usable by anyone who can make a CLASSPATH.  Having to install a
particular build system (whether gradle, lein, or maven) in order to use a
tool is a non-starter for 90% of the projects I am involved with.

Regards,
Stu


On Mon, Sep 1, 2014 at 12:55 PM, Jony Hudson jonyepsi...@gmail.com wrote:

 Beau, Lee - thanks for the kind words - glad you're enjoying it!

 Stu - I've no experience of running Clojure under either maven or gradle,
 but my guess is that it won't work out-of-the-box yet. Currently, Gorilla
 launches by using Leiningen to run its own server process in the classpath
 of the project. The Gorilla server starts up an nREPL server in process and
 connects to that. I've been planning to add the feature to connect to an
 external nREPL server (and also, probably, for local connections to
 launch the nREPL server as a separate process). It would then be
 straightforward, I'd imagine, to run an nREPL server from maven/gradle -
 which would take care of the classpath - and have maven/gradle start up the
 gorilla server and connect to nREPL.

 I guess a workaroundy way to do it would be if maven/gradle can output the
 classpath for a project, then it might possibly work to run the Gorilla jar
 with the appropriate classpath. I'm not sure about this though as, in
 truth, I don't know exactly what nREPL does when it starts up!


 Jony


 On Monday, 1 September 2014 17:33:50 UTC+1, stuart@gmail.com wrote:

 Hi Jony,

 Is there a path for using Gorilla REPL from a maven or gradle project?

 Thanks,
 Stu


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


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

Re: [ANN] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Stuart Halloway]

And now, answering part of my own question.  It appears the following
almost just works from a maven project that references gorilla:

  (require '[gorilla-repl.core :as gorilla])
  (gorilla/run-gorilla-server {:port 8990})

The only problem is that gorilla's declaration of its own dependencies
appears incomplete.  When I try to run the snippet above, I fail for lack
of org.clojure/tools.nrepl and clojure-complete.  Adding them as explicit
dependencies in my own project fixes the problem.  My quick guess is that
these two libs need to be added to gorilla's own dependencies.  (One
wonders why it works inside of lein...)

Stu



On Mon, Sep 1, 2014 at 12:55 PM, Jony Hudson jonyepsi...@gmail.com wrote:

 Beau, Lee - thanks for the kind words - glad you're enjoying it!

 Stu - I've no experience of running Clojure under either maven or gradle,
 but my guess is that it won't work out-of-the-box yet. Currently, Gorilla
 launches by using Leiningen to run its own server process in the classpath
 of the project. The Gorilla server starts up an nREPL server in process and
 connects to that. I've been planning to add the feature to connect to an
 external nREPL server (and also, probably, for local connections to
 launch the nREPL server as a separate process). It would then be
 straightforward, I'd imagine, to run an nREPL server from maven/gradle -
 which would take care of the classpath - and have maven/gradle start up the
 gorilla server and connect to nREPL.

 I guess a workaroundy way to do it would be if maven/gradle can output the
 classpath for a project, then it might possibly work to run the Gorilla jar
 with the appropriate classpath. I'm not sure about this though as, in
 truth, I don't know exactly what nREPL does when it starts up!


 Jony


 On Monday, 1 September 2014 17:33:50 UTC+1, stuart@gmail.com wrote:

 Hi Jony,

 Is there a path for using Gorilla REPL from a maven or gradle project?

 Thanks,
 Stu


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


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

Re: [ANN] Gorilla REPL 0.3.3 - inline docs, CIDER compatibility

[Stuart Halloway]

Hi Jony,

I sent you a pull request.  I believe adding those items is correct and
necessary for producing a usable JAR, and that the build works so long as
you have a recent version of leiningen.

Stu


On Mon, Sep 1, 2014 at 5:04 PM, Jony Hudson jonyepsi...@gmail.com wrote:

 Ahh, nice, yes that's a simple way to do it if you can manage to add the
 code somewhere.

 Regarding the dependencies - Leiningen adds both of the dependencies you
 list. I did declare them explicitly at one point, but I recall having some
 odd error, so I decided to take them back out rather than debug it! It's
 possibly related to this, but like I say I didn't put any time into
 investigating it, so could be a red herring:
 https://github.com/technomancy/leiningen/issues/1569


 Jony


 On Monday, 1 September 2014 21:57:07 UTC+1, stuart@gmail.com wrote:

 And now, answering part of my own question.  It appears the following
 almost just works from a maven project that references gorilla:

   (require '[gorilla-repl.core :as gorilla])
   (gorilla/run-gorilla-server {:port 8990})

 The only problem is that gorilla's declaration of its own dependencies
 appears incomplete.  When I try to run the snippet above, I fail for lack
 of org.clojure/tools.nrepl and clojure-complete.  Adding them as explicit
 dependencies in my own project fixes the problem.  My quick guess is that
 these two libs need to be added to gorilla's own dependencies.  (One
 wonders why it works inside of lein...)

 Stu

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

Clojure in financial services

[Stuart Halloway]

Many companies are using Clojure in financial services.  Some of these are
easily visible on the web, and I am aware of many more through
private/NDAed conversations.

I am working to gather experience reports, which I will then compile and
share on the web.  If you have experiences using Clojure in financial
services, and are able to share them (either by name or anonymously),
please let me know.  On-list or off-list is fine.

Thanks!
Stu Halloway
Cognitect

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

[Stuart Halloway]

;; I think this shed should be painted red
(def immutable-string
  foo)

(def ^java.lang.reflect.Field value-field
  (doto (.getDeclaredField String value)
(.setAccessible true)))

(aset (.get value-field immutable-string) 1 \i)
(aset (.get value-field immutable-string) 2 \e)

(println immutable-string)



On Wed, May 7, 2014 at 11:15 AM, Mike Fikes mikefi...@me.com wrote:

 I would offer that the key distinction is whether final is used: This
 prescribes what you must do when using the object.

 Take Date for example. You can't just pass one directly from one thread
 to another. The receiving thread could read a date associated with
 System.currentTimeMillis() of 0.

 But, String, since it uses final on its char[], fundamentally changes
 this. (If the final keyword were not present in String, even though you
 have no way to change its char[], it would be broken with respect to
 threading semantics.)

 On Wednesday, May 7, 2014 10:35:04 AM UTC-4, Andy Fingerhut wrote:

 Sorry if I'm beating a dead horse here.

 I agree that my example is not using published Clojure APIs, and I never
 do that kind of thing in a Clojure program, except as an example that
 PersistentVector's are mutable if you use Java APIs instead of restricting
 yourself to Clojure APIs.  You don't even need to use reflection in Java or
 know about JVM security policies to mutate them (I am not suggesting that
 Clojure should be changed in any way here).

 I've actually got a copy of Java: Concurrency in Practice, and looked up
 (some of) what they say about immutability.  Here is one definition they
 give of immutability, with some preceding text.  I have added emphasis to
 one phrase:

 Neither the Java Language Specification nor the Java Memory Model
 formally defines immutability, but __immutability is *not* equivalent to
 simply declaring all fields of an object 'final'__.  An object whose fields
 are all final may still be mutable, since final fields can hold references
 to mutable objects.

 An object is *immutable* if:
 + Its state cannot be modified after construction;
 + All its fields are 'final'; and
 + It is *properly constructed* (the 'this' reference does not escape
 during construction).

 I have no argument with PersistentVector satisfying the 2nd and 3rd
 bullet points above, but (1) seems not to hold.  According to JCIP's
 definition of effectively immutable (Objects that are not technically
 immutable, but whose state will not be modified after publication),
 PersistentVector appears to me to be effectively immutable, but not truly
 immutable.

 Andy


 On Tue, May 6, 2014 at 8:31 PM, Alex Miller al...@puredanger.com wrote:

 Hey Andy,

 It does matter with regard to visibility across threads - your example
 does not use a synchronization mechanism and there is no guarantee that
 other threads will ever see those changes (so don't ever ever do that :).
 But if you stick to the normal Clojure apis, all is good. I'd highly
 recommend reading JCIP to dive into the details.

 Final field freeze is particularly weird and it baked my noodle when I
 first encountered it - here's a blog I wrote about it approx 697 years ago
 in internet time (and Brian Goetz backs me up in the comments :)
 http://tech.puredanger.com/2008/11/26/jmm-and-final-field-freeze/

 Alex


 On Tuesday, May 6, 2014 7:35:43 PM UTC-5, Andy Fingerhut wrote:

 Alex, I may be unfamiliar with the definitions of truly immutable and
 effectively immutable being used here, but if I can mutate the contents of
 a Java Object array that is a final field after an object is constructed,
 does it really matter that much if it is final?  It is trivially easy to
 mutate using Java access.  Here is the example that I mentioned earlier in
 this thread, copied here for convenience:

 user= (def v [1 2 3])
 #'user/v
 user= (class v)
 clojure.lang.PersistentVector
 user= v
 [1 2 3]
 user= (aset (.tail v) 1 -2)
 -2
 user= v
 [1 -2 3]

 Andy


 On Tue, May 6, 2014 at 4:49 PM, Alex Miller al...@puredanger.comwrote:

  The Clojure persistent data structures are truly immutable - all
 fields are final and referred objects are not mutated after construction 
 so
 that freeze occurs.  One obvious exception are the transient variants (
 http://clojure.org/transients). You can look at the code in
 https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang -
 any of the Persistent*.java.


 On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:

 Are the persistent immutable data structures in Clojure truly
 immutable (using final fields, relying on constructor freezing), or are
 they mean to be merely effectively immutable (as defined in JICP)?

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

Re: Any experience with Cognitect?

[Stuart Halloway]

Applying too early will never hurt you, so long as you are candid about
where you are and where you want to be.  It took me three rounds of
rejection+feedback to land my first high-profile tech job.

The contracting relationship is designed to handle high variability.  You
might get lucky and see exactly the stream of work on the schedule you
want, or pretty much the opposite can happen.

Stu
President, Cognitect


On Tue, Apr 8, 2014 at 12:56 PM, Mike Haney txmikes...@gmail.com wrote:

 Cognitect (and previously Relevance) always seem to have openings for
 contract Clojure developers.  I was wondering if anyone here has applied
 for and/or actually been hired for one of these positions, and was willing
 to share their experience?

 I have thought about the possibility of being a contractor for Cognitect
 for awhile, and it's been pretty much my target goal as I've been learning
 Clojure/Datomic over the last 8-9 months.  The bar seems pretty high - I
 mean, do you have to be a Mike Fogus or Tim Baldridge to work there?

 My current contract is winding up soon, and my Clojure skills are at the
 point where I think I am almost productive enough to use it professionally
 (IMO you have to actually USE something professionally to reach that last
 level of productivity, which is why I said almost).  This would be an ideal
 time to make the switch, but I don't want to apply too soon and ruin my
 chances.

 One other question - for anyone who has worked as a contractor for them,
 was there usually/always enough work to keep you busy full time, or would I
 need to plan on doing other freelance work to fill in the gaps between
 assignments for them?

 TIA for any advice.



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


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

Re: Is Clojure right for me?

[Stuart Halloway]

Yes, thanks Mark. It seems to me that you are saying namespaces make poor
maps.  Stipulated.  So why not use records or maps?

I think that where my experience differs from yours is summarized in your
comment In Clojure, a project often begins with a bunch of functions
sharing some immutable state or magic constants stored in vars. I
*never* do that.  If there are a group of related things, I put them in an
associative container (maybe just a map) on day one.

The analogy with OO is misleading here.  If you started an OO project
putting everything in static/singleton members, you would have the same
pain you attribute to Clojure's namespaces.

I find this to be a my car doesn't have wings argument, and the kind of
thing that leads into casually complecting everything with everything else.

Stu




On Thu, Dec 26, 2013 at 10:04 PM, Mark Engelberg
mark.engelb...@gmail.comwrote:

 Does this OO pseudocode help clarify at all?
 https://gist.github.com/Engelberg/8142000

 On Thu, Dec 26, 2013 at 6:27 PM, Stuart Halloway 
 stuart.hallo...@gmail.com wrote:

 Hi Mark,

 I am not following your example.  Can you post (pseudocode fine) what a
 good OO impl would look like, and why Clojure's defrecords can't do
 something similar?

 Stu

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

[Stuart Halloway]

Hi Mark,

I am not following your example.  Can you post (pseudocode fine) what a
good OO impl would look like, and why Clojure's defrecords can't do
something similar?

Stu



On Thu, Dec 26, 2013 at 9:08 PM, Mark Engelberg mark.engelb...@gmail.comwrote:

 I do like the way Clojure steers you away from all sorts of unnecessary
 OO-nonsense, and provides most of the raw capabilities of OO in other forms.

 However, even if you avoid mutable state, inheritance, and polymorphism,
 Classes/objects make great namespaces, and Clojure's namespaces can't do
 everything classes can do, for example, cyclic dependencies.  This was the
 subject of my blog post yesterday.  Take a look at the following gist code
 for one of the scenarios that frequently drives me up a wall:

 https://gist.github.com/Engelberg/8141352

 I'd love to hear any tricks you guys use to deal with situations like this
 in your own code.

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

[Stuart Halloway]

Hi Dave,

You can use reduce for this job, and have the reducing function return a
(reduced retval) when you want to break out.

Cheers,
Stu


On Sun, Nov 24, 2013 at 11:19 AM, David Simmons shortlypor...@gmail.comwrote:

 Hi All.

 Still struggling to get my head around Clojure - this is attempt number 4.

 I wish to process each item in a vector. I know I can use map to do this
 e.g. (map my-func my-vector). My problem is that I need to be able to break
 out of the map if my-func returns an error when processing any of the
 items. I know map isn't what I'm looking for but is there a function or
 some idiomatic piece of clojure to achieve my aim.

 cheers

 Dave

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

[Stuart Halloway]

data.fressian [1] is a Clojure-language wrapper for the reference
implementation [2] of Fressian.  I am still setting up CI, maven release,
etc. but wanted to get the source up so that interested parties can peruse
and contribute.

The wiki at [2] is currently the best source of documentation.

Cheers,
Stu

[1] https://github.com/clojure/data.fressian
[2] https://github.com/Datomic/fressian/wiki

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

Re: Do (should?) these core.async utilities exist?

[Stuart Halloway]

Hi Paul,

Two different reasons:  The channel-to-sequence conversion seems like a
questionable idea, making seqs that block.  The doseq over a channel is
easily enough implemented, and was not considered important enough to be on
the core API.

Stu


On Tue, Nov 12, 2013 at 4:48 AM, Paul Butcher p...@paulbutcher.com wrote:

 I've been playing with core.async, and have come across a couple of things
 that it seemed would probably be common use cases, but can't find anything
 in the library that addresses them.

 I'd be grateful for pointers if any of these do exist and I'm just missing
 them, or suggestions for reasons why I don't really want them and should be
 tackling the problem in a different way:


- A way to convert a channel to a lazy sequence (i.e. build the
sequence by repeatedly reading from a channel until it's closed). It seems
odd that core.async provides a means to turn a lazy sequence into a channel
(to-chan) but not the inverse?
- An equivalent of doseq for a channel, which repeatedly reads from
the channel and calls its body with the result of doing so, terminating
when the channel is closed.


 Of course, both of these are easy enough to write, but I'm wondering
 whether the fact that they aren't provided as standard is telling me
 something?

 --
 paul.butcher-msgCount++

 Silverstone, Brands Hatch, Donington Park...
 Who says I have a one track mind?

 http://www.paulbutcher.com/
 LinkedIn: http://www.linkedin.com/in/paulbutcher
 Skype: paulrabutcher




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

[Stuart Halloway]

To save others from having to read this whole thread, is the following
summary correct?

1. We believe that the performance issue Paul first encountered is
substantially / entirely caused by hash collisions.

2. The hash collisions could be improved by spreading the hashes of numbers
(and not needing to mess with hashes of collections).

If the above summary is correct, then I have the following questions:

a. Is the approach Scala took substantially #2 above, or something
different / more?

b. Is changing the hash codes of numbers going to break expectations on the
Java side of things?


On Thu, Oct 24, 2013 at 8:37 PM, Evan Gamble solar.f...@gmail.com wrote:

 As Andy Fingerhut pointed out, since (hash [a b]) is 31*(a + 30) + (b +
 31) when a and b are ints, summing the hashes of 2-tuples when the values
 are small ints, as happens when hashing sets of such 2-tuples, is quite
 likely to lead to collisions. This particular problem could be avoided by
 spreading the hashes of ints out to large numbers with a non-linear
 function, not just multiplying them all by some N.


 On Wednesday, October 23, 2013 5:41:15 PM UTC-7, puzzler wrote:

 Perhaps I don't understand your point, but vector hashing is not
 currently the sum of hashes.  It's a more complex computation.

 = (hash [0 2])
 963
 = (hash [2 0])
 1023
 = (hash [2])
 33

 The fact that numbers hash to themselves means that the resulting hashes
 are not hugely spread apart, but collisions don't seem to be as common as
 with sets and maps.  I'm sure it could be improved, but vector/sequence
 hashing doesn't strike me as a huge issue.


 On Wed, Oct 23, 2013 at 5:31 PM, Cedric Greevey cgre...@gmail.comwrote:

 There's still a problem with collisions among *vectors* though.

 I'd say the real underlying problem is that small integers hash to
 themselves. If you let N be a fairly large number satisfying GCD(N, 2^32 -
 1) = 1, then multiplying 32-bit integers by N would send nearby integers to
 widely separated ones, while inducing a permutation on nonzero integers --
 the hash space wouldn't be any smaller. That alone won't help much with the
 vector problem, since 3N + 2N = 5N just as 3 + 2 = 5, though it may help
 avoid collisions with small integers in small hash maps when the hash is
 being used modulo a small hash-table length. What might help with vectors,
 sets, and other small data structures containing integers (but would shrink
 the hash space by about half) is to additionally square the result (all
 operations being 2s-complement 32-bit integer operations with wrapping --
 Java int arithmetic). Now 1 and 4 won't give the same summed hashes as 3
 and 2, and 0 and 5 will be different again. You might also want to add some
 constant to avoid 0 hashing to 0.

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

[Stuart Halloway]

Is the Scala for lazy or eager?  If the latter, you are not comparing
apples to apples (separate from the other differences David already pointed
out.)

Stu


On Wed, Oct 23, 2013 at 8:41 PM, Mark Engelberg mark.engelb...@gmail.comwrote:

 Perhaps I don't understand your point, but vector hashing is not currently
 the sum of hashes.  It's a more complex computation.

 = (hash [0 2])
 963
 = (hash [2 0])
 1023
 = (hash [2])
 33

 The fact that numbers hash to themselves means that the resulting hashes
 are not hugely spread apart, but collisions don't seem to be as common as
 with sets and maps.  I'm sure it could be improved, but vector/sequence
 hashing doesn't strike me as a huge issue.



 On Wed, Oct 23, 2013 at 5:31 PM, Cedric Greevey cgree...@gmail.comwrote:

 There's still a problem with collisions among *vectors* though.

 I'd say the real underlying problem is that small integers hash to
 themselves. If you let N be a fairly large number satisfying GCD(N, 2^32 -
 1) = 1, then multiplying 32-bit integers by N would send nearby integers to
 widely separated ones, while inducing a permutation on nonzero integers --
 the hash space wouldn't be any smaller. That alone won't help much with the
 vector problem, since 3N + 2N = 5N just as 3 + 2 = 5, though it may help
 avoid collisions with small integers in small hash maps when the hash is
 being used modulo a small hash-table length. What might help with vectors,
 sets, and other small data structures containing integers (but would shrink
 the hash space by about half) is to additionally square the result (all
 operations being 2s-complement 32-bit integer operations with wrapping --
 Java int arithmetic). Now 1 and 4 won't give the same summed hashes as 3
 and 2, and 0 and 5 will be different again. You might also want to add some
 constant to avoid 0 hashing to 0.

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

[Stuart Halloway]

Hi splondike,

I disagree with your arguments about what is sensible -- *any* behavior is
sensible when you violate the contract of an API.

Of course everybody could get behind the throwing the error plan if the
cost of throwing that error was zero:  zero assessment cost, zero
development cost, zero runtime cost, and zero maintenance cost.  But those
costs are not zero, so as a screener I have to ask myself should I spend
my next half hour looking at this issue, which impacts only broken
programs, or one of the (currently 20) screenable tickets, many of which
impact *correct* programs?

That said, perhaps core.typed can help us here.  I believe core.typed can
allow us to check programs and detect these kinds of errors, without
runtime impact (and without any change to Clojure at all.)  I am doing some
experiments with exactly this case, and will follow up on a separate thread.

Regards,
Stu


On Mon, Sep 30, 2013 at 2:20 PM, splondike splond...@gmail.com wrote:

 Thanks for the comment. The current behaviour is sensible for the code
 branch where the second argument is the same length or shorter than the
 first (see my first post). It is the other branch that does not do what you
 would expect. My real issue though is how the behaviour changes
 dramatically once we hit this branch (for non set args).

 The original author of the 
 patchhttps://github.com/clojure/clojure/commit/60e805dc7bd42b7b26fc8c8925bf71079729e0e6which
  produced this behaviour noted
 this shortcoming himself http://dev.clojure.org/jira/browse/CLJ-67, and
 only refrained from implementing the check due to being unsure about the
 performance penalty.

 I think that people who are currently relying on this function working for
 non set arguments are playing a risky game (which, like me, they're
 probably not aware of) due to this sudden change in behaviour. I would
 argue that existing users would be better served by having an error thrown
 rather than having unexpected data generated which is hard to track down.

 On Sunday, September 29, 2013 7:05:17 PM UTC-4, stuart@gmail.comwrote:

 I think the bar for such an enhancement is fairly high, and the value
 delivered fairly low.  It isn't so much the impact of assessing this single
 change, as the impact of managing the universe of such changes.

 Regards,
 Stu

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

type checking clojure.set with core.typed

[Stuart Halloway]

I tried the following experiment with type checking clojure.set:

(ns exploring.core-typed
  (:use clojure.core.typed clojure.repl)
  (:require [clojure.set :as set]))

(ann ^:no-check clojure.set/difference [(Set Any) (Set Any) - (Set Any)])

(set/difference #{1 2} [1 2])

(comment
  (check-ns)
  )

Is there an extant example that shows how this kind of safety check might
be used in e.g. a CI build?

Stu

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

[Stuart Halloway]

Any experience reports?  My experience so far:

Type Checker: Found 1 error
$ echo $?
0




On Mon, Sep 30, 2013 at 7:20 PM, Ben Mabey b...@benmabey.com wrote:

 On 9/30/13 5:16 PM, Stuart Halloway wrote:

 I tried the following experiment with type checking clojure.set:

 (ns exploring.core-typed
   (:use clojure.core.typed clojure.repl)
   (:require [clojure.set :as set]))

 (ann ^:no-check clojure.set/difference [(Set Any) (Set Any) - (Set Any)])

 (set/difference #{1 2} [1 2])

 (comment
   (check-ns)
   )

 Is there an extant example that shows how this kind of safety check might
 be used in e.g. a CI build?

 Stu

  Seems like an invocation of `lein typed check`[1] would do the trick in
 a CI build...

 -Ben

 1. 
 https://github.com/frenchy64/**lein-typedhttps://github.com/frenchy64/lein-typed

 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
 --- You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to 
 clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://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: Parallelising over a lazy sequence - request for help

[Stuart Halloway]

To be clear, I don't object to the approach, only to naming it fold
and/or tying it to interfaces related to folding.

Stu


On Sat, Sep 28, 2013 at 5:29 PM, Paul Butcher p...@paulbutcher.com wrote:

 On 28 Sep 2013, at 22:00, Alex Miller a...@puredanger.com wrote:

 Reducers (and fork/join in general) are best suited for fine-grained
 computational parallelism on in-memory data. The problem in question
 involves processing more data than will fit in memory.

 So the question is then what is the best way to parallelize computation
 over the stream. There are many ways to do so - pmap is one easy mechanism
 to get parallelism over a lazy sequence but the chunking behavior of pmap
 can easily be non-optimal for particular use cases. Stu's other solution
 (prepare-with-partition-then-fold) reads chunks of data into memory, then
 uses f/j over the top of those chunks.


 Yes - I'm aware that that's how Stu's solution works. However when I use
 that in my example, the performance sucks. As I said in my earlier message,
 I believe that the reason for this is the additional copying that it
 involves.

 To date, I have exactly one implementation that has good parallel
 performance - the one that uses foldable-seq (which is 3x faster than the
 sequential version). Everything else I've tried performs worse than the
 sequential version.

 Yet another possible solution is to use a pool of compute threads and to
 read from the stream, give those compute tasks to the pool to execute in a
 background thread, then reassemble the results at the end (or in a separate
 thread). The balance in this approach is to make the tasks the right
 chunkiness. Using a buffered queue is one technique to avoid having your
 input reader overload the capacity of the processing system.


 That's basically *exactly* what the foldable-seq implementation does.

 I would also mention that using transients as you build input collections
 will be a big win.


 I'm sure that that's true - but the foldable-seq implementation is the one
 that would gain most from that, and that's the one that already runs 3x
 faster than the sequential implementation. But it's also the one that Stu
 objects to. What I'm trying to find is an implementation that Stu doesn't
 object to, but is faster than the sequential version of the algorithm.

 --
 paul.butcher-msgCount++

 Snetterton, Castle Combe, Cadwell Park...
 Who says I have a one track mind?

 http://www.paulbutcher.com/
 LinkedIn: http://www.linkedin.com/in/paulbutcher
 MSN: p...@paulbutcher.com
 AIM: paulrabutcher
 Skype: paulrabutcher

 On 28 Sep 2013, at 22:00, Alex Miller a...@puredanger.com wrote:

 Reducers (and fork/join in general) are best suited for fine-grained
 computational parallelism on in-memory data. The problem in question
 involves processing more data than will fit in memory.

 So the question is then what is the best way to parallelize computation
 over the stream. There are many ways to do so - pmap is one easy mechanism
 to get parallelism over a lazy sequence but the chunking behavior of pmap
 can easily be non-optimal for particular use cases. Stu's other solution
 (prepare-with-partition-then-fold) reads chunks of data into memory, then
 uses f/j over the top of those chunks.

 Yet another possible solution is to use a pool of compute threads and to
 read from the stream, give those compute tasks to the pool to execute in a
 background thread, then reassemble the results at the end (or in a separate
 thread). The balance in this approach is to make the tasks the right
 chunkiness. Using a buffered queue is one technique to avoid having your
 input reader overload the capacity of the processing system.

 I would also mention that using transients as you build input collections
 will be a big win.

 Alex

 On Saturday, September 28, 2013 11:14:41 AM UTC-5, Jozef Wagner wrote:

 I would go a bit more further and suggest that you do not use sequences
 at all and work only with reducible/foldable collections. Make an input
 reader which returns a foldable collection and you will have the most
 performant solution. The thing about holding into the head is being worked
 on right now, see 
 http://dev.clojure.org/**jira/browse/CLJ-1250http://dev.clojure.org/jira/browse/CLJ-1250

 JW

 On Saturday, September 28, 2013 10:41:20 AM UTC+2, Paul Butcher wrote:

 On 28 Sep 2013, at 00:27, Stuart Halloway stuart@gmail.com wrote:

 I have posted an example that shows partition-then-fold at
 https://github.com/**stuarthalloway/exploring-**
 clojure/blob/master/examples/**exploring/reducing_apple_pie.**cljhttps://github.com/stuarthalloway/exploring-clojure/blob/master/examples/exploring/reducing_apple_pie.clj
 .

 I would be curious to know how this approach performs with your data.
  With the generated data I used, the partition+fold and partition+pmap
 approaches both used most of my cores and had similar perf.


 Hey Stuart,

 Thanks for getting back to me.

 I've updated the code for my word

Re: Type hints for clojure.set functions

[Stuart Halloway]

I think the bar for such an enhancement is fairly high, and the value
delivered fairly low.  It isn't so much the impact of assessing this single
change, as the impact of managing the universe of such changes.

Regards,
Stu

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

[Stuart Halloway]

Hi Paul,

I have posted an example that shows partition-then-fold at
https://github.com/stuarthalloway/exploring-clojure/blob/master/examples/exploring/reducing_apple_pie.clj
.

I would be curious to know how this approach performs with your data.  With
the generated data I used, the partition+fold and partition+pmap approaches
both used most of my cores and had similar perf.

Enjoying your book!

Stu


On Sat, May 25, 2013 at 12:34 PM, Paul Butcher p...@paulbutcher.com wrote:

 I'm currently working on a book on concurrent/parallel development for The
 Pragmatic Programmers. One of the subjects I'm covering is parallel
 programming in Clojure, but I've hit a roadblock with one of the examples.
 I'm hoping that I can get some help to work through it here.

 The example counts the words contained within a Wikipedia dump. It should
 respond well to parallelisation (I have Java and Scala versions that
 perform excellently) but I've been incapable of coming up with a nice
 solution in Clojure.

 The code I'm working with is checked into 
 GitHubhttps://github.com/paulbutcher/parallel-word-count
 :

 The basic sequential algorithm is:

 (frequencies (mapcat get-words pages))


 If I run that on the first 10k pages in Wikipedia dump, it takes ~21s on
 my MacBook Pro.

 One way to parallelise it is to create a parallel version of frequencies
 that uses reducers:

 (defn frequencies-fold [words]
   (r/fold (partial merge-with +)
   (fn [counts word] (assoc counts word (inc (get counts word 0

   words))


 And sure enough, if I use that, along with use the 
 foldable-seqhttps://github.com/paulbutcher/parallel-word-count/blob/master/src/foldable_seq/core.clj
  utility
 I posted about 
 herehttps://groups.google.com/d/msg/clojure/8RKCjF00ukQ/b5mmmOB5Uh4J are
 while ago it runs in ~8s, almost a 3x speedup, not bad given that the
 parallel version is unable to use transients.

 Unfortunately, as they currently stand, reducers have a fatal flaw that
 means that, even with foldable-seq, they're basically useless with lazy
 sequences. Reducers always hold onto the 
 headhttps://groups.google.com/d/msg/clojure-dev/qJo7z_9CVdw/ARnHe1bThuMJ of
 the sequence they're given, so there's no way to use this approach for a
 complete Wikipedia dump (which runs to around 40GiB).

 So the other approach I've tried is to use pmap:

 (defn frequencies-pmap [words]
   (reduce (partial merge-with +)
 (pmap frequencies
   (partition-all 1 words


 But, for reasons I don't understand, this performs dreadfully - taking
 ~26s, i.e. significantly slower than the sequential version.

 I've tried playing with different partition sizes without materially
 affecting the result.

 So, what I'm looking for is either:

 a) An explanation for why the pmap-based solution performs so badly

 b) A way to fix the holding onto head problem that's inherent within
 reducers.

 With the last of these in mind, it strikes me that the problem
 fundamentally arises from the desire for reducers to follow the same basic
 API as normal code. So:

 (reduce (filter ... (map ... coll)))

 becomes:

 (r/fold (r/filter ... (r/map ... coll)))

 A very small change to the reducers API - passing the collection to the
 reduce and/or fold - would avoid the problem:

 (r/fold (r/filter ... (r/map ...)) coll)

 Anyway - I'd be very grateful for any insight into either of the above
 questions. Or for suggestions for an alternative approach that might be
 more fruitful.

 Many thanks in advance,

 --
 paul.butcher-msgCount++

 Snetterton, Castle Combe, Cadwell Park...
 Who says I have a one track mind?

 http://www.paulbutcher.com/
 LinkedIn: http://www.linkedin.com/in/paulbutcher
 MSN: p...@paulbutcher.com
 AIM: paulrabutcher
 Skype: paulrabutcher

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

October Barnstorming in Europe

[Stuart Halloway]

Michael Nygard [1] and Stu Halloway [2] will be in Europe for much of
October.  We are speaking at a bunch of conferences [3], [4], [5], and
[6] and hope to see some of you there.

Since we are already on the road, we thought it would be a good
opportunity to turn this into a barnstorming tour, working with teams
who are looking for help with Clojure, ClojureScript, and/or Datomic.
If you would like to have us work with your team, pricing is as
follows:

* Free for user group talks
* $1500 for a 90 minute talk
* $5000 for a day of training or consulting
* $0 for travel expenses (we are already there!)

Our prepared materials are summarized at [7] and [8], or feel free to
request
specific topics.

If you are interested in scheduling a meeting, please send an email to
i...@thinkrelevance.com, subject line: October Barnstorming.
Includes in the body of the message the kind of event you are
interested in, as well as possible dates and locations.

Regards,
Michael and Stu

[1] http://thinkrelevance.com/team/members/stuart-halloway
[2] http://thinkrelevance.com/team/members/michael-nygard
[3] http://euroclojure.com/2013/
[4] http://reaktordevday.fi/2013/
[5] http://gotocon.com/berlin-2013/
[6] http://gotocon.com/amsterdam-2013/upcomingevents/
[7] https://github.com/stuarthalloway/presentations/wiki
[8] https://github.com/mtnygard/presentations/wiki

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

Re: Clojure 1.6 API: clojure.lang.IFn and clojure.api.API

[Stuart Halloway]

Hi Joerg,

I am not sure I understand your question. The API class is for intraprocess
communication, not interprocess.

All API does is provide a public, supported entry point for the kinds of
things people are already doing with Var. The latter is undesirable because
using Var makes it way too easy to marry implementation detail.

Stu


On Sat, Jun 22, 2013 at 6:01 AM, Jörg Winter jwin1...@gmail.com wrote:

 So these APIs are new in 1.6-SNAPSHOT and from what I understand provide
 an integration api between Java and Clojure-Runtime (symbols and their
 invocation).
 Apart from limitations which probably exist, what is the mode of execution
 for these API-calls ?

 For example if a tool/IDE starts a (REPL) _process_ by calling
 ClojureUtils.CLOJURE_MAIN, how am I supposed to call

 API.var(clojure.core, +);
 ?

 How would I get the JVMs class-instance of API if I don't add some kind of 
 inter-process communication ?

 Any known projects using this new API already ?

 Joerg



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

[Stuart Halloway]

Hi Steven,

A few thoughts:

1. You may want to look at
https://github.com/clojure/test.generative/blob/master/data-model.org.

2. I don't think you want a ref for *assertion-results* -- I am not aware
of any use cases that would need transactions. In any case the choice of
reference type probably belongs in the impl, not the spec.

Good luck with this!
Stu


On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis sbdegu...@gmail.com wrote:

 Test2 is a new testing lib for Clojure, where the power is its simplicity,
 extensibility, and a 
 SPEChttps://github.com/evanescence/test2/blob/master/SPEC.md much
 like Ring's.

 Github: https://github.com/evanescence/test2

 Some background: It came out of 
 discussionshttps://github.com/evanescence/test2/wiki/Communal-Brainstorming 
 with
 the smart folks in #clojure, who were frustrated with the inflexibility of
 existing libs, and intended this to be the spiritual successor to
 clojure.test. We wanted something that was still simple like clojure.test,
 but could be extended externally much more easily in case you wanted
 features found in clojure.test, Midje, Speclj, or Expectations, or whatever
 else.

 This is a pre-ANN because it's more of a call for extensions. I've written
 one last night, 
 test2-autorunnerhttps://github.com/evanescence/test2-autorunner,
 which took about an hour. This should give some idea of how easy it is and
 how well-designed the SPEC was by the smart folks of #clojure. There are
 some ideas at the bottom of the wiki, but of course any extensions are
 encouraged.

 -Steven

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

is there a way to use clojure.main/repl from lein?

[Stuart Halloway]

As opposed to tools.nrepl?

Thanks,
Stu

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

Re: is there a way to use clojure.main/repl from lein?

[Stuart Halloway]

I thought I wanted some of the affordances, but not the nrepl connection
(e.g. get to reply's standalone eval mode).

But it turns out that for my use case, I don't need any of that, so calling
clojure.main directly is the right thing.

Thanks,
Stu


On Mon, May 27, 2013 at 11:27 AM, Laurent PETIT laurent.pe...@gmail.comwrote:

 Hello,

 What about

 lein run -m clojure.main

 ?


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

Clojure and Datomic workshops at NDC Oslo week of June 10

[Stuart Halloway]

Hi all,

I will be doing Clojure and Datomic workshops, as well as a few talks. at
NDC Oslo in a few weeks, see http://ndcoslo.oktaset.com/Agenda for details.

Hope to see some of you there!

Stu

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

[Stuart Halloway]

Wiki/repo:   https://github.com/Datomic/simulant/wiki
Clojars:   https://clojars.org/com.datomic/simulant
Presentations:
https://github.com/stuarthalloway/presentations/wiki/Simulation-Testing

Enjoy!

Stu

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

Re: Clojure 1.5.1

[Stuart Halloway]

Fixed, thanks.

Stu


On Sun, Mar 10, 2013 at 7:28 PM, ke.mar...@gmail.com wrote:

 I think there's a typo in the download link on
 http://clojure.org/downloads:

 It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0*
 /clojure-1.5.1.ziphttp://repo1.maven.org/maven2/org/clojure/clojure/1.5.0/clojure-1.5.1.zip
 whereas it should be
 http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*1*
 /clojure-1.5.1.ziphttp://repo1.maven.org/maven2/org/clojure/clojure/1.5.1/clojure-1.5.1.zip
 (note the 1.5.1 vs. 1.5.0 in the second to last part of the URL)


 Am Sonntag, 10. März 2013 19:35:34 UTC+1 schrieb stuart@gmail.com:

 Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:

 https://groups.google.com/d/**msg/clojure-dev/uAFM0Ti4AcQ/**GmnKmphF1BgJhttps://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ

 Getting Clojure:

   Web:  http://clojure.org/downloads
   Lein/Maven:   :dependencies [[org.clojure/clojure 1.5.1]]

 Note that it will take a few hours for the links above to become live,
 as the completed build moves into Maven Central.

 Thanks,

 Stu Halloway
 Clojure/core

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

Clojure 1.5.1

[Stuart Halloway]

Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:

https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ

Getting Clojure:

  Web:  http://clojure.org/downloads
  Lein/Maven:   :dependencies [[org.clojure/clojure 1.5.1]]

Note that it will take a few hours for the links above to become live,
as the completed build moves into Maven Central.

Thanks,

Stu Halloway
Clojure/core

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

[Stuart Halloway]

We are pleased to announce the release of Clojure 1.5.

Getting Clojure:

  Web:  http://clojure.org/downloads
  Lein/Maven:   :dependencies [[org.clojure/clojure 1.5.0]]

Note that it will take a few hours for the links above to become live,
as the completed build moves into Maven Central.

This release includes significant features and bug fixes, documented
here:

  https://github.com/clojure/clojure/blob/master/changes.md

The number of Clojure contributors continues to grow. Thanks to all
the people whose code is included in this release:

Aaron Bedra
Alan Malloy
Alex Redington
Alf Kristian Stoyle
Ambrose Bonnaire-Sergeant
Andy Fingerhut
Brandon Bloom
Brenton Ashworth
Bronsa
Chas Emerick
Christophe Grand
Colin Jones
Cosmin Stejerean
Daniel Solano Gómez
David Powell
David Santiago
Ed Bowler
Federico Brubacher
Gabriel Horner
Gary Fredericks
Herwig Hochleitner
Hubert Iwaniuk
Hugo Duncan
John Szakmeister
Juha Arpiainen
Justin Kramer
Kevin Downey
Laurent Petit
Meikel Brandmeyer
Michael Fogus
Michał Marczyk
Michel Alexandre Salim
Philip Aston
Philip Potter
Rich Hickey
Scott Lowe
Steve Miner
Stuart Halloway
Stuart Sierra
Tassilo Horn
Toby Crawley
Tom Faulhaber

Thanks to all involved!

Stu Halloway
Clojure/core

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

Clojure 1.5 RC 17 wending through the maven pipes

[Stuart Halloway]

Only change from RC 16 is http://dev.clojure.org/jira/browse/CLJ-1168.

Please test for regression.

Stu

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

Clojure in the Field 2013 edition, suggestions wanted

[Stuart Halloway]

Next week, I will be giving an all-new version of my Clojure in the Field'
experience report [1] at DevNexus in Atlanta [2].

I will be drawing in Chas's State of Clojure Survey [3], and on the
community success stories page [4], but those only scratch the surface of
the wealth of Clojure experience on this list.

So I need your help! If you were talking to somebody who was considering
Clojure, and who wanted to know what it was like using it in the real
world, what are the most important ideas and stories you would want to
convey?

Thanks!
Stu

[1] http://www.infoq.com/presentations/Clojure-in-the-Field
[2] http://devnexus.com/s/presentations#id-1396
[3]
http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/
[4] http://dev.clojure.org/display/community/Clojure+Success+Stories

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

RC 16: Last chance to test against Clojure 1.5 before it ships

[Stuart Halloway]

If you care about Clojure 1.5 compatibility for your codebase, please test
it against RC 16 as soon as possible.

You can get the source and build it yourself from [1], or wait for Maven
Central [2] to pick up the CI build, which usually takes a few hours.

Thanks!
Stu

[1] https://github.com/clojure/clojure
[2] http://bit.ly/WEnjAi

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

Re: Clojure 1.5 RC 14

[Stuart Halloway]

 1972-05-30T18:17:49.692-00:00 #inst 1986-03-14T02:42:42.374-00:00 #inst
 2096-01-05T11:11:23.974-00:00 #inst 1997-12-03T18:50:28.444-00:00 #inst
 2009-05-12T23:48:54.862-00:00 #inst 2026-02-16T11:51:39.884-00:00 #inst
 1978-07-24T14:57:30.134-00:00 #inst 2003-08-21T22:16:56.540-00:00 #inst
 2000-04-06T12:22:12.441-00:00 #inst 2002-11-24T01:28:22.121-00:00 #inst
 1994-03-25T13:59:33.563-00:00 #inst 2071-07-24T05:23:57.700-00:00 #inst
 1973-02-21T21:19:53.593-00:00 #inst 2002-01-15T22:05:02.577-00:00 #inst
 2070-11-21T11:43:26.215-00:00 #inst 1981-02-13T22:11:16.246-00:00 #inst
 1970-07-22T21:48:11.057-00:00 #inst 1971-01-29T03:41:18.739-00:00 #inst
 1999-03-27T23:30:24.423-00:00 #inst 1977-02-06T08:36:28.391-00:00 #inst
 2077-10-02T22:12:19.848-00:00 #inst 2033-06-20T08:33:04.929-00:00 #inst
 2076-12-24T03:10:57.403-00:00 #inst 1994-02-24T15:51:53.173-00:00 #inst
 1971-05-25T22:45:07.225-00:00 #inst 1973-12-18T13:35:59.229-00:00 #inst
 2042-10-23T01:45:24.233-00:00 #inst 2038-03-23T00:12:18.445-00:00 #inst
 2000-05-08T18:30:51.890-00:00 #inst 1970-03-22T04:27:39.217-00:00 #inst
 1980-11-20T20:59:16.421-00:00 #inst 2001-06-29T08:24:25.837-00:00],
 :read #OutOfMemoryError java.lang.OutOfMemoryError: PermGen space}

 -Aaron

 On Feb 9, 2013, at 2:13 PM, Stuart Halloway stuart.hallo...@gmail.com
 wrote:

 Clojure 1.5 RC 14 (fourteen) will be available soon from Maven Central:


 http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0*

 Please test it!

 Thanks,
 Stu

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

 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.






 --
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.


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

[Stuart Halloway]

I found it, fix coming soon.

Pesky interned keywords.




On Sun, Feb 10, 2013 at 10:31 AM, Aaron Bedra aaron.be...@gmail.com wrote:

 I tried it on 3 machines with the following results

 Late '11 iMac running OS X 10.8.2: Failed with PermGen error
 Mid '12 Macbook Air running OS X 10.8.2: Success
 VM Running Arch Linux: Success

 So I can't say it is easily reproducible. I'll see if I can find what is
 tripping things up on the iMac today.

 -Aaron

 On Feb 10, 2013, at 8:36 AM, Stuart Halloway stuart.hallo...@gmail.com
 wrote:

 Aaron:

 Were you simply running the test suite via the build?  On what hardware
 and OS?

 Stu


 On Sat, Feb 9, 2013 at 9:16 PM, Aaron Bedra aaron.be...@gmail.com wrote:

 Yeah, I know what would fix it, but I would like to make sure the right
 defaults are in place for folks who pull it down.

 -Aaron

 On Feb 9, 2013, at 4:29 PM, AtKaaZ atk...@gmail.com wrote:

 maybe jvm arg would help
 -XX:MaxPermSize=256m



 On Sat, Feb 9, 2013 at 11:17 PM, Aaron Bedra aaron.be...@gmail.comwrote:

 I just pulled it down locally and got the dreaded PermGen…

  [java] java.lang.OutOfMemoryError: PermGen space
  [java] at
 clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
  [java] at clojure.lang.AFn.applyToHelper(AFn.java:161)
  [java] at clojure.lang.AFn.applyTo(AFn.java:151)
  [java] at clojure.core$apply.invoke(core.clj:617)
  [java] at
 clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
  [java] at
 clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
  [java] at
 clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
  [java] at
 clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
  [java] at
 clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
  [java] at clojure.lang.AFn.call(AFn.java:18)
  [java] at
 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
  [java] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
  [java] at
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  [java] at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  [java] at java.lang.Thread.run(Thread.java:680)
  [java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see
 ex-data {:printed [#inst 2034-04-17T21:03:17.620-00:00 #inst
 1979-04-19T20:14:07.477-00:00 #inst 1996-06-20T05:47:52.868-00:00 #inst
 1995-08-15T20:51:41.920-00:00 #inst 2029-05-17T14:34:37.906-00:00 #inst
 1987-06-05T21:05:23.305-00:00 #inst 1994-06-29T16:17:24.459-00:00 #inst
 2035-12-03T09:39:44.754-00:00 #inst 2040-01-31T09:47:29.774-00:00 #inst
 1973-06-09T04:53:42.029-00:00 #inst 1996-12-23T17:26:25.607-00:00 #inst
 2022-07-01T16:33:57.846-00:00 #inst 1998-10-01T00:21:09.895-00:00 #inst
 1973-01-11T17:43:58.457-00:00 #inst 1988-11-03T22:46:53.468-00:00 #inst
 1982-01-31T11:34:19.796-00:00 #inst 2011-11-11T10:59:23.168-00:00 #inst
 1973-06-07T12:37:22.285-00:00 #inst 1977-12-15T03:32:20.215-00:00 #inst
 2047-10-15T13:51:28.327-00:00 #inst 2007-12-16T05:50:59.539-00:00 #inst
 1980-05-01T01:58:13.802-00:00 #inst 1980-01-30T04:31:20.418-00:00 #inst
 2044-09-16T14:38:34.919-00:00 #inst 1980-08-05T18:06:50.589-00:00 #inst
 1978-12-31T11:40:11.800-00:00 #inst 2015-05-08T15:03:27.594-00:00 #inst
 1975-06-28T17:24:08.855-00:00 #inst 1975-06-09T07:22:42.892-00:00 #inst
 2026-03-20T07:01:01.296-00:00 #inst 2053-02-02T01:33:45.525-00:00 #inst
 2002-04-11T18:43:38.347-00:00 #inst 1992-12-10T13:33:55.048-00:00 #inst
 2015-04-16T20:53:45.670-00:00 #inst 2013-12-23T20:16:07.506-00:00 #inst
 1978-09-02T09:42:03.175-00:00 #inst 1980-06-29T00:54:55.361-00:00 #inst
 2061-11-04T22:40:32.484-00:00 #inst 2190-06-05T04:42:38.638-00:00 #inst
 2038-03-19T09:05:50.002-00:00 #inst 2033-08-08T13:48:51.747-00:00 #inst
 2077-11-18T06:09:19.557-00:00 #inst 1997-02-07T14:02:27.410-00:00 #inst
 1988-08-20T07:11:32.623-00:00 #inst 1981-12-06T05:48:21.787-00:00 #inst
 1980-08-15T09:40:38.877-00:00 #inst 2022-01-19T16:23:06.638-00:00 #inst
 1994-09-09T17:35:55.052-00:00 #inst 1989-09-14T07:24:38.880-00:00 #inst
 2050-03-30T21:22:42.054-00:00 #inst 2071-10-09T20:37:08.430-00:00 #inst
 2083-04-19T10:25:43.108-00:00 #inst 1978-09-09T18:28:22.366-00:00 #inst
 1979-11-03T08:18:42.779-00:00 #inst 1975-10-24T00:59:58.497-00:00 #inst
 1974-10-10T14:40:29.360-00:00 #inst 1999-07-14T07:47:47.220-00:00 #inst
 2215-11-23T00:36:40.748-00:00 #inst 2077-02-14T19:40:22.712-00:00 #inst
 1985-03-14T12:30:49.064-00:00 #inst 2021-08-26T20:51:15.030-00:00 #inst
 2013-04-22T10:48:12.278-00:00 #inst 2019-08-31T17:31:05.195-00:00 #inst
 1975-04-21T22:13:33.370-00:00 #inst 1984-09-10T23:30:15.313-00:00 #inst
 2053-11-10T05:36:02.093-00:00 #inst 1974-01-05T15:17:02.286-00:00 #inst
 2058-09-18T08:11:45.895-00:00 #inst 1987-10-26T13:15:29.968-00:00 #inst
 2001-10-01T08:12:45.877-00:00 #inst 2003-05

Clojure 1.5 RC 15 coming soon to Maven Central

[Stuart Halloway]

Please test...

Stu

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

[Stuart Halloway]

+1 on this line of thought. We are definitely interested in decomplecting
dev mode utility from production lean-and-meanness.

One question along this path is What options exist in Java/maven land for
doing multiple releases of the same artifact with e.g. different
performance and debugging characteristics, and how could these be
incorporated into the Clojure build in a transparent, easy-to-assess way?

Answering the preceding question (or reframing it into a better question)
is not blocked waiting on anybody. Have at it!

Stu


On Fri, Feb 8, 2013 at 9:36 PM, Brian Marick mar...@exampler.com wrote:


 On Feb 8, 2013, at 7:56 PM, Daniel Glauser danglau...@gmail.com wrote:

 
  This sounds like a great idea. I was working with some tests today and
 it would have been really useful to have some way to query the current
 function/execution context. Seems like passing that through all lets would
 go a long way, provided I'm reading this right.

 It would be very interesting to have a maximally informative mode and a
 generate really tense code mode. There is tradition behind such an idea.

 It would be especially interesting if the maximally informative mode had
 hooks tools could exploit. For example, Midje provides a hack where you can
 declare records in a way that the contained functions can be mocked:
 `defrecord-openly`. I expect almost no one uses it, even though it is no
 different than `defrecord` when in production mode: it's too weird
 looking. But people would use it if ordinary defrecord methods weren't
 inlined during development.

 There's no *semantic* reason why parts of Clojure should *always* be
 closed to introspection-type actions. It's purely a matter of time
 constraints on the core team, which I am certainly not in a position to
 judge. How much core time should be spent on saving anonymous programmers
 time vs. saving cycles for anonymous apps running on the Amazon cloud? It's
 a tough tradeoff.

 
 Looking for 1/2-time employment as a Clojure programmer
 Latest book: /Functional Programming for the Object-Oriented Programmer/
 https://leanpub.com/fp-oo

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

Clojure 1.5 RC 14

[Stuart Halloway]

Clojure 1.5 RC 14 (fourteen) will be available soon from Maven Central:

http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0*

Please test it!

Thanks,
Stu

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

[Stuart Halloway]

It is likely that, once this Pandora's box is opened, there will be more
profiles that just debug yes/no.

It is almost certain that whatever we do must be maven friendly.  (Maven is
a de facto standard for 1000x more people than leiningen, and some of them
want to use libs written in Clojure.)

If you are excited about doing this design work, please start a page in
Confluence, and capture your goals, options, tradeoffs, and recommendations.

Stu


On Sat, Feb 9, 2013 at 7:20 PM, vemv v...@vemv.net wrote:

 I had something like this in mind:

- There's a set of clojure.core vars that mean something (potentially)
expensive yet convenient, and default to true
- Neither library producers or consumers have ever to touch those
(unless they want fine-grained control for some specific var/context)
- When performing a release to clojars or central, Lein creates two
versions (DEBUG, NO-DEBUG), in which the vars are set to true and
false, respectively
- Then library consumers can specify either [com.example/awesomelib *
1.4.0*], [com.example *1.4.0-DEBUG*], or [com.example *
1.4.0-NO-DEBUG*] in their :dependencies vector, in the corresponding
project.clj.
- If no version directive is specified, DEBUG would be chosen unless
specified otherwise in profiles.clj: {:user {:debug-dependencies false}}

 Does it sound good enough?


 On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:

 Given that: a) fns can have names for debugging purposes, and b) data
 structures can have metadata, wouldn't it be a good idea to let let auto
 attach (where possible) the names of the bindings to their corresponding
 values?

 For example, the improved let I'm thinking of would translate this input:

 (ns my.namespace)

 (defn do-it
   (let [foo (fn [] (throw (Exception.)))
 bar {:hello (/ 0 0)}]))

 to:

 (ns my.namespace)

 (defn do-it
   (let [foo (fn foo [] (throw (Exception.)))
 bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))

 This could be used to increase the precision of the stack traces, or in
 IDEs/editors for locating the exact source of an exception.

 Do you see such a mechanism being incorporated to clojure.core/let -
 should I open a ticket?

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

[Stuart Halloway]

I am pleased to announce the release of Simulant, an open-source framework
for simulation-based testing built using Datomic and Clojure:

https://github.com/Datomic/simulant

Feedback welcome!

Stu

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

Clojure 1.5 RC 4 wants to be Clojure 1.5

[Stuart Halloway]

Clojure 1.5 RC 4 is now available via Maven Central:

http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0*

Please test it!

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

[Stuart Halloway]

The docs are clear that the test occurs before the bindings:

(doc if-let)
-
clojure.core/if-let
([bindings then] [bindings then else  oldform])
Macro
  bindings = binding-form test

  If test is true, evaluates then with binding-form bound to the value of
  test, if not, yields else

Cheers,
Stu


On Thu, Jan 31, 2013 at 2:43 AM, Mimmo Cosenza mimmo.cose...@gmail.comwrote:


 On Thursday, January 31, 2013 1:49:40 AM UTC+1, Sean Corfield wrote:

 but now that you've posted this, I
 can see some potential for confusion when folks first encounter
 if-let... Presumably the same confusion could arise for when-let?


 yes, this is the confusion that you can incur in.

 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: Clojure 1.5.0 RC 1

[Stuart Halloway]

Changing the way Clojure is *packaged* to meet the needs of an alien build
system is the tail wagging the dog.

Clojure uses the de facto Java standard (Maven) to deal with these things.
 Clojure's build depends on a number of plugins (maven-release-plugin,
maven-source-plugin, maven-jar-plugin, maven-assembly-plugin,
build-helper-maven-plugin, maven-antrun-plugin, and maven-compiler-plugin),
and most of these dependencies have been present for several releases
already, so this is not a new problem.

Whatever technique prevents those items from being downloaded from the
Internet should also be considered for test.generative.

Stu


On Sun, Dec 23, 2012 at 4:11 PM, Jochen Schmitt joc...@herr-schmitt.dewrote:

 On Sun, Dec 23, 2012 at 12:45:50PM -0800, Andy Fingerhut wrote:

  Are there no other RPMs that require Internet access to complete their
 build?
 
  e.g. no others that use Maven to pull in dependencies before building?

 Dependencies should be solved by the specification of BuildRequires
 statements
 in the SPEC file, so the build system will install the packages which are
 required
 to build a package before the build will be start.

  If there is no provision for that, I'd open up the question to others
 with more experience in these matters: How would you recommend that someone
 create an RPM for Clojure on a build machine with no Internet access?

 Sorry, I'm talking about the official build system of the Fedora projejct
 and
 the download of data during the build process may a violatation of the
 packaging policies.

  The only way I can think of would be to pull in the dependencies on a
 machine with Internet access, and make a package available to the RPM build
 machine with all dependencies included.

 ???

  Either that, or get a pre-built JAR file for Clojure from the official
 distribution locations (e.g. the Maven repo) and put that into an RPM.

 Using of pre-built JAR files in a package is also a violation of the
 packaging
 policy which state that all stuff should be built from soruce.

 Because it's looks like, thest test.gnerative may be a speicial JAR file
 for Clojure, the best way may to include it into the official Clojure
 soruce pacakge.

 In the meanwhile, I have found a way to suppres the test step in the
 ant script.

 Best Regards:

 Jochen Schmitt

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

Clojure 1.5.0 RC 1

[Stuart Halloway]

I just kicked off the RC1 build for Clojure.  With luck, within a few hours
it will show up at Maven Central [1]

Please test it.  It would be fantastic if as many people as possible
updated their projects and tested with the RC, so we can flush out issues
now instead of in release.

Regards,
Stu

[1] http://bit.ly/WEnjAi

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

[Stuart Halloway]

Hi Paul,

If it isn't too late to change your chapter title, I would encourage
emphasizing Clojure's model of references and values in general, and the
option of implementing a variety of different reference semantics that all
conform to the same basic API shape.

That general approach has been game-changing for me, and the STM occupies a
rather small niche in the overall space.

Datomic stores the entire database in an atom (not an STM ref), and updates
it with a call to swap!  It is literally no more complex than a trivial
hackneyed book example. :-)

Cheers,
Stu



On Sun, Dec 2, 2012 at 11:03 AM, Paul Butcher p...@paulbutcher.com wrote:

 All,

 I have a request which I hope the members of this group are uniquely
 positioned to help with. I have recently started working on a new book for
 The Pragmatic Programmers with the working title Seven Concurrency Models
 in Seven Weeks (it follows on from their existing Seven Languages and
 Seven Databases titles).

 One of the approaches that I'll be covering is STM, and I'll be presenting
 it in Clojure.

 What I'd like to solicit are war stories about problems you've solved
 using STM, which demonstrate the strengths of the technique over and above
 (say) threads and locks.

 I'm looking for real-world examples instead of presenting yet another
 hackneyed atomically-make-a-bank-account-withdrawal :-)

 Very many thanks in advance for your help!

 --
 paul.butcher-msgCount++

 Snetterton, Castle Combe, Cadwell Park...
 Who says I have a one track mind?

 http://www.paulbutcher.com/
 LinkedIn: http://www.linkedin.com/in/paulbutcher
 MSN: p...@paulbutcher.com
 AIM: paulrabutcher
 Skype: paulrabutcher

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group 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: STM - a request for war stories

[Stuart Halloway]

Hi Paul,

Here is a real-world, production software example of the advantage of
values+refs over mutable objects and locks. A Datomic user reported the
following stack trace as a potential bug:

12:45:43.480 [qtp517338136-84] WARN  c.v.a.s.p.e.UnknownExceptionHandler -
UnknownExceptionHandler: null
java.util.ConcurrentModificationException: null
   at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819)
~[na:1.7.0_07]
   at java.util.ArrayList$Itr.next(ArrayList.java:791) ~[na:1.7.0_07]
   at clojure.core.protocols$fn__5871.invoke(protocols.clj:76)
~[clojure-1.4.0.jar:na]
   at clojure.core.protocols$fn__5828$G__5823__5841.invoke(protocols.clj:13)
~[clojure-1.4.0.jar:na]
   at clojure.core$reduce.invoke(core.clj:6030) ~[clojure-1.4.0.jar:na]

I immediately had 99% confidence that the bug was in user code, and even a
pretty good idea what went wrong.  A call to reduce is a functional
transformation, and it expects to be passed values.  The exception clearly
indicates a violation of that contract, and is caused by cross-thread
aliasing and mutation in the calling code.

Regards,
Stu





On Sun, Dec 2, 2012 at 11:03 AM, Paul Butcher p...@paulbutcher.com wrote:

 All,

 I have a request which I hope the members of this group are uniquely
 positioned to help with. I have recently started working on a new book for
 The Pragmatic Programmers with the working title Seven Concurrency Models
 in Seven Weeks (it follows on from their existing Seven Languages and
 Seven Databases titles).

 One of the approaches that I'll be covering is STM, and I'll be presenting
 it in Clojure.

 What I'd like to solicit are war stories about problems you've solved
 using STM, which demonstrate the strengths of the technique over and above
 (say) threads and locks.

 I'm looking for real-world examples instead of presenting yet another
 hackneyed atomically-make-a-bank-account-withdrawal :-)

 Very many thanks in advance for your help!

 --
 paul.butcher-msgCount++

 Snetterton, Castle Combe, Cadwell Park...
 Who says I have a one track mind?

 http://www.paulbutcher.com/
 LinkedIn: http://www.linkedin.com/in/paulbutcher
 MSN: p...@paulbutcher.com
 AIM: paulrabutcher
 Skype: paulrabutcher

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group 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: STM - a request for war stories

[Stuart Halloway]

Is it possible to write a reducing function that mutates a list in Clojure?
Sure. But I think it is absurdly unlikely that it would happen by accident.
 My 1% chance wasn't hedging against that case -- I was hedging against a
bug in reduce itself.

I don't really see even a 1% likelihood of either of those, but I played
DD as a kid and learned that even the most unlikely things happen one time
in twenty. :-)

Stu


On Tue, Dec 11, 2012 at 3:30 PM, Marko Topolnik marko.topol...@gmail.comwrote:

 Just curious, how did you immediately eliminate the possibility that the
 reducing function was mutating the list that is being reduced? No
 concurrency involved. In regular Java the 95% leading cause of CME is
 precisely that.

 Anyway, this applies to immutable structures per se, whether combined with
 atoms, refs, or none. But a full wartime story must also cover how the
 solution avoids the pitfalls of retryable transactions. This is the real
 sore point in my experience, and the one which makes STM an all-or-nothing
 enterprise.


 On Tuesday, December 11, 2012 8:53:40 PM UTC+1, stuart@gmail.comwrote:

 Hi Paul,

 Here is a real-world, production software example of the advantage of
 values+refs over mutable objects and locks. A Datomic user reported the
 following stack trace as a potential bug:

 12:45:43.480 [qtp517338136-84] WARN  c.v.a.s.p.e.UnknownExceptionH**andler
 - UnknownExceptionHandler: null
 java.util.ConcurrentModificati**onException: null
at 
 java.util.ArrayList$Itr.checkF**orComodification(ArrayList.**java:819)
 ~[na:1.7.0_07]
at java.util.ArrayList$Itr.next(A**rrayList.java:791)
 ~[na:1.7.0_07]
at clojure.core.protocols$fn_**_5871.invoke(protocols.clj:76)
 ~[clojure-1.4.0.jar:na]
at 
 clojure.core.protocols$fn_**_5828$G__5823__5841.invoke(pro**tocols.clj:13)
 ~[clojure-1.4.0.jar:na]
at clojure.core$reduce.invoke(cor**e.clj:6030)
 ~[clojure-1.4.0.jar:na]

 I immediately had 99% confidence that the bug was in user code, and even
 a pretty good idea what went wrong.  A call to reduce is a functional
 transformation, and it expects to be passed values.  The exception clearly
 indicates a violation of that contract, and is caused by cross-thread
 aliasing and mutation in the calling code.

 Regards,
 Stu

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group 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: Default random in Clojure doesn't seem to fit fp paradigm

[Stuart Halloway]

Yes, that fix needs to be made, patch welcome. I also have considered
making a protocol for random so that (1) other impls can be used and (2)
easier to port to ClojureScript.

Stu


On Thu, Dec 6, 2012 at 9:15 AM, Asim Jalis asimja...@gmail.com wrote:

 On Thu, Dec 6, 2012 at 5:40 AM, Stuart Sierra the.stuart.sie...@gmail.com
  wrote:

 The data.generators library has versions of these functions that use a
 fixed seed and a rebindable Random instance.

 https://github.com/clojure/data.generators


 Looking at
 https://github.com/clojure/data.generators/blob/master/src/main/clojure/clojure/data/generators.cljcan
  *seed* on line 22 be eliminated, since the only way to change the
 underlying seed is to generate a new Random object and bind it to *rnd*?

 Asim
 --
 http://metaprose.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: Evolving the Clojure contribution process and goals

[Stuart Halloway]

 3.) Much like an Emergency Room, there should be a a fast-track to getting 
 smaller patches approved and merged.
 This is actually not a problem consistent across all areas of the language - 
 some contrib libraries and ClojureScript in particular seem to be getting 
 this *just right*.
 Is there a way we can adjust the current workflow to fill need?  It seems 
 like even with more screeners, patches are sitting idle.
 One possible solution is if we extended contrib-like ownership into parts of 
 Clojure proper, like clojure.test, clojure.string, etc.

Better triage is high on my wish list, too. (Although I think the emergency 
room metaphor implies he opposite result for smaller patches.)

Now that dependency management has improved to the point that Clojure has 
build-time dependencies down into contrib, another option is to take 
clojure.test et al out of Clojure into contribs.  This would be a breaking 
change in that people would have to add such new contribs to their maven deps.

Stu


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Evolving the Clojure contribution process and goals

[Stuart Halloway]

 Currently I advice Clojure newcomers to not use clojure.org for anything, it 
 is hopelessly outdated, reference-oriented and will only confuse them more.
 Unsurprisingly, this does not encourage newcomers as they think that many 
 other things are hopelessly broken and outdated in this community.

1. Agreed that the outdated parts of clojure.org should be fixed. I hope to 
spend some time on that this week.

2. We can and should have better community-driven documentation. Currently 
clojure.org links out to http://dev.clojure.org/display/doc/Home in a few 
places, and could link out more.  Leadership in making dev.clojure.org 
excellent would be most welcome.  Don't ask for permission, just do it.

Cheers,
Stu


Stuart Halloway
Clojure/core
http://clojure.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: Evolving the Clojure contribution process and goals

[Stuart Halloway]

 Stuart, can you elaborate a little what better triage looks like?  What are 
 the current issues you're facing and what would make the process better for 
 you?  The ER metaphor perhaps isn't the best :)
 What are other ways the community can help get changes pushed along better 
 and integrated?
 How might we better adjust the process to prevent patched and screened 
 changes from sitting around for long stretches of time?

Here are a few ideas:

1. Please be clear in marking something a defect vs. an enhancement requests. 
Defects have top priority, and I would guess that I reclassify 30% of the 
tickets I review from defect to enhancement request.

2. If you have found a defect for which you know of no workaround, shout 
*loudly*. Put a message on the mailing list, making it clear that you are 
stuck. These items should get the very highest priority.

3. If your enhancement can be library code, make a contrib library of it. Then 
you are not tied to Clojure's deliberately more conservative release cycle.

I will put some more thought into this, and plan to host an unsession at the 
conj for people who want to work on it.

Stu

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

[Stuart Halloway]

The rationale appears to be up now, and for my money, it is quite clear: JSON 
not powerful enough, Clojure does too much and is a burden for implementers.

That said, I won't complain if somebody happens to implement full Clojure 
serialization while implementing edn. ;-)

Stu

 I expect there to be a point, and thus also expect it to be communicatable. 
 If there wasn't
 a point, you wouldn't have chosen to use it in datomic, or create the page. I 
 feel you haven't
 communicated the point adequately yet, which is why I raised the questions I 
 raised, also as
 a sign to you that these questions do exist. As I wrote, I look forward to 
 reading the rationale.
 It's not you who needs to convince me (or anybody), it's edn that needs to. 
 If it cannot convince
 anyone, you're wasting your time. I don't expect you to waste your time. 
 Thus, I expect edn
 to be able to convince me, once it gets its point across. And I will refrain 
 from further comments
 until I've seen that argument edn makes for itself.
 
 Regards,
 -Martin


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Question about sets

[Stuart Halloway]

Hi Mark,

Thanks for extracting a summary of the conversation so far, and +1 for making 
sure this is on the wiki.

Stu

 On Tue, Sep 4, 2012 at 9:30 AM, Andy Fingerhut andy.finger...@gmail.com 
 wrote:
 I'm just trying to get the argument for change as clearly as possible.
 
 The major bullet points:
 1. It's a bug that should be fixed.  The change to throw-on-duplicate 
 behavior for sets in 1.3 was a breaking change that causes a runtime error in 
 previously working, legitimate code.  
 
 Looking through the history of the issue, one can see that no one was 
 directly asking for throw-on-duplicate behavior.  The underlying problem was 
 that array-maps with duplicate keys returned nonsensical objects; surely it 
 would be more user-friendly to just block people from creating such nonsense 
 by throwing an error.  This logic was extended to other types of maps and 
 sets.
 
 It's not entirely clear the degree to which the consequences of these changes 
 were considered, but it seems likely that there was an implicit assumption 
 that throw-on-duplicate behavior would only come into play in programs with 
 some sort of syntactic error, when in fact it has semantic implications for 
 working programs.  When a new feature causes unintentional breakage in 
 working code, this is arguably a bug and needs to be reconsidered.  
 
 2. The current way of doing things is internally inconsistent and therefore 
 complex.
 (def a 1)
 (def b 1)
 (set [a b]) - good
 (hash-set a b) - error
 #{a b} - error
 (sorted-set a b) - good
 (into #{} a b) - good
 
 The cognitive load from having to remember which constructors do what is a 
 bad thing.  
 
 3. Current behavior conflicts with the mathematical and intuitive notion of 
 a set.
 In math, {1, 1} = {1}.  In programming, sets are used as a means to eliminate 
 duplicates.
 
 
 Many people have +1'd and reiterated variations of the above arguments.  Now 
 let's summarize the arguments that have been raised here in support of the 
 status quo.
 
 1. Changing everything to throw-on-duplicate would be just as logically 
 consistent as changing everything to use-last-in.
 
 True, but that doesn't mean that both approaches would be equally useful.  
 It's readily apparent that an essential idea of sets is that they need to be 
 able to gracefully absorb duplicates, so at least one such method of doing 
 that is essential.  On the other hand, we can get along just fine without 
 sets throwing errors in the event of a duplicate value.  So if you're looking 
 for consistency, there's really only one practical option.
 
 2.  I like the idea that Clojure will protect me from accidentally from this 
 kind of syntax error.
 
 Clojure, as a dynamically typed language, is unable to protect you from the 
 vast majority of data-entry syntax errors you're likely to make.
 
 Let's say you want to type in {:apple 1, :banana 2}.  Even if Clojure can 
 catch your mistake if you type {:apple 1, :apple 2}, there's no way it's ever 
 going to catch you if you type {:apple 1, :banano 2}, and frankly, the latter 
 error is one you're far more likely to make.
 
 This is precisely why there's little evidence that anyone was asking for this 
 kind of syntax error protection, and little evidence that anyone has 
 benefited significantly from its addition -- its real-world utility is fairly 
 minimal and dwarfed by the other kinds of errors one is likely to make.
 
 3.  Maybe we can do it both ways.
 
 It's laudable to want to make everyone happy.  The danger, of course, is that 
 such sentiment paints a picture that it would be a massive amount of work to 
 please everyone, and therefore, we should do nothing.  Let's be practical 
 about what is easily doable here with the greatest net benefit.  The current 
 system has awkward and inconsistent semantics with little benefit.  Let's 
 focus on fixing it. The easiest patch -- revert to 1.2 behavior, but bring 
 array-map's semantics into alignment with the other associative collections.
 


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: redefining multimethods at the repl

[Stuart Halloway]

Brian,

I share  your pain. A standardized contrib solution for this would be welcomed.

Are there other things like this that cause people to restart REPL 
unnecessarily? I would like to identify the whole list of such things and kill 
them.

Stu

 Thanks. I think I'll write my own `defgeneric` to hide an `ns-unmap` from the 
 reader. (I like the terminology of generic function better than multimethod 
 anyway, as an introduction to the idea.)
 
 
 On Sep 4, 2012, at 5:41 PM, Ulises wrote:
 
 Binding to the var instead of the value will allow it to be udpated.
 
 Alternatively you could ns-unmap the multimethod before redefining it.
 
 U
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 
 -
 Brian Marick, Artisanal Labrador
 Contract programming in Ruby and Clojure
 Occasional consulting on Agile
 Writing /Functional Programming for the Object-Oriented Programmer/: 
 https://leanpub.com/fp-oo
 


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: redefining multimethods at the repl

[Stuart Halloway]

I started a wiki page for this:

http://dev.clojure.org/display/design/Never+Close+a+REPL

If you have other REPL-reloading annoyances please add them there.

Stuart Halloway
Clojure/core
http://clojure.com

 Kevin Downey redc...@gmail.com writes:
 
 if I recall, the current defonce like behavior of multimethods was a
 response to the situation where if you have your multimethods split
 across multiple files reloading the file with the defmulti in it would
 re-def the multimethod with the new dispatch, but it would not have
 any of the methods loaded from the other files.
 
 oscillating between these poles at about 6.31139e7hz seems less than ideal.
 
 maybe defmethod could try and capture the ns a method is defined in,
 and defmulti would try to force a reload? seems overly complicated for
 core.
 
 I assume there's already a really good reason re-evaling defmulti
 doesn't just change the dispatch function without blowing away the
 method table? Though I can't think of one myself.
 
 -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

Re: Rich's The Value of Values and REST

[Stuart Halloway]

 Rich was promoting functional programming. I can see functional programming 
 has its benefits, but you will need mutable states eventually somewhere to do 
 useful things. Functional programming just tell you to constraint yourself 
 when using mutable states. It's not like mutable states are to be avoided by 
 all means. I mean, do you want to get a copy of Google's internal state so 
 you can send it back to Google next time along with your search string, and 
 hence make Google search functional? That is neither practical nor desirable.

It is practical, and desirable, to make a complete (albeit lazily realized) 
value of e.g. entire databases available to any process in a system.  

Stu




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

I will be doing Intro to Clojure at StrangeLoop

[Stuart Halloway]

Late-breaking add to the StrageLoop preconference workshops:

https://thestrangeloop.com/sessions/intro-to-clojure

Cheers,
Stu


Stuart Halloway
Clojure/core
http://clojure.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: reduce-kv doesn't reduce a sorted-map in order

[Stuart Halloway]

Confirmed -- thanks for the report.

Stu

 Hi,
 
 It seems reduce-kv doesn't reduce a sorted-map in the correct order.
 
 Example -
 
 user (def *sm (into (sorted-map) {:aa 1 :zz 2 :bb 3 :yy 4 :cc 5 :xx 6}))
 ;= #'user/*sm
 
 user *sm
 ;= {:aa 1, :bb 3, :cc 5, :xx 6, :yy 4, :zz 2}
 
 ;; plain reduce
 user (reduce (fn [ret e] (conj ret e)) [] *sm)
 ;= [[:aa 1] [:bb 3] [:cc 5] [:xx 6] [:yy 4] [:zz 2]] ; correct
 
 ;; reduce-kv
 user (reduce-kv (fn [ret k v] (conj ret [k v])) [] *sm)
 ;= [[:cc 5] [:bb 3] [:aa 1] [:yy 4] [:xx 6] [:zz 2]] ; incorrect
 
 Is this a bug?
 
 Regards,
 BG

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Question about sets

[Stuart Halloway]

My 2c:

1. Simplicity is partially about having orthogonal primitives. A 
duplicate-removing collection factory cannot be sensibly used to implement a 
throw-on-duplicates collection factory, nor vice versa, so both seem equally 
primitive to me.

2. Given that both flavors are useful, they should both be provided, with 
explicit docs distinguishing them. This could involve new variants of the 
sorted collections for completeness.

3. People may differ about which flavor constructor the literals should use, 
but I don't see any arguments here warranting a breaking change.

In short: can't this be fixed by fixing the docstrings?

Stu

P.S. I pre-disagree with Mark's recommendation that appeared as I was writing 
this. :-)

 On Sun, Aug 5, 2012 at 7:33 AM, Chas Emerick c...@cemerick.com wrote:
 Note that the .createWithCheck variations of all of the collections in 
 question are used by their constructor functions as well, e.g. hash-set, 
 hash-map, and array-map:
 
 I hadn't noticed that, but I think that is good evidence that this 
 createWithCheck concept has been taken to an unintended extreme.  This is no 
 longer about literal versions of maps/sets and constructed versions of 
 maps/sets, so all the initial comments about how literal vectors/maps/sets 
 should only have constants are no longer relevant here (and the decision to 
 make constructors call the same builder as the literal syntax is actually 
 further evidence in support of my claim that literals and constructed 
 versions aren't intended to be hugely different in their semantics).  
 Instead, this is about how maps and sets are intended to be used, overall.
 
 As I recall, the way constructed maps used to work was that when there were 
 duplicate keys, the right-most version took precedence.  To the best of my 
 knowledge, no one every complained about this.  It was intuitive, and 
 consistent with the behavior of into.  The only complaint was that very small 
 maps, built with the literal syntax, didn't do the intuitive thing and behave 
 like larger maps, because behind the scenes they used array maps which didn't 
 check for duplicate keys.  If you said something like {:a 1 :a 2}, Clojure 
 would happily go ahead and build something that wouldn't behave the way you'd 
 expect (e.g., it would return the wrong count and possibly the first 
 key-value pair would take precedence over the last).  But the solution isn't 
 to go ahead and alter the semantics of all forms of maps and sets!  All 
 people really wanted was to bring ArrayMaps into accordance with the other 
 forms of maps so that the behavior would be more predictable.
 
 Furthermore, there's a *long* history of sets being used to reduce a 
 collection with duplicates into something that has no duplicates.  You're 
 creating a huge stumbling block for people if you create some arbitrary rule 
 that with one particular set of syntaxes (i.e., (set [1 2 1]) (sorted-set 1 2 
 1)), sets do what you expect and reduce collections with duplicates to one 
 that has no duplicates, but that with another set of syntaxes (i.e., 
 (hash-set 1 2 1) or #{1 2 1}), it just breaks.  That's seriously confusing, 
 and counter to the spirit of what sets are supposed to do, in my opinion.
 
 It sounds to me like when the dev team thought through the issue about how to 
 fix the problem with array maps, they were thinking specifically about the 
 cases where maps and sets are comprised entirely of constants, and thought it 
 would be a convenient place to try to catch human errors of the form {:apple 
 1, :apple 2} where someone unintentionally duplicated a constant key.  If 
 somehow, the checking could only be limited to constants, I'd be perfectly 
 happy with the error check.  But I suspect there is no easy way to make 
 Clojure behave this way.
 
 Therefore, it's important to be realistic and acknowledge that sets and maps 
 are created in a variety of ways, both with constants and variables, and we 
 want consistent semantics across these constructions.  Run-time errors for 
 duplicate keys in certain kinds of constructions of maps and sets strikes me 
 as running counter to Clojure's mantra of simplicity.
 
 You talk about whether it's fair to expect Clojure to be a mind-reader.  Of 
 course not.  And there are all sorts of things that Clojure can't conceivably 
 check for me when I'm typing in data literals, for example, if I type {:apple 
 1, :banano 2}, it's not going to warn me that I spelled banana wrong, nor 
 should it (if I wanted that kind of protection, I'd use a static-typed 
 language where each type of data was hardcoded to only allowing certain 
 fields).  The reality is that any sort of constant data entered into Clojure 
 has to be carefully double-checked for typos, because most things are not 
 checkable or mind-readable by Clojure.  Going to such error-checking extremes 
 and creating complex semantics in order to protect the user from errors like 
 {:apple 1 :apple 2} is 

Re: [ANN] Datomic Free Edition

[Stuart Halloway]

Working on this, should have a fix shortly.

Stu

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 7/24/12 9:21 AM, Rich Hickey wrote:
 We released a new edition of Datomic today that I think will be of 
 interest to Clojure developers - Datomic Free Edition:
 
 http://blog.datomic.com/2012/07/datomic-free-edition.html
 
 This edition is oriented around making Datomic easier to get, and
 use, for open source and smaller production deployments. Of note
 here is that Datomic Free Edition, in addition to being free, comes
 with a redistributable license, e.g. you can put the Datomic Free
 Edition jar in Clojars.
 
 Datomic Free Edition provides a free database and datalog engine to
 all developers. When combined with Clojure, I think it provides a
 unique path Out of the Tar Pit [1]. I look forward to seeing
 wonderful things created by the Clojure community with this potent
 combination of tools.
 
 Rich
 
 [1] http://shaffner.us/cs/papers/tarpit.pdf
 
 The installation instructions for the free version of datomic don't
 work; they give this command to install locally:
 
 mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic
 - -Dfile=datomic-0.8.3331.jar -DpomFile=pom.xml
 
 Which references the pom.xml file, which does not exist, causing this
 error:
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
 (default-cli) on project standalone-pom: File not found
 /Users/hinmanm/Downloads/datomic-free-0.8.3331/pom.xml:
 /Users/hinmanm/Downloads/datomic-free-0.8.3331/pom.xml (No such file
 or directory) - [Help 1]
 
 Looks like a pom.xml file needs to be included in the free version zip
 archive.
 
 - - Lee Hinman
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJQDtrSAAoJEJ1kZdQ6zsrgjiAP/R+h6Z8r0Dldd0+PL7jkm6zj
 RJOqdXwHqKHUDbB8JSM1YrJVJG3CCf5HGTnRlxJ1GhMf6tZ6ncMJvx9P18mVuI6f
 /mJMZqMBUmjPaHmqn9/WK7ZPiCmRh5e7jsoKcSRINv6R3dgf1PWU6oEmn2iRRRXf
 HfeQiizW4zAYKEPDmdOhxPnBUzcU3FZsVww9jN2EHnSHbvYWUIB8NvdJcgyGxT99
 9qeQXrlT1HumyNu5C2K9w5Vqreb0Y38Zose8egfXUTGqkKSKBE5TkrWxWBJGYCSp
 0PuyI5Q6nGMiuJXwZgNgPuc5qCH8hjIdI0V9HNn+Sgq1RbhiwMNwia5daITwpzXC
 bycqBuCoBwqM2PG4W5xbwMBI4MJc/57IgurXsrs5nQwDlsKIWYHmLAc6pkq81zNu
 rPyxLAiR6Nt2DBLYgZNvQPq2RvgSU/pq4n/RchvLuB2kOIVrYhMzrdHOiLBZH9i7
 GUE6XSiMWSKLSGWU4GruEb+ZI3f0dcqBif93WJAeCQWGV+x+EtLvzqDiAlmly8bh
 Hc9tRIDm//F9uQVaIyEfFflHatMVzykIASGmAkGDddl4fWkYkU34CFFFnBpHc0Jj
 GuRYQyOrGs0ztkCWvtHDm0PmklIPrTeMkvgYEnjaiOKTYybbuEE1icwozG/qCDxD
 7Dw/159RJ4AzwXKhyGEn
 =GLOQ
 -END PGP SIGNATURE-
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

Stuart Halloway
Clojure/core
http://clojure.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

Fwd: [ANN] Datomic Free Edition

[Stuart Halloway]

0.8.3335 is now on the site, and includes the correct pom.xml.

http://www.datomic.com/get-datomic.html 

Cheers,
Stu

 From: Stuart Halloway stuart.hallo...@gmail.com
 Date: July 24, 2012 1:54:25 PM EDT
 To: clojure@googlegroups.com
 Subject: Re: [ANN] Datomic Free Edition
 
 Working on this, should have a fix shortly.
 
 Stu
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 7/24/12 9:21 AM, Rich Hickey wrote:
 We released a new edition of Datomic today that I think will be of 
 interest to Clojure developers - Datomic Free Edition:
 
 http://blog.datomic.com/2012/07/datomic-free-edition.html
 
 This edition is oriented around making Datomic easier to get, and
 use, for open source and smaller production deployments. Of note
 here is that Datomic Free Edition, in addition to being free, comes
 with a redistributable license, e.g. you can put the Datomic Free
 Edition jar in Clojars.
 
 Datomic Free Edition provides a free database and datalog engine to
 all developers. When combined with Clojure, I think it provides a
 unique path Out of the Tar Pit [1]. I look forward to seeing
 wonderful things created by the Clojure community with this potent
 combination of tools.
 
 Rich
 
 [1] http://shaffner.us/cs/papers/tarpit.pdf
 
 The installation instructions for the free version of datomic don't
 work; they give this command to install locally:
 
 mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic
 - -Dfile=datomic-0.8.3331.jar -DpomFile=pom.xml
 
 Which references the pom.xml file, which does not exist, causing this
 error:
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
 (default-cli) on project standalone-pom: File not found
 /Users/hinmanm/Downloads/datomic-free-0.8.3331/pom.xml:
 /Users/hinmanm/Downloads/datomic-free-0.8.3331/pom.xml (No such file
 or directory) - [Help 1]
 
 Looks like a pom.xml file needs to be included in the free version zip
 archive.
 
 - - Lee Hinman
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJQDtrSAAoJEJ1kZdQ6zsrgjiAP/R+h6Z8r0Dldd0+PL7jkm6zj
 RJOqdXwHqKHUDbB8JSM1YrJVJG3CCf5HGTnRlxJ1GhMf6tZ6ncMJvx9P18mVuI6f
 /mJMZqMBUmjPaHmqn9/WK7ZPiCmRh5e7jsoKcSRINv6R3dgf1PWU6oEmn2iRRRXf
 HfeQiizW4zAYKEPDmdOhxPnBUzcU3FZsVww9jN2EHnSHbvYWUIB8NvdJcgyGxT99
 9qeQXrlT1HumyNu5C2K9w5Vqreb0Y38Zose8egfXUTGqkKSKBE5TkrWxWBJGYCSp
 0PuyI5Q6nGMiuJXwZgNgPuc5qCH8hjIdI0V9HNn+Sgq1RbhiwMNwia5daITwpzXC
 bycqBuCoBwqM2PG4W5xbwMBI4MJc/57IgurXsrs5nQwDlsKIWYHmLAc6pkq81zNu
 rPyxLAiR6Nt2DBLYgZNvQPq2RvgSU/pq4n/RchvLuB2kOIVrYhMzrdHOiLBZH9i7
 GUE6XSiMWSKLSGWU4GruEb+ZI3f0dcqBif93WJAeCQWGV+x+EtLvzqDiAlmly8bh
 Hc9tRIDm//F9uQVaIyEfFflHatMVzykIASGmAkGDddl4fWkYkU34CFFFnBpHc0Jj
 GuRYQyOrGs0ztkCWvtHDm0PmklIPrTeMkvgYEnjaiOKTYybbuEE1icwozG/qCDxD
 7Dw/159RJ4AzwXKhyGEn
 =GLOQ
 -END PGP SIGNATURE-



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Why cannot last be fast on vector?

[Stuart Halloway]

Having separate peek and last, with documented performance characteristics, 
makes it straightforward to reason about how code is likely to perform, a point 
that Mark made earlier.

It is a fundamental design principle of Clojure that, when given two 
approaches, A and B, make primitive the one that could be used to build the 
other.  Clojure's peek and last might be useful to somebody building the 
last that Warren wants.  Warren's last is *useless* for building the peek 
and last that Clojure already has.

Not arguing against having Warren's last.  Just saying that c.c/last ain't 
broken, and is simpler.

Stu

 Even not a single action is taken because of this thread, I still would not 
 consider the thread fruitless. It helped me (and maybe others) understand the 
 issue better.
 
 My point was: you need a clear documentation on a coherent, consistent 
 abstraction, and let the programmer to understand. Just clear documentation 
 is not enough. You can document a very messy system in clear documentation 
 (maybe the US tax code?).
 
 Here, we are having both peek and last, which is not coherent to me. 
 consider the documentation on an alternative design:
 
 last: get the last element from an ordered collection. for queues and linked 
 lists, it takes linear time. for vectors, it takes constant time.
 
 and get rid of peek (we already have first for linked list and queues, 
 right?)
 
 Which one is cleaner?
 
 
 On Friday, June 29, 2012 3:27:57 PM UTC-4, Sean Corfield wrote:
 On Fri, Jun 29, 2012 at 7:51 AM, Warren Lynn wrn.l...@gmail.com wrote: 
  1. Put good documentations on the functions, and the programmer needs to 
  have some idea what data structure is fast/slow for what use. 
 
 At the risk of continuing what is quickly becoming a rather fruitless 
 thread, I figured I'd quote the docstrings from last and peek: 
 
 last: Return the last item in coll, in linear time 
 
 peek: For a list or queue, same as first, for a vector, same as, but 
 much more efficient than, last. If the collection is empty, returns 
 nil. 
 
 That seems like pretty good documentation to me. (last my-vector) is 
 documented to be a linear operation. (peek my-vector) is documented to 
 be much more efficient. last is not dependent on the type of its 
 argument, peek is. 
 -- 
 Sean A Corfield -- (904) 302-SEAN 
 An Architect's View -- http://corfield.org/ 
 World Singles, LLC. -- http://worldsingles.com/ 
 
 Perfection is the enemy of the good. 
 -- Gustave Flaubert, French realist novelist (1821-1880) 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

Stuart Halloway
Clojure/core
http://clojure.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: Is there a reason why 'some' returns nil instead o false?

[Stuart Halloway]

(doc boolean)

Cheers,
Stu

Stuart Halloway
Clojure/core
http://clojure.com

  (defmacro in?
   Returns true if colle contains elm, false otherwise.
   [colle elm] 
  `(if (some #{~elm} ~colle) true false))
 
 Yes. Should not be a macro. (There is no reason for it to be a macro).
 On top of that, it is not very often useful to convert nil to false as 
 clojure understands nil/not-nil as false/true everywhere.
 (Someone corrects me if there is a counter example.)
 
 Might be useful for java interop?
 Then I would define a 
 (defn to-bool [x]
(if x true false))
 and use it when necessary.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: [PATCH] RFC: Add Functions `tabify` And `untabify`

[Stuart Halloway]

Whatever we do let's make sure we think about how to make it available in all 
Clojure dialects.

Stu

 On Jun 8, 2012, at 8:49 AM, Jay Fields wrote:
 
 I wouldn't mind seeing more in clojure.string. e.g. daserize, underscore, 
 pascal-case, camel-case
 
 +1
 
 
 -
 Brian Marick, Artisanal Labrador
 Contract programming in Ruby and Clojure
 Occasional consulting on Agile
 www.exampler.com, www.twitter.com/marick

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Clojure for shell scripts

[Stuart Halloway]

Hi Ned,

I think the medium-term strategy likely to yield good results is for someone to 
put together a story around ClojureScript + advanced mode + V8.  I know a few 
people have played with this, but I am not sure if anyone has gone so far as to 
package it up for easy consumption.

Stu


Stuart Halloway
Clojure/core
http://clojure.com

 Hey everyone!,
 
 I know this is an old story.
 
 I've played with clojure, but the main thing that has kept me from
 never looking back is the startup speed.  Hello world! in Java takes
 me .303s, but just java -cp clojure-1.5.0-master-SNAPSHOT.jar takes
 1.989s (sending C-d to close the repl even before it starts).
 Searching around here, I've found -XX:+TieredCompilation knocks me
 down to 1.581s and also
 -Xbootclasspath/a:clojure-1.5.0-master-SNAPSHOT.jar all the way to
 0.938s.
 
 Incidentally, the same tricks with Hello World take me to 0.159s.
 
 Those were major improvements with very little cost; a huge win
 (thanks clojure list!).  Any further easy tips and tricks?  I'd like
 to get to the point where shell scripts aren't painful.  It looks like
 other major hints are nailgun, and never restarting the repl during
 development.
 
 I took the liberty of printing some System.getCurrentMillis from
 clojure.main.  It looks like it takes me 0.666s to enter the
 clojure.main main method, which I didn't entirely expect.  There are
 several static members of clojure.main that need to be initialized,
 these members take ~.520s to initialize in total; almost all of this
 is initializing `Var REQUIRE`.  Presumably this is when most of the
 clojure environment starts to get loaded?
 
 I'm just starting to look into clojure's jvm implementation; does
 anyone have some pointers on how to get quickly up to speed with the
 internals of clojure?
 
 Thanks!,
 
 -- Ned Ruggeri
 



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

1.5.0 alpha1 on the way

[Stuart Halloway]

Build box has done its job, not sure how long it takes to become visible 
through maven central.

You can follow along:

Code changes
https://github.com/clojure/clojure.

Issue tracking
http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=10002.

Dev mailing list
https://groups.google.com/forum/?fromgroups#!forum/clojure-dev

Thanks to everyone contributing feedback and patches, and special thanks to 
Andy Fingerhut for producing the Friday work lists on the dev mailing list.

Stu


Stuart Halloway
Clojure/core
http://clojure.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: Accessing collections from Datomic datalog queries

[Stuart Halloway]

 I've seen hinted (and I'm pretty sure I've seen examples, but I can't 
 remember where) that Datomic can incorporate data from regular Clojure 
 collections.  Is there some doc for this or an example?  
 
 Thanks in advance

Hi Mark,

I have moved this to the Datomic group and answered it there: 

Prose:
https://groups.google.com/forum/?fromgroups#!topic/datomic/sELmS3gAUUY

Code:
https://gist.github.com/2645453

Cheers,
Stu

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: code as data vs. code injection vulnerability

[Stuart Halloway]

 This is the point! On one hand I need to evaluate data from a client
 on the other hand I'd like to filter out things like rm -rf /, drop
 table users etc. To me it looks like a contradiction impossible to
 circumvent. So I ask if there's anything like best practices or even
 better something like a concept of access rights or prepared
 statements in clojure?. AFAIK there isn't any. So this problem must be
 solved on the host platforms (database, operating system etc). To me
 this looks much like a wheel-reinventing...
 
 Or you can just use something like XML or a custom language for data 
 transfer, which also avoids trying your clients to Clojure. I've never 
 understood why anyone would use prn/read for data transfer, other than 
 extreme laziness.

(1) Using Clojure as a print/read format does not tie your clients to Clojure. 
Readers exist in many languages, and are easy to implement. 

(2) XML, despite its baroqueness, is extensible. So is Clojure data. This is a 
big advantage, and many approaches lack it.

Cheers,
Stu


Stuart Halloway
Clojure/core
http://clojure.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: Data vs API

[Stuart Halloway]

 I've read in some recent posts that Clorujians prefer data to APIs.  I'm not 
 sure I understand what this means, in practice.  When I'm in the early stages 
 of developing an application, the data structures undergo a great deal of 
 change.  One of the ways, I isolate parts of the code from these sorts of 
 changes is by writing accessor functions.  Maybe this is OO thinking but it 
 seems to me a wise application of DRY.  
 
 Would these accessor functions be considered an API?  If so, why should I 
 prefer accessing the raw data structure?  If not, what is constitutes an API?

(1) You always have to choose a representation for your data.

(2) Having chosen a data representation, if you make an accessor function API, 
you now have two representations. This is the very opposite of DRY. If you 
think that the representation implied by the accessor functions is better/more 
stable than the data representation, then choose a data representation like the 
one implied by your accessor functions.

(3) If you have helper functions for dealing with a particular representation, 
those helpers can and should be separate from the representation itself. For 
example, a customer order is some combination of maps, vectors, etc.  
totalPrice is never a member function of some accessor-riddled Order object -- 
it is instead a plain function that knows how to navigate a data representation 
(or, via a la carte polymorphism, many different representations).

Cheers,
Stu


Stuart Halloway
Clojure/core
http://clojure.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