Re: Faster application startup for rapid development

[Michael Gardner]

There's also nailgun: it keeps a JVM running in the background that Java 
programs can connect to, eliminating JVM startup time completely. It's totally 
insecure on multi-user machines and hasn't been updated in a while, but it may 
be sufficient to ease the pain on developer machines.

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

[David Nolen]

Returning the symbol seems odd at least to me. I think the best we could do
is have a compiler flag so that defs can return nil for REPLs.

On Tuesday, May 15, 2012, kovas boguta wrote:

> Yeah, that is sort of what I was implying in "changing the semantics of
> def"
>
> Though I wasn't ready to totally committed to that, since I don't
> understand the properties of symbols in clojurescript.
>
> Like, how do go from the symbol to the javascript object we've just
> bound to the symbol?
>
>
> On Tue, May 15, 2012 at 2:26 AM, Laurent PETIT 
> wrote:
> > Clojurescript doesn't have vars, so why not have def return the symbol ?
> >
> >
> >
> > Le 15 mai 2012 à 06:14, kovas boguta  a écrit :
> >
> >> I think this is a pretty valid feature request.
> >>
> >> The main question is, can this be done without having vars in
> clojurescript.
> >>
> >> One way to do it is to surpress output somehow, under certain
> conditions.
> >>
> >> Either as a token at the end of a repl input, or in the semantics of
> def itself.
> >>
> >> I don't have an ideal specific solution here, but I've noticed this
> >> problem as well and found it pretty annoying.
> >>
> >> There should be a way to solve it that is a reasonable compromise.
> >>
> >>
> >>
> >> On Mon, May 14, 2012 at 11:13 PM, Mark Engelberg
> >>  wrote:
> >>> On Mon, May 14, 2012 at 4:41 PM, David Nolen 
> wrote:
> 
>  On Mon, May 14, 2012 at 7:27 PM, Mark Engelberg <
> mark.engelb...@gmail.com>
>  wrote:
> >
> > (def tree (function-that-produces-an-enormous-tree 2))
> 
> 
>  Isn't doing this at the top level bad form?
> >>>
> >>>
> >>> The purpose of a REPL is for interactive experimentation.  I want to
> give
> >>> names to the things I'm building so I can play with them in the REPL.
> >>> Nothing bad form about that.
> >>>
> 
>  Also I don't see how this isn't solved by modifying some habits.
> 
>  (defn test-tree [] (function-that-produces-an-enormous-tree 2))
>  (time (test-tree))
> 
> >>>
> >>> time prints out the value that is computed.  The above example would
> suffer
> >>> the same problem of printing out the tree at the REPL.  You could do
> >>> something like (time (do (test-tree) nil)) to suppress printing, but
> if you
> >>> want to do further interactive manipulations to the tree, you'd end up
> >>> recomputing it.  So then, you get into workarounds involving delay.  It
> >>> starts to get ugly, I think.
> >>>
> >>> Clojure's ability to give names to things without printing the values
> is a
> >>> feature I use every day in my interactive explorations.
> >>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Clojure" group.
> >>> To post to this group, send email to clojure@googlegroups.com
> >>> Note that posts from new members are moderated - please be patient
> with your
> >>> first post.
> >>> To unsubscribe from this group, send email to
> >>> clojure+unsubscr...@googlegroups.com
> >>> For more options, visit this group 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 r

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

Re: defs in Clojurescript REPL

[Michał Marczyk]

Workaround:

(do (def foo (build-something-enormous)) nil)

As for the reason for this behaviour -- probably non other than it's
just the easiest thing for def in ClojureScript to do; "it" being to
inherit the return value from the JavaScript assignment def compiles
to.

Sticking a void () around the assignment (so that (def foo ...) would
do what (js* "void (~{})" (def foo ...)) does currently) would be a
straightforward way of suppressing the returned value. I can put
together the (trivial) patch to do that in :statement context in the
presence of a flag if this seems useful. The REPL could just set this
flag by default.

Sincerely,
Michał


On 15 May 2012 06:14, kovas boguta  wrote:
> I think this is a pretty valid feature request.
>
> The main question is, can this be done without having vars in clojurescript.
>
> One way to do it is to surpress output somehow, under certain conditions.
>
> Either as a token at the end of a repl input, or in the semantics of def 
> itself.
>
> I don't have an ideal specific solution here, but I've noticed this
> problem as well and found it pretty annoying.
>
> There should be a way to solve it that is a reasonable compromise.
>
>
>
> On Mon, May 14, 2012 at 11:13 PM, Mark Engelberg
>  wrote:
>> On Mon, May 14, 2012 at 4:41 PM, David Nolen  wrote:
>>>
>>> On Mon, May 14, 2012 at 7:27 PM, Mark Engelberg 
>>> wrote:

 (def tree (function-that-produces-an-enormous-tree 2))
>>>
>>>
>>> Isn't doing this at the top level bad form?
>>
>>
>> The purpose of a REPL is for interactive experimentation.  I want to give
>> names to the things I'm building so I can play with them in the REPL.
>> Nothing bad form about that.
>>
>>>
>>> Also I don't see how this isn't solved by modifying some habits.
>>>
>>> (defn test-tree [] (function-that-produces-an-enormous-tree 2))
>>> (time (test-tree))
>>>
>>
>> time prints out the value that is computed.  The above example would suffer
>> the same problem of printing out the tree at the REPL.  You could do
>> something like (time (do (test-tree) nil)) to suppress printing, but if you
>> want to do further interactive manipulations to the tree, you'd end up
>> recomputing it.  So then, you get into workarounds involving delay.  It
>> starts to get ugly, I think.
>>
>> Clojure's ability to give names to things without printing the values is a
>> feature I use every day in my interactive explorations.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: defrecord serialization and *data-readers*

[Stuart Sierra]

Data reader literals are not intended to replace record serialization. If 
you want the flexibility to change your record types, I think you need to 
use data reader literals from the beginning, and have them deserialize as 
the appropriate record type.

-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

Re: How to use third-party libraries with Leiningen that are not found in Clojars or Maven

[Tim Visher]

On Sat, May 12, 2012 at 12:36 PM, Mads Andreas Elvheim
 wrote:
> I have a few issues which are all related. I'll do my best to explain them
> one by one.
>
> I'd like to use the latest version of the jOGL library with Clojure 1.3 /
> Leiningen 1.7.1 / OpenJDK 1.6.
>
> After getting the jars from joGL's website, how can I get the library
> exposed to leiningen and Clojure in the most convenient way? I see no
> obvious way to set extra classpaths for a leiningen project, but I might
> have missed something obvious. Also, leiningen happily ignores the
> $CLASSPATH environment variable.
>
> And besides repacking jOGL and make it available in Maven or Clojars, what
> is the best approach for distributing the extra jOGL dependency? jOGL is a
> JRI library, and I assume that's why the existing opengl/jogl 2.0-rc3
> package in Clojars appears to be broken. Roughly from what I've read
> elsewhere, Maven repos don't like platform-specific dependencies, so that
> probably leaves lein-localrepo out of the picture as well.
>
> You'll have to excuse my ignorance. I'm both new to Clojure and Java, but
> any pointers and reading suggestions will humbly be taken with open arms. My
> background is C++ and various assembly dialects. I'd love to get OpenGL 3.3
> and Swing working in Clojure :-)

And since no one else pointed it out, here's a link to the wiki page
explaining why leiningen makes it so bloddy difficult to just throw
random things on the classpath:

https://github.com/technomancy/leiningen/wiki/Repeatability

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

[Tim Visher]

On Sat, May 12, 2012 at 3:48 PM, JDuPreez  wrote:
> I'm new to Clojure. I've been unsuccessful in finding a clear answer or
> getting it to work (might just have done it incorrectly, since I'm still
> learning). I understand that you can add metadata to an object, "with-meta",
> and to a variable or parameter, "^{:". However, I would like to apply
> metadata to defrecord and defstruct, so that the data type definitions are
> associated with the metadata. This will be the same as applying an
> annotation to a Java class.
>
> Does Clojure support something similar? If so, please provide a simple
> example of how it will be applied to, and read from, a defrecord and
> defstruct. If Clojure doesn't, then that's okay as well, as I've found a
> relatively straight forward way to achieve the same result. I just want to
> make sure I'm not missing something before going ahead using my custom
> annotation mechanism.
>
> Really appreciate the help. Thanks!

Don't think I'll be much help but maybe I can unofficially confirm
your findings.

Looking through the various implementation details ([defrecord][],
[emit-defrecord][], [emit-deftype*][]) I can't see any way that you
can attach custom meta-data to any of the products of those
constructs at the time of their construction. None of arguments are
used in the metadata of the artifacts.

They do associate metadata with the class produced, but
I'm not sure to what degree you can affect that definition post
macro-expansion. If you can affect the definition of that class
post-expansion then you should be good to go.

[emit-deftype*]:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_deftype.clj#L361
[emit-defrecord]:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_deftype.clj#L140
[defrecord]: 
https://github.com/clojure/clojure/blob/6d84867f4c892159ad48f6ef4b56f11567b2172c/src/clj/clojure/core_deftype.clj#L257

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

[Stefan Kamphausen]

Hi,

I am not sure whether I fully understand your question.  However, when you 
create a record, a second constructor will be created for you which also 
expects a meta-data map:

user=> (defrecord Foo (bar baz))
user=> (meta (Foo. 2 3 {:foo "meta"} nil))
{:foo "meta"}


Hope that helps.
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

A Clout-like route-matching lib for ClojureScript.

[eduardoejp]

Made it for a project I'm working on. Thought it'd be nice to open-source 
it. It's called Snout.

https://github.com/eduardoejp/snout

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

[Timothy Baldridge]

There seems to be a few steps involved in this from, what I'm seeing.

>From what I'm seeing of the source, there's two files I'll be dealing with

closure.clj -- defines functions for looking up info about libraries,
functions, etc.
compiler.clj -- actually defines the compiler

To start with, I'm thinking of trying to compile ClojureScript in
ClojureScript. I know this won't work if the user has optimized
ClojureScript at all, but it should be a good testing point.

The first step in this process would then be to write a version of
closure.clj in ClojureScript. Somehow it would present the same
interface as closure.clj but in a JS environment. I'll have to look
into how well that may work out. I'm going to call this file the
platform.clj file.

>From there I'll need to take a look at the GSOC work (where is that
currently?) to see how much of the compiler I'd need to modify. But
we'd basically need to re-write the compiler to use only ClojureScript
compatible forms. From there it should be fairly complete.

So the way I'd then port ClojureScript to Python would be the following:

1) Write a platform.clj (closure.clj) file for Python. This would
somehow allow Java to tap into Python and run reflection on the
modules in Python.
2) Implement a Python back-end for the GSOC pluggable-backend
3) Compile compiler.clj into one massive python file
4) Write a new platform.clj file to just look at the Python VM instead
of going from Java->Python->Modules
5) Compile compiler.clj into one massive python file
6) ...
7) Profit!

Long term I'm only seeing that we'll need to write 3 files each time
we want to port ClojureScript to a new platform:

1) The Java version of platform.clj
2) The compiler backend
3) A "native" version of platform.clj

I'm going to look into the GSOC stuff next to make sure I'm not going
to duplicate anyone's work.

Timothy

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

[Stuart Sierra]

Reasonable enough. Patch welcome.
-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

Re: Reducers

[Stuart Sierra]

It's fixed now.

On Friday, May 11, 2012 12:30:47 PM UTC-4, Sean Corfield wrote:
>
> Just to clarify: Clojure isn't building at the moment _on 
> build.clojure.org_ but you can build it yourself easily enough: 
>
>

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

[Vinzent]

Or maybe if-let and when-let should support multiple bindings, like the doc 
states.

воскресенье, 13 мая 2012 г., 4:55:40 UTC+6 пользователь Borkdude написал:
>
> The docstring of if-let is as follows:
>
> bindings => binding-form test
>
> If test is true, evaluates then with binding-form bound to the value of 
> test, if not, yields else
>
> I think it should be mentioned in the docs that if-let and when-let 
> support only *one binding*, not multiple bindings (like for example 
> https://www.refheap.com/paste/2700).
>  
> Kind regards,
>
> Michiel
>

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

[JDuPreez]

Stefan,

Thank you for your reply. You are referring to applying an annotation to an 
instance/object.

If we could imagine it existed for the moment, this is what I'd be looking 
for:
(meta {:foo "meta"} (defrecord Foo (bar baz)))

I should then somehow be able to retrieve the metadata of the type 
definition, given an instance of it. In other words, given an instance of 
record Foo, I should be able to get to the metadata of its defrecord 
definition.

Maybe I should post my solution to this problem here?

Thanks!

Jacques


On Tuesday, May 15, 2012 4:51:15 PM UTC+2, Stefan Kamphausen wrote:
>
> Hi,
>
> I am not sure whether I fully understand your question.  However, when you 
> create a record, a second constructor will be created for you which also 
> expects a meta-data map:
>
> user=> (defrecord Foo (bar baz))
> user=> (meta (Foo. 2 3 {:foo "meta"} nil))
> {:foo "meta"}
>
>
> Hope that helps.
> 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

Re: Bootstrapping Clojure-in-Clojure

[Kevin Downey]

On Tue, May 15, 2012 at 8:05 AM, Timothy Baldridge  wrote:
> There seems to be a few steps involved in this from, what I'm seeing.
>
> From what I'm seeing of the source, there's two files I'll be dealing with
>
> closure.clj -- defines functions for looking up info about libraries,
> functions, etc.
> compiler.clj -- actually defines the compiler
>
> To start with, I'm thinking of trying to compile ClojureScript in
> ClojureScript. I know this won't work if the user has optimized
> ClojureScript at all, but it should be a good testing point.
>
> The first step in this process would then be to write a version of
> closure.clj in ClojureScript. Somehow it would present the same
> interface as closure.clj but in a JS environment. I'll have to look
> into how well that may work out. I'm going to call this file the
> platform.clj file.
>
> From there I'll need to take a look at the GSOC work (where is that
> currently?) to see how much of the compiler I'd need to modify. But
> we'd basically need to re-write the compiler to use only ClojureScript
> compatible forms. From there it should be fairly complete.
>
> So the way I'd then port ClojureScript to Python would be the following:
>
> 1) Write a platform.clj (closure.clj) file for Python. This would
> somehow allow Java to tap into Python and run reflection on the
> modules in Python.
> 2) Implement a Python back-end for the GSOC pluggable-backend
> 3) Compile compiler.clj into one massive python file
> 4) Write a new platform.clj file to just look at the Python VM instead
> of going from Java->Python->Modules
> 5) Compile compiler.clj into one massive python file
> 6) ...
> 7) Profit!
>
> Long term I'm only seeing that we'll need to write 3 files each time
> we want to port ClojureScript to a new platform:
>
> 1) The Java version of platform.clj
> 2) The compiler backend
> 3) A "native" version of platform.clj
>
> I'm going to look into the GSOC stuff next to make sure I'm not going
> to duplicate anyone's work.
>
> Timothy

Logically the interface between the analyzer and the emitter is data
(maps, etc) which can be serialized as json or some platform specific
representation. Then all you need to do is write an emitter on your
platform of choice that can emit code for the data.

So for Python:
1. run the analyzer on itself to get the data describing it
2. serialize that data in some format Python can read
3. write an emitter in Python
4. feed the analyzer data to the emitter
5. hook the emitted analyzer code up to the emitter

so the whole thing pivots around the data emitted from the analyzer

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



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

[Timothy Baldridge]

> Logically the interface between the analyzer and the emitter is data
> (maps, etc) which can be serialized as json or some platform specific
> representation. Then all you need to do is write an emitter on your
> platform of choice that can emit code for the data.
>
> So for Python:
> 1. run the analyzer on itself to get the data describing it
> 2. serialize that data in some format Python can read
> 3. write an emitter in Python
> 4. feed the analyzer data to the emitter
> 5. hook the emitted analyzer code up to the emitter
>
> so the whole thing pivots around the data emitted from the analyzer

One question. Let's say that we are analyzing "(require 'foo.bar)".
How does the analyzer know if foo.bar exists? Are you suggesting that
we leave that to the emitter?

I like this idea...I'm going to think about it a bit more...

Timothy

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

[Rich Hickey]

I've written another post which goes into the reducers in more detail:

http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html

Rich

On May 10, 2012, at 1:26 PM, Christian Romney wrote:

> 
> 
> On Thursday, May 10, 2012 8:02:09 AM UTC-4, Nicolas Oury wrote:
> I can describe the background to understand my last email. 
> 
> Thank you very much for taking the time to post all of that–I've got some 
> reading to do for sure. 
> 
> -- 
> 

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

[Hubert Iwaniuk]

I tried using if-let with multiple binding in past as well.
Following least surprise principle, I would like to see support for 
multiple bindings.


Cheers,
Hubert.

Vinzent 
May 15, 2012 5:47 PM
Or maybe if-let and when-let should support multiple bindings, like 
the doc states.


воскресенье, 13 мая 2012 г., 4:55:40 UTC+6 пользователь Borkdude 
написал: --

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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Borkdude 
May 13, 2012 12:55 AM
The docstring of if-let is as follows:

bindings => binding-form test

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

I think it should be mentioned in the docs that if-let and when-let 
support only /one binding/, not multiple bindings (like for 
example https://www.refheap.com/paste/2700).


Kind regards,

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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


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

Re: Bootstrapping Clojure-in-Clojure

[Kevin Downey]

On Tue, May 15, 2012 at 11:25 AM, Timothy Baldridge
 wrote:
>> Logically the interface between the analyzer and the emitter is data
>> (maps, etc) which can be serialized as json or some platform specific
>> representation. Then all you need to do is write an emitter on your
>> platform of choice that can emit code for the data.
>>
>> So for Python:
>> 1. run the analyzer on itself to get the data describing it
>> 2. serialize that data in some format Python can read
>> 3. write an emitter in Python
>> 4. feed the analyzer data to the emitter
>> 5. hook the emitted analyzer code up to the emitter
>>
>> so the whole thing pivots around the data emitted from the analyzer
>
> One question. Let's say that we are analyzing "(require 'foo.bar)".
> How does the analyzer know if foo.bar exists? Are you suggesting that
> we leave that to the emitter?
>
> I like this idea...I'm going to think about it a bit more...
>
> Timothy

It sort of depends in some sense "(require 'foo.bar)" is just calling
the function require with a symbol as an argument.

 I can certainly imagine cases where the analyzer might want
reflection on types etc of the given platform, but I think that is
really an optimization, trading off compile/analyzer time reflection
for runtime reflection. That platform reflective information would be
provided by something like clojure.reflect, and could either run via
querying a running instance of the platform, or via just a static data
file of the information. But that info is, I think, mostly required to
make generated code fast, but it should be possible to generate slower
reflective code "generically" for the initial bootstrap without 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



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

[Evan Gamble]

If if-let and when-let don't get support for multiple bindings, you could 
try https://github.com/egamble/let-else .

On Tuesday, May 15, 2012 12:09:08 PM UTC-7, Hubert Iwaniuk wrote:
>
> I tried using if-let with multiple binding in past as well.
> Following least surprise principle, I would like to see support for 
> multiple bindings.
>
> Cheers,
> Hubert
>  

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

[Aaron Cohen]

Does the principle of least surprise suggest that multiple bindings be
combined with AND or OR?

--Aaron

On Tue, May 15, 2012 at 3:09 PM, Hubert Iwaniuk  wrote:

> I tried using if-let with multiple binding in past as well.
> Following least surprise principle, I would like to see support for
> multiple bindings.
>
> Cheers,
> Hubert.
>
>   Vinzent 
>  May 15, 2012 5:47 PM
> Or maybe if-let and when-let should support multiple bindings, like the
> doc states.
>
> воскресенье, 13 мая 2012 г., 4:55:40 UTC+6 пользователь Borkdude написал:
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>   Borkdude 
>  May 13, 2012 12:55 AM
> The docstring of if-let is as follows:
>
> bindings => binding-form test
>
> If test is true, evaluates then with binding-form bound to the value of
> test, if not, yields else
>
> I think it should be mentioned in the docs that if-let and when-let
> support only *one binding*, not multiple bindings (like for example
> https://www.refheap.com/paste/2700).
>
> Kind regards,
>
> Michiel
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: docstrings of if-let and when-let incorrect

[Walter Tetzner]

On Tuesday, May 15, 2012 3:26:52 PM UTC-4, Aaron Cohen wrote:
>
> Does the principle of least surprise suggest that multiple bindings be 
> combined with AND or OR?
>
>  
For `when-let', I would expect it to work like nested when-lets:

(when-let [x (exp-1)
   y (exp-2 x)
   z (exp-3 y)]
  [x y z])

would be the same as

(when-let [x (exp-1)]
  (when-let [y (exp-2 x)]
(when-let [z (exp-3 y)]
  [x y z])))

For the behavior of `if-let' to not be suprising given this definition
of `when-let', I think it would have to behave similarily:

(if-let [x (exp-1)
 y (exp-2 x)
 z (exp-3 y)]
  [x y z]
  'failed)

would be the same as

(if-let [x (exp-1)]
  (if-let [y (exp-2 x)]
(if-let [z (exp-3 y)]
  [x y z]
  'failed)
'failed)
  'failed)

So, AND I guess. But later expressions can refer to earlier ones, just
like in `let'.

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

[Dan Cross]

On Tue, May 15, 2012 at 3:26 PM, Aaron Cohen  wrote:

> Does the principle of least surprise suggest that multiple bindings be
> combined with AND or OR?


My own personal opinion is that it makes sense in combination with 'and',
but others may feel differently.  E.g.,

(when-let [a (allocate-thing) b (read-into-thing a) c
(extract-something-from-thing b)]
  (do-something-with c))

makes intuitive sense to me.  If, at any stage of the execution, any of a,
b or c was nil, the evaluation would stop and the (when-let) form would
return nil.

- Dan C.

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

[Walter Tetzner]

On Tuesday, May 15, 2012 3:41:58 PM UTC-4, Dan Cross wrote:
>
> My own personal opinion is that it makes sense in combination with 'and', 
> but others may feel differently.  E.g.,
>
> (when-let [a (allocate-thing) b (read-into-thing a) c 
> (extract-something-from-thing b)]
>   (do-something-with c))
>
> makes intuitive sense to me.  If, at any stage of the execution, any of a, 
> b or c was nil, the evaluation would stop and the (when-let) form would 
> return nil.
>
>
So judging by both your response and my response, it should behave like the 
maybe monad.

-Walter

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

[Timothy Baldridge]

>  I can certainly imagine cases where the analyzer might want
> reflection on types etc of the given platform, but I think that is
> really an optimization, trading off compile/analyzer time reflection
> for runtime reflection. That platform reflective information would be
> provided by something like clojure.reflect, and could either run via
> querying a running instance of the platform, or via just a static data
> file of the information. But that info is, I think, mostly required to
> make generated code fast, but it should be possible to generate slower
> reflective code "generically" for the initial bootstrap without it.

The real reason this is done, is because Clojure is a compiled
language. For instance:

user=> (defn z [baz] baz)
#'user/z
user=> (defn foo [] (z.))
java.lang.IllegalArgumentException: Unable to resolve classname: z (NO_SOURCE_FI
LE:10)

The other thing I'm starting to wonder is what doing all the above
really gets us?

For instance, let's say the analyzer sees this function:

(defn as-str [x] (.toString x))

That can't port to Python, or really any other VM besides JS. So if
we're looking at translating the analyzer itself we have to develop
some sort of base set of libraries that every thing else can build
upon. So either we need to define a ur-clojure function called
"toString", and then every emitter will need to implement that
seperately.

At that point, I have to wonder what's the point of this "analyzer"
step? In Clojure code is data is code. The more I think about what
this serialized output would look like the more I think it would look
just like Clojure code. What are we actually saving with this process?

Timothy

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

[Robert McIntyre]

There's a right parenthesis missing at
http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html :

Now:

(reduce + 0 (map inc [1 2 3 4]))
;;becomes
(reduce + 0 (reducer [1 2 3 4] (mapping inc)) < MISSING PAREN


under the heading "Reducers"


sincerely,
--Robert McIntyre, Dylan Holmes

On Tue, May 15, 2012 at 1:58 PM, Rich Hickey  wrote:
> I've written another post which goes into the reducers in more detail:
>
> http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html
>
> Rich
>
> On May 10, 2012, at 1:26 PM, Christian Romney wrote:
>
>>
>>
>> On Thursday, May 10, 2012 8:02:09 AM UTC-4, Nicolas Oury wrote:
>> I can describe the background to understand my last email.
>>
>> Thank you very much for taking the time to post all of that–I've got some 
>> reading to do for sure.
>>
>> --
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Bootstrapping Clojure-in-Clojure

[David Nolen]

On Tue, May 15, 2012 at 3:51 PM, Timothy Baldridge wrote:

> (defn as-str [x] (.toString x))
>
> That can't port to Python, or really any other VM besides JS. So if
> we're looking at translating the analyzer itself we have to develop
> some sort of base set of libraries that every thing else can build
> upon. So either we need to define a ur-clojure function called
> "toString", and then every emitter will need to implement that
> seperately.


Why can't it port to Python? You have can have an instance with a method
toString right?

David

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

[Timothy Baldridge]

> Why can't it port to Python? You have can have an instance with a method
> toString right?

The python version of that code (at least in clojure-py) would be this:

(defn as-str [x] (py/str x))

So my point is that some platforms may define toString, other define
str and still others (CLR) define ToString. There will have to be some
translator layer for each and every native function called from inside
the compiler.

Timothy

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

[Kevin Downey]

On Tue, May 15, 2012 at 12:51 PM, Timothy Baldridge
 wrote:
>>  I can certainly imagine cases where the analyzer might want
>> reflection on types etc of the given platform, but I think that is
>> really an optimization, trading off compile/analyzer time reflection
>> for runtime reflection. That platform reflective information would be
>> provided by something like clojure.reflect, and could either run via
>> querying a running instance of the platform, or via just a static data
>> file of the information. But that info is, I think, mostly required to
>> make generated code fast, but it should be possible to generate slower
>> reflective code "generically" for the initial bootstrap without it.
>
> The real reason this is done, is because Clojure is a compiled
> language. For instance:
>
> user=> (defn z [baz] baz)
> #'user/z
> user=> (defn foo [] (z.))
> java.lang.IllegalArgumentException: Unable to resolve classname: z 
> (NO_SOURCE_FI
> LE:10)

I dunno what the defn z above is supposed to demonstrate. the analyzer
result for (z.) would be something like "this is code creating an
instance of a type named 'z' in the namespace 'foo without arguments,
it doesn't reference any locals"

> The other thing I'm starting to wonder is what doing all the above
> really gets us?
>
> For instance, let's say the analyzer sees this function:
>
> (defn as-str [x] (.toString x))

. is an interop form, the analysis would result in something like
"call the interop toString on the local x, dunno what type x is"

> That can't port to Python, or really any other VM besides JS. So if
> we're looking at translating the analyzer itself we have to develop
> some sort of base set of libraries that every thing else can build
> upon. So either we need to define a ur-clojure function called
> "toString", and then every emitter will need to implement that
> seperately.
>
> At that point, I have to wonder what's the point of this "analyzer"
> step? In Clojure code is data is code. The more I think about what
> this serialized output would look like the more I think it would look
> just like Clojure code. What are we actually saving with this process?
>
> Timothy

the point of the analysis step is to generate a richer (more verbose)
set of information about the code, there is a lot of information you
would like to have when compiling (for example, for some platforms it
would be nice to know at the start of a function what locals exist in
the that function, or what locals it closes over) which are
extractable from the regular clojure data that represents code, but
it's takes an annoying amount of repetitive work to do so.

This is not to say you might not end up with a platform specific
analyzer (which would kind of be a shame, because I can imagine a
library of platform agnostic optimizers that run over analyzer
output), just a place to start from when bootstrapping.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

[David Nolen]

On Tue, May 15, 2012 at 4:03 PM, Timothy Baldridge wrote:

> > Why can't it port to Python? You have can have an instance with a method
> > toString right?
>
> The python version of that code (at least in clojure-py) would be this:
>
> (defn as-str [x] (py/str x))
>

That would be defined core.cljs - it doesn't have much to do with the
compiler.

(defn as-str [x] (.toString x))

is perfectly valid code and should compile anywhere.


> So my point is that some platforms may define toString, other define
> str and still others (CLR) define ToString. There will have to be some
> translator layer for each and every native function called from inside
> the compiler.


There doesn't need to be any special handling of any kind in the compiler
for this case. People will need to adapt core.cljs.

David

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

[Andy Fingerhut]

If if-let/when-let had multiple bindings, how would you propose to define the 
condition of whether to do the "then" branch?

As the logical AND of all of the multiple forms?  The OR?  Only use the first 
expression?  Only the last?

I don't see that any of those is any more clear or "least surprising" than any 
of the others.  Permitting only one makes that part of the behavior clear, at 
least.

Andy

On May 15, 2012, at 12:09 PM, Hubert Iwaniuk wrote:

> I tried using if-let with multiple binding in past as well.
> Following least surprise principle, I would like to see support for multiple 
> bindings.
> 
> Cheers,
> Hubert.
>>  Vinzent May 15, 2012 5:47 PM
>> Or maybe if-let and when-let should support multiple bindings, like the doc 
>> states.

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

[Michael Gardner]

On May 15, 2012, at 3:15 PM, Andy Fingerhut wrote:

> If if-let/when-let had multiple bindings, how would you propose to define the 
> condition of whether to do the "then" branch?
> 
> As the logical AND of all of the multiple forms?  The OR?  Only use the first 
> expression?  Only the last?
> 
> I don't see that any of those is any more clear or "least surprising" than 
> any of the others.  Permitting only one makes that part of the behavior 
> clear, at least.

AND is the obvious choice, IMO. People will probably still have to look up what 
happens with multiple bindings from time to time, but that doesn't seem worse 
than having to look up whether if-let and when-let even support multiple 
bindings.

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

[Timothy Baldridge]

>the point of the analysis step is to generate a richer (more verbose)
>set of information about the code, there is a lot of information you
>would like to have when compiling (for example, for some platforms it
>would be nice to know at the start of a function what locals exist in
>the that function, or what locals it closes over)

Ah yes, that makes sense. Well that's going to be a good point to
start I think. And it looks like I can just hack the compiler.clj to
output json (or something close to that). From there I should be able
to whip out at Python emitter in no time.

Timothy

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

[ANN] clojure-encog 0.3.0 released on clojars

[Jim - FooBar();]

Hello folks,

I'm happy to announce the release of clojure-encog, a thin wrapper 
around Encog AI framework 3.1. Basically i did this so i could use it 
for a project of mine but I guess someone else might find it useful as 
well...especially if someone does not want to get down and dirty with Java.


Information about encog can be found here:
http://www.heatonresearch.com/encog

and information about my code and how to use it can be found on github:
https://github.com/jimpil/clojure-encog

I have also included a couple of examples to get you started in the 
examples.clj namespace.


Hope someone else finds it useful as well... :-)

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

Re: Faster application startup for rapid development

[MarkSwanson]

> reloading code at the REPL, because old background threads may still be
> running with old code. So I end up restarting the process many times per
> day.

I usually create a 'restart fn that closes down the background threads
and services and restarts them.
This might require you to add a 'shutdown' command to your services
but I've found this to be a small price to pay.

Also, it's some extra code to have threads loop/block on some
condition for 100ms (in debug mode) instead of forever, but this gives
the thread a chance to clean up and terminate every 100ms based on
some condition (set by your restart fn).

Every time you restart your repl you'll wish you had taken the time to
do something like this :-)

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

[Dan Cross]

On Tue, May 15, 2012 at 3:47 PM, Walter Tetzner
 wrote:
> On Tuesday, May 15, 2012 3:41:58 PM UTC-4, Dan Cross wrote:
>> My own personal opinion is that it makes sense in combination with 'and',
>> but others may feel differently.  E.g.,
>>
>>     (when-let [a (allocate-thing) b (read-into-thing a) c
>> (extract-something-from-thing b)]
>>       (do-something-with c))
>>
>> makes intuitive sense to me.  If, at any stage of the execution, any of a,
>> b or c was nil, the evaluation would stop and the (when-let) form would
>> return nil.
>
> So judging by both your response and my response, it should behave like the
> maybe monad.

Yes, that's a very good characterization.

- Dan C.

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

[Rich Hickey]

Fixed - thanks.

Rich

On May 15, 2012, at 3:54 PM, Robert McIntyre wrote:

> There's a right parenthesis missing at
> http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html :
> 
> Now:
> 
> (reduce + 0 (map inc [1 2 3 4]))
> ;;becomes
> (reduce + 0 (reducer [1 2 3 4] (mapping inc)) < MISSING PAREN
> 
> 
> under the heading "Reducers"
> 
> 
> sincerely,
> --Robert McIntyre, Dylan Holmes
> 
> On Tue, May 15, 2012 at 1:58 PM, Rich Hickey  wrote:
>> I've written another post which goes into the reducers in more detail:
>> 
>> http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html
>> 
>> Rich
>> 
>> On May 10, 2012, at 1:26 PM, Christian Romney wrote:
>> 
>>> 
>>> 
>>> On Thursday, May 10, 2012 8:02:09 AM UTC-4, Nicolas Oury wrote:
>>> I can describe the background to understand my last email.
>>> 
>>> Thank you very much for taking the time to post all of that–I've got some 
>>> reading to do for sure.
>>> 
>>> --
>>> 
>> 
>> --
>> 

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

Best way to write an InputStream to disk

[Raju Bitter]

What is the best way to write an FilterInputStream or InputStream do
disk? I'm downloading a file using the clj-http library:

(:body (client/get
"http://www.openlaszlo.org/pipermail/laszlo-dev/2012-May.txt.gz"; {:as
:stream})

That returns the response body as a FilteredInputStream, which I need to save.

Thanks,
Raju

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

[Robert Marianski]

On Wed, May 16, 2012 at 02:15:59AM +0200, Raju Bitter wrote:
> What is the best way to write an FilterInputStream or InputStream do
> disk? I'm downloading a file using the clj-http library:
> 
> (:body (client/get
> "http://www.openlaszlo.org/pipermail/laszlo-dev/2012-May.txt.gz"; {:as
> :stream})
> 
> That returns the response body as a FilteredInputStream, which I need to save.
> 
> Thanks,
> Raju

I'd use clojure.java.io/copy:

http://richhickey.github.com/clojure/clojure.java.io-api.html#clojure.java.io/copy

Robert

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

[Raju Bitter]

Thanks a lot, that worked for me.

Raju

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

Unable to replace static Java method with Clojure function

[Matthew Boston]

I currently have a static method in Java. I have rewritten it in Clojure. I 
wish to allow the rest of the Java app to call the new function with 
minimal change. Still getting "NumberValidator cannot be resolved" even 
after reading the following SO post and it's not helping for my particular 
situation.

http://stackoverflow.com/questions/2181774/calling-clojure-from-java

Any help is greatly appreciated.

Current Java implementation
===
package com.company.bank;

class NumberValidator {
  public static boolean isValid(String account) {
...
  }
}
===

What I'd like to not have to change:
===
package com.company.bank;

class App {
  public run(String account) {
...
NumberValidator.isValid(account);
...
  }
}
===

My new Clojure implementation:
===
(ns com.company.bank.number-validator
  (:gen-class
   :main false
   :name com.company.bank.NumberValidator
   :methods [#^{:static true} [isValid [String] boolean]))

(defn isValid [account]
  ...)

(defn -isValid [account]
  (isValid account))
===

code has been modified to protect the innocent.

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

Clojurescript NS question

[Oded Badt]

In:
https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure 
It is written than:
"You must use the :as form of :require "

Does this basically mean there is no natural way to write a set of 
functions and import them globally (with no namespace prefix)?

For example I would like to freely use trigonometric functions and 
mathematical constants in my ClojureScript code:
  eg: (sin PI) instead of (Math/sin Math/PI)

Thanks
Oded

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

[Oded Badt]

Sorry, meant to quote:
" :use is not supported  "

On Wednesday, May 16, 2012 8:36:24 AM UTC+3, Oded Badt wrote:
>
> In:
> https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure 
> It is written than:
> "You must use the :as form of :require "
>
> Does this basically mean there is no natural way to write a set of 
> functions and import them globally (with no namespace prefix)?
>
> For example I would like to freely use trigonometric functions and 
> mathematical constants in my ClojureScript code:
>   eg: (sin PI) instead of (Math/sin Math/PI)
>
> Thanks
> Oded
>
>

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

Re: Unable to replace static Java method with Clojure function

[Meikel Brandmeyer (kotarak)]

Hi,

you are sure that your AOT compiled class files are on the classpath before 
compiling the Java side?

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

ANN clj-wallhack

[Allen Rohner]

I've resurrected old school clojure.contrib.java-utils/wall-hack-
{method,field} into a new library

https://github.com/arohner/clj-wallhack

Thanks to hiredman for the original implementation.

Allen

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

[kovas boguta]

I'd rather see something at the beginning or at the end of the statement.

like ^:toss (def ...)

or (def ...) ;;


On Tue, May 15, 2012 at 6:50 AM, Michał Marczyk
 wrote:
> Workaround:
>
> (do (def foo (build-something-enormous)) nil)
>
> As for the reason for this behaviour -- probably non other than it's
> just the easiest thing for def in ClojureScript to do; "it" being to
> inherit the return value from the JavaScript assignment def compiles
> to.
>
> Sticking a void () around the assignment (so that (def foo ...) would
> do what (js* "void (~{})" (def foo ...)) does currently) would be a
> straightforward way of suppressing the returned value. I can put
> together the (trivial) patch to do that in :statement context in the
> presence of a flag if this seems useful. The REPL could just set this
> flag by default.
>
> Sincerely,
> Michał
>
>
> On 15 May 2012 06:14, kovas boguta  wrote:
>> I think this is a pretty valid feature request.
>>
>> The main question is, can this be done without having vars in clojurescript.
>>
>> One way to do it is to surpress output somehow, under certain conditions.
>>
>> Either as a token at the end of a repl input, or in the semantics of def 
>> itself.
>>
>> I don't have an ideal specific solution here, but I've noticed this
>> problem as well and found it pretty annoying.
>>
>> There should be a way to solve it that is a reasonable compromise.
>>
>>
>>
>> On Mon, May 14, 2012 at 11:13 PM, Mark Engelberg
>>  wrote:
>>> On Mon, May 14, 2012 at 4:41 PM, David Nolen  wrote:

 On Mon, May 14, 2012 at 7:27 PM, Mark Engelberg 
 wrote:
>
> (def tree (function-that-produces-an-enormous-tree 2))


 Isn't doing this at the top level bad form?
>>>
>>>
>>> The purpose of a REPL is for interactive experimentation.  I want to give
>>> names to the things I'm building so I can play with them in the REPL.
>>> Nothing bad form about that.
>>>

 Also I don't see how this isn't solved by modifying some habits.

 (defn test-tree [] (function-that-produces-an-enormous-tree 2))
 (time (test-tree))

>>>
>>> time prints out the value that is computed.  The above example would suffer
>>> the same problem of printing out the tree at the REPL.  You could do
>>> something like (time (do (test-tree) nil)) to suppress printing, but if you
>>> want to do further interactive manipulations to the tree, you'd end up
>>> recomputing it.  So then, you get into workarounds involving delay.  It
>>> starts to get ugly, I think.
>>>
>>> Clojure's ability to give names to things without printing the values is a
>>> feature I use every day in my interactive explorations.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with your
>>> first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group 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 post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 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