Re: Benefits to partial functions.

[John D. Hume]

It's been a long time since I looked at this, but as of a few years ago,
the biggest noticeable performance detriment of comp or partial was likely
to come if you pass enough args to hit a "& args" overload, which requires
creating a fresh object array at each call, when the underlying function
being called has a non-"& args" arity.

On one application I worked on, we preferred defining #(anonymous ...)
functions to some uses of higher order functions to avoid excessive
garbage-creation in some hot spots.

This assumes you don't need primitive type-hint-level optimization.

I wouldn't recommend sacrificing any clarity unless you've profiled and
found a real issue.

definition of partial:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2614

definition of comp:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2557


On Sun, Oct 20, 2019, 3:25 PM david hoyt  wrote:

> Is there a performance benefit (or detriment) to creating partial
> functions? Other than the potential reduction of complexity, is there a
> difference between using partial & comp and defining new functions?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/146f2a73-9887-4eba-89c6-815eed6841b1%40googlegroups.com
> .
>

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

Re: Expected inconsistency between set and map w/ ArrayList?

[John D. Hume]

On Mon, May 12, 2014 at 12:53 PM, Alex Miller  wrote:

> My recommendation in Java would be the same - using mutable objects as
> keys in a map (where mutability changes the hashcode) is a bug waiting to
> happen.
>

Although I used java.util.ArrayList in the sample REPL session showing the
surprising behavior, I never said anything about the Java types used in our
application being mutable. That gets at my point: the "best" Java
collection values, the only ones that make good hashmap keys, are
immutable, but Clojure still gives them this mixed status where they're
equiv but not hasheq to IPersistentCollections w/ the same contents.

[Having made that point again, I'll now admit that under the cover of
java.util.List, the lists in messages our app receives are ArrayLists
:-), BUT they're never mutated, and we'd have the same issue if they were
Guava ImmutableList, which is a fine value type (so long as V is
immutable).]

In general, Clojure treats Java collections (and arrays) as values now ...
> but if you do mutation, then any Clojure guarantees are off (in hashing, in
> STM, etc). I think that's been generally a happy compromise so far. The
> question is to what extent that should continue.
>

I'm totally happy to see crazy things happen to anyone who treats a mutable
collection as a value and then mutates it.

It may even be that this could be supported without much of a hit. Strings,
> numbers, keywords, symbols, and all Clojure collections should be handled
> above the suggested change and that covers most common key types. Some
> research would need to be done on what common non-Clojure classes (hence
> not IHashEq implementors) fall into the final else case - java.lang.Class
> is one that comes to mind which is used a lot inside Clojure itself.
>

I like the sound of this. One of your comments on the ticket mentioned JVM
inlining issues, which scared me.

Is it a safe bet that protocol dispatch would be too slow for hasheq?

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

Expected inconsistency between set and map w/ ArrayList?

[John D. Hume]

Is this behavioral change in Clojure 1.6.0 expected? Under 1.6.0, a set and
a map seem to treat a java.util.ArrayList differently with respect to its
equivalence to a vector.
https://gist.github.com/duelinmarkers/7c9f84cfc238e5d37a09

user=> (-> {} (assoc [1 2] "vec") (assoc (java.util.ArrayList. [1 2]) "alist"))
{[1 2] "alist"}
user=> (-> #{} (conj [1 2]) (conj (java.util.ArrayList. [1 2])))
*#{[1 2]}*
user=> *clojure-version*
{:major 1, :minor 5, :incremental 1, :qualifier nil}

;

user> (-> {} (assoc [1 2] "vec") (assoc (java.util.ArrayList. [1 2]) "alist"))
{[1 2] "alist"}
user> (-> #{} (conj [1 2]) (conj (java.util.ArrayList. [1 2])))
*#{[1 2] [1 2]}*
user> *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}

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

Name for this pattern: side-effect from swap!

[John D. Hume]

I sometimes find that after mutating an atom, I want to create some
side-effect that depends on the old and new state as well as the context in
which the change was made. Because of the dependence on context, a watch
doesn't work (unless there's something I'm not thinking of). So I add
things to the new atom state (returned by swap!) purely to tell the calling
code what side-effect to have (or give it the data it needs to decide what
side-effect to have). That additional state isn't used anywhere other than
the fn that called swap!.

One gotcha to this approach is that one must be careful not to leave some
old side-effect causing state in place to cause another side-effect based
on stale data.

Is there a name for this pattern? A standard way of implementing it? A
better alternative?

One alternative I'm aware of is using mutable locals (provided by
https://github.com/ztellman/proteus) as a side-channel of communication
from swap!. Both approaches strike me as messy, though a let-mutable
probably makes it more obvious that something funny is going on, and it
doesn't pollute the atom.

Thanks.
-hume.

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

[John D. Hume]

On Sat, Feb 15, 2014 at 6:04 PM, t x  wrote:

>
> (defn what-I-want []
>   (with-atom some-atom
> assoc-in ...
> assoc-in ...
> update-in ...))
>

I often do something like this and don't find it too ugly:
(swap! my-atom #(-> %
  (assoc-in [:k] v)
  (update-in [:k2] inc)
  ,,,))

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

[John D. Hume]

On Tue, Feb 11, 2014 at 7:32 AM, Phillip Lord
wrote:

> "John D. Hume"  writes:
> > Other than the new (and quite minimal) Java API for calling
> > Clojure code[1], the details of Clojure's underlying Java classes are
> > considered implementation details and could change from release to
> release
> > without being considered a breaking change.
>
>
> And the interfaces? I mean, ISeq is defines the sequence abstraction.


When I said "underlying java classes" I meant "underlying Java classes and
interfaces."

Although there are contrib and third party libraries that depend on these
implementation details, I think the message to the community at large has
always been not to depend on them, and as far as I know, the maintainers
have not committed to keeping anything other than the newly documented Java
API and the existing Clojure API in Clojure stable.

So if I'm not mistaken, in spite of the fact that you can find many
examples of people doing it, there is no blessed way to create custom
Clojure data structures (unless you count defrecord) and no official
documentation to encourage or assist you.

Hopefully I am mistaken, or this will change someday soon. :)

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

[John D. Hume]

On Feb 11, 2014 4:41 AM, "Phillip Lord" 
wrote:
>
> Is the only place this is written down is by working reading the
> implementing classes?

I believe so. Other than the new (and quite minimal) Java API for calling
Clojure code[1], the details of Clojure's underlying Java classes are
considered implementation details and could change from release to release
without being considered a breaking change.

[1]: https://github.com/clojure/clojure/blob/master/changes.md#21-java-api

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

[John D. Hume]

It includes this update, which I'd say brings it up to date.

" *update (4/18/2012):** As of the 1.4.0 release, there's no longer a good
reason to use use. Use require :refer instead. From the Clojure 1.4.0 *
*changelog**: "require can now take a :refer option. :refer takes a list of
symbols to refer from the namespace or :all to bring in all public **vars*
*."*"
On Feb 8, 2014 2:39 PM, "Der Engel"  wrote:

> Hi, I'm finding namespaces in Clojure a bit confusion, does know someone
> if the information in this 
> article
>  (from
> 2010) is still current with today Clojure best practices and all the idioms
> are still supported today.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: map semantics

[John D. Hume]

On Fri, Feb 7, 2014 at 9:41 PM, Andy C  wrote:

> I do perceive sets, lists, vector as atoms which are indivisible (well,
> this is not true but this is popular meaning) from semantics standpoint.
> Therefore map is just a function which processes them as whole, again from
> semantics point of view. Implementation and laziness should not matter
> really and we still should get the same result.
>

Following your intuition, what would you expect from the following?
> (map + [1 3 5] '(2 4 6))
# => ?

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

[John D. Hume]

I haven't attempted any code manipulation, just analysis and indexing, but
I embarked on a similar idea here:
https://github.com/duelinmarkers/insfactor and here:
http://github.com/duelinmarkers/insfactor.el. (Nothing Vim-related there,
the similar part is trying to put as much as possible of the smarts into
the same JVM as the project.) It indexes a simple clojure project and
provides a find-usages command, the idea being that find-usages is the
first useful step toward rename-var and move-var commands. (I say "simple"
because it still barfs on some common stuff, including defprotocol, IIRC.)

Focusing on what you're doing in http://github.com/cgag/nrepl-refactor, the
mess I came upon and backed away from when I initially played with
transforming code in Clojure is that the forms are easy to manipulate but
formatting is hard to maintain. There are also several non-whitespace bits
of source that the reader will hide away from you (including comments and
#_ forms) but that a proper refactoring tool won't clobber.

If you haven't already, you might take a look at
https://github.com/cgrand/sjacket.

I've been hoping that the new https://github.com/clojure/tools.analyzer work
will support some of what source manipulation tools are likely to need, but
I haven't looked into it. For example, one hassle with
jvm.tools.analyzer (at least the now outdated version I've been using) is
that the reader doesn't provide line and column metadata in many places
where you'd expect to find it. Another is that it can only show you the
post-macro-expansion view of the world.



On Fri, Feb 7, 2014 at 3:51 PM, Curtis Gagliardi  wrote:

> Hey everyone, I just wanted to get some feedback on whether or not this is
> a good idea.  I've seen clj-refactor.el recommended a decent amount, but as
> a dyed-in-the-wool take-no-prisoners vim user, I can't use it.  I've always
> thought it was weird that refactoring was so tightly coupled to editors and
> IDEs, so I thought I'd try writing some refactors as an nrepl middleware,
> that would ideally be able to be used across editors.  I've only
> re-implemented the threading and some of the cycling refactors from
> clj-refactor.el, but it's to the point where I'm going to investigate
> actually integrating with vim or light table.  I've never written any
> plugins for either of these editors so I might discover there are good
> reasons I haven't seen refactoring done as a client/server type thing.
> Anyway, the code is here: https://github.com/cgag/nrepl-refactor , if
> anyone has any has any feedback I'd love to hear it, and if anyone has
> vimscript or lighttable plugin experience and wants to help, that'd be
> great as well.
>
> Curtis
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Lessons Learned from Adopting Clojure

[John D. Hume]

On Wed, Feb 5, 2014 at 1:27 PM, Sean Corfield  wrote:

> On Feb 5, 2014, at 5:39 AM, John D. Hume  wrote:
> > Could you clarify the difference between LightTable's M-) and using
> C-M-x* in Emacs jacked into an nrepl session with Cider?
>
> M-) is paredit-forward-slurp-sexp in both LightTable and Emacs.
>

Sorry, I thought you were saying that kb shortcut is what "committed" the
change to the running JVM. I now see your point that LightTable keeps
trying to eval each top-level form and show you the result as you edit,
whereas in Emacs you would have to issue a command to see the value of a
top-level form. It seems like a small distinction, but I can see how it
would make work more fluid.

The misconception I hope is disappearing is that REPL-driven development in
Emacs necessarily involves lots of switching and copy-pasting back and
forth between source file buffers and a REPL buffer. The video in Jay's
blog post makes it pretty clear you never need to see the REPL prompt to
use the REPL to change a running system.

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

[John D. Hume]

On Wednesday, February 5, 2014, Sean Corfield wrote:

>  It's one of the things that has me really
> hooked on LightTable. I have my source and test namespaces both open.
> I have them both connected to a "REPL". I can evaluate any code, in
> place, in either file. If I grow some code in the source file, I can
> put (defn some-name [args]) in front of it and M-) slurps it into a
> function - done! If I grow some code in the test file, I can put
> (expect result-value) in front of it and M-) slurps it into a test -
> done!
>

Could you clarify the difference between LightTable's M-) and using
C-M-x* in Emacs jacked into an nrepl session with Cider?

* `eval-defun` or whatever cider replaces that with for clojure.

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

Re: Profiling, VisualVM & random-pause

[John D. Hume]

On Tue, Jan 21, 2014 at 1:50 PM, Yves Parès  wrote:

> 2) All my methods listed in the profiler are suffixed by .invoke. Is it
> normal or is pathological of something (I haven't aot-compiled anything, I
> don't know if it may have an impact here), like unnecessary reflection
> calls?
>

That's normal. Your fns are compiled to implementors of clojure.lang.IFn,
where you can see those invoke methods declared. For methods with "rest
args", they'll subclass clojure.lang.RestFn, and in profilers you'll see
RestFn#invoke calling your function's doInvoke method.

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

Re: type hinting overloaded methods

[John D. Hume]

On Tue, Dec 10, 2013 at 4:25 AM, Phillip Lord
wrote:

> (defn ^IRI iri
>   [name]
>   (cond
>(instance? String name)
>(IRI/create ^String name)
>(instance? java.net.URL name)
>(IRI/create ^java.net.URL name)
>(instance? java.io.File name)
>(IRI/create ^java.io.File name)))
>
> which is a lot longer and, well, just not very nice. I could make this
> neater with a macro -- something like...
>
> (with-types [String, URL, File]
>(IRI/create name))
>
> which would expand into the cond form above. But the instance? checks
> seem not ideal. Is there a better solution?
>

You could create and extend an "IIriCreate" protocol to String, URL, and
File.

I'd like to point out that Java doesn't provide a clean way to handle this
either.

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

Re: [Clojure-CLR] implement interface that has properties

[John D. Hume]

If I recall, properties are just syntactic sugar for awkwardly named
methods. Have you tried the compiler-generated get and set method-names?
On Dec 9, 2013 9:50 AM, "Frank Hale"  wrote:

> I'm trying to implement an interface that has properties but can't quite
> seem to get it to work and I also have not found any relevant examples via
> Google (yet). I'm sure I'm doing something completely wrong here but have
> no idea how to fix it.
>
> (System.Reflection.Assembly/LoadWithPartialName "System.Web")
>
> (defn foo-handler []
> (reify System.Web.IHttpHandler
>  (IsReusable [] false)
> (ProcessRequest [context] (
>
> IsReusable is a property and I don't know how to tell reify that it is not
> a traditional function.
>
> CompilerException clojure.lang.CljCompiler.Ast.ParseException: Must supply
> at least one argument for 'this' in: IsReusable
>
> Okay, I supply 'this' for IsReusable
>
> CompilerException clojure.lang.CljCompiler.Ast.ParseException: Can't
> define method not in interfaces: IsReusable
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: error-on-reflection

[John D. Hume]

Are you aware of `lein check`? We have our some of our CI builds wired to
fail if that finds anything.
On Dec 9, 2013 4:12 AM, "Phillip Lord"  wrote:

>
> I know about *warn-on-reflection* but is there anyway that I can get an
> error-on-reflection instead?
>
> I've been type hinting my application (50% done and yes it goes faster
> now), and it's a bit painful. What I would really want is to have a unit
> test which fails if reflection is used.
>
> So far, my best idea is catching standard-out and parsing it for
> reflection warnings. Not ideal.
>
> Phil
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: expand a form

[John D. Hume]

You won't find the results as easy to read as what you're asking for, but
clojure.tools.analyzer will show you calls that have been inlined by the
compiler.
On Nov 25, 2013 2:24 PM, "Andy Smith"  wrote:

> In your example a full expansion might be : (. clojure.lang.Numbers (add
> 10 1))
>
>
> On Monday, 25 November 2013 17:16:42 UTC, Guru Devanla wrote:
>>
>> Hi Andy,
>>
>> Not sure what you need in terms of function calls being expanded. Can you
>> provide an example.
>>
>> Here is an silly example, even though this kind of macro is not needed:
>>
>> (def addone [v]
>> (+ v 1)
>>
>> (defmacro testmacro [init]
>>(list 'addone init))
>>
>> (macroexpand '(testmacro 10))
>>
>> expands to
>>
>> (addone 10)
>>
>> Thanks
>> Guru
>>
>>
>> On Mon, Nov 25, 2013 at 6:32 AM, Andy Smith wrote:
>>
>>> It doesnt seem to expand function calls though right?
>>>
>>>
>>> On Monday, 25 November 2013 12:55:27 UTC, Andy Smith wrote:

 Hi,

 I am new to clojure and I was wondering if there is a macro I can use
 to fully expand all symbols and macros in a form, without performing the
 final evaluation of the built in functions?

 Thanks

 Andy

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

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

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

[John D. Hume]

On Nov 22, 2013 4:09 PM, "Sean Corfield"  wrote:
>
> Perhaps a solution here is for me to
> put it in a library, on Clojars, under a different name and let folks
> migrate to that as an interim solution (i.e., identical API so folks
> would just update project.clj and update some ns declarations)?

That sounds like a good move.

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

[John D. Hume]

generate-key is not thread-safe. Multiple callers might get the same id.

It would probably be worthwhile to have your debit fn disallow a negative
balance in some way. Maybe also don't allow closing an account unless it
has zero balance. (Though the latter might require coordination between the
"bank" and the account ref, hence bank can't be an atom any more.) Do at
least consider the case where one thread already has a reference to an
account another thread is closing.
 My latest iteration has brought me to this:

https://github.com/jimpil/bankio/blob/master/src/bankio/core.clj

If anyone can think of a more evident and safe approach for demonstration
purposes, by all means, shout out. After consulting the Clojure Programming
book, I decided to use commute for simply depositing in to an account.
There are still 2 fns that use dosync but only modify a single identity,
namely deposit! & withdraw!. I don't see how else this can be done since
they are refs. I would appreciate feedback for this (hopefully) last
version...


many thanks in advance :)

Jim


On 21/11/13 13:19, John D. Hume wrote:

If you want to demonstrate STM with the deposit-withdraw-transfer example,
you definitely need a ref for each account.

I'd suggest an atom for the account-num->balance-ref map ("the bank") and
an atom for the account-num-generator, but you say coordination is
necessary for opening and closing accounts. What coordination do you have
in mind?
On Nov 21, 2013 5:27 AM, "Jim - FooBar();"  wrote:

> also I forgot to add that having the bank in some reference type allows
> opening/closing new accounts, an operation that at least to me sounds like
> it needs coordination...
> So which way is preferred? map-ref that stores values, map that stores
> refs or map-ref that stores refs?
>
> Jim
>
>
> On 21/11/13 10:58, Jim - FooBar(); wrote:
>
>> Hi Stefan,
>>
>> thanks for your interest. let me explain further...
>>
>> 1. I did start with a design that involved a map (the bank) full of
>> agents (accounts). Then I switched to a map full of atoms thinking that I
>> don't really need asynchronous operations. I settled to the single ref
>> approach because it seemed like an overkill to have all these refs inside.
>> Your comment however does make sense...Since there is a single identity,
>> perhaps STM is an overkill...
>>
>> 2. can you ellaborate why you think this is debatable? All the
>> ref-managing fns return the in-transaction value of the ref (i.e. 'alter').
>> My problem was with 'doseq' which returns nil so I followed the general
>> approach of returning the in-transaction value of the ref after it commits.
>>
>> 3. As I understand it these 2 transactions will be composed/merged into a
>> single transaction. Again, originally I had a bare 'alter' (no dosync) on
>> the private fn transfer1 simply because it is hidden and not supposed to be
>> used...think of it as a helper fn for 'transfer'. but then I read somewhere
>> that transaction can be nested without a problem so I thought it is safer
>> to include 'dosync' in tranfer1 as well...
>>
>> I'm not getting you wrong, don't worry...this is the reason I started
>> this thread - need some answers /feedback :)
>>
>> Jim
>>
>>
>> On 21/11/13 10:42, Stefan Kamphausen wrote:
>>
>>> Hi,
>>>
>>> I may be missing something here, since this thread leaves me a bit
>>> confused.
>>>
>>> 1. Why are you using a Ref for the bank in the first place?  It is a
>>> single identity and thus should be an atom, because you do not need to
>>> coordinate changes of at least two identities.
>>>
>>> If I am not mistaken, the generic bank transfer example is to have a Ref
>>> for each of the accounts and to make sure, that there is never a state of
>>> the world in which the money is missing or is available twice.
>>>
>>> 2. "Even our side-effecting fns return something (per alter) which is
>>> good." -> That seems debatable to me.
>>>
>>> 3. Why do you nest transactions on the same Ref in transfer1 and
>>> transfer?
>>>
>>> Don't get me wrong, what you're doing may be fine.  In that case, I just
>>> don't get it.  Which, in turn, may be a relevant feedback to you, since
>>> this is to be educational :-)
>>>
>>>
>>> Kind regards,
>>> Stefan
>>>
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clo

Re: first vals first vals

[John D. Hume]

On Nov 21, 2013 3:32 AM, "Zhemin Lin"  wrote:
> 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 ...?

Maps seem an awkward choice of data-structure for a scenario where you
don't know or care about the keys.

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

[John D. Hume]

If you want to demonstrate STM with the deposit-withdraw-transfer example,
you definitely need a ref for each account.

I'd suggest an atom for the account-num->balance-ref map ("the bank") and
an atom for the account-num-generator, but you say coordination is
necessary for opening and closing accounts. What coordination do you have
in mind?
On Nov 21, 2013 5:27 AM, "Jim - FooBar();"  wrote:

> also I forgot to add that having the bank in some reference type allows
> opening/closing new accounts, an operation that at least to me sounds like
> it needs coordination...
> So which way is preferred? map-ref that stores values, map that stores
> refs or map-ref that stores refs?
>
> Jim
>
>
> On 21/11/13 10:58, Jim - FooBar(); wrote:
>
>> Hi Stefan,
>>
>> thanks for your interest. let me explain further...
>>
>> 1. I did start with a design that involved a map (the bank) full of
>> agents (accounts). Then I switched to a map full of atoms thinking that I
>> don't really need asynchronous operations. I settled to the single ref
>> approach because it seemed like an overkill to have all these refs inside.
>> Your comment however does make sense...Since there is a single identity,
>> perhaps STM is an overkill...
>>
>> 2. can you ellaborate why you think this is debatable? All the
>> ref-managing fns return the in-transaction value of the ref (i.e. 'alter').
>> My problem was with 'doseq' which returns nil so I followed the general
>> approach of returning the in-transaction value of the ref after it commits.
>>
>> 3. As I understand it these 2 transactions will be composed/merged into a
>> single transaction. Again, originally I had a bare 'alter' (no dosync) on
>> the private fn transfer1 simply because it is hidden and not supposed to be
>> used...think of it as a helper fn for 'transfer'. but then I read somewhere
>> that transaction can be nested without a problem so I thought it is safer
>> to include 'dosync' in tranfer1 as well...
>>
>> I'm not getting you wrong, don't worry...this is the reason I started
>> this thread - need some answers /feedback :)
>>
>> Jim
>>
>>
>> On 21/11/13 10:42, Stefan Kamphausen wrote:
>>
>>> Hi,
>>>
>>> I may be missing something here, since this thread leaves me a bit
>>> confused.
>>>
>>> 1. Why are you using a Ref for the bank in the first place?  It is a
>>> single identity and thus should be an atom, because you do not need to
>>> coordinate changes of at least two identities.
>>>
>>> If I am not mistaken, the generic bank transfer example is to have a Ref
>>> for each of the accounts and to make sure, that there is never a state of
>>> the world in which the money is missing or is available twice.
>>>
>>> 2. "Even our side-effecting fns return something (per alter) which is
>>> good." -> That seems debatable to me.
>>>
>>> 3. Why do you nest transactions on the same Ref in transfer1 and
>>> transfer?
>>>
>>> Don't get me wrong, what you're doing may be fine.  In that case, I just
>>> don't get it.  Which, in turn, may be a relevant feedback to you, since
>>> this is to be educational :-)
>>>
>>>
>>> Kind regards,
>>> Stefan
>>>
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Generating functions from data

[John D. Hume]

After some experience with excessively meta-programmed Ruby apps, I
generally try to design an API that is as clean (or almost) as what I'm
tempted to generate and avoid the metaprogramming. For example
(api/get-user-by-id "123") is only slightly nicer than (api/get-by-id :user
"123"), so if the former requires code that some of the team will be afraid
to touch, or requires an extra build step, I prefer the latter.

Maybe if you spell out some of the boiler-plate you want to eliminate we'll
have a better idea of what you're trying to achieve.


On Mon, Nov 18, 2013 at 8:51 PM, Jeremy Heiler wrote:

> On Mon, Nov 18, 2013 at 7:48 PM, Jeremy Heiler wrote:
>
>> I am interested in what you think about generating functions at compile
>> time (with a macro) from data. The specific use case I am thinking about
>> pertains to libraries for large web services with a lot of endpoints. A
>> cost-benefit analysis could probably be done for what size is appropriate,
>> but lets just assume the number of endpoints is large enough for you to
>> start thinking about this.
>>
>> Potential advantages include:
>>
>> - Less boilerplate. It would be less annoying to maintain data that
>> represents each endpoint and generate the boilerplate than it is to
>> maintain a lot of repetitive code.
>>
>> - Shareable. The work done to maintain the endpoint data could be used by
>> multiple libraries for multiple languages. In fact, it could be maintained
>> by the web service itself.
>>
>> Potential disadvantages include:
>>
>> - Limited discoverability. If the code is generated at compile time,
>> there is no direct source for it, which may hinder the ability to view or
>> generate documentation with your favorite tool(s).
>>
>> - Complicated edge cases. Endpoints that require extra code are usually
>> edge cases, but not always. Regardless, breaking from the template may
>> complicate the code further. (I don't think this is a difficult problem to
>> solve, though.)
>>
>> One way to alleviate the "limited discoverability" problem is to generate
>> source code at build time. This is what you would do in langauges like
>> Java, and that has always left me frustrated, so I am not inclined to think
>> it's a good idea. However, feel free to make the case!
>>
>> A language like Clojure makes doing this relatively easy, but is it
>> simple?
>>
>
> Another consequence of this that I forgot to mention in the mail above is
> that there will either need to be way for the library to self-execute the
> macro or require the user to initialize the library. The latter might not
> be too bad considering global (immutable) configuration such as
> authentication credentials and URLs are necessary.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>



-- 
http://elhumidor.blogspot.com/

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

Re: Design question - dependencies and function discovery

[John D. Hume]

Rather than having hidden mutable state for wiring events to handlers,
would it be clearer if the main namespace just passed an :event->[handlers]
map to the event processor?

If that would create a huge, frequently changing data structure, each
namespace with handlers could expose an :event->[handlers] map of its own,
and the main ns could merge-with concat. That would at least make explicit
what's currently implied by the main ns requiring all the handler
namespaces.


On Mon, Nov 18, 2013 at 4:07 PM, dm3  wrote:

> Hello,
>
> Looking for opinions :)
>
> I'm currently building an event-driven service which consumes events using
> handlers. Now, the idea is to define a set of handlers (functions of type
> Event->Unit) in different parts of the service,  which are then invoked
> when an event comes into the system. The dependencies are in the following
> order:
>
> [ns.event-processor] -> [ns.handlers] <- [ns.handler-1], [ns.handler-2]
>
> Definition of a handler in *ns.handler-1* looks like this:
>
> (ns.handlers/defhandler Handler1
>   (on :EventA [event] (do something))
>   (on :EventB [event] (do something else)))
>
> The *defhandler* macro registers the handler in an atom, which is then
> queried when the *ns.event-processor* receives an event.
> You might have already figured out that I run into problems when the event
> processor is invoked and not all of the handler namespaces have been loaded
> yet.
> Currently I resolve this by explicitly requiring all of the namespaces
> which invoke *defhandler* from the main application namespace which
> constructs the running system.
>
> It seems that I'm looking for some cross-ns var discovery mechanism,
> something like classpath scanning in Java (which smells like an
> anti-pattern in Clojure).
> I was wandering whether I'm missing some cleaner/better approach?
>
> Thanks,
> Vadim
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>



-- 
http://elhumidor.blogspot.com/

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

Re: [ANN] datasource 0.1 - Small clojure library for access to environment dependent configuration.

[John D. Hume]

One piece of feedback: the name "datasource" is confusing, given
javax.sql.DataSource, as seen, for example, at
http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html#
setting-up-a-data-source


On Thu, Nov 14, 2013 at 10:09 AM, Andrey Antukh  wrote:
>
> https://github.com/niwibe/datasource
>
> Feedback always welcomed.
> Andrey
>

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

cider status

[John D. Hume]

The last (non-authoritative) word on cider on this mailing list[1] was that
it is unstable. Is that really the case? Is it just a matter of many
packages that depend on it not being updated?

I tried checking the official mailing list[2] and was surprised to find
that it's private.

I'm trying to understand this because I submitted a recipe to MELPA, and
they will no longer accept packages that depend on nrepl.el.

Thanks.
-hume.

[1]
https://groups.google.com/forum/#!searchin/clojure/cider/clojure/JfS7ZzePtA4/ZAPHHn1zS5gJ
Tim
Visher: "Also, Cider is _unstable_ at this point. I'm still using nrepl
0.2.0 and it's working fine. I would _not_ recommend upgrading to Cider at this
point."
[2] https://groups.google.com/forum/#!forum/cider-emacs

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

[John D. Hume]

For me, the one feature that can justify an internal DSL for generating SQL
is the ability to compose queries. I assume that's not on the Yesql
roadmap.
On Nov 11, 2013 5:10 AM, "Kris Jenkins"  wrote:

> https://github.com/krisajenkins/yesql
>
> Yesql is a simple library for blending SQL & Clojure together, cleanly.
> Here's how it works ,
> and how to use it .
>
> Feedback welcomed,
> Kris
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: road map for clojure?

[John D. Hume]

Are you looking at the right repo?
https://github.com/clojure/clojure/commits/master


On Wed, Oct 30, 2013 at 6:02 PM, julius  wrote:

> Hi,
>
> Is clojure under dev? there is no much commits in months, any plan or road
> map  for clojure?
>
> thanks
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
http://elhumidor.blogspot.com/

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

Re: Compulsive over-optimization

[John D. Hume]

What kind of optimal do you compulsively rearrange for? Performance?
Readability? Amusing terseness?
On Oct 18, 2013 6:20 PM, "Kendall Shaw"  wrote:

> With clojure in particular, I am having trouble not rearranging my code to
> be what I think is more optimal in ways that seem probably not practical.
> I've noticed myself doing that when I'm newish to languages and apis. But,
> I go bonkers with clojure.
>
> Do you have any thoughts about how to avoid that, other than Bob Newhart's
> advice:
>
> http://www.youtube.com/watch?**v=Ow0lr63y4Mw
>
> Kendall
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>

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

Re: uberjar problem with Leiningen 2.3.3 (works with 2.3.2)

[John D. Hume]

How does your app serve up the home page?

Have you tried extracting the working uberjar and the broken uberjar and
comparing the resulting directory trees?
On Oct 18, 2013 5:11 PM, "xavi"  wrote:

> Hello,
>
> I have a strange problem when running an uberjar produced by Leiningen
> 2.3.3, which doesn't happen with Leiningen 2.3.2 .
> The uberjar corresponds to a web app I'm working on. With 2.3.3 ...
>
> $ lein clean
> $ lein uberjar
> $ java $JVM_OPTS -cp target/myapp-standalone.jar clojure.main -m
> myapp.server
> $ curl -i http://localhost:8080
> HTTP/1.1 200 OK
> Date: Fri, 18 Oct 2013 21:52:21 GMT
> Last-Modified: Fri, 18 Oct 2013 21:50:47 GMT
> Content-Length: 0
> Content-Type: application/octet-stream
> Server: Jetty(7.x.y-SNAPSHOT)
>
> So, requesting the home page, I get an empty response. But if I generate
> the uberjar with lein 2.3.2 ...
>
> $ lein clean
> $ lein uberjar
> $ java $JVM_OPTS -cp target/myapp-standalone.jar clojure.main -m
> myapp.server
> $ curl -i http://localhost:8080
> HTTP/1.1 200 OK
> Date: Fri, 18 Oct 2013 21:58:54 GMT
> Content-Type: text/html;charset=UTF-8
> Transfer-Encoding: chunked
> Server: Jetty(7.x.y-SNAPSHOT)
>
> 
> 
> ...
>
> then it works!
>
> Any idea on what can be the problem with Leiningen 2.3.3?
> (After hours of trying different things I'm quite desperate now :(
>
> Cheers,
> Xavi
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: finding a call to longCast

[John D. Hume]

If you have some idea where to look in your code, or if there isn't much
code, I'd take a look at clojure.tools.analyzer/analyze-ns[1]. The output
is a little overwhelming, but it's pretty easy to navigate in
clojure.inspector. One issue may be finding the call (e.g. to some
clojure.core fn) that calls RT.longCast. I don't know how many paths lead
to longCast.

[1]
https://github.com/clojure/jvm.tools.analyzer/blob/master/src/main/clojure/clojure/tools/analyzer.clj#L940but
to be clear, I don't mean that you should read clojure.tools.analyzer
code, just use it to look at your code.



On Mon, Oct 14, 2013 at 11:54 PM, Brian Craft  wrote:

> Profiling shows clojure.lang.RT.longCast is currently 25% of the run time
> of the code I'm working on. It's being called from a routine that
> manipulates primitive arrays while building a hex string, with aget, aset,
> inc, and bitwise operations. Looking through the source for those, I can't
> see where it's being called. How can I find it?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
http://elhumidor.blogspot.com/

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

Re: use lein compile a Java project

[John D. Hume]

I believe :dependencies and :resource-paths will be used for the classpath
at both build and run time. Does that meet your needs?


On Fri, Oct 11, 2013 at 8:00 AM, Gaofeng Zeng  wrote:

> How use lein compile a Java project?
>
> I know the java-source-paths can specify the src path. But I don't know is
> there any option can specify the lib path that contains dependencies of
> Java source.
>
> (defproject crawler "0.1.0-SNAPSHOT"
>  :description "FIXME: write description"
>  :url "http://example.com/FIXME";
>  :license {:name "Eclipse Public License"
>:url "http://www.eclipse.org/legal/epl-v10.html"}
>  :dependencies [[org.clojure/clojure "1.5.1"]]
>  :source-paths ["src/clj"]
>  :java-source-paths ["java/NetSpider/src"])
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>



-- 
http://elhumidor.blogspot.com/

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

Re: boolean java interopt puzzle/bug?!

[John D. Hume]

That behavior seems like a bug to me. Do you know whether there's some good
(or stated, good or bad) reason for it?

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/reflect/UnsafeBooleanFieldAccessorImpl.java
On Oct 9, 2013 4:33 PM, "Pablo Nussembaum"  wrote:

>  Thanks for the help and clarifications.
> My problem is that I'm working on a tool, as a part of my thesis, to
> randomly execute annotated java classes to try discover its behavior.
> So if a class has a (b|B)oolean field and I read its value using
> reflection it returns (using Field.get()) a Boolean that for clojure will
> be always false.
>
> In order to solve this issue I created the follow fn:
>
> (defn- get-val
>   [^java.lang.reflect.Field f instance]
>   (let [value (.get f instance)]
> (if (instance? java.lang.Boolean value)
>   (boolean value)
>   value)))
>
> Thanks and regards,
> --
> Bauna
>
>
> On 10/06/2013 10:57 PM, Andy Fingerhut wrote:
>
> There is also this page on ClojureDocs that might shed some light on this
> quirk:
>
> http://clojuredocs.org/clojure_core/clojure.core/if
>
>
> On Sun, Oct 6, 2013 at 6:14 PM, Rob Browning  wrote:
>
>> Gary Trakhman  writes:
>>
>> > Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for
>> speed
>> > reasons (I think) anything that checks for truthiness uses java's ==,
>> which
>> > will fail on any new Boolean object.  Usually, this isn't a problem, but
>> > sometimes it is.  You can see that this assumption is pervasive by
>> looking
>> > at the implementations of 'true?' and 'false?', which use identical? and
>> > the check for != Boolean.FALSE in
>> >
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569
>>
>>  ...and further, my understanding is that the Boolean constructors are
>> more or less considered a mistake, and you should effectively never
>> use them.  For example:
>>
>>   http://rayfd.me/2007/01/17/the-evil-boolean-constructors/
>>
>> Hope this helps
>> --
>> Rob Browning
>> rlb @defaultvalue.org and @debian.org
>> GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
>> GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] Grenchman, for running Clojure code quickly

[John D. Hume]

On Wed, Oct 9, 2013 at 2:32 AM, Zack Maril  wrote:

> How does this vary from flatland/drip?
> -Zack
>

Grenchman connects to a JVM-with-nrepl you previously launched. Repeated
invocations from the command line will hit that same JVM, potentially
building up state over time, and Grenchman knows nothing of the JVM's
lifecycle.

Drip is a JVM "pre-launcher," so every time you run drip (with the same
classpath), you're running in a fresh JVM, with no state hanging around
from previous invocations.

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

Re: How to go about 'proving' why dynamically typed languages are better.

[John D. Hume]

On Oct 8, 2013 5:35 AM, "Phillip Lord"
>
> > However… I find that I am writing a lot of statements like this:
> >
> > (cond (hash-map? v)
> > ……
> >
> >(vector? v)
> > ……
> >
> >(list? v)
> >…..
> >
> > :else …..)
> >

zcaudate, in what context(s) do you find yourself writing a lot of
expressions like that? I rarely want to allow so much flexibility in
arguments. I'm wondering if there are idioms to avoid it.

> > I'm not sure a type checker will help in that instance.
>
>
> A type-checker wouldn't no, but a type system would; pretty much
> every language with a static type system has a type based dispatch
> somewhere. It would be nice to be able to do
>
> (defun fn
>   ([^vector v] ...)
>   ([^list l] ...)
>   ([else] ...)

How is Clojure's protocols feature different from what you're describing?

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

[John D. Hume]

On Oct 7, 2013 3:29 AM, "Phillip Lord"  wrote:
> Tend to agree with this also. As nice as leiningen is, Clojure seems to
> inherit from Java bulky projects. Compare these two hello worlds:
>
> (println "hello world")
>
> to
>
> #!/usr/bin/python
> print( "hello world" )
>
> Both equivalently simple, up and till the point you actually try to run
> them. The best I came up with is...
>
> java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar
hello_world.clj
>
> which, of course, depends on me having installed leiningen and used it.

I'd suggest that Clojure's "Hello, World!" should happen initially at the
repl, where leiningen definitely simplifies the UX.

lein repl # from any cwd
(println "...")

which launches nicely into demonstrating dynamic development.

If your students work with Java, I'd make a point of demonstrating the joy
of the Clojure repl + Java interop, useful even when your project is pure
Java.

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

[John D. Hume]

WebDriver's HtmlUnitDriver is only one of many supported drivers. Most
Selenium-using teams I've been on have driven real browsers using another
driver (which among other benefits allows one to generate realistic screen
shots).

The one team I was on that used HtmlUnit (a couple years ago) blamed it for
sporadic test failures and had their own patched version that supposedly
fixed concurrency issues (that they'd submitted as a patch but had not been
accepted). I wasn't close to that research, so I can't attest to the issues
personally.



On Sun, Oct 6, 2013 at 8:40 AM, Kelker Ryan  wrote:

>  I've never tried it for unit testing, but it's the de facto Java library
> for headless browsers and it's the driving force behind products such as
> Selenium WebDriver => http://seleniumhq.org/
>
> I mostly use it for bot creation/automation and it supports many versions
> of popular web browsers such as Firefox (3.6, 10, 17), Chrome (+ 16), and
> IE (6, 7, 8, 9) =>
> http://htmlunit.sourceforge.net/apidocs/com/gargoylesoftware/htmlunit/BrowserVersion.html
>
> 06.10.2013, 20:23, "Mimmo Cosenza" :
>
> Hi all,
> did anyone give a try to this java based HTMLUnit headless browser for
> cljs unit test to be used of phantomjs?
>
> http://htmlunit.sourceforge.net/
>
> Thanks
>
> Mimmo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
http://elhumidor.blogspot.com/

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

Re: Type of let form

[John D. Hume]

It seems like at least a gray area. Notably, clojure.core/destructure is
one of only 35 undocumented (via metadata) public vars out of almost 600 in
clojure.core. Here's the full list (1.5.1):

(->> 'clojure.core ns-publics vals (filter (comp nil? :doc meta)) (map
#(.sym %)) sort)
(*allow-unresolved-vars* *assert* *fn-loader* *math-context* *source-path*
*use-context-classloader* *verbose-defrecords* -cache-protocol-fn
-reset-methods EMPTY-NODE await1 chunk chunk-append chunk-buffer chunk-cons
chunk-first chunk-next chunk-rest chunked-seq? destructure
find-protocol-impl find-protocol-method hash-combine method-sig munge
primitives-classnames print-ctor print-dup print-method print-simple
proxy-call-with-super proxy-name unquote unquote-splicing
with-loading-context)



On Fri, Oct 4, 2013 at 3:48 PM, Gary Trakhman wrote:

> I agree user code probably shouldn't rely on the details of what's a
> special form and what isn't.  However, I see no problem with using
> destructure in user code, I've done so myself, and I don't think it's
> necessarily platform-specific.
>
> It's more obvious the intent when things are intentionally marked
> 'private'.  Seems like anything else is fair-game, with java bits being a
> clear delineation of host-specific functionality.
>
>
> On Fri, Oct 4, 2013 at 4:20 PM, John D. Hume wrote:
>
>> This seems intentional, not a case of docs lagging behind. If you look at
>> the source of let you can see that it has :special-form true in its
>> metadata so that it will remain documented as special even though it's just
>> a macro.
>>
>> I assume the thinking is that it's more useful to continue to document
>> let, loop, and maybe others as special forms than to tell you they're
>> macros that expand into uglier calls to special forms, and then go on to
>> document (and support the APIs of) clojure.core/destructure and the less
>> sugary, true special forms (let*, loop*, and maybe others).
>>
>> It's probably safe to assume these are implementation details that won't
>> necessarily hold in other dialects of Clojure and that breaking changes in
>> that layer might be introduced in a future version of Clojure and would not
>> be considered a backwards-incompatible change by the maintainers.
>>
>>
>>
>> On Fri, Oct 4, 2013 at 2:47 PM, Amrut  wrote:
>>
>>> Thanks. I went through the checkins and looks like it was changed 
>>> here.<https://github.com/clojure/clojure/commit/3129be6d80d315e3be2f77dadcf7e904fc6015f5>
>>>  This
>>> was 6 years back. Maybe it's time to update the documentation for special
>>> forms.
>>>
>>>
>>> On Friday, October 4, 2013 11:41:22 AM UTC-7, Gary Trakhman wrote:
>>>
>>>> The definitive authority on what is a special form and what isn't is
>>>> Compiler.java:
>>>>
>>>> https://github.com/clojure/**clojure/blob/master/src/jvm/**
>>>> clojure/lang/Compiler.java#L39<https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L39>
>>>>
>>>>
>>>> On Fri, Oct 4, 2013 at 2:27 PM, Amrut  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> According to this <http://clojure.org/special_forms>, "let" is a
>>>>> special form. but the 
>>>>> source<http://clojuredocs.org/clojure_core/clojure.core/let> tells
>>>>> me that it's a macro that uses let*. I could not find any info on let* 
>>>>> form.
>>>>> Can someone please explain what is happening here?
>>>>>
>>>>> TIA
>>>>>
>>>>> --
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To post to this group, send email to clo...@googlegroups.com
>>>>>
>>>>> Note that posts from new members are moderated - please be patient
>>>>> with your first post.
>>>>> To unsubscribe from this group, send email to
>>>>> clojure+u...@**googlegroups.com
>>>>>
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To unsubscribe from this group and stop receiving e

Re: Type of let form

[John D. Hume]

This seems intentional, not a case of docs lagging behind. If you look at
the source of let you can see that it has :special-form true in its
metadata so that it will remain documented as special even though it's just
a macro.

I assume the thinking is that it's more useful to continue to document let,
loop, and maybe others as special forms than to tell you they're macros
that expand into uglier calls to special forms, and then go on to document
(and support the APIs of) clojure.core/destructure and the less sugary,
true special forms (let*, loop*, and maybe others).

It's probably safe to assume these are implementation details that won't
necessarily hold in other dialects of Clojure and that breaking changes in
that layer might be introduced in a future version of Clojure and would not
be considered a backwards-incompatible change by the maintainers.



On Fri, Oct 4, 2013 at 2:47 PM, Amrut  wrote:

> Thanks. I went through the checkins and looks like it was changed 
> here.
>  This
> was 6 years back. Maybe it's time to update the documentation for special
> forms.
>
>
> On Friday, October 4, 2013 11:41:22 AM UTC-7, Gary Trakhman wrote:
>
>> The definitive authority on what is a special form and what isn't is
>> Compiler.java:
>>
>> https://github.com/clojure/**clojure/blob/master/src/jvm/**
>> clojure/lang/Compiler.java#L39
>>
>>
>> On Fri, Oct 4, 2013 at 2:27 PM, Amrut  wrote:
>>
>>> Hello,
>>>
>>> According to this , "let" is a
>>> special form. but the 
>>> source tells
>>> me that it's a macro that uses let*. I could not find any info on let* form.
>>> Can someone please explain what is happening here?
>>>
>>> TIA
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
http://elhumidor.blogspot.com/

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

Re: Jsonify a Jdbc4Array in Clojure

[John D. Hume]

I believe it was on the clojure-docs page (linked from the
clojure.java.jdbc readme) where they talk about managing your own
connection.

The more idiomatic way may be to wrap the whole thing in some transaction
fn or macro. Sorry I'm not familiar with the API. A lot of vars are
deprecated, but their doc strings don't say what to do instead.
On Oct 2, 2013 9:05 AM, "Christian Jauvin"  wrote:

> Actually, re-reading the jdbc/query doc
>
> http://clojure.github.io/java.jdbc/#clojure.java.jdbc/query
>
> I can't find any reference to this ":connection" keyword param.. may I ask
> where you got it from?
>
>
>
>
> On Wednesday, October 2, 2013 9:50:13 AM UTC-4, Christian Jauvin wrote:
>>
>> Ah finally, thanks John, the "with-open" pattern was indeed the missing
>> piece: it works!
>>
>> Just to summarize, here's what works for me:
>>
>> (extend-type org.postgresql.jdbc4.**Jdbc4Array
>>   json/JSONWriter
>>   (-write [o out]
>> (json/-write (.getArray o) out)))
>>
>> ; plus any other additional required custom JSON writers
>> (java.sql.Timestamp, Date, etc)
>>
>> (with-open [conn (jdbc/get-connection *db*)]
>>   (json/write-str
>> (jdbc/query {:connection conn}
>> ["select * from .."])))
>>
>>
>>
>> On Wednesday, October 2, 2013 12:06:44 AM UTC-4, John Hume wrote:
>>>
>>> I don't use clojure.java.jdbc, so this may be non-idiomatic or just
>>> wrong, but have you tried something like
>>>
>>> (with-open [connection (jdbc/db-connection *db*)]
>>>   (json/write-str
>>> (jdbc/query {:connection connection}
>>>   ["SELECT * FROM..."])))
>>>
>>>
>>>
>>> On Tue, Oct 1, 2013 at 8:13 PM, Christian Jauvin wrote:
>>>
 Hi Philippe,

 The Jdbc4Array that's causing me trouble is not the "outer" one,
 returned from jdbc/query: that one seems to be properly handled by
 json/write-str.

 The problem happens with a Postgres table containing a text[] column:

 create table something (
 something_id serial primary key,
 list_of_something text[]
 )

 In that case the query returns an ("inner") array for each record, and
 it gets converted to a Jdbc4Array, which, when passed to the JSON
 writer, causes the problem.

 Querying a table without a PG array works perfectly fine though.



 On Tuesday, October 1, 2013 4:21:33 PM UTC-4, Philippe Guillebert wrote:

> Hi,
>
> You probably need to realize your query using (doall (jdbc/query ...))
>
> Also, I was wondering, depending on your needs, you could convert
> Jdbc4Array into a native type (vector ?) as a post-processing
> function of your query and forget about registering JSON writers.
>
>
>
> On Tue, Oct 1, 2013 at 9:00 PM, Christian Jauvin wrote:
>
>> Hi Roman,
>>
>> This approach works for java.sql.Timestamp, which was another type
>> for which a JSON writer wasn't defined in my case.
>>
>> For org.postgresql.jdbc4.**Jdbc4**Array however, there's something
>> missing, because I get:
>>
>> *org.postgresql.util.PSQLException: This connection has been
>> closed.*
>>
>> As the person answering me on Stack Overflow suggested, it seems that
>> the resultset should be somehow processed before the connection is 
>> closed,
>> but I really don't know how to do given the construct I'm currently 
>> using:
>>
>> (json/write-str
>>   (jdbc/query *db*
>> ["SELECT * FROM .."]))
>>
>> where and how could I intercept the resultset that way? Thanks.
>>
>>
>>
>> On Tuesday, October 1, 2013 12:49:10 PM UTC-4, r0man wrote:
>>>
>>> I think you need to implement the JSONWriter protocol for the
>>> Jdbc4Array class, and possibly for the datatypes that are in the
>>> array. This for example makes the json library aware of
>>> java.util.Date classes.
>>>
>>> (extend-type java.util.Date
>>>   JSONWriter
>>>   (-write [date out]
>>> (-write (str date) out)))
>>>
>>> Something like this (not tested):
>>>
>>> (extend-type org.postgresql.jdbc4.**Jdbc4Array
>>>   JSONWriter
>>>   (-write [array out]
>>> (-write (seq (.getArray array)) out)))
>>>
>>> Roman
>>>
>>>
>>> On Tuesday, October 1, 2013 3:57:02 PM UTC+2, Christian Jauvin wrote:

 Hi,

 I asked this question on Stack Overflow yesterday:

 I want to jsonify the results of a query performed against a
 Postgres table containing a column of type text[], but the problem
 is that clojure.data.json.write-str doesn't seem to know how to
 handle PG arrays:

 *Exception Don't know how to write JSON of class
 org.postgresql.jdbc4.Jdbc4Array  clojure.data.json/write-generic*

  Do I have to supply a custom handler, or is there a simpler way?


 http:/

Re: Jsonify a Jdbc4Array in Clojure

[John D. Hume]

I don't use clojure.java.jdbc, so this may be non-idiomatic or just wrong,
but have you tried something like

(with-open [connection (jdbc/db-connection *db*)]
  (json/write-str
(jdbc/query {:connection connection}
  ["SELECT * FROM..."])))



On Tue, Oct 1, 2013 at 8:13 PM, Christian Jauvin  wrote:

> Hi Philippe,
>
> The Jdbc4Array that's causing me trouble is not the "outer" one, returned
> from jdbc/query: that one seems to be properly handled by json/write-str.
>
> The problem happens with a Postgres table containing a text[] column:
>
> create table something (
> something_id serial primary key,
> list_of_something text[]
> )
>
> In that case the query returns an ("inner") array for each record, and it
> gets converted to a Jdbc4Array, which, when passed to the JSON writer,
> causes the problem.
>
> Querying a table without a PG array works perfectly fine though.
>
>
>
> On Tuesday, October 1, 2013 4:21:33 PM UTC-4, Philippe Guillebert wrote:
>
>> Hi,
>>
>> You probably need to realize your query using (doall (jdbc/query ...))
>>
>> Also, I was wondering, depending on your needs, you could convert
>> Jdbc4Array into a native type (vector ?) as a post-processing function
>> of your query and forget about registering JSON writers.
>>
>>
>>
>> On Tue, Oct 1, 2013 at 9:00 PM, Christian Jauvin wrote:
>>
>>> Hi Roman,
>>>
>>> This approach works for java.sql.Timestamp, which was another type for
>>> which a JSON writer wasn't defined in my case.
>>>
>>> For org.postgresql.jdbc4.**Jdbc4Array however, there's something
>>> missing, because I get:
>>>
>>> *org.postgresql.util.PSQLException: This connection has been closed.
>>> *
>>>
>>> As the person answering me on Stack Overflow suggested, it seems that
>>> the resultset should be somehow processed before the connection is closed,
>>> but I really don't know how to do given the construct I'm currently using:
>>>
>>> (json/write-str
>>>   (jdbc/query *db*
>>> ["SELECT * FROM .."]))
>>>
>>> where and how could I intercept the resultset that way? Thanks.
>>>
>>>
>>>
>>> On Tuesday, October 1, 2013 12:49:10 PM UTC-4, r0man wrote:

 I think you need to implement the JSONWriter protocol for the
 Jdbc4Array class, and possibly for the datatypes that are in the
 array. This for example makes the json library aware of
 java.util.Date classes.

 (extend-type java.util.Date
   JSONWriter
   (-write [date out]
 (-write (str date) out)))

 Something like this (not tested):

 (extend-type org.postgresql.jdbc4.**Jdbc4Arra**y
   JSONWriter
   (-write [array out]
 (-write (seq (.getArray array)) out)))

 Roman


 On Tuesday, October 1, 2013 3:57:02 PM UTC+2, Christian Jauvin wrote:
>
> Hi,
>
> I asked this question on Stack Overflow yesterday:
>
> I want to jsonify the results of a query performed against a Postgres
> table containing a column of type text[], but the problem is that
> clojure.data.json.write-str doesn't seem to know how to handle PG
> arrays:
>
> *Exception Don't know how to write JSON of class org.postgresql.jdbc4.
> Jdbc4Array  clojure.data.json/write-generic*
>
> Do I have to supply a custom handler, or is there a simpler way?
>
>
> http://stackoverflow.com/**quest**ions/19103870/jsonify-a-**jdbc4a**
> rray-in-clojure
>
> I'm asking it here in the hope of getting (maybe) a simpler solution,
> or at least one I can implement readily, because the problem I have with
> one of the suggestions I received (extending org.postgresql.jdbc4.**
> Jdbc4Arra**y to implement the missing function) is that I don't know
> how to make it work with my usage pattern, which is simply:
>
> (json/write-str
> (jdbc/query *db*
> ["SELECT * FROM ..."]))
>
> How do I "get the array before the connection is closed" with such a
> construct? Is there another way?
>
>   --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>
>>
>>
>> --
>> Philippe
>>

Re: Type hints for clojure.set functions

[John D. Hume]

On Sep 28, 2013 1:47 PM, "splondike"  wrote:
>
> Can anyone else think of a reason why we should not add type hints to the
functions, or why coercing the arguments to sets is better (or something
else I haven't thought of)?

IIRC, type hints are only used by the compiler to generate non-reflective
interop code. If you don't do interop, they have no effect. (So you won't
get an exception if you pass an incompatible type, unless there's a Java
method call in there, and I doubt clojure.set does (m)any.)

Iff clojure.set could call clojure.core/set on the appropriate args with
zero performance penalty when the arg were already a set, then I think I'd
want it to do so.

I'd guess the thinking behind the current code is "if they want to do set
operations on their data, let them decide when and how to get that data to
be a set."

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

[John D. Hume]

I haven't tried this, so apologies if it couldn't even work, but have you
considered providing a fn in your library intended to be used inside the ns
macro?  The refer-clojure :exclude boilerplate could be replaced with
something like this.

(ns my-thing
  (:require core.matrix.ns)
  (:core.matrix.ns/exclude-clojure-core-math-ops)
  (:use core.matrix))

It's not too much boilerplate, and probably explicit enough for anyone who
was going to :refer :all anyway.

(Sorry for butchering your lib's name. Mobile keyboard bad for code.)
On Sep 4, 2013 8:22 PM, "Mikera"  wrote:

> Hi all,
>
> While building the API for core.matrix, I've fun into a few cases where
> the "best" name is a direct clash with clojure.core.
>
> Examples are "+", "zero?", "vector?", "=="
>
> In many of these cases, the core.matrix behaviour is a natural extension
> of the clojure.core function (i.e. it extends the same functionality to
> arbitrary N-dimensional arrays).
>
> I'm not very happy with any of the options I can see for handling this:
>
> A) Use the good names in the "clojure.core.matrix" namespace. Problem:
> that gives you a ton of nasty warnings of the type "WARNING: + already
> refers to: #'clojure.core/+ in namespace: test.blank, being replaced by:
> #'clojure.core.matrix/+". Significant boilerplate must be maintained by the
> user in their ns declaration to prevent these warnings. I don't like
> forcing users to maintain boilerplate, and I think that normal idiomatic
> usage should be warning-free.
>
> B) Separate the name-clashing functions into separate namespaces - e.g.
> "clojure.core.matrix.operators". Problem: that's something of an artificial
> division, and again it forces users to do extra ns-management work to
> access the functions they want.
>
> C) Use different names. Problem: names would be worse, and this would be
> inconsistent and confusing, especially for functions that do effectively
> the same thing.
>
> D) Encourage users to use aliases. Problem: that's horrendously ugly and
> inconvenient for numerical code. Users with any sense of elegance in their
> coding style would quite rightly throw their hands up in disgust.
>
> Currently we're doing B), I'd prefer to do A) but can't figure out a way
> to automatically suppress the warnings.
>
> Any better ideas?
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Java Metadata Wrapper

[John D. Hume]

On Fri, Aug 30, 2013 at 2:16 PM, JvJ  wrote:

> Would it be possible (or even useful) to create some kind of generic IMeta
> structure that can wrap other Java objects and have them act like normal,
> except for the added metadata (or even other Clojure-esque features)?
>

Are you interested in :tag metadata or something else? Just curious what
the use-case is.

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

[John D. Hume]

On Aug 22, 2013 2:19 PM, "Softaddicts"  wrote:
>
>
>
>
> > Jim,
> > > This is indeed a hack and not a best practice, maybe you're not using
the > right tool for your problem...
> > > - If you want to exchange data (think values), you should not be in
need of > keeping types and meta data
>
> Metadata is part of the Clojure environment and part of the value domain
it handles.
> Why should it not be transmitted along with the value ?
> If the receiver is not written in Clojure it may be questionable an
probably not
> very useful to transmit it but otherwise ?

I don't think anyone suggested the type of a record should not be part of
its edn representation. Here we're talking about arbitrary metadata. While
it is "part of the Clojure environment," the way in which it's "part of the
value domain it handles" is... subtle.

"An important thing to understand about metadata is that it is not
considered to be part of the value of an object. As such, metadata does not
impact equality (or hash codes). Two objects that differ only in metadata
are equal."
http://clojure.org/metadata

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

[John D. Hume]

On Aug 22, 2013 6:25 AM, "Jim"  wrote:
> this is funny! I thought about this approach but I originally considered
it to be a clever hack rather than the official way to do this...

If you need some data persisted or sent over the wire, then it should
probably be considered part of a value, and maybe metadata isn't an
appropriate place to store it. It could go into the record, as in Meikel's
workaround, or in some wrapper structure, if you need to maintain the
behavior that records with distinct metadata can compare =. (Or you could
embed the data in the record but `#(dissoc % :data-fka-meta)` only when you
want to compare while disregarding that data.)

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

[John D. Hume]

On Aug 19, 2013 5:53 AM, "Phillip Lord" 
wrote:
>
> That would be true, if I knew what my code was going to do when I
> started. But most of my code is used to investigate things that I don't
> understand; so it evolves slowly over time. I don't know when I start
> what "low-level" is going to be. So, I'm left with the task of removing
> forward declarations at the end.

I don't think Stuart was suggesting that you start by writing low-level fns
at the top but that, as you extract or introduce low-level things to
support the idea you're working on, you put them above where you're working
(instead of just putting the forward declarations there).

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

[John D. Hume]

Though in some cases the performance impact could be significant, my
concern is readability. My understanding of the concept of partial function
application is that it's about supplying some but not all of the arguments.
So when I see `partial` in code, I expect more arguments to be supplied
later, which is confusing when that's not the case. (Obviously context can
make it easy to see that there will be no more arguments, but often that
context is not present.)



On Tue, Aug 13, 2013 at 7:47 AM, Jay Fields  wrote:

> Say you have a simple function: (defn do-work [f] (f))
>
> When you want to call do-work you need a function, let's pretend we
> want to use this function: (defn say-hello [n] (println "hello" n))
>
> Which of the following solutions do you prefer?
>
> (do-work (partial say-hello "bob"))
> (do-work #(say-hello "bob"))
>
> I'd been using partial (which I font-lock**), but a teammate recently
> pointed out that partial's documentation explicitly calls out the fact
> that the number of args to partial should be less than the number of
> args to f. In practice it's been working 'fine', but I can't help but
> wonder if I'm sacrificing something I'm not aware of (performance?)
>
> ** with a font-lock, using partial *displays* the same number of chars
> as the reader macro solution, and I find it more readable when
> everything is in the parenthesis. -
> http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
http://elhumidor.blogspot.com/

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

Re: Making Music with Clojure: Meta-eX

[John D. Hume]

Great demonstration. I'd love to have the camera video side-by-side w/
screencast video (and large enough to read your code as you play).


On Thu, Aug 8, 2013 at 9:16 AM, Sam Aaron  wrote:

> Hey everyone,
>
> I just thought I'd give you a heads up of what I'm currently doing with
> Clojure and Overtone within the music space. I gave a talk at a music tech
> conference in London a good few months ago and they just put the video
> online:
>
> https://www.youtube.com/watch?v=zJqH5bNcIN0
>
> It's a pretty good description of the kinds of things we do (as Meta-eX)
> and a demonstration of the power of Clojure for making and manipulating
> music live in front of an audience. We also put a different spin on the
> notion of performance testing of our software ;-)
>
> The great thing about this video for me is that I can clearly see the huge
> improvements we've made since then. Clojure is such a joy to hack with and
> I feel wonderfully productive with it. Our system is a massively concurrent
> beast handling and coordinating many different streams of information
> (nREPL comms, MIDI devices, monomes, OSC messages, etc.) in addition to
> coordinating the synthesis engine with the GLSL shaders. Such fun stuff!
>
> For more info, check us out here: http://meta-ex.com
>
> Finally, for anyone in the London/Cambridge area - you might want to come
> to Wysing Arts Festival to see us play:
> http://www.wysingartscentre.org/whats_on/annual_music_festival
>
> Sam
>
> ---
> http://sam.aaron.name
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>


-- 
http://elhumidor.blogspot.com/

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

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

[John D. Hume]

On Mon, Aug 5, 2013 at 8:55 PM, John D. Hume wrote:

> ICE concerns?
>
IDE concerns.

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

[John D. Hume]

On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta  wrote:

> https://github.com/kovasb/paredit-widget
>


> The bigger idea is that code editing should be available a la carte.
>
> Tying something as fundamental as code editing together with IDE concerns
> (file & project management, artifact generation, debugging, etc)  is a
> mistake with profound consequences.
>

That's an interesting idea. How would you envision interactions like "jump
to definition" or even auto-completion working in an editor decoupled from
ICE concerns?

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

[John D. Hume]

I think I'd rather see separate functions or macros for consuming from a
channel with the "maybe throw" behavior rather than having the standard
consume form(s) come with that feature (or threat, depending on whether you
want it). At that point you're back to the earlier advice to wrap
core.async to fit your approach.

As new as core.async is to the Clojure community, it seems premature to
build in an error-handling approach that may turn out not to be appropriate
for many users.
 On Aug 1, 2013 5:19 AM, "Alice"  wrote:

throw>! is an explicit operation, and there's no special channel states
involved. It's passing an exception like other data that just automatically
throws it when taken. So it won't hurt anybody. You can use it when you
need it, you can ignore it if you don't need it. Yet, it makes using async
functions look almost identical to the sync functions.


On Thursday, August 1, 2013 3:37:51 AM UTC+9, tbc++ wrote:

> The position of core.async is to not specify how exceptions should be done
> (instead leaving it up to the user). So if that method works well for you,
> write some macros and use it!
>
> Other methods may be the use of supervisor channels. In this model, go
> blocks that die would enqueue the exception into a global (or shared)
> channel and the go block would then be re-started by a monitor process.
>
> Both methods (and may more) are supported by core.async...it simply
> doesn't care how you handle exceptions, but it is up to you to specify how
> they are handled.
>
> Timothy
>
>
> On Wed, Jul 31, 2013 at 11:49 AM, Alice  wrote:
>
>> It would be nice to have a function throw>! that puts an exception into
>> the channel and throws it when taken, so that I can write
>>
>> (let [c (chan)]
>>   (go (throw>! c (Exception.)))
>>   (go (try
>> (prn (> (catch Throwable t
>>   (prn "exception")
>>
>> instead of
>>
>> (let [c (chan)]
>>   (go (>! c (Exception.)))
>>   (go (try
>> (let [res (>   (if (instance? Throwable res)
>> (throw res)
>> (prn res)))
>> (catch Throwable t
>>   (prn "exception")
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@**googlegroups.com
>>
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@**googlegroups.com.
>>
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
 --
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

Re: clojure keyword spec

[John D. Hume]

It's probably worth distinguishing between the "spec" as documented on
clojure.org (or https://github.com/edn-format/edn if you prefer) and what
the reader permits. Symbols are documented to begin with a non-numeric
character (with a special note in the EDN spec about the names of
namespaced symbols following the same first-character rule. Keywords are in
both documents described as following the rules of symbols.

The first char restriction for symbols makes sense, since they're Clojure's
identifier type, and the reader needs to be able to distinguish between a
number like `2M` and a symbol. I haven't thought of a reason it's important
to have the same restriction on keywords, but there may well be one.

Switching gears, you can do this (at least in Clojure 1.5.1):

(keyword "foo" "1")
(symbol "foo" "1")

but since the docs say these are invalid, I wouldn't recommend using it in
non-throw-away code.



On Wed, Jul 31, 2013 at 2:59 PM, Brent Millare wrote:

> I've been discovering in my code that namespaced identifiers are a
> wonderful thing. In particular, I am found of namespaced integers as an id.
>
> Keywords usually serve the role as identifiers, but currently, the spec
> does not allow namespaced integers, which is odd since integers are valid
> as keywords and you can namespace words.
>
> Again in table form:
>
> Keyword...
> name-starts-with | has-namespace | is-valid?
> letter, no, yes
> letter, yes, yes
> number, no, yes
> number, yes, no <-- This is odd
>
> Can we change this so we don't get stack traces like so?
>
> clojure.lang.LispReader$ReaderException: java.lang.RuntimeException:
> Invalid token: :asdf/3a
>LispReader.java:220
> clojure.lang.LispReader.read
>  core.clj:3407 clojure.core/read
>  core.clj:3405 clojure.core/read
>  interruptible_eval.clj:52
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>   main.clj:257 clojure.main/repl[fn]
>   main.clj:257 clojure.main/repl[fn]
>   main.clj:277 clojure.main/repl[fn]
>   main.clj:277 clojure.main/repl
>   RestFn.java:1096
> clojure.lang.RestFn.invoke
>  interruptible_eval.clj:56
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>   AFn.java:159
> clojure.lang.AFn.applyToHelper
>   AFn.java:151 clojure.lang.AFn.applyTo
>   core.clj:617 clojure.core/apply
>  core.clj:1788
> clojure.core/with-bindings*
>RestFn.java:425
> clojure.lang.RestFn.invoke
>  interruptible_eval.clj:41
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:171
> clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn]
>  core.clj:2330 clojure.core/comp[fn]
> interruptible_eval.clj:138
> clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
>AFn.java:24 clojure.lang.AFn.run
>   ThreadPoolExecutor.java:1145
> java.util.concurrent.ThreadPoolExecutor.runWorker
>ThreadPoolExecutor.java:615
> java.util.concurrent.ThreadPoolExecutor$Worker.run
>Thread.java:724 java.lang.Thread.run
> Caused by: java.lang.RuntimeException: Invalid token: :asdf/3a
>  Util.java:219
> clojure.lang.Util.runtimeException
>LispReader.java:326
> clojure.lang.LispReader.interpretToken
>LispReader.java:211
> clojure.lang.LispReader.read
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>



-- 
http://elhumidor.blogspot.com/

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members ar

Re: [ANN] verily, non-magic testing lib

[John D. Hume]

I've never tried it, but I like the idea of test fns returning their
results.

On Jul 24, 2013 8:30 AM, "Steven Degutis"  wrote:
>
> Also, I've been considering having a non-side-effecty way of returning
test results. What do people think? It would get rid of the last bit of
magic in the lib.
>
>
> ;; current style (side-effecty)
>
> (defn test-1 []
>   (let [foo (get-foo)]
> (expect empty? foo)
> (expect awesome? foo)))
>
> ;; proposed style (more functional)
>
> (defn test-1 []
>   (let [foo (get-foo)]
> [(expect empty? foo)
>  (expect awesome? foo)]))
>

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

[John D. Hume]

Note that `merge` is basically just `conj` plus nil-checking, so there's a
good chance `conj!` already does what you need.
On Jul 2, 2013 5:33 AM, "Amir Wasim"  wrote:

> Is there reset! and merge a possibility for (transient {})
>
> sometimes we have a doseq and it might be requirement sometime.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: -> macro and accessing context

[John D. Hume]

I believe the intended idiom for as-> (and the reason it doesn't take a
binding vector, like other forms that create locals) is

(-> {}
  (assoc :a "a")
  (as-> ctx
(assoc ctx :b (some-fn ctx
On Jul 2, 2013 1:12 AM, "Meikel Brandmeyer (kotarak)"  wrote:

> Hi,
>
> since 1.5 there is 
> as->
> :
>
> (as-> {} ctx
>   (assoc ctx :a "a")
>   (assoc ctx :b (some-fn ctx)))
>
> Kind regards
> Meikel
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Is there a better way to update a map atom?

[John D. Hume]

It's worth knowing that the "moment" is implemented via a compare-and-set,
and if the value has been changed (by another thread), the fn you passed to
swap! will be called again with the atom's new value.
On Jun 28, 2013 11:57 PM, "Greg"  wrote:

> OK, I've found something that shows how these two work when used in the
> implementation of a generator:
>
> https://gist.github.com/daveray/1263503
>
> I think I understand what the problem is now:
>
> (reset! id (inc @id))
>
> There's a "time gap" in between the dereference of 'id' and its assignment
> back to 'id' (after being incremented).
>
> With swap!, no such problem exists, because it's an atomic operation where
> there is no such "time gap" between dereferencing, applying a function, and
> setting the new value. That all takes place in on magical atomic moment.
>
> If I've got this wrong, please let me know!
>
> Cheers,
> Greg
>
> On Jun 28, 2013, at 11:19 PM, Greg  wrote:
>
> Can anyone explain the relationship between swap! and reset! ?
>
> Why is using swap! in this example "safe" and using reset! not?
>
> I've tried searching google for comparisons of the two but can't find
> anything, and the documentation doesn't help much.
>
> Thanks,
> Greg
>
> On Jan 21, 2013, at 6:22 PM, Stephen Compall 
> wrote:
>
> On Jan 21, 2013 3:28 PM, "Jim - FooBar();"  wrote:
> > ...or you can go all the way, skipping reset! completely:
> >
> > (swap! game-objects (fn [objects] (reduce-kv #(assoc % %2 (update-object
> %3)) {} objects) ))
>
> Which also has the benefit of being safe, unlike any reset!-based update.
>
> --
> Stephen Compall
> If anyone in the MSA is online, you should watch this flythrough.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: representing clojure source code as data?

[John D. Hume]

On Jun 23, 2013 1:43 AM, "kovas boguta"  wrote:
> what about the other cases? Random java objects and whatnot.
>
> Those should be output in an EDN way, though its unclear what they would
mean when read. Would there be any attempt to convey their contents or
characteristics?

Aren't you only worried about representing the structure of the source
code? If so, doesn't Java interop just break down into lists of symbols,
the dot special form, and maybe a special thing for .methodOrField syntax?

Or do you have something other than interop in mind when you talk about
random Java objects? It doesn't sound to me like you're interested in
representing runtime values.

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

[John D. Hume]

If you use for, which is lazy, wrap it in a doall to force it to do its
work before with-open closes your reader.
On Jun 21, 2013 6:52 AM, "Jim"  wrote:

>  Only use 'doseq' when you don't care about the reuturn value. In other
> words only for side-effect-y code. Use 'for'  instead...
>
> Jim
>
>
>
> On 21/06/13 11:17, Jay C wrote:
>
> Hi, I'm fairly new to Clojure and need help with a problem. The following
> function always returns nil, whereas it should return the value of "line"
> (which is not nil - I've tested).
>
> (defn find-line-in-output [regex]
>> (with-open [rdr (reader belarc-output-filepath)]
>> (doseq [line (line-seq rdr)]
>> (if (not (nil? (re-find (re-pattern regex) line)))
>> line
>> )
>> )
>> )
>> )
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Why does peek on a seq of vector fail?

[John D. Hume]

On Jun 20, 2013 3:11 PM, "Jason Gilman"  wrote:
>
> (defn bar [my-list n]
>   (if (= n 0)
>   (peek my-list)
>   (bar (rest my-list) (dec n
> (bar [1 2 3] 1)
>

It seems likely you want either first and rest* (to work from the front of
any seqable) or peek and pop (to work from the back of a vector or the
front of a list or queue). Combining peek and rest on a vector as the bar
function does makes no sense, since they work at opposite ends.

*or next in place of rest.

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

[John D. Hume]

Offhand it looks like the only RestFn you call from filter-link is
clojure.core/format. Have you tried replacing that with something like this?

(String/format (.get link 1) (doto (make-array String 1) (aset 0 (.get link
2)))

I'm not suggesting that's idiomatic, but if it addresses the issue then you
can focus on the difference and look for a happy medium.


On Tue, Jun 18, 2013 at 4:10 PM, Tim Jones  wrote:

>
> (defn- filter-link
>   "Format lang and cc into the link returned from the product."
>   [^List link]
>   [(.get link 0) (.get link 1) (.get link 2) (.get link 3)
>(-> (.get link 4)
>(URLDecoder/decode "UTF-8")
>(format (.get link 1) (.get link 2)))])
>
> (defn link-info
>   "Retrieve all link info from a product as a lazy-seq of vectors of
> String.  The function
>handles parameter substitution within the URL"
>   [^Product p]
>   (map filter-link
>(.getAllLinkInfo p @lib {"h_lang" "%1$s" "h_cc" "%2$s"})))
>

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

Re: with-open and for

[John D. Hume]

On Jun 11, 2013 8:25 AM, "Meikel Brandmeyer (kotarak)"  wrote:
> Or another one:
>
> (defn filter-lines
>   [rdr]
>   (->> (line-seq rdr)
> (mapcat #(str/split % #"\s+"))
> (filter #(<= 4 (count %) 9))
> (into #{})))
>
> (defn filter-file
>   [filename]
>   (with-open [rdr (io/reader filename)]
> (filter-lines rdr)))

I like this split a lot, though I'd prefer to pass the line-seq to
filter-lines. Then you have an extremely simple impure fn and all your
logic in an easy-to-test, easy-to-reuse pure function.

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

Re: clojure diffs

[John D. Hume]

One neat hidden Github feature is that if you add the query string
parameter w=1 to any diff view, it will ignore whitespace-only changes
(like passing -w to git diff).
That doesn't help with those final lines with added or removed close
parens, but it still improves readability of many diffs.

https://github.com/blog/967-github-secrets
On Jun 6, 2013 9:31 PM, "Moocar"  wrote:

> Hi all,
>
> Diffs for clojure code (and lisps in general) can be hard to read. Every
> time we wrap a form, any lines below are indented. The resulting diff just
> shows that you've deleted lines and added lines, even though you've only
> changed a few characters.
>
> What diff tools do people use to address this? I've found ediff is useful
> in emacs, but what I really want is a way to see good diffs in github pull
> requests.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Compiler bug?

[John D. Hume]

Guessing a bit here.
1. This file
https://github.com/Engelberg/instaparse/blob/master/src/instaparse/print.cljdefines
fns called parser->str and Parser->str.
2. Windows has a case-insensitive filesystem.
3. [guess] Something about class files getting overwritten?
4. [guess] Instaparse can't work on Windows without one of those fns
getting renamed.


On Thu, Jun 6, 2013 at 9:53 AM, Frantisek Sodomka wrote:

> Hi all,
> I am trying new parsing library Instaparse. I setup a Leiningen project,
> included [instaparse "1.1.0"] as my dependency and tried to run it.
> Unfortunately, I am getting this error:
>
> Exception in thread "main" java.lang.NoClassDefFoundError:
> instaparse/print$parser__GT_str (wrong name:
> instaparse/print$Parser__GT_str)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(Unknown Source)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at java.security.SecureClassLoader.defineClass(Unknown Source)
> at java.net.URLClassLoader.defineClass(Unknown Source)
> at java.net.URLClassLoader.access$000(Unknown Source)
> at java.net.URLClassLoader$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at instaparse.print__init.load(Unknown Source)
> at instaparse.print__init.(Unknown Source)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Unknown Source)
> at clojure.lang.RT.loadClassForName(RT.java:2098)
> at clojure.lang.RT.load(RT.java:430)
>
> Inside compiled class:
> target\classes\instaparse\print$parser__GT_str.class
> is a string "instaparse/print$Parser__GT_str", which I believe is a name
> of a class. Class name and file name do not match - lowercase p versus
> uppercase P in $parser.
>
> Windows 7 64-Bit
> Leiningen 2.2.0 on Java 1.6.0_35 Java HotSpot(TM) 64-Bit Server VM
> Instaparse 1.1 has a dependency on [org.clojure/clojure "1.5.1"].
>
> Is this a bug inside the Clojure compiler? Or is my setup wrong?
>
> Downloading just Instaparse (branch 1.1) from github and compiling it
> yields the same class/file name difference.
>
> Thank you for your help,
> Frantisek
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>



-- 
http://elhumidor.blogspot.com/

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

Re: A blocking lazy sequence populated by multiple worker threads

[John D. Hume]

On May 30, 2013 4:12 AM, "Colin Yates"  wrote:
> ; the following would need to reify itself to be a Runnable, not got that
far yet :)
> (defn execute [job result-queue] (let [result (job)] (.put result-queue
result)))
>

A no-args fn is both a perfectly good Callable and a perfectly good
Runnable, making interop with java.util.concurrent pretty painless.

So it takes as little as
#(execute my-job my-queue)

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

[John D. Hume]

Oops. That is what I meant, but I don't know why I thought pre- and
post-conditions get stored in metadata. It would be handy for :pre. Thanks,
Ambrose.

To the OP, I would still recommend using metadata to store the
applicability test and also making it a precondition of the fn in a partial
function implementation, but that will require more effort than I thought.
On May 27, 2013 8:12 AM, "Ambrose Bonnaire-Sergeant" <
abonnaireserge...@gmail.com> wrote:

> Hi John,
>
> By :pre, do you mean function preconditions? eg. (fn [] {:pre [..]}) ?
>
> How is :pre related to metadata and dispatch? AFAICT it's purely for
> macroexpansion and
> there is no metadata available on the precondition post-macroexpansion.
>
> Thanks,
> Ambrose
>
> On Mon, May 27, 2013 at 9:00 PM, John D. Hume wrote:
>
>> On May 26, 2013 8:53 PM, "Mark Engelberg" 
>> wrote:
>> >
>> > Another possible design choice is to store a domain-testing predicate
>> in the function's metadata.
>>
>> Using metadata would be a much more idiomatic choice than using arity.
>> Multiple arities are idiomatically used (like method overloading) to
>> default arguments.
>>
>> An interesting detail James thought of but didn't call out is putting the
>> domain check in the :pre metadata of the fn. This is an infrequently used
>> Clojure feature, but it's a perfect fit for partial functions. Calling a fn
>> with an argument that fails the :pre check will throw an exception, so the
>> body can be written to assume it's got good input. Anyone can grab the :pre
>> metadata to test for applicability, and anyone who knows clojure will have
>> at least passing familiarity with the concept.
>>
>> Your macro can still pull apart the pattern matching forms to build the
>> :pre fn, and it's still easy to do orElse-style composition.
>>
>> Unrelated: If you haven't already, you may want to read and follow up on
>> the May 16 thread "core.match" before going very far with it.
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Some feedback on coding style

[John D. Hume]

On May 26, 2013 8:53 PM, "Mark Engelberg"  wrote:
>
> Another possible design choice is to store a domain-testing predicate in
the function's metadata.

Using metadata would be a much more idiomatic choice than using arity.
Multiple arities are idiomatically used (like method overloading) to
default arguments.

An interesting detail James thought of but didn't call out is putting the
domain check in the :pre metadata of the fn. This is an infrequently used
Clojure feature, but it's a perfect fit for partial functions. Calling a fn
with an argument that fails the :pre check will throw an exception, so the
body can be written to assume it's got good input. Anyone can grab the :pre
metadata to test for applicability, and anyone who knows clojure will have
at least passing familiarity with the concept.

Your macro can still pull apart the pattern matching forms to build the
:pre fn, and it's still easy to do orElse-style composition.

Unrelated: If you haven't already, you may want to read and follow up on
the May 16 thread "core.match" before going very far with it.

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

Re: How to: reduce boolean operations?

[John D. Hume]

On Fri, May 24, 2013 at 1:25 PM, atkaaz  wrote:

> It kinda makes sense except I wouldn't have expected that on the map it
> would return a vector (but then how else could it return both key and value
> right? )  so everyone expects the "input" to the pred would be a vector
> when passed in a map.
>

It's actually a clojure.lang.MapEntry, which is a java.util.Map$Entry
that's also a clojure.lang.IPersistentCollection that acts like a vector.
So if you conj onto it, you get a vector with three things, and likewise
other fns that work with colls will give you vector results, but you can
also call clojure.core/key and clojure.core/val on it (or hand it to Java
code that expects a map entry).

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

Re: How to: reduce boolean operations?

[John D. Hume]

On Thu, May 23, 2013 at 11:30 AM, atkaaz  wrote:

> So all I was saying above is that it should throw when [] is empty just as
> it does when [] is not empty, but it doesn't throw when empty because it's
> never called (by "it" i mean "false" not "false?")
>

This sort of behavior is handy for users new to the language but generally
goes against the grain in a dynamic language (e.g., Clojure, Ruby, Python,
JavaScript). If you want libraries to consistently error when you try to
pass the wrong sort of thing to a method or function, there are a whole
bunch of languages that make it inconvenient not to do that (e.g., Haskell,
Scala, Java, Go).

In a dynamic language this requires extra code in every method or function
that makes assumptions about its arguments' types. People who choose
dynamic languages often do so in part because of how little code it takes
to do powerful things. So I think the communities largely see validation of
arguments as clutter. That doesn't mean it's never done, but it's kept to a
minimum. For example, clojure supports adding :pre and :post conditions to
a fn's metadata, but that feature seems to be used only three times in
clojure itself: twice in clojure.reflect.java and once in clojure.uuid. On
the other hand, many macros in clojure.core validate their usage with the
private assert-args.

This philosophical bent also comes up in question about how to design a
library so that users can't mess up certain things. In the Java community,
that's a common concern. In Clojure-land, the prevailing wisdom is to
design and document so that it's easy to do the right thing but not worry
much about people who do the wrong thing.

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

Re: How to: reduce boolean operations?

[John D. Hume]

On May 22, 2013 5:35 AM, "atkaaz"  wrote:
>
> I find the wording of this confusing "otherwise it returns the value of
the last expr. (and) returns true."
> I mean, I know it returns the last true value, but that's because I've
tested it not because the doc is trying(failing) to tell me so with that
phrase.

The next-to-last sentence describes the behavior you're talking about. The
last sentence is addressing the no-args case. Starting a sentence with a
parenthesized form makes it hard to read.

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

[John D. Hume]

In the xalan.ext :gen-class the static methods are named "foo" and "bar"
but your xslt template is using the (prefixed) names of the clojure impl
fns. Did you try just "foo" and "bar" instead?

To be sure the class and methods are available in your test, rather than
calling the clojure fns, call the static methods, like (xalan.ext/foo...).

Hope this helps.
On May 15, 2013 7:08 AM, "Gregg Reynolds"  wrote:

> Hi,
>
> I'm having trouble getting clojure functions to work as xslt extensions.
>  The code is very simple; you can find it at
> https://github.com/greynolds/xslj.  The problem is obviously related to
> how clojure functions get called from java.  I have some idea of how that
> works but can't figure out how to make it work here.  I could always write
> a java wrapper to call the clojure stuff but it would clearly be preferable
> to not have to do that.
>
> Rather than describe the problem in detail here, the above-mentioned code
> is simple and commented so you can see immediately what's happening.  It
> contains code for both saxon and xalan.  (If you're not familiar with xslt,
> the idea is just that you can reference an extension function using a URI
> in a stylesheet.)  If anybody who knows the secrets of calling clojure code
> would care to take a few minutes to look I'd be grateful.
>
> The errors I get involve finding the class.  But calling the functions
> from clojure works just fine.  It's not a classpath problem because the
> same thing happens using command line processing with explicit classpath
> (see the test.sh files in the repo).
>
> Saxon:
> XPath syntax error at char 12 on line 15 in {xj:saxfoo(7)}:
> Cannot find a matching 1-argument function named
> {java:saxon.ext}saxfoo()
>
> Xalan:
> java.lang.NoSuchMethodException: For extension function, could not find
> method xalan.ext.xalfoo([ExpressionContext,] #NUMBER).
>
> Thanks,
>
> Gregg Reynolds
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: ANN: kits 1.5.1 - some of Runa's core utilities

[John D. Hume]

On Thu, May 9, 2013 at 7:15 PM, Dave Sann  wrote:

> There are several "projects" that provide a bunch of base level/common
> functions and extensions (similar to those here) beyond core Clojure. And I
> am sure that many people have their own collection of useful utilities like
> this. I know that I do.
>

I wouldn't want to try to wrangle all these together, but I would like to
have a list of them for reference. Here are two I know of offhand.
https://github.com/jaycfields/jry
https://github.com/flatland/useful

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

[John D. Hume]

The add method that you partially apply in new-scheduler should be private,
because a user can't supply the first argument it expects. You might do
something like this.

(defn- add* [queue item] (...))

(defn add [scheduler item]
  ((scheduler :add) item))

(defn new-scheduler []
  (let [queue (...)]
{:add (partial add* queue)}))

But again, I am not recommending this. I just wanted to point out that a
closure gives you encapsulation w/o extra language features.
On May 10, 2013 6:56 AM, "Colin Yates"  wrote:

> Thanks John.  To be explicit - the add method shouldn't be private - it is
> the only way users should add to the queue.  I think this is what you meant
> but you wrote "..and `add` and `clear` are your private fns..".
>
> Again, this paradigm shift of 'trust your users' is unfortunately alien to
> me based on my experience with most of the Java devs I have come across :).
>  I say that not be snarky, but to highlight how much it really does change
> things.  The open-closed principle now becomes much simpler to realise for
> example.
>
> Thanks again.
>
>
> On 10 May 2013 12:44, John D. Hume  wrote:
>
>> I agree with the advice you've gotten, but since no one has mentioned it,
>> I wanted to point out that you can have encapsulation w/o protocols with
>> something like this.
>>
>> Assume a queue is your only state and `add` and `clear` are your private
>> fns that take a queue as first argument.
>>
>> (defn new-scheduler []
>>   (let [queue (...)]
>> {:add (partial add queue)
>>  :clear (partial clear queue)}))
>>
>> There are several disadvantages to this, however. The biggest in my book
>> is that it achieves your goal, and you're limited in the same way your
>> users are. You can't add behavior to an already created scheduler (unless
>> it's built on adding and clearing). Furthermore, if you dynamically
>> recompile `add` or `clear`, it won't change the behavior of an already
>> created scheduler, since partial has the fns, not the symbols or vars that
>> point at them. (These same disadvantages apply to a reified protocol.)
>>
>> As others have recommended, just return a map. Keep in mind that the
>> documentation is just a `(doc new-scheduler)` away and that auto-completion
>> will tend to send people back into your ns's fns rather than into the
>> internals of a data structure.
>>  On May 10, 2013 5:51 AM, "Colin Yates"  wrote:
>>
>>> Thanks Korny.
>>>
>>> Ok, the over-ridding theme seems to be: expose state, even if it is
>>> dangerous, but expect consumers to 'do the right thing' and read the
>>> documentation.
>>>
>>> I can see that.  I guess I have worked (and to be honest, been guilty
>>> myself) with too many people who don't read the documentation, use
>>> auto-complete to find something that looks like it might work and then move
>>> on to the next chunk of wiring things up in XML :).
>>>
>>> I think I also got hung up on the 'data as a contract'.  The point here
>>> is that I am not returning data, rather I am defining a service.  A subtle
>>> difference but an important one I think.
>>>
>>> Keep the comments coming!
>>>
>>>
>>> On 10 May 2013 11:37, Korny Sietsma  wrote:
>>>
>>>> I would generally handle this sort of encapsulation at the namespace
>>>> level.
>>>>
>>>> Put (create-woobly) and (add-job) and all the other woobly-related
>>>> functions into a woobly namespace.  Also add any functions that access info
>>>> from a woobly bag-o-state, or mutate a woobly to make a woobly-with-extras.
>>>>
>>>> Functions that might dangerously expose internals of a woobly can be
>>>> made private, or possibly you can just document them in a way to warn folks
>>>> away from "bad" behaviour.
>>>>
>>>> While external users of (woobly/create-woobly) can in theory dig into
>>>> the internals of the woobly "object", but it should be relatively obvious
>>>> that this isn't a good idea.
>>>>
>>>> I'd defer making protocols until you actually need polymorphism.
>>>>
>>>> - Korny
>>>>
>>>>
>>>>
>>>> On 10 May 2013 03:03, Colin Yates  wrote:
>>>>
>>>>>  Thanks for all the helpful responses.
>>>>>
>>>>> One reason I want to hide the internals is that I don

Re: Struggling with encapsulation

[John D. Hume]

I agree with the advice you've gotten, but since no one has mentioned it, I
wanted to point out that you can have encapsulation w/o protocols with
something like this.

Assume a queue is your only state and `add` and `clear` are your private
fns that take a queue as first argument.

(defn new-scheduler []
  (let [queue (...)]
{:add (partial add queue)
 :clear (partial clear queue)}))

There are several disadvantages to this, however. The biggest in my book is
that it achieves your goal, and you're limited in the same way your users
are. You can't add behavior to an already created scheduler (unless it's
built on adding and clearing). Furthermore, if you dynamically recompile
`add` or `clear`, it won't change the behavior of an already created
scheduler, since partial has the fns, not the symbols or vars that point at
them. (These same disadvantages apply to a reified protocol.)

As others have recommended, just return a map. Keep in mind that the
documentation is just a `(doc new-scheduler)` away and that auto-completion
will tend to send people back into your ns's fns rather than into the
internals of a data structure.
On May 10, 2013 5:51 AM, "Colin Yates"  wrote:

> Thanks Korny.
>
> Ok, the over-ridding theme seems to be: expose state, even if it is
> dangerous, but expect consumers to 'do the right thing' and read the
> documentation.
>
> I can see that.  I guess I have worked (and to be honest, been guilty
> myself) with too many people who don't read the documentation, use
> auto-complete to find something that looks like it might work and then move
> on to the next chunk of wiring things up in XML :).
>
> I think I also got hung up on the 'data as a contract'.  The point here is
> that I am not returning data, rather I am defining a service.  A subtle
> difference but an important one I think.
>
> Keep the comments coming!
>
>
> On 10 May 2013 11:37, Korny Sietsma  wrote:
>
>> I would generally handle this sort of encapsulation at the namespace
>> level.
>>
>> Put (create-woobly) and (add-job) and all the other woobly-related
>> functions into a woobly namespace.  Also add any functions that access info
>> from a woobly bag-o-state, or mutate a woobly to make a woobly-with-extras.
>>
>> Functions that might dangerously expose internals of a woobly can be made
>> private, or possibly you can just document them in a way to warn folks away
>> from "bad" behaviour.
>>
>> While external users of (woobly/create-woobly) can in theory dig into the
>> internals of the woobly "object", but it should be relatively obvious that
>> this isn't a good idea.
>>
>> I'd defer making protocols until you actually need polymorphism.
>>
>> - Korny
>>
>>
>>
>> On 10 May 2013 03:03, Colin Yates  wrote:
>>
>>>  Thanks for all the helpful responses.
>>>
>>> One reason I want to hide the internals is that I don't want people to
>>> add jobs directly to the queue.  (add-job) will put a map containing the
>>> provided function onto the queue.  Not really relevant, but this is so that
>>> I can track queue timings that I can later on use to determine how much
>>> capacity the system can handle.
>>>
>>> I am nervous as well about "expose internals but trust people to do the
>>> right thing" because in this case, if I was a consumer and saw that queue,
>>> particularly given the emphasis about data being the contract etc. then why
>>> would I think *not* to use it.
>>>
>>> I do appreciate the point about not needlessly obfuscating information -
>>> this is a slightly different case.
>>>
>>> Sounds like in this case, either reify is the way to go or maybe return
>>> a bad of data but have this stuff in an 'internal' map (i.e. {:internal
>>> {:queue...}})
>>>
>>> Thanks a bunch - really helpful.
>>>
>>>
>>> On 9 May 2013 17:30, James Reeves  wrote:
>>>
 On 9 May 2013 17:07, Colin Yates  wrote:

> The part I am struggling with is how to create a Woobly without
> exposing its internals.
>

 To what end? What's the benefit?

 If you take a look at some internal data structures Clojure uses, like
 zippers or protocols, you'll notice that they're just maps. In general
 there's no need to try and obfuscate data to stop people from diving into
 the internals; just don't provide a public API for the internal parts and
 people will get the hint.

 - James

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

Re: Import java classes in clojure

[John D. Hume]

Did you try the downloads link here?
http://openrules.com/jsr331/
On May 6, 2013 12:10 AM, "Caocoa"  wrote:

> Well, so I just tried the following commands:
>
>> user=> (ns mx.clojure.contemporary.pitch-centricity-and-symmetry
>>   #_=>   (:import [jm.music.data
>>   #_=> Score
>>   #_=> Part
>>   #_=> Phrase
>>   #_=> Note])
>>   #_=>   (:import [jm.music.tools
>>   #_=> Mod])
>>   #_=>   (:import [jm JMC])
>>   #_=>   (:import [jm.util Write]))
>> jm.util.Write
>> mx.clojure.contemporary.pitch-centricity-and-symmetry=>
>>
> It seems to work, right? :) Have I imported jMusic in a clean way?
> But I've still a problem with javax :-(
>
> On Monday, May 6, 2013 12:04:39 AM UTC+2, Caocoa wrote:
>>
>> Hi all! I'm  a new Clojure user. I'm trying to import some java classes
>> in order to use them with overtone, but I fail :/ Would you help me?
>> Thanks a lot in advance for your answer.
>>
>> Here is the bug:
>>
>>> user=> (:import [javax.constraints
>>>   #_=> Problem
>>>   #_=> ProblemFactory
>>>   #_=> Var
>>>   #_=> Solver
>>>   #_=> Objective
>>>   #_=> VarSet])
>>> CompilerException java.lang.RuntimeException: 
>>> java.lang.**ClassNotFoundException:
>>> javax.constraints, compiling:(NO_SOURCE_PATH:1)
>>>
>>> user=> (:import [jm.music.data
>>>   #_=> Score
>>>   #_=> Part
>>>   #_=> Phrase
>>>   #_=> Note])
>>> CompilerException java.lang.RuntimeException: 
>>> java.lang.**ClassNotFoundException:
>>> jm.music.data, compiling:(NO_SOURCE_PATH:1)
>>>
>>
>> As a newbie, I have several questions:
>>
>>- I've found jMusic here: http://sourceforge.net/**
>>
>> projects/jmusic/?source=dlp.
>>I hope it's the latest version. I've copied it in
>>>
>>>/usr/lib/jvm/java-7-openjdk/**jre/lib/ext
>>>
>>but I still can't invoke any jm.music.data classes. How could I
>>include it int the classpath. I thought that folder was already included.
>>- How can I download and properly install javax.constraints? I don't
>>even know where I can find that package.
>>
>> Some data about my system:
>>
>>- uname -a gives me back:
>>
>>>Linux C40C04 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST
>>>2013 x86_64 GNU/Linux
>>>
>>- When I look for jMusic or javax in package database with my package
>>manager (I use yaourt), I don't find anything.
>>- Here is what java packages I've already installed:
>>
>>>$ yaourt -Qs java
>>>extra/apache-ant 1.9.0-1
>>>A java-based build tool
>>>extra/ca-certificates-java 20121112+nmu2-1
>>>Common CA certificates (JKS keystore)
>>>extra/eclipse 4.2.2-1
>>>An IDE for Java and other languages
>>>extra/gjs 1.36.1-1
>>>Javascript Bindings for GNOME
>>>local/hsqldb-java 1:1.8.0.10-2
>>>HSQLDB Java libraries
>>>extra/java-activation-gnu 1.1.1-1
>>>JavaBeans Activation Framework (JAF), framework for declaring
>>>what beans operate on what MIME type data
>>>local/java-commons-email 1.2-1
>>>Library for sending e-mail from Java.
>>>extra/java-gnumail 1.1.2-1
>>>GNU implementation of the JavaMail API specification, version 1.3
>>>extra/jdk7-openjdk 7.u21_2.3.9-1
>>>Free Java environment based on OpenJDK 7.0 with IcedTea7
>>>replacing binary plugs - SDK
>>>extra/jre7-openjdk 7.u21_2.3.9-1
>>>Free Java environment based on OpenJDK 7.0 with IcedTea7
>>>replacing binary plugs - Full Java runtime environment - needed for
>>>executing Java GUI and Webstart programs
>>>extra/jre7-openjdk-headless 7.u21_2.3.9-1
>>>Free Java environment based on OpenJDK 7.0 with IcedTea7
>>>replacing binary plugs - Minimal Java runtime - needed for executing non
>>>GUI Java programs
>>>community/netbeans 7.3-1
>>>IDE for Java, HTML5, PHP, Groovy, C and C++$ yaourt -Qs java
>>>extra/apache-ant 1.9.0-1
>>>A java-based build tool
>>>extra/ca-certificates-java 20121112+nmu2-1
>>>Common CA certificates (JKS keystore)
>>>extra/eclipse 4.2.2-1
>>>An IDE for Java and other languages
>>>extra/gjs 1.36.1-1
>>>Javascript Bindings for GNOME
>>>local/hsqldb-java 1:1.8.0.10-2
>>>HSQLDB Java libraries
>>>extra/java-activation-gnu 1.1.1-1
>>>JavaBeans Activation Framework (JAF), framework for declaring
>>>what beans operate on what MIME type data
>>>local/java-commons-email 1.2-1
>>>Library for sending e-mail from Java.
>>>extra/java-gnumail 1.1.2-1
>>>GNU implementation of the JavaMail API specification, version 1.3
>>>extra/jdk7-openjdk 7.u21_2.3.9-1
>>>Free Java environment based on OpenJDK 7.0 with IcedTea7
>>>replacing binary plugs - SDK
>>>extra/jre7-openjdk 7.u21_2.3.9-1
>>>Free Java environment based on OpenJDK 7.0 with IcedTea7
>>>r

Re: Clojure Login form error: java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.Atom

[John D. Hume]

I've never used noir and have barely used 4clojure, but both of them
apparently do hidden global things that make it hard to know the context in
which your code is running. Your app needs to be wrapped in noir's
`wrap-noir-session` middleware in much the same way this blog post shows
Ring's `wrap-session` being used:

http://rjevans.net/post/2628238502/session-support-in-compojure-ring
https://gist.github.com/mirrormatch/768768

I'll leave it at that.

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

Re: higher order functions and metadata

[John D. Hume]

On Thu, May 2, 2013 at 8:33 AM, Phillip Lord
wrote:

> Well, I guess I will code up a simple macro; in my current case, I can
> infer the arglists anyway.
>

Once you do, be sure to weigh the complexity against:

(defn my-partial-function [y] (my-function 10 y))

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

Re: Clojure Login form error: java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.Atom

[John D. Hume]

On May 2, 2013 2:04 AM, "David Toomey"  wrote:
> Is there anything
> I could show that could reveal the problem?

Yes, you should have shown the stack trace of the exception (or at least
the part from the top of the text down to your code).

But even without that, you have an error coming out of noir.session that
says something is unbound where an atom was expected. That should send you
to the source for noir.session. There you'll see everything depends on the
dynamic global *noir-session*, which is only ever bound by
wrap-noir-session, which you're not calling. That's a compojure middleware
fn. Take a look at some compojure tutorial to see where and how they're
used.

There are likely other similar middleware fn calls noir will expect you to
have made. Hopefully having struggled with this one, figuring the others
out will be easy.

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

[John D. Hume]

As a user of Codeq with Navgeet's proposed additions, I would definitely
want to see macro usages along with runtime var references. So you're right
that you'd want the result of analyzing the subject code with all macros
expanded, but it would also be valuable to see the macros that got expanded
along the way.
On May 1, 2013 5:53 AM, "Navgeet Agrawal"  wrote:

> Ah seems like I did not think that through.
>
> For macros it makes sense to do analysis on their expansions. For example,
> for analyzing a defn form, codeq should examine the expansion's ast. Since
> I wanted to build all analysis functionality as plugins, therefore source
> analysis plugins should have access to a defn's full expanded ast, which
> would adequately allow them to answer questions like "Which functions are
> called by this function?".
>
> This should also be able to deal with false positives, since analysis is
> run on expanded code.
>
> Thanks for the feedback,
> Navgeet
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: testing for nil may not be enough

[John D. Hume]

On Apr 29, 2013 1:07 PM, "Jonathan Fischer Friberg" 
wrote:
>
> If you don't want to set the initial value to nil, set it to ::unbound or
similar. Should be very
> hard to accidentally bind the same value.

Please take Jonathan's advice if nil is a valid value for a user to bind;
use nil as the initial value if it's not.

It is non-idiomatic to leave the var unbound for exactly the reason you're
running into: unbound vars are annoying to deal with.

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

[John D. Hume]

On Fri, Apr 26, 2013 at 11:58 AM, Steven Degutis wrote:

> I found that I want to have multiple multi-methods, but grouped
> together, much like an interface.
>

There's no syntax for grouping multimethods, but wouldn't it be good enough
to put the defmulti forms near one another? Presumably they'll share a
dispatch fn (or some underlying part of their dispatch fns) and maybe a
hierarchy (as in clojure.core/make-hierarchy), which makes it easier to see
that this set of multimethods goes together.

If your concern is making it fool-proof for consumers of your API to
defmethod for all the right multimethods, you can easily do :default
defmethods that provide a clear error message.

Somewhat less easily you could create a macro that expanded into the right
set of defmethod forms. That seems excessive to me, but I don't know your
context.

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

[John D. Hume]

On Sun, Apr 28, 2013 at 5:46 AM, AtKaaZ  wrote:

> => (defn abc [] 3)
> #'ants/abc
>
> => (loop [a 1]
>  (when (= 1 a) (recur (abc
> NO_SOURCE_FILE:2 recur arg for primitive local: a is not matching
> primitive, had: Object, needed: long
> Auto-boxing loop arg: a
> nil
>

The compiler isn't telling you it will need to box your recur arg into a
long, but that it will be boxing your initial loop arg into an Object.
Think of the message as "Maybe you intended `a` to be a primitive local,
but since you passed `recur` a who-knows-what, it won't be."

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

[John D. Hume]

Both `for` and `doseq` support the same vector form preceding a body. `for`
returns a lazy sequence and is often appropriate for a purely functional
body. `doseq` is not lazy and returns nil, so it is only appropriate when
you want to run the body for side effects.

Take a look at http://clojure.github.io/clojure/clojure.core-api.html and
play around in the repl to get a clearer idea of how that works. Maybe
start with an expression like this:
(let [nested [[1 2 3] [4 5 6]]]
  (for [row nested
number row]
(str number " from row " row)))
If you change `for` to `doseq`, you may also want to change `str` to
`println`.

Alan's example uses `map-indexed` to get numeric indices. Note that `cols`
holds a row from `rows` and is then passed to the second `map-indexed`
call, so his example is like a nested for-loop in a C-like language, except
that it is lazy and returns a sequence of results of calling `display` with
each item from your nested vector along with its coordinates. For this
example to make sense, `display` should return a value that will be used to
put something on screen. If `display` just does the screen-putting, and its
return value is insignificant, then `doseq` would make sense.

Hope this helps.
-hume.
On Apr 19, 2013 4:27 AM,  wrote:

> How does that work: you appear to be iterating over two, unconnected,
> vectors.
>
> And yes that's an example of the second option but doesn't explain if or
> why that's the best approach- which was the question ;)
>
> On Thursday, 18 April 2013 19:48:40 UTC+1, Alan Malloy wrote:
>>
>> (for [[y cols] (map-indexed vector rows)
>>   [x cell] (map-indexed vector cols)]
>>   (display cell y x))
>>
>> ?
>>
>> On Thursday, April 18, 2013 3:14:19 AM UTC-7, edw...@kenworthy.infowrote:
>>>
>>> So, I want a 2 dimensional array.
>>>
>>> I think the best way to implement this is a vector of vectors.
>>>
>>> Now I want to display that array drawing each element relative to its
>>> position in the array.
>>>
>>> Is the best way to use doseq and manually maintain the indices? Or is it
>>> to use nested for-loops manually iterating of the vector-of-vectors?
>>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: destructuring vectors with :or

[John D. Hume]

You can use a map destructuring form on a vector like so:

(let [{x 0 y 1 :or {x 0 y 0}} [7]] [x y])

returns [7 0]

On Fri, Apr 12, 2013 at 5:00 PM, henry clifford  wrote:
> I'm trying to use the :or destructuring syntax as seen here applied to a map
>
> (def point {:y 7})
> (let [{:keys [x y] :or {x 0 y 0}} point]
>   (println "x:" x "y:" y))
> x: 0 y: 7
>
> but I can't get this to work with vectors:
>
> (def point [7])
> (let [[x y :or [0 0]] point]
>   (println "x:" x "y:" y))
>
> what' I'm expecting is x:7 y:0
>
> but I'm getting Exception Unsupported binding form: :or
>
> Any thoughts on this?
> Thanks!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
http://elhumidor.blogspot.com/

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

Re: Some docs on comparators, including mistakes to avoid, & Clojure "extended doc strings"

[John D. Hume]

This seems like a good fit for http://clojure-doc.org/

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

Re: Analog to Scheme's partition in Clojure?

[John D. Hume]

On Thu, Apr 4, 2013 at 8:06 AM, David Powell  wrote:
> You could use the long-form of map destructuring:
>
> (let [{odd true even false} (group-by odd? (range 1 10))]
>   (println odd)
>   (println even))

I do this frequently. Do be careful that if your "predicate" doesn't
return actual booleans, you may want to coerce with (boolean ...).

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

[John D. Hume]

On Apr 4, 2013 6:54 AM, "Jim - FooBar();"  wrote:
>
> Thanks John,
>
> I came up with this, which uses destructuring quite heavily and might
slow things down...
>
> (reduce (fn [s [t1 t2 w3 v]] (assoc-in s [t1 t2 w3] (/ (count v) all))) {}
> (for [[k1 v1] ems [k2 v2] v1 [k3 v3] v2] [k1 k2 k3 v3]))
>
> is this what you meant?

Yes, something like that.

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

Re: nested reduce/reduce-kv idiom

[John D. Hume]

Destructure the map entry.
(for [[k vs] some-map, v vs] v) or whatever.

On Wed, Apr 3, 2013 at 1:44 PM, Jim - FooBar();  wrote:
> Hi all,
>
> I 've recently come across this idiom (instead of nested reduces - from
> Christophe's blog post of course!)
>
> (reduce f init (for [x xs, y x, z y] z)) ;;it took me a while to realise how
> cool this is :)
>
>
> I'm trying to do the same for reduce-kv (for nested maps) but doesn't quite
> work...has anyone done this already? It comes down to 'seq' returning a
> [k,v] vector when called on a map so the second nesting level will break
> because it will find a keyword or something similar. any ideas?
>
>
> Jim
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
http://elhumidor.blogspot.com/

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

Re: Problem with map (only when running on browser)

[John D. Hume]

When you want a side effect and don't care about return values, it's
idiomatic to use doseq.

(doseq [c calls-log] (log-call c))
On Mar 30, 2013 4:23 AM, "Neale Swinnerton"  wrote:

> ;(.log js/console (pr-str calls-log 
>> (map log-call calls-log)))
>>
>> map is lazily evaluated, so if you never read it's result nothing happens.
>
> You can force evaluation with doall (and variants)
>
> so...
>
>   (doall (map log-call calls-log))
>
> will behave as you expect.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Best way of doing clojure / clojurescript development

[John D. Hume]

https://github.com/emezeske/lein-cljsbuild/blob/0.3.0/doc/CROSSOVERS.md
 On Mar 27, 2013 6:40 AM, "Steven Obua"  wrote:

> Hi,
>
> I have thought long which language to use for my current project. My main
> choices were Scala and Clojure, and I decided on Clojure mainly because I
> need to run substantial amounts of my code to run on both the JVM and in
> the browser.
>
> So now I am approaching the parts of my project that need to run in both
> environments. Are there any best practices for setting up my environment so
> that I can compile to both the JVM and to Javascript from the same
> codebase? I am aware that Clojure and Clojurescript are different
> languages, but for those pieces of my code that are shared I will make sure
> that the code looks the same, and I don't want to maintain different
> codebases for the same code.
>
> Thanks for any pointers,
>
> Steven
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Seeking advice on a safe way to mock/stub fns

[John D. Hume]

On Mar 27, 2013 1:56 AM, "Shantanu Kumar"  wrote:
>
> Sorry, in the last illustration, the (binding [*deps* deps] ...) cannot
be useful for Compojure route handlers because dynamic vars are bound at a
thread-local level; you will probably have to `alter-var-root` it to some
var and have the handlers use that static var instead. In the code I write
personally, I use a static var that I `alter-var-root` so I couldn't see
the error in dynamic var immediately.

If that thread-local binding is done in a middleware, that should work fine
for ring, which handles each request synchronously on a thread. (Whereas
alter-var-root would be visible across threads and defeat the OP's goal of
running tests concurrently.)

Do note, however, that the premise of this advice, that with-redefs doesn't
play nicely with concurrency, is too broadly stated.
• It doesn't play nicely with running tests that mock the same vars across
multiple threads.
• It doesn't play nicely with running tests in one thread while running
your app in another, if your app does things w/o user interaction. (This is
a pain for me.)
• BUT it does play nicely, more so than binding, with testing code that
does work across multiple threads, for example in futures, agents, or
hand-rolled threading.

So if you're testing concurrent code and can stand to run just one test at
a time, it allows you to avoid the verbosity of injecting all your
dependencies.

-hume.

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

[John D. Hume]

It looks like MimetypesFileTypeMap wants a path to a plain file. I can't
try this right now, but I think you want the constructor that takes an
InputStream. Something like
(MimetypesFileTypeMap. (io/input-stream (io/resource "thefile")))
though if you just passed "/thefile" to io/input-stream, that might do it.
On Mar 25, 2013 9:08 PM, "Clinton Dreisbach"  wrote:

> My apologies for a simple question, but:
>
> I have a very small library I wrote that needs to read a file in its
> resources/ directory. In the project, this works fine. However, when I
> package the library as a JAR, it can't find the file. I thought I was
> following the best practice of getting the file like so:
>
> (.getFile (io/resource "mime.types"))
>
> "mime.types" is definitely in the JAR; it's at the root.
>
> You can see the project at
> https://github.com/cndreisbach/ring.middleware.mime-extensions and the
> problem in particular at
>
> https://github.com/cndreisbach/ring.middleware.mime-extensions/blob/master/src/ring/middleware/mime_extensions.clj#L12
> .
>
> Am I missing some piece of knowledge about my project.clj? Any help
> you could give would be very appreciated.
>
> Thanks,
> Clinton Dreisbach
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Macro for bailout-style programming

[John D. Hume]

Your maybe-> does almost the same thing as Clojure 1.5's some-> but without
support for naked fns (like `(some-> 1 inc)`). It also evaluates each
"step" but the last twice (once for the `if`, once when inserted after
`op`).

If you don't want to switch to some->, I'd recommend you use when-let to
avoid the double evaluation.


On Mar 23, 2013 4:12 AM, "Gary Verhaegen"  wrote:

> I've recently had a need for something like that in my own code. The
> "real" solution to that problem in the functional programming world is
> known as the maybe monad. Since I just needed a quick and dirty
> solution and I have not wrapped my head around monads yet, here's what
> I did :
>
> (defmacro maybe->
>   "Sort of like a maybe monad, but without a monad. Takes an initial value
> and
>a list of functions with their arguments, and returns the result of
> applying
>each function to the result of the preceding one as long as there is no
> nil
>value. Returns nil if there ever is a nil in the chain of values."
>   [init & fns]
>   (reduce (fn [acc [op & args]]
> `(if-not (nil? ~acc)
>(~op ~acc ~@args)))
>   init fns))
>
> I did not have a need for "as->"-like functionality.
>

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

[John D. Hume]

On Tue, Mar 19, 2013 at 2:58 PM, Jim - FooBar();  wrote:
> awsome!...the full thing actually is {{:keys [w1 w2 w3]} :weights u
> :uni-probs b :bi-probs t :tri-probs}

You might also consider
{:keys [uni-probs bi-probs tri-probs]} {:keys [w1 w2 w3]} :weights}

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

[John D. Hume]

One argument against using exceptions for commonplace occurrences (like
invalid user input) is that the structure of the code may make it difficult
to see where those things can pop up, which can lead to misunderstanding
and introduction of bugs.

Even with Java's checked exceptions, where a certain method may be declared
to throw a custom ValidationException or whatever, you can't see from the
calling code which methods can throw one. You have to go look at the
signatures of all called methods looking for them. (Or more likely you
comment out the catch clause and see which calls your IDE underlines in
red.) Using standard control-flow constructs make branch-points explicit.
On Mar 19, 2013 8:26 PM, "Dave Sann"  wrote:

> That should have been "why is 1 preferable over 2"...
>
>
> On Wednesday, 20 March 2013 12:24:12 UTC+11, Dave Sann wrote:
>>
>> I am interested in this view that exceptions are an anti pattern. I have
>> heard it voiced before.
>>
>> I am not sure that I understand why.
>>
>> As I see it you have a choices:
>>
>> 1. Handle in the result  - and test this result repeatedly all the way
>> back to the caller
>> 2. Handle "out of band" - Throw an exception, allow the stack to unwind
>> and catch where it matters
>>
>> [And maybe - but I am not very knowledgeable on this and it won't work
>> today on the JVM anyway
>>  3. Use continuation passing style with TCO to shortcut the return to
>> follow an exception path]
>>
>> So, ignoring 3.
>>
>> Why is 2 preferable over 1? There are certainly pros and cons.
>>
>> Dave
>>
>>
>> On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
>>>
>>> I'd argue that using exceptions for control flow is something of an
>>> anti-pattern, even in Java.
>>>
>>> In this case a better mechanism might be to use polymorphism. For
>>> instance:
>>>
>>> (defprotocol Validatable
>>>   (validation-errors [x] "Return the validation errors for x."))
>>>
>>> (defn valid? [x]
>>>   (empty? (validation-errors x)))
>>>
>>> Then you can define a general function to validate and store that item
>>> in a database:
>>>
>>> (defn store-valid [db x]
>>>   (if (valid? x)
>>> (store db x)
>>> (validation-error-response x)))
>>>
>>> - James
>>>
>>>
>>> On 19 March 2013 16:43, Julien Dreux  wrote:
>>>
 Hi all,

 Coming from a Java background, I am having a hard time understanding
 how validation error propagation should work in clojure web APIs.

 To be clear, this is similar to how my Java web service would be setup:

 /** Method that validates the model, accesses the DB. If something went
 wrong, throw an exception */
 public void validateAndCreateUser(User u) throws ValidationException,
 EmailAlreadyInUseException, ... {
   ...
   if(...) {
 throw new ValidationException(fieldName)**;
   } else if (...) {
 throw new EmailAlreadyInUseException(u.**getEmail());
   }
 }

 /** Endpoint method, catches & formats the exceptions thrown by the db
 method. **/
 @POST("/api/user/create")
 public Response createUser (User u)  {
   ..
   try{
 validateAndCreateUser(u);
 return Response.ok();
   } catch (Exception e) {
 return generateExceptionResponse(e); //Method that maps exceptions
 to responses.
   }
 }

 For all of Java's clunkiness, this had the benefit of not having to
 write tons of if/else statements for validation handling. Exception were
 just thrown from anywhere, bubbling back up to inital call, and if not
 handled in the endpoint method, a specialized class mapped them into a
 proper response. The exceptions contained all the information needed to
 generate 'rich' error messages back to the client.

 Being a Clojure newbie, I wonder what a good pattern is for a similar
 situation. So far, I have a method that validates models based on a schema,
 that returns

 {:success true}

 or

 {:success false :errors ["error 1" "error 2" ...]}

 But I don't know how to avoid having to write if/else conditions of the
 sort in each function between my endpoint and db functions.

 (if (validation :success)
   (follow-normal-path)
   (handle-validation-errors validation))


 Any guidance appreciated.

 Cheers,

 Julien

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

Re: Beginners question - emacs & compiling tests

[John D. Hume]

It looks like you're missing (ns ...) forms at the top of each file.
That tutorial doesn't show them, but lein would have generated them
for you when it generated the project. The key element is that your
test file should have a (:use clojure.test) in the (ns) form, which is
what allows you to use clojure.test/deftest without
namespace-qualification.

On Tue, Mar 19, 2013 at 2:12 PM, tyaakow  wrote:
> I'm going through clojure & emacs tutorial from clojure-doc.org, and
> when compiling
> the test as suggested, i get following output in emacs nrepl:
>
>
> clojure.lang.Compiler$CompilerException:
> java.lang.RuntimeException: Unable to resolve symbol: deftest in this
> context, compiling:(/home/jakov/dev/PROJECTS/clojure/test2/test/test2/
> core_test.clj:1)
>  Compiler.java:6281 clojure.lang.Compiler.analyze
>  Compiler.java:6223 clojure.lang.Compiler.analyze
>  Compiler.java:3497 clojure.lang.Compiler
> $InvokeExpr.parse
>  Compiler.java:6457 clojure.lang.Compiler.analyzeSeq
>  Compiler.java:6262 clojure.lang.Compiler.analyze
>  Compiler.java:6223 clojure.lang.Compiler.analyze
>  Compiler.java:6515 clojure.lang.Compiler.eval
>  Compiler.java:6952 clojure.lang.Compiler.load
>  Compiler.java:6912 clojure.lang.Compiler.loadFile
> RT.java:307 clojure.lang.RT$3.invoke
>NO_SOURCE_FILE:1 user/eval42
>  Compiler.java:6511 clojure.lang.Compiler.eval
>  Compiler.java:6477 clojure.lang.Compiler.eval
>   core.clj:2797 clojure.core/eval
>main.clj:245 clojure.main/repl[fn]
>main.clj:266 clojure.main/repl[fn]
>main.clj:266 clojure.main/repl
>RestFn.java:1096 clojure.lang.RestFn.invoke
>   interruptible_eval.clj:56
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>AFn.java:159 clojure.lang.AFn.applyToHelper
>AFn.java:151 clojure.lang.AFn.applyTo
>core.clj:601 clojure.core/apply
>   core.clj:1771 clojure.core/with-bindings*
> RestFn.java:425 clojure.lang.RestFn.invoke
>   interruptible_eval.clj:41
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate
>  interruptible_eval.clj:171
> clojure.tools.nrepl.middleware.interruptible-eval/interruptible-
> eval[fn]
>   core.clj:2278 clojure.core/comp[fn]
>  interruptible_eval.clj:138
> clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
> AFn.java:24 clojure.lang.AFn.run
> ThreadPoolExecutor.java:895
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask
> ThreadPoolExecutor.java:918
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> Thread.java:662 java.lang.Thread.run
> Caused by: java.lang.RuntimeException: Unable to resolve symbol:
> deftest in this context
>   Util.java:170 clojure.lang.Util.runtimeException
>  Compiler.java:6766 clojure.lang.Compiler.resolveIn
>  Compiler.java:6710 clojure.lang.Compiler.resolve
>  Compiler.java:6671
> clojure.lang.Compiler.analyzeSymbol
>  Compiler.java:6244 clojure.lang.Compiler.analyze
>
> To me, it seems like this line is crucial in the nrepl error output:
>
> Caused by: java.lang.RuntimeException: Unable to resolve symbol:
> deftest in this context
>
> Anyway, i am really a clojure & emacs noob, and I dont have much clue
> here.
> All the emacs slime clojure stuff is installed, `leiningen2` is
> installed, java is oracle java 1.6, emacs is emacs 24, and when I run
> lein test in projects directory, it goes without errors.
>
> Can anyone help me?
>
>
> My core_test.clj file:
>
> (deftest pairs-of-values
>(let [args ["--server" "localhost"
>"--port" "8080"
>"--environment" "production"]]
>   (is (= {:server "localhost"
>   :port "8080"
>   :environment "production"}
>  (parse-args args)
>
> My core.clj file:
>
> (defn parse-args [args]
>   {})
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from 

Re: Clj-record

[John D. Hume]

On Tue, Sep 1, 2009 at 4:43 PM, Luc
Prefontaine wrote:
> Hi John,
>
> Clj-record will make its way into production in a couple of weeks.
>
> It's been working flawlessly in high volume tests here.

Hi Luc,
That's great to hear. I recently set up a Google Group for clj-record,
so you may want to sign up.
http://groups.google.com/group/clj-record-dev

It's very low-volume. In fact, it's basically no-volume. :)

Thanks for the encouragement.
-hume.

-- 
http://elhumidor.blogspot.com/

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

Re: ANN: libraries promoted from contrib to clojure

[John D. Hume]

There may already have been a discussion about this in IRC, but I
would have loved to see the 'are' macro continue to support the old
syntax (maybe with deprecation warnings) as well as the new until
after 1.1 is released. This change makes it relatively expensive for
any library with a significant test suite that uses 'are' to keep
testing with both the current release and the current snapshot of
clojure and contrib.

On Thu, Jun 25, 2009 at 10:40 PM, Stuart
Halloway wrote:
> ... Also, the signature and implementation
> of test/are has changed, and is now more idiomatic. For example:
>
> (deftest test-count
>   (are [x y] (= x y)   ; instead of (are (= _1 _2))
>       (count nil) 0
>       (count ()) 0
>       (count '(1)) 1
>       (count '(1 2 3)) 3
> ; etc.


-- 
http://elhumidor.blogspot.com/

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

Re: Interest in creating a NYC Clojure user group?

[John D. Hume]

On Thu, Jun 4, 2009 at 12:09 PM, Eric Thorsen wrote:
> what kind of interest there might be in creating a Clojure user group
> in the NY metro area to meet up in Manhattan once a month to discuss
> all things Clojure.

I'd make an effort to attend monthly Clojure meetings in NYC.

-- 
http://elhumidor.blogspot.com/

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

Re: Google App Engine - best workflow

[John D. Hume]

On Fri, May 15, 2009 at 6:02 AM, Kees-Jochem Wehrmeijer
 wrote:
> beyond my skill level. At first I tried to start a swank server from
> my servlet, but that failed because GAE doesn't allow you to open
> sockets. By decompiling and disabling that, I could probably work

This still wouldn't give you a REPL running in the dev server, but for
messing around with datastore stuff interactively you can call
appengine-clj.test-utils/ds-setup [1] from a REPL which will create an
in-memory datastore. I've used this with vimclojure with some success.
(Occasionally it will tell me I don't have an app registered for the
current thread, and I have to call ds-setup again. I assume this has
to do with something multi-threaded happening in the nailgun server
vimclojure uses, but I haven't delved into it.)

-hume.

[1] 
http://github.com/duelinmarkers/appengine-clj/blob/master/src/appengine_clj/test_utils.clj#L9

-- 
http://elhumidor.blogspot.com/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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.main always exits with code 0

[John D. Hume]

Submitted as
http://code.google.com/p/clojure/issues/detail?id=106

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