Re: (System/console) is nil?

[John Szakmeister]

On Wed, Feb 1, 2017 at 5:35 PM, Mark Reed  wrote:
> Trying to write a CLI that will prompt for a password, and it's failing
> because (System/console) always returns nil (whether in a compiled app or
> inside the REPL).

It works for me in a compiled app (it's non-nil), but not at the REPL
(probably because things are being redirected for the REPL).

-John

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

Re: [ANN] Gorilla REPL v0.4.0

[John Szakmeister]

It looks like the v0.4.0 and v0.3.6 tags point to the same thing in
the gorilla-repl repo, so the v0.4.0 tag isn't picking up the new
commits.

-John

On Mon, Jan 30, 2017 at 1:58 PM, Jony Hudson  wrote:
> Hi All,
>
>  it's a pleasure to announce a new release of Gorilla REPL :-) For those
> that haven't seen it before, Gorilla REPL is a browser-based notebook
> environment for Clojure that lets you make interactive documents with
> tables, graphs etc.
>
> The most important thing to note about this release is that I didn't do any
> of the work! Ben Bailey has been taking an active role in moving Gorilla
> forward, which is really great as I don't have a lot of time to devote to it
> at the moment. Congrats to Ben for the great work on this release.
>
> This release brings in some features that Ben has developed for use in a
> class he and Lee Spector teach. They allow Gorilla to be used to edit plain
> Clojure files as well as rich Gorilla worksheets. This allows them to use
> Gorilla as the sole environment for working in Clojure, which I'm told makes
> the set-up for the class much easier!
>
> As always you can find everything you need to know at
> http://gorilla-repl.org .
>
>
> Jony
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Deriving a protocol from a protocol...

[John Szakmeister]

On Mon, Oct 31, 2016 at 5:57 PM, Alex Miller  wrote:
> You can create instances that implement multiple Java interfaces using
> `reify` or by declaring them inline of a `defrecord` or a `deftype`. (See
> http://clojure.org/reference/datatypes for more.)

Thank you Alex.  I should have been more clear in that I'd like
something like ICombined which represents several protocols brought
together.  The motivation here is that it helps us ensure that all the
right protocols are being implemented.  AFAICT, Clojure has no
equivalent for abstract base classes... and I see a ticket about
issues with them (http://dev.clojure.org/jira/browse/CLJ-1255).

> Clojure does *not* encourage or support concrete inheritance (other than of
> the limited degree provided by `proxy`) and you will generally find that to
> be a hard way to go.

Sure.  I was more interested in the protocol aspects though.  This
might be a case where it's better for us to do this part in Java.

Thanks for the information.

-John

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

Deriving a protocol from a protocol...

[John Szakmeister]

I'm looking at using Clojure in an application where we make
fine-grained use of interfaces that help describe the capabilities of
an object.  We need to take several interfaces and bring them
together, not necessarily in an implementation, but to help define
what the overall interface for the object needs to support.

In Java, I could use an abstract base class to help:

public abstract class MyGear implements IFoo, IBar {
// ...
}

How does one do such a thing in Clojure?  Does it even make sense?  I
could see turning some things on their head an using multi-methods for
this, but I thought I'd ask and see if there is some other approach I
may be missing.

Thanks!

-John

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

[John Szakmeister]

Fantastic!  Thank you!

-John

On Tue, Oct 18, 2016 at 11:49 PM, David Nolen <dnolen.li...@gmail.com> wrote:
> This issue is fixed in master now thanks to Thomas Heller. The performance
> hit is negligible.
>
> Thank you for the report.
>
> David
>
> On Tue, Oct 18, 2016 at 3:45 PM, John Szakmeister <j...@szakmeister.net>
> wrote:
>>
>> On Tue, Oct 18, 2016 at 5:59 AM, Thomas Heller <th.hel...@gmail.com>
>> wrote:
>> > Don't think there is a best practice for your case in particular.
>>
>> Okay.  Earlier in the thread you said "while this issue can be very
>> confusing you will hardly ever run into it when following best
>> practices."  So it seemed to me that perhaps I missing something
>> important, or didn't know about a best practice that would have saved
>> me.  I think the issue here is a bit different though.  There's
>> nothing that would have saved short of knowing that js->clj has this
>> issue lurking in the background. :-)
>>
>> > The issue is that js->cli is built on top of protocols to allow
>> > converting
>> > custom JS types to CLJS types. Which makes it extensible for the price
>> > of
>> > checking protocols. In your case you are converting JSON which cannot
>> > have
>> > custom types, so a custom converter only checking for the very few
>> > possible
>> > JSON types would "fix" your problem (and would probably be a lot
>> > faster).
>>
>> Yep.  OTOH, I don't really need the performance and js->clj would have
>> been just as nice to use, if it worked correctly. :-)
>>
>> > The case can be made that cljs-ajax should not be using js->clj when
>> > converting JSON, maybe even add a json->clj to cljs.core.
>>
>> I think having json->clj would be a nice option.  Though for
>> cljs-ajax, we probably need to roll our own since the api wouldn't be
>> available in older ClojureScript versions.
>>
>> > The sentinel is the "safest" solution but impacts the performance of
>> > everyone, so we should be doing more benchmarks on more platforms before
>> > deciding anything. Benchmarks and Votes on the Jira Issue would help to
>> > push
>> > this along.
>>
>> True, but I think the correctness argument here is pretty valuable.
>> Again, much of what I see out there is the js->clj is the way to
>> convert data, and having this problem lurking seems like setting folks
>> up for failure.  I'm pretty persistent when it comes to
>> troubleshooting this stuff, but I could see others being awfully
>> frustrated by the result.  So I hope that some version of the sentinel
>> patch makes it in. :-)
>>
>> -John
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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: Possible ClojureScript compiler issue...

[John Szakmeister]

On Tue, Oct 18, 2016 at 5:59 AM, Thomas Heller  wrote:
> Don't think there is a best practice for your case in particular.

Okay.  Earlier in the thread you said "while this issue can be very
confusing you will hardly ever run into it when following best
practices."  So it seemed to me that perhaps I missing something
important, or didn't know about a best practice that would have saved
me.  I think the issue here is a bit different though.  There's
nothing that would have saved short of knowing that js->clj has this
issue lurking in the background. :-)

> The issue is that js->cli is built on top of protocols to allow converting
> custom JS types to CLJS types. Which makes it extensible for the price of
> checking protocols. In your case you are converting JSON which cannot have
> custom types, so a custom converter only checking for the very few possible
> JSON types would "fix" your problem (and would probably be a lot faster).

Yep.  OTOH, I don't really need the performance and js->clj would have
been just as nice to use, if it worked correctly. :-)

> The case can be made that cljs-ajax should not be using js->clj when
> converting JSON, maybe even add a json->clj to cljs.core.

I think having json->clj would be a nice option.  Though for
cljs-ajax, we probably need to roll our own since the api wouldn't be
available in older ClojureScript versions.

> The sentinel is the "safest" solution but impacts the performance of
> everyone, so we should be doing more benchmarks on more platforms before
> deciding anything. Benchmarks and Votes on the Jira Issue would help to push
> this along.

True, but I think the correctness argument here is pretty valuable.
Again, much of what I see out there is the js->clj is the way to
convert data, and having this problem lurking seems like setting folks
up for failure.  I'm pretty persistent when it comes to
troubleshooting this stuff, but I could see others being awfully
frustrated by the result.  So I hope that some version of the sentinel
patch makes it in. :-)

-John

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

[John Szakmeister]

Yes, you could do that, but it could also do Bad Things.  Namely if
you have strings that match some of the format, it could be
misinterpreted as Transit data rather than JSON, so I don't consider
it a particularly useful solution either.  It just moves where the
problem can happen. :-(  If there was a way to so "ignore the transit
extensions", that would change things though.

-John

On Tue, Oct 18, 2016 at 7:36 AM, Gary Trakhman  wrote:
> If you're parsing raw json streams/strings, I think transit claims to be a
> 30x perf improvement over js/JSON.parse+js->clj:
> http://swannodette.github.io/2014/07/26/transit-clojurescript
>
> On Tue, Oct 18, 2016 at 6:41 AM Matching Socks  wrote:
>>
>> A reliable "implements?" would be better than a fast-and-sometimes-wrong
>> "implements?".
>>
>> With that in mind, have you tried a distinct sentinel object, as opposed
>> to true?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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: Possible ClojureScript compiler issue...

[John Szakmeister]

On Tue, Oct 18, 2016 at 2:59 AM, Thomas Heller  wrote:
[snip]
> While this issue can be very confusing you will hardly ever run into it when
> following best practices. As David suggested using a custom js->clj here
> would prevent the issue and is probably the best course of action
> regardless.

Which best practices?  Is there a good place to read about them?  I've
not seen anything that would have steered me away from this problem.
In fact, I've seen quite the opposite: js->clj appears to be *the* way
to convert from JavaScript data structures to ClojureScript ones. :-(

FWIW, I did end up putting something together that was able to do what
I needed, but it could have easily gone a different direction.
js->clj was being called in a library that I'm using (cljs-ajax), and
it, fortunately, had a knob that I could turn to just get the raw json
back out without running anything through js->clj.  Had the knob been
missing, I think the solution would have been much more painful as I'd
either have to fork and maintain a copy of the library, migrate to a
different library, or write my own to replace it with. :-(

I also like the sentinel idea.  I hope some version of your patch is
incorporated.

-John

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

[John Szakmeister]

On Sat, Oct 15, 2016 at 2:49 PM, David Nolen  wrote:
> This issue is somewhat to be expected if you're going to use `js->clj`. This
> issue has nothing to do with ClojureScript compiler versions - you just got
> lucky before. Google Closure will collapse properties, but some of these
> collapsed properties are going to be used to determine protocol membership.
> That's it.

Wow.  I did not that expect that at all.  It makes sense, but it's unfortunate.

> I suggest just avoiding `js->clj` and using your own simple helper for
> recursively converting JSON into Clojure values. Changing the (admittedly
> questionable) behavior of `js->clj` will only lead to more breakage.

I'll definitely look at alternatives.  It'd be nice if js->clj had
documentation on this shortcoming though, and perhaps pointers to
better alternatives.

Thanks for the help David!

-John

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

Possible ClojureScript compiler issue...

[John Szakmeister]

I've been using ClojureScript rather successfully for a year now, but
ran into an interesting issue recently.

I've discovered that js->clj isn't quite working as expected.  After
quite a bit of tearing things down and apart, I discovered it was one
of the keys in some JSON data coming back from the server that looks
like:

"Bi": 8

And the resultant error would be:

No protocol method IEncodeClojure.-js->clj defined for type
object: [object Object]

I don't know why this particular sequence caused a problem, but I
ended trying to vary things a bit just to see what happens.  If I use:

"Bi": 0

I don't see the issue.  Any non-zero value though does seem to bring
the problem about for this sequence of letters though.  Similarly, I
tried varying the two letter sequence, and discovered two others with
similar problems: Ai, and ba.  The latter brought about a different
error:

[object Object] is not ISeqable

And the pattern with the value needing to be non-zero follows.  If the
value associated with the key is 0, then I don't see a problem.

As I wasn't seeing this issue before, I backpedaled my version of the
ClojureScript compiler and eventually found that 1.9.56 didn't seem to
sufffer from the problem.  After checking out ClojureScript, and
bisecting more I found that commit
bcf60ce194e5292fbc5c4b2d89dfc5a7b886b94c is when the behavior changed
from behaving correctly to behaving badly, but I think it's a false
positive.

I then created a much smaller test case, with no other libraries
involved.  This time it's a different set of values that are broken:

* "Ta" with a non-zero value gives: [object Object] is not ISeqable

* "Ub" with a non-zero value gives: No protocol method
IEmptyableCollection.-empty defined for type object: [object Object]

* "Wb" with a non-zero value gives: No protocol method
IEncodeClojure.-js->clj defined for type object: [object Object]

If I back up to before the previously mentioned commit, I can still
cause the problem, though the letter sequences change a bit.

Also, this only appears to happen with advanced optimizations.  With
no optimizations or with whitespace optimizations, there's no issues.
So it smells like a strange interaction between the ClojureScript
runtime and the compiler.

Has anyone seen an issue like this before?  Does anyone have any ideas
what is going on?  We have these short keys in our data, and it'd be
pretty painful to make them something else (especially since the names
are meaningful to those in the know, despite them being cryptic--they
refer to bit settings on various motors).

I'd be happy to file a ticket, if that's what needs to get done too.

Thanks!

-John

PS Here's the code I used to hunt down problematic keys:

(def alphabet [\a \b \c \d \e \f \g \h \i \j \k \l \m \n \o \p \q \r \s \t \u
   \v \w \x \y \z \A \B \C \D \E \F \G \H \I \J \K \L \M \N \O \P
   \Q \R \S \T \U \V \W \X \Y \Z])

(enable-console-print!)

(defn ^:export main-page []
  (println"Starting...")
  (doseq [c1 alphabet
  c2 alphabet
  i  (range 256)]
(let [s (str "{\"" c1 c2 "\": " i "}")]
  (try
;; (prn :parse-s (js/JSON.parse s))
;; (prn :js-clj-parse (js->clj (js/JSON.parse s)))
(js->clj (js/JSON.parse s))
(catch js/Error e
  (println "didn't work" s (str e
   ))
  (println "Done!"))

Then you can observe the results from the JS console.

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

[John Szakmeister]

On Wed, Jul 13, 2016 at 9:59 AM, Cecil Westerhof  wrote:
[snip]
> I already tried that, but this gives:
> WARNING: You're currently running as root; probably by accident.
> Press control-C to abort or Enter to continue as root.
> Set LEIN_ROOT to disable this warning.
>
> Downloading Leiningen to
> /root/.lein/self-installs/leiningen-2.3.4-standalone.jar now...
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
> 0curl: (22) The requested URL returned error: 403 Forbidden
> Failed to download
> https://leiningen.s3.amazonaws.com/downloads/leiningen-2.3.4-standalone.jar
> It's possible your HTTP client's certificate store does not have the
> correct certificate authority needed. This is often caused by an
> out-of-date version of libssl. Either upgrade it or set HTTP_CLIENT
> to turn off certificate checks:
>   export HTTP_CLIENT="wget --no-check-certificate -O" # or
>   export HTTP_CLIENT="curl --insecure -f -L -o"
> It's also possible that you're behind a firewall haven't yet
> set HTTP_PROXY and HTTPS_PROXY.

I think that might have been because the client was so far out-of-date.

> I now just installed it again. And that works. But what if I default want to
> work with a newer (or older) version. I understood it could be done with
> profile.clj, but I did not get it working.

I haven't done it, but perhaps look at:
https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md#replacing-default-repl-dependencies

> At the moment every user has to install lein, is there a way to install it
> globally?

Not that I'm aware of, but someone else here may know.

-John

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

[John Szakmeister]

On Wed, Jul 13, 2016 at 7:20 AM, Cecil Westerhof  wrote:
> After a long time I want to start with Clojure again. As I understand it, it
> is best to use:
> lein repl
>
> But then I work with 1.5.1. Is there a way to work default with the latest
> stable version of Clojure?

I think you probably want to run "lein upgrade".  My version currently
provides a REPL for Clojure 1.8.0 without any special options.

-John

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

[John Szakmeister]

On Thu, May 26, 2016 at 5:41 PM, Erik Assum  wrote:
> Not being good at reading other peoples mind, I’ll give my guess as to what 
> Timothy was trying to suggest:
>
> If you define your input as a map with keys such as:
>
> {:type :switched ; can be :switched :dual or :something
>  :pos 54}
>
> You can make something like:
>
> (defmulti verify-pos-for :type)

Yes, a multi-method could be used here, but Timothy suggested the data
model might be wrong and that's what I was interested in.  I think I'm
already setup to do the multi-methods with the current data model,
though it feels like a heavy-weight answer to the problem.

Thanks for the suggestion though!

-John

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

[John Szakmeister]

On Thu, May 26, 2016 at 7:09 PM, Mark Engelberg
<mark.engelb...@gmail.com> wrote:
> On Thu, May 26, 2016 at 1:29 PM, John Szakmeister <j...@szakmeister.net>
> wrote:
>>
>>
>> Yeah, cond is definitely useful here, but not in general.
>>
>
> cond is useful in general, just not the cond that is built-in to Clojure.

Sorry, I didn't mean it that way--just that it didn't seem useful to
me in general for the problems I've been facing with validation.

> About 5 years ago, Christophe Grand pointed out in a blog post that cond,
> augmented with a few extra things (:let, :when, and :when-let) neatly solved
> a ton of situations where Clojure often gets inelegantly nested, i.e.,
> interleavings of conditional tests with local variable definitions,
> protection against nil values, etc.
>
> I've been using this better cond ever since, for five years now, routinely,
> in my own code.  Once you start using this better cond, you'll never want to
> go back.
>
> Here's the implementation, for use in your own code:
> https://gist.github.com/Engelberg/9fc1264f938077cf03eee112ebed1768
>
> The most important ingredient here is the ability to put :let into your
> cond.  There has been a JIRA issue for this for nearly 7 years (it's a
> natural extension to cond, because :let is allowed in for clauses).  Given
> the incredible value this feature offers in terms of keeping code nice and
> "flat" as opposed to deeply nested/indented, I'm surprised it hasn't yet
> made it in to Clojure core.  Maybe soon, though, if enough people
> demonstrate that they care.  Go vote for this issue:
> http://dev.clojure.org/jira/browse/CLJ-200.

I can see a lot of use for this!  Thank you for pointing it out!

-John

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

[John Szakmeister]

(sorry for the repeat Nathan, this was meant to go to the list too)

On Thu, May 26, 2016 at 1:43 PM, Nathan Davis
 wrote:
> First off, I should say that you should first consider alternative
> approaches before considering the options below.  For example, cond seems
> well-suited for this particular case:
>
>
> (defn verify-position[pos type]
>  (cond (nil? pos) true
>(or (> pos 90)
>(< pos 0)) false
>
>.
>.
>.
>
>:else true))

Yeah, cond is definitely useful here, but not in general.

> However, sometimes you really do want imperative-style control flow.  Two
> possibilities come to mind here:
>
> Monads (e.g., algo.monads)
> Continuations (e.g., pulley.cps)
>
> In fact, monads and (delimited) continuations are isomorphic.  The main
> difference is one of view-point -- the essence of monads is the composition
> of computations; the essence of continuations is control flow.
>
> For a monadic approach, I would start with something like the "Maybe" monad,
> but add a monadic 'bail' operator (to use your terminology and avoid
> conflicting with the common use of 'return' as one of the fundamental
> operators on monads).  Essentially, 'bail' would be constructed to abort the
> "current computation".  Then if you implement a function in terms of the
> 'bailing' monad (and encapsulate the effect to that function), you can use
> 'bail' to effectively return a value from the function at any point in the
> computation.
>
> With continuations, all you need is an "abortive" continuation back to the
> call-site of the function.  With pulley.cps, this is easily accomplished
> using call-cc / let-cc.  For example, here's your first example in terms of
> let-cc:

This was very informative.  I'm definitely going to write this down as
something to look into.  I think there's probably other and better
choices for input validation, but I can see this being extremely
useful for some of the equipment control work I do.

Thank you for the suggestion.

-John

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

[John Szakmeister]

On Thu, May 26, 2016 at 2:12 PM, Timothy Baldridge  wrote:
> I would suggest reviewing your data model a bit. One of the problems  you
> are experiencing is that you are overloading the inputs to your function.
> And since they are overloaded you have to create a state machine of sorts to
> parse out if the data is valid. Another approach is to use namespaced keys
> in a map then dispatching on the contents of the map. This removes a lot of
> ambiguity in the code.

Can you describe what you mean a little more?  I think what you're
trying to say it that I should somehow separate switched axes from
variable axes, etc., despite that the same data is present in
both--just with slightly different semantics.

The problem I see there is then I have to somehow figure out which
version to grab from the map.  If I'm following correctly, you're
perhaps suggesting that I pull the type information higher into the
data model so I can use it to know which version to grab out of the
map?  If that's the though process, it seems to me that it's
cluttering things rather than making it better--at least from my
ability to understand what the data model is actually saying.  Having
the type grouped under the axis seems more coherent to me.

I've probably misunderstood what you're saying though, so an example
of what you mean would be really helpful.  I'm certain that you're
telling me something profound, but I'm just not parsing it out. :-)

> Then you can use something like clojure.spec to validate your data:
>
> (s/def :pos.switch/value #{0 90})
> (s/def :pos.slider/value (set (range 90)))

Is there a way to cope with 0 and 90 actually being variable?  What I
mean is that I don't know what the valid range is until I talk with
the back end equipment.  So I can't say at compile time what the valid
range will be.  I took that bit out of my example because I felt it
was making things too complex to be useful.

> (s/def :switch/change (s/or :nil nil?
> :switch (s/keys :req [:pos.switch/value])
> :slider (s/keys :req [:pos.slider/value])))
>
> (s/valid? :switch/change {:pos.switch/value 42})   ; => false
> (s/valid? :switch/change {:pos.slider/value 42}); => true
> (s/conform :switch/change {:pos.switch/value 0}) ; => [:switch
> {:pos.switch/value 0}]
> (s/conform :switch/change nil)   ; =>
> [:nil nil]
> (s/conform :switch/change {:pos.slider/dual 0}) ; =>
> :clojure.spec/invalid
>
> (s/exercise :switch/change) ; => Generates
> 10 example data sets
>
> And as you see from this example, you can use specs to dispatch, validate
> and even generate test data for your application.

This is definitely interesting, though I thought spec was geared more
towards testing and less towards runtime validation.  Well, now that I
say that, I guess what was said is that spec wasn't meant to be
enabled for everything all the time... you call out the bits you want
to do at runtime.  It's probably still too new for me to use though,
especially since I'm currently using ClojureScript and clojure.spec
isn't available there yet.  But definitely good to know about.  Thank
you for the example!

-John

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

[John Szakmeister]

On Thu, May 26, 2016 at 1:47 PM, Sean Corfield  wrote:
[snip]
> A pattern that I’ve also started using is something like this:
>
> (defn guarded-process [data]
>   (some-> data
>   first-guard
>   second-guard
>   (another-guard :with “parameters”)
>   (process-the-data 1 2 3 4)))
>
> That works well for a process that operates on non-nil data and then you 
> write the guards to return the data if it’s valid or nil if it isn’t.

You know, I know about half of the threading macros well, but I
haven't touched some->.  It seems like a really good fit for some
problems I'm facing.  Thank you for the suggestion!

-John

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

[John Szakmeister]

On Thu, May 26, 2016 at 10:55 AM, Gary Trakhman  wrote:
> I think the idiomatic way to handle this in clojure is to do all your
> validation upfront on a single descriptive data structure, perhaps in a
> single function, then bail early.  That has the added advantage of being
> able to report multiple errors, instead of just the first, and is well
> supported by libs like Schema and the new clojure.spec.

-ENOPARSE. :-)  I think you're saying "describe the data you expect
with other data in Clojure", and then use that data to validate the
inputs--hence the reference to Schema.

I guess the problem I see here is that it's complicated.  I really
dumbed things down in my example, but there are a number of properties
of the system that are dynamic: the limits of the axis, what
acceptable values are based on the type of axis, whether the
coordinate system is linear or compass-based, etc.  Almost all of this
is determined at runtime when we link up with the equipment, but ends
up driving the kinds of validation we need to do. I'm not sure how
something like Schema would handle this, but...

I was trying to avoid using Schema, since it's rather large and I have
slow links to worry about (at least for the web side of things).  And
I took clojure.spec as something not to be used in production, but to
help with testing--though I see the cross-over.

**update**: so I went and pulled in Schema, and it's not as bad as I
thought.  So perhaps using Schema is more viable than I thought.

> Maybe if the target of the code is by nature imperative, it would make this
> more difficult.  You could probably abuse exceptions to avoid the nesting.

I'm not sure I can say it's imperative by nature--it's my desire to
reduce nesting and the number of edges I have to keep in my brain.  I
just haven't found a way that I'm happy to deal with it in a
functional manner.

As I mentioned, I was trying to avoid exceptions, but you're right--it
may be the only real way forward, but I'm looking for other options
first. :-)

-John

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

Avoiding nested ifs...

[John Szakmeister]

I'm very much a fan of bailing out early in imperative
programming as it helps to avoid a bunch of nested if conditions
that are to follow and read.  This typically comes up when
checking arguments to ensure that they're valid (in range, of
acceptable values, etc).  One of the major stumbling blocks
I've had when writing Clojure is to find a good way to keep code
concise, but readable.

For instance, take a snippet like this:

def verify_position(pos, type):
# It's acceptable to have a None value--it just means don't
# change the position for the axis.
if pos is None:
return True

# Anything outside our limits is invalid.
if (pos > 90) or (pos < 0):
return False

if type == 'switched' and pos not in (0, 90):
# Switched axes only allow 0 and 90, and nothing in
# between.
return False

if type == 'dual':
# We can't control the value on this axis, so anything
# other than None is invalid.
return False

return True


I find this very readable in that along the way, I can start
throwing things off the raft: after the first condition, I don't
need to worry about None being present.  After the second, I
know the value is within limits, etc.  I have a hard time
translating the above into (what I believe) is readable Clojure.
Here's my stab at it:

(defn verify-pos [pos axis-type]
  (if (nil? pos)
;; nil means don't move the axis.
true
(case axis-type
  ;; Only 0 and 90 are allowed on a switched axis.
  "switched" (or (= pos 0)
 (= pos 90))

  ;; Any non-nil value is disallowed on dual.
  "dual" false

  ;; Otherwise, make sure we're within a valid range.
  (and (<= pos 90)
   (>= pos 0)

Now, this was a rather simple example, but you can see some of
the nesting starting.  Add in another condition like
nil?--something that is somewhat global across the different
types--and you get another level of nesting in there.

I can break it up more:

(defn verify-range [pos axis-type]
  (case axis-type
;; Only 0 and 90 are allowed on a switched axis.
"switched" (or (= pos 0)
   (= pos 90))
;; Any non-nil value is disallowed on dual.
"dual" false
;; Otherwise, make sure we're within a valid range.
(and (<= pos 90)
 (>= pos 0

(defn verify-pos [pos axis-type]
  (or (nil? pos)
  (verify-range pos axis-type)))

And this is a bit better, but you run up against another issue:
coming up with good names for each part of the whole so that you
can combine them.  And, coming up with names that don't sound so
similar that folks have to dig into the implementation to know
which one is the correct one (I feel the above break up has this
problem).

In some cases, the error checking logic is really
complicated--because the thing being controlled has complex
restrictions that are out of my control--and the nesting of if
conditionals is maddening.  Having to come up with names for
each of them would be more than twice as frustrating, as the
individual bits don't lend themselves to good names.

Then there's the issue of combining the verification and the
actual work into a useful function, where you need to verify and
then act on it:

(defn set-position [pos type]
  (if (verify-pos pos type)
(send-position-to-equip pos)
(do-something-for-invalid-input)))

Again, this is a simple example, but more complicated cases have
more to check, and therefore more nesting of if statements,
where the early bail technique leaves the flow pretty readable.
I also realize pre- and post- conditions might be useful, but I
don't feel they're appropriate when validating user
input--especially not assertion errors, which we generally think
of programming errors, not user input errors.

I realize some of this may be me and shaping my mind more to
functional programming, though I do feel like I have a decent
grasp of it.  I've been dabbling in Clojure for several years,
and have more recently incorporated ClojureScript into a project
for our web front-end.  However, I feel like I might be missing
an important strategy for this kind of problem, and I'm hoping
that one of you can point me in a good direction.  And please
don't get hung up on this example.  I was trying to boil
something much more difficult down into something reasonable
that would help show the issue.

Thank you!

-John

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

Re: IntelliJ / ClojureScript Integration...

[John Szakmeister]

On Tue, Aug 5, 2014 at 3:08 AM, Colin Fleming
colin.mailingl...@gmail.com wrote:
 Hi John,

[snip]
 Here's what Wilker Lúcio wrote:

 This is how I got it done (and I'm using it on node-webkit project):

 Add this plugin to your project (plugins, not dependencies):

 [jarohen/simple-brepl 0.1.0]

 On your main cljs file, add this :require

 [weasel.repl :as ws-repl]

 Also add this at your init point so it connects with the REPL:

 (ws-repl/connect ws://localhost:9001)

 Setup wise that's all you need.

 After that, start your REPL (with lein repl), and them run: (simple-brepl)

 Wait a bit, it will change your REPL into browser REPL, and it will say
 that the websocket is listening. After that open you page, and you are done,
 just evaluate stuff :)


 Let me know if this doesn't work for you and I'll see what I can do.

Thank you Colin, that was helpful.  I think I need to work out a
couple of details for myself, but I was able to get a REPL that works!
 Thank you!

-John

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

IntelliJ / ClojureScript Integration...

[John Szakmeister]

Sorry for pestering the list about this, but despite trying to follow
several different blog posts about this, I seem unable to get a
working ClojureScript REPL that connects to the browser.  Ideally, I'd
like to start from a clean project using lein new om-start
project_name and get the right bits together to do this.  My goal is
to be able to do the Om tutorials and try things out on-the-fly.

Given that, I do have Clojure repl working where I can start the Jetty
server.  However, when I try this:

(browser-repl)

As suggested by the om-start README, anything I try to evaluate just
hangs there.  FWIW, I see no errors in the JavaScript console.
Looking at the raw HTML, it looks like the connection back to the
server-side for the browser REPL is correct, and the (browser-repl)
command comes back with:

(browser-repl)
WARNING: unsigned-bit-shift-right already refers to:
#'clojure.core/unsigned-bit-shift-right in namespace: cljs.core, being
replaced by: #'cljs.core/unsigned-bit-shift-right
Browser-REPL ready @ http://localhost:60442/9462/repl/start
Type `:cljs/quit` to stop the ClojureScript REPL
= nil

Any advice folks can give would be appreciated.  I'm fairly new to
IntelliJ in general, and to this point have used Vim and a
command-line REPL to do my work.  It'd be nice to have IntelliJ
working here.  I should add that I'm using the Cursive plugin for
IntelliJ and not La Clojure.

Thanks!

-John

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

[John Szakmeister]

On Thu, Jan 23, 2014 at 9:17 PM, Cedric Greevey cgree...@gmail.com wrote:
 [meta, but about something apparently triggered by the message, from this
 thread, that I'm quoting]

 Why did reading this post cause gmail to go bonkers? I saw this thread had
 new articles since earlier today, brought it up, and read the previous
 message, then just after I'd scrolled down to this one, leaned back, and
 started reading it the browser just suddenly began spinning on its own and
 navigated by itself. Apparently about 10 seconds after I sat back
 *something* input a click on the little down-triangle in the upper right
 corner of the page and then clicked sign out because it went to the gmail
 login page. And a second or so before that the chat thingy at the left
 crashed as a popup there distracted me by appearing suddenly and saying
 something like Oops, problem connecting to chat.

GMail's sessions time out periodically.  I forget the interval (or if
it's random... it seems to be at times), but when it does, it has
similar behavior to what you've described.  Chat goes a little wonky,
and then you're brought to the sign in page some moments later.  I
think the behavior is slightly worse if you have two accounts in GMail
(I have a regular GMail account and one that's in the Apps for
Business).  They sometimes interact badly, especially around starting
and ending sessions.

-John

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

Re: [ANN] optparse-clj: Functional GNU-style command line options parsing

[John Szakmeister]

On Fri, Nov 22, 2013 at 8:30 PM, guns s...@sungpae.com wrote:
 On Fri 22 Nov 2013 at 07:22:20PM -0500, John Szakmeister wrote:

 This looks very nice.  Have you considered something along the lines
 of Python's argparse?

 http://docs.python.org/dev/library/argparse.html

 Thank you. I am not familiar with Python's argparse. My experience with
 option parsers are primarily the C functions getopt and getopt_long, the
 getopts builtin in bash, and Ruby's OptionParser.

 On first scan, argparse and OptionParser appear to be very similar,
 both in capability and programming interface. I know OptionParser
 particularly well, and while I enjoy its flexibility and power, the
 actual implemention and scope of what it tries to accomplish are quite
 un-Clojuresque.

Sorry, I didn't mean to suggest you should model the inteface after
argparse.  That said, I think there's much about it that's declarative
and would fit well.

 The beautiful thing about tools.cli is that it is conceptually very
 simple: it reduces an option specification and a list of arguments into
 a map of configuration options.

Yep, and I think that's good as well.

 IMHO, printing elaborate usage banners, associating subcommands with
 methods, managing options of subcommands, and invoking behaviour should
 be handled separately from option parsing. The guiding principle of
 optparse-clj and the next version of tools.cli is to provide data and
 let the user take it from there.

The one thing that makes argparse interesting from everything else is
that it gives all the nice handling to arguments as well.  I can see
from the examples you've got things like :parse-fn for parsing the
argument and turning it into something else.  It's nice to have those
features for arguments as well, and that's where I think argparse is
really shines.  It treats both options and arguments as first-class
citizens. :-)

I think that would be useful for your library as well.

 It's nice to see you thought about subcommand support as well. Thank
 you for your contribution!

 The gist I linked to earlier¹ contains a detailed proposal for how I'd
 like to advance tools.cli. If you are interested, comments on that are
 much appreciated.

I'll take a look at it over the weekend.  Thanks!

-John

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

Re: [ANN] optparse-clj: Functional GNU-style command line options parsing

[John Szakmeister]

On Wed, Aug 7, 2013 at 11:53 AM, guns s...@sungpae.com wrote:
 Hello,

 I'd like to announce optparse-clj, a command line options parser that
 supports GNU option parsing conventions:

 https://github.com/guns/optparse-clj

 [guns.cli/optparse 1.0.0]

 The interface is modelled after clojure.tools.cli¹, but the parser is
 more flexible:

This looks very nice.  Have you considered something along the lines
of Python's argparse?

http://docs.python.org/dev/library/argparse.html

It's nice to see you thought about subcommand support as well.  Thank
you for your contribution!

-John

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

Re: first vals first vals

[John Szakmeister]

On Thu, Nov 21, 2013 at 4:08 AM, Zhemin Lin lin.zhe...@gmail.com wrote:
 Hi.
 I'm quite annoyed by the ugly smell of (first (vals (first ... )).  Is there
 any better way to do it?

 user= (- {:key1 {:cf {:cq 0,1,2,3}}} vals first vals first vals first
 (clojure.string/split #,))
 [0 1 2 3]

I think you want get-in:

(- {:key1 {:cf {:cq 0,1,2,3}}}
(get-in [:key1 :cf :cq])
(clojure.string/split #,))

-John

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

Re: first vals first vals

[John Szakmeister]

On Thu, Nov 21, 2013 at 4:32 AM, Zhemin Lin lin.zhe...@gmail.com wrote:
 Thanks, John  Jernau.
 What if :cf, :cq are not fixed, and I don't really care about the keys, but
 only the value of the value of the value ...?

You might want to consider tree-seq to get at the innermost string:

(last (tree-seq map? vals
{:key1 {:cf {:cq 0,1,2,3}}}))

-John

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

Re: StackOverflowError

[John Szakmeister]

On Fri, Nov 8, 2013 at 5:11 AM, ru soro...@oogis.ru wrote:
 Hi Jim,

 I forget to say that call to count have been done in not a bare repl, but
 inside a quite complex program after it did a lot of work on a quite big
 data. But, after long and profound analysis of source code I did not found
 any places with deep recursive calls :( Something like stack is filling
 against my will...?

Are you using concat, remove, or filter to build or modify a sequence?
 If so, you can run into a StackOverflow error if you build a long
chain of operations and then try to process the whole sequence.

-John

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

Re: StackOverflowError

[John Szakmeister]

On Fri, Nov 8, 2013 at 8:51 AM, ru soro...@oogis.ru wrote:
 Solution have found:

 (remove ...) = (doall (remove ...))

Be careful with this technique.  It can easily make your O(n)
algorithm O(n^2).  It may be better to use data structures that you
can use with conj and disj if you need to maintain performance.

-John

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

Re: blog article on RSpec like TDD with a rapid feedback cycle in Clojure

[John Szakmeister]

On Sun, Oct 20, 2013 at 4:24 PM, Korny Sietsma ko...@sietsma.com wrote:
 Note you can do the same thing in midje :
 https://github.com/marick/Midje/wiki/Auto test - it works quite nicely.

Looks like a space made it in between Auto and test.  The link should be:
   https://github.com/marick/Midje/wiki/Autotest

-John

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

Re: What is the status of Clojure on LLVM or C?

[John Szakmeister]

On Thu, Mar 28, 2013 at 9:26 PM, Mikera mike.r.anderson...@gmail.com wrote:
 On Friday, 29 March 2013 05:45:53 UTC+8, Laurent PETIT wrote:

 2013/3/28 Marko Topolnik marko.t...@gmail.com:
  Or you may have just a trivial requirement for a program that both
  starts
  and executes quickly.

 To what extent would an LLVM / C version of a Clojure program not
 incur startup penalty as the JVM does.

 As far as I understand it, the startup cost is manyfold:
 1/ JVM startup
 2/ loading of Clojure Core
 3/ loading of non-lazy parts of your application (generally from
 loading a global namespace to invoke its -main function)

 In my experience 1) is a small fraction of the total. A trivial hello
 world Java program runs in less than 0.1sec on my machine, which proves
 that JVM startup isn't really important. Or at least, far less important
 than most people think.

I certainly don't see that.  I've measured this more than a few times,
and it's several seconds for a simple Hello World Java application
on any machine that I can touch.  Additionally, on an embedded system,
I'm not going to have the same kind of CPU power.  For instance, the
current processor we use runs at 400MHz instead of your desktop's
3GHz.

[snip]
 It might even be slower in LLVM / C, unless you can at least match the JVM
 in terms of JIT optimisation and garbage collector efficiency, which in turn
 affects the runtime for 2+3 (I believe a garbage collector is a requirement
 to execute Clojure?). Beating the JVM isn't an easy feat.

You could argue the same for any application written in C, though I
think in practice C keeps up pretty well.  However, raw execution
speed isn't necessarily my goal.  More interesting to me is having
better tools to use.  Clojure's approach to concurrent programming is
world's better that the share everything approach used in C, and
it's that facility that I'd like to use the most.  But requiring the
JVM to use it--in my environment--is just too high of a price to pay.
To be honest, LLVM might be too high as well.  LLVM is certainly far
from small and lightweight. :-)

-John

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

Re: What is the status of Clojure on LLVM or C?

[John Szakmeister]

On Fri, Mar 29, 2013 at 5:28 AM, Marko Topolnik
marko.topol...@gmail.com wrote:

 I certainly don't see that.  I've measured this more than a few times,
 and it's several seconds for a simple Hello World Java application
 on any machine that I can touch.  Additionally, on an embedded system,
 I'm not going to have the same kind of CPU power.  For instance, the
 current processor we use runs at 400MHz instead of your desktop's
 3GHz.


 In fairness to Java, your measurements are the exception, not Mikera's. For
 example:

 $ java -version
 java version 1.7.0_17
 Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
 Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
 $ echo 'public class Test { public static void main(String... args) {
 System.out.println(Hello); } }'  Test.java
 $ javac Test.java
 $ time java Test
 Hello

 real 0m0.137s
 user 0m0.097s
 sys 0m0.034s

Hmmm... perhaps I was testing something more full-fledged (though not
a server application) that could be used as a skeleton for a
command-line tool.  I'll have to check.  I'm not seeing it be that
fast on my current machine, but is less that 1 second with Java
6--though this machine is rather powerful.

Still, it's not going to be that fast on a 400MHz ARM. :-)

-John

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

Re: What is the status of Clojure on LLVM or C?

[John Szakmeister]

On Fri, Mar 29, 2013 at 5:49 AM, Mikera mike.r.anderson...@gmail.com wrote:
 I decided to benchmark JVM startup again, in case of any doubt, and because
 I see plenty of FUD on this issue.

Sorry, I don't mean to spread any FUD.  I'm just being loose with the
phrase start-up time.  You're right, I should be more precise in my
terminology.  FWIW, I think when people talk about this, they're doing
the same thing: including the class loading overhead for something
other than the most trivial of examples.

[snip]
 As you can see JVM startup is 0.1s or less: in fact the entire execution of
 Hello World took 0.1 sec on my machine. Note that this is the server VM. I
 did about 20 successive runs which were all in the 0.08 to 0.12 sec range.

Yes.  It's about double that on my machine, but within reach.

[snip]
 I certainly don't see that.  I've measured this more than a few times,
 and it's several seconds for a simple Hello World Java application
 on any machine that I can touch.  Additionally, on an embedded system,
 I'm not going to have the same kind of CPU power.  For instance, the
 current processor we use runs at 400MHz instead of your desktop's
 3GHz.

 I suggest you recheck your measurement approach / configuration. See above
 :-)

Okay.  I pushed up a barebones example of a command line application
here: https://github.com/jszakmeister/barebones

Really, it's just Clojure plus tools.cli, and a small snippet in main.
 Running this 10 times, I'm seeing about 3.07s on my machine to
execute this example.  I built in with lein2 uberjar, and did:

:: time java -jar target/barebones-0.1.0-SNAPSHOT-standalone.jar
{:faux bar, :help false}
Hello, World!
java -jar target/barebones-0.1.0-SNAPSHOT-standalone.jar  3.09s user
0.28s system 186% cpu 1.804 total

:: java -version
java version 1.6.0_43
Java(TM) SE Runtime Environment (build 1.6.0_43-b01-447-10M4203)
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01-447, mixed mode)

 Agreed that any embedded processor is likely much slower than a PC (mine is
 a laptop in fact). And IO speed probably makes a big difference as well if
 there are caching effects / large .jar files to load.

Definitely.

[snip]
 Agreed - the JVM is a poor fit for very tightly constrained environments.
 Excited to see what you can achieve here!

 Just don't knock the JVM unfairly, it is one of the best tools we have :-)

I don't mean to do that.  The JVM is an amazing piece of software.  I
just happen to be in circles where folks believe it's the answer to
everything, and unfortunately, it's not.  It has some limitations and
it isn't well-suited to every problem.  Even at 100ms for the start-up
time, that's still pretty non-trivial for a command line application.
The real question is whether we can get something like the barebones
example to fire up and run in a similar amount of time.

As you said: I'm excited to see what can be achieved in this space!

-John

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

Re: What is the status of Clojure on LLVM or C?

[John Szakmeister]

On Wed, Mar 27, 2013 at 5:21 PM, Timothy Baldridge tbaldri...@gmail.com wrote:
 What use-case do you have for such an implementation? Is there something
 that Clojure on LLVM will give you that Clojure on the JVM or on V8 won't
 allow you to do?

Clojure on C would likely allow me to use Clojure in a deeply embedded
environment.  Such as an ARM processor with 32MB of Flash and 64MB of
RAM.  To run the JVM, that may require licensing, and V8 doesn't allow
for threads.

I'm not the OP, but I thought I'd share my view too.

-John

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

Re: Looking for help with a deadlock issue

[John Szakmeister]

On Fri, Jul 27, 2012 at 12:02 PM, Kyle R. Burton kyle.bur...@gmail.com wrote:
 I encountered a deadlock on one of our production systems (one out of
 3) last night.  Looking at a thread dump of the JVM, there are several
 (over 200) threads that are all waiting on a
 java.util.concurrent.locks.ReentrantLock from Keyword.intern.

 I've put up the thread dump and information about the os and jvm versions 
 here:

   https://github.com/relaynetwork/20120727-deadlock-issue

 The part of our application that deadlocked is a web service that uses
 Compjure and Jetty.  Other parts of the application did not deadlock
 (we have AMQP consumers that were still processing successfully).

 I have since restarted the service and it is processing again.  I'm
 not sure what to look at next, can anyone suggest a next step for
 determining the cause?

I think you're hitting a bug in Java.  Specifically, this one:
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6822370

It looks like there are 237 threads attempting to call
java.util.concurrent.ConcurrentHashMap$Segment.put, which makes the
lock awfully contentious.  But the problem is that they all decided to
park themselves.  That's a sure sign that the view of memory is
inconsistent across the processors.  Looking at the evaluation of the
bug, that seems to be exactly the problem.  It was supposedly fixed in
1.6.0_19, but there seem to be reports that it's still present in _20
and _21.

It's not all bad news though.  It seems like a workaround is to use
-XX:+UseMembar.

-John

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

Re: is their a Clojure framework for handling form validation?

[John Szakmeister]

On Tue, Jul 24, 2012 at 6:05 PM, Trent Ogren m...@trentogren.com wrote:
 https://github.com/weavejester/valip

 The approach of that project is interesting. Not only does it decouple
 validation from any notion of web form (it just works on maps like many of
 the others in this thread), it decouple the error messages from the
 predicates that produce an error message. I can't imagine it being any
 simpler...

I had completely forgotten about that library!  Thanks for the reminder!

-John

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

Re: Clojure shell calls results inconsistent with actual shell calls.

[John Szakmeister]

On Wed, Jul 11, 2012 at 7:47 PM, Eric in San Diego eric.sc...@acm.org wrote:

 It's very application specific, but it's Object 'test' does not have a
 field named 'test1' c:/path/to/importTest, suggesting that it's not
 inferring the value of an  'I' parameter which should indicate a directory
 within which to search for a file called 'test' which included some trivial
 code that informs my test.

This doesn't sound like a problem with sh, but in the way you're
calling it.  Without a traceback, and some sample source though, it's
harder to give useful feedback.  Perhaps, you're doing something
slightly unexpected, and the script isn't coping with it well?  For
instance, you're doing the equivalent of:

   (sh/sh testApp -I c:/path/to/importTest)

Instead of:

   (sh/sh testApp -I c:/path/to/importTest)

In the first case, testApp is called with 1 argument -I
c:/path/to/importTest.  In the second case, it's called with 2
arguments, just as it would be with the shell.

 I tried substituting a batch file (this is on windows) with the single line
 in it, and get the same discrepency in behavior - the batch file works fine
 when invoked from the shell, but fails when called with sh.  This suggest to
 me that it's nothing to do with clojure's processing of the arguments. Maybe
 this has something to do with how the environment is represented?

Is it the script that's failing?  From sh, you should get a map of
:in, :out, and :err.  If you're getting that, then the problem is
definitely lower (in the script) versus in sh.

 I tried printing the value of sh/*sh-env* during my call, and it was 'nil',
 but in order to call the app at all, it must have some knowledge of the
 PATH. Does (null *sh-env*)  then mean 'no changes to the default
 environment'?

IIRC, the set command will dump your environment in Windows.  env
will do it under Linux or Mac OS X.  You can do:
(print (sh/sh env))

(print (sh/sh set)) should work in Windows... but I don't run
Windows, so I can't be certain. *sh-env* is a thread local binding,
and can be used to customize the environment for several calls via
(with-sh-env ...).  The 'nil' you're seeing is the default binding
value, which means take the parent environment.  (sh ...) does allow
you to override the environment too using the :env keyword.

-John

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

Re: Central screwup

[John Szakmeister]

On Wed, Jun 13, 2012 at 5:47 AM, Chas Emerick c...@cemerick.com wrote:
 On Jun 12, 2012, at 7:12 PM, Phil Hagelberg wrote:

 On Mon, Jun 11, 2012 at 1:48 PM, Phil Hagelberg p...@hagelb.org wrote:
 On Mon, Jun 11, 2012 at 9:36 AM, Phil Hagelberg p...@hagelb.org wrote:
 These will be removed once Central gets back to working order, but
 they should help stem the flow of catastrophic build failures.

 While this will allow most builds to work, it's a band-aid solution.
 Is there anyone on the Clojure/core team with a contact among those
 who run Central who could get them to look into this?

 Central is back to normal, so I've removed the workaround jars on Clojars.

I don't believe the issue is entirely fixed as the checksums still
don't match.  The sha1sum of maven-metadata.xml is
643fa0e8afd24c907e5e7f268943957846b13d25, while
maven-metadata.xml.sha1 claims
92472231000f7b66ebf43cb412c74b4ba3cd7277.

-John

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

Re: Unable to pass unboxed primitive to methods taking multiple numeric primitive types.

[John Szakmeister]

On Wed, May 23, 2012 at 7:58 PM, Cedric Greevey cgree...@gmail.com wrote:
 (defn f [^java.awt.image.BufferedImage bi x]
  (.setSample (.getRaster bi) 0 0 0 (double x)))
 #CompilerException java.lang.IllegalArgumentException: More than one
 matching method found: setSample, compiling:(NO_SOURCE_PATH:1)

 The only way I was able to find to fix this is

 (defn f [^java.awt.image.BufferedImage bi]
  (.setSample (.getRaster bi) 0 0 0 ^Double (double x)))

I'm entirely not sure what's going on, but this seems to be good in the repl:

(defn f [^java.awt.image.BufferedImage bi x]
(.setSample (.getRaster bi) (int 0) (int 0) (int 0) ^double x))

I tried creating an object and running it through the function as well
with no warnings.

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

Re: Parallel doseq?

[John Szakmeister]

On Thu, May 24, 2012 at 2:15 AM, Sean Corfield seancorfi...@gmail.com wrote:
 First off, the code you posted can't actually be right: you have
 (println n) but the for binding was for i.

 Second, given your macro, try (range 100) instead of (range 10) and
 see what you get...

Can you explain that a little more Sean?  I know of some issues with
chunked sequences, but I expected this to work as well with the doall
in there.

Thanks!

-John

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

Re: Parallel doseq?

[John Szakmeister]

On Thu, May 24, 2012 at 7:46 AM, Chris Perkins chrisperkin...@gmail.com wrote:
[snip]
 Also, pmap is not broken; the problem with the code you pasted is simply an
 errant closing paren. You had (do (doall (pmap ...) nil)), where you meant
 (do (doall (pmap ...)) nil). Apparently doall has a two-arg version, which
 is news to me :)

I think you answered my question as well.  Thanks for the nice explanation!

-John

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

Re: Lexer and parser generator in Clojure

[John Szakmeister]

On Fri, May 18, 2012 at 8:46 AM, Alexsandro Soares
prof.asoa...@gmail.com wrote:
 Hi,

  I'm trying to build a compiler using Clojure. Is there any tools
 like flex and bison generating Clojure code?
  I'm interested in a lexer/parser in pure Clojure because I think
  in use the same code with Javascript (via ClojureScript) and Java (via
 Clojure).
 I already know isolated tools like Jflex, JavaCup and Bison generating Java
 and
 Jison, JS/CC and friends for Javascript, but I am just interested in a pure
 Clojure solution.

You might want to look at Parsley:
https://github.com/cgrand/parsley

-John

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

Re: Article on HTTP-based REPL

[John Szakmeister]

On Fri, May 4, 2012 at 2:30 PM, Phil Hagelberg p...@hagelb.org wrote:
 Hello folks.

 I just posted an article yesterday on using cemerick's drawbridge
 library for live-debugging a Ring application over HTTP:

    https://devcenter.heroku.com/articles/debugging-clojure

 You may find it interesting if you need to connect to deployed nodes
 but can't open a new socket connection for whatever reason, such as
 running on a provider like Heroku. Hope it's helpful.

Nice write up Phil!

-John

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

Re: New release of Paredit mode for Vim with support for VimClojure repls and Map literals

[John Szakmeister]

On Sun, Apr 22, 2012 at 3:28 PM, Evan Mezeske emeze...@gmail.com wrote:
 Version 0.9.3 does indeed support balanced map literals.

 I believe that the bitbucket repository is the official home of slimv (from
 which paredit.vim comes):  https://bitbucket.org/kovisoft/slimv/ .

Just an FYI, but there seems to be version 0.9.6 here:
   http://www.vim.org/scripts/script.php?script_id=3998

-John

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

Re: Bret Victor's live editable game in ClojureScript

[John Szakmeister]

On Mon, Feb 27, 2012 at 3:14 PM, Chris Granger ibdk...@gmail.com wrote:
 Hey folks,

 In reference to the previous thread on Inventing On Principle, I
 built a ClojureScript example of his live editable game :)

 http://www.chris-granger.com/2012/02/26/connecting-to-your-creation/

 Enjoy!

Nice!  You rock!

-John

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

Re: lein run takes an excessive amount of time...

[John Szakmeister]

On Fri, Feb 17, 2012 at 5:50 AM, John Szakmeister j...@szakmeister.net wrote:
 It appears that when executing 'lein run' that it's examining
 dependencies and/or contacting Maven repositories.  This overhead is
 adding a considerable amount of time to lein run.  Firing things up
 from the command line takes *significantly* less time (30s vs 4-5s).

 Has anyone else seen this behavior?  I'd rather 'lein run' just run
 and not do any checking of dependencies.

Answering my own question here, but putting ':checksum-deps false' in
the defproject does the trick.

-John

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

lein run takes an excessive amount of time...

[John Szakmeister]

It appears that when executing 'lein run' that it's examining
dependencies and/or contacting Maven repositories.  This overhead is
adding a considerable amount of time to lein run.  Firing things up
from the command line takes *significantly* less time (30s vs 4-5s).

Has anyone else seen this behavior?  I'd rather 'lein run' just run
and not do any checking of dependencies.

Thanks for the help!

-John

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

Re: No show?

[John Szakmeister]

On Sat, Feb 11, 2012 at 10:15 PM, Sean Corfield seancorfi...@gmail.com wrote:
 On Sat, Feb 11, 2012 at 6:30 PM, Michał Marczyk
 michal.marc...@gmail.com wrote:
 print-table expects a sequence of maps, e.g.

 (print-table (:members (reflect Math)))

 Wow! I had no idea how useful that could be... Learn something new
 every day! (and, lately, that's a new Clojure function every day...)

That is amazing!   Thanks for the tip Michał!

-John

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

Re: Please try the alphas and betas!

[John Szakmeister]

On Wed, Nov 2, 2011 at 10:00 AM, Chas Emerick cemer...@snowtide.com wrote:
[snip]
 Yes; this is called locking snapshots in the Maven world, and there are 
 commands there that can lock any snapshot dependencies to the current 
 snapshot.

 If you are using Leiningen, there are no corollary commands, but you can use 
 the same concrete snapshot version numbers.  e.g. looking at Clojure 1.4.0 
 snapshots here:

 https://oss.sonatype.org/content/repositories/snapshots/org/clojure/clojure/1.4.0-master-SNAPSHOT/

 You can use a version number like 1.4.0-master-20111025.230825-6 to fix 
 against that particular snapshot instead of continually updating to HEAD.

 That said, if alphas are going to be emitted at a steady pace, then updating 
 to them as desired may suit your use case better (i.e. it's easier to know to 
 revert to -alpha8 [or whatever] than it is to revert to 
 1.4.0-master-20111025.230825-6).

 The maven snapshot metadata is only maintained for the latest snapshot so 
 version numbers that include SNAPSHOT can resolve to a particular concrete 
 artifact. Explicitly using a concrete snapshot version (like 
 1.4.0-master-20111025.230825-6) resolves directly to the artifact in 
 question, so the metadata isn't relevant.

Thanks to all who responded!  This is really good to know.

-John

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

Re: Please try the alphas and betas!

[John Szakmeister]

On Mon, Oct 31, 2011 at 4:25 PM, Sean Corfield seancorfi...@gmail.com wrote:
 On Mon, Oct 31, 2011 at 8:06 AM, Timothy Baldridge tbaldri...@gmail.com 
 wrote:
 I'd like to second what Bill said...I don't really have the time to
 setup a clojure build process to test out the 1.4 Alphas/Betas, but if
 there was a way for me to get to it via lein...I would just target 1.4
 for all my day-to-day development.

 This should work:

  :repositories [[sonatype-snapshots
 https://oss.sonatype.org/content/repositories/snapshots/;]]
  :dependencies [[org.clojure/clojure 1.4.0-master-SNAPSHOT] ...]

Is there a way to peg a particular snapshot?  If we find that
something breaks, we'd want to roll back to a previous version until
the problem is fixed.  It looks like the maven metadata only has the
latest snapshot recorded (I may be wrong... I'm certainly not a Maven
guru).

-John

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

Re: Issue with lein-ring...

[John Szakmeister]

On Tue, Mar 8, 2011 at 4:04 PM, Michael Ossareh ossa...@gmail.com wrote:
[snip]

 90% of the time I find that:
 lein clean  rm -rf lib  lein deps
 solves this type of issue.

Yeah... I've done that a few times. :-)  I should say that I'm using
the 1.3.0-master-snapshot of Clojure.  I did find that
ring.util.tracker is in ring-reload-modified-0.1.0.jar for the
development dependencies.  But I think something else is wrong.  The
actual traceback points to find-namespace as being the culprit... but
I don't see how it can be short of a compiler bug. :-(

-John

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

Re: Issue with lein-ring...

[John Szakmeister]

On Wed, Mar 9, 2011 at 1:29 PM, John Szakmeister j...@szakmeister.net wrote:
 On Tue, Mar 8, 2011 at 4:04 PM, Michael Ossareh ossa...@gmail.com wrote:
 [snip]

 90% of the time I find that:
 lein clean  rm -rf lib  lein deps
 solves this type of issue.

 Yeah... I've done that a few times. :-)  I should say that I'm using
 the 1.3.0-master-snapshot of Clojure.  I did find that
 ring.util.tracker is in ring-reload-modified-0.1.0.jar for the
 development dependencies.  But I think something else is wrong.  The
 actual traceback points to find-namespace as being the culprit... but
 I don't see how it can be short of a compiler bug. :-(

Changing it to use clojure and contrib 1.2.0, everything is fine.  So
something is happening between going from 1.2.0 to 1.3.0.

-John

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

Re: Issue with lein-ring...

[John Szakmeister]

On Wed, Mar 9, 2011 at 3:29 AM, Saul Hazledine shaz...@gmail.com wrote:
 On Mar 8, 8:31 pm, John Szakmeister j...@szakmeister.net wrote:
 I've been working on a web app, and it was using leiningen-war.  The
 author of that suggest moving to the lein-ring plugin on his github
 site... so, I did that.

 Apologies if the wording in the README of leiningen-war has caused any
 problems. The road to hell is paved with good intentions.

No worries. :-)

 Leiningen-war remains alive and supported. I'm happy to fix bugs and
 add features when requested - I use the plugin myself and will
 continue to do so. However, people new to Java web development were
 having problems with Leiningen-war since it does everything in the
 Java style with XML config files and an unfamiliar directory
 structure. This approach was obviously a barrier for newcomers using
 Clojure who wanted to create a deployable web application. The lein-
 ring plugin is a much easier plugin to use, it integrates well with
 Ring and it has extra features. It is my hope was that all new users
 start with lein-ring.

That's pretty much what I read.  I happen to be a newish user of it,
so I saw the readme and said oh, I guess I should try lein-ring.  So
I jumped that direction.

 I'll change the README in leiningen-war to make it clearer.

Thanks for the explanation!

-John

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

Issue with lein-ring...

[John Szakmeister]

I've been working on a web app, and it was using leiningen-war.  The
author of that suggest moving to the lein-ring plugin on his github
site... so, I did that.  However, when I run lein ring server I get
a traceback, which I show below.  Two lines stand out to me:
at 
ring.util.tracker$eval688$loading__4292__auto689.invoke(tracker.clj:1)
at ring.util.tracker$eval688.invoke(tracker.clj:1)

So I went to look at ring.util.tracker... but there is no
ring.util.tracker. :-(  So I have no idea what's happening here.  I'm
hoping someone here can shed some light on this.

Here's the traceback:

Var *classpath* not marked :dynamic true, setting to :dynamic. You
should fix this before next release!
Var *html-mode* not marked :dynamic true, setting to :dynamic. You
should fix this before next release!
Exception in thread main java.lang.UnsupportedOperationException:
Cannot recur across try,
compiling:(clojure/contrib/find_namespaces.clj:61)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6253)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyze(Compiler.java:6018)
at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2516)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6246)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6234)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyze(Compiler.java:6018)
at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2524)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6246)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6234)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyze(Compiler.java:6018)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5422)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5718)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6246)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6234)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyze(Compiler.java:6018)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5422)
at clojure.lang.Compiler$TryExpr$Parser.parse(Compiler.java:2022)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6246)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyze(Compiler.java:6018)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5422)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:4858)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3530)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6244)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6234)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.access$100(Compiler.java:36)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:494)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6246)
at clojure.lang.Compiler.analyze(Compiler.java:6057)
at clojure.lang.Compiler.analyze(Compiler.java:6018)
at clojure.lang.Compiler.eval(Compiler.java:6305)
at clojure.lang.Compiler.load(Compiler.java:6736)
at clojure.lang.RT.loadResourceScript(RT.java:344)
at clojure.lang.RT.loadResourceScript(RT.java:335)
at clojure.lang.RT.load(RT.java:413)
at clojure.lang.RT.load(RT.java:385)
at clojure.core$load$fn__4397.invoke(core.clj:5318)
at clojure.core$load.doInvoke(core.clj:5317)
at clojure.lang.RestFn.invoke(RestFn.java:409)
at clojure.core$load_one.invoke(core.clj:5132)
at clojure.core$load_lib.doInvoke(core.clj:5169)
at clojure.lang.RestFn.applyTo(RestFn.java:143)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$load_libs.doInvoke(core.clj:5203)
at clojure.lang.RestFn.applyTo(RestFn.java:138)
at clojure.core$apply.invoke(core.clj:604)
at clojure.core$use.doInvoke(core.clj:5295)
at clojure.lang.RestFn.invoke(RestFn.java:458)
at 
ring.util.tracker$eval688$loading__4292__auto689.invoke(tracker.clj:1)
at ring.util.tracker$eval688.invoke(tracker.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6301)
at clojure.lang.Compiler.eval(Compiler.java:6292)
at clojure.lang.Compiler.load(Compiler.java:6736)
at clojure.lang.RT.loadResourceScript(RT.java:344)
at clojure.lang.RT.loadResourceScript(RT.java:335)
at clojure.lang.RT.load(RT.java:413)
at 

Re: Regarding The Implementation of 'merge-with'

[John Szakmeister]

On Thu, Jan 20, 2011 at 3:34 AM, Stefan Rohlfing
stefan.rohlf...@gmail.com wrote:
 Hi John,
 Thank you very much for your correction of my code! my-merge-with is working
 perfectly now.
 There is just one thing: I always want to understand my errors so that I can
 learn from them. However, I still don't understand why my implementation did
 not work. Looking at my code I am thinking everything should be fine as all
 key/val pairs are added to the map acc of the outer reduce (or so is my
 assumption).

That's exactly it though: it doesn't add the key to acc.  It creates a
new copy of acc with the updated key and returns that result (it
doesn't update acc in place).  For each iteration of the inner reduce,
it was starting off with the original acc, trying to add the key, and
then the updated map would get discarded... except for the last entry
for each of the maps.

For the first run, acc is an empty map, and then the inner reduce
would try to add the keys.  So it was basically doing
  (assoc {} :a 1) = {:a 1}
  (assoc {} :b 2) = {:b 2}

The last result is kept as the result of the inner reduce operation,
which then becomes the next intermediate result for the outer reduce
operation.  Then, we run through the second map:
  (assoc {:b 2} :a 9) = {:b 2 :a 9}
  (assoc {:b 2} :b 100) = {:b 100}
  (assoc {:b 2} :c 0) = {:b 2 :c 0}

Once again, the last result is kept as the result of the reduce
operation.  This also happens to be the last result of the outer
reduce as well, and ends up being your answer.  Hopefully, you can see
how the intermediate results were being discarded now.  It sometimes
difficult to remember that you're operating on immutable data. :-)

-John

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

Re: just an observation about doseq...

[John Szakmeister]

On Thu, Jan 20, 2011 at 5:38 AM, Baishampayan Ghose b.gh...@gmail.com wrote:
 when we give an empty vector of seq-exprs to doseq it returns the value of
 the last s-expression.. but returns nil when the
 vector-of-seq-exprs is not empty.. may be this is the expected behaviour ..
 but the documentation states otherwise ..

 Yeah, that looks like a bug (either in the documentation or the code):
   (doseq [] 1) = 1

 doseq works just like do when the seq-exprs part is empty. This is
 certainly not a bug in the code, but I believe the documentation can
 be improved.

 Relevant portion of the code:
 https://github.com/clojure/clojure/blob/b578c69d7480f621841ebcafdfa98e33fcb765f6/src/clj/clojure/core.clj#L2395

Yep, I took a look at that before responding.  I'm just not sure what
the fix should be: make (doseq) return nil as advertised, or update
the documentation.  I tend towards the former, although the latter is
fine too. :-)  Either way, something should be fixed. :-)

I folks believe it's a documentation problem, I'm happy to whip up a
patch for that.

-John

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

Quick question about str/join....

[John Szakmeister]

I was looking at a commit that updated a docstring for str/join, which
enticed me to take a look at the implementation.  I was kind of
surprised to see that it wasn't:
  (apply str (interpose sep coll))

I'm just curious about the developer was thinking.  Here's a link to the code:
  
https://github.com/clojure/clojure/blob/f30995c86056959abca53d0ca35dcb9cfa73e6e6/src/clj/clojure/string.clj#L130

Thanks!

-John

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

Re: Quick question about str/join....

[John Szakmeister]

On Tue, Jan 4, 2011 at 8:01 PM, MiltondSilva shadowtr...@gmail.com wrote:
 I believe it's for performance reasons. Strings in java are immutable,
 so they use the StringBuilder(mutable) to achieve better performance.

But str use StringBuilder too.  Maybe it was better to avoid the extra
call overhead?

-John


 On Jan 5, 12:18 am, John Szakmeister j...@szakmeister.net wrote:
 I was looking at a commit that updated a docstring for str/join, which
 enticed me to take a look at the implementation.  I was kind of
 surprised to see that it wasn't:
   (apply str (interpose sep coll))

 I'm just curious about the developer was thinking.  Here's a link to the 
 code:
   https://github.com/clojure/clojure/blob/f30995c86056959abca53d0ca35dc...

 Thanks!

 -John

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

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

Re: Quick question about str/join....

[John Szakmeister]

On Tue, Jan 4, 2011 at 8:22 PM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
 Several people had hands in that code, and the final result is all about 
 perf. Do not treat string.clj as a reference for idiomatic code. :-)

That's what I suspected. :-)  Thanks Stuart!

-John

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

Re: Quick question about str/join....

[John Szakmeister]

On Tue, Jan 4, 2011 at 8:29 PM, MiltondSilva shadowtr...@gmail.com wrote:
 Again from inspection it seems the way it's implemented in contrib,
 the code makes one pass. With (apply str (interpose sep coll)) you
 make two, one to interpose the other to convert (seq-str).

Well, interpose does return a lazy sequence, but it does appear that
would get realized passing them in as args to str.  Thanks!  That's
was the tidbit I was looking for!

-John

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

Re: Posted the Bowling Game Kata in Clojure w/ Video. Thoughts welcome. EOM

[John Szakmeister]

On Fri, Dec 10, 2010 at 3:30 PM, Tim Visher tim.vis...@gmail.com wrote:
 Because posting the link would make some modicum of sense…

 http://blog.twonegatives.com/post/2168030248/kata

 ^_^

Awesome Tim!  Thanks for taking the time to put that together!

-John

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

Re: StackOverflowError while using map inside a reduce

[John Szakmeister]

On Wed, Nov 3, 2010 at 2:35 AM, Meikel Brandmeyer m...@kotka.de wrote:
 Hi,

 On 3 Nov., 00:40, Rasmus Svensson r...@lysator.liu.se wrote:

 I think the problem is that this reduction will build an expression like 
 this:

     (map + ... (map + ... (map + ... (map + ... one million nesting 
 levels

 When clojure tries to realize an element of the resulting lazy seq,
 every level will result in a nested method call, which will eventually
 blow the stack.

 Exactly. Much better than my try on an explanation. The doall in my
 example realises each sequence as it is created by reduce. Hence this
 deep nesting level of calls cannot happen.

Thank you both for the explanation.  I hadn't realized that reduce
could work with lazy sequences in that way.  I figured it was doing
the equivalent of a doall already for each element of the sequence,
but apparently not. :-)  So now I see how the nesting can happen.
Thanks!

-John

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

Re: [Bug] StackOverflowError while using map inside a reduce

[John Szakmeister]

On Tue, Nov 2, 2010 at 4:49 PM, Meikel Brandmeyer m...@kotka.de wrote:
 Hi,

 Am 02.11.2010 um 12:58 schrieb Pepijn de Vos:

 The one-liner:
 http://gist.github.com/659491

 I would expect this is because you pile lazy seq on lazy seq, which then get 
 realised, unfolding the whole thing resulting in the stack overflow. Try this:

I'm sorry... I don't quite understand this explanation.  Do you mean
that reduce is realizing the entire list all at once?  I would think
it would grab an element one at a time.  Sorry for the stupid
question, but there's something subtle here that I'm not
understanding.

 user= (reduce #(doall (map + %1 %2)) (partition 5 (range 1e6)))
 (950 970 990 1010 1030)

Is it because of the way the lazy sequence is being generated?  Would
different implementations of partition or range do better?

Thanks in advance!

-John

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

Access to the issue tracker...

[John Szakmeister]

I'm not sure what the protocol is for this, but I'd like to attach a
patch to one of the issues in Assembla.  Unfortunately, it won't let
me.  Do I have to get added to the project in some way?  Or should I
just hang out until Jira comes online?

BTW, I did send in my CA.  Rich should hopefully have it in hand
already (I sent it in early last week).

Thanks!

-John

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