Destructuring Bind on Regex

[JvJ]

I wrote this little macro today that lets you do it.  However, I feel like 
it was implemented in a pattern match library or something... but I'm not 
sure.
Someone let me know if I'm re-inventing the wheel.

If I'm not, here's the code:

(defn re-bind-fn
  [str re bnds act & forms]
  `(let [~'__TEMP__ (re-find ~re ~str)
 ~bnds ~'__TEMP__]
 (if ~'__TEMP__
   ~act
   ~(if (empty? forms)
  nil
  (apply re-bind-fn str forms)

(defmacro re-bind
  [str re bnds act & forms]
  (apply re-bind-fn str re bnds act forms))



You can do things like this:

(defn msg-parse
   [s]
 (re-bind
  s
  #"HELLO (\w+)" [_ nme] (println "Hello message for " nme)
  #"COORDS (\d+) (\d+)" [_ x y] (println "Coords: (" x ", " y ")")
  #".*" _ (println "unimportant")))


cons-irc.util> (msg-parse "COORDS 123 456")
Coords: ( 123 ,  456 )

nil
cons-irc.util> (msg-parse "HELLO Kaylen")
Hello message for  Kaylen

nil
cons-irc.util> (msg-parse "fdsfsd")
unimportant

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/groups/opt_out.

Re: Prismatic Plumbing and Graph Open-Source Release

[Edmund]

Hi Jason,

  That's roughly what I figured, thanks for the helpful reply.

Thanks for taking the time release this lib; its really great

Edmund

On Saturday, 9 February 2013 01:28:09 UTC, Jason Wolfe wrote:
>
>
>
> On Friday, February 8, 2013 1:56:27 AM UTC-8, Edmund wrote:
>>
>> Hey Jason,
>>
>>Going slightly OT here to describe my motivations, but you did ask
>> for more details ! :)
>>
>> I wrote a little blog post + lib last month using Stuart Sierra's Flow 
>> (much like
>> Graph) to implement the steps in doing a very simple discrete inference 
>> task.  Its
>> demonstrating the same thing you talk about in your post about
>> declarative computation - here the point is that you can efficiently 
>> update your
>> inference based new data on account of having the
>> graph structure to work over.  Here's the post 
>> http://boss-level.com/?p=160 and a
>> literate version of the code http://ejackson.github.com/inflow/
>> This is my original motivation.
>>
>
> I think I understand what you're trying to do from the example, thanks!
>  
>
>> What I'm doing there is 'building-up' the computation over time,
>> so I start with a graph with just the input data, and end up with a
>> graph with the input and output.  But the 'building up' is not the 
>> principal hangup I
>> have: I'm happy to have an in- and out- map.  The problem is, when
>> dealing with a very nested graph, getting a fine grained syntax for
>> describing where to put the outputs.  Ie how do I tell Graph to put just
>> the output x into
>> {:a {:b 1 :c x}} of the graph, without replacing the entire map of the :a 
>> key ?
>>
>
> Like I said earlier, it's a requirement of Graph that node names must be 
> unique, and distinct from top-level input keys. 
>
> Thus, there cannot be a way to 'put x into the map under :a at key :c' , 
> because there is no way to in-place modify the inputs or other node values 
> of the graph.  The output is just a map of all the node results, nothing 
> more and nothing less.
>
> That said, you can use a hierarchical graph to specify different node 
> functions for the different sub-keys:
>
> ;; As a hierarchical graph
> user> ((eager-compile {:a2 {:b (fnk [[:a1 b]] b) 
> :c (fnk [[:a1 b]] (inc b))}}) 
>{:a1 {:b 1}})
> {:a2 {:b 1, :c 2}}
>
> So for an example like the one you gave in the above link, you can 
> represent your nested stats directly as a nested graph without resorting to 
> key flattening.  And if you want to compute just a subset of the graph for 
> updated downstream values and then merge this into your previous map, you 
> can do this in two steps:
>
> 1.  Pick out the subset of leaf functions that may have changed, using the 
> same strategy you currently use with Flow, and construct a Graph with only 
> those sub-keys.  For example:
>
> user> ((eager-compile {:a2 {:b (fnk [[:a1 b]] b)}}) 
>{:a1 {:b 2}})
> {:a2 {:b 2}}
>
> , then 
>
> 2. deep-merge these results with the original result map.  
>
> i..e, (deep-merge-with (fn [x y] y) original-results updated-results)
> where deep-merge-with is 
> http://clojuredocs.org/clojure_contrib/clojure.contrib.map-utils/deep-merge-with
>
> This logic could be wrapped up into a single higher-order function that 
> takes a graph and knows how to incrementally update the results given 
> incremental changes in input.  Does that make sense / seem like it will 
> satisfy your need?
>
> Cheers, 
> Jason
>
>
>
>  
>
>> That's obviously no good if I need to have lots of things changing
>> beneath :a in a single graph flow due to uniqueness.[
>>
>> With Flow what I did is flatten the nested graph such that the keys are
>> vectors of the path to each node, run the flow on that graph, and then
>> re-nest the the graph afterwards (the flow-> and ->flow functions).
>> So the map {:a {:b 1 :c x}} becomes {[:a :b] 1, [:a :c] x}, and I can 
>> refer to
>> nested nodes this way.
>>
>> In Graph such a scheme would be possible too, but that Graph enforces
>> keywords as the keys for the graph.  Having vectors for the keys still
>> allows you to
>> have uniqueness, topological ordering etc.  So the example I gave in my
>> last email:
>>
>> {:a {:b 1}} -> {:a {:b 1, :c 2}}
>>
>> could, hypothetically, be written for just the outputs as
>>
>> ((graph/eager-compile {[:a :c] (fnk [[:a b]] (inc b))})
>>   {:a {:b 1}})
>>
>> >> {:a {:c 2}}
>>
>> So my question is: how do I refer to nested nodes in the output
>> selector using Graph?  Conditionally, on that being impossible, would
>> there be any merit in the vector scheme that I have suggested ?
>>
>> Sorry for the long post, I hope I haven't obscured my question. I also
>> get the feeling that I must be missing something very obvious in your
>> code for how to do this !
>>
>>  Edmund
>>
>>
>> On Thursday, 7 February 2013 19:27:13 UTC, Jason Wolfe wrote:
>>>
>>> On Thu, Feb 7, 2013 at 10:54 AM, AtKaaZ  wrote: 
>>> > Hello. 
>>> > 
>>> https://github.com/Prismatic/plumbing/blob/master/tes

Re: Building a REST API / efficient RPC interface in Clojure

[bernardH]

Hi,

On Saturday, February 9, 2013 4:47:26 AM UTC+1, Feng Shen wrote:
>
> Hi,  I did something similar during work (we are using Clojure)
>
>1. Use HTTP as the transport:  browser ajax call,  mobile API call, 
>intertal use
>2. JSON as encoding.  Javascript support it natively, mobile can 
>decode it easily,  Clojure has very good support for it
>
> Clojure can decode and encode json*[1]* very efficiently.  Nginx can be 
> configured to zip the data to save bandwidth.
>

I, for one,  would love to use fressian [*], for reasons explained by Rich 
Hickey [**]. Would you consider including this possibility in your lein 
template (which I'd very much like to use, considering the quality of your 
http-kit !)

As for REST, have you considered liberator [***] ?

Cheers,

Bernard

[*] https://github.com/Datomic/fressian
[**] 
http://skillsmatter.com/podcast/scala/the-language-of-the-system/mh-6213
[***] https://github.com/clojure-liberator/liberator

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

[vemv]

>
> Define an API in terms of messages 
>

I'm not familiar with the concept - just out of curiosity, what does a 
mesagge-based API consist of? Is the drastically different from most 
REST/JSON web APIs out there?

Thank you - Victor

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

[Takahiro Hozumi]

Thanks for amazing work!

I want to know how typical CRUD application is implemented.
Do you use single gigantic graph with lazy-compile or separated graph
for each operation?
How do you handle validation and error?
Will almost all x->y function disappear?

On Jan 30, 3:46 am, Aria Haghighi  wrote:
> Hey all,
>
>  Prismatic has open-sourced our Plumbing and Graph library on 
> github.
> Jason Wolfe gave a 
> talkabout
>  how we use graph for systems composition at Strange loop last year.
> Please give the library
> a whirl and let us know if you're using it and if you find any issues or
> feature requests. We use this library very heavily throughout our code and
> hope others find it useful as well.
>
>  Best, Aria

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

[vemv]

>
> I like the parentheses better. My only complaint is that I have to press 
> the shift key to type them.
>

You can always remap your keyboard / keyboard bindings. For example in 
emacs:

(define-key clojure-mode-map "9" 'paredit-open-round)

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

[Stuart Halloway]

+1 on this line of thought. We are definitely interested in decomplecting
dev mode utility from production lean-and-meanness.

One question along this path is "What options exist in Java/maven land for
doing multiple releases of the same artifact with e.g. different
performance and debugging characteristics, and how could these be
incorporated into the Clojure build in a transparent, easy-to-assess way?"

Answering the preceding question (or reframing it into a better question)
is not blocked waiting on anybody. Have at it!

Stu


On Fri, Feb 8, 2013 at 9:36 PM, Brian Marick  wrote:

>
> On Feb 8, 2013, at 7:56 PM, Daniel Glauser  wrote:
>
> >
> > This sounds like a great idea. I was working with some tests today and
> it would have been really useful to have some way to query the current
> function/execution context. Seems like passing that through all lets would
> go a long way, provided I'm reading this right.
>
> It would be very interesting to have a "maximally informative mode" and a
> "generate really tense code" mode. There is tradition behind such an idea.
>
> It would be especially interesting if the maximally informative mode had
> hooks tools could exploit. For example, Midje provides a hack where you can
> declare records in a way that the contained functions can be mocked:
> `defrecord-openly`. I expect almost no one uses it, even though it is no
> different than `defrecord` when in "production mode": it's too weird
> looking. But people would use it if ordinary defrecord methods weren't
> inlined during development.
>
> There's no *semantic* reason why parts of Clojure should *always* be
> closed to introspection-type actions. It's purely a matter of time
> constraints on the core team, which I am certainly not in a position to
> judge. How much core time should be spent on saving anonymous programmers
> time vs. saving cycles for anonymous apps running on the Amazon cloud? It's
> a tough tradeoff.
>
> 
> Looking for 1/2-time employment as a Clojure programmer
> Latest book: /Functional Programming for the Object-Oriented Programmer/
> https://leanpub.com/fp-oo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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: Simple Network Messaging

[Daniel Bryan]

There's any number of answers to this, but when I have to do IPC between 
different languages I send JSON messages over ZeroMQ sockets.

http://www.zeromq.org/

Pretty simple to use, implementations exist in almost all currently popular 
languages.

On Friday, February 8, 2013 8:44:06 AM UTC+11, JvJ wrote:
>
> I'm looking to do some simple messaging (json strings) between programs 
> running on the same machine.  One will be in C# and one will be in Clojure. 
>  Is there a library/set of libraries that could simplify this 
> communication?  I haven't done much networking in the past, and I'd like to 
> keep this as painless as possible.
>
> 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.

Re: `let` to automatically add metadata / fn names?

[Mark]

Going the build route, probably use maven to produce debug and production 
artifacts of differing versions:  blah-1.0.0-DEBUG.jar and blah-1.0.0.jar.  

Rather than go that route and the ensuing naming convention madness, I 
wonder how much we could rely on the JIT to push the decision of debug vs 
production to runtime?

On Saturday, February 9, 2013 6:31:10 AM UTC-8, stuart@gmail.com wrote:
>
> +1 on this line of thought. We are definitely interested in decomplecting 
> dev mode utility from production lean-and-meanness.
>
> One question along this path is "What options exist in Java/maven land for 
> doing multiple releases of the same artifact with e.g. different 
> performance and debugging characteristics, and how could these be 
> incorporated into the Clojure build in a transparent, easy-to-assess way?"
>
> Answering the preceding question (or reframing it into a better question) 
> is not blocked waiting on anybody. Have at it!
>
> Stu 
>
>
> On Fri, Feb 8, 2013 at 9:36 PM, Brian Marick 
> > wrote:
>
>>
>> On Feb 8, 2013, at 7:56 PM, Daniel Glauser > 
>> wrote:
>>
>> >
>> > This sounds like a great idea. I was working with some tests today and 
>> it would have been really useful to have some way to query the current 
>> function/execution context. Seems like passing that through all lets would 
>> go a long way, provided I'm reading this right.
>>
>> It would be very interesting to have a "maximally informative mode" and a 
>> "generate really tense code" mode. There is tradition behind such an idea.
>>
>> It would be especially interesting if the maximally informative mode had 
>> hooks tools could exploit. For example, Midje provides a hack where you can 
>> declare records in a way that the contained functions can be mocked: 
>> `defrecord-openly`. I expect almost no one uses it, even though it is no 
>> different than `defrecord` when in "production mode": it's too weird 
>> looking. But people would use it if ordinary defrecord methods weren't 
>> inlined during development.
>>
>> There's no *semantic* reason why parts of Clojure should *always* be 
>> closed to introspection-type actions. It's purely a matter of time 
>> constraints on the core team, which I am certainly not in a position to 
>> judge. How much core time should be spent on saving anonymous programmers 
>> time vs. saving cycles for anonymous apps running on the Amazon cloud? It's 
>> a tough tradeoff.
>>
>> 
>> Looking for 1/2-time employment as a Clojure programmer
>> Latest book: /Functional Programming for the Object-Oriented Programmer/
>> https://leanpub.com/fp-oo
>>
>> --
>> --
>> 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.

pr-str captures stdout- Is this intentional or a bug?

[Conrad]

I tested this in the latest 1.5.0-RC6:

=> (def k (pr-str (for [x (range 5)] 
 (do (pr x) 
  x
#'user/k
=> k
"(012340 1 2 3 4)"

This seems wrong to me... I can see what would be needed to fix it in 
clojure/core.clj, but it would require creating several additional private 
functions. Does anyone know if this behavior is intentional?

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

[AtKaaZ]

I think it's an illusion from being lazy ?
=> (def k (pr-str (vec (for [x (range 5)]
(do (pr x)
 x)
01234
#'datest1.ret/k
=> k
"[0 1 2 3 4]"



On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:

> I tested this in the latest 1.5.0-RC6:
>
> => (def k (pr-str (for [x (range 5)]
>  (do (pr x)
>   x
> #'user/k
> => k
> "(012340 1 2 3 4)"
>
> This seems wrong to me... I can see what would be needed to fix it in
> clojure/core.clj, but it would require creating several additional private
> functions. Does anyone know if this behavior is intentional?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

actually replacing vec with dorun or doall, would've been a better example
:)


On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ  wrote:

> I think it's an illusion from being lazy ?
> => (def k (pr-str (vec (for [x (range 5)]
> (do (pr x)
>  x)
> 01234
> #'datest1.ret/k
> => k
> "[0 1 2 3 4]"
>
>
>
> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>
>> I tested this in the latest 1.5.0-RC6:
>>
>> => (def k (pr-str (for [x (range 5)]
>>  (do (pr x)
>>   x
>> #'user/k
>> => k
>> "(012340 1 2 3 4)"
>>
>> This seems wrong to me... I can see what would be needed to fix it in
>> clojure/core.clj, but it would require creating several additional private
>> functions. Does anyone know if this behavior is intentional?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you 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.
>>
>>
>>
>
>
>
> --
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate it.
>
>


-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

here's a simpler example:
=> (map println '(1 2 3))
(1
2
nil 3
nil nil)
=> (dorun (map println '(1 2 3)))
1
2
3
nil



On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ  wrote:

> actually replacing vec with dorun or doall, would've been a better example
> :)
>
>
> On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ  wrote:
>
>> I think it's an illusion from being lazy ?
>> => (def k (pr-str (vec (for [x (range 5)]
>> (do (pr x)
>>  x)
>> 01234
>> #'datest1.ret/k
>> => k
>> "[0 1 2 3 4]"
>>
>>
>>
>> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>>
>>> I tested this in the latest 1.5.0-RC6:
>>>
>>> => (def k (pr-str (for [x (range 5)]
>>>  (do (pr x)
>>>   x
>>> #'user/k
>>> => k
>>> "(012340 1 2 3 4)"
>>>
>>> This seems wrong to me... I can see what would be needed to fix it in
>>> clojure/core.clj, but it would require creating several additional private
>>> functions. Does anyone know if this behavior is intentional?
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you 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.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Please correct me if I'm wrong or incomplete,
>> even if you think I'll subconsciously hate it.
>>
>>
>
>
> --
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate it.
>
>


-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: pr-str captures stdout- Is this intentional or a bug?

[Conrad]

I agree when you print to stdout you'd expect lazily evaluated output to be 
mangled in.

However, it would seem more natural to me that if you print something to a 
string it is counter intuitive for incidental writes to stdout to be 
redirected to the string, as well- There is also nothing in the 
documentation that suggests this would happen.

Also, it would be technically relatively easy to change this.

On Saturday, February 9, 2013 12:46:08 PM UTC-6, AtKaaZ wrote:
>
> here's a simpler example:
> => (map println '(1 2 3))
> (1
> 2
> nil 3
> nil nil)
> => (dorun (map println '(1 2 3)))
> 1
> 2
> 3
> nil
>
>
>
> On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ >wrote:
>
>> actually replacing vec with dorun or doall, would've been a better 
>> example :)
>>
>>
>> On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ >wrote:
>>
>>> I think it's an illusion from being lazy ?
>>> => (def k (pr-str (vec (for [x (range 5)] 
>>> (do (pr x) 
>>>  x)
>>> 01234
>>> #'datest1.ret/k
>>> => k
>>> "[0 1 2 3 4]"
>>>
>>>
>>>
>>> On Sat, Feb 9, 2013 at 7:30 PM, Conrad >> >wrote:
>>>
 I tested this in the latest 1.5.0-RC6:

 => (def k (pr-str (for [x (range 5)] 
  (do (pr x) 
   x
 #'user/k
 => k
 "(012340 1 2 3 4)"

 This seems wrong to me... I can see what would be needed to fix it in 
 clojure/core.clj, but it would require creating several additional private 
 functions. Does anyone know if this behavior is intentional?
  
 -- 
 -- 
 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.
  
  

>>>
>>>
>>>
>>> -- 
>>> Please correct me if I'm wrong or incomplete,
>>> even if you think I'll subconsciously hate it.
>>>
>>>  
>>
>>
>> -- 
>> Please correct me if I'm wrong or incomplete,
>> even if you think I'll subconsciously hate it.
>>
>>  
>
>
> -- 
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate 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: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

do you mean that, when the string it outputted  like:
=> (println k)
(012340 1 2 3 4)
nil
=> (prn k)
"(012340 1 2 3 4)"
nil

the side effects of evaluating k being mixed into the output could affect
you (other than just visually in the repl) ? if ie. you redirect *out* to
some file with the purpose of saving and later restoring that?

Well, I don't actually like this myself (ever since I've encountered the
map println example I've given) but I ignored it because people didn't seem
to find it a big deal and nothing I could do about it + it only affected me
in viewing REPL output.


But I'm not sure if it is clear to you what is happening (perhaps I
misunderstand what you're saying), it's only when showing the value of the
string (k in this case) that the text shown is mixed, but the value of k is
accurate, as seen below:
On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:

> I tested this in the latest 1.5.0-RC6:
>
> => (def k (pr-str (for [x (range 5)]
>  (do (pr x)
>   x
> #'user/k
> => k
> "(012340 1 2 3 4)"
>
=> (= "[0 1 2 3 4]" k)
true





On Sat, Feb 9, 2013 at 8:03 PM, Conrad  wrote:

> I agree when you print to stdout you'd expect lazily evaluated output to
> be mangled in.
>
> However, it would seem more natural to me that if you print something to a
> string it is counter intuitive for incidental writes to stdout to be
> redirected to the string, as well- There is also nothing in the
> documentation that suggests this would happen.
>
> Also, it would be technically relatively easy to change this.
>
> On Saturday, February 9, 2013 12:46:08 PM UTC-6, AtKaaZ wrote:
>
>> here's a simpler example:
>> => (map println '(1 2 3))
>> (1
>> 2
>> nil 3
>> nil nil)
>> => (dorun (map println '(1 2 3)))
>> 1
>> 2
>> 3
>> nil
>>
>>
>>
>> On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ  wrote:
>>
>>> actually replacing vec with dorun or doall, would've been a better
>>> example :)
>>>
>>>
>>> On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ  wrote:
>>>
 I think it's an illusion from being lazy ?
 => (def k (pr-str (vec (for [x (range 5)]
   **  (do (pr x)
   **   x)
 01234
 #'datest1.ret/k
 => k
 "[0 1 2 3 4]"



 On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:

> I tested this in the latest 1.5.0-RC6:
>
> => (def k (pr-str (for [x (range 5)]
>  (do (pr x)
>   x
> #'user/k
> => k
> "(012340 1 2 3 4)"
>
> This seems wrong to me... I can see what would be needed to fix it in
> clojure/core.clj, but it would require creating several additional private
> functions. Does anyone know if this behavior is intentional?
>
> --
> --
> 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
> .
>
>
>



 --
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.


>>>
>>>
>>> --
>>> Please correct me if I'm wrong or incomplete,
>>> even if you think I'll subconsciously hate it.
>>>
>>>
>>
>>
>> --
>> Please correct me if I'm wrong or incomplete,
>> even if you think I'll subconsciously hate 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

-- 
-- 
You received this message 

Re: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

On Sat, Feb 9, 2013 at 8:22 PM, AtKaaZ  wrote:

> do you mean that, when the string it outputted  like:
> => (println k)
>
> (012340 1 2 3 4)
> nil
> => (prn k)
>
> "(012340 1 2 3 4)"
> nil
>
> the side effects of evaluating k being mixed into the output could affect
> you (other than just visually in the repl) ? if ie. you redirect *out* to
> some file with the purpose of saving and later restoring that?
>
> Well, I don't actually like this myself (ever since I've encountered the
> map println example I've given) but I ignored it because people didn't seem
> to find it a big deal and nothing I could do about it + it only affected me
> in viewing REPL output.
>
>
> But I'm not sure if it is clear to you what is happening (perhaps I
> misunderstand what you're saying), it's only when showing the value of the
> string (k in this case) that the text shown is mixed, but the value of k is
> accurate, as seen below:
>
> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>
>> I tested this in the latest 1.5.0-RC6:
>>
>> => (def k (pr-str (for [x (range 5)]
>>  (do (pr x)
>>   x
>> #'user/k
>> => k
>> "(012340 1 2 3 4)"
>>
> => (= "[0 1 2 3 4]" k)
> true
>
OOps, I pasted the wrong one here (from the "vec" form)
But looks like I was wrong, and you were correct!!
=> (def k (pr-str (for [x (range 5)]
(do ;(pr x)
 x
#'user/k
=> k
"(0 1 2 3 4)"
=> (= "(0 1 2 3 4)" k)
true
=> (def k (pr-str (for [x (range 5)]
(do (pr x)
 x
#'user/k
=> (= "(0 1 2 3 4)" k)
false


>
>
>
>
>
> On Sat, Feb 9, 2013 at 8:03 PM, Conrad  wrote:
>
>> I agree when you print to stdout you'd expect lazily evaluated output to
>> be mangled in.
>>
>> However, it would seem more natural to me that if you print something to
>> a string it is counter intuitive for incidental writes to stdout to be
>> redirected to the string, as well- There is also nothing in the
>> documentation that suggests this would happen.
>>
>> Also, it would be technically relatively easy to change this.
>>
>> On Saturday, February 9, 2013 12:46:08 PM UTC-6, AtKaaZ wrote:
>>
>>> here's a simpler example:
>>> => (map println '(1 2 3))
>>> (1
>>> 2
>>> nil 3
>>> nil nil)
>>> => (dorun (map println '(1 2 3)))
>>> 1
>>> 2
>>> 3
>>> nil
>>>
>>>
>>>
>>> On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ  wrote:
>>>
  actually replacing vec with dorun or doall, would've been a better
 example :)


 On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ  wrote:

> I think it's an illusion from being lazy ?
> => (def k (pr-str (vec (for [x (range 5)]
>   **  (do (pr x)
>   **   x)
> 01234
> #'datest1.ret/k
> => k
> "[0 1 2 3 4]"
>
>
>
> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>
>> I tested this in the latest 1.5.0-RC6:
>>
>> => (def k (pr-str (for [x (range 5)]
>>  (do (pr x)
>>   x
>> #'user/k
>> => k
>> "(012340 1 2 3 4)"
>>
>> This seems wrong to me... I can see what would be needed to fix it in
>> clojure/core.clj, but it would require creating several additional 
>> private
>> functions. Does anyone know if this behavior is intentional?
>>
>> --
>> --
>> 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
>> .
>>
>>
>>
>
>
>
> --
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate it.
>
>


 --
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.


>>>
>>>
>>> --
>>> Please correct me if I'm wrong or incomplete,
>>> even if you think I'll subconsciously hate 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

Re: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

On Sat, Feb 9, 2013 at 8:25 PM, AtKaaZ  wrote:

>
>
>
> On Sat, Feb 9, 2013 at 8:22 PM, AtKaaZ  wrote:
>
>> do you mean that, when the string it outputted  like:
>> => (println k)
>>
>> (012340 1 2 3 4)
>> nil
>> => (prn k)
>>
>> "(012340 1 2 3 4)"
>> nil
>>
>> the side effects of evaluating k being mixed into the output could affect
>> you (other than just visually in the repl) ? if ie. you redirect *out* to
>> some file with the purpose of saving and later restoring that?
>>
>> Well, I don't actually like this myself (ever since I've encountered the
>> map println example I've given) but I ignored it because people didn't seem
>> to find it a big deal and nothing I could do about it + it only affected me
>> in viewing REPL output.
>>
>>
>> But I'm not sure if it is clear to you what is happening (perhaps I
>> misunderstand what you're saying), it's only when showing the value of the
>> string (k in this case) that the text shown is mixed, but the value of k is
>> accurate, as seen below:
>>
>> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>>
>>> I tested this in the latest 1.5.0-RC6:
>>>
>>> => (def k (pr-str (for [x (range 5)]
>>>  (do (pr x)
>>>   x
>>> #'user/k
>>> => k
>>> "(012340 1 2 3 4)"
>>>
>> => (= "[0 1 2 3 4]" k)
>> true
>>
> OOps, I pasted the wrong one here (from the "vec" form)
> But looks like I was wrong, and you were correct!!
>
> => (def k (pr-str (for [x (range 5)]
> (do ;(pr x)
>  x
> #'user/k
> => k
> "(0 1 2 3 4)"
> => (= "(0 1 2 3 4)" k)
> true
>
> => (def k (pr-str (for [x (range 5)]
> (do (pr x)
>  x
> #'user/k
> => (= "(0 1 2 3 4)" k)
> false
>
=> (= "(012340 1 2 3 4)" k)
true

so it's not exactly like the example that I've given... I'll have to
investigate more

>
>
>>
>>
>>
>>
>>
>> On Sat, Feb 9, 2013 at 8:03 PM, Conrad  wrote:
>>
>>> I agree when you print to stdout you'd expect lazily evaluated output to
>>> be mangled in.
>>>
>>> However, it would seem more natural to me that if you print something to
>>> a string it is counter intuitive for incidental writes to stdout to be
>>> redirected to the string, as well- There is also nothing in the
>>> documentation that suggests this would happen.
>>>
>>> Also, it would be technically relatively easy to change this.
>>>
>>> On Saturday, February 9, 2013 12:46:08 PM UTC-6, AtKaaZ wrote:
>>>
 here's a simpler example:
 => (map println '(1 2 3))
 (1
 2
 nil 3
 nil nil)
 => (dorun (map println '(1 2 3)))
 1
 2
 3
 nil



 On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ  wrote:

>  actually replacing vec with dorun or doall, would've been a better
> example :)
>
>
> On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ  wrote:
>
>> I think it's an illusion from being lazy ?
>> => (def k (pr-str (vec (for [x (range 5)]
>>   **  (do (pr x)
>>   **   x)
>> 01234
>> #'datest1.ret/k
>> => k
>> "[0 1 2 3 4]"
>>
>>
>>
>> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>>
>>> I tested this in the latest 1.5.0-RC6:
>>>
>>> => (def k (pr-str (for [x (range 5)]
>>>  (do (pr x)
>>>   x
>>> #'user/k
>>> => k
>>> "(012340 1 2 3 4)"
>>>
>>> This seems wrong to me... I can see what would be needed to fix it
>>> in clojure/core.clj, but it would require creating several additional
>>> private functions. Does anyone know if this behavior is intentional?
>>>
>>> --
>>> --
>>> 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
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> Please correct me if I'm wrong or incomplete,
>> even if you think I'll subconsciously hate it.
>>
>>
>
>
> --
> Please correct me if I'm wrong or incomplete,
> even if you 

Re: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

So, I basically thought that this is what's happening in your case also
(but it's not!):
=> (map println '(1 2 3))
(1
2
nil 3
nil nil)
=> (= '(nil nil nil) (map println '(1 2 3)))
1
2
3
true

;so your case is different due to pr-str and pr

=> (def k (pr-str (for [x (range 5)]
(do (pr x)
 x
#'user/k
=> k
"(012340 1 2 3 4)"
=> (= "(012340 1 2 3 4)" k)
true

Sorry for the noise, indeed it seems like pr-str is just redirecting *out*
until done using with-out-str.
This is certainly much more severe that I thought initially.

=> (def k (pr-str (for [x (range 5)]
   (do (pr x)
 (println "nothing")
x
#'user/k
=> k
"(0nothing\r\n1nothing\r\n2nothing\r\n3nothing\r\n4nothing\r\n0 1 2 3 4)"
=> (= "(0nothing\r\n1nothing\r\n2nothing\r\n3nothing\r\n4nothing\r\n0 1 2 3
4)" k)
true

This is so bad :)


On Sat, Feb 9, 2013 at 8:26 PM, AtKaaZ  wrote:

>
>
>
> On Sat, Feb 9, 2013 at 8:25 PM, AtKaaZ  wrote:
>
>>
>>
>>
>> On Sat, Feb 9, 2013 at 8:22 PM, AtKaaZ  wrote:
>>
>>> do you mean that, when the string it outputted  like:
>>> => (println k)
>>>
>>> (012340 1 2 3 4)
>>> nil
>>> => (prn k)
>>>
>>> "(012340 1 2 3 4)"
>>> nil
>>>
>>> the side effects of evaluating k being mixed into the output could
>>> affect you (other than just visually in the repl) ? if ie. you redirect
>>> *out* to some file with the purpose of saving and later restoring that?
>>>
>>> Well, I don't actually like this myself (ever since I've encountered the
>>> map println example I've given) but I ignored it because people didn't seem
>>> to find it a big deal and nothing I could do about it + it only affected me
>>> in viewing REPL output.
>>>
>>>
>>> But I'm not sure if it is clear to you what is happening (perhaps I
>>> misunderstand what you're saying), it's only when showing the value of the
>>> string (k in this case) that the text shown is mixed, but the value of k is
>>> accurate, as seen below:
>>>
>>> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>>>
 I tested this in the latest 1.5.0-RC6:

 => (def k (pr-str (for [x (range 5)]
  (do (pr x)
   x
 #'user/k
 => k
 "(012340 1 2 3 4)"

>>> => (= "[0 1 2 3 4]" k)
>>> true
>>>
>> OOps, I pasted the wrong one here (from the "vec" form)
>> But looks like I was wrong, and you were correct!!
>>
>> => (def k (pr-str (for [x (range 5)]
>> (do ;(pr x)
>>  x
>> #'user/k
>>  => k
>> "(0 1 2 3 4)"
>> => (= "(0 1 2 3 4)" k)
>> true
>>
>> => (def k (pr-str (for [x (range 5)]
>> (do (pr x)
>>  x
>> #'user/k
>> => (= "(0 1 2 3 4)" k)
>> false
>>
> => (= "(012340 1 2 3 4)" k)
> true
>
> so it's not exactly like the example that I've given... I'll have to
> investigate more
>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Feb 9, 2013 at 8:03 PM, Conrad  wrote:
>>>
 I agree when you print to stdout you'd expect lazily evaluated output
 to be mangled in.

 However, it would seem more natural to me that if you print something
 to a string it is counter intuitive for incidental writes to stdout to be
 redirected to the string, as well- There is also nothing in the
 documentation that suggests this would happen.

 Also, it would be technically relatively easy to change this.

 On Saturday, February 9, 2013 12:46:08 PM UTC-6, AtKaaZ wrote:

> here's a simpler example:
> => (map println '(1 2 3))
> (1
> 2
> nil 3
> nil nil)
> => (dorun (map println '(1 2 3)))
> 1
> 2
> 3
> nil
>
>
>
> On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ  wrote:
>
>>  actually replacing vec with dorun or doall, would've been a better
>> example :)
>>
>>
>> On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ  wrote:
>>
>>> I think it's an illusion from being lazy ?
>>> => (def k (pr-str (vec (for [x (range 5)]
>>>   **  (do (pr x)
>>>   **   x)
>>> 01234
>>> #'datest1.ret/k
>>> => k
>>> "[0 1 2 3 4]"
>>>
>>>
>>>
>>> On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:
>>>
 I tested this in the latest 1.5.0-RC6:

 => (def k (pr-str (for [x (range 5)]
  (do (pr x)
   x
 #'user/k
 => k
 "(012340 1 2 3 4)"

 This seems wrong to me... I can see what would be needed to fix it
 in clojure/core.clj, but it would require creating several additional
 private functions. Does anyone know if this behavior is intentional?

 --
 --
 You rec

Global variables in closure ?

[Bogdan Valentin Neacsa]

Hello,

I'm a total beginer in Clojure and I've ran into a problem that I'm not 
even sure if can be done in Closure. 

So the issue is the following. I've implemeted a function that computes the 
prime numbers from an interval (up to a limit). 

(defn gather_primes_in_range [range_start range_end target_number 
prime_list]
(if (or (= 0 target_number) (> range_start range_end) (= FIND_MORE_PRIMES 
false)) 
prime_list
(do
(if (is_prime? range_start)
(gather_primes_in_range (+ range_start 1) range_end (- target_number 1) 
(conj, prime_list, range_start))
(gather_primes_in_range (+ range_start 1) range_end target_number 
prime_list)
)
)
)
)

(defn find_nr_of_primes_in_range [range_start range_end target_number]
(if (< range_start 2)
(gather_primes_in_range 2 range_end target_number [])
(gather_primes_in_range range_start range_end target_number [])
)
)

This works just fine. But what I want now is to have a global variable that 
should store on each method call the primes that are found in a variable to 
lookup later. In other languages like Python, Ruby or Scala I would just do 
this by having a Set to which I add entries before returing from the 
function. But in Clojure I have no ideea how to go around this. 

Basically what I tried is, have somewhere global declared:

(def PRIMES_FOUND_SO_FAR #{})

And then somehow on return add the entries to this variable. Is this 
possible at all in Clojure and if so how? I've tried on other variables to 
change their values using either swap! and atom, or set! but could not make 
it to work here in any situation.

Best regards,
Bogdan

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

Clojure 1.5 RC 14

[Stuart Halloway]

Clojure 1.5 RC 14 (fourteen) will be available soon from Maven Central:

http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0*

Please test it!

Thanks,
Stu

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

[AtKaaZ]

Hi Stu. All I see is
beta13as
being last (9 feb), and RC6 05-Feb-2013


On Sat, Feb 9, 2013 at 9:13 PM, Stuart Halloway
wrote:

> Clojure 1.5 RC 14 (fourteen) will be available soon from Maven Central:
>
>
> http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0*
>
> Please test it!
>
> Thanks,
> Stu
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: Clojure 1.5 RC 14

[Steve Miner]

Maybe the registry has caught up with the updates yet.  Leiningen found RC 14.

% lein deps
Retrieving org/clojure/clojure/1.5.0-RC14/clojure-1.5.0-RC14.pom from 
sonatype-oss-public
Retrieving org/clojure/clojure/1.5.0-RC14/clojure-1.5.0-RC14.jar from 
sonatype-oss-public


On Feb 9, 2013, at 3:29 PM, AtKaaZ  wrote:

> Hi Stu. All I see is beta13 as being last (9 feb), and RC6 05-Feb-2013
> 

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

[AtKaaZ]

thanks, obviously after I posted that I re-read Stu's post and "will be
available soon" made me realize how superficially I read his post.

lein deps
Could not find artifact org.clojure:clojure:jar:1.5.0-RC14 in central (
http://repo1.maven.org/maven2/)
Could not find artifact org.clojure:clojure:jar:1.5.0-RC14 in clojars (
https://clojars.org/repo/)
This could be due to a typo in :dependencies or network issues.
Could not resolve dependencies

I added:

:repositories {"sonatype-oss-public"
   "https://oss.sonatype.org/content/groups/public/"}

;and it works now



On Sat, Feb 9, 2013 at 10:06 PM, Steve Miner  wrote:

> Maybe the registry has caught up with the updates yet.  Leiningen found RC
> 14.
>
> % lein deps
> Retrieving org/clojure/clojure/1.5.0-RC14/clojure-1.5.0-RC14.pom from
> sonatype-oss-public
> Retrieving org/clojure/clojure/1.5.0-RC14/clojure-1.5.0-RC14.jar from
> sonatype-oss-public
>
>
> On Feb 9, 2013, at 3:29 PM, AtKaaZ  wrote:
>
> Hi Stu. All I see is 
> beta13
>  as being last (9 feb), and RC6 05-Feb-2013
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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.

delete-file implementation (?!)

[AtKaaZ]

Hi, does anyone see anything wrong with this?

=> (source clojure.java.io/delete-file)
(defn delete-file
  "Delete file f. Raise an exception if it fails unless silently is true."
  {:added "1.2"}
  [f & [silently]]
  (or (.delete (file f))
  silently
  (throw (java.io.IOException. (str "Couldn't delete " f)
nil

If you don't already, see below:

=> (.delete (q/newClass java.io.File "a.tx1"))
false
=> (.delete (q/newClass java.io.File "c:\\a.tx1"))
true

=> (clojure.java.io/delete-file (new java.io.File "c:\\a.tx1"))
IOException Couldn't delete c:\a.tx1  clojure.java.io/delete-file(io.clj:425)
=> (clojure.java.io/delete-file (new java.io.File "c:\\a.tx1") true)
true
=> (clojure.java.io/delete-file (new java.io.File "c:\\a.tx1") 1)
1

Yep, I do need it to return the true/false status from .delete
fix?

=> *clojure-version*
{:major 1, :minor 5, :incremental 0, :qualifier "RC14"}




-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: pr-str captures stdout- Is this intentional or a bug?

[Conrad]

OK, if I follow your posts correctly you now agree with me that this is 
unpleasant behavior :-)

On Saturday, February 9, 2013 1:35:48 PM UTC-6, AtKaaZ wrote:
>
> So, I basically thought that this is what's happening in your case also 
> (but it's not!):
> => (map println '(1 2 3))
> (1
> 2
> nil 3
> nil nil)
> => (= '(nil nil nil) (map println '(1 2 3)))
> 1
> 2
> 3
> true
>
> ;so your case is different due to pr-str and pr 
>
> => (def k (pr-str (for [x (range 5)] 
> (do (pr x) 
>  x
> #'user/k
> => k
> "(012340 1 2 3 4)"
> => (= "(012340 1 2 3 4)" k)
> true
>
> Sorry for the noise, indeed it seems like pr-str is just redirecting *out* 
> until done using with-out-str.
> This is certainly much more severe that I thought initially.
>
> => (def k (pr-str (for [x (range 5)]
>(do (pr x)
>  (println "nothing")
> x
> #'user/k
> => k
> "(0nothing\r\n1nothing\r\n2nothing\r\n3nothing\r\n4nothing\r\n0 1 2 3 4)"
> => (= "(0nothing\r\n1nothing\r\n2nothing\r\n3nothing\r\n4nothing\r\n0 1 2 
> 3 4)" k)
> true
>
> This is so bad :)
>
>
> On Sat, Feb 9, 2013 at 8:26 PM, AtKaaZ >wrote:
>
>>
>>
>>
>> On Sat, Feb 9, 2013 at 8:25 PM, AtKaaZ >wrote:
>>
>>>
>>>
>>>
>>> On Sat, Feb 9, 2013 at 8:22 PM, AtKaaZ >> >wrote:
>>>
 do you mean that, when the string it outputted  like:
 => (println k)

 (012340 1 2 3 4)
 nil
 => (prn k)

 "(012340 1 2 3 4)"
 nil

 the side effects of evaluating k being mixed into the output could 
 affect you (other than just visually in the repl) ? if ie. you redirect 
 *out* to some file with the purpose of saving and later restoring that?

 Well, I don't actually like this myself (ever since I've encountered 
 the map println example I've given) but I ignored it because people didn't 
 seem to find it a big deal and nothing I could do about it + it only 
 affected me in viewing REPL output.


 But I'm not sure if it is clear to you what is happening (perhaps I 
 misunderstand what you're saying), it's only when showing the value of the 
 string (k in this case) that the text shown is mixed, but the value of k 
 is 
 accurate, as seen below:

 On Sat, Feb 9, 2013 at 7:30 PM, Conrad >>> >wrote:

> I tested this in the latest 1.5.0-RC6:
>
> => (def k (pr-str (for [x (range 5)] 
>  (do (pr x) 
>   x
> #'user/k
> => k
> "(012340 1 2 3 4)"
>
 => (= "[0 1 2 3 4]" k)
 true

>>> OOps, I pasted the wrong one here (from the "vec" form)
>>> But looks like I was wrong, and you were correct!!
>>>
>>> => (def k (pr-str (for [x (range 5)] 
>>> (do ;(pr x) 
>>>  x
>>> #'user/k
>>>  => k
>>> "(0 1 2 3 4)"
>>> => (= "(0 1 2 3 4)" k)
>>> true
>>>
>>> => (def k (pr-str (for [x (range 5)] 
>>> (do (pr x) 
>>>  x
>>> #'user/k
>>> => (= "(0 1 2 3 4)" k)
>>> false
>>>
>> => (= "(012340 1 2 3 4)" k)
>> true
>>
>> so it's not exactly like the example that I've given... I'll have to 
>> investigate more 
>>
>>>  
>>>  
  




 On Sat, Feb 9, 2013 at 8:03 PM, Conrad >>> >wrote:

> I agree when you print to stdout you'd expect lazily evaluated output 
> to be mangled in.
>
> However, it would seem more natural to me that if you print something 
> to a string it is counter intuitive for incidental writes to stdout to be 
> redirected to the string, as well- There is also nothing in the 
> documentation that suggests this would happen.
>
> Also, it would be technically relatively easy to change this.
>
> On Saturday, February 9, 2013 12:46:08 PM UTC-6, AtKaaZ wrote:
>
>> here's a simpler example:
>> => (map println '(1 2 3))
>> (1
>> 2
>> nil 3
>> nil nil)
>> => (dorun (map println '(1 2 3)))
>> 1
>> 2
>> 3
>> nil
>>
>>  
>>
>> On Sat, Feb 9, 2013 at 7:44 PM, AtKaaZ  wrote:
>>
>>>  actually replacing vec with dorun or doall, would've been a better 
>>> example :)
>>>
>>>
>>> On Sat, Feb 9, 2013 at 7:42 PM, AtKaaZ  wrote:
>>>
 I think it's an illusion from being lazy ?
 => (def k (pr-str (vec (for [x (range 5)] 
   **  (do (pr x) 
   **   x)
 01234
 #'datest1.ret/k
 => k
 "[0 1 2 3 4]"



 On Sat, Feb 9, 2013 at 7:30 PM, Conrad  wrote:

> I tested this in the latest 1.5.0-RC6:
>
> => (def k (pr-str (for [x (range 5)] 
>  

Re: pr-str captures stdout- Is this intentional or a bug?

[Conrad]

For those reading this, the issue is NOT that output in the REPL looks 
funny. The problem is that if, for instance, you put debug code into a 
chunk of code that makes use of "pr-str" your debug code is actually 
WRITTEN TO THE STRING. This is because "pr-str" works by using 
"with-out-str". This seems clumsy and is undocumented IMHO and I am 
wondering if other people feel the same.

On Saturday, February 9, 2013 12:30:20 PM UTC-6, Conrad wrote:
>
> I tested this in the latest 1.5.0-RC6:
>
> => (def k (pr-str (for [x (range 5)] 
>  (do (pr x) 
>   x
> #'user/k
> => k
> "(012340 1 2 3 4)"
>
> This seems wrong to me... I can see what would be needed to fix it in 
> clojure/core.clj, but it would require creating several additional private 
> functions. Does anyone know if this behavior is intentional?
>

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

[Chas Emerick]

Hi all,

It looks like Rich has selected an approach to addressing *read-eval*, #=, and 
related issues.  The sands may still be shifting a bit, but far less than e.g. 
earlier this week.  With that in mind, I thought it might be helpful to point 
to three authoritative messages from the clojure-dev ML that describe various 
relevant changes and additions coming in 1.5.0.  The first one contains a 
summary of the general principles involved, but note that the "default mode" 
described therein didn't last, as described in the second message:

http://groups.google.com/group/clojure-dev/msg/786c689b596bb6a3
http://groups.google.com/group/clojure-dev/msg/f299efc525f096e2
http://groups.google.com/group/clojure-dev/msg/8b572b8ebaba2ff5

Most relevant to the tactical concern of this thread (the default value of 
*read-eval* and its implications) is the new ability to set that default via a 
Java system property.

Hopefully the above satiates anyone yearning for news on this topic until the 
1.5.0 changelog is updated to reflect the relevant changes.

Finally, I just wanted to thank everyone, for your attention, energy, 
enthusiasm, and brilliance.  It's an honor to be among you.

Cheers,

- Chas

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

[Aaron Bedra]

I just pulled it down locally and got the dreaded PermGen…

 [java] java.lang.OutOfMemoryError: PermGen space
 [java] at 
clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
 [java] at clojure.lang.AFn.applyToHelper(AFn.java:161)
 [java] at clojure.lang.AFn.applyTo(AFn.java:151)
 [java] at clojure.core$apply.invoke(core.clj:617)
 [java] at 
clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
 [java] at 
clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
 [java] at 
clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
 [java] at 
clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
 [java] at 
clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
 [java] at clojure.lang.AFn.call(AFn.java:18)
 [java] at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 [java] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 [java] at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 [java] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 [java] at java.lang.Thread.run(Thread.java:680)
 [java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see ex-data 
{:printed [#inst "2034-04-17T21:03:17.620-00:00" #inst 
"1979-04-19T20:14:07.477-00:00" #inst "1996-06-20T05:47:52.868-00:00" #inst 
"1995-08-15T20:51:41.920-00:00" #inst "2029-05-17T14:34:37.906-00:00" #inst 
"1987-06-05T21:05:23.305-00:00" #inst "1994-06-29T16:17:24.459-00:00" #inst 
"2035-12-03T09:39:44.754-00:00" #inst "2040-01-31T09:47:29.774-00:00" #inst 
"1973-06-09T04:53:42.029-00:00" #inst "1996-12-23T17:26:25.607-00:00" #inst 
"2022-07-01T16:33:57.846-00:00" #inst "1998-10-01T00:21:09.895-00:00" #inst 
"1973-01-11T17:43:58.457-00:00" #inst "1988-11-03T22:46:53.468-00:00" #inst 
"1982-01-31T11:34:19.796-00:00" #inst "2011-11-11T10:59:23.168-00:00" #inst 
"1973-06-07T12:37:22.285-00:00" #inst "1977-12-15T03:32:20.215-00:00" #inst 
"2047-10-15T13:51:28.327-00:00" #inst "2007-12-16T05:50:59.539-00:00" #inst 
"1980-05-01T01:58:13.802-00:00" #inst "1980-01-30T04:31:20.418-00:00" #inst 
"2044-09-16T14:38:34.919-00:00" #inst "1980-08-05T18:06:50.589-00:00" #inst 
"1978-12-31T11:40:11.800-00:00" #inst "2015-05-08T15:03:27.594-00:00" #inst 
"1975-06-28T17:24:08.855-00:00" #inst "1975-06-09T07:22:42.892-00:00" #inst 
"2026-03-20T07:01:01.296-00:00" #inst "2053-02-02T01:33:45.525-00:00" #inst 
"2002-04-11T18:43:38.347-00:00" #inst "1992-12-10T13:33:55.048-00:00" #inst 
"2015-04-16T20:53:45.670-00:00" #inst "2013-12-23T20:16:07.506-00:00" #inst 
"1978-09-02T09:42:03.175-00:00" #inst "1980-06-29T00:54:55.361-00:00" #inst 
"2061-11-04T22:40:32.484-00:00" #inst "2190-06-05T04:42:38.638-00:00" #inst 
"2038-03-19T09:05:50.002-00:00" #inst "2033-08-08T13:48:51.747-00:00" #inst 
"2077-11-18T06:09:19.557-00:00" #inst "1997-02-07T14:02:27.410-00:00" #inst 
"1988-08-20T07:11:32.623-00:00" #inst "1981-12-06T05:48:21.787-00:00" #inst 
"1980-08-15T09:40:38.877-00:00" #inst "2022-01-19T16:23:06.638-00:00" #inst 
"1994-09-09T17:35:55.052-00:00" #inst "1989-09-14T07:24:38.880-00:00" #inst 
"2050-03-30T21:22:42.054-00:00" #inst "2071-10-09T20:37:08.430-00:00" #inst 
"2083-04-19T10:25:43.108-00:00" #inst "1978-09-09T18:28:22.366-00:00" #inst 
"1979-11-03T08:18:42.779-00:00" #inst "1975-10-24T00:59:58.497-00:00" #inst 
"1974-10-10T14:40:29.360-00:00" #inst "1999-07-14T07:47:47.220-00:00" #inst 
"2215-11-23T00:36:40.748-00:00" #inst "2077-02-14T19:40:22.712-00:00" #inst 
"1985-03-14T12:30:49.064-00:00" #inst "2021-08-26T20:51:15.030-00:00" #inst 
"2013-04-22T10:48:12.278-00:00" #inst "2019-08-31T17:31:05.195-00:00" #inst 
"1975-04-21T22:13:33.370-00:00" #inst "1984-09-10T23:30:15.313-00:00" #inst 
"2053-11-10T05:36:02.093-00:00" #inst "1974-01-05T15:17:02.286-00:00" #inst 
"2058-09-18T08:11:45.895-00:00" #inst "1987-10-26T13:15:29.968-00:00" #inst 
"2001-10-01T08:12:45.877-00:00" #inst "2003-05-29T15:17:24.449-00:00" #inst 
"1981-02-07T01:20:10.665-00:00" #inst "1972-02-20T03:11:10.395-00:00" #inst 
"1971-05-15T02:20:31.099-00:00" #inst "1998-07-14T19:05:58.450-00:00" #inst 
"2003-11-20T14:15:43.535-00:00" #inst "2032-11-06T18:16:34.702-00:00" #inst 
"1974-09-12T12:12:41.530-00:00" #inst "1971-01-16T05:00:36.536-00:00" #inst 
"1997-04-22T20:01:48.046-00:00" #inst "1980-02-10T15:10:37.905-00:00" #inst 
"1978-05-09T10:52:42.400-00:00" #inst "1991-03-04T00:27:15.926-00:00" #inst 
"1993-12-10T20:33:14.714-00:00" #inst "2045-04-04T10:42:38.474-00:00" #inst 
"1972-05-30T18:17:49.692-00:00" #inst "1986-03-14T02:42:42.374-00:00" #inst 
"2096-01-05T11:11:23.974-00:00" #inst "1997-12-03T18:50:28.444-00:00" #inst 
"2009-05-12T23:48:54.862-00:00" #inst "2026-02-16T11:51:39.884-00:00" #inst 
"1978-07-24T14:57:30.134-00:00" #inst "2003-08-21T2

Re: Clojure 1.5 RC 14

[AtKaaZ]

maybe jvm arg would help
-XX:MaxPermSize=256m



On Sat, Feb 9, 2013 at 11:17 PM, Aaron Bedra  wrote:

> I just pulled it down locally and got the dreaded PermGen…
>
>  [java] java.lang.OutOfMemoryError: PermGen space
>  [java] at
> clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
>  [java] at clojure.lang.AFn.applyToHelper(AFn.java:161)
>  [java] at clojure.lang.AFn.applyTo(AFn.java:151)
>  [java] at clojure.core$apply.invoke(core.clj:617)
>  [java] at
> clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
>  [java] at
> clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
>  [java] at
> clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
>  [java] at
> clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
>  [java] at
> clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
>  [java] at clojure.lang.AFn.call(AFn.java:18)
>  [java] at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>  [java] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>  [java] at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>  [java] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>  [java] at java.lang.Thread.run(Thread.java:680)
>  [java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see
> ex-data {:printed [#inst "2034-04-17T21:03:17.620-00:00" #inst
> "1979-04-19T20:14:07.477-00:00" #inst "1996-06-20T05:47:52.868-00:00" #inst
> "1995-08-15T20:51:41.920-00:00" #inst "2029-05-17T14:34:37.906-00:00" #inst
> "1987-06-05T21:05:23.305-00:00" #inst "1994-06-29T16:17:24.459-00:00" #inst
> "2035-12-03T09:39:44.754-00:00" #inst "2040-01-31T09:47:29.774-00:00" #inst
> "1973-06-09T04:53:42.029-00:00" #inst "1996-12-23T17:26:25.607-00:00" #inst
> "2022-07-01T16:33:57.846-00:00" #inst "1998-10-01T00:21:09.895-00:00" #inst
> "1973-01-11T17:43:58.457-00:00" #inst "1988-11-03T22:46:53.468-00:00" #inst
> "1982-01-31T11:34:19.796-00:00" #inst "2011-11-11T10:59:23.168-00:00" #inst
> "1973-06-07T12:37:22.285-00:00" #inst "1977-12-15T03:32:20.215-00:00" #inst
> "2047-10-15T13:51:28.327-00:00" #inst "2007-12-16T05:50:59.539-00:00" #inst
> "1980-05-01T01:58:13.802-00:00" #inst "1980-01-30T04:31:20.418-00:00" #inst
> "2044-09-16T14:38:34.919-00:00" #inst "1980-08-05T18:06:50.589-00:00" #inst
> "1978-12-31T11:40:11.800-00:00" #inst "2015-05-08T15:03:27.594-00:00" #inst
> "1975-06-28T17:24:08.855-00:00" #inst "1975-06-09T07:22:42.892-00:00" #inst
> "2026-03-20T07:01:01.296-00:00" #inst "2053-02-02T01:33:45.525-00:00" #inst
> "2002-04-11T18:43:38.347-00:00" #inst "1992-12-10T13:33:55.048-00:00" #inst
> "2015-04-16T20:53:45.670-00:00" #inst "2013-12-23T20:16:07.506-00:00" #inst
> "1978-09-02T09:42:03.175-00:00" #inst "1980-06-29T00:54:55.361-00:00" #inst
> "2061-11-04T22:40:32.484-00:00" #inst "2190-06-05T04:42:38.638-00:00" #inst
> "2038-03-19T09:05:50.002-00:00" #inst "2033-08-08T13:48:51.747-00:00" #inst
> "2077-11-18T06:09:19.557-00:00" #inst "1997-02-07T14:02:27.410-00:00" #inst
> "1988-08-20T07:11:32.623-00:00" #inst "1981-12-06T05:48:21.787-00:00" #inst
> "1980-08-15T09:40:38.877-00:00" #inst "2022-01-19T16:23:06.638-00:00" #inst
> "1994-09-09T17:35:55.052-00:00" #inst "1989-09-14T07:24:38.880-00:00" #inst
> "2050-03-30T21:22:42.054-00:00" #inst "2071-10-09T20:37:08.430-00:00" #inst
> "2083-04-19T10:25:43.108-00:00" #inst "1978-09-09T18:28:22.366-00:00" #inst
> "1979-11-03T08:18:42.779-00:00" #inst "1975-10-24T00:59:58.497-00:00" #inst
> "1974-10-10T14:40:29.360-00:00" #inst "1999-07-14T07:47:47.220-00:00" #inst
> "2215-11-23T00:36:40.748-00:00" #inst "2077-02-14T19:40:22.712-00:00" #inst
> "1985-03-14T12:30:49.064-00:00" #inst "2021-08-26T20:51:15.030-00:00" #inst
> "2013-04-22T10:48:12.278-00:00" #inst "2019-08-31T17:31:05.195-00:00" #inst
> "1975-04-21T22:13:33.370-00:00" #inst "1984-09-10T23:30:15.313-00:00" #inst
> "2053-11-10T05:36:02.093-00:00" #inst "1974-01-05T15:17:02.286-00:00" #inst
> "2058-09-18T08:11:45.895-00:00" #inst "1987-10-26T13:15:29.968-00:00" #inst
> "2001-10-01T08:12:45.877-00:00" #inst "2003-05-29T15:17:24.449-00:00" #inst
> "1981-02-07T01:20:10.665-00:00" #inst "1972-02-20T03:11:10.395-00:00" #inst
> "1971-05-15T02:20:31.099-00:00" #inst "1998-07-14T19:05:58.450-00:00" #inst
> "2003-11-20T14:15:43.535-00:00" #inst "2032-11-06T18:16:34.702-00:00" #inst
> "1974-09-12T12:12:41.530-00:00" #inst "1971-01-16T05:00:36.536-00:00" #inst
> "1997-04-22T20:01:48.046-00:00" #inst "1980-02-10T15:10:37.905-00:00" #inst
> "1978-05-09T10:52:42.400-00:00" #inst "1991-03-04T00:27:15.926-00:00" #inst
> "1993-12-10T20:33:14.714-00:00" #inst "2045-04-04T10:42:38.474-00:00" #inst
> "1972-05-30T18:17:49.692-00:00" #inst "1986-03-14T02:42:42.374-00:00" #inst
> "2096-01-05T11:11:23.974-00:00" #inst "1997-12-03T18:50:28.444-00:00" #

Passing ordinary Clojure data into incanter.stats.linear-model

[Conrad]

Hi, I'm having trouble finding any examples of how to use linear-model with 
simple clojure data. As per the documentation it says both x and y can be 
"vectors of values" so I would think the following would work:

(linear-model [1 2 3 4] [5 4 3 4])

Since the second can also be a matrix, I would think I could also write:

(linear-model [1 2 3 4] (matrix [[5 4 3 4] [1 2 1 1]]))

However, both of these bits of code throw obscure errors- Nothing I do seem 
to work. I'm guessing that I am misunderstanding what is meant by a "vector 
of values" in Incanter and that it has to be in some special Incanter data 
type- But I can't figure out which one... Could someone toss an Incanter 
newbie a bone and tell me what I'm missing? 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.

Re: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

these examples to illustrate what you are saying:

=> (= "(debug 1\r\n2 nil 3)" (pr-str (lazy-seq (list 2 (println "debug" 1)
3
true


=> (= "(1\r\n)" (pr-str (lazy-seq (println 1
true




On Sat, Feb 9, 2013 at 10:57 PM, Conrad  wrote:

> For those reading this, the issue is NOT that output in the REPL looks
> funny. The problem is that if, for instance, you put debug code into a
> chunk of code that makes use of "pr-str" your debug code is actually
> WRITTEN TO THE STRING. This is because "pr-str" works by using
> "with-out-str". This seems clumsy and is undocumented IMHO and I am
> wondering if other people feel the same.
>
>
> On Saturday, February 9, 2013 12:30:20 PM UTC-6, Conrad wrote:
>>
>> I tested this in the latest 1.5.0-RC6:
>>
>> => (def k (pr-str (for [x (range 5)]
>>  (do (pr x)
>>   x
>> #'user/k
>> => k
>> "(012340 1 2 3 4)"
>>
>> This seems wrong to me... I can see what would be needed to fix it in
>> clojure/core.clj, but it would require creating several additional private
>> functions. Does anyone know if this behavior is intentional?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: `let` to automatically add metadata / fn names?

[vemv]

>
> Going the build route, probably use maven to produce debug and production 
> artifacts of differing versions:  blah-1.0.0-DEBUG.jar and blah-1.0.0.jar. 
>

My thoughts too. And there's no need for convention madness - e.g. 
Leiningen could transparently create those versions to the user: the 
"NO-DEBUG" versions would simply set certain vars to false. For example, 
for the idea I'm proposing there would be *tagging-let*, which defaulted to 
true.

Would this adress the Android story as well?

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

[Gregory Graham]

> I like the parentheses better. My only complaint is that I have to press 
>> the shift key to type them.
>>
>
> You can always remap your keyboard / keyboard bindings. For example in 
> emacs:
>
> (define-key clojure-mode-map "9" 'paredit-open-round)
>

Thank-you, I'll try 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: `let` to automatically add metadata / fn names?

[Mark]

Are you thinking that the client developer (the person using the library) 
would maintain the proper magic ear-muffs in lein profiles?

On Saturday, February 9, 2013 3:17:51 PM UTC-8, vemv wrote:
>
> Going the build route, probably use maven to produce debug and production 
>> artifacts of differing versions:  blah-1.0.0-DEBUG.jar and blah-1.0.0.jar. 
>>
>
> My thoughts too. And there's no need for convention madness - e.g. 
> Leiningen could transparently create those versions to the user: the 
> "NO-DEBUG" versions would simply set certain vars to false. For example, 
> for the idea I'm proposing there would be *tagging-let*, which defaulted 
> to true.
>
> Would this adress the Android story as well?
>

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

[Juan Carlos Kuri Pinto]

I was programming a Clojure applet when I had similar problems with 
java.lang.ExceptionInInitializerError. But my experience with Java told me 
to delete the old class files generated by my project. And it worked. 
Always delete the old class files in every compilation and the problem 
disappears.

On Tuesday, December 2, 2008 1:56:47 PM UTC-5, Rich Hickey wrote:
>
>
>
> On Dec 2, 12:12 pm, Chouser  wrote: 
> > On Tue, Dec 2, 2008 at 10:24 AM, Rich Hickey  
> wrote: 
> > 
> > >  Proxy generation was the last runtime code-gen/classloader 
> > > requirement. So the path is clear for building Clojure apps without 
> > > runtime codegen, for delivery in those environments that preclude it 
> > > (e.g. Android, unsigned applets). Looking forward to feedback from 
> > > people trying to reach those targets. 
> > 
> > You asked for it.  :-) 
> > 
> > Here's a minimal applet .clj: 
> > 
> > (ns net.n01se.Tree 
> >   (:gen-class 
> >:extends java.applet.Applet)) 
> > 
> > Since it's missing a main fn, I would expect an exception like the this: 
> > java.lang.UnsupportedOperationException: net.n01se.Tree/-main not 
> > defined (NO_SOURCE_FILE:0) 
>
> When and why? 
>
> The mappings are dynamic, you'll get an error if you try to call it, 
> and you could define that later somehow. 
>
> > 
> > Using svn 1136 I can compile and get the above exception from a normal 
> > Clojure REPL, but if I try to use it as an applet: 
> > 
> > $ appletviewer test.html 
> > java.lang.ExceptionInInitializerError 
> > at clojure.lang.Namespace.(Namespace.java:31) 
> > at clojure.lang.Namespace.findOrCreate(Namespace.java:116) 
> > at clojure.lang.Var.internPrivate(Var.java:95) 
> > at net.n01se.Tree.(Unknown Source) 
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method) 
> > at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>  
>
> > at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  
>
> > at 
> java.lang.reflect.Constructor.newInstance(Constructor.java:532) 
> > at java.lang.Class.newInstance0(Class.java:372) 
> > at java.lang.Class.newInstance(Class.java:325) 
> > at sun.applet.AppletPanel.createApplet(AppletPanel.java:798) 
> > at sun.applet.AppletPanel.runLoader(AppletPanel.java:727) 
> > at sun.applet.AppletPanel.run(AppletPanel.java:380) 
> > at java.lang.Thread.run(Thread.java:636) 
> > Caused by: java.security.AccessControlException: access denied 
> > (java.lang.RuntimePermission createClassLoader) 
>
> > You can see it found my class okay, but it looks like there may be 
> > some dynamic classloader stuff still going on? 
> > 
>
> Thanks, that's useful. 
>
> Yes, the dynamic loader is still there, just won't be used, but it 
> looks like the security check is on creation. Getting it completely 
> out is another project... 
>
> Rich 
>

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

[vemv]

I had something like this in mind:

   - There's a set of clojure.core vars that mean something (potentially) 
   expensive yet convenient, and default to true
   - Neither library producers or consumers have ever to touch those 
   (unless they want fine-grained control for some specific var/context)
   - When performing a release to clojars or central, Lein creates two 
   versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and 
   false, respectively
   - Then library consumers can specify either [com.example/awesomelib *
   "1.4.0"*], [com.example *"1.4.0-DEBUG"*], or [com.example *
   "1.4.0-NO-DEBUG"*] in their :dependencies vector, in the corresponding 
   project.clj.
   - If no version directive is specified, "DEBUG" would be chosen unless 
   specified otherwise in profiles.clj: {:user {:debug-dependencies false}}

Does it sound good enough?

On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>
> Given that: a) fns can have names for debugging purposes, and b) data 
> structures can have metadata, wouldn't it be a good idea to let let auto 
> attach (where possible) the names of the bindings to their corresponding 
> values?
>
> For example, the improved let I'm thinking of would translate this input:
>
> (ns my.namespace)
>
> (defn do-it
>   (let [foo (fn [] (throw (Exception.)))
> bar {:hello (/ 0 0)}]))
>
> to:
>
> (ns my.namespace)
>
> (defn do-it
>   (let [foo (fn foo [] (throw (Exception.)))
> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>
> This could be used to increase the precision of the stack traces, or in 
> IDEs/editors for locating the exact source of an exception.
>
> Do you see such a mechanism being incorporated to clojure.core/let - 
> should I open a ticket?
>

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

[Armando Blancas]

There's nothing wrong with pr-str. Debug output should go to stderr.

user=>  (def k (pr-str (for [x (range 5)]
   (do (.println *err* x)
 (.println *err* "nothing")
x
0
nothing
1
nothing
2
nothing
3
nothing
4
nothing
#'user/k
user=> k
"(0 1 2 3 4)"

On Saturday, February 9, 2013 2:41:23 PM UTC-8, AtKaaZ wrote:
>
> these examples to illustrate what you are saying:
>
> => (= "(debug 1\r\n2 nil 3)" (pr-str (lazy-seq (list 2 (println "debug" 1) 
> 3
> true
>
>
> => (= "(1\r\n)" (pr-str (lazy-seq (println 1
> true
>
>
>
>
> On Sat, Feb 9, 2013 at 10:57 PM, Conrad >wrote:
>
>> For those reading this, the issue is NOT that output in the REPL looks 
>> funny. The problem is that if, for instance, you put debug code into a 
>> chunk of code that makes use of "pr-str" your debug code is actually 
>> WRITTEN TO THE STRING. This is because "pr-str" works by using 
>> "with-out-str". This seems clumsy and is undocumented IMHO and I am 
>> wondering if other people feel the same.
>>
>>
>> On Saturday, February 9, 2013 12:30:20 PM UTC-6, Conrad wrote:
>>>
>>> I tested this in the latest 1.5.0-RC6:
>>>
>>> => (def k (pr-str (for [x (range 5)] 
>>>  (do (pr x) 
>>>   x
>>> #'user/k
>>> => k
>>> "(012340 1 2 3 4)"
>>>
>>> This seems wrong to me... I can see what would be needed to fix it in 
>>> clojure/core.clj, but it would require creating several additional private 
>>> functions. Does anyone know if this behavior is intentional?
>>>
>>  -- 
>> -- 
>> 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.
>>  
>>  
>>
>
>
>
> -- 
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate 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: `let` to automatically add metadata / fn names?

[Stuart Halloway]

It is likely that, once this Pandora's box is opened, there will be more
profiles that just debug yes/no.

It is almost certain that whatever we do must be maven friendly.  (Maven is
a de facto standard for 1000x more people than leiningen, and some of them
want to use libs written in Clojure.)

If you are excited about doing this design work, please start a page in
Confluence, and capture your goals, options, tradeoffs, and recommendations.

Stu


On Sat, Feb 9, 2013 at 7:20 PM, vemv  wrote:

> I had something like this in mind:
>
>- There's a set of clojure.core vars that mean something (potentially)
>expensive yet convenient, and default to true
>- Neither library producers or consumers have ever to touch those
>(unless they want fine-grained control for some specific var/context)
>- When performing a release to clojars or central, Lein creates two
>versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and
>false, respectively
>- Then library consumers can specify either [com.example/awesomelib *
>"1.4.0"*], [com.example *"1.4.0-DEBUG"*], or [com.example *
>"1.4.0-NO-DEBUG"*] in their :dependencies vector, in the corresponding
>project.clj.
>- If no version directive is specified, "DEBUG" would be chosen unless
>specified otherwise in profiles.clj: {:user {:debug-dependencies false}}
>
> Does it sound good enough?
>
>
> On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>>
>> Given that: a) fns can have names for debugging purposes, and b) data
>> structures can have metadata, wouldn't it be a good idea to let let auto
>> attach (where possible) the names of the bindings to their corresponding
>> values?
>>
>> For example, the improved let I'm thinking of would translate this input:
>>
>> (ns my.namespace)
>>
>> (defn do-it
>>   (let [foo (fn [] (throw (Exception.)))
>> bar {:hello (/ 0 0)}]))
>>
>> to:
>>
>> (ns my.namespace)
>>
>> (defn do-it
>>   (let [foo (fn foo [] (throw (Exception.)))
>> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>>
>> This could be used to increase the precision of the stack traces, or in
>> IDEs/editors for locating the exact source of an exception.
>>
>> Do you see such a mechanism being incorporated to clojure.core/let -
>> should I open a ticket?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 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: pr-str captures stdout- Is this intentional or a bug?

[AtKaaZ]

this makes it a little more obvious maybe?

=> (pr-str (seq (println 1)))
1
"nil"
=> (= "nil" (pr-str (seq (println 1
1
true


=> (pr-str (lazy-seq (println 1)))
"(1\r\n)"
=> (= "(1\r\n)" (pr-str (lazy-seq (println 1
true




On Sun, Feb 10, 2013 at 1:55 AM, Armando Blancas wrote:

> There's nothing wrong with pr-str. Debug output should go to stderr.
>
> user=>  (def k (pr-str (for [x (range 5)]
>(do (.println *err* x)
>  (.println *err* "nothing")
> x
> 0
> nothing
> 1
> nothing
> 2
> nothing
> 3
> nothing
> 4
> nothing
> #'user/k
> user=> k
> "(0 1 2 3 4)"
>
> On Saturday, February 9, 2013 2:41:23 PM UTC-8, AtKaaZ wrote:
>
>> these examples to illustrate what you are saying:
>>
>> => (= "(debug 1\r\n2 nil 3)" (pr-str (lazy-seq (list 2 (println "debug"
>> 1) 3
>> true
>>
>>
>> => (= "(1\r\n)" (pr-str (lazy-seq (println 1
>> true
>>
>>
>>
>>
>> On Sat, Feb 9, 2013 at 10:57 PM, Conrad  wrote:
>>
>>> For those reading this, the issue is NOT that output in the REPL looks
>>> funny. The problem is that if, for instance, you put debug code into a
>>> chunk of code that makes use of "pr-str" your debug code is actually
>>> WRITTEN TO THE STRING. This is because "pr-str" works by using
>>> "with-out-str". This seems clumsy and is undocumented IMHO and I am
>>> wondering if other people feel the same.
>>>
>>>
>>> On Saturday, February 9, 2013 12:30:20 PM UTC-6, Conrad wrote:

 I tested this in the latest 1.5.0-RC6:

 => (def k (pr-str (for [x (range 5)]
  (do (pr x)
   x
 #'user/k
 => k
 "(012340 1 2 3 4)"

 This seems wrong to me... I can see what would be needed to fix it in
 clojure/core.clj, but it would require creating several additional private
 functions. Does anyone know if this behavior is intentional?

>>>  --
>>> --
>>> 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
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> Please correct me if I'm wrong or incomplete,
>> even if you think I'll subconsciously hate 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: `let` to automatically add metadata / fn names?

[Víctor M . V .]

Thanks for the advice Stu! I might give it a shot at Confluence at some
point. Just for the record, I like to defend my hypotethical approach:

Non-Clojure consumers most likely win nothing from extended metadata
facilities etc. So on second thoughts, the best default for "mylib-*1.0.0*.jar"
is to turn them off.

But on the Lein side, even if you specify [mylib *"1.0.0"*], *"*mylib-*
1.0.0-DEBUG*.jar*"* gets fetched instead unless one specifies otherwise,
which'd be the exception rather than the rule.

That way we'd get the best of both worlds - zero noise for Java consumers
or constrained Clojure envs, and full / a la carte facilities for the
majority of Clojure library producers and consumers.

On Sun, Feb 10, 2013 at 1:59 AM, Stuart Halloway
wrote:

> It is likely that, once this Pandora's box is opened, there will be more
> profiles that just debug yes/no.
>
> It is almost certain that whatever we do must be maven friendly.  (Maven
> is a de facto standard for 1000x more people than leiningen, and some of
> them want to use libs written in Clojure.)
>
> If you are excited about doing this design work, please start a page in
> Confluence, and capture your goals, options, tradeoffs, and recommendations.
>
> Stu
>
>
> On Sat, Feb 9, 2013 at 7:20 PM, vemv  wrote:
>
>> I had something like this in mind:
>>
>>- There's a set of clojure.core vars that mean something
>>(potentially) expensive yet convenient, and default to true
>>- Neither library producers or consumers have ever to touch those
>>(unless they want fine-grained control for some specific var/context)
>>- When performing a release to clojars or central, Lein creates two
>>versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and
>>false, respectively
>>- Then library consumers can specify either [com.example/awesomelib *
>>"1.4.0"*], [com.example *"1.4.0-DEBUG"*], or [com.example *
>>"1.4.0-NO-DEBUG"*] in their :dependencies vector, in the
>>corresponding project.clj.
>>- If no version directive is specified, "DEBUG" would be chosen
>>unless specified otherwise in profiles.clj: {:user {:debug-dependencies
>>false}}
>>
>> Does it sound good enough?
>>
>>
>> On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>>>
>>> Given that: a) fns can have names for debugging purposes, and b) data
>>> structures can have metadata, wouldn't it be a good idea to let letauto 
>>> attach (where possible) the names of the bindings to their
>>> corresponding values?
>>>
>>> For example, the improved let I'm thinking of would translate this
>>> input:
>>>
>>> (ns my.namespace)
>>>
>>> (defn do-it
>>>   (let [foo (fn [] (throw (Exception.)))
>>> bar {:hello (/ 0 0)}]))
>>>
>>> to:
>>>
>>> (ns my.namespace)
>>>
>>> (defn do-it
>>>   (let [foo (fn foo [] (throw (Exception.)))
>>> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>>>
>>> This could be used to increase the precision of the stack traces, or in
>>> IDEs/editors for locating the exact source of an exception.
>>>
>>> Do you see such a mechanism being incorporated to clojure.core/let -
>>> should I open a ticket?
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you 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.

Re: pr-str captures stdout- Is this intentional or a bug?

[Conrad]

OK, that viewpoint does sound reasonable- Thanks.

On Saturday, February 9, 2013 6:55:32 PM UTC-6, Armando Blancas wrote:
>
> There's nothing wrong with pr-str. Debug output should go to stderr.
>
> user=>  (def k (pr-str (for [x (range 5)]
>(do (.println *err* x)
>  (.println *err* "nothing")
> x
> 0
> nothing
> 1
> nothing
> 2
> nothing
> 3
> nothing
> 4
> nothing
> #'user/k
> user=> k
> "(0 1 2 3 4)"
>
> On Saturday, February 9, 2013 2:41:23 PM UTC-8, AtKaaZ wrote:
>>
>> these examples to illustrate what you are saying:
>>
>> => (= "(debug 1\r\n2 nil 3)" (pr-str (lazy-seq (list 2 (println "debug" 
>> 1) 3
>> true
>>
>>
>> => (= "(1\r\n)" (pr-str (lazy-seq (println 1
>> true
>>
>>
>>
>>
>> On Sat, Feb 9, 2013 at 10:57 PM, Conrad  wrote:
>>
>>> For those reading this, the issue is NOT that output in the REPL looks 
>>> funny. The problem is that if, for instance, you put debug code into a 
>>> chunk of code that makes use of "pr-str" your debug code is actually 
>>> WRITTEN TO THE STRING. This is because "pr-str" works by using 
>>> "with-out-str". This seems clumsy and is undocumented IMHO and I am 
>>> wondering if other people feel the same.
>>>
>>>
>>> On Saturday, February 9, 2013 12:30:20 PM UTC-6, Conrad wrote:

 I tested this in the latest 1.5.0-RC6:

 => (def k (pr-str (for [x (range 5)] 
  (do (pr x) 
   x
 #'user/k
 => k
 "(012340 1 2 3 4)"

 This seems wrong to me... I can see what would be needed to fix it in 
 clojure/core.clj, but it would require creating several additional private 
 functions. Does anyone know if this behavior is intentional?

>>>  -- 
>>> -- 
>>> 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.
>>>  
>>>  
>>>
>>
>>
>>
>> -- 
>> Please correct me if I'm wrong or incomplete,
>> even if you think I'll subconsciously hate 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: Passing ordinary Clojure data into incanter.stats.linear-model

[Conrad]

I just saw there's a special Incanter group- I will move my question over 
there...

On Saturday, February 9, 2013 4:34:56 PM UTC-6, Conrad wrote:
>
> Hi, I'm having trouble finding any examples of how to use linear-model 
> with simple clojure data. As per the documentation it says both x and y can 
> be "vectors of values" so I would think the following would work:
>
> (linear-model [1 2 3 4] [5 4 3 4])
>
> Since the second can also be a matrix, I would think I could also write:
>
> (linear-model [1 2 3 4] (matrix [[5 4 3 4] [1 2 1 1]]))
>
> However, both of these bits of code throw obscure errors- Nothing I do 
> seem to work. I'm guessing that I am misunderstanding what is meant by a 
> "vector of values" in Incanter and that it has to be in some special 
> Incanter data type- But I can't figure out which one... Could someone toss 
> an Incanter newbie a bone and tell me what I'm missing? 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.

Re: Clojure 1.5 RC 14

[Aaron Bedra]

Yeah, I know what would fix it, but I would like to make sure the right 
defaults are in place for folks who pull it down.

-Aaron

On Feb 9, 2013, at 4:29 PM, AtKaaZ  wrote:

> maybe jvm arg would help
> -XX:MaxPermSize=256m
> 
> 
> 
> On Sat, Feb 9, 2013 at 11:17 PM, Aaron Bedra  wrote:
> I just pulled it down locally and got the dreaded PermGen…
> 
>  [java] java.lang.OutOfMemoryError: PermGen space
>  [java]   at 
> clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
>  [java]   at clojure.lang.AFn.applyToHelper(AFn.java:161)
>  [java]   at clojure.lang.AFn.applyTo(AFn.java:151)
>  [java]   at clojure.core$apply.invoke(core.clj:617)
>  [java]   at 
> clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
>  [java]   at 
> clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
>  [java]   at 
> clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
>  [java]   at 
> clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
>  [java]   at 
> clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
>  [java]   at clojure.lang.AFn.call(AFn.java:18)
>  [java]   at 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>  [java]   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>  [java]   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>  [java]   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>  [java]   at java.lang.Thread.run(Thread.java:680)
>  [java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see ex-data 
> {:printed [#inst "2034-04-17T21:03:17.620-00:00" #inst 
> "1979-04-19T20:14:07.477-00:00" #inst "1996-06-20T05:47:52.868-00:00" #inst 
> "1995-08-15T20:51:41.920-00:00" #inst "2029-05-17T14:34:37.906-00:00" #inst 
> "1987-06-05T21:05:23.305-00:00" #inst "1994-06-29T16:17:24.459-00:00" #inst 
> "2035-12-03T09:39:44.754-00:00" #inst "2040-01-31T09:47:29.774-00:00" #inst 
> "1973-06-09T04:53:42.029-00:00" #inst "1996-12-23T17:26:25.607-00:00" #inst 
> "2022-07-01T16:33:57.846-00:00" #inst "1998-10-01T00:21:09.895-00:00" #inst 
> "1973-01-11T17:43:58.457-00:00" #inst "1988-11-03T22:46:53.468-00:00" #inst 
> "1982-01-31T11:34:19.796-00:00" #inst "2011-11-11T10:59:23.168-00:00" #inst 
> "1973-06-07T12:37:22.285-00:00" #inst "1977-12-15T03:32:20.215-00:00" #inst 
> "2047-10-15T13:51:28.327-00:00" #inst "2007-12-16T05:50:59.539-00:00" #inst 
> "1980-05-01T01:58:13.802-00:00" #inst "1980-01-30T04:31:20.418-00:00" #inst 
> "2044-09-16T14:38:34.919-00:00" #inst "1980-08-05T18:06:50.589-00:00" #inst 
> "1978-12-31T11:40:11.800-00:00" #inst "2015-05-08T15:03:27.594-00:00" #inst 
> "1975-06-28T17:24:08.855-00:00" #inst "1975-06-09T07:22:42.892-00:00" #inst 
> "2026-03-20T07:01:01.296-00:00" #inst "2053-02-02T01:33:45.525-00:00" #inst 
> "2002-04-11T18:43:38.347-00:00" #inst "1992-12-10T13:33:55.048-00:00" #inst 
> "2015-04-16T20:53:45.670-00:00" #inst "2013-12-23T20:16:07.506-00:00" #inst 
> "1978-09-02T09:42:03.175-00:00" #inst "1980-06-29T00:54:55.361-00:00" #inst 
> "2061-11-04T22:40:32.484-00:00" #inst "2190-06-05T04:42:38.638-00:00" #inst 
> "2038-03-19T09:05:50.002-00:00" #inst "2033-08-08T13:48:51.747-00:00" #inst 
> "2077-11-18T06:09:19.557-00:00" #inst "1997-02-07T14:02:27.410-00:00" #inst 
> "1988-08-20T07:11:32.623-00:00" #inst "1981-12-06T05:48:21.787-00:00" #inst 
> "1980-08-15T09:40:38.877-00:00" #inst "2022-01-19T16:23:06.638-00:00" #inst 
> "1994-09-09T17:35:55.052-00:00" #inst "1989-09-14T07:24:38.880-00:00" #inst 
> "2050-03-30T21:22:42.054-00:00" #inst "2071-10-09T20:37:08.430-00:00" #inst 
> "2083-04-19T10:25:43.108-00:00" #inst "1978-09-09T18:28:22.366-00:00" #inst 
> "1979-11-03T08:18:42.779-00:00" #inst "1975-10-24T00:59:58.497-00:00" #inst 
> "1974-10-10T14:40:29.360-00:00" #inst "1999-07-14T07:47:47.220-00:00" #inst 
> "2215-11-23T00:36:40.748-00:00" #inst "2077-02-14T19:40:22.712-00:00" #inst 
> "1985-03-14T12:30:49.064-00:00" #inst "2021-08-26T20:51:15.030-00:00" #inst 
> "2013-04-22T10:48:12.278-00:00" #inst "2019-08-31T17:31:05.195-00:00" #inst 
> "1975-04-21T22:13:33.370-00:00" #inst "1984-09-10T23:30:15.313-00:00" #inst 
> "2053-11-10T05:36:02.093-00:00" #inst "1974-01-05T15:17:02.286-00:00" #inst 
> "2058-09-18T08:11:45.895-00:00" #inst "1987-10-26T13:15:29.968-00:00" #inst 
> "2001-10-01T08:12:45.877-00:00" #inst "2003-05-29T15:17:24.449-00:00" #inst 
> "1981-02-07T01:20:10.665-00:00" #inst "1972-02-20T03:11:10.395-00:00" #inst 
> "1971-05-15T02:20:31.099-00:00" #inst "1998-07-14T19:05:58.450-00:00" #inst 
> "2003-11-20T14:15:43.535-00:00" #inst "2032-11-06T18:16:34.702-00:00" #inst 
> "1974-09-12T12:12:41.530-00:00" #inst "1971-01-16T05:00:36.536-00:00" #inst 
> "1997-04-22T20:01:48.046-00:00" #inst "1980-02-10T15:10:37.905-00:00" #inst 
> "1978-05-09T10:52:42.400-00:00" #ins

Re: Clojure - Python Style suggestion

[Jason Lewis]

ITT: emacs users complaining about modifier keys.

Sorry, but as a Vim guy, I couldn't help laughing.
On Feb 9, 2013 6:46 PM, "Gregory Graham"  wrote:

>
> I like the parentheses better. My only complaint is that I have to press
>>> the shift key to type them.
>>>
>>
>> You can always remap your keyboard / keyboard bindings. For example in
>> emacs:
>>
>> (define-key clojure-mode-map "9" 'paredit-open-round)
>>
>
> Thank-you, I'll try 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.
>
>
>

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

[Softaddicts]

:))

Luc P.


> ITT: emacs users complaining about modifier keys.
> 
> Sorry, but as a Vim guy, I couldn't help laughing.
> On Feb 9, 2013 6:46 PM, "Gregory Graham"  wrote:
> 
> >
> > I like the parentheses better. My only complaint is that I have to press
> >>> the shift key to type them.
> >>>
> >>
> >> You can always remap your keyboard / keyboard bindings. For example in
> >> emacs:
> >>
> >> (define-key clojure-mode-map "9" 'paredit-open-round)
> >>
> >
> > Thank-you, I'll try 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.
> >
> >
> >
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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

[Softaddicts]

For those too young to have seen this:

http://www.globalnerdy.com/2009/02/05/hacklabtos-lisp-machine-keyboard/



--
Softaddicts sent by ibisMail from my ipad!

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

[Jonas Enlund]

On Thursday, February 7, 2013 7:11:35 PM UTC+2, David Nolen wrote:
> http://dev.clojure.org/jira/browse/CLJS-418
> 
> 
> 
> Some of you may have encountered bizarre problems when trying to use browser 
> REPL with the latest releases of ClojureScript. This ticket contains a patch 
> that should resolve the issue but we need people to test.
> 
> 
> 
> Thanks,
> David

Hi

I tested this with the following approach and got the repl to work without 
issues:

* I modified cljsbuild[1] to use [org.clojure/google-closure-library 
"0.0-2029-2"] instead of [org.clojure/google-closure-library-third-party 
"0.0-2029"].
* AFAIK google-closure-library "0.0-2029-2" will be used by clojurescript in a 
new release so the above change (should) confirm that the transitive dependency 
on google-closure-library-third-party is indeed working as expected.

I also tried to test the browser repl without cljsbuild but script/bootstrap 
pulls in different closure-library deps than are specified in the pom.xml. The 
browser repl works without cljsbuild out of the box. 

If more testing concerning this issue is required please tell me because I'd 
like to see a new clojurescript release soon.

Jonas

[1] https://github.com/emezeske/lein-cljsbuild/blob/master/support/project.clj

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