Re: [ANN] stateful-check 0.4.0 - test stateful systems with test.check

[Lucas Bradstreet]

Thanks Carlo! I've enjoyed using stateful-check in the part, and I'm
looking forward to trying the update.

On 12 February 2018 at 14:32, Carlo Zancanaro  wrote:
> Hey everyone!
>
> I've just released a new version of my library for testing stateful systems
> with test.check! Now with added race condition detection!
>
>  [org.clojars.czan/stateful-check "0.4.0"]
>
>  https://github.com/czan/stateful-check
>  https://clojars.org/org.clojars.czan/stateful-check
>
> This version is a major release, and given the long timescale (my last
> release was August 2015), I've taken the chance to break a lot of things. In
> return, though, we can now run parallel test cases to detect race
> conditions. If you watched John Hughes' talk at Clojure/West 2014[1], then
> you have some idea of what I'm talking about. If you haven't watched it,
> then you should, because it's great.
>
> The main changes are:
>
> - more clearly delineate separate phases (generation, execution,
> verification), this most noticeably changes the time when postcondition
> functions are run, and what they are permitted to do
>
> - add support for race condition detection (see doc/queue.org[2] for an
> example, and see doc/race-conditions.org[3] for a bit of explanation about
> what it's testing)
>
> - change to the MIT license
>
> If you've used stateful-check before then you should be careful and check
> your assumptions before doing things. If you've not used stateful-check
> before then now might be a fun time to give it a go!
>
> Carlo
>
> [1]: https://www.youtube.com/watch?v=zi0rHwfiX1Q
> [2]: https://github.com/czan/stateful-check/blob/0.4.0/doc/queue.org
> [3]:
> https://github.com/czan/stateful-check/blob/0.4.0/doc/race-conditions.org
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8

[Lucas Bradstreet]

Thanks Sean. You make an excellent point with specs being in a
separate namespace. I had thought that using fdef would have prevented
doing something like this but it appears I am wrong.

On 30 June 2016 at 01:20, Sean Corfield <s...@corfield.org> wrote:
> On 6/29/16, 10:03 AM, "Lucas Bradstreet" <clojure@googlegroups.com on behalf 
> of lucasbradstr...@gmail.com> wrote:
>> Sean, a lot of library developers still want to support Clojure 1.8,
>> but this would prevent using spec with their projects.
>
> clojure.java.jdbc solves that by having the specs in a separate namespace 
> (and by the tests conditionally loading that and clojure.spec.test). 
> clojure.java.jdbc supports back to Clojure 1.4.
>
> Nikita, it would be interesting to know how far back (in Clojure versions) 
> your library could support. I can see real value in being able to back port 
> spec beyond 1.8…
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8

[Lucas Bradstreet]

This looks great Nikita.

Sean, a lot of library developers still want to support Clojure 1.8,
but this would prevent using spec with their projects. This would help
there. Onyx in particular was going to avoid using spec for the time
being, but we may re-evaluate now.

On 30 June 2016 at 00:31, Sean Corfield  wrote:
> Interesting idea.
>
>
>
> If you’re already on Clojure 1.8, I think it’s pretty safe to upgrade to the
> Alpha builds of 1.9. We’re running 1.9 Alpha 7 in production at the moment
> (and will move to Alpha 8 in our next build after today).
>
>
>
> The only glitches we ran into were name collisions in libraries due to new
> predicates being added to core, and only one of those caused an actual
> breakage – and those libraries all got updated very quickly (big thanks
> mostly to Peter Taoussanis for the fast responses).
>
>
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
>
> On 6/29/16, 5:16 AM, "Nikita Prokopov"  of proko...@gmail.com> wrote:
>
>
>
> Hi!
>
>
>
> Not sure if a good idea or bad, but if you were eager to play with latest
> version of clojure.spec but don’t want to upgrade your production to alpha
> version of the language, you can add clojure.spec capabilities as a library
> to 1.8:
>
>
>
> https://github.com/tonsky/clojure-future-spec
>
>
>
> :dependencies [
>
>   [org.clojure/clojure "1.8.0"]
>
>   [clojure-future-spec "1.9.0-alpha8"]
>
> ]
>
>
>
> (require '[clojure.spec :as spec])
>
> (require '[clojure.spec.gen :as spec.gen])
>
> (require '[clojure.future :refer :all])
>
>
>
> clojure.future namespace contains all new clojure.core functions like int?,
> seqable? etc
>
>
>
> The version numbers will follow clojure 1.9 versions. Expect this lib
> upgraded with every new Clojure alpha release until 1.9 if finally out.
>
>
>
> Nikita.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[lucas . bradstreet]

Hi Josh,

I am one of the core Onyx developers, so I am biased in some respects. I'm 
going to only speak to specific advantages that code > data gives Onyx.

An advantage with Onyx is the ability to build up your jobs dynamically 
using data that is easily transformable by code, using all of the functions 
that you use in clojure e.g. conj, assoc, update, get, etc. Data in clojure 
is far more easily manipulated by core functions than XML, ensuring that 
you can do things like build up a job from a base system, add arbitrary 
numbers and types of tasks, parameters, lifecycles, and options to your job 
for different purposes.

This ensures that Onyx is very flexible - complex jobs do not have to be 
simply stored in lengthy static EDN files, they can be built by code from 
job to job, depending on your needs. To give an example, imagine a case 
where you wanted to load data from an arbitrary number of queue 
datasources, and an input plugin only allows a single queue name to be read 
from in a single task - you can easily transform your job's workflow and 
catalog to expand out an arbitrary number of tasks to read from these 
queues, annotating the input data with the queue name, all directed at 
another task that you define. If you wish to sometimes add some debugging 
metrics, you can do so by transforming the job, etc. If tasks within a job 
are not the correct level of granularity, you could instead dynamically 
build multiple jobs and submit them all to the cluster.

Mike brings up a good point around performance concerns around data > code. 
With respect to Onyx, the "dataness" of Onyx jobs is very often compiled 
down to records and more performant representations. This ensures that the 
dataness at the user level isn't lost, while ensuring performance for the 
common case. In some ways you can think of the data in the Onyx job as the 
AST for the Onyx job, which is validated, and then compiled for 
performance. It would be quite easily to build code over this data which 
ensured you never had to touch the data that defined the job, especially 
since the core code functionality, a task's onyx/fn, is a plain clojure 
function, operating using whatever Clojure/Java objects you want. We don't 
think this is generally a good idea, but you have the ability should you 
need it.

When these jobs are submitted to the cluster, this data is serialized and 
stored in ZooKeeper, to be read back by the cluster for scheduling 
purposes. This data is human readable when viewed in a dashboard, usable in 
ClojureScript (even allowing jobs to be built and dispatched by web clients 
- at which point you may need a data representation anyway), or 
transformable e.g. if you inspect a previous job's end state and data in 
order to migrate between jobs.

By defining an information model and documentation around the core data 
representation, we can easily present specific documentation to users when 
their jobs fail schema validation for any reason, see 
https://github.com/onyx-platform/onyx/blob/0.8.x/src/onyx/information_model.cljc
 
for the model and documentation map that we use for error messages, and how 
we have additionally leveraged this information model to build a 
ClojureScript page that is a handy reference guide for users 
http://www.onyxplatform.org/docs/cheat-sheet/latest/#/trigger-entry.

Hopefully this answers some of your questions around why I like this 
technique for Onyx, even if I didn't answer your overarching question.

Cheers,

Lucas

On Tuesday, February 2, 2016 at 6:02:23 AM UTC+8, Josh Tilles wrote:
>
> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: 
> Distributed Computing for Clojure” 
> , I'm distracted by a 
> nagging worry that we —as a community— are somehow falling into the same 
> trap as the those advocating XML in the early 2000s. That said, it's a very 
> *vague* unease, because I don’t know much about why the industry seems to 
> have rejected XML as “bad”; by the time I started programming 
> professionally there was already a consensus that XML sucked, and that 
> libraries/frameworks that relied heavily on XML configuration files were to 
> be regarded with suspicion and/or distaste.
>
> So, am I incorrect in seeing a similarity between the “data > code” 
> mentality and the rise of XML? Or, assuming there is a legitimate 
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use 
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is 
> it the case that the widespread backlash against XML threw a baby out with 
> the bathwater, forgetting the advantages of data over code?
>
> Cheers,
> Josh
>

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

Re: Reducing the pain of a clojars outage

[Lucas Bradstreet]

Ouch. I'm not sure what happened to that email. I blame autocorrect.

There were some scaling problems with npm in the past and they ended
up taking funding. The list of issues you've provided look good.
Perhaps some "newbie" tags in the issues would be good too. I will
join the maintainers list.

Thank you for your effort in providing this essential service.

Lucas

On 5 January 2016 at 11:51, Toby Crawley <t...@tcrawley.org> wrote:
> On Mon, Jan 4, 2016 at 3:31 PM, Lucas Bradstreet
> <lucasbradstr...@gmail.com> wrote:
>> Good info. Now that we've performed the initial clojars drive, which was
>> performed at a very fortuitous time, do you think that the problem is
>> primarily one of money, man poweror, or both? I realise that there's a lot
>> of kI'm happy to help in I'm one of
>> Ri way, because I think we definitely want to avoid some of the past
>> issues in Node JS - which I think they have mostly solved now
>
> I don't quite follow all of that, but I think I get the gist :)
>
> Seriously though, what issues did the Node JS community have? I
> haven't been involved there at all, so haven't paid attention.
>
> The donations have been great, and I appreciate every bit of it. But
> what we primarily need right now is time from others. For the past
> nine months, I've been the only administrator, but today Daniel
> Compton graciously agreed to help out with that[1], so I think we are
> good there. I also need help with some of the bigger issues (moving
> the repo to block storage[2], possibly behind a CDN[3], and
> implementing atomic deploys[4]), which I plan to post bounties[5] for
> (using some of the donations) in the next few days.
>
> Beyond that, we have quite a few other smaller issues that are ready
> for work (marked with the "ready" tag[6], along with a subjective
> rough estimate of effort involved ("small", "medium", "large")), if
> people are looking for other ways to contribute. And, if you are
> wanting to be more involved in and up to date with what is happening
> with Clojars, I urge you to join the clojars-maintainers list[7].
>
> - Toby
>
> [1]: 
> https://groups.google.com/d/msg/clojars-maintainers/75VmB2F0VX4/hL6dQZAKCQAJ
> [2]: https://github.com/clojars/clojars-web/issues/433
> [3]: https://github.com/clojars/clojars-web/issues/434
> [4]: https://github.com/clojars/clojars-web/issues/226
> [5]: https://www.bountysource.com/teams/clojars
> [6]: https://github.com/clojars/clojars-web/labels/ready
> [7]: https://groups.google.com/forum/#!forum/clojars-maintainers
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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: Reducing the pain of a clojars outage

[Lucas Bradstreet]

Good info. Now that we've performed the initial clojars drive, which was 
performed at a very fortuitous time, do you think that the problem is primarily 
one of money, man poweror, or both? I realise that there's a lot of kI'm happy 
to help in I'm one of
Ri way, because I think we definitely want to avoid some of the past  
issues in Node JS - which I think they have mostly solved now

Lucas

> On 4 Jan 2016, at 5:14 AM, Nando Breiter  wrote:
> 
> I've spent some time looking into both Cloudflare and Fastly over the 
> weekend. Fastly seems to have a sophisticated purging mechanism which the 
> ticket mentions would be a requirement. See 
> https://docs.fastly.com/guides/purging/
> 
> Initial setup is dead easy (for both), basically requiring a signup and a 
> change to the DNS record, adding a CNAME. Fastly charges for bandwidth and 
> caches everything. Cloudflare charges monthly flat rates but only caches the 
> most popular assets, unless the subscriber pays $200 a month. In a nutshell, 
> you have full control over the content cached in the CDN with Fastly and full 
> control of the price paid, but not the service rendered, with Cloudflare.
> 
> 
> 
> Aria Media Sagl
> Via Rompada 40
> 6987 Caslano
> Switzerland
> 
> +41 (0)91 600 9601
> +41 (0)76 303 4477 cell
> skype: ariamedia
> 
>> On Sun, Jan 3, 2016 at 8:00 PM, Toby Crawley  wrote:
>> Cloudflare (or a similar CDN) would be useful - we have an open issue
>> to implement that, but haven't had a chance to get to it:
>> https://github.com/clojars/clojars-web/issues/434
>> 
>> - Toby
>> 
>> On Sat, Jan 2, 2016 at 4:30 AM, Nando Breiter  wrote:
>> > Would CloudFlare help on the short term? I haven't used the service yet, I
>> > just ran across it researching DDoS solutions, but judging from the 
>> > overview
>> > of how it works, it might be able to cache all clojars.org assets in a
>> > distributed manner and handle the DNS issue as well.
>> > https://www.cloudflare.com/ If it would work, the advantage is a very quick
>> > initial setup. All you need to do is let them handle the DNS.
>> >
>> >
>> >
>> >
>> >
>> > Aria Media Sagl
>> > Via Rompada 40
>> > 6987 Caslano
>> > Switzerland
>> >
>> > +41 (0)91 600 9601
>> > +41 (0)76 303 4477 cell
>> > skype: ariamedia
>> >
>> > On Sat, Jan 2, 2016 at 4:31 AM, Toby Crawley  wrote:
>> >>
>> >> Given the recent DDoS-triggered outages at linode (including the one
>> >> today that has been the worst yet, currently 10 hours at the time I'm
>> >> writing this), I've been giving some more thought to how we can make
>> >> future outages less painful for the community.
>> >>
>> >> I have an open issue[1] (but no code yet) to move the repository off
>> >> of the server and on to a block store (s3, etc), with the goal there
>> >> to make repo reads (which is what we use clojars for 99.9% of the
>> >> time) independent of the status of the server. But I'm not sure that
>> >> really solves the problem we are seeing today. Currently, we have two
>> >> points of failure for repo reads:
>> >>
>> >> (1) the server itself (hosted on linode)
>> >> (2) DNS for the clojars.org domain (also hosted on linode)
>> >>
>> >> moving the repo off of the server to a block store still has two
>> >> points of failure:
>> >>
>> >> (1) the block store (aws, rackspace, etc)
>> >> (2) DNS for the clojars.org domain, since we would CNAME the block
>> >>  store (hosted on linode)
>> >>
>> >> Though the block store provider would probably be better distributed,
>> >> and have more resources to withstand a DDoS (but do any block store
>> >> providers have 100% uptime?).
>> >>
>> >> The block store solution is complex - it introduces more moving parts
>> >> into clojars, and requires reworking the way we generate usage stats,
>> >> and how the api gets its data. It also requires reworking the way we
>> >> administer the repo (deletion requests, cleaning up failed/partial
>> >> deploys). And it may not solve the availability problem at all, since
>> >> we still have two points of failure.
>> >>
>> >> I think a better solution may be to have multiple mirrors of the repo,
>> >> either run by concerned citizens or maintained by the clojars staff. I
>> >> know some folks in the community already run internal caching proxies
>> >> or rsynced mirrors (and are probably chuckling knowingly at those of
>> >> us affected by the outage), but those proxies don't really help those
>> >> in the community that don't have that internal infrastructure. And I
>> >> don't want to recommend that everyone set up a private mirror - that
>> >> seems like a lot of wasted effort.
>> >>
>> >> Ideally, it would be nice if we had a turn-key tool for creating a
>> >> mirror of clojars. We currently provide a way to rsync the repo[2], so
>> >> the seed for a mirror could be small, and could then slurp down the
>> >> full repo (and could continue to do so on a schedule to remain up 

Re: crazy idea...

[Lucas Bradstreet]

Kibit (https://github.com/jonase/kibit) does many of the things that
you describe, though it doesn't go as far you dream. It also uses
core.logic to suggest equivalent substitutions.

I'd be happy to see more work in this area.

Lucas

On 29 November 2015 at 02:01, Jules  wrote:
> Guys,
>
> I've had pieces of this idea wandering around my head for years now and have
> finally decided that the time might be right for putting them together in
> the context of Clojure. I'm sure that others have had similar ideas before :
>
> Imagine my Clojure program which reads in your Clojure program and spits out
> a smaller, simpler, faster Clojure program which does exactly what yours
> did...
>
> Of course, you are such a good programmer that your program could not be
> improved ? In which case we need you writing my Clojure program :-)
>
> This is opening the door onto a very large but very interesting problem
> space.
>
> Starting the project off in a language that is homoiconic should deliver
> enormous benefits straight away as the language itself provides a reader, an
> Abstract Syntax Tree (itself) , a macro language (itself) etc...
>
> I have some initial ideas -
>
> - I was thinking of looking at core.logic to see if I might be able to use
> it to match code to which refactorings might be applied.
>
> - I was wondering whether analysing a class/methods transitive bytecode
> might be enough to decide whether a function/method was effectively pure or
> not.
>
> - I was wondering whether a simple initial approach would be to inline all
> but the recursive macros and functions in a program and then work backwards
> from the fully expanded program applying refactorings to extract shared code
> etc.
>
> - I was thinking that some of this machinery would be a nice thing to have
> in a Clojure IDE, advising you about potential refactorings and applying
> them as you type.
>
> - I was imagining that ultimately the inputs might not be have to be
> Clojure, but maybe anything that compiled down to Java bytecode.
>
> - I was wondering whether there was much synergy with core.typed.
>
> - I was wondering whether you could work out how many cpu cycles a function
> might take to run by inspecting its bytecode or optimise for mechanical
> sympathy if your system knew a bit about the right things.
>
> - I was wondering whether my program could benchmark functions then rewrite
> them and benchmark them again to confirm that they were faster.
>
> - i was considering which metrics should be used to decide that a program
> was simpler,
>
> - I was wondering whether a Clojure program could learn much about writing
> Clojure programs from analysing all the Clojure programs stored on e.g.
> GitHub.
>
> - I am dreaming of the day when programs are written by more abstract
> programs which are written by more abstract programs... which are written by
> AIs :-)
>
>
> I guess I am talking about writing an Expert System whose problem domain is
> Clojure [and Java bytecode], which encodes a set of rules for transforming
> one form of its input into another form that in some way satisfies some sort
> of [sub]goal. A system which can plan refactorings from an initial state to
> an 'improved' goal state.
>
> I haven't written any code yet. I realise that this is a huge subject and
> that the best thing to do would be to talk to lots of people much smarter
> than myself about it - so here I am.
>
> What does everyone think ?
>
> Is this worth discussing or just pie in the sky ?
>
> Looking forward to hearing your thoughts,
>
>
> Jules
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 

Re: [ANN] core.async-0.2.371

[Lucas Bradstreet]

Fantastic release. I've been waiting for poll! and offer! for a while.

What is the recommended way to check whether a channel is closed?
Previously if the channel returned nil, then we know the channel is
closed, however with poll! we can't tell between the channel being
closed or just empty.

Thanks again,

Lucas

On 29 October 2015 at 05:06, Alex Miller  wrote:
> I am happy to announce a long-overdue core.async release.
>
> Dependency info:  [org.clojure/core.async "0.2.371"]
>
> There are a few new features in this release:
>
> 1) promise-chan is a function that returns a new kind of channel (with a
> custom buffer) with promise semantics. Specifically, channels make a
> one-time transition to having a deliverable value. promise-chan takes an
> optional transducer, and an optional exception-handler (like chan). A
> promise channel can take exactly one value that consumers will receive. Once
> full, puts complete but val is dropped (no transfer).
> Consumers will block until either a value is placed in the channel or the
> channel is closed (and nil will be delivered).
>
> 2) offer! and poll! are two new non-blocking functions available on
> channels.
>
> offer! puts a val into a channel if it can do so immediately and will never
> block. Returns true if offer succeeds.
> poll! takes a val from a channel if it can do so immediately and will never
> block. Return a value if successful, nil otherwise.
>
> All changes:
>
> ASYNC-103 - NEW promise-chan
> ASYNC-104 - NEW non-blocking offer!, poll!
> ASYNC-124 - dispatch multiple pending takers resulting from expanding
> transducer
> ASYNC-101 - async/reduce now respects reduced
> ASYNC-112 - replace "transformer" with "transducer" in deprecation messages
> ASYNC-6 - alts! docs updated to explicitly state ports is a vector
> Support (try (catch :default)) in CLJS exception handling
> Use cljs.test
> Updated tools.analyzer.jvm version (and other upstream deps) - fixes various
> analyzer errors
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Onyx Platform Release Digest

[Lucas Bradstreet]

The Onyx team is proud to announce some releases of Onyx Platform projects.

Michael Drogalis (https://twitter.com/michaeldrogalis) and myself
(https://twitter.com/ghaz) will both be at Strange Loop this week. If
you're interested in Onyx come find us to have a chat!

== Onyx Redis ==
https://github.com/onyx-platform/onyx-redis

Released onyx-redis 0.7.5.

Thanks to Gardners Vickers https://github.com/gardnervickers, we now
have an official Onyx Redis plugin!

== Onyx Kafka ==
https://github.com/onyx-platform/onyx-kafka

Released onyx-kafka 0.7.5.

Recent versions of onyx-kafka now support auto assigned partition
readers and the ability to write to particular keys and partitions. An
embedded Kafka server is now included with the plugin for easy unit
testing.

== Onyx Datomic ==
https://github.com/onyx-platform/onyx-datomic

Released onyx-datomic 0.7.5.

Recent versions of onyx-datomic include a log reader plugin, to read
from the datomic log in a reproducible and fault tolerant way. This
feature is already being used to good effect in production.

== Onyx Seq ===
https://github.com/onyx-platform/onyx-seq

Released onyx-seq 0.7.5.

Onyx Seq is a new "swiss army knife" plugin to distributed work read
from a seq. This can easily be used to create file reader plugins,
computation plugins, etc.

== Onyx Core ==
https://github.com/onyx-platform/onyx

# 0.7.5
No functional changes in this release. We had a build problem that
wasn't worth fixing across all 0.7.4 releases. Fixed build and trying
again under alias 0.7.5

# 0.7.4
Operations: Onyx now requires Java 8.
API breaking change: update signature of onyx.api/await-job-completion
to take an opts map.
API breaking change: removed Netty and core.async messaging implementations.
API: New catalog entry option :onyx/n-peers to automatically expand to
make :onyx/min-peers and :onyx/max-peers peers the same value. #282
API: Allow functions in leaf position of a workflow. #198
Bug fix: flow-conditions retry default action should emit segments #262
Bug fix: cleaned up publications on write failure

# 0.7.3
Bug fix: Kill-job no longer throws a malformed exception with bad parameters.
Bug fix: Fixed arity in garbage collection to seek the next origin.
Documentation: Fixed Aeron docstring for port allocation
Added schema type-checking to all replica updates in the log.
Allow Aeron to use short virtual peer ID when hashing. #250
Exposed all schemas used for internal validation through onyx.schema
namespace, meant for use in 3rd party tooling.
Allow plugins to write task-metadata to the replica, which will be
cleaned up when jobs are completed or killed #287

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

[Lucas Bradstreet]

I have had a lot of success with nippy https://github.com/ptaoussanis/nippy, 
which is quite well documented. We had problems with fressian round tripping 
Clojure collections, as you've described.

It has a number of other features (compression, encryption) that I may end up 
using. It has given attention to backwards compatibility, and there is a mode 
to turn this backwards compatibility off if it is not required. 

Lucas 



 On 16 Mar 2015, at 09:40, Ryan Schmitt rschm...@u.rochester.edu wrote:
 
 I'm the author of dynamic-object, an open source library that makes Clojure's 
 data modeling power available to Java programmers. This includes features 
 like serialization and deserialization. I'll copy this small usage example 
 from the README to give you a sense of how it works:
 
 public interface Album extends DynamicObjectAlbum {
   @Key(:artist) String getArtist();
   @Key(:album)  String getAlbum();
   @Key(:tracks) int getTracks();
   @Key(:year)   int getYear();
 }
 
 String edn = {:artist \Meshuggah\, :album \Chaosphere\, :tracks 8, :year 
 1998};
 Album album = DynamicObject.deserialize(edn, Album.class);
 album.getArtist(); // = Meshuggah
 
 dynamic-object has always been opinionated about using Edn as the primary 
 data language on the wire, for a number of reasons. For a long time, I also 
 thought about adding Fressian support to dynamic-object, and I've recently 
 done so on an experimental basis. (It looks like this.) Some time after I 
 initially released dynamic-object, Transit was also released, with support 
 for various encodings (JSON, JSON-Verbose, MessagePack).
 
 In working (to different extents) with these data languages, I've had some 
 apprehensions about all of them.
 There is a lack of tooling available for Edn, such as validators and 
 pretty-printers. I spent a while looking for an Edn equivalent of python 
 -mjson.tool and never found one. Clojure's built-in pprint function does not 
 work out-of-the-box to pretty print arbitrary values, and also appears to 
 handle some data structures, such as records, incorrectly. (pprint omits 
 reader tags when printing records.) pprint's underlying implementation, 
 cl-format, is extremely powerful and could almost certainly be used to build 
 a validating Edn pretty-printer, but it would have an unacceptably long 
 startup time.
 There is a lack of high-quality Edn implementations for different languages. 
 Because the Edn spec is not very formal or complete, there seems to be some 
 uncertainty regarding what constitutes an Edn implementation in the first 
 place. For instance, clojure.edn parses the Ratio type as a builtin, even 
 though it is mentioned nowhere in the spec. (Issue.) There are also oddities 
 such as the recommended C++ implementation describing itself as 
 experimental.
 Fressian's reference Java implementation is almost totally undocumented. This 
 is a problem, because I'm writing a library that targets Java developers; 
 they won't be going through the Clojure bindings (which are decently 
 documented). Fressian's source code is outstanding, but it's still not 
 documentation.
 Due to the lack of documentation, it's not clear which parts of Fressian are 
 actually stable. Stuart Halloway's data.fressian talk included some 
 parentheticals about the extension points being subject to change, which so 
 far they haven't, but that might only be because of the following point...
 Fressian does not seem to have gotten any attention since the initial launch. 
 People have submitted GitHub issues, including one surprisingly high-quality 
 bug report, but they have all been ignored. The JIRA is mostly tumbleweeds.
 The Clojure bindings for Fressian, namely data.fressian, are essentially 
 incomplete. With the exception of maps, Clojure collection types do not round 
 trip, and in at least one case (vectors) that is because of a blocking issue 
 in the underlying Fressian implementation.
 There are no documented best practices for the use of Fressian or some of its 
 more advanced features like chunking. It is not clear how to read and write 
 Fressian in a way that facilitates (for instance) ranged reads from the 
 middle of a resource. It is not clear when checksums should be used and how 
 they should be validated. It is not clear whether tags should be namespaced, 
 or how. The only namespaced tag in data.fressian is for IRecord; none of the 
 other type tags are namespaced. It's not clear whether this is due to 
 bugwards compatibility.
 Transit is advertised as a work-in-progress. This is the main reason I 
 haven't seriously considered adding Transit support to dynamic-object.
 However, what happens when Transit is stabilized (if that ever happens)? 
 Since Transit offers a msgpack encoding, will Fressian then be irrelevant 
 (except for legacy use cases)? There's a FUD aspect here--I like Fressian and 
 I want dynamic-object to support it, but I don't want to back the wrong pony 
 and end up having to support 

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

[Lucas Bradstreet]

Thanks for the extra analysis. My feeling was that it would be possible, but I 
wasn't sure. 

Luckily my current use cases don't depend on keeping UUIDs secret, but I was 
still wondering if there was a trade off. A mention in the docs seems 
worthwhile.

Cheers 

 On 4 Mar 2015, at 21:40, danle...@gmail.com danle...@gmail.com wrote:
 
 Also, if someone were given another time based UUID to use as a basis of 
 comparison, they could eliminate 47 more bits of randomness to guess at.  So, 
 I think you make a good point that I think will be worthwhile to mention in 
 my documentation.   Thank you.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group 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: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

[Lucas Bradstreet]

Hi,

Nice work!

I wanted to clarify something: it seems to me that the v1 uuids clj-uuid 
generate are not exactly equivalent or comparable to the uuids generated by 
java.util/randomUUID? It appears that V1 uuids are time (and MAC) based and 
don't use a cryptographic random number generator, so the use cases are 
different and the speed difference seems like more of a trade off. 

If I'm completely off base then please just say so. 

Thanks for the good work. Even with the above limitations I can see myself 
using the faster version in the future. 

Lucas

 On 2 Mar 2015, at 14:52, Jacob Strength mypci...@gmail.com wrote:
 
 That is pretty amazing, I'll have to remember this library next time I need 
 to use UUID's.
 Also I think you meant 450% faster.
 
 On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote:
 Ok, for anyone following my adventures optimizing clj-uuid, I've gotten 
 another substantial win.   
 Check it out:http://danlentz.github.io/clj-uuid
 
 #'uuid/v1:443 nanoseconds
 #'java.util.UUID/randomUUID: 2012 nanoseconds
 
 Also, the test suite has much greater coverage with individual tests for 
 each v1, v,3, v4, v5 uuid version.
 And, finally, there more interesting notes about some of the esoteric 
 details of the node-id representation
 and the way it is calculated to disambiguate it from any legal 802 MAC 
 hardware address.  And more ;)
 
 
 ==
 
 user (criterium/bench (uuid/v1))
 
 Evaluation count: 139356300 in 60 samples of 2322605 calls.
 Execution time mean: 443.707611 ns
 
 
 user (criterium/bench (java.util.UUID/randomUUID))
 
 Evaluation count : 30850980 in 60 samples of 514183 calls.
 Execution time mean : 2.012861 µs
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

[Lucas Bradstreet]

I've been thinking about this for a bit and our posts just happen to be within 
a minute of each other! A hash bucket is filling up somewhere, I just know it!

 On 4 Mar 2015, at 04:13, Colin Yates colin.ya...@gmail.com wrote:
 
 Ha - the irony of you and I posting a message about uniqueness at pretty much 
 the same time :).
 
 On 3 Mar 2015 20:11, Lucas Bradstreet lucasbradstr...@gmail.com wrote:
 Hi,
 
 Nice work!
 
 I wanted to clarify something: it seems to me that the v1 uuids clj-uuid 
 generate are not exactly equivalent or comparable to the uuids generated by 
 java.util/randomUUID? It appears that V1 uuids are time (and MAC) based and 
 don't use a cryptographic random number generator, so the use cases are 
 different and the speed difference seems like more of a trade off. 
 
 If I'm completely off base then please just say so. 
 
 Thanks for the good work. Even with the above limitations I can see myself 
 using the faster version in the future. 
 
 Lucas
 
 On 2 Mar 2015, at 14:52, Jacob Strength mypci...@gmail.com wrote:
 
 That is pretty amazing, I'll have to remember this library next time I need 
 to use UUID's.
 Also I think you meant 450% faster.
 
 On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote:
 Ok, for anyone following my adventures optimizing clj-uuid, I've gotten 
 another substantial win.   
 Check it out:http://danlentz.github.io/clj-uuid
 
 #'uuid/v1:443 nanoseconds
 #'java.util.UUID/randomUUID: 2012 nanoseconds
 
 Also, the test suite has much greater coverage with individual tests for 
 each v1, v,3, v4, v5 uuid version.
 And, finally, there more interesting notes about some of the esoteric 
 details of the node-id representation
 and the way it is calculated to disambiguate it from any legal 802 MAC 
 hardware address.  And more ;)
 
 
 ==
 
 user (criterium/bench (uuid/v1))
 
 Evaluation count: 139356300 in 60 samples of 2322605 calls.
 Execution time mean: 443.707611 ns
 
 
 user (criterium/bench (java.util.UUID/randomUUID))
 
 Evaluation count : 30850980 in 60 samples of 514183 calls.
 Execution time mean : 2.012861 µs
 
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group 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

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

[Lucas Bradstreet]

Hi Dan,

The hash bucket sentence was only a joke about us posting the same
question at the same time :).

I don't have any particular thoughts on whether there's a reason to
use the truly random UUIDs over v1 UUIDs, I just wanted to check
whether the methods were equivalent so I know if I should evaluate
whether v1 UUIDs are appropriate for my use cases. I guess one reason
you might use randomUUID is if you need your UUID to be unguessable to
attackers that might know your MAC address.

Thanks for your reply, it was illuminating.

Lucas


On 4 March 2015 at 11:32, danle...@gmail.com danle...@gmail.com wrote:
 Lucas, if there are any good reasons why one should pay 10 times the cost to
 generate a UUID randomly, I'd like to hear them.

 Thank you very much for your kind words and please see my prior reply to
 Colin.

 Best,
 Dan


 On Tuesday, March 3, 2015 at 3:24:42 PM UTC-5, Lucas Bradstreet wrote:

 I've been thinking about this for a bit and our posts just happen to be
 within a minute of each other! A hash bucket is filling up somewhere, I just
 know it!

 On 4 Mar 2015, at 04:13, Colin Yates colin...@gmail.com wrote:

 Ha - the irony of you and I posting a message about uniqueness at pretty
 much the same time :).

 On 3 Mar 2015 20:11, Lucas Bradstreet lucasbr...@gmail.com wrote:

 Hi,

 Nice work!

 I wanted to clarify something: it seems to me that the v1 uuids clj-uuid
 generate are not exactly equivalent or comparable to the uuids generated by
 java.util/randomUUID? It appears that V1 uuids are time (and MAC) based and
 don't use a cryptographic random number generator, so the use cases are
 different and the speed difference seems like more of a trade off.

 If I'm completely off base then please just say so.

 Thanks for the good work. Even with the above limitations I can see
 myself using the faster version in the future.

 Lucas

 On 2 Mar 2015, at 14:52, Jacob Strength mypc...@gmail.com wrote:

 That is pretty amazing, I'll have to remember this library next time I
 need to use UUID's.
 Also I think you meant 450% faster.

 On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote:

 Ok, for anyone following my adventures optimizing clj-uuid, I've gotten
 another substantial win.
 Check it out:http://danlentz.github.io/clj-uuid

 #'uuid/v1:443 nanoseconds
 #'java.util.UUID/randomUUID: 2012 nanoseconds

 Also, the test suite has much greater coverage with individual tests for
 each v1, v,3, v4, v5 uuid version.
 And, finally, there more interesting notes about some of the esoteric
 details of the node-id representation
 and the way it is calculated to disambiguate it from any legal 802 MAC
 hardware address.  And more ;)


 ==

 user (criterium/bench (uuid/v1))

 Evaluation count: 139356300 in 60 samples of 2322605 calls.
 Execution time mean: 443.707611 ns


 user (criterium/bench (java.util.UUID/randomUUID))

 Evaluation count : 30850980 in 60 samples of 514183 calls.
 Execution time mean : 2.012861 µs


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

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

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

Re: Is there a way to stop a long running expression in the REPL

[Lucas Bradstreet]

Which repl are you using? In lein repl, this does not happen to me, it
just terminates the expression.

On 21 February 2015 at 19:45, Cecil Westerhof cldwester...@gmail.com wrote:
 Sometimes I execute something that takes to long. With Ctrl-C I can cancel
 it, but this also cancels the REPL itself. Is there a way to terminate the
 running command without terminating the running REPL?

 --
 Cecil Westerhof

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

[Lucas Bradstreet]

Onyx is a batch/stream processing hybrid, written in Clojure, for
Clojure. https://github.com/MichaelDrogalis/onyx

Today I released a dashboard for Onyx, that leverages Onyx's
information model to provide some nifty monitoring and job management
features. You can read about its use of its information model, and
view some nice screen shots at
http://lbradstreet.github.io/clojure/onyx/distributed-systems/2015/02/18/onyx-dashboard.html.

You can find the code and uberjar release at
https://github.com/lbradstreet/onyx-dashboard.

Cheers

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

Re: [ANN] cqrs-server - An opinionated CQRS/ES implementation using Onyx, Datomic, DynamoDB, Kafka and Zookeeper.

[Lucas Bradstreet]

Just a small clarification: both Storm and Onyx both depend on Zookeeper. Onyx 
is masterless as of 0.5.0, however it still requires Zookeeper IN order to 
write an append only log used by the peers in order to coordinate. In contrast 
to Storm, Onyx does not have dedicated coordinator nodes (in Storm these are 
Nimbus nodes). The masterless design is described at 
http://michaeldrogalis.github.io/jekyll/update/2015/01/20/Onyx-0.5.0:-The-Cluster-as-a-Value.html.
 

Lucas

 On 14 Feb 2015, at 07:57, Christopher Small metasoar...@gmail.com wrote:
 
 I'll chime in with a couple of comments about Storm vs Onyx.
 
 I've used Storm in a production application, so I'm fairly familiar with it. 
 I haven't spent too much time playing with Onyx yet, but will be soon. From 
 what I do know about it and Storm though, I can say the following:
 
 Both Storm and Onyx are similar in that you specify distributed computations 
 via computational topologies. So in general, you can do similar pretty things 
 with them. So for the differences:
 Storm is certainly much more mature at this point.
 At the moment, Storm is much faster, though Michael D. has some plans for 
 stealing some of the performance tricks and intergrating them into Onyx.
 The main difference: As Deon points out, Storm's functionality is heavily 
 built on macros, and rather opaque. In contrast, Onyx embraces using simple 
 data structures to describe the flow of a computation. This makes the 
 specification of computational flow much more modular and composable, to the 
 extant that it's even possible to modify the computational flow at runtime.
 Onyx is built from the ground up in Clojure, for Clojure, whereas Storm has a 
 lot of Java under the hood, and places stronger emphasis on it's Java API 
 than it's Clojure API
 Onyx is moving (has moved? forget now...) to a very clever masterless 
 architecture, while Storm depends on Zookeper, which is a pretty massive 
 piece of software.
 If you need something that's battled tested right away, Storm may be your 
 best bet. But I think as it matures (and it's developing quickly and 
 beginning to get production adoption), it's going to win out over Storm, at 
 least within the Clojure community, for the strengths mentioned above. The 
 value of embracing data structures for the sake of composability is well 
 argued and described in Zach Tellman's Always Be Composing talk; this is 
 something that seems to be catching on among Clojurists, and will likely see 
 Onyx gain significant traction.
 
 My two cents...
 
 Chris Small
 
 
 
 On Friday, February 13, 2015 at 11:34:36 AM UTC-8, Deon Moolman wrote:
 Hi Aaron,
 
 Onyx is still quite young, but incredibly promising. I absolutely enjoy the 
 way that they have teased apart the different bits of distributed systems. I 
 highly recommend getting involved in the project, they're going to do great 
 things.
 
 As for Storm, I haven't really used it so I'm not really qualified to 
 comment. I've stayed away from it mostly because the defspout and defbolt 
 macros made a deep part inside me cringe. Other than that, I'm sure it's a 
 perfectly capable platform and I've heard people doing a lot of great things 
 with it.
 
 Onyx really just translates to a library, at the end of the day. You build 
 your application on top of it and manage firing up your peers inside each 
 process yourself. This gives you as an application developer immense 
 flexibilty. Deployment is outside the scope of Onyx - it assumes you've got 
 that covered. I think that's a very wise assumption, given that the ways to 
 deploy jars are diverse.
 
 Cheers,
  - Deon
 
 On Friday, 13 February 2015 02:04:26 UTC+2, Aaron France wrote:
 Hi,
 
 What are your opinions on Onyx?
 
 What are your opinions on Onyx compared to Storm?
 
 What are your opinions on Onyx deployment?
 
 Aaron
  
 
 On Thursday, 12 February 2015 10:15:44 UTC+1, Deon Moolman wrote:
 Hi everyone,
 
 I spent some time putting together an implementation of the CQRS pattern 
 in Clojure and wrote an article on it:
 
 http://yuppiechef.github.io/cqrs-server/
 
 It mostly boils down to an Onyx 
 (http://www.github.com/MichaelDrogalis/onyx) configuration, but it's been 
 an interesting journey that I felt is worthwhile sharing.
 
 Feedback really appreciated!
 
 Cheers,
  - Deon
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, 

Re: which are the pros and cons between stuartsierra/component and prismatic/graph?

[Lucas Bradstreet]

Component is more for managing state, whereas graph is for structuring 
computation. All I can really tell you is that after using component I am never 
going back (at least in Clojure).

Lucas

 On 4 Feb 2015, at 20:46, Juan A. Ruz juanantonio...@gmail.com wrote:
 
 Hi guys!
 
 Can anyone give some insight on the features or downsides of choosing 
 component vs graph libs?
 
 Or maybe explain the advantages of using defrecords instead of plain fns?
 
 thanks in advance! 
 Juan
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group 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: gofmt like tool for Clojure?

[Lucas Bradstreet]

This was released recently: https://github.com/weavejester/cljfmt

On 29 January 2015 at 10:20, Papa Balyo papaba...@gmail.com wrote:
 Greetings,

 Is there a tool that reads .clj(s) source file and prints it in canonical
 fashion? (things like equal number of blank lines between forms, consistent
 placement of arguments vector in defn, etc.)

 I use Cursive IDE and it does nice indentation, but it is not enough.
 Ideally I would like to see code style enforcement before committing to VCS.

 Thanks!

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

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

Re: simple procedure for updating a value one level down

[Lucas Bradstreet]

Given these points I would probably just do:

(defn update-val-with-id [values m]
(map (fn [v]
 (if (= (:id v) id)
 (merge v m)
  v))
  values))

I'm not that happy with it either, so other suggestions are welcome.

On 27 January 2015 at 00:06, Josh Stratton strattonbra...@gmail.com wrote:
 They're not keyed by id because order in both the category and its items is
 important. I could maintain the order explicitly, but that just makes other
 problems like reordering more difficult.

 As a couple people have suggested I could access the page using vector
 indexing, but then I'd need to figure out what those induces are for the
 category and the page given the item id. That seems reasonable, but I'm not
 sure the best way to do that. I'm sure there's some python enumerate
 equivalent where I can map all categories and items and filter down just the
 pair with the matching item id.

 On Jan 26, 2015 7:47 AM, Michael Willis willismich...@gmail.com wrote:

 Now that I think about it, I wonder why your categories aren't keyed by
 id, like this:

 (def categories [ {1 {:text foo} 2 {:text bar :ack 5}} {3 {:age 7}}])

 Then the update-in can take the category id, instead of having to know its
 index within a vector:

 (update-in categories [1 3]  merge { :age 12 :somethingElse 29 })
 [{1 {:text foo}, 2 {:text bar, :ack 5}} {3 {:age 12, :somethingElse
 29}}]


 On Monday, January 26, 2015 at 9:42:56 AM UTC-6, Michael Willis wrote:

 (def categories [ [ { :id 1 :text foo } { :id 2 :text bar :ack 5 } ]
 [ { :id 3 :age 7 } ] ])
 #'user/categories
 (update-in categories [1 0] merge { :age 12 :somethingElse 29 })
 [[{:text foo, :id 1} {:text bar, :ack 5, :id 2}] [{:age 12,
 :somethingElse 29, :id 3}]]


 On Monday, January 26, 2015 at 8:54:58 AM UTC-6, Erik Price wrote:

 Many functions that affect keyed collections will work on vectors if you
 supply the numeric index as a key.

 e

 On Monday, January 26, 2015, Josh Stratton stratto...@gmail.com wrote:

 I'm new to clojure and FP in general.  One thing that has always been a
 little confusing for me is working with immutable trees.  I have a vector 
 of
 categories, each category containing a vector of items--each one a 
 hashmap.
 In that hashmap I have a bunch of attributes including an item-id.  Now,
 assuming I have an item id, what's the easiest way to update the 
 appropriate
 hashmap?  I can't use an assoc, I believe, because my data is in a
 vector--not keyed by the id.

 What I have been doing is writing a function that maps the categories
 to new categories and then write another function that is called on every
 item and updates it iff the item id matches.  This works, but it seems
 really clunky and I'm assuming there's a simpler way to do it.

 ; categories is a vector of item vectors, where the item is a hash
 (def categories [ [ { :id 1 :text foo } { :id 2 :text bar :ack 5 }
 ] [ { :id 3 :age 7 } ] ])

 Is there a more elegant workflow for updating categories?  Let's say I
 want to update item of id 3 with { :age 12 :somethingElse 29 }, what's the
 easiest way to do this?

 ; so the return would be
 [ [ { :id 1 :text foo } { :id 2 :text bar :ack 5 } ] [ { :id 3 :age
 12 :somethingElse 29 } ] ]

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

Re: simple procedure for updating a value one level down

[Lucas Bradstreet]

Are you sure you want to return:
[ [ { :id 1 :text foo } { :id 2 :text bar :ack 5 } ] [ { :id 3
:age 12 :somethingElse 29 } ] ]
(notice the two nested vectors), or rather
[ [ { :id 1 :text foo } { :id 2 :text bar :ack 5 } { :id 3 :age 12
:somethingElse 29 } ] ]

Lucas

On 26 January 2015 at 13:10, Josh Stratton strattonbra...@gmail.com wrote:
 I'm new to clojure and FP in general.  One thing that has always been a
 little confusing for me is working with immutable trees.  I have a vector of
 categories, each category containing a vector of items--each one a hashmap.
 In that hashmap I have a bunch of attributes including an item-id.  Now,
 assuming I have an item id, what's the easiest way to update the appropriate
 hashmap?  I can't use an assoc, I believe, because my data is in a
 vector--not keyed by the id.

 What I have been doing is writing a function that maps the categories to new
 categories and then write another function that is called on every item and
 updates it iff the item id matches.  This works, but it seems really clunky
 and I'm assuming there's a simpler way to do it.

 ; categories is a vector of item vectors, where the item is a hash
 (def categories [ [ { :id 1 :text foo } { :id 2 :text bar :ack 5 } ] [ {
 :id 3 :age 7 } ] ])

 Is there a more elegant workflow for updating categories?  Let's say I want
 to update item of id 3 with { :age 12 :somethingElse 29 }, what's the
 easiest way to do this?

 ; so the return would be
 [ [ { :id 1 :text foo } { :id 2 :text bar :ack 5 } ] [ { :id 3 :age 12
 :somethingElse 29 } ] ]

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

[Lucas Bradstreet]

Hi Mike, Matt,

Some responses below.

On 12 December 2014 at 23:33, Matt Revelle mreve...@gmail.com wrote:
 I had started thinking about this problem recently too and also had broken
 it down to two parts. I was going to create a simple data frame protocol for
 a) and a ggplot2-inspired library which emits SVG for b). There is prior
 work for plotting in Incanter (using JFreeChart) and David Liebke also
 started a SVG-emitting plot library, Analemma
 (https://github.com/liebke/analemma). I believe there is some sort of data
 frame implementation in Incanter.

Thanks. I'll have a look at these. The data frame implementation in
core.matrix is currently quite similar to the incanter data frame
format. However we may find this format limiting, and therefore we're
looking into extending it to matrices with arbitrary dimensionality.
Thanks for the Analemma suggestion, I think some of the ideas will be
useful.


 My motivation was for simple libraries which could be used to generate
 well-designed figures. I frequently end up exporting data from Clojure to R
 only for ggplot2. Having a data frame is useful for designing the plotting
 API or quickly collecting aggregate statistics for certain attributes or
 factor levels.

That's unfortunate, and certainly part of what we are trying to avoid.
Our initial focus is on a clojurescript implementation of the charting
/ figure generation, however the point of the discussion is to ensure
that the charting format/data frame format would be usable from the
clojure/JVM side too.


 On Friday, December 12, 2014 4:29:37 AM UTC-5, Mike Anderson wrote:

 Lucas,

 Thanks for kicking off the discussion - great to see your proposal on
 this. I think it will be really valuable if we can converge on a standard
 way of representing this kind of data in Clojure/ClojureScript. Copying the
 Incanter and main Clojure groups as well because I think there will be broad
 interest in this.

 My view is that it is worth distinguishing (decomplecting?) two things:

 a) The format used to convey the actual data, i.e. the labelled :dataset
 part of the data format suggested below
 b) The format used to specify the chart (chart type, axes etc.)

 I think a) Can be pretty closely linked to the standard core.matrix
 dataset / n-dimensional array structure.

Agreed. We have attempted to follow a similar structure to the
core.matrix dataset implementation, however it looks like this will
prove limiting in the long run. Ideally core.matrix datasets will be
extended to support n-dimensional core.matrix matrices.


 b) is much harder and may call for something more like ggplot2, also worth
 checking out Kevin Lynagh's c2 work (https://keminglabs.com/c2/)

c2 is certainly interesting, though I haven't seen many examples of it
being used in more advanced visualisations. It may be better to wrap
d3 in a more declarative way, though based on our experiences thus far
we may end up fighting between the two models. On the plus side, d3 is
far more battle-tested. Our experience in wrapping d3 based charting
libraries like C3 and Dimple with the OM component model has proven to
be an excellent experience so far. Updates to these charts are only
triggered when data changes, and are handled internally by d3's update
model. However, once if we need to venture outside of these charting
libraries for any other visualisation needs, then we're back to
writing d3 code.


 Therefore it may be easier to tackle a) in isolation first. b) will
 probably need more experimentation before we can settle on something
 sufficiently well designed and general.

I agree that the data frame/set spec is definitely the place to start.

Cheers


 On Thursday, 11 December 2014 17:45:00 UTC+8, Lucas Bradstreet wrote:

 Hi everyone,

 We are currently writing an OM based visualisation / charting library
 that we
 intend to use extensively in combination with core.matrix and other data
 analysis libraries/tools (e.g. gorilla REPL, incanter, etc).

 Some of the goals of this library:
 - Provide a clojurescript wrapper for common visualisation libraries (C3,
   dimple, Rickshaw, NVD3) for standard charting features.
 - Provide a generic data format, with conversion functions to native
 charting
   library formats.
 - Provide transformation functions between core.matrix datasets, incanter
   datasets, etc to this generic charting format.
 - Provide update functions to allow datasets to seamlessly be updated
 with the
   addition of data-points in map and vector formats.
 - Provide seamless transitions when a dataset is updated, ala om.

 We would like to hear any of your thoughts regarding the following
 charting
 data format below. This format maps fairly closely to core.matrix
 datasets
 (note, although core.matrix datasets currently do not allow labelled
 dimensions, this support is incoming).

 {:axes [{:label X axis label :type :category}
 {:label Y axis label :type :category}
 {:label Z axis label :type :measure}
 {:label C axis label

Re: Charting Data Format Feedback Requested

[Lucas Bradstreet]

Hi Jony,

I'm a fan of Gorilla REPL. I'd love to have this work supported with
it. Is it easy to support Clojurescript based renderers within
GorillaREPL? It would be nice to support interactive figures with this
kind of use case (in addition to SVG based plots, of course).

From the responses thus far, it appears that ggplot is the gold
standard for composable, customizable charts. Once we get the
dataframe format right, I'll invest some time into learning what I can
from it. We certainly want any implementation to be as data driven as
possible.

Thanks,

Lucas


On 13 December 2014 at 22:42, Jony Hudson jonyepsi...@gmail.com wrote:
 I think it would be great, and a very useful contribution to the Clojure
 world, to have a flexible plotting library. My perspective, at risk of going
 a bit off-topic, and from the biased position of a Gorilla REPL author ...


 When I think about the sort of programming I do as a scientist - data
 analysis, modelling, numerics, statistics - I have a few requirements:


 - For me, having a notebook interface is essential. It's how I think. It's
 the interactivity of the REPL, plus rich output, plus note-taking.

 - I'd like to write my code in a civilised language. Ideally one that puts
 data first, because that's at the heart of the problems I solve.

 - I want to be able to make things run fast when I need to. So I need some
 ability to write low-level code on occasion.

 - I'd rather not re-write the whole world, so libraries are good.

 - I want to be able to plot things the way I want them.


 If I think about the possible contenders, written as (Notebook interface,
 language, low-level language escape hatch) then the ones I'm familiar with,
 and are advanced enough to use day-to-day for work, are:


 (Gorilla REPL, Clojure, Java)

 (IPython, Python, C)

 (R, R, C)

 (Mathematica notebook, Wolfram language,
 sort-of-C/sort-of-Java/sort-of-.NET)


 In terms of the interface, obviously Gorilla REPL is the best of the bunch
 :-) From a language perspective, my opinion is Clojure/Java wins this
 hands-down. Preaching to the choir here, but Clojure is great for
 data-oriented programming, and importantly for me, it's _really_ easy to
 drop into Java when it matters. Library-wise, all are strong. Each has their
 own advantages, but I'd say the Clojure/Java ecosystem has enough that, for
 what I do, I rarely get stuck. For plotting Mathematica and R are leagues
 ahead. I'm not familiar with the latest developments in Python, but last I
 looked I didn’t see anything doing it the way I think it should be done.


 Which, brings me to why I’m sharing all of this unsolicited opinion … it’s
 because I think a really strong plotting library would position Clojure
 alongside the very best environments to do science and technical
 computing/data science (or whatever it is we’re calling “thinking about data
 with a computer” these days). Gorilla/Clojure works great for me, but I do
 fire up R and Mathematica frequently for more advanced plotting. So, a
 full-featured plot library is something I’d love to see happen, and would be
 interested in working towards.


 In terms of what such a library would look like, while there’s value in
 debating the best way to do it, there’s also value in copying the best
 that’s out there! So I agree with Matt that a ggplot2-alike emitting SVG is
 a good thing to start with. ggplot2 does a great job of making plots
 composable, easily customised etc. And SVG can be rendered to anything, and
 Gorilla supports it natively. The key point, to my mind, would be how to
 make the ggplot API more data-driven, rather than the OO approach that it
 takes.


 So, to summarise my ramble: I think this would be great, and it’s something
 I’d like to be involved with. I’d been planning to give some thought to just
 this after the end of term. Although, I don’t know how that will work out,
 realistically … if everyone on this list manages to do what they’re planning
 to do over the holiday break then January will be a golden age of Clojure!



 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 

Re: test.check slow shrinking

[Lucas Bradstreet]

My thought process with that suggestion is that a shrink of the matrix elements 
(not the size), will not require the samples and probes to be regenerated.

At some point I'll probably have to look into how the shrinking works.

 On 13 Nov 2014, at 06:18, Brian Craft craft.br...@gmail.com wrote:
 
 I tried your idea of generating the size first, then passing it to the matrix 
  vector generators. This does seem to work better. The shrunk cases that 
 return are actually worse, but so far it hasn't wedged itself, which is a 
 great improvement. They all return within a few seconds. I don't yet 
 understand the shrinking well enough to know why it's better.
 
 Example shrunk state:
 
 :samples [0 0 0 0 0 0 0 0 0], :probes [0 0 0 0 0 
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
 0 0 0]
 
 (def gen-matrix-size
   (gen/tuple gen/s-pos-int gen/s-pos-int))
 
 (def gen-mostly-ints
   (gen/frequency [[9 gen/int] [1 (gen/return Double/NaN)]]))
 
 (defn gen-matrix2 [x y]
   (gen/vector (gen/vector gen-mostly-ints x) y))
 
 (defn gen-names [n]
   (gen/vector
 (gen/such-that not-empty gen/string-alpha-numeric)
 n))
 
 (def gen-tsv2
   (gen/bind
 gen-matrix-size
 (fn [[x y]]
   (gen/hash-map
 :probes (gen-names x)
 :samples (gen-names y)
 :matrix (gen-matrix2 x y)
 
 
 On Wednesday, November 12, 2014 12:47:37 PM UTC-8, Lucas Bradstreet wrote:
 I'm pretty sure I did encounter the performance problem you're talking 
 about, but I killed it and re-ran until I hit cases that shrink quickly. I'm 
 afraid I'm not much help with those, although I agree that the bad shrinking 
 is probably related to the performance issues.
 
 On 13 Nov 2014, at 04:22, Brian Craft craft...@gmail.com wrote:
 
 Interesting that you don't see a performance problem. What version did you 
 try? I'm using 0.5.9. 
 
 I just re-ran this example to make sure I wasn't imagining it. On the 11th 
 run, it wedged, not returning, and burning a lot of cpu, presumably trying 
 to shrink.
 
 It's a larger problem with the real test cases. One test ran for about 
 eight hours yesterday before I killed it. Hard to tell what it's doing, and 
 not sure what sort of times I should expect for shrinking larger test cases.
 
 
 On Wednesday, November 12, 2014 9:05:40 AM UTC-8, Lucas Bradstreet wrote:
 I've also had some tricky shrinking type issues with recursive generators 
 using bind. I had a play with your generators, using such-that to reduce 
 the row/column name length and also preventing some generator shrinking by 
 using no-shrink, but I didn't have much luck improving the resulting 
 shrinks (though the shrinks did finish in a timely fashion). 
 
 You might have more luck if you generated an m x n matrix size 
 independently of the matrix itself and feed the size into the matrix 
 generator and the samples and probes generators. This may allow the matrix 
 size to be shrunk down more easily, while also shrinking the samples and 
 probes vectors without them having to be regenerated for ever new matrix 
 shrink (i.e. where the matrix size is maintained but the gen/int values 
 within it are shrunk). 
 
 However, this is all guess work and conjecture, as I don't understand the 
 shrinking algorithm well enough, and I haven't tried my suggestion. Also, 
 modifying your generators in this way may make your model less general if 
 you wish to use it in other ways later. 
 
 Cheers
 
 Lucas
 
 
 
 On 12 Nov 2014, at 02:43, Brian Craft craft...@gmail.com wrote:
 
 Using test.check, I'm finding the shrinking to be very, very slow. 
 Running a hundred cases takes a few seconds, unless it hits an error, in 
 which case it takes 40-60 minutes to shrink, and the shrinking is not 
 very effective (resulting test case is much larger than necessary). 
 Sometimes the shrinking is much faster. It behaves a bit like it's 
 occasionally getting into a pathological state, or a difficult shrinking 
 scenario.
 
 Are there any docs on generators or the shrinking algorithm that would 
 help build tests that shrink more effectively?
 
 The problematic generator builds a randomly-sized matrix of integers, 
 with randomly assigned names for the rows and columns. The failure case 
 is when either a column or row name is repeated. I expect the slow 
 shrinking has something to do with it being rare for the generator to 
 emit the same name twice.
 
 ; Generator of randomly sized matrices of random numbers.
 (def gen-matrix
   (gen/bind
 gen/s-pos-int
 (fn [x] (gen/bind
   gen/s-pos-int
   (fn [y] (gen/vector (gen/vector gen/int x) y))
 
 ; Generator of matrix with probe and sample ids.
 (def gen-tsv
   (gen/bind
 gen-matrix
 (fn [m]
   (gen/hash-map
 :probes (gen/vector 
   (gen/such-that not-empty gen/string-alpha-numeric)
   (count m))
 :samples (gen/vector

Re: test.check slow shrinking

[Lucas Bradstreet]

I've also had some tricky shrinking type issues with recursive generators using 
bind. I had a play with your generators, using such-that to reduce the 
row/column name length and also preventing some generator shrinking by using 
no-shrink, but I didn't have much luck improving the resulting shrinks (though 
the shrinks did finish in a timely fashion). 

You might have more luck if you generated an m x n matrix size independently of 
the matrix itself and feed the size into the matrix generator and the samples 
and probes generators. This may allow the matrix size to be shrunk down more 
easily, while also shrinking the samples and probes vectors without them having 
to be regenerated for ever new matrix shrink (i.e. where the matrix size is 
maintained but the gen/int values within it are shrunk). 

However, this is all guess work and conjecture, as I don't understand the 
shrinking algorithm well enough, and I haven't tried my suggestion. Also, 
modifying your generators in this way may make your model less general if you 
wish to use it in other ways later. 

Cheers

Lucas



 On 12 Nov 2014, at 02:43, Brian Craft craft.br...@gmail.com wrote:
 
 Using test.check, I'm finding the shrinking to be very, very slow. Running a 
 hundred cases takes a few seconds, unless it hits an error, in which case it 
 takes 40-60 minutes to shrink, and the shrinking is not very effective 
 (resulting test case is much larger than necessary). Sometimes the shrinking 
 is much faster. It behaves a bit like it's occasionally getting into a 
 pathological state, or a difficult shrinking scenario.
 
 Are there any docs on generators or the shrinking algorithm that would help 
 build tests that shrink more effectively?
 
 The problematic generator builds a randomly-sized matrix of integers, with 
 randomly assigned names for the rows and columns. The failure case is when 
 either a column or row name is repeated. I expect the slow shrinking has 
 something to do with it being rare for the generator to emit the same name 
 twice.
 
 ; Generator of randomly sized matrices of random numbers.
 (def gen-matrix
   (gen/bind
 gen/s-pos-int
 (fn [x] (gen/bind
   gen/s-pos-int
   (fn [y] (gen/vector (gen/vector gen/int x) y))
 
 ; Generator of matrix with probe and sample ids.
 (def gen-tsv
   (gen/bind
 gen-matrix
 (fn [m]
   (gen/hash-map
 :probes (gen/vector 
   (gen/such-that not-empty gen/string-alpha-numeric)
   (count m))
 :samples (gen/vector 
(gen/such-that not-empty gen/string-alpha-numeric)
(count (first m)))
 :matrix (gen/return m)
 
 Shrinking will result in a case like
 
 {:matrix [[1 4 -3] [-4 -3 -5] [-5 2 3] [4 -5 -5] [1 -2 3] [1 4 1]], :samples 
 [0 0 0], :probes [0 0 0 0 0 0]}
 
 where :samples [0 0] :probes[0] would do.
 
 The following test will exhibit the behavior, sometimes succeeding, sometimes 
 failing quickly, sometimes shrinking for a very long time:
 
 (tc/quick-check 100 (prop/for-all [tsv gen-tsv] (= (count (set (:probes 
 tsv))) (count (:probes tsv)
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group 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: test.check slow shrinking

[Lucas Bradstreet]

I'm pretty sure I did encounter the performance problem you're talking about, 
but I killed it and re-ran until I hit cases that shrink quickly. I'm afraid 
I'm not much help with those, although I agree that the bad shrinking is 
probably related to the performance issues.

 On 13 Nov 2014, at 04:22, Brian Craft craft.br...@gmail.com wrote:
 
 Interesting that you don't see a performance problem. What version did you 
 try? I'm using 0.5.9. 
 
 I just re-ran this example to make sure I wasn't imagining it. On the 11th 
 run, it wedged, not returning, and burning a lot of cpu, presumably trying to 
 shrink.
 
 It's a larger problem with the real test cases. One test ran for about eight 
 hours yesterday before I killed it. Hard to tell what it's doing, and not 
 sure what sort of times I should expect for shrinking larger test cases.
 
 
 On Wednesday, November 12, 2014 9:05:40 AM UTC-8, Lucas Bradstreet wrote:
 I've also had some tricky shrinking type issues with recursive generators 
 using bind. I had a play with your generators, using such-that to reduce the 
 row/column name length and also preventing some generator shrinking by using 
 no-shrink, but I didn't have much luck improving the resulting shrinks 
 (though the shrinks did finish in a timely fashion). 
 
 You might have more luck if you generated an m x n matrix size independently 
 of the matrix itself and feed the size into the matrix generator and the 
 samples and probes generators. This may allow the matrix size to be shrunk 
 down more easily, while also shrinking the samples and probes vectors 
 without them having to be regenerated for ever new matrix shrink (i.e. where 
 the matrix size is maintained but the gen/int values within it are shrunk). 
 
 However, this is all guess work and conjecture, as I don't understand the 
 shrinking algorithm well enough, and I haven't tried my suggestion. Also, 
 modifying your generators in this way may make your model less general if 
 you wish to use it in other ways later. 
 
 Cheers
 
 Lucas
 
 
 
 On 12 Nov 2014, at 02:43, Brian Craft craft...@gmail.com wrote:
 
 Using test.check, I'm finding the shrinking to be very, very slow. Running 
 a hundred cases takes a few seconds, unless it hits an error, in which case 
 it takes 40-60 minutes to shrink, and the shrinking is not very effective 
 (resulting test case is much larger than necessary). Sometimes the 
 shrinking is much faster. It behaves a bit like it's occasionally getting 
 into a pathological state, or a difficult shrinking scenario.
 
 Are there any docs on generators or the shrinking algorithm that would help 
 build tests that shrink more effectively?
 
 The problematic generator builds a randomly-sized matrix of integers, with 
 randomly assigned names for the rows and columns. The failure case is when 
 either a column or row name is repeated. I expect the slow shrinking has 
 something to do with it being rare for the generator to emit the same name 
 twice.
 
 ; Generator of randomly sized matrices of random numbers.
 (def gen-matrix
   (gen/bind
 gen/s-pos-int
 (fn [x] (gen/bind
   gen/s-pos-int
   (fn [y] (gen/vector (gen/vector gen/int x) y))
 
 ; Generator of matrix with probe and sample ids.
 (def gen-tsv
   (gen/bind
 gen-matrix
 (fn [m]
   (gen/hash-map
 :probes (gen/vector 
   (gen/such-that not-empty gen/string-alpha-numeric)
   (count m))
 :samples (gen/vector 
(gen/such-that not-empty gen/string-alpha-numeric)
(count (first m)))
 :matrix (gen/return m)
 
 Shrinking will result in a case like
 
 {:matrix [[1 4 -3] [-4 -3 -5] [-5 2 3] [4 -5 -5] [1 -2 3] [1 4 1]], 
 :samples [0 0 0], :probes [0 0 0 0 0 0]}
 
 where :samples [0 0] :probes[0] would do.
 
 The following test will exhibit the behavior, sometimes succeeding, 
 sometimes failing quickly, sometimes shrinking for a very long time:
 
 (tc/quick-check 100 (prop/for-all [tsv gen-tsv] (= (count (set (:probes 
 tsv))) (count (:probes tsv)
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members

Re: On Testing

[Lucas Bradstreet]

I totally agree about pr-str in test.check. Quite often I want to copy and 
paste the failure into a repl and play around, but need to re-add missing 
quotation marks or quote lists. 

 On 31 Oct 2014, at 22:05, Jessica Kerr jessit...@gmail.com wrote:
 
 My top wish it more readable output from test.check when running within 
 clojure.test
 
 In particular, I want to know the value of each generated parameter at the 
 first failure, and at the simplest failure. Currently that prints as part of 
 a map, but if empty-string is generated, that does not show. (Forking and) 
 printing with pr-str improves it, but I'd like to do a lot more with that.
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] om-bootstrap 0.2.6 released

[Lucas Bradstreet]

Bootstrap doesn't have tables with functionality like that and is used on a 
*lot* of sites, so it's hardly of little use. 

If you need a sortable table, you could write an om wrapper around
https://github.com/glittershark/reactable

I may give this a try soon myself. 

Lucas

 On 16 Sep 2014, at 21:17, Daniel doubleagen...@gmail.com wrote:
 
 Good work.  Although I hate to say it, It's of little use for most projects 
 without more out-of-the-box table options eg searchable, sortable, paginated, 
 never-ending.
 
 On Wednesday, August 27, 2014 2:05:27 PM UTC-5, Sam Ritchie wrote:
 This release adds a bunch of new active components - notably, dropdown 
 buttons, split dropdown buttons and a navbar. The navbar allowed me to beef 
 up the doc site with a proper navbar, more pages and client-side javascript 
 navigation using Secretary and Html5 pushState:
 
 http://om-bootstrap.herokuapp.com 
 
 Code:
 
 https://github.com/racehub/om-bootstrap
 
 Leiningen:
 
 [racehub/om-bootstrap 0.2.6]
  
 
 RELEASE NOTES:
 
 - Upgraded Clojurescript dependency on the doc site to get around this bug: 
 http://dev.clojure.org/jira/browse/CLJS-839. Added a note.
 
 This hash code bug was causing `bs-class-set`'s internal lookup in 
 `class-map` to sporadically fail in Safari 7.0.x.
 
 From https://github.com/racehub/om-bootstrap/pull/13:
 - `om-bootstrap.util/clone-with-props` can now clone proper om  components 
 by injecting extra attributes into the om cursor.
 - `:on-select` handlers on top level nav elements now get called if set,  
 along with the current nav-item `:on-select` handlers
 
 ### New Components
 
 - `dropdown-mixin` (mixins.cljs)
 - `menu-item`, `dropdown-menu`, `dropdown` (button.cljs)
 - `split` (ie, SplitButton) (button.cljs)
 - `navbar` (ie, SplitButton) (button.cljs)
  
 -- 
 Sam Ritchie (@sritchie)
 Paddleguru Co-Founder
 703.863.8561
 www.paddleguru.com
 Twitter // Facebook
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group 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: Productivity tip for code transformations with cider

[Lucas Bradstreet]

The same tip can be used in vim-fireplace with c!! (minus the quotes). 

I find it especially useful when creating tests (as in OP). 

Lucas



 On 15 Sep 2014, at 13:11, Mayank Jain firesof...@gmail.com wrote:
 
 Nice! Thanks for sharing!
 
 On Mon, Sep 15, 2014 at 1:40 AM, Jony Hudson jonyepsi...@gmail.com wrote:
 Why did I never think of using that! Nice :-)
 
 
 Jony
 
 
 On Sunday, 14 September 2014 08:35:16 UTC+1, Stathis Sideris wrote:
 Hello all,
 
 There is some functionality in cider (C-c C-w) that can potentially save 
 you a lot of typing when transforming Clojure code and I haven't seen many 
 people using it, so I made a screencast to demonstrate:
 
 http://www.youtube.com/watch?v=LXhWW1Yqpt0
 
 Hopefully you'll find it useful.
 
 Thanks,
 
 Stathis
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group 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: Optimizing lein profile for Heroku deployment

[Lucas Bradstreet]

A quick fix would be to increase the repl timeout time:

:repl-options  {:timeout 12}

I believe you can also run the repl with a different profile:

e.g. lein with-profile production repl

Lucas

On 26 August 2014 19:28, Jonathon McKitrick jmckitr...@gmail.com wrote:
 I'm able to deploy my project, but 'lein repl' constantly times out.  Yet
 this profile still loads all dependencies for 'lein repl'.  Is there a way
 to prevent this?

 {:user {:dependencies [[pjstadig/humane-test-output 0.6.0]
[ring-mock 0.1.5]
[org.clojars.runa/conjure 2.1.3]]
 :plugins [[lein-ring 0.8.10]
   [lein-cloverage 1.0.2]
   [cider/cider-nrepl 0.7.0]
   [com.cemerick/clojurescript.test 0.3.1]]
 :injections [(require 'pjstadig.humane-test-output)
  (pjstadig.humane-test-output/activate!)]}
  :test {:dependencies [[pjstadig/humane-test-output 0.6.0]
[ring-mock 0.1.5]
[org.clojars.runa/conjure 2.1.3]]
 :plugins [[lein-ring 0.8.10]
   [lein-cloverage 1.0.2]
   [cider/cider-nrepl 0.7.0]
   [com.cemerick/clojurescript.test 0.3.1]]
 :injections [(require 'pjstadig.humane-test-output)
  (pjstadig.humane-test-output/activate!)]}}


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