Re: Building a formatter like gofmt for Clojure

[Marc O'Morain]

Hi Daniel,

I think that this is a great idea. I'm a big fan of gofmt, because it has
no options - it prevents any discussion of indentation and instead allows
code-reviews to be focused on the code itself.

Marc

On Tue, 18 Dec 2018 at 20:42, Daniel Compton 
wrote:

> Hi folks
>
> In the last ten years or so, source code formatters with limited/no
> configuration have become popular. Go is the most well-known example,
> shipping with gofmt, but there are similar tools in Rust, JavaScript,
> Python, and Elixir.
>
> Clojure and Lisps, in general, have historically allowed very flexible
> formatting of s-expressions. This can aid readability but adds a cognitive
> overhead for readers used to different styles. It can also be challenging
> to match existing source code formatting if you are using a different
> editor to the original author.
>
> *I believe it would be useful for the Clojure community to be able to
> develop (or adopt) a single source-code formatter which is able to format
> Clojure source code to a canonical format.* It seems unlikely that 100%
> (maybe not even 50%) of the community would want such a tool, but I feel
> like there is enough desire for a common formatting tool that this could
> still be valuable.
>
> I've created a discussion thread
> 
> on ClojureVerse about building a Clojure/ClojureScript source code
> formatter as part of CLJ Commons . There are a
> few differences in goals between this tool and the existing ones that
> exist. I go into more detail in the thread, but I'm proposing the creation
> of
>
> * A fairly canonical format for Clojure code, e.g. reindenting code,
> reformatting namespace declarations. A format that has idiomatic opinions.
> * A formatting spec and test suite that multiple different tools and
> editors can implement, not a spec defined by the implementation of a single
> tool.
> * The creation of a reference implementation formatter.
> * A formatter with few (maybe zero?) options
>
> It's possible that 10 years after Clojure's creation, it's going to be too
> difficult for the community to coalesce around a canonical format, and it
> will be necessary to add some configuration options. I'm not really sure,
> which is why I'm asking for community members to join in the discussion.
>
> I realise that I'm touching the third rail
>  here, and lots of
> people have strong opinions about formatting. I don't expect that everyone
> would like or want to adopt such a strict formatting tool, and that's
> totally ok! For those of you that *do* like the idea of building/having
> such a tool, please jump in on the discussion on ClojureVerse, and on a
> GitHub repo discussing the different aspects of formatting at
> https://github.com/clj-commons/formatter.
>
> Thanks, Daniel.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Marc O'Morain]

Hi Daniel,

Well done on the podcast.

I listen every week, it's great!

Marc

On Wed, 28 Nov 2018 at 20:07, Daniel Compton 
wrote:

> Hi folks
>
> I've started a podcast "The REPL" about Clojure and ClojureScript to
> accompany the weekly newsletter. I've written a little bit about the
> background of starting it on my personal site
> , and you can
> subscribe to the podcast or listen online at https://www.therepl.net.
>
> The REPL focuses on diving into Clojure programs and libraries in a
> discussion with their creators. I've talked with a bunch
>  of awesome people already, and have
> some great episodes in the pipeline too.
>
> If you like podcasts, then give it a try, perhaps on your way
>  to The Conj
> this week?
>
> Thanks!
> Daniel.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.10.0-RC1 (please test!)

[Marc O'Morain]

Yeah, nice work on getting to a RC Alex 
On Thu, 11 Oct 2018 at 16:32, Alex Miller  wrote:
>
> Thanks, good to hear.
>
> On Thursday, October 11, 2018 at 10:29:22 AM UTC-5, Rick Moynihan wrote:
>>
>> Hi  Alex,
>>
>> I've tried updating 4 of our projects to 1.10.0-RC1 and running their test 
>> suites etc and have uncovered no issues so far.
>>
>> Many, many thanks to everyone for their hardwork!
>>
>> R.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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: Scripting with Clojure / "slow" boot time

[Marc O'Morain]

On 10 February 2016 at 16:36, Alex Miller  wrote:
> Parallel loading is something I've looked at a little bit. Unfortunately
> theory is easier in theory than in practice. :) While in many cases, it
> probably works fine, it's possible for there to be problematic ambiguity
> with which namespace is loaded first, especially for things that update
> stateful things in the Clojure runtime (protocol extensions, multimethod
> cases, namespaces, the dynamic classloader, etc). Perhaps you've heard that
> mutable state and concurrency are problematic. :) I think it's been
> interesting to see the issues that ClojureScript has found as they've
> implemented parallel compilation as they are likely similar.

Yeah, I was thinking along these lines too – parallel loading of files
could leave to non-deterministic compilation.

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

[Marc O'Morain]

Hi Alex,

I've love to offer any help/test data on this that I can. At CircleCI we
run (among other processes) a large Clojure app that takes 2 minutes to
load on a top of line Macbook Pro, with Java 1.8 (Hotspot) . From my best
efforts at profiling, this time is all spend in the Clojure Compiler and
the JVM class loader, loading all transitive dependencies. Mike's analysis
above is totally in line with what we see.

One thing I have noticed is that all compilation runs in a single thread.
In theory all namespaces required in an `ns` form can be loaded in parallel.

If there is any profiling you would like me to run on the code-base, please
let me know.

Marc

On 10 February 2016 at 08:22, Mikera  wrote:

> Good initiative, I've filled in a response to the survey.
>
> One thing that strikes me is that the main issue with loading time is the
> time required to transitively load and compile all the referred namespaces
> (which can be a lot in a big project...). This in turn may trigger class
> loading of Java libraries, IO as various resources are initialised etc. An
> observation is that a lot of this is often not required initially, so there
> *might* be a clever strategy to mitigate this through laziness.
>
> This could be something like:
> - When loading the current namespace, *don't* load referred namespaces
> (yet)
> - Create lazy placeholders within vars in the current namespace for (for
> every def, defn etc.)
> - Only when the placeholder is deref'd / invoked then compile the relevant
> function and pull in dependencies.
> - After first deref / invocation, replace the placeholder with the full
> compiled function / value, so that subsequent access has no overhead
>
> This would be a pretty big change, and might break tools that make
> assumptions about order of loading of namespaces... but I think it would
> solve 90% of the boot time problems if implemented correctly.
>
> The other potentially big win would be concurrent loading of namespaces.
> Guess you are looking at that already?
>
>
>
> On Wednesday, 10 February 2016 02:36:43 UTC+8, Alex Miller wrote:
>>
>> I'm doing some research on slow Clojure boot time and would be interested
>> in collecting info about example use cases where it's been a problem for
>> people.
>>
>> http://goo.gl/forms/eSpn8M5FNB
>>
>> I'm not expecting to release the results in any formal way, mostly
>> looking to use it to pull out particular use cases and/or commonalities
>> across anecdotes so that we can work on boot time problems that matter the
>> most (and solutions likely to help the most). Any numbers you can provide
>> would be great.
>>
>> Alex
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Marc O'Morain]

The `get-in` function will help you:


user=> (def result {:results [{:series [{:name "solr.numPedidos5", :columns
["time" "last"], :values [["1970-01-01T00:00:00Z" 0]]}]}]})
#'user/result

user=> (get-in result [:results 0 :series 0 :values 0 1])
0


On 21 January 2016 at 15:29, Alex Latorre 
wrote:

> Hi all,
>
> I'm trying to get a value from a JSON. I query an influxdb database and I
> get the next reply:
>
> {:orig-content-encoding gzip, :trace-redirects 
> [http:///query?pretty=true;db=riemann;q=select%20last(value)%20from%20%22solr.numPedidos5%22%20where%20idTag%20=%20%27ADE99003392%27],
> :request-time 4, :status 200, :headers {Connection close, Content-Length
> 165, Date Thu, 21 Jan 2016 15:24:24 GMT, X-Influxdb-Version 0.9.2,
> Request-Id 0db6c40f-c053-11e5-909c-, Content-Type
> application/json}, :body {
> "results": [
> {
> "series": [
> {
> "name": "solr.numPedidos5",
> "columns": [
> "time",
> "last"
> ],
> "values": [
> [
> "1970-01-01T00:00:00Z",
> 0
> ]
> ]
> }
> ]
> }
> ]
> }}
>
> I get the JSON with (:body):
>
>  {
> "results": [
> {
> "series": [
> {
> "name": "solr.numPedidos5",
> "columns": [
> "time",
> "last"
> ],
> "values": [
> [
> "1970-01-01T00:00:00Z",
> 0
> ]
> ]
> }
> ]
> }
> ]
> }
>
> I parse it with cheshire with (json/parse-string ... true):
>
> {:results [{:series [{:name solr.numPedidos5, :columns [time last],
> :values [[1970-01-01T00:00:00Z 0]]}]}]}
>
> Now with (:results ...) I get:
>
> [{:series [{:name solr.numPedidos5, :columns [time last], :values
> [[1970-01-01T00:00:00Z 0]]}]}]
>
> but now I don't know how to extract more values. I want to get the number
> "0" from :values and I don't know how to get it.
>
> I would be very grateful if someone can help me with it.
>
> Thank you so much!
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] New clojure.org!

[Marc O'Morain]

Very nice! Good job all.

On 14 January 2016 at 15:45, Alex Miller  wrote:

> The new http://clojure.org is alive!
>
> Most of the content on the site is the same content as before (but in a
> new shinier package). However, the site is now sourced from the public repo
> at https://github.com/clojure/clojure-site and is open for contribution.
> Contributions (via pull request) require a signed Clojure Contributor
> Agreement, just as with Clojure itself - if you've already signed it, then
> you don't need to do anything additional.
>
> We have been working on several new guides for the new Guides section and
> you can see things in process at
> https://github.com/clojure/clojure-site/issues - feel free to discuss on
> issues there or threads here with a [DOC] indicator. Or on the #docs
> channel on Slack.
>
> Big thanks to Tom Hickey on the design for the new site! As always, he was
> a pleasure to work with.
>
> Alex
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Can direct linking allow compile-time artiy checks?

[Marc O'Morain]

Hi all,

Now that Clojure 1.8 supports direct linking, in theory compiler should be
able to throw an error when the user tries to call a function with the
wrong arity, since the callee must be known the compiler, and the callee
cannot be redefined.

This would be a really great improvement to the compiler since it would
turn potential run-time errors into compile-time errors.

Is something like this possible now?

Thanks,

Marc

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

[Marc O'Morain]

We have a large app at CircleCI - as of September:





"The repo for our main app contains 93,983 lines of Clojure code. The src 
directory of our main app contains 369 namespaces."





http://blog.circleci.com/why-were-no-longer-using-core-typed/

On Sun, Nov 15, 2015 at 7:22 PM, null  wrote:

> I've been having a (friendly) argument with a friend who is an old-school 
> OOP programmer.  He insists that you need objects to make large-scale 
> codebases legible and maintainable over the long run.  Quite apart from 
> this argument's virtues or lack thereof, this made me curious -- what are 
> the largest programs written in Clojure in terms of LOC?  I know I've seen 
> mentions of 50k-100k LOC projects (World Singles, if I'm remembering 
> correctly), but are there any that are larger?
>Vikram
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] Clojure 1.8.0-beta1

[Marc O'Morain]

FYI - Trying to upgrade CircleCI I get a syntax error in clj-ssh (passing
too many argument to throw):

https://github.com/hugoduncan/clj-ssh/issues/39

I've logged the issue with them.



On 13 October 2015 at 15:01, Alex Miller  wrote:

> Clojure 1.8.0-beta1 is now available.
>
> Try it via
>
>- Download:
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-beta1
>- Leiningen: [org.clojure/clojure "1.8.0-beta1"]
>
> Below is a list of the other changes included in beta1. See the full
> change log here: https://github.com/clojure/clojure/blob/master/changes.md
> .
>
>
>- CLJ-1456  Compiler now
>errors if too few or too many arguments to throw
>- CLJ-1282  quote now
>throws if passed more or less than one arg
>- CLJ-1210  Improved
>error message for (clojure.java.io/reader nil)
>- CLJ-1414  sort and
>sort-by now indicate sort is stable in docstring
>- CLJ-1765  areduce
>performance improvements
>- CLJ-1724  Remove
>unnecessary call to seq() in LazySeq.hashCode()
>- CLJ-1295  Improved
>array-map dissoc performance
>- CLJ-1277  Speed up
>printing of time instants with type hints
>- CLJ-1259  Speed up
>pprint and cl-format with type hints
>- CLJ-668  Improve slurp
>performance by using StringWriter and jio/copy
>- CLJ-1810  ATransientMap
>now marked public
>- CLJ-1653  str of an
>empty list should be "()"
>- CLJ-1567  Removed
>unused local in condp implementation
>- CLJ-1351  Unused
>swapThunk method was being emitted for fns with keyword callsites
>- CLJ-1329  Removed
>unused local in PersistentVector.cons()
>- CLJ-1380  3-arg
>ExceptionInfo constructor permitted nil data
>- CLJ-1226  set! of a
>deftype field using field-access syntax caused ClassCastException
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.8.0-beta1

[Marc O'Morain]

I just ran the CircleCI code-base under 1.8 beta 1 to see if there were any
gains in compile time (which is in the region of 90 seconds for our main
app). The clj-ssh issue was the only third-party lib that didn't work.

Here is our compile time on Clojure 1.7 and 1.8:

Clojure 1.7:
real 1m30.622s user 1m32.535s sys 0m4.182s
real 1m33.238s user 1m36.139s sys 0m4.381s

Clojure 1.8 beta 1:
real 1m31.001s user 1m41.139s sys 0m4.432s
real 1m34.107s user 1m42.723s sys 0m4.742s

Marc


On 14 October 2015 at 20:56, Mike Rodriguez  wrote:

> Just a heads up, I tried upliftign to Clojure 1.8.0-beta1 today and had a
> failure that is originating from potemkin "0.4.1".  I think the issue may
> be in its dependent project riddley "0.1.10".
> I logged an issue there at https://github.com/ztellman/riddley/issues/18.
>
> I haven't tracked down the cause of this problem right now.  I figure this
> may affect more people though, since I often read of people using potemkin
> in their projects.  These issues didn't seem to exists when I ran against
> some older potemkin versions (e.g. "0.3.2" was my test case).
>
> On Tuesday, October 13, 2015 at 9:01:06 AM UTC-5, Alex Miller wrote:
>>
>> Clojure 1.8.0-beta1 is now available.
>>
>> Try it via
>>
>>- Download:
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-beta1
>>- Leiningen: [org.clojure/clojure "1.8.0-beta1"]
>>
>> Below is a list of the other changes included in beta1. See the full
>> change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>
>>- CLJ-1456  Compiler now
>>errors if too few or too many arguments to throw
>>- CLJ-1282  quote now
>>throws if passed more or less than one arg
>>- CLJ-1210  Improved
>>error message for (clojure.java.io/reader nil)
>>- CLJ-1414  sort and
>>sort-by now indicate sort is stable in docstring
>>- CLJ-1765  areduce
>>performance improvements
>>- CLJ-1724  Remove
>>unnecessary call to seq() in LazySeq.hashCode()
>>- CLJ-1295  Improved
>>array-map dissoc performance
>>- CLJ-1277  Speed up
>>printing of time instants with type hints
>>- CLJ-1259  Speed up
>>pprint and cl-format with type hints
>>- CLJ-668  Improve slurp
>>performance by using StringWriter and jio/copy
>>- CLJ-1810  ATransientMap
>>now marked public
>>- CLJ-1653  str of an
>>empty list should be "()"
>>- CLJ-1567  Removed
>>unused local in condp implementation
>>- CLJ-1351  Unused
>>swapThunk method was being emitted for fns with keyword callsites
>>- CLJ-1329  Removed
>>unused local in PersistentVector.cons()
>>- CLJ-1380  3-arg
>>ExceptionInfo constructor permitted nil data
>>- CLJ-1226  set! of a
>>deftype field using field-access syntax caused ClassCastException
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] Clojure 1.8.0-beta1

[Marc O'Morain]

Agreed :)

On 14 October 2015 at 23:08, Alex Miller <a...@puredanger.com> wrote:

> This is a bug in the original code that is being caught by the stricter
> check on throws (at
> https://github.com/hugoduncan/clj-ssh/blob/develop/src/clj_ssh/ssh.clj#L301)
> - name there should be the final arg to ex-info, not to throw.
>
> So I'm going to call that a good regression. :)
>
> On Wednesday, October 14, 2015 at 3:35:09 PM UTC-5, Marc O'Morain wrote:
>>
>> FYI - Trying to upgrade CircleCI I get a syntax error in clj-ssh (passing
>> too many argument to throw):
>>
>> https://github.com/hugoduncan/clj-ssh/issues/39
>>
>> I've logged the issue with them.
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.8.0-beta1

[Marc O'Morain]

I don't have a good way to measure runtime like that I'm afraid.

On 14 October 2015 at 22:39, Ghadi Shayban <gshay...@gmail.com> wrote:

> Marc,
> Any changes up or down in run-time performance (post-startup)?
>
> On Wednesday, October 14, 2015 at 5:11:20 PM UTC-4, Marc O'Morain wrote:
>>
>> I just ran the CircleCI code-base under 1.8 beta 1 to see if there were
>> any gains in compile time (which is in the region of 90 seconds for our
>> main app). The clj-ssh issue was the only third-party lib that didn't work.
>>
>> Here is our compile time on Clojure 1.7 and 1.8:
>>
>> Clojure 1.7:
>> real 1m30.622s user 1m32.535s sys 0m4.182s
>> real 1m33.238s user 1m36.139s sys 0m4.381s
>>
>> Clojure 1.8 beta 1:
>> real 1m31.001s user 1m41.139s sys 0m4.432s
>> real 1m34.107s user 1m42.723s sys 0m4.742s
>>
>> Marc
>>
>>
>> On 14 October 2015 at 20:56, Mike Rodriguez <mjr...@gmail.com> wrote:
>>
>>> Just a heads up, I tried upliftign to Clojure 1.8.0-beta1 today and had
>>> a failure that is originating from potemkin "0.4.1".  I think the issue may
>>> be in its dependent project riddley "0.1.10".
>>> I logged an issue there at https://github.com/ztellman/riddley/issues/18
>>> .
>>>
>>> I haven't tracked down the cause of this problem right now.  I figure
>>> this may affect more people though, since I often read of people using
>>> potemkin in their projects.  These issues didn't seem to exists when I ran
>>> against some older potemkin versions (e.g. "0.3.2" was my test case).
>>>
>>> On Tuesday, October 13, 2015 at 9:01:06 AM UTC-5, Alex Miller wrote:
>>>>
>>>> Clojure 1.8.0-beta1 is now available.
>>>>
>>>> Try it via
>>>>
>>>>- Download:
>>>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-beta1
>>>>- Leiningen: [org.clojure/clojure "1.8.0-beta1"]
>>>>
>>>> Below is a list of the other changes included in beta1. See the full
>>>> change log here:
>>>> https://github.com/clojure/clojure/blob/master/changes.md.
>>>>
>>>>
>>>>- CLJ-1456 <http://dev.clojure.org/jira/browse/CLJ-1456> Compiler
>>>>now errors if too few or too many arguments to throw
>>>>- CLJ-1282 <http://dev.clojure.org/jira/browse/CLJ-1282> quote now
>>>>throws if passed more or less than one arg
>>>>- CLJ-1210 <http://dev.clojure.org/jira/browse/CLJ-1210> Improved
>>>>error message for (clojure.java.io/reader nil)
>>>>- CLJ-1414 <http://dev.clojure.org/jira/browse/CLJ-1414> sort and
>>>>sort-by now indicate sort is stable in docstring
>>>>- CLJ-1765 <http://dev.clojure.org/jira/browse/CLJ-1765> areduce
>>>>performance improvements
>>>>- CLJ-1724 <http://dev.clojure.org/jira/browse/CLJ-1724> Remove
>>>>unnecessary call to seq() in LazySeq.hashCode()
>>>>- CLJ-1295 <http://dev.clojure.org/jira/browse/CLJ-1295> Improved
>>>>array-map dissoc performance
>>>>- CLJ-1277 <http://dev.clojure.org/jira/browse/CLJ-1277> Speed up
>>>>printing of time instants with type hints
>>>>- CLJ-1259 <http://dev.clojure.org/jira/browse/CLJ-1259> Speed up
>>>>pprint and cl-format with type hints
>>>>- CLJ-668 <http://dev.clojure.org/jira/browse/CLJ-668> Improve
>>>>slurp performance by using StringWriter and jio/copy
>>>>- CLJ-1810 <http://dev.clojure.org/jira/browse/CLJ-1810> ATransientMap
>>>>now marked public
>>>>- CLJ-1653 <http://dev.clojure.org/jira/browse/CLJ-1653> str of an
>>>>empty list should be "()"
>>>>- CLJ-1567 <http://dev.clojure.org/jira/browse/CLJ-1567> Removed
>>>>unused local in condp implementation
>>>>- CLJ-1351 <http://dev.clojure.org/jira/browse/CLJ-1351> Unused
>>>>swapThunk method was being emitted for fns with keyword callsites
>>>>- CLJ-1329 <http://dev.clojure.org/jira/browse/CLJ-1329> Removed
>>>>unused local in PersistentVector.cons()
>>>>- CLJ-1380 <http://dev.clojure.org/jira/browse/CLJ-1380> 3-arg
>>>>ExceptionInfo constructor permitted nil data
>>>>- CLJ-1226 <http://dev.clojure.org/jira/browse/CLJ-1226> set! of a
>>>>   

Re: How does one print the stacktrace from slingshot?

[Marc O'Morain]

If you pass (:throwable ) as an arg before the string it will 
print the stack trace:




(timbre/log :trace (:throwable )  "the true stack trace: ")

On Fri, Oct 9, 2015 at 11:00 AM, Lawrence Krubner
 wrote:

> I'm trying to use Slingshot. I would like to print the stacktrace. If I do: 
>  (timbre/log :trace " the stack trace via slingshot-support " 
> (slingshot-support/stack-trace))
> I get: 
> the stack trace via slingshot-support 
>  [Ljava.lang.StackTraceElement;@72ee66cd
> How do I get what is in StackTraceElement? 
> I looked at these articles: 
> http://www.tutorialspoint.com/java/lang/stacktraceelement_tostring.htm
> http://www.javaworld.com/article/2072391/the-surprisingly-simple-stacktraceelement.html
> but I could not figure out how to translate that to what I'm doing. 
> I also tried: 
>  (timbre/log :trace " the true stack trace: "(.getStackTrace 
> (:throwable )))
> but that gives me: 
>  the true stack trace:  [Ljava.lang.StackTraceElement;@3733df3
> I can not figure out how to see what is in StackTraceElement. 
> If I search on Google for "slingshot print stacktrace" I can not find any 
> examples: 
> https://www.google.com/search?q=slingshot+print+stacktrace=slingshot+pr=chrome.0.69i59j0j69i57j0l3.3861j0j7=chrome_sm=91=UTF-8
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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: palingdrome problem (4 clojure)

[Marc O'Morain]

> So you convert the coll first to a sequence and compared it to the
reverse.
> Does the reversed coll not to be converted to a sequence then?

`reverse` will call `seq` on the coll that is passed in, so you don't need
to.

I used `doc` and `source` to find this out:

user=> (doc reverse)
-
clojure.core/reverse
([coll])
  Returns a seq of the items in coll in reverse order. Not lazy.


user=> (source reverse)
(defn reverse
  "Returns a seq of the items in coll in reverse order. Not lazy."
  {:added "1.0"
   :static true}
  [coll]
(reduce1 conj () coll))


user=> (source clojure.core/reduce1)
(defn ^:private ^:static
  reduce1
   ([f coll]
 (let [s (seq coll)]
   (if s
 (reduce1 f (first s) (next s))
 (f
   ([f val coll]
  (let [s (seq coll)]
(if s
  (if (chunked-seq? s)
(recur f
   (.reduce (chunk-first s) f val)
   (chunk-next s))
(recur f (f val (first s)) (next s)))
 val

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

[Marc O'Morain]

This should do it:

(defn palindrome? [coll]
  (= (seq coll) (reverse coll)))


user=> (palindrome? "tattarrattat")
true
user=> (palindrome? [1 5 10 10 5 1])
true
user=> (palindrome? "marc")
false
user=> (palindrome? [1 2 3])
false


On 8 October 2015 at 12:48, r/ Wobben  wrote:

> Chjips you are right. See  this :
>
> (defn palindrome [x]
>   (if (string? x)
> (clojure.string/reverse x)
> (into (empty x) (reverse x
>
> (palindrome '( 1 2 3 4)) (1 2 3 4)
>
> So back to the drawing table.
>
> Roelof
>
>
> Op donderdag 8 oktober 2015 10:59:30 UTC+2 schreef Alan Forrester:
>
>> On 8 Oct 2015, at 09:15, r/ Wobben  wrote:
>>
>> > I have now this :
>> >
>> > (ns fourclojure.core
>> >   (:gen-class))
>> >
>> >
>> > (defn checker [x]
>> >   ( = x (if (string? x)
>> > (clojure.string/reverse x)
>> > (into (empty x) (reverse x)
>> >
>> >
>> > (checker '(1 2 3 4 5)) true
>> >
>> >
>> > ( = '( 1 2 3 4 5) '( 5 4 3 2 1) ) false
>> >
>> > So something is wrong about my code
>> >
>> > it works fine with string but not with a set
>>
>> First, ‘(1 2 3 4 5) is a list, not a set.
>>
>> Second, (reverse ‘(1 2 3 4 5)) is  ‘(5 4 3 2 1) and according to the docs
>> for into
>>
>> https://clojuredocs.org/clojure.core/into
>>
>> that function conjoins items from (reverse ‘(1 2 3 4 5)) onto  (empty ‘(1
>> 2 3 4 5)). The docs for conj tell you what will happen
>>
>> https://clojuredocs.org/clojure.core/conj
>>
>> (empty ‘(1 2 3 4 5)) is a list and conjoining to a list puts items at the
>> front of the list not the back, so it puts 5 in at the from, then puts 4 in
>> front of the 5 and so on. So you are doing  ( = '( 1 2 3 4 5) ‘(1 2 3 4
>> 5)).
>>
>> Alan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Marc O'Morain]

Could you use Russian Dolls as an analogy? To build a Russian doll (or to build 
middleware) you start out with the smallest doll, and put it inside the second 
smallest, which in turn goes inside the third smallest. When opening the doll 
(calling the function) you start with the largest doll, and open it to reveal 
the second largest, etc. 




Imagine the function as a marble, and Russian Dolls as middleware. To put the 
marble inside the dolls you wrap it in the smallest doll first. To call the 
function (retrieve the marble) you need to open the largest, outermost doll 
first.

On Fri, Oct 2, 2015 at 8:10 PM, Jason Felice 
wrote:

> Why is it so hard to describe to new people?
> I mean, the questions I get are (I understand what's happening here, but I
> can't describe it well):
> 1. If -> threads things first-to-last, why does the middleware run
> last-to-first?
> 2. Why is comp backwards?
> 3. Wait, so how does each wrapper get a second pass at it?
> 4. Why would you do this to me?
> I hope to write a blog or something on this, but I wanted to check in here
> first.  Any ideas on how to talk about this?
> Thanks,
> -Jason
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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.

rand-nth on empty collections

[Marc O'Morain]

Hi all,

I was surprised by the fact that rand-nth thrown when called on an empty
collection - see http://dev.clojure.org/jira/browse/CLJ-925

This behaviour is strange, since passing nil to rand-nth returns nil,
whereas in my experience, other Clojure functions treat nil and empty
collections in the same way (compare with next/rest/first, etc).

http://dev.clojure.org/jira/browse/CLJ-925 was marked as Completed without
comment – is this the intended behaviour? If so, would you accept a patch
to update the docstring to make it clear that the function will throw an
exception when passed an empty collection?

Thanks,

Marc

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

[Marc O'Morain]

I think Mailbox app might have messed with the quoting in my last reply. I hope 
it makes sense. 




I'm not suggesting that the function be changed - Clojure's API compatibility 
between versions is amazing and a fine example of great engineering. 




Reading other people's input on this thread has made it clear to my what I find 
surprising - rand-nth does not behave like `first` when called on an empty 
collection, and in my mind asking for the first element of a sequence and 
asking for a random element of that sequence are similar operations. 




I do see the point of view that nth throws on out-of-bounds access, so rand-nth 
should too, but in that case I would expect rand-nth to throw too. 




I would like to see that subtlety mentioned in the doc string. 




Thanks Alex & all!

On Wed, Sep 30, 2015 at 3:14 PM, Alex Miller <a...@puredanger.com> wrote:

> rand-nth cannot return a random element if there are no elements to return, 
> so I do not find this surprising. Returning nil would be an invalid answer 
> in my opinion.
> The rand-nth doc string implies that rand-nth will inherit the semantics of 
> nth for the specified collection. nth will generally throw on an invalid 
> index (and all indexes are invalid for an empty collection).
> For nil, the docstring for nth does not mention nil explicitly, so I would 
> treat this as undefined behavior unless you consider it as a degenerate 
> sequence. 
> The code (in RT.nthFrom()) explicitly handles this case and effectively 
> treats nil as an infinite indexed source of nils, rather than as an empty 
> sequence. In my own opinion (but maybe not Rich's), it seems to make more 
> sense to take the sequence interpretation and say that on nil, nth should 
> throw instead.
> So that might be a valid ticket. I'm not sure what, if any, negative 
> consequences would arise out of existing uses of nth that rely on this 
> behavior though. Given the number of things built on nth, it may be 
> impossible to change this even if it made sense to.
> Alex
>  
> On Wednesday, September 30, 2015 at 6:38:49 AM UTC-5, Marc O'Morain wrote:
>>
>> Hi all,
>>
>> I was surprised by the fact that rand-nth thrown when called on an empty 
>> collection - see http://dev.clojure.org/jira/browse/CLJ-925 
>> <http://www.google.com/url?q=http%3A%2F%2Fdev.clojure.org%2Fjira%2Fbrowse%2FCLJ-925=D=1=AFQjCNFpBhBI2wA5LnBRCiAP8oYyF5HdOg>
>>
>> This behaviour is strange, since passing nil to rand-nth returns nil, 
>> whereas in my experience, other Clojure functions treat nil and empty 
>> collections in the same way (compare with next/rest/first, etc).
>>
>> http://dev.clojure.org/jira/browse/CLJ-925 was marked as Completed 
>> without comment – is this the intended behaviour? If so, would you accept a 
>> patch to update the docstring to make it clear that the function will throw 
>> an exception when passed an empty collection?
>>
>> Thanks,
>>
>> Marc
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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: rand-nth on empty collections

[Marc O'Morain]

I also think it makes perfect sense for rand-nth to throw an error on an empty 
collection.  That's because the first step is it needs to generate a random 
number between 0 and the length of the collection (0), which is impossible.  So 
it should throw an error.  Note that it is the *random generation of the 
index*, not the nth that conceptually is throwing the error.







​

​Throwing an exception doesn't feel like idiomatic Clojure to me. In my 
experience Clojure throws on type errors, and returns nil to indicate failure 
or absence. 

​

​first and next don't throw when you ask for non-existing elements of a 
collection - they return nil to indicate absense. Similarly get and get-in 
return nil rather than throwing when the provided key is not associated with a 
value in an associative data structure. 




​That's why I found it odd that rand-nth throws.

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

[Marc O'Morain]

Thanks for the reply, Alex.

Would there be any interest in a patch to remove the unused variables, and
other redundant code, such as the `if (true)` constructs? Or even just to
remove the commented out code?

Marc

On 13 September 2015 at 20:02, Alex Miller  wrote:

> Rich may change the formatting at some point but I do not expect he would
> accept a patch like this. Sorry.
>
> Alex
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Marc O'Morain]

No worries, thanks.

On 14 September 2015 at 20:36, Alex Miller <a...@puredanger.com> wrote:

> No, thanks.
>
> On Monday, September 14, 2015 at 10:51:37 AM UTC-5, Marc O'Morain wrote:
>>
>> Thanks for the reply, Alex.
>>
>> Would there be any interest in a patch to remove the unused variables,
>> and other redundant code, such as the `if (true)` constructs? Or even just
>> to remove the commented out code?
>>
>> Marc
>>
>> On 13 September 2015 at 20:02, Alex Miller <al...@puredanger.com> wrote:
>>
>>> Rich may change the formatting at some point but I do not expect he
>>> would accept a patch like this. Sorry.
>>>
>>> Alex
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Accept patch for Compiler.java formatting and clean-up?

[Marc O'Morain]

Hi there,


I've been working on some patches to Compiler.java in my spare time to add 
profiling and to try to add some optimisations to the code. My ultimate goal is 
to identify where time is spent during our app's start-up time, so that we can 
improve it.


One thing that hinders my progress is the formatting of the source code in 
Compiler.java (I won't go into specifics, as I think it has been brought up 
plenty of times before). After changing code the file ends up being reformatted 
by the editors that I have used. Using an IDE is difficult since there are so 
many warnings generated. 


Trying to generate a patch that I can submit to JIRA issue seems like it would 
be more trouble than it is worth, which means I am less willing to contribute 
to Clojure. 


Would the Clojure team be willing to accept a patch to standardise the 
formatting? Or a series of patches changing the file in smaller increments?


After the 1.8 release would be a good time to apply such a patch. 


I've seen mentioned here before that one potential issue is that patches 
created off the current Compiler.java would no longer apply. If that is deemed 
to be a real problem, I would be happy to fix up those patches myself. 


Thanks,


Marc

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

[Marc O'Morain]

Hi Hussein,

A combination of filter and tree-seq might do what you need.

Marc

On 19 August 2015 at 15:18, Hussein B. hubaghd...@gmail.com wrote:
 Hi,

 I have transformed JSON response into the equivalent data structure using
 Cheshire library.

 The result is a huge nested data structure , mostly vectors and maps. It is
 actually a tree.

 How to find a property that is nested deep inside the tree ? For example I'm
 search for the node that has the value zyx for property uuid.

 What I'm supposed to use? Something like zipper or walk? or something
 simpler is available?

 Thanks for help.

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

[Marc O'Morain]

This caught us out at Circle when preparing the code-base for Clojure 1.7 –
which reminds me of http://dev.clojure.org/jira/browse/CLJ-1752

It would be very nice if `reliased?` returned true for values that are not
instances of IPending



On 31 July 2015 at 03:51, Mars0i marsh...@logical.net wrote:

 OK, thanks.

 (I didn't have a real use case.  It's useful for experimenting at the
 prompt.)


 On Thursday, July 30, 2015 at 7:30:46 PM UTC-5, Alex Miller wrote:

 Yes, this behavior has changed.

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

[Marc O'Morain]

Hi Yuri,

You need to call .setDynamic before the access to the var is compiled. In
your test, the call to .setDynamic is invoked when the function is called,
which is after the function has been compiled.  So when compiler sees the
read of static-var the var is still static, and it can emit a read of the
static var (or inline the value, I'm not sure which approach the compiler
takes).

If the var is dynamic when a form is compiled that reads the var, a dynamic
look-up can be emitted. Try this:

(def static-var 123)

(.setDynamic #'static-var true)
(defn quz[]
  (binding [static-var 1000]
(println static-var = static-var deref = @#'static-var)))

(quz) ; = static-var = 1000 deref = 1000
static-var ; = 123

This doesn't help much when the var is defined in a library though, since
the library will be compiled before you get a chance to set the var to be
dynamic. It explains the behaviour that you are seeing though.

Marc

On 22 July 2015 at 13:13, Yuri Govorushchenko yuri.go...@gmail.com wrote:

 Thank you for a reply, I totally agree with you on dependency injection.
 Though I'm exercising in writing a mocking framework and thought it would
be an interesting feature to implement a thread-safe mocking of an implicit
dependency.

 среда, 22 июля 2015 г., 5:03:36 UTC+3 пользователь Surgo написал:

 Not that it's the answer you're looking for, but usually this is when
you rewrite the code you're testing to use dependency injection (ie, take
the var of interest as an argument instead of a global or in its lexical
environment).

 -- Morgon

 On Tuesday, July 21, 2015 at 10:54:42 AM UTC-4, Yuri Govorushchenko
wrote:

 The problem I'm trying to solve is how to stub a variable (e.g. a
function from a third-party lib) in tests so that the stubbing occurs only
in the current thread with other threads continuing using var's root value.
It's important because unit tests may be run in parallel. Without
thread-local binding two threads stubbing the same function will lead to
race conditions:

 (binding [somelib/foo foo-stub] ; throws
java.lang.IllegalStateException: Can't dynamically bind non-dynamic var
   ; invoke tested code which depends on foo
   ; assert stuff
   )

 I've tried to use .setDynamic (as described in blog post [1]) but it
doesn't work without direct deref-ing of the var:

 (def static-var 123)
 (defn quz[]
   (.setDynamic #'static-var true)
   (binding [static-var 1000]
 (println static-var = static-var deref = @#'static-var)))

 (quz) ; = static-var = 123 deref = 1000

 This approach seems to be used in a recent bolth lib [2]. And The
strange thing is that in REPL running this code line by line works:

 user= (def static-var 123)
 #'user/static-var
 user= (.setDynamic #'static-var true)
 #'user/static-var
 user= (binding [static-var 1000] (println static-var = static-var))
 static-var = 1000


 Looking at Var class implementation I couldn't figure out why
.setDynamic call wouldn't work. My guess is that compiler somehow caches
initial static Var value for performance reasons?..

 So the questions are:
 1) Is it a bug that .setDynamic + binding don't work?
 2) Is there any other way to temporally rebind static variable
thread-locally? Considering I can't add ^:dynamic into third-party lib and
don't want to write a wrapper or use dependency injection in order to
explicitly substitute the dependency in my unit tests.
 3) Is there a Clojure parallel test runner which runs tests in new
processes instead of threads? This would eliminate any race conditions.
Python's nose test runner works this way [3].
 4) Maybe crazy: does Clojure allow dynamically rebinding the symbol to
a new Var instance so that I could set 'static-var to point at (.setDynamic
(Var/create)?
 5) Even crazier idea: can I change the nature of the var so that it
behaves like an InheritedThreadLocal instead of ThreadLocal, but without
forcing a user to deref it (as it was described in [4])?

 Links:
 [1]
http://blog.zolotko.me/2012/06/making-variable-dynamic-in-clojure.html
 [2]
https://github.com/yeller/bolth/blob/323532683e3f66ae11566db5423c1e927e51818e/src/bolth/runner.clj#L99
 [3]
http://nose.readthedocs.org/en/latest/doc_tests/test_multiprocess/multiprocess.html
 [4] https://aphyr.com/posts/240-configuration-and-scope  - see
Thread-inheritable dynamic vars in Clojure

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