Re: Question about transitivity in MultiFn.prefers() --- possible bug

[John Alan McDonald]

A related but slightly different issue: is prefer-method supposed to be 
transitive?
That is,  (prefer-method f a b) and  (prefer-method f b c) implies 
(prefer-method f a c)?
Here is a unit test that checks for transitivity (which fails in Clojure 
1.8.0):

(test/deftest transitive
  (derive ::transitive-d ::transitive-a)
  (derive ::transitive-d ::transitive-c)
  (defmulti transitive identity)
  (defmethod transitive ::transitive-a [x] [::transitive-a x]) 
  (defmethod transitive ::transitive-c [x] [::transitive-c x]) 
  (prefer-method transitive ::transitive-a ::transitive-b)
  (prefer-method transitive ::transitive-b ::transitive-c)
  (test/is (= [::transitive-a ::transitive-d] 
  (transitive ::transitive-d


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

Question about transitivity in MultiFn.prefers() --- possible bug

[John Alan McDonald]

prefers(x,y) checks the ancestors of x, and returns true if any of them are 
preferred to y --- which makes sense to me.

However, it also check the ancestors of y, and returns true if x is 
preferred to any of them, which I don't understand. 
Is that the intended behavior?  Seems like it should be checking the 
descendants of y.
What I am I missing?

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

Re: clojure.spec possible bug

[Rich Hickey]

This was fixed for alpha 3

> On May 26, 2016, at 10:08 AM, Georgi Danov  wrote:
> 
> I am trying to match sequences with fixed start and end but varying content. 
> After lots of experiments I start to suspect there is either bug, or severe 
> misunderstanding on my side.
> Here is one example that behaves illogical to me
> 
> (sp/conform
>  (sp/cat
>:start #{1}
>:mid (sp/+
>   (sp/alt :b (sp/+ #{3}) :c (sp/+ #{9})))
>:end #{10})
>  [1 3 3 3 9 9 3 10])
> => invalid ??
> 
> slight variation
> (sp/conform
>  (sp/cat
>:start #{1}
>:mid (sp/* ;; <<=
>   (sp/alt :b (sp/+ #{3}) :c (sp/+ #{9})))
>:end #{10})
>  [1 3 3 3 9 9 10]) ;; <<=
> => invalid ??
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

clojure.spec possible bug

[Georgi Danov]

I am trying to match sequences with fixed start and end but varying 
content. After lots of experiments I start to suspect there is either bug, 
or severe misunderstanding on my side.
Here is one example that behaves illogical to me

(sp/conform
 (sp/cat
   :start #{1}
   :mid (sp/+
  (sp/alt :b (sp/+ #{3}) :c (sp/+ #{9})))
   :end #{10})
 [1 3 3 3 9 9 3 10])
=> invalid ??

slight variation
(sp/conform
 (sp/cat
   :start #{1}
   :mid (sp/* ;; <<=
  (sp/alt :b (sp/+ #{3}) :c (sp/+ #{9})))
   :end #{10})
 [1 3 3 3 9 9 10]) ;; <<=
=> invalid ??



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

Re: Possible bug with (keys some-container) in a try-catch?

[Steve Riley]

Thanks for your explanation

On Friday, April 22, 2016 at 2:02:53 PM UTC-7, red...@gmail.com wrote:
>
> keys is lazy, you see the exception at the repl because printing out the 
> result forces the sequence, but if you don't do anything with the result 
> then it isn't forced, so no errors. 
>
> On 04/22/2016 01:28 PM, Steve Riley wrote: 
> > I am trying to determine if a container, x, passed to a function, is a 
> > map or not. 
> > 
> > If I evaluation (keys x) at a REPL prompt, and, x is instantiated list, 
> > vector or set, I will get a java.lang.ClassCastException that some item 
> > in x cannot be cast to java.util.Map$Entry. 
> > 
> > On the other hand, if I evaluate (try (keys x) true), the form evaluates 
> > to true. It will also evaluation to true if I add a catch expression 
> > with the last value of false. I've tried catching both 
> > ClassCastException and just Exception. 
> > 
> > (try (/ 10 0) true (catch ArithmeticException _ "divide by zero!")) 
> > and (try (/ 10 1) true (catch ArithmeticException _ "divide by zero!")), 
> > for example, evaluate as expected. 
> > 
> > Is this a feature I don't understand? 
> > 
> > Some of you may recognize the 4Clojure problem I am working on. I'm not 
> > interested in solutions to that problem...just curious about this 
> > behavior and if there is something I am missing in the try (keys x) 
> > catch formulation. 
> > 
> > Many thanks 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> > your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to clojure+u...@googlegroups.com  
> > . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> And what is good, Phaedrus, 
> And what is not good— 
> Need we ask anyone to tell us these things? 
>

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

Re: Possible bug with (keys some-container) in a try-catch?

[Kevin Downey]

keys is lazy, you see the exception at the repl because printing out the
result forces the sequence, but if you don't do anything with the result
then it isn't forced, so no errors.

On 04/22/2016 01:28 PM, Steve Riley wrote:
> I am trying to determine if a container, x, passed to a function, is a
> map or not.
> 
> If I evaluation (keys x) at a REPL prompt, and, x is instantiated list,
> vector or set, I will get a java.lang.ClassCastException that some item
> in x cannot be cast to java.util.Map$Entry.
> 
> On the other hand, if I evaluate (try (keys x) true), the form evaluates
> to true. It will also evaluation to true if I add a catch expression
> with the last value of false. I've tried catching both
> ClassCastException and just Exception.
> 
> (try (/ 10 0) true (catch ArithmeticException _ "divide by zero!"))
> and (try (/ 10 1) true (catch ArithmeticException _ "divide by zero!")),
> for example, evaluate as expected.
> 
> Is this a feature I don't understand?
> 
> Some of you may recognize the 4Clojure problem I am working on. I'm not
> interested in solutions to that problem...just curious about this
> behavior and if there is something I am missing in the try (keys x)
> catch formulation.
> 
> Many 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/d/optout.


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

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

Re: Possible bug with (keys some-container) in a try-catch?

[Alex Miller]

(keys x) is a lazy seq so in (try (keys x) true), the (keys x) is created 
but not realized so the error is not discovered. The REPL will print the 
result, which requires the values to be realized.


On Friday, April 22, 2016 at 3:37:07 PM UTC-5, Steve Riley wrote:
>
> I am trying to determine if a container, x, passed to a function, is a map 
> or not.
>
> If I evaluation (keys x) at a REPL prompt, and, x is instantiated list, 
> vector or set, I will get a java.lang.ClassCastException that some item in 
> x cannot be cast to java.util.Map$Entry.
>
> On the other hand, if I evaluate (try (keys x) true), the form evaluates 
> to true. It will also evaluation to true if I add a catch expression with 
> the last value of false. I've tried catching both ClassCastException and 
> just Exception.
>
> (try (/ 10 0) true (catch ArithmeticException _ "divide by zero!")) 
> and (try (/ 10 1) true (catch ArithmeticException _ "divide by zero!")), 
> for example, evaluate as expected.
>
> Is this a feature I don't understand?
>
> Some of you may recognize the 4Clojure problem I am working on. I'm not 
> interested in solutions to that problem...just curious about this behavior 
> and if there is something I am missing in the try (keys x) catch 
> formulation.
>
> Many 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/d/optout.

Possible bug with (keys some-container) in a try-catch?

[Steve Riley]

I am trying to determine if a container, x, passed to a function, is a map 
or not.

If I evaluation (keys x) at a REPL prompt, and, x is instantiated list, 
vector or set, I will get a java.lang.ClassCastException that some item in 
x cannot be cast to java.util.Map$Entry.

On the other hand, if I evaluate (try (keys x) true), the form evaluates to 
true. It will also evaluation to true if I add a catch expression with the 
last value of false. I've tried catching both ClassCastException and just 
Exception.

(try (/ 10 0) true (catch ArithmeticException _ "divide by zero!")) 
and (try (/ 10 1) true (catch ArithmeticException _ "divide by zero!")), 
for example, evaluate as expected.

Is this a feature I don't understand?

Some of you may recognize the 4Clojure problem I am working on. I'm not 
interested in solutions to that problem...just curious about this behavior 
and if there is something I am missing in the try (keys x) catch 
formulation.

Many 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/d/optout.

Re: Possible bug in clojure.set/union?

[Matching Socks]

This is an FAQ.  It is such a good FAQ that "fixing" it would be a shame.  
It's a good FAQ because it starts with a real problem that everyone thinks 
they have, and it leads (if you doggedly pursue it) to a well-rounded 
enlightenment as to what makes Clojure interesting.

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

Re: Possible bug in clojure.set/union?

[Alex Miller]

Hi Randy,

Several functions in clojure.set allow non-set arguments and this has been 
an issue with a long history. There have been or are tickets like this, 
such as http://dev.clojure.org/jira/browse/CLJ-1682 (although this one is 
re intersection).

This was done somewhat intentionally for performance reasons - rather than 
validate or transform, just assume they are sets - their behavior when 
passed non-sets is considered undefined. However, I think this is worth 
revisiting in light of where we are today vs then. I do not know of a jira 
specific to clojure.set/union - you are welcome to create one via the 
contribution process documented 
at http://clojure.org/community/contributing. 

Alex


On Friday, March 4, 2016 at 11:40:28 AM UTC-5, Randy J. Ray wrote:
>
> Hi,
>
> Fairly-new Clojure enthusiast here, currently using Clojure to work 
> through projecteuler.net problems as a means of learning. While using 
> sets on one of the PE problems, I encountered what *might* be a bug. I 
> admit that I haven't searched the backlog of messages from this group or 
> the issues on GitHub, so if this is already known I apologize.
>
> Here is the issue: I discovered that I could pass a list as the second 
> parameter to set/union, and it would be merged into the the set passed as 
> the first parameter and the new resulting set returned. However, if the 
> number of items in the list exceeds the number of items in the set, then 
> the return value is a list with any duplicate elements completely present.
>
> To illustrate, here is a snippet from my REPL:
>
> user=> (require '[clojure.set :as set])
> nil
> user=> (set/union #{1 2 3} #{2 3 4})
> #{1 4 3 2}
> user=> (set/union #{1 2 3} #{2 3 4 5})
> #{1 4 3 2 5}
> user=> (set/union #{1 2 3} (list 2 3 4))
> #{1 4 3 2}
> user=> (set/union #{1 2 3} (list 2 3 4 5))
> (2 3 1 2 3 4 5)
>
> Note that the last expression yields a list of 7 elements rather than a 
> set of 5.
>
> I have not tried this with more than two arguments, so I don't know that 
> would affect the output. I did try putting a list as the first parameter, 
> and that results in a list return value all the time.
>
> Is this a bug? Should I file a GitHub issue on this? I first encountered 
> this in 1.7.0, but I recently updated to 1.8.0 and it is still present.
>
> Randy
> -- 
> Randy J. Ray - randy.j@gmail.com - twitter.com/rjray
> Silicon Valley Scale Modelers: http://www.svsm.org
> Sunnyvale, CA
>

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

Possible bug in clojure.set/union?

[Randy J. Ray]

Hi,

Fairly-new Clojure enthusiast here, currently using Clojure to work through
projecteuler.net problems as a means of learning. While using sets on one
of the PE problems, I encountered what *might* be a bug. I admit that I
haven't searched the backlog of messages from this group or the issues on
GitHub, so if this is already known I apologize.

Here is the issue: I discovered that I could pass a list as the second
parameter to set/union, and it would be merged into the the set passed as
the first parameter and the new resulting set returned. However, if the
number of items in the list exceeds the number of items in the set, then
the return value is a list with any duplicate elements completely present.

To illustrate, here is a snippet from my REPL:

user=> (require '[clojure.set :as set])
nil
user=> (set/union #{1 2 3} #{2 3 4})
#{1 4 3 2}
user=> (set/union #{1 2 3} #{2 3 4 5})
#{1 4 3 2 5}
user=> (set/union #{1 2 3} (list 2 3 4))
#{1 4 3 2}
user=> (set/union #{1 2 3} (list 2 3 4 5))
(2 3 1 2 3 4 5)

Note that the last expression yields a list of 7 elements rather than a set
of 5.

I have not tried this with more than two arguments, so I don't know that
would affect the output. I did try putting a list as the first parameter,
and that results in a list return value all the time.

Is this a bug? Should I file a GitHub issue on this? I first encountered
this in 1.7.0, but I recently updated to 1.8.0 and it is still present.

Randy
-- 
Randy J. Ray - randy.j@gmail.com - twitter.com/rjray
Silicon Valley Scale Modelers: http://www.svsm.org
Sunnyvale, CA

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

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

['wparke...@yahoo.com' via Clojure]

I have logged an issue at http://dev.clojure.org/jira/browse/CLJ-1874  

Thank you all for the responses.

On Wednesday, December 30, 2015 at 12:02:35 PM UTC-6, Nicola Mometto wrote:
>
> While it's true that AOT has many issues, it's getting better release 
> after release and this is definitely a bug. 
> I don't understand why you wouldn't expect this to work, you *should*. 
>
> OP: can you open a ticket for this bug? I'd love to have a look at this 
> and try to fix it. 
>
> > On 29 Dec 2015, at 17:28, Stuart Sierra  > wrote: 
> > 
> > AOT-compilation breaks almost any code that tries to redefine Vars. I 
> wouldn't expect this to work. 
> > —S 
> > 
> > 
> > On Monday, December 28, 2015, wparker30 wrote: 
> > I have found what appears to be a bug in AOT-compiled Clojure when 
> ns-unmap is used.  I have the following reduced case: 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (def a :test-2) 
> > 
> > It turns out that a is not resolvable when this namespace is loaded. 
>  When I looked at the compiled bytecode, 
> > it appears that the following operations occur: 
> > 
> > 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which 
> is bound to a constant. 
> >   This var is added to the namespaces's mapping during this call. 
> > 2. Same as 1. 
> > 3. The var from 1 is bound to :test-1. 
> > 4. ns-unmap is called. 
> > 5. The var from 2 is bound to :test-2. 
> > 
> > Disclaimer: This is the first time I have had occasion to look directly 
> at bytecode and I could be missing something. 
> > 
> > The basic problem here is that the var is accessible from the load 
> method, but when step 5 executes the var is no longer 
> > accessible from the namespace mappings.  Thus, the root of the Var is 
> set to :test-2, but that Var is not mapped from the namespace. 
> > This works when there is no AOT compilation, as well as when I use 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (intern 'unmap-test.core 'a :test-2) 
> > 
> > I realize that creating defs, unmapping them, and then recreating them 
> is generally poor practice in Clojure. 
> > We have an odd case in that we need to have an interface and a Var of 
> the same name in the same namespace.  Simply 
> > doing definterface and then def causes a compilation failure: 
> > 
> > user=> (definterface abc) 
> > user.abc 
> > user=> (def abc 1) 
> > CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> mapped to interface user.abc, 
> compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
>  
>
> > 
> > Without going into too much detail, this is basically a hack to allow us 
> to refactor our internal framework code 
> > without immediately changing a very large amount of downstream consumer 
> code.  We get rid of the usage of the interface during macroexpansion, 
> > but it still needs to exist on the classpath so it can be imported by 
> downstream namespaces.   
> > There are a number of other ways to accomplish this, so it isn't a 
> particularly big problem for us, but I thought the issue was worth raising. 
> > This was just the first thing I tried and I was surprised when it didn't 
> work. 
> > 
> > Note that I used the 1.8.0 RC4 version of Clojure in my sample project, 
> but I had the same behavior on 1.7.0. 
> > 
> > Relevant links: 
> > 
> > 1. Bytecode for the load method of the init class: 
> https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a 
> > 2. Bytecode for the init0 method: 
> https://gist.github.com/WilliamParker/dc606ad086670915efd9 
> > 3. Decompiled Java code for the init class.  Note that this does not 
> completely line up with the bytecode as far as I can tell, 
> > but it is a quicker way to get a general idea of what is happening than 
> the bytecode. 
> > https://gist.github.com/WilliamParker/4cc47939f613d4595d94 
> > 4. A simple project containing the code above: 
> https://github.com/WilliamParker/unmap-test 
> > Note that if you try it without AOT compilation the target folder with 
> any previously compiled classes should be removed. 
> > 
> > I may or may not be able to respond to any replies before next week; I 
> apologize for any delayed responses. 
> > 
> > -- 
> > 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 

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

[Nicola Mometto]

Thanks for that, I've attached a possible fix to the ticket.

> On 5 Jan 2016, at 15:40, 'wparke...@yahoo.com' via Clojure 
>  wrote:
> 
> I have logged an issue at http://dev.clojure.org/jira/browse/CLJ-1874  
> 
> Thank you all for the responses.
> 
> On Wednesday, December 30, 2015 at 12:02:35 PM UTC-6, Nicola Mometto wrote:
> While it's true that AOT has many issues, it's getting better release after 
> release and this is definitely a bug. 
> I don't understand why you wouldn't expect this to work, you *should*. 
> 
> OP: can you open a ticket for this bug? I'd love to have a look at this and 
> try to fix it. 
> 
> > On 29 Dec 2015, at 17:28, Stuart Sierra  wrote: 
> > 
> > AOT-compilation breaks almost any code that tries to redefine Vars. I 
> > wouldn't expect this to work. 
> > —S 
> > 
> > 
> > On Monday, December 28, 2015, wparker30 wrote: 
> > I have found what appears to be a bug in AOT-compiled Clojure when ns-unmap 
> > is used.  I have the following reduced case: 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (def a :test-2) 
> > 
> > It turns out that a is not resolvable when this namespace is loaded.  When 
> > I looked at the compiled bytecode, 
> > it appears that the following operations occur: 
> > 
> > 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which is 
> > bound to a constant. 
> >   This var is added to the namespaces's mapping during this call. 
> > 2. Same as 1. 
> > 3. The var from 1 is bound to :test-1. 
> > 4. ns-unmap is called. 
> > 5. The var from 2 is bound to :test-2. 
> > 
> > Disclaimer: This is the first time I have had occasion to look directly at 
> > bytecode and I could be missing something. 
> > 
> > The basic problem here is that the var is accessible from the load method, 
> > but when step 5 executes the var is no longer 
> > accessible from the namespace mappings.  Thus, the root of the Var is set 
> > to :test-2, but that Var is not mapped from the namespace. 
> > This works when there is no AOT compilation, as well as when I use 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (intern 'unmap-test.core 'a :test-2) 
> > 
> > I realize that creating defs, unmapping them, and then recreating them is 
> > generally poor practice in Clojure. 
> > We have an odd case in that we need to have an interface and a Var of the 
> > same name in the same namespace.  Simply 
> > doing definterface and then def causes a compilation failure: 
> > 
> > user=> (definterface abc) 
> > user.abc 
> > user=> (def abc 1) 
> > CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> > mapped to interface user.abc, 
> > compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
> >  
> > 
> > Without going into too much detail, this is basically a hack to allow us to 
> > refactor our internal framework code 
> > without immediately changing a very large amount of downstream consumer 
> > code.  We get rid of the usage of the interface during macroexpansion, 
> > but it still needs to exist on the classpath so it can be imported by 
> > downstream namespaces.   
> > There are a number of other ways to accomplish this, so it isn't a 
> > particularly big problem for us, but I thought the issue was worth raising. 
> > This was just the first thing I tried and I was surprised when it didn't 
> > work. 
> > 
> > Note that I used the 1.8.0 RC4 version of Clojure in my sample project, but 
> > I had the same behavior on 1.7.0. 
> > 
> > Relevant links: 
> > 
> > 1. Bytecode for the load method of the init class: 
> > https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a 
> > 2. Bytecode for the init0 method: 
> > https://gist.github.com/WilliamParker/dc606ad086670915efd9 
> > 3. Decompiled Java code for the init class.  Note that this does not 
> > completely line up with the bytecode as far as I can tell, 
> > but it is a quicker way to get a general idea of what is happening than the 
> > bytecode. 
> > https://gist.github.com/WilliamParker/4cc47939f613d4595d94 
> > 4. A simple project containing the code above: 
> > https://github.com/WilliamParker/unmap-test 
> > Note that if you try it without AOT compilation the target folder with any 
> > previously compiled classes should be removed. 
> > 
> > I may or may not be able to respond to any replies before next week; I 
> > apologize for any delayed responses. 
> > 
> > -- 
> > 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 
> > 

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

[Mike Rodriguez]

This issue is a subtle one.  I do find it interesting that all vars are 
created and mapped to their namespace in the initN() (where N is 0 though 
whatever) methods.
However, other top-level function calls happen in the load() method.  All 
of this runs in the clinit of the class though.  

I'd really like to understand/get an explanation of the reason why some 
things go in the initN() methods vs what goes in the load() method.  I 
think it looks mostly clear that initN() methods just assign values to 
static fields of the class and everything else goes in load().  That may be 
an oversimplification though.

The thing that really surprised me on this one is that the order of 
operations in the AOT class is not really the same as the order you'd 
expect the compiler events to occur.  I do agree that multiple `def`s of 
the same var is probably a bad pattern.

On Wednesday, December 30, 2015 at 12:02:35 PM UTC-6, Nicola Mometto wrote:
>
> While it's true that AOT has many issues, it's getting better release 
> after release and this is definitely a bug. 
> I don't understand why you wouldn't expect this to work, you *should*. 
>
> OP: can you open a ticket for this bug? I'd love to have a look at this 
> and try to fix it. 
>
> > On 29 Dec 2015, at 17:28, Stuart Sierra  > wrote: 
> > 
> > AOT-compilation breaks almost any code that tries to redefine Vars. I 
> wouldn't expect this to work. 
> > —S 
> > 
> > 
> > On Monday, December 28, 2015, wparker30 wrote: 
> > I have found what appears to be a bug in AOT-compiled Clojure when 
> ns-unmap is used.  I have the following reduced case: 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (def a :test-2) 
> > 
> > It turns out that a is not resolvable when this namespace is loaded. 
>  When I looked at the compiled bytecode, 
> > it appears that the following operations occur: 
> > 
> > 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which 
> is bound to a constant. 
> >   This var is added to the namespaces's mapping during this call. 
> > 2. Same as 1. 
> > 3. The var from 1 is bound to :test-1. 
> > 4. ns-unmap is called. 
> > 5. The var from 2 is bound to :test-2. 
> > 
> > Disclaimer: This is the first time I have had occasion to look directly 
> at bytecode and I could be missing something. 
> > 
> > The basic problem here is that the var is accessible from the load 
> method, but when step 5 executes the var is no longer 
> > accessible from the namespace mappings.  Thus, the root of the Var is 
> set to :test-2, but that Var is not mapped from the namespace. 
> > This works when there is no AOT compilation, as well as when I use 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (intern 'unmap-test.core 'a :test-2) 
> > 
> > I realize that creating defs, unmapping them, and then recreating them 
> is generally poor practice in Clojure. 
> > We have an odd case in that we need to have an interface and a Var of 
> the same name in the same namespace.  Simply 
> > doing definterface and then def causes a compilation failure: 
> > 
> > user=> (definterface abc) 
> > user.abc 
> > user=> (def abc 1) 
> > CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> mapped to interface user.abc, 
> compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
>  
>
> > 
> > Without going into too much detail, this is basically a hack to allow us 
> to refactor our internal framework code 
> > without immediately changing a very large amount of downstream consumer 
> code.  We get rid of the usage of the interface during macroexpansion, 
> > but it still needs to exist on the classpath so it can be imported by 
> downstream namespaces.   
> > There are a number of other ways to accomplish this, so it isn't a 
> particularly big problem for us, but I thought the issue was worth raising. 
> > This was just the first thing I tried and I was surprised when it didn't 
> work. 
> > 
> > Note that I used the 1.8.0 RC4 version of Clojure in my sample project, 
> but I had the same behavior on 1.7.0. 
> > 
> > Relevant links: 
> > 
> > 1. Bytecode for the load method of the init class: 
> https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a 
> > 2. Bytecode for the init0 method: 
> https://gist.github.com/WilliamParker/dc606ad086670915efd9 
> > 3. Decompiled Java code for the init class.  Note that this does not 
> completely line up with the bytecode as far as I can tell, 
> > but it is a quicker way to get a general idea of what is happening than 
> the bytecode. 
> > https://gist.github.com/WilliamParker/4cc47939f613d4595d94 
> > 4. A simple project containing the code above: 
> https://github.com/WilliamParker/unmap-test 
> > Note that if you try it without AOT compilation the target folder with 
> any previously compiled classes should be removed. 

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

[Nicola Mometto]

While it's true that AOT has many issues, it's getting better release after 
release and this is definitely a bug. 
I don't understand why you wouldn't expect this to work, you *should*.

OP: can you open a ticket for this bug? I'd love to have a look at this and try 
to fix it.

> On 29 Dec 2015, at 17:28, Stuart Sierra  wrote:
> 
> AOT-compilation breaks almost any code that tries to redefine Vars. I 
> wouldn't expect this to work.
> —S
> 
> 
> On Monday, December 28, 2015, wparker30 wrote:
> I have found what appears to be a bug in AOT-compiled Clojure when ns-unmap 
> is used.  I have the following reduced case:
> 
> (ns unmap-test.core)
> 
> (def a :test-1)
> 
> (ns-unmap 'unmap-test.core 'a)
> 
> (def a :test-2)
> 
> It turns out that a is not resolvable when this namespace is loaded.  When I 
> looked at the compiled bytecode,
> it appears that the following operations occur:
> 
> 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which is 
> bound to a constant.
>   This var is added to the namespaces's mapping during this call.
> 2. Same as 1.
> 3. The var from 1 is bound to :test-1.
> 4. ns-unmap is called.
> 5. The var from 2 is bound to :test-2.
> 
> Disclaimer: This is the first time I have had occasion to look directly at 
> bytecode and I could be missing something.
> 
> The basic problem here is that the var is accessible from the load method, 
> but when step 5 executes the var is no longer
> accessible from the namespace mappings.  Thus, the root of the Var is set to 
> :test-2, but that Var is not mapped from the namespace.
> This works when there is no AOT compilation, as well as when I use 
> 
> (ns unmap-test.core)
> 
> (def a :test-1)
> 
> (ns-unmap 'unmap-test.core 'a)
> 
> (intern 'unmap-test.core 'a :test-2)
> 
> I realize that creating defs, unmapping them, and then recreating them is 
> generally poor practice in Clojure.
> We have an odd case in that we need to have an interface and a Var of the 
> same name in the same namespace.  Simply
> doing definterface and then def causes a compilation failure:
> 
> user=> (definterface abc)
> user.abc
> user=> (def abc 1)
> CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> mapped to interface user.abc, 
> compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
>  
> 
> Without going into too much detail, this is basically a hack to allow us to 
> refactor our internal framework code
> without immediately changing a very large amount of downstream consumer code. 
>  We get rid of the usage of the interface during macroexpansion,
> but it still needs to exist on the classpath so it can be imported by 
> downstream namespaces.  
> There are a number of other ways to accomplish this, so it isn't a 
> particularly big problem for us, but I thought the issue was worth raising.
> This was just the first thing I tried and I was surprised when it didn't work.
> 
> Note that I used the 1.8.0 RC4 version of Clojure in my sample project, but I 
> had the same behavior on 1.7.0.
> 
> Relevant links:
> 
> 1. Bytecode for the load method of the init class: 
> https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a
> 2. Bytecode for the init0 method: 
> https://gist.github.com/WilliamParker/dc606ad086670915efd9
> 3. Decompiled Java code for the init class.  Note that this does not 
> completely line up with the bytecode as far as I can tell,
> but it is a quicker way to get a general idea of what is happening than the 
> bytecode.
> https://gist.github.com/WilliamParker/4cc47939f613d4595d94
> 4. A simple project containing the code above: 
> https://github.com/WilliamParker/unmap-test
> Note that if you try it without AOT compilation the target folder with any 
> previously compiled classes should be removed.
> 
> I may or may not be able to respond to any replies before next week; I 
> apologize for any delayed responses.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

[Stuart Sierra]

AOT-compilation breaks almost any code that tries to redefine Vars. I 
wouldn't expect this to work.
—S


On Monday, December 28, 2015, wparker30 wrote:
>
> I have found what appears to be a bug in AOT-compiled Clojure when 
> ns-unmap is used.  I have the following reduced case:
>
> (ns unmap-test.core)
>
> (def a :test-1)
>
> (ns-unmap 'unmap-test.core 'a)
>
> (def a :test-2)
>
> It turns out that a is not resolvable when this namespace is loaded.  When 
> I looked at the compiled bytecode,
> it appears that the following operations occur:
>
> 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which is 
> bound to a constant.
>   This var is added to the namespaces's mapping during this call.
> 2. Same as 1.
> 3. The var from 1 is bound to :test-1.
> 4. ns-unmap is called.
> 5. The var from 2 is bound to :test-2.
>
> Disclaimer: This is the first time I have had occasion to look directly at 
> bytecode and I could be missing something.
>
> The basic problem here is that the var is accessible from the load method, 
> but when step 5 executes the var is no longer
> accessible from the namespace mappings.  Thus, the root of the Var is set 
> to :test-2, but that Var is not mapped from the namespace.
> This works when there is no AOT compilation, as well as when I use 
>
> (ns unmap-test.core)
>
> (def a :test-1)
>
> (ns-unmap 'unmap-test.core 'a)
>
> (intern 'unmap-test.core 'a :test-2)
>
> I realize that creating defs, unmapping them, and then recreating them is 
> generally poor practice in Clojure.
> We have an odd case in that we need to have an interface and a Var of the 
> same name in the same namespace.  Simply
> doing definterface and then def causes a compilation failure:
>
> user=> (definterface abc)
> user.abc
> user=> (def abc 1)
> CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> mapped to interface user.abc, 
> compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
>  
>
> Without going into too much detail, this is basically a hack to allow us 
> to refactor our internal framework code
> without immediately changing a very large amount of downstream consumer 
> code.  We get rid of the usage of the interface during macroexpansion,
> but it still needs to exist on the classpath so it can be imported by 
> downstream namespaces.  
> There are a number of other ways to accomplish this, so it isn't a 
> particularly big problem for us, but I thought the issue was worth raising.
> This was just the first thing I tried and I was surprised when it didn't 
> work.
>
> Note that I used the 1.8.0 RC4 version of Clojure in my sample project, 
> but I had the same behavior on 1.7.0.
>
> Relevant links:
>
> 1. Bytecode for the load method of the init class: 
> https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a
> 2. Bytecode for the init0 method: 
> https://gist.github.com/WilliamParker/dc606ad086670915efd9
> 3. Decompiled Java code for the init class.  Note that this does not 
> completely line up with the bytecode as far as I can tell,
> but it is a quicker way to get a general idea of what is happening than 
> the bytecode.
> https://gist.github.com/WilliamParker/4cc47939f613d4595d94
> 4. A simple project containing the code above: 
> https://github.com/WilliamParker/unmap-test
> Note that if you try it without AOT compilation the target folder with any 
> previously compiled classes should be removed.
>
> I may or may not be able to respond to any replies before next week; I 
> apologize for any delayed responses.
>

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

Possible bug in AOT-compiled Clojure when ns-unmap is used

['wparke...@yahoo.com' via Clojure]

I have found what appears to be a bug in AOT-compiled Clojure when ns-unmap 
is used.  I have the following reduced case:

(ns unmap-test.core)

(def a :test-1)

(ns-unmap 'unmap-test.core 'a)

(def a :test-2)

It turns out that a is not resolvable when this namespace is loaded.  When 
I looked at the compiled bytecode,
it appears that the following operations occur:

1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which is 
bound to a constant.
  This var is added to the namespaces's mapping during this call.
2. Same as 1.
3. The var from 1 is bound to :test-1.
4. ns-unmap is called.
5. The var from 2 is bound to :test-2.

Disclaimer: This is the first time I have had occasion to look directly at 
bytecode and I could be missing something.

The basic problem here is that the var is accessible from the load method, 
but when step 5 executes the var is no longer
accessible from the namespace mappings.  Thus, the root of the Var is set 
to :test-2, but that Var is not mapped from the namespace.
This works when there is no AOT compilation, as well as when I use 

(ns unmap-test.core)

(def a :test-1)

(ns-unmap 'unmap-test.core 'a)

(intern 'unmap-test.core 'a :test-2)

I realize that creating defs, unmapping them, and then recreating them is 
generally poor practice in Clojure.
We have an odd case in that we need to have an interface and a Var of the 
same name in the same namespace.  Simply
doing definterface and then def causes a compilation failure:

user=> (definterface abc)
user.abc
user=> (def abc 1)
CompilerException java.lang.RuntimeException: Expecting var, but abc is 
mapped to interface user.abc, 
compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
 

Without going into too much detail, this is basically a hack to allow us to 
refactor our internal framework code
without immediately changing a very large amount of downstream consumer 
code.  We get rid of the usage of the interface during macroexpansion,
but it still needs to exist on the classpath so it can be imported by 
downstream namespaces.  
There are a number of other ways to accomplish this, so it isn't a 
particularly big problem for us, but I thought the issue was worth raising.
This was just the first thing I tried and I was surprised when it didn't 
work.

Note that I used the 1.8.0 RC4 version of Clojure in my sample project, but 
I had the same behavior on 1.7.0.

Relevant links:

1. Bytecode for the load method of the init class: 
https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a
2. Bytecode for the init0 method: 
https://gist.github.com/WilliamParker/dc606ad086670915efd9
3. Decompiled Java code for the init class.  Note that this does not 
completely line up with the bytecode as far as I can tell,
but it is a quicker way to get a general idea of what is happening than the 
bytecode.
https://gist.github.com/WilliamParker/4cc47939f613d4595d94
4. A simple project containing the code above: 
https://github.com/WilliamParker/unmap-test
Note that if you try it without AOT compilation the target folder with any 
previously compiled classes should be removed.

I may or may not be able to respond to any replies before next week; I 
apologize for any delayed responses.

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

Re: possible bug in 1.51?

[Meikel Brandmeyer (kotarak)]

Hi,

the difference between type and class is, that type inspects the metadata 
first for a :type keyword. This let's you bless data structures with a type 
tag eg. for printing or multimethod dispatching. This predates records and 
protocols. It is used in pr, which triggers the exception while printing in 
the repl. It's not a bug. It's a (old) feature.

Kind regards
Meikel

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

possible bug in 1.51?

[Paul VanHouten]

;; run the following code that creates namespace blech where (ns ...)
includes metadata
;; both cases compile without error
;; case 1: when metadata entry :type test  is included (the-ns 'blech)
works
;; case 2: when metadata entry :type :test  is included (the-ns 'blech)
triggers the exception:
;;ClassCastException clojure.lang.Namespace cannot be cast to
clojure.lang.IObj
;;clojure.core/with-meta (core.clj:214)
;; note: cases were run with freshly restarted repl

;; test code
---
(ns blech{:xtype:test ;; no error
   ;:type test   ;; case 1 - (the-ns 'blech) works
:type:test  ;; case 2 - (the-ns 'blech)
triggers exception
 })

(in-ns 'user)
(the-ns 'blech)

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

[Brandon Ibach]

Thanks for the confirmation, Alex.  Ticket 
filedhttp://dev.clojure.org/jira/browse/CLJ-1260. 
:)

Aaron, as shown in the test case attached to the ticket, I'm calling the 
Clojure library from Java code, so I use the Agent.dispatch() method.  The 
project where this issue was found is attempting to use Clojure's STM and 
Agent support to fix concurrency issues in an existing, rather large, Java 
code base, which we're not quite ready to port to another language, just 
yet.

Meikel, thanks for the suggestion.  I wasn't very clear about it in my 
description, but a workaround much like that is what I'd already employed 
in order to move forward with my work.  The version of it that is shown in 
the test case on the ticket just references a static field from the RT 
class, which is enough to trigger the runtime initialization.

-Brandon :)


On Wednesday, September 11, 2013 8:25:31 AM UTC-4, Alex Miller wrote:

 I have not gone to look at the code but the description certainly sounds 
 like a recipe for a bug. 

 If you can a) create a reproducible case and b) check that it happens on 
 1.5 as well we would greatly appreciate a ticket:

 Create a jira account - 
 http://dev.clojure.org/jira/secure/Signup!default.jspa
 Then create a jira ticket - 
 http://dev.clojure.org/display/community/Creating+Tickets

 Thanks,
 Alex


 On Wednesday, September 11, 2013 1:47:56 AM UTC-5, Brandon Ibach wrote:

 I have found what appears to be a bug in LockingTransaction, albeit one 
 that probably wouldn't occur often.  But, I suppose that's a given for a 
 previously undiscovered problem in oft-used code that hasn't changed for 
 some while. :)

 I'm using the Clojure 1.4 library strictly from Java code and I have a 
 fairly simple transaction which dispatches an action to an agent (send, not 
 send-off).  When called from a JUnit test, such that we jump right in to 
 things, skipping some of the initialization we normally do in our app, I 
 get a ConcurrentModificationException from inside Locktransaction.run() 
 while it is iterating through the actions list, dispatching the actions 
 after committing the transaction.

 Based on some debugging, here's what seems to be happening:

 1. My transaction is run, dispatching an action to an agent.
 2. The transaction completes and is successfully committed.
 3. LockingTransaction does post-commit cleanup, freeing locks and putting 
 a stop() to the transaction, which nulls the transaction's Info object 
 reference.
 4. Notifications are sent and we start iterating the list of actions to 
 be dispatched.
 5. The run() method calls Agent.dispatchAction().  Because the thread's 
 transaction is no longer running (due to the Info object being null) and 
 no action is being processed on the thread (so its nested vector is 
 null), the action is enqueue()d with the agent.
 6. As part of the enqueue process, the action is consed onto the agent's 
 ActionQueue.  Here's where the unique circumstances come into play.
a. At this point, we haven't really interacted with the Clojure 
 runtime, specifically the RT class, so its initiation machinery kicks in.
b. Down in the depths, it executes a transaction to add a library to 
 its list of loaded libraries.
c. The still-existing-but-not-running thread-local transaction, with 
 its existing action list intact, fires up, runs and commits.
d. The post-commit stuff runs, including a nested attempt to dispatch 
 that same action, again, which apparently succeeds.
e. The action list is cleared before exiting the run() method.
 7. Upon returning way back up the stack to our 
 not-quite-finished-post-processing transaction, we continue iterating the 
 now-cleared action list, which promptly throws the 
 ConcurrentModificationException.

 A quick perusal of the LockingTransaction code shows that the only 
 interaction with the action list is adding an item to it in the enqueue() 
 method, iterating it in the post-processing section of run() and clearing 
 it in the finally clause of that section, so it's easy to see how a 
 transaction started by any of the action-dispatching machinery would cause 
 problems.  Any such activity in the actions themselves would not be an 
 issue, since they'd occur on other threads, but the dispatch stuff all runs 
 on the same thread.  The few moving parts that occur in this code seem 
 fairly safe, as long as the runtime is already initialized, but if that 
 occurs during this phase, I think all bets are off.

 Does this analysis seem sound?  If so, is there a more formal process for 
 filing this as a bug?  I can probably create a nice, compact example to 
 reproduce it.

 Thanks!

 -Brandon :)



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

Re: Possible bug in LockingTransaction

[Meikel Brandmeyer (kotarak)]

Hi,

Am Donnerstag, 12. September 2013 11:11:36 UTC+2 schrieb Brandon Ibach:

 Aaron, as shown in the test case attached to the ticket, I'm calling the 
 Clojure library from Java code, so I use the Agent.dispatch() method.  The 
 project where this issue was found is attempting to use Clojure's STM and 
 Agent support to fix concurrency issues in an existing, rather large, Java 
 code base, which we're not quite ready to port to another language, just 
 yet.


In the past using Java methods directly was considered wrong. If you want 
to send to a Agent you should use RT.var(clojure.core, send).invoke(...). 
This can be hidden behind a simple Java facade. (At some point there was 
some talk about an official Java facade for that purpose, IIRCI).

Kind regards
Meikel

 

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

Possible bug in LockingTransaction

[Brandon Ibach]

I have found what appears to be a bug in LockingTransaction, albeit one 
that probably wouldn't occur often.  But, I suppose that's a given for a 
previously undiscovered problem in oft-used code that hasn't changed for 
some while. :)

I'm using the Clojure 1.4 library strictly from Java code and I have a 
fairly simple transaction which dispatches an action to an agent (send, not 
send-off).  When called from a JUnit test, such that we jump right in to 
things, skipping some of the initialization we normally do in our app, I 
get a ConcurrentModificationException from inside Locktransaction.run() 
while it is iterating through the actions list, dispatching the actions 
after committing the transaction.

Based on some debugging, here's what seems to be happening:

1. My transaction is run, dispatching an action to an agent.
2. The transaction completes and is successfully committed.
3. LockingTransaction does post-commit cleanup, freeing locks and putting a 
stop() to the transaction, which nulls the transaction's Info object 
reference.
4. Notifications are sent and we start iterating the list of actions to be 
dispatched.
5. The run() method calls Agent.dispatchAction().  Because the thread's 
transaction is no longer running (due to the Info object being null) and 
no action is being processed on the thread (so its nested vector is 
null), the action is enqueue()d with the agent.
6. As part of the enqueue process, the action is consed onto the agent's 
ActionQueue.  Here's where the unique circumstances come into play.
   a. At this point, we haven't really interacted with the Clojure runtime, 
specifically the RT class, so its initiation machinery kicks in.
   b. Down in the depths, it executes a transaction to add a library to its 
list of loaded libraries.
   c. The still-existing-but-not-running thread-local transaction, with its 
existing action list intact, fires up, runs and commits.
   d. The post-commit stuff runs, including a nested attempt to dispatch 
that same action, again, which apparently succeeds.
   e. The action list is cleared before exiting the run() method.
7. Upon returning way back up the stack to our 
not-quite-finished-post-processing transaction, we continue iterating the 
now-cleared action list, which promptly throws the 
ConcurrentModificationException.

A quick perusal of the LockingTransaction code shows that the only 
interaction with the action list is adding an item to it in the enqueue() 
method, iterating it in the post-processing section of run() and clearing 
it in the finally clause of that section, so it's easy to see how a 
transaction started by any of the action-dispatching machinery would cause 
problems.  Any such activity in the actions themselves would not be an 
issue, since they'd occur on other threads, but the dispatch stuff all runs 
on the same thread.  The few moving parts that occur in this code seem 
fairly safe, as long as the runtime is already initialized, but if that 
occurs during this phase, I think all bets are off.

Does this analysis seem sound?  If so, is there a more formal process for 
filing this as a bug?  I can probably create a nice, compact example to 
reproduce it.

Thanks!

-Brandon :)

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

[Alex Miller]

I have not gone to look at the code but the description certainly sounds 
like a recipe for a bug. 

If you can a) create a reproducible case and b) check that it happens on 
1.5 as well we would greatly appreciate a ticket:

Create a jira account 
- http://dev.clojure.org/jira/secure/Signup!default.jspa
Then create a jira ticket 
- http://dev.clojure.org/display/community/Creating+Tickets

Thanks,
Alex


On Wednesday, September 11, 2013 1:47:56 AM UTC-5, Brandon Ibach wrote:

 I have found what appears to be a bug in LockingTransaction, albeit one 
 that probably wouldn't occur often.  But, I suppose that's a given for a 
 previously undiscovered problem in oft-used code that hasn't changed for 
 some while. :)

 I'm using the Clojure 1.4 library strictly from Java code and I have a 
 fairly simple transaction which dispatches an action to an agent (send, not 
 send-off).  When called from a JUnit test, such that we jump right in to 
 things, skipping some of the initialization we normally do in our app, I 
 get a ConcurrentModificationException from inside Locktransaction.run() 
 while it is iterating through the actions list, dispatching the actions 
 after committing the transaction.

 Based on some debugging, here's what seems to be happening:

 1. My transaction is run, dispatching an action to an agent.
 2. The transaction completes and is successfully committed.
 3. LockingTransaction does post-commit cleanup, freeing locks and putting 
 a stop() to the transaction, which nulls the transaction's Info object 
 reference.
 4. Notifications are sent and we start iterating the list of actions to be 
 dispatched.
 5. The run() method calls Agent.dispatchAction().  Because the thread's 
 transaction is no longer running (due to the Info object being null) and 
 no action is being processed on the thread (so its nested vector is 
 null), the action is enqueue()d with the agent.
 6. As part of the enqueue process, the action is consed onto the agent's 
 ActionQueue.  Here's where the unique circumstances come into play.
a. At this point, we haven't really interacted with the Clojure 
 runtime, specifically the RT class, so its initiation machinery kicks in.
b. Down in the depths, it executes a transaction to add a library to 
 its list of loaded libraries.
c. The still-existing-but-not-running thread-local transaction, with 
 its existing action list intact, fires up, runs and commits.
d. The post-commit stuff runs, including a nested attempt to dispatch 
 that same action, again, which apparently succeeds.
e. The action list is cleared before exiting the run() method.
 7. Upon returning way back up the stack to our 
 not-quite-finished-post-processing transaction, we continue iterating the 
 now-cleared action list, which promptly throws the 
 ConcurrentModificationException.

 A quick perusal of the LockingTransaction code shows that the only 
 interaction with the action list is adding an item to it in the enqueue() 
 method, iterating it in the post-processing section of run() and clearing 
 it in the finally clause of that section, so it's easy to see how a 
 transaction started by any of the action-dispatching machinery would cause 
 problems.  Any such activity in the actions themselves would not be an 
 issue, since they'd occur on other threads, but the dispatch stuff all runs 
 on the same thread.  The few moving parts that occur in this code seem 
 fairly safe, as long as the runtime is already initialized, but if that 
 occurs during this phase, I think all bets are off.

 Does this analysis seem sound?  If so, is there a more formal process for 
 filing this as a bug?  I can probably create a nice, compact example to 
 reproduce it.

 Thanks!

 -Brandon :)


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

[Aaron Cohen]

On Wed, Sep 11, 2013 at 2:47 AM, Brandon Ibach brandon.l.ib...@gmail.comwrote:

 I have found what appears to be a bug in LockingTransaction, albeit one
 that probably wouldn't occur often.  But, I suppose that's a given for a
 previously undiscovered problem in oft-used code that hasn't changed for
 some while. :)

 I'm using the Clojure 1.4 library strictly from Java code and I have a
 fairly simple transaction which dispatches an action to an agent (send, not
 send-off).  When called from a JUnit test, such that we jump right in to
 things, skipping some of the initialization we normally do in our app, I
 get a ConcurrentModificationException from inside Locktransaction.run()
 while it is iterating through the actions list, dispatching the actions
 after committing the transaction.

 How are you calling send without the rest of clojure having been
initialized?



 Based on some debugging, here's what seems to be happening:

 1. My transaction is run, dispatching an action to an agent.
 2. The transaction completes and is successfully committed.
 3. LockingTransaction does post-commit cleanup, freeing locks and putting
 a stop() to the transaction, which nulls the transaction's Info object
 reference.
 4. Notifications are sent and we start iterating the list of actions to be
 dispatched.
 5. The run() method calls Agent.dispatchAction().  Because the thread's
 transaction is no longer running (due to the Info object being null) and
 no action is being processed on the thread (so its nested vector is
 null), the action is enqueue()d with the agent.
 6. As part of the enqueue process, the action is consed onto the agent's
 ActionQueue.  Here's where the unique circumstances come into play.
a. At this point, we haven't really interacted with the Clojure
 runtime, specifically the RT class, so its initiation machinery kicks in.
b. Down in the depths, it executes a transaction to add a library to
 its list of loaded libraries.
c. The still-existing-but-not-running thread-local transaction, with
 its existing action list intact, fires up, runs and commits.
d. The post-commit stuff runs, including a nested attempt to dispatch
 that same action, again, which apparently succeeds.
e. The action list is cleared before exiting the run() method.
 7. Upon returning way back up the stack to our
 not-quite-finished-post-processing transaction, we continue iterating the
 now-cleared action list, which promptly throws the
 ConcurrentModificationException.

 A quick perusal of the LockingTransaction code shows that the only
 interaction with the action list is adding an item to it in the enqueue()
 method, iterating it in the post-processing section of run() and clearing
 it in the finally clause of that section, so it's easy to see how a
 transaction started by any of the action-dispatching machinery would cause
 problems.  Any such activity in the actions themselves would not be an
 issue, since they'd occur on other threads, but the dispatch stuff all runs
 on the same thread.  The few moving parts that occur in this code seem
 fairly safe, as long as the runtime is already initialized, but if that
 occurs during this phase, I think all bets are off.



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

[Meikel Brandmeyer (kotarak)]

Hi,

without having a clear solution and without pinpointing to the exact issue, 
I remember seeing this before. Also in unit tests from Java. The person 
back then came up with the following solution.

He created a class from Clojure.

(ns your.app.CljApi
  (:gen-class))

(defn -init [])

And then calls as early as possible in his application:

static {
CljApi.init();
}

This initialiases the runtime and solved the problem for him.

Maybe a simple access to the Clojure runtime is also sufficient: 
RT.var(clojure.core, require). But I haven't tested that.

Kind regards
Meikel

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

Possible bug with realized? and cancelled futures

[Alex Nixon]

Hey all,

The docstring of clojure.core/realized? states  Returns true if a value
has been produced for a promise, delay, future or lazy sequence., however
calling realized? on a cancelled future returns true, despite the fact a
value *has not* been produced.

This is a problem because the print-method multimethod implementation for
clojure.lang.IDeref assumes that if the .isRealized method returns true,
it's safe to deref the instance.

Thus, attempting to print (with pr) a cancelled future throws a
CancellationException, in contrast to

   - agents which have thrown an exception: agent-error is called, and the
   exception is printed, and
   - delays which have thrown an exception: .isRealized returns false, so
   no deref is attempted and :pending is printed.

This inconsistency feels like a bug, but I'd like confirmation/thoughts in
case I'm missing something.

Thanks,
-- 
*Alex Nixon*

Software Engineer | SwiftKey

*a...@swiftkey.net** | http://www.swiftkey.net/*

++
WINNER - MOST INNOVATIVE MOBILE
APPhttp://www.swiftkey.net/swiftkey-wins-most-innovative-app-at-mwc
 - GSMA GLOBAL MOBILE AWARDS 2012

Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a
limited company registered in England and Wales, number 06671487.
Registered office: 91-95 Southwark Bridge Road, London, SE1 0AX

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

[Peter Taoussanis]

Hi Alex,

This is a problem because the print-method multimethod implementation for 
 clojure.lang.IDeref assumes that if the .isRealized method returns true, 
 it's safe to deref the instance.


That's interesting. I've run into the case before where a cancelled future 
was throwing an exception on print, and certainly found it quite strange. 
Didn't think to look into it. This must be a bug, surely?

  

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

[Alex Nixon]

Hey Peter,

On 19 February 2013 17:55, Peter Taoussanis ptaoussa...@gmail.com wrote:

 Hi Alex,

 This is a problem because the print-method multimethod implementation for
 clojure.lang.IDeref assumes that if the .isRealized method returns true,
 it's safe to deref the instance.


 That's interesting. I've run into the case before where a cancelled future
 was throwing an exception on print, and certainly found it quite strange.
 Didn't think to look into it. This must be a bug, surely?

Yeah it does seem like a bug to me.

Firstly, I think the mismatch between the clojure.core/realized? docstring
and the clojure.core/future implementation of isRealized should be fixed.
 This could prevent the exception being thrown when printing futures.
Secondly, I think it'd be nice if print-method was aware of futures (as it
is agents), and printed the exception or :cancelled, if that's the future's
state (and possibly the same for delays too; it seems strange to say print
:pending when they aren't).

-- 
*Alex Nixon*

Software Engineer | SwiftKey

*a...@swiftkey.net** | http://www.swiftkey.net/*

++
WINNER - MOST INNOVATIVE MOBILE
APPhttp://www.swiftkey.net/swiftkey-wins-most-innovative-app-at-mwc
 - GSMA GLOBAL MOBILE AWARDS 2012

Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a
limited company registered in England and Wales, number 06671487.
Registered office: 91-95 Southwark Bridge Road, London, SE1 0AX

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

[AtKaaZ]

also check this:
https://groups.google.com/d/msg/clojure/xlhDSPZGrL4/C9EGFvlqOZ8J


On Tue, Feb 19, 2013 at 7:13 PM, Alex Nixon a...@swiftkey.net wrote:

 Hey Peter,

 On 19 February 2013 17:55, Peter Taoussanis ptaoussa...@gmail.com wrote:

 Hi Alex,

 This is a problem because the print-method multimethod implementation for
 clojure.lang.IDeref assumes that if the .isRealized method returns true,
 it's safe to deref the instance.


 That's interesting. I've run into the case before where a cancelled
 future was throwing an exception on print, and certainly found it quite
 strange. Didn't think to look into it. This must be a bug, surely?

 Yeah it does seem like a bug to me.

 Firstly, I think the mismatch between the clojure.core/realized? docstring
 and the clojure.core/future implementation of isRealized should be fixed.
  This could prevent the exception being thrown when printing futures.
 Secondly, I think it'd be nice if print-method was aware of futures (as it
 is agents), and printed the exception or :cancelled, if that's the future's
 state (and possibly the same for delays too; it seems strange to say print
 :pending when they aren't).

 --
 *Alex Nixon*

 Software Engineer | SwiftKey

 *a...@swiftkey.net** | http://www.swiftkey.net/*

 ++
 WINNER - MOST INNOVATIVE MOBILE 
 APPhttp://www.swiftkey.net/swiftkey-wins-most-innovative-app-at-mwc
  - GSMA GLOBAL MOBILE AWARDS 2012

 Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a
 limited company registered in England and Wales, number 06671487.
 Registered office: 91-95 Southwark Bridge Road, London, SE1 0AX

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

[Marko Topolnik]

It could be that actually the *realized?* docstring needs change or 
clarification because a future can be realized in one of two ways: a value 
or a failure. Both count as realized in the sense that they are the *outcome
* of the future; in other words, *realized?* evaluating to true* *gives the 
crucial guarantee that *deref* won't block. The pitfall lies with the 
assumption that a future can only realize into a value.

On Tuesday, February 19, 2013 7:13:41 PM UTC+1, Alex Nixon wrote:

 Hey Peter,

 On 19 February 2013 17:55, Peter Taoussanis ptaou...@gmail.comjavascript:
  wrote:

 Hi Alex,

 This is a problem because the print-method multimethod implementation for 
 clojure.lang.IDeref assumes that if the .isRealized method returns true, 
 it's safe to deref the instance.


 That's interesting. I've run into the case before where a cancelled 
 future was throwing an exception on print, and certainly found it quite 
 strange. Didn't think to look into it. This must be a bug, surely?

 Yeah it does seem like a bug to me.

 Firstly, I think the mismatch between the clojure.core/realized? docstring 
 and the clojure.core/future implementation of isRealized should be fixed. 
  This could prevent the exception being thrown when printing futures.
 Secondly, I think it'd be nice if print-method was aware of futures (as it 
 is agents), and printed the exception or :cancelled, if that's the future's 
 state (and possibly the same for delays too; it seems strange to say print 
 :pending when they aren't).

 -- 
 *Alex Nixon*

 Software Engineer | SwiftKey

 *al...@swiftkey.net javascript:** | http://www.swiftkey.net/*

 ++
 WINNER - MOST INNOVATIVE MOBILE 
 APPhttp://www.swiftkey.net/swiftkey-wins-most-innovative-app-at-mwc
  - GSMA GLOBAL MOBILE AWARDS 2012

 Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a 
 limited company registered in England and Wales, number 06671487. 
 Registered office: 91-95 Southwark Bridge Road, London, SE1 0AX
  

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

[Shantanu Kumar]

On Feb 6, 11:42 am, Sean Corfield seancorfi...@gmail.com wrote:
 Andy's right on process... but as maintainer of clojure.java.jdbc, I
 have to ask: why on earth do you have column names containing spaces
 or  or other weird characters? That's a serious question: how do you
 get into that situation?

JDBC is an interface for SQL dialects, not necessarily for relational
data stores. For example, I've seen WBEM/CIM[1] exposed via JDBC. I am
not surprised to see spaces in column names. Quite often those
situations are not under the control of JDBC user.

[1] CIM: http://en.wikipedia.org/wiki/Common_Information_Model_(computing)

 I'm not saying clojure.java.jdbc can't be updated to support it, I'm
 just questioning whether it should...

I believe it should. The runtime configuration aspects (1. conversion
of column-name from Clojure to DB and vice versa, 2. wrapping of
Connection, Statement, PreparedStatement objects -- e.g. Excel JDBC-
ODBC connection doesn't support/throws exception on setAutoCommit, or
`long` data type that Clojure defaults to for ints) should be
extensible by the user.

Shantanu

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

[Sean Corfield]

Try this:

...
(jdbc/with-quoted-identifiers \
(jdbc/update-or-insert-values ...))
...

clojure.java.jdbc supports generic naming strategies that specify how to
wrap column names (going into JDBC) and how to convert column names (back
to Clojure keys on the way out of JDBC).

Different databases use different quoting conventions - MySQL supports
`column` for example. I think MS SQL Server supports [column] so you can do
that by passing a two element vector to with-quoted-identifiers [\[ \]]

By default, c.j.jdbc converts column names to lowercase keywords when
returning a resultset but you can use a naming strategy to override that
and return column names as-is, for example.

See the docs for more details:

http://clojure.github.com/java.jdbc/#clojure.java.jdbc/with-naming-strategy

Sean


On Tue, Feb 5, 2013 at 11:15 PM, a...@bitlimn.com wrote:

 @Andy: Sorry, I didn't know the proper channel, I'll post it there.

 I don't control the column names. They're imported from an excel
 spreadsheet or assigned by the client I'm writing the app for. From
 experience, it is certainly *possible*, at least to add these columns.
 Currently I just have a function that escapes the user input, replacing
 special characters with lookalikes (i.e. space with an underscore).

 On Tuesday, February 5, 2013 10:42:50 PM UTC-8, Sean Corfield wrote:

 Andy's right on process... but as maintainer of clojure.java.jdbc, I
 have to ask: why on earth do you have column names containing spaces
 or  or other weird characters? That's a serious question: how do you
 get into that situation?

 I'm not saying clojure.java.jdbc can't be updated to support it, I'm
 just questioning whether it should...

 On Tue, Feb 5, 2013 at 7:32 PM, Andy Fingerhut andy.fi...@gmail.com
 wrote:
  You can create a ticket for java.jdbc here if you wish that describes
 the problem and what you think will fix it.  Then any of the 500+ Clojure
 contributors can take a shot at fixing it:
 
  
  http://dev.clojure.org/jira/**browse/JDBChttp://dev.clojure.org/jira/browse/JDBC
 
  Andy
 
  On Feb 5, 2013, at 7:07 PM, al...@bitlimn.com wrote:
 
  Hey all,
 
  I've been using clojure.java.jdbc to write a simple database app. When
 I use the `update-or-insert-values` function, I get an SQLException thrown
 whenever my column names have special characters in them (like a space or
 an ampersand). I think the solution is in line 908: the column-strs should
 be quoted before calling `interpose`. If you do `(map #(str \ %1 \)
 column-strs)` that should do it?
 
  I can get around this by just writing my own version, but I wanted to
 patch it for everybody. I was told in #clojure that I can't? Anyways, I'm
 going to try to get in contact with the maintainer, but if anyone here has
 contributing rights, and would like to patch it, you have my thanks.
 
  --semisight
 
  --
  --
  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=enhttp://groups.google.com/group/clojure?hl=en
  ---
  You received this message because you 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_outhttps://groups.google.com/groups/opt_out.

 
 



 --
 Sean A Corfield -- (904) 302-SEAN
 An Architect's View -- http://corfield.org/
 World Singles, LLC. -- http://worldsingles.com/

 Perfection is the enemy of the good.
 -- Gustave Flaubert, French realist novelist (1821-1880)

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






-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to 

Possible bug in clojure.java.jdbc

[alex]

Hey all,

I've been using clojure.java.jdbc to write a simple database app. When I 
use the `update-or-insert-values` function, I get an SQLException thrown 
whenever my column names have special characters in them (like a space or 
an ampersand). I think the solution is in line 908: the column-strs should 
be quoted before calling `interpose`. If you do `(map #(str \ %1 \) 
column-strs)` that should do it?

I can get around this by just writing my own version, but I wanted to patch 
it for everybody. I was told in #clojure that I can't? Anyways, I'm going 
to try to get in contact with the maintainer, but if anyone here has 
contributing rights, and would like to patch it, you have my thanks.

--semisight

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

[Andy Fingerhut]

You can create a ticket for java.jdbc here if you wish that describes the 
problem and what you think will fix it.  Then any of the 500+ Clojure 
contributors can take a shot at fixing it:

http://dev.clojure.org/jira/browse/JDBC

Andy

On Feb 5, 2013, at 7:07 PM, a...@bitlimn.com wrote:

 Hey all,
 
 I've been using clojure.java.jdbc to write a simple database app. When I use 
 the `update-or-insert-values` function, I get an SQLException thrown whenever 
 my column names have special characters in them (like a space or an 
 ampersand). I think the solution is in line 908: the column-strs should be 
 quoted before calling `interpose`. If you do `(map #(str \ %1 \) 
 column-strs)` that should do it?
 
 I can get around this by just writing my own version, but I wanted to patch 
 it for everybody. I was told in #clojure that I can't? Anyways, I'm going to 
 try to get in contact with the maintainer, but if anyone here has 
 contributing rights, and would like to patch it, you have my thanks.
 
 --semisight

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

[Sean Corfield]

Andy's right on process... but as maintainer of clojure.java.jdbc, I
have to ask: why on earth do you have column names containing spaces
or  or other weird characters? That's a serious question: how do you
get into that situation?

I'm not saying clojure.java.jdbc can't be updated to support it, I'm
just questioning whether it should...

On Tue, Feb 5, 2013 at 7:32 PM, Andy Fingerhut andy.finger...@gmail.com wrote:
 You can create a ticket for java.jdbc here if you wish that describes the 
 problem and what you think will fix it.  Then any of the 500+ Clojure 
 contributors can take a shot at fixing it:

 http://dev.clojure.org/jira/browse/JDBC

 Andy

 On Feb 5, 2013, at 7:07 PM, a...@bitlimn.com wrote:

 Hey all,

 I've been using clojure.java.jdbc to write a simple database app. When I use 
 the `update-or-insert-values` function, I get an SQLException thrown 
 whenever my column names have special characters in them (like a space or an 
 ampersand). I think the solution is in line 908: the column-strs should be 
 quoted before calling `interpose`. If you do `(map #(str \ %1 \) 
 column-strs)` that should do it?

 I can get around this by just writing my own version, but I wanted to patch 
 it for everybody. I was told in #clojure that I can't? Anyways, I'm going to 
 try to get in contact with the maintainer, but if anyone here has 
 contributing rights, and would like to patch it, you have my thanks.

 --semisight

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





-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)

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

[alex]

@Andy: Sorry, I didn't know the proper channel, I'll post it there.

I don't control the column names. They're imported from an excel 
spreadsheet or assigned by the client I'm writing the app for. From 
experience, it is certainly *possible*, at least to add these columns. 
Currently I just have a function that escapes the user input, replacing 
special characters with lookalikes (i.e. space with an underscore).

On Tuesday, February 5, 2013 10:42:50 PM UTC-8, Sean Corfield wrote:

 Andy's right on process... but as maintainer of clojure.java.jdbc, I 
 have to ask: why on earth do you have column names containing spaces 
 or  or other weird characters? That's a serious question: how do you 
 get into that situation? 

 I'm not saying clojure.java.jdbc can't be updated to support it, I'm 
 just questioning whether it should... 

 On Tue, Feb 5, 2013 at 7:32 PM, Andy Fingerhut 
 andy.fi...@gmail.comjavascript: 
 wrote: 
  You can create a ticket for java.jdbc here if you wish that describes 
 the problem and what you think will fix it.  Then any of the 500+ Clojure 
 contributors can take a shot at fixing it: 
  
  http://dev.clojure.org/jira/browse/JDBC 
  
  Andy 
  
  On Feb 5, 2013, at 7:07 PM, al...@bitlimn.com javascript: wrote: 
  
  Hey all, 
  
  I've been using clojure.java.jdbc to write a simple database app. When 
 I use the `update-or-insert-values` function, I get an SQLException thrown 
 whenever my column names have special characters in them (like a space or 
 an ampersand). I think the solution is in line 908: the column-strs should 
 be quoted before calling `interpose`. If you do `(map #(str \ %1 \) 
 column-strs)` that should do it? 
  
  I can get around this by just writing my own version, but I wanted to 
 patch it for everybody. I was told in #clojure that I can't? Anyways, I'm 
 going to try to get in contact with the maintainer, but if anyone here has 
 contributing rights, and would like to patch it, you have my thanks. 
  
  --semisight 
  
  -- 
  -- 
  You received this message because you are subscribed to the Google 
  Groups Clojure group. 
  To post to this group, send email to clo...@googlegroups.comjavascript: 
  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 javascript: 
  For more options, visit this group at 
  http://groups.google.com/group/clojure?hl=en 
  --- 
  You received this message because you 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 javascript:. 
  For more options, visit https://groups.google.com/groups/opt_out. 
  
  



 -- 
 Sean A Corfield -- (904) 302-SEAN 
 An Architect's View -- http://corfield.org/ 
 World Singles, LLC. -- http://worldsingles.com/ 

 Perfection is the enemy of the good. 
 -- Gustave Flaubert, French realist novelist (1821-1880) 


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

Questions about some-fn and every-pred (possible bug, and improvements)

[Max Penet]

Hello, 

I am trying to understand the rationale behind the current implementation 
of some-fn and every-pred, there seems to be a couple of odd things, or 
maybe that is just me misunderstanding their doc.

user ((every-pred (fn [_])))
true
user ((some-fn (fn [_])))
nil

Shouldn't the first example return false? since the first function always 
returns nil? 

I was also wondering if it would make sense to add a 0 argument version of 
these, it would make their usage with apply more convenient, and comp which 
has a smiliar signature behaves like that: 

user ((comp) true)
true

user ((some-fn) true)
; Evaluation aborted.

user ((every-pred) true)
; Evaluation aborted.

Max

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

Re: Questions about some-fn and every-pred (possible bug, and improvements)

[Tassilo Horn]

Max Penet m...@qbits.cc writes:

 user ((every-pred (fn [_])))
 true
 user ((some-fn (fn [_])))
 nil

 Shouldn't the first example return false? since the first function
 always returns nil?

No.  ((every-pred a b c) o1 o2 ...) returns true if all predicates a, b,
and c return true for all given args o1, o2, and so one.  You don't pass
any args, so this is basically (and), which also returns true.  `and` is
true if all arguments are logically true, which is trivially given when
none are provided.

 I was also wondering if it would make sense to add a 0 argument
 version of these, it would make their usage with apply more
 convenient, and comp which has a smiliar signature behaves like that:

 user ((comp) true)
 true

 user ((some-fn) true)
 ; Evaluation aborted.

 user ((every-pred) true)
 ; Evaluation aborted.

(comp) is `identity` which makes sense.  What would the semantics be for
every-pred and some-fn?  IMO, it should be

user ((some-fn) no-matter-what)
false
user ((every-pred) no-matter-what)
true

e.g. (some-cn) was equivalent to (constantly false) and (every-pred) was
equivalent to (constantly true).

Bye,
Tassilo

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

Re: Questions about some-fn and every-pred (possible bug, and improvements)

[Max Penet]

user (every? identity [])
true

I think I understand now, this might be to match the behavior of every?.

Max

On Thursday, October 25, 2012 12:31:57 PM UTC+2, Max Penet wrote:

 Hello, 

 I am trying to understand the rationale behind the current implementation 
 of some-fn and every-pred, there seems to be a couple of odd things, or 
 maybe that is just me misunderstanding their doc.

 user ((every-pred (fn [_])))
 true
 user ((some-fn (fn [_])))
 nil

 Shouldn't the first example return false? since the first function always 
 returns nil? 

 I was also wondering if it would make sense to add a 0 argument version of 
 these, it would make their usage with apply more convenient, and comp which 
 has a smiliar signature behaves like that: 

 user ((comp) true)
 true

 user ((some-fn) true)
 ; Evaluation aborted.

 user ((every-pred) true)
 ; Evaluation aborted.

 Max


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

Re: Questions about some-fn and every-pred (possible bug, and improvements)

[Max Penet]

On Thursday, October 25, 2012 12:49:32 PM UTC+2, Tassilo Horn wrote:

 Max Penet m...@qbits.cc writes: 

  user ((every-pred (fn [_]))) 
  true 
  user ((some-fn (fn [_]))) 
  nil 
  
  Shouldn't the first example return false? since the first function 
  always returns nil? 

 No.  ((every-pred a b c) o1 o2 ...) returns true if all predicates a, b, 
 and c return true for all given args o1, o2, and so one.  You don't pass 
 any args, so this is basically (and), which also returns true.  `and` is 
 true if all arguments are logically true, which is trivially given when 
 none are provided. 


Ok that makes sense. 
 


  I was also wondering if it would make sense to add a 0 argument 
  version of these, it would make their usage with apply more 
  convenient, and comp which has a smiliar signature behaves like that: 
  
  user ((comp) true) 
  true 
  
  user ((some-fn) true) 
  ; Evaluation aborted. 
  
  user ((every-pred) true) 
  ; Evaluation aborted. 

 (comp) is `identity` which makes sense.  What would the semantics be for 
 every-pred and some-fn?  IMO, it should be 

 user ((some-fn) no-matter-what) 
 false 
 user ((every-pred) no-matter-what) 
 true 


 e.g. (some-cn) was equivalent to (constantly false) and (every-pred) was 
 equivalent to (constantly true). 


Yes I understand that, the proposal was just to avoid exceptions when used 
with apply, but this could end up be bit confusing maybe, and it can be 
tested beforehand anyway. 

Max

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

Re: Questions about some-fn and every-pred (possible bug, and improvements)

[Tassilo Horn]

Max Penet m...@qbits.cc writes:

Hi Max,

 user ((some-fn) no-matter-what) 
 false 
 user ((every-pred) no-matter-what) 
 true 

 e.g. (some-cn) was equivalent to (constantly false) and (every-pred) was 
 equivalent to (constantly true). 

 Yes I understand that, the proposal was just to avoid exceptions when
 used with apply, but this could end up be bit confusing maybe, and it
 can be tested beforehand anyway.

No, I think it's a valid request and it wouldn't be more confusing than
(and) = true (or) = false.  I'll create a ticket and patch for it.

Bye,
Tassilo

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

Re: Questions about some-fn and every-pred (possible bug, and improvements)

[Tassilo Horn]

Tassilo Horn t...@gnu.org writes:

 user ((some-fn) no-matter-what) 
 false 
 user ((every-pred) no-matter-what) 
 true 

 e.g. (some-cn) was equivalent to (constantly false) and (every-pred) was 
 equivalent to (constantly true). 

 Yes I understand that, the proposal was just to avoid exceptions when
 used with apply, but this could end up be bit confusing maybe, and it
 can be tested beforehand anyway.

 No, I think it's a valid request and it wouldn't be more confusing than
 (and) = true (or) = false.  I'll create a ticket and patch for it.

Done, see http://dev.clojure.org/jira/browse/CLJ-1094

In contrast to what's written above, I decided to make (some-fn) to be
(constantly nil), which matches the behavior of `some` better than
(constantly false).

Bye,
Tassilo

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

Re: Questions about some-fn and every-pred (possible bug, and improvements)

[Max Penet]

Thanks, perfect, I had prepared a patch that was identical.

On Thursday, October 25, 2012 2:11:44 PM UTC+2, Tassilo Horn wrote:

 Tassilo Horn ts...@gnu.org javascript: writes: 

  user ((some-fn) no-matter-what) 
  false 
  user ((every-pred) no-matter-what) 
  true 
  
  e.g. (some-cn) was equivalent to (constantly false) and (every-pred) 
 was 
  equivalent to (constantly true). 
  
  Yes I understand that, the proposal was just to avoid exceptions when 
  used with apply, but this could end up be bit confusing maybe, and it 
  can be tested beforehand anyway. 
  
  No, I think it's a valid request and it wouldn't be more confusing than 
  (and) = true (or) = false.  I'll create a ticket and patch for it. 

 Done, see http://dev.clojure.org/jira/browse/CLJ-1094 

 In contrast to what's written above, I decided to make (some-fn) to be 
 (constantly nil), which matches the behavior of `some` better than 
 (constantly false). 

 Bye, 
 Tassilo 


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

Possible bug in CLJS `case` with quoted symbols

[Shantanu Kumar]

Hello,

In Clojure 1.4.0 REPL I noticed this:

user= (let [a 'a] (case a nil :nil ' :amp :none))
:none
user= (let [a '] (case a nil :nil ' :amp :none))
:amp
user= (let [a 'b] (case a nil :nil 'b :b :none))
:b

In the CLJS Rhino REPL I saw this:

ClojureScript:cljs.user (let [a 'a] (case a nil :nil ' :amp :none))
:none
ClojureScript:cljs.user (let [a '] (case a nil :nil ' :amp :none))
:none
ClojureScript:cljs.user (let [a 'b] (case a nil :nil 'b :b :none))
:none

If somebody confirms that it looks like a bug, I can file an issue.

Shantanu

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

Re: Possible bug in CLJS `case` with quoted symbols

[David Nolen]

On Fri, Sep 7, 2012 at 5:26 AM, Shantanu Kumar kumar.shant...@gmail.com wrote:
 Hello,

 In Clojure 1.4.0 REPL I noticed this:

 user= (let [a 'a] (case a nil :nil ' :amp :none))
 :none
 user= (let [a '] (case a nil :nil ' :amp :none))
 :amp
 user= (let [a 'b] (case a nil :nil 'b :b :none))
 :b

 In the CLJS Rhino REPL I saw this:

 ClojureScript:cljs.user (let [a 'a] (case a nil :nil ' :amp :none))
 :none
 ClojureScript:cljs.user (let [a '] (case a nil :nil ' :amp :none))
 :none
 ClojureScript:cljs.user (let [a 'b] (case a nil :nil 'b :b :none))
 :none

 If somebody confirms that it looks like a bug, I can file an issue.

 Shantanu

Looks like a bug.

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

Re: Possible bug in CLJS `case` with quoted symbols

[Shantanu Kumar]

 Looks like a bug.

Thanks, I filed the issue here:

http://dev.clojure.org/jira/browse/CLJS-376

Shantanu

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

Possible bug in reducer code? Or dead code? Or derp on my part?

[retnuH]

Hi there, I've been browsing through the code trying to wrap my head the 
new reducers library.

I came across 2 functions called 'reduce' in APersistentVector.java around 
line 447.  The don't have the same 'reduced?' check that ArrayChunk.java 
has in it's implementation of reduce (around line 57 or so).

Now, as far as I can tell, those 2 reduce functions aren't actually 
reachable through the normal reduce code-path, but that's only based on 
what I could tell - I'm certainly no expert on clojure internals!  But it 
did occur to me that they could still be called directly.

So I'm just wondering if this is a latent bug-in-waiting, or dead code, or 
a misundersting on my part.

Cheers,

H

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

Re: Possible bug in reducer code? Or dead code? Or derp on my part?

[Timothy Baldridge]

Before we had reducers we had a optimization (and still have this
optimization) called internal-reduce:

https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/protocols.clj#L86

If you run reduce on a seq, then your only option is to walk through
the structure one cell at a time, doing if null checks at each step,
and then invoking next, first, etc. However with vectors, there's a
better way, simply use a loop with a index to the current item.

So the idea was that Clojure defines a protocol called
internal-reduce you can extend any datatype (for instance strings)
to support this protocol, and then reduce in anyone's code will use
this fast path when reducing your collection. This means that

(reduce + [1 2 3 4 5])

will be faster than

(reduce + (seq [1 2 3 4 5]))

And in the case of vectors gets around the problem of allocating a new
indexed seq on each call to (next). Also see
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/protocols.clj#L94

Hope this helps,

Timothy

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

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[mnicky]

Wow. Thanks, Cedric. I'll definitely look into those options...

On Sunday, March 25, 2012 4:28:04 AM UTC+2, Cedric Greevey wrote:

 On Sat, Mar 24, 2012 at 9:39 PM, Cedric Greevey cgree...@gmail.com 
 wrote:
  In increasing order of difficulty...
 
  Option 1:
 
  Extend your comparator to sort first on the key you're actually
  interested in, then if that key isn't different on the others
  more-or-less arbitrarily.

 Or use this:

 (defn po-to [po]
   (let [m (atom #{})]
 (fn [a b]
   (or
 (po a b)
 (and
   (not (po b a))
   (or
 ( (hash a) (hash b))
 (and
   (== (hash a) (hash b))
   (not= a b)
   (or (contains? @m [a b])
 (and
   (not (contains? @m [b a]))
   (swap! m conj [a b]))

 (defn sorted-set-po [po  keys]
   (apply sorted-set-by (po-to po) keys))

 Input: a partial order (may be true for a b, true for b a, or false for 
 both).

 Output: a sorted-set that uses a total order built from the partial
 order. For things where the po says neither a  b nor b  a, it will
 first compare their hashes. If those don't collide, the order of a and
 b is decided that way. If they do, and a and b are not actually equal,
 it will arbitrarily pick one to be less than the other and remember
 its decision so that the ordering of unequal, hash-colliding items
 will remain consistent.

 Notes:
 1. The memory use can grow over time due to the memoization-like
 behavior using the atom. However, this only occurs for items with both
 order and hash collisions, which should be extraordinarily infrequent.
 (If hashes were uniform on [0,2^32-1] you'd need an average of around
 65,000 items before, per the birthday paradox, a single collision was
 likely within your collection. And then it would probably be for a
 pair of items that po considered unequal.) So the memory use growth
 should be small (for collections of thousands to millions of items) to
 nonexistent (for smaller ones).

 2. Two sorted-set-pos with the same items, where they were added in
 different sequences, may not sort them in the same order, though this
 should be rare (again tied to the frequency of order+hash collisions).
 But this is not really a problem since, if you're sorting with a
 partial order, it makes sense to consider the ordering within equality
 buckets of the partial order to be undefined (the way ordering of an
 entire hash-set is undefined) and thus does not make sense to make
 program semantics depend on the ordering. Also, all sets compare equal
 purely by having the same contents (I checked APersistentSet.java to
 be sure) so the two sorted-set-pos would still compare equal despite
 traversing their elements in slightly different sequences.

 Here's a clooj REPL session testing po-to. Note that the last tests
 intentionally induce an order+hash collision of unequal items and
 check that the same instance of a po-to produces consistent results
 when given the colliding items in either order (that is, it always
 returns logical true when given the items in one order and always
 returns logical false when given them in the opposite order). The very
 last tests verify that it always returns false for equal items.

 user=
 (def foo (po-to #( (:a %1) (:a %2
 #'user/foo

 user=
 (foo {:a 1 :b 1} {:a 2 :b 1})
 true

 user=
 (foo {:a 1 :b 1} {:a 2 :b 1})
 true

 user=
 (foo {:a 1 :b 1} {:a 2 :b 1})
 true

 user=
 (foo {:a 2 :b 1} {:a 1 :b 1})
 false

 user=
 (foo {:a 2 :b 1} {:a 1 :b 1})
 false

 user=
 (foo {:a 1 :b 1} {:a 1 :b 2})
 true

 user=
 (foo {:a 1 :b 1} {:a 1 :b 2})
 true

 user=
 (foo {:a 1 :b 1} {:a 1 :b 2})
 true

 user=
 (foo {:a 1 :b 2} {:a 1 :b 1})
 false

 user=
 (foo {:a 1 :b 2} {:a 1 :b 1})
 false

 user=
 (foo {:a 1 :b 2} {:a 1 :b 1})
 false

 user=
 (hash {:a 1 :b 1 :c 1})
 -1253235521

 user=
 (hash {:a 1 :b 1 :c 2})
 -1253235522

 user=
 (hash {:a 1 :b 2 :c 1})
 -1253235520

 user=
 (hash {:a 1 :b 0 :c 1})
 -1253235522

 user=
 (foo {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
 #{[{:a 1, :c 2, :b 1} {:a 1, :c 1, :b 0}]}

 user=
 (foo {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
 true

 user=
 (foo {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
 true

 user=
 (foo {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
 false

 user=
 (foo {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
 false

 user=
 (foo {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
 false

 user=
 (def bar (po-to #( (:a %1) (:a %2
 #'user/bar

 user=
 (bar {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
 #{[{:a 1, :c 1, :b 0} {:a 1, :c 2, :b 1}]}

 user=
 (bar {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
 true

 user=
 (bar {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
 false

 user=
 (bar {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
 false

 user=
 (bar {:a 1 :b 1 :c 2} {:a 1 :b 1 :c 2})
 false

 user=
 (bar {:a 1 :b 1 :c 2} {:a 1 :b 1 :c 2})
 false

 user=
 (bar {:a 1 :b 0 :c 1} {:a 1 :b 0 :c 1})
 false

 user=
 (bar {:a 1 :b 0 :c 1} {:a 1 :b 0 :c 1})
 false


On Sunday, March 25, 2012 4:28:04 AM UTC+2, 

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[mnicky]

Thanks for the explanations!
So is there a way to build a set or map that has sorting property 
independent from the element lookup?

On Friday, March 16, 2012 2:03:15 AM UTC+1, Alan Malloy wrote:

 And this is exactly as it should be. The sorted set has no way to 
 compare items other than by your comparator. If it just arbitrarily 
 decided to use = instead of checking that (zero? (compare x y)) it 
 would not be using your comparator. 

 Note also that the behavior of contains? is consistent with conj and 
 disj: if the item is contained in the set, then conj will keep size 
 the same and disj will decrease it; otherwise conj will increase the 
 size and disj will leave it the same. 

 On Mar 15, 3:39 pm, Stuart Campbell stu...@harto.org wrote: 
  Actually, sorted-map-by does behave the same way, but in your example 
 you 
  tried to lookup a value instead of a key: 
  
  user (def m (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b])) 
  #'user/m 
  user (get m [1 :foo]) 
  [2 :b] 
  
  It looks like PersistentTreeMap.entryAt
 http​s://github.com/clojure/​clojure/blob/master/src/jvm/​clojure/lang/P..https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/P...is
  

  responsible for this behaviour. 
  
  Regards, 
  Stuart 
  
  On 13 March 2012 05:20, mnicky markus.mas...@gmail.com wrote: 
  
   It seems that when using the sorted set with my own comparator 
   (sorted-set-by), 
   the lookup via 'contains?' function is based only on the part of the 
 items 
   that participate in the ordering: 
  
   (contains? (sorted-set [1 :a] [2 :b]) [2 :c]) 
   ;= false 
  
   (contains? (sorted-set-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c]) 
   ;= true 
  
   The documentation of 'sorted-set-by' says that the _whole_ items are 
 keys: 
  
   (doc sorted-set-by) 
   ; clojure.core/sorted-set-by 
   ; ([comparator  keys]) 
   ; Returns a new sorted set with supplied keys, using the supplied 
   comparator. 
   ; nil 
  
   So according to the documentation of 'contains?', it should do lookup 
   based on the whole items, not just their parts used in the comparator: 
  
   (doc contains?) 
   ; clojure.core/contains? 
   ; ([coll key]) 
   ; Returns true if key is present in the given collection, otherwise 
   ; returns false. Note that for numerically indexed collections like 
   ; vectors and Java arrays, this tests if the numeric key is within the 
   ; range of indexes. 'contains?' operates constant or logarithmic time; 
   ; it will not perform a linear search for a value. See also 'some'. 
   ; nil 
  
   It's also worth noting that 'sorted-map-by' doesn't behave in this 
 way: 
  
   (contains? (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c]) 
   ;= false 
  
   Can this be a bug? If not, what's the reason behind this behavior? 
  
   -- Mnicky 
  
-- 
   You received this message because you are subscribed to the Google 
   Groups Clojure group. 
   To post to this group, send email to clojure@googlegroups.com 
   Note that posts from new members are moderated - please be patient 
 with 
   your first post. 
   To unsubscribe from this group, send email to 
   clojure+unsubscribe@​googlegroups.comclojure%2bunsubscr...@googlegroups.com

   For more options, visit this group at 
  http://groups.google.com/​group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en


On Friday, March 16, 2012 2:03:15 AM UTC+1, Alan Malloy wrote:

 And this is exactly as it should be. The sorted set has no way to 
 compare items other than by your comparator. If it just arbitrarily 
 decided to use = instead of checking that (zero? (compare x y)) it 
 would not be using your comparator. 

 Note also that the behavior of contains? is consistent with conj and 
 disj: if the item is contained in the set, then conj will keep size 
 the same and disj will decrease it; otherwise conj will increase the 
 size and disj will leave it the same. 

 On Mar 15, 3:39 pm, Stuart Campbell stu...@harto.org wrote: 
  Actually, sorted-map-by does behave the same way, but in your example 
 you 
  tried to lookup a value instead of a key: 
  
  user (def m (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b])) 
  #'user/m 
  user (get m [1 :foo]) 
  [2 :b] 
  
  It looks like PersistentTreeMap.entryAt
 http​s://github.com/clojure/​clojure/blob/master/src/jvm/​clojure/lang/P..https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/P...is
  

  responsible for this behaviour. 
  
  Regards, 
  Stuart 
  
  On 13 March 2012 05:20, mnicky markus.mas...@gmail.com wrote: 
  
   It seems that when using the sorted set with my own comparator 
   (sorted-set-by), 
   the lookup via 'contains?' function is based only on the part of the 
 items 
   that participate in the ordering: 
  
   (contains? (sorted-set [1 :a] [2 :b]) [2 :c]) 
   ;= false 
  
   (contains? (sorted-set-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c]) 
   ;= true 
  
   The documentation of 'sorted-set-by' says that the _whole_ items are 
 keys: 
  
   

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[Philip Potter]

There's java.util.LinkedHashSet:

http://docs.oracle.com/javase/6/docs/api/java/util/LinkedHashSet.html

Its iterator will preserve insertion order, but it will ignore duplicates
when inserted. It has a number of disadvantages:

* only available on clj-jvm
* not a persistent data structure, with all the pain that brings
* doesn't permit arbitrary iterator orders,  only insertion order

It would be an interesting exercise to reimplement Linkedhashset as a
persistent data structure, implementing IPersistentSet and Seqable.

Phil
On Mar 24, 2012 1:29 PM, mnicky markus.mas...@gmail.com wrote:

 Thanks for the explanations!
 So is there a way to build a set or map that has sorting property
 independent from the element lookup?

 On Friday, March 16, 2012 2:03:15 AM UTC+1, Alan Malloy wrote:

 And this is exactly as it should be. The sorted set has no way to
 compare items other than by your comparator. If it just arbitrarily
 decided to use = instead of checking that (zero? (compare x y)) it
 would not be using your comparator.

 Note also that the behavior of contains? is consistent with conj and
 disj: if the item is contained in the set, then conj will keep size
 the same and disj will decrease it; otherwise conj will increase the
 size and disj will leave it the same.

 On Mar 15, 3:39 pm, Stuart Campbell stu...@harto.org wrote:
  Actually, sorted-map-by does behave the same way, but in your example
 you
  tried to lookup a value instead of a key:
 
  user (def m (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]))
  #'user/m
  user (get m [1 :foo])
  [2 :b]
 
  It looks like PersistentTreeMap.entryAt
 http​s://github.com/clojure/​clojure/blob/master/src/jvm/​clojure/lang/P..https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/P...is

  responsible for this behaviour.
 
  Regards,
  Stuart
 
  On 13 March 2012 05:20, mnicky markus.mas...@gmail.com wrote:
 
   It seems that when using the sorted set with my own comparator
   (sorted-set-by),
   the lookup via 'contains?' function is based only on the part of the
 items
   that participate in the ordering:
 
   (contains? (sorted-set [1 :a] [2 :b]) [2 :c])
   ;= false
 
   (contains? (sorted-set-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
   ;= true
 
   The documentation of 'sorted-set-by' says that the _whole_ items are
 keys:
 
   (doc sorted-set-by)
   ; clojure.core/sorted-set-by
   ; ([comparator  keys])
   ; Returns a new sorted set with supplied keys, using the supplied
   comparator.
   ; nil
 
   So according to the documentation of 'contains?', it should do lookup
   based on the whole items, not just their parts used in the
 comparator:
 
   (doc contains?)
   ; clojure.core/contains?
   ; ([coll key])
   ; Returns true if key is present in the given collection, otherwise
   ; returns false. Note that for numerically indexed collections like
   ; vectors and Java arrays, this tests if the numeric key is within
 the
   ; range of indexes. 'contains?' operates constant or logarithmic
 time;
   ; it will not perform a linear search for a value. See also 'some'.
   ; nil
 
   It's also worth noting that 'sorted-map-by' doesn't behave in this
 way:
 
   (contains? (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
   ;= false
 
   Can this be a bug? If not, what's the reason behind this behavior?
 
   -- Mnicky
 
--
   You received this message because you are subscribed to the Google
   Groups Clojure group.
   To post to this group, send email to clojure@googlegroups.com
   Note that posts from new members are moderated - please be patient
 with
   your first post.
   To unsubscribe from this group, send email to
   clojure+unsubscribe@​googlegroups.comclojure%2bunsubscr...@googlegroups.com
   For more options, visit this group at
  http://groups.google.com/​group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en


 On Friday, March 16, 2012 2:03:15 AM UTC+1, Alan Malloy wrote:

 And this is exactly as it should be. The sorted set has no way to
 compare items other than by your comparator. If it just arbitrarily
 decided to use = instead of checking that (zero? (compare x y)) it
 would not be using your comparator.

 Note also that the behavior of contains? is consistent with conj and
 disj: if the item is contained in the set, then conj will keep size
 the same and disj will decrease it; otherwise conj will increase the
 size and disj will leave it the same.

 On Mar 15, 3:39 pm, Stuart Campbell stu...@harto.org wrote:
  Actually, sorted-map-by does behave the same way, but in your example
 you
  tried to lookup a value instead of a key:
 
  user (def m (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]))
  #'user/m
  user (get m [1 :foo])
  [2 :b]
 
  It looks like PersistentTreeMap.entryAt
 http​s://github.com/clojure/​clojure/blob/master/src/jvm/​clojure/lang/P..https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/P...is

  responsible for this behaviour.
 
  Regards,
  Stuart
 
  On 13 March 2012 05:20, 

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[Cedric Greevey]

In increasing order of difficulty...

Option 1:

Extend your comparator to sort first on the key you're actually
interested in, then if that key isn't different on the others
more-or-less arbitrarily.

Option 2:

Keep the data unsorted in a hash-set. Sort when you need sorted data,
e.g. for user presentation, by using a sort function that outputs a
seq. (Inefficient if the sort will then be performed often for a given
set.)

Option 3:

Implement your own sorted set type that handles sort-order collisions
by having plain sets as equality buckets, using deftype, gen-class, or
Java.

Option 4:

Convince Rich Hickey that having the built in sorted-set not deal with
order collisions (ala Option 3, above) is as silly as if he'd had
hash-set not deal with hash collisions. :)

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

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[Cedric Greevey]

On Sat, Mar 24, 2012 at 9:39 PM, Cedric Greevey cgree...@gmail.com wrote:
 In increasing order of difficulty...

 Option 1:

 Extend your comparator to sort first on the key you're actually
 interested in, then if that key isn't different on the others
 more-or-less arbitrarily.

Or use this:

(defn po-to [po]
  (let [m (atom #{})]
(fn [a b]
  (or
(po a b)
(and
  (not (po b a))
  (or
( (hash a) (hash b))
(and
  (== (hash a) (hash b))
  (not= a b)
  (or (contains? @m [a b])
(and
  (not (contains? @m [b a]))
  (swap! m conj [a b]))

(defn sorted-set-po [po  keys]
  (apply sorted-set-by (po-to po) keys))

Input: a partial order (may be true for a b, true for b a, or false for both).

Output: a sorted-set that uses a total order built from the partial
order. For things where the po says neither a  b nor b  a, it will
first compare their hashes. If those don't collide, the order of a and
b is decided that way. If they do, and a and b are not actually equal,
it will arbitrarily pick one to be less than the other and remember
its decision so that the ordering of unequal, hash-colliding items
will remain consistent.

Notes:
1. The memory use can grow over time due to the memoization-like
behavior using the atom. However, this only occurs for items with both
order and hash collisions, which should be extraordinarily infrequent.
(If hashes were uniform on [0,2^32-1] you'd need an average of around
65,000 items before, per the birthday paradox, a single collision was
likely within your collection. And then it would probably be for a
pair of items that po considered unequal.) So the memory use growth
should be small (for collections of thousands to millions of items) to
nonexistent (for smaller ones).

2. Two sorted-set-pos with the same items, where they were added in
different sequences, may not sort them in the same order, though this
should be rare (again tied to the frequency of order+hash collisions).
But this is not really a problem since, if you're sorting with a
partial order, it makes sense to consider the ordering within equality
buckets of the partial order to be undefined (the way ordering of an
entire hash-set is undefined) and thus does not make sense to make
program semantics depend on the ordering. Also, all sets compare equal
purely by having the same contents (I checked APersistentSet.java to
be sure) so the two sorted-set-pos would still compare equal despite
traversing their elements in slightly different sequences.

Here's a clooj REPL session testing po-to. Note that the last tests
intentionally induce an order+hash collision of unequal items and
check that the same instance of a po-to produces consistent results
when given the colliding items in either order (that is, it always
returns logical true when given the items in one order and always
returns logical false when given them in the opposite order). The very
last tests verify that it always returns false for equal items.

user=
(def foo (po-to #( (:a %1) (:a %2
#'user/foo

user=
(foo {:a 1 :b 1} {:a 2 :b 1})
true

user=
(foo {:a 1 :b 1} {:a 2 :b 1})
true

user=
(foo {:a 1 :b 1} {:a 2 :b 1})
true

user=
(foo {:a 2 :b 1} {:a 1 :b 1})
false

user=
(foo {:a 2 :b 1} {:a 1 :b 1})
false

user=
(foo {:a 1 :b 1} {:a 1 :b 2})
true

user=
(foo {:a 1 :b 1} {:a 1 :b 2})
true

user=
(foo {:a 1 :b 1} {:a 1 :b 2})
true

user=
(foo {:a 1 :b 2} {:a 1 :b 1})
false

user=
(foo {:a 1 :b 2} {:a 1 :b 1})
false

user=
(foo {:a 1 :b 2} {:a 1 :b 1})
false

user=
(hash {:a 1 :b 1 :c 1})
-1253235521

user=
(hash {:a 1 :b 1 :c 2})
-1253235522

user=
(hash {:a 1 :b 2 :c 1})
-1253235520

user=
(hash {:a 1 :b 0 :c 1})
-1253235522

user=
(foo {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
#{[{:a 1, :c 2, :b 1} {:a 1, :c 1, :b 0}]}

user=
(foo {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
true

user=
(foo {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
true

user=
(foo {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
false

user=
(foo {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
false

user=
(foo {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
false

user=
(def bar (po-to #( (:a %1) (:a %2
#'user/bar

user=
(bar {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
#{[{:a 1, :c 1, :b 0} {:a 1, :c 2, :b 1}]}

user=
(bar {:a 1 :b 0 :c 1} {:a 1 :b 1 :c 2})
true

user=
(bar {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
false

user=
(bar {:a 1 :b 1 :c 2} {:a 1 :b 0 :c 1})
false

user=
(bar {:a 1 :b 1 :c 2} {:a 1 :b 1 :c 2})
false

user=
(bar {:a 1 :b 1 :c 2} {:a 1 :b 1 :c 2})
false

user=
(bar {:a 1 :b 0 :c 1} {:a 1 :b 0 :c 1})
false

user=
(bar {:a 1 :b 0 :c 1} {:a 1 :b 0 :c 1})
false

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

'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[mnicky]

It seems that when using the sorted set with my own comparator 
(sorted-set-by),
the lookup via 'contains?' function is based only on the part of the items
that participate in the ordering:

(contains? (sorted-set [1 :a] [2 :b]) [2 :c])
;= false

(contains? (sorted-set-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
;= true

The documentation of 'sorted-set-by' says that the _whole_ items are keys:

(doc sorted-set-by)
; clojure.core/sorted-set-by
; ([comparator  keys])
; Returns a new sorted set with supplied keys, using the supplied 
comparator.
; nil

So according to the documentation of 'contains?', it should do lookup
based on the whole items, not just their parts used in the comparator:

(doc contains?)
; clojure.core/contains?
; ([coll key])
; Returns true if key is present in the given collection, otherwise
; returns false. Note that for numerically indexed collections like
; vectors and Java arrays, this tests if the numeric key is within the
; range of indexes. 'contains?' operates constant or logarithmic time;
; it will not perform a linear search for a value. See also 'some'.
; nil


It's also worth noting that 'sorted-map-by' doesn't behave in this way:

(contains? (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
;= false

Can this be a bug? If not, what's the reason behind this behavior?


-- Mnicky

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

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[Stuart Campbell]

Actually, sorted-map-by does behave the same way, but in your example you
tried to lookup a value instead of a key:

user (def m (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]))
#'user/m
user (get m [1 :foo])
[2 :b]

It looks like 
PersistentTreeMap.entryAthttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentTreeMap.java#L285is
responsible for this behaviour.

Regards,
Stuart

On 13 March 2012 05:20, mnicky markus.mas...@gmail.com wrote:

 It seems that when using the sorted set with my own comparator
 (sorted-set-by),
 the lookup via 'contains?' function is based only on the part of the items
 that participate in the ordering:

 (contains? (sorted-set [1 :a] [2 :b]) [2 :c])
 ;= false

 (contains? (sorted-set-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
 ;= true

 The documentation of 'sorted-set-by' says that the _whole_ items are keys:

 (doc sorted-set-by)
 ; clojure.core/sorted-set-by
 ; ([comparator  keys])
 ; Returns a new sorted set with supplied keys, using the supplied
 comparator.
 ; nil

 So according to the documentation of 'contains?', it should do lookup
 based on the whole items, not just their parts used in the comparator:

 (doc contains?)
 ; clojure.core/contains?
 ; ([coll key])
 ; Returns true if key is present in the given collection, otherwise
 ; returns false. Note that for numerically indexed collections like
 ; vectors and Java arrays, this tests if the numeric key is within the
 ; range of indexes. 'contains?' operates constant or logarithmic time;
 ; it will not perform a linear search for a value. See also 'some'.
 ; nil


 It's also worth noting that 'sorted-map-by' doesn't behave in this way:

 (contains? (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
 ;= false

 Can this be a bug? If not, what's the reason behind this behavior?


 -- Mnicky

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

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

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[Mark Engelberg]

It's not a problem with Clojure, it's also how Java behaves.

For sorted-sets to work properly, your comparator *must* satisfy the
trichotomy property of orderings.

Consider a comparison predicate less?.  The trichotomy property states that
for all x,y, exactly one of the following hold:
(less? x y)
(less? y x)
(= x y)

In other words, if two things are treated by your comparison as equal,
they must actually be equal in the = sense.

That's the issue.

[1 :foo] and [1 :bar] are such that neither is considered less than the
other, but neither are they equal.  So your comparison operator does not
work properly.

Another way of thinking about is that your comparison operator must set up
a strict linear order among all nonequal elements.  If you take two unequal
things, one must come out to be less than the other.

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

Re: 'contains?' on 'sorted-set-by' based on the comparator only? (possible bug?)

[Alan Malloy]

And this is exactly as it should be. The sorted set has no way to
compare items other than by your comparator. If it just arbitrarily
decided to use = instead of checking that (zero? (compare x y)) it
would not be using your comparator.

Note also that the behavior of contains? is consistent with conj and
disj: if the item is contained in the set, then conj will keep size
the same and disj will decrease it; otherwise conj will increase the
size and disj will leave it the same.

On Mar 15, 3:39 pm, Stuart Campbell stu...@harto.org wrote:
 Actually, sorted-map-by does behave the same way, but in your example you
 tried to lookup a value instead of a key:

 user (def m (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]))
 #'user/m
 user (get m [1 :foo])
 [2 :b]

 It looks like 
 PersistentTreeMap.entryAthttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/P...is
 responsible for this behaviour.

 Regards,
 Stuart

 On 13 March 2012 05:20, mnicky markus.mas...@gmail.com wrote:

  It seems that when using the sorted set with my own comparator
  (sorted-set-by),
  the lookup via 'contains?' function is based only on the part of the items
  that participate in the ordering:

  (contains? (sorted-set [1 :a] [2 :b]) [2 :c])
  ;= false

  (contains? (sorted-set-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
  ;= true

  The documentation of 'sorted-set-by' says that the _whole_ items are keys:

  (doc sorted-set-by)
  ; clojure.core/sorted-set-by
  ; ([comparator  keys])
  ; Returns a new sorted set with supplied keys, using the supplied
  comparator.
  ; nil

  So according to the documentation of 'contains?', it should do lookup
  based on the whole items, not just their parts used in the comparator:

  (doc contains?)
  ; clojure.core/contains?
  ; ([coll key])
  ; Returns true if key is present in the given collection, otherwise
  ; returns false. Note that for numerically indexed collections like
  ; vectors and Java arrays, this tests if the numeric key is within the
  ; range of indexes. 'contains?' operates constant or logarithmic time;
  ; it will not perform a linear search for a value. See also 'some'.
  ; nil

  It's also worth noting that 'sorted-map-by' doesn't behave in this way:

  (contains? (sorted-map-by #( (%1 0) (%2 0)) [1 :a] [2 :b]) [2 :c])
  ;= false

  Can this be a bug? If not, what's the reason behind this behavior?

  -- Mnicky

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

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

possible bug in cl-format (rounding floating-point number)

[Travis Treseder]

I didn't see this as an open issue on the JIRA bug list, so I thought
I would ask about it here.

 (cl-format nil ~,5f -434343.867071)
-434343.86707
 (cl-format nil ~,5f -434343.867072)
-434343.86707
 (cl-format nil ~,5f -434343.867075)

For input string: 43434386707
  [Thrown class java.lang.NumberFormatException]

Backtrace:
  0: 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
  1: java.lang.Integer.parseInt(Integer.java:461)
  2: java.lang.Integer.valueOf(Integer.java:554)
  3: clojure.pprint$round_str.invoke(cl_format.clj:585)


After looking at the round-str function, it appears that if round-char
= 5, then result is parsed by Integer.valueOf(result), which causes
an exception if result is too large.  I rewrote part of it to use
BigInteger, and it seemed to fix the problem, but I didn't test it
extensively.  It might be a valid solution in any case.

Incidentally, I love using clojure.pprint.  It's powerful, and after
diving into the CLM spec I have new appreciation for the daunting task
it must be to test it.

-Travis

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

Re: possible bug in `case'

[Alex Osborne]

Eric Schulte schulte.e...@gmail.com writes:

 Hi,

 The following case statement

   #+begin_src clojure
 (defn buggy-case [n]
   (case (int n)
 0  :null
 1  :load
 0x7000 :loproc))
   #+end_src

 throws the following error

   No distinct mapping found
 [Thrown class java.lang.IllegalArgumentException]

 However removing any of the cases alleviates the problem.  Am I missing
 something obvious, or is this a bug in the case statement?

Interesting!  I hadn't looked at how case was implemented before.  It
takes the keys and then finds a shift and bitmask which can be used to
differentiate them with a minimum number of contiguous bits.  The
private function clojure.core/min-hash is used to do this.  For example
if you have the case keys 0x400, 0x500 and 0x7700 then:

(min-hash [0x400 0x500 0x7700]) = [8 3]

Which means bit-shift-right by 8 bits and then bitwise-and by 3.  So if
we apply that to our keys we get:

(map #(shift-mask 8 3 %) [0x400 0x500 0x7700]) = (0 1 3)

The resulting values are then turned into a jump table which the
tableswitch JVM instruction dispatches on.

The maximum size of the mask is 14 bits, presumably as that's the
maximum the tableswitch instruction supports.

Now the problem in your case is there's no simple shift mask that is
unique.   If we write your keys in binary then the problem is obvious:

000
001
111
  ^-^

000
001
111
^-^

There's no way to position the 14-bit mask (the ^-^ in my
diagram) to obtain a unique result.

It looks like Java's switch statement falls back to the lookupswitch
instruction which is apparently usually implemented with a binary
search.  That doesn't seem to be implemented in Clojure and would in any
case be breaking the constant time contract the case macro's docstring
mentions (binary search is logarithmic time).

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

Re: possible bug in `case'

[Stuart Halloway]

This is on the release roadmap for 1.3: 
http://dev.clojure.org/jira/browse/CLJ-426.

Volunteers welcome!

Stu

 Hi,
 
 The following case statement
 
  #+begin_src clojure
(defn buggy-case [n]
  (case (int n)
0  :null
1  :load
0x7000 :loproc))
  #+end_src
 
 throws the following error
 
  No distinct mapping found
[Thrown class java.lang.IllegalArgumentException]
 
 However removing any of the cases alleviates the problem.  Am I missing
 something obvious, or is this a bug in the case statement?
 
 Thanks -- Eric
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

possible bug in `case'

[Eric Schulte]

Hi,

The following case statement

  #+begin_src clojure
(defn buggy-case [n]
  (case (int n)
0  :null
1  :load
0x7000 :loproc))
  #+end_src

throws the following error

  No distinct mapping found
[Thrown class java.lang.IllegalArgumentException]

However removing any of the cases alleviates the problem.  Am I missing
something obvious, or is this a bug in the case statement?

Thanks -- Eric

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

Re: possible bug in `case'

[Alan]

It looks like a problem in clojure.core/min-hash to me. case depends
on min-hash to generate ahead-of-time hashes of all the test clauses,
and while I can't easily follow what's going on, it seems to be trying
to find a shift/mask combination that is...somehow related to the
hashes of the test clauses. I speculate that it's easier to perform
this operation on N values than N+1; with (0,0x7000) it's hard,
but with another 1 it becomes unmanageable with the simple algorithm.

On Jan 6, 10:49 pm, Eric Schulte schulte.e...@gmail.com wrote:
 Hi,

 The following case statement

   #+begin_src clojure
     (defn buggy-case [n]
       (case (int n)
             0          :null
             1          :load
             0x7000 :loproc))
   #+end_src

 throws the following error

   No distinct mapping found
     [Thrown class java.lang.IllegalArgumentException]

 However removing any of the cases alleviates the problem.  Am I missing
 something obvious, or is this a bug in the case statement?

 Thanks -- Eric

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

Re: possible bug

[doc]

That works.  Thanks!

take care,

Mike

On Sep 14, 1:38 am, Meikel Brandmeyer m...@kotka.de wrote:
 Hi,

 I can reproduce it with 1.2 and 1.3.0-master-20100911.130147-5. And I
 think I know, what the problem is: You must not recur out of a
 binding. The binding implicitely contains a try with cleanup code in
 the finally clause. It seems that recur bypasses the finally and
 executes again the binding. This pushes another frame of the bindings
 onto the stack, but the old frame is not popped. When the exception is
 thrown, the finally part gets executed and one frame is popped, but
 the additional frames remain. The stack of bindings is now out of
 sync. Hence your result. Throwing the exception in the first iteration
 will leave the bindings stack intact.

 user= (binding [x [1 2 3]] (loop [c 0] (binding [y [4 5 6]] (throw
 (Exception. BOOOM)
 Exception BOOOM  user/eval13 (NO_SOURCE_FILE:9)
 user= x
 IllegalStateException Var user/x is unbound.  clojure.lang.Var.deref
 (Var.java:142)
 user= y
 IllegalStateException Var user/y is unbound.  clojure.lang.Var.deref
 (Var.java:142)

 Please find the following code, which works as expected:

 (defn test-fixed-nested-binding
   []
   (binding  [x [0 1 2 3 4 5 6]]
     (try
       (binding [y [7 8 9]]
         (loop [c 0]
           (change-value-of-thread-local-var)
           (throw-random-exception c)
           (recur (inc c
       (catch Exception e (println (str x \n (.getMessage e)))

 Since recur is local, I think don't do it is a valid short- to mid-
 term fix.

 Sincerely
 Meikel

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

Re: Possible bug in with-symbol-macros, interacts badly with case

[icemaze]

I digged a little and I have a patch. I modified the case* parser in
Compiler.java, so the patch shouldn't affect anything else: I prefer
keeping safe since my knowledge of Clojure internals is limited, but a
more radical solution might be desirable.


The problem seems caused by the way case* gets constructed. The 7th
parameter is a hash-map that is passed directly to the compiler
(Compiler.java). The values of this hash-map are instances of the
MapEntry class.

When a case call is macroexpanded, those MapEntry instances get
printed out as vectors. When they are read back and evaluated, they
become instances of PersistentVector and the compiler barfs. Since
case* arguments are not evaluated there's no way, as far as I know, to
pass a MapEntry object to case* by calling it directly since there's
no such thing as a MapEntry literal.

My patch modifies case* so that it can handle a PersistentVector and
make a new MapEntry from it.

I'll post the patch here directly, since it's only a few lines long. I
hope it's not too rude. It's against git master branch.

--- Compiler.java.orig  2010-09-11 14:35:07.0 +0200
+++ Compiler.java   2010-09-13 12:12:12.033621364 +0200
@@ -7445,7 +7445,13 @@
{
Map.Entry e = (Map.Entry) o;
Integer minhash =
((Number)e.getKey()).intValue();
-   MapEntry me = (MapEntry) e.getValue();
+   MapEntry me = null;
+   if (e.getValue() instanceof
PersistentVector) {
+   PersistentVector pv =
(PersistentVector) e.getValue();
+   me = new MapEntry(pv.nth(0),
pv.nth(1));
+   } else {
+   me = (MapEntry) e.getValue();
+   }

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

Re: possible bug

[doc]

it was on 1.2.0-master but I will upgrade to 1.3.0-master

thanks! :-)

On Sep 13, 3:01 am, Chouser chou...@gmail.com wrote:
 On Sun, Sep 12, 2010 at 3:58 PM, doc mdpendergr...@gmail.com wrote:
  Hello,

  I am relatively new to clojure and lispy languages in general.  I
  wrote a small program that manipulated thread vars using the binding
  macro and I am seeing what seems to be strange behavior.

  To illustrate, here is another small program that reproduces what I am
  seeing (without all the distraction of the original).  There is a
  reason for the nested bindings in the original code where it seems a
  bit contrived here.  Regardless, if it is something I am doing wrong,
  please let me know.

  

  (declare x y)

  (def rnd1 (java.util.Random.))
  (def rnd2 (java.util.Random.))

  (defn throw-random-exception [c]
   (let [value (.nextInt rnd1 100)]
     (if (= value 50)
       (throw (Exception. (str Random Exception after count = 
  c))

  (defn change-value-of-thread-local-var []
   (set! x (conj x (.nextInt rnd2 100

  (defn test-binding []
   (binding  [x [0 1 2 3 4 5 6]]
     (try
       (loop [c 0]
         (do
           (change-value-of-thread-local-var)
           (throw-random-exception c))
         (recur (inc c)))
       (catch Exception e (println (str x \n (.getMessage e)))

  (defn test-nested-binding []
   (binding  [x [0 1 2 3 4 5 6]]
     (try
       (loop [c 0]
         (binding [y [7 8 9]]
           (do
             (change-value-of-thread-local-var)
             (throw-random-exception c))
           (recur (inc c
       (catch Exception e (println (str x \n (.getMessage e)))

  

  If I load this as a file at the REPL and then run (test-binding) the
  value of x is unbound when the function returns.  However if you run
  (test-nested-binding) then the value of BOTH x and y have a bound
  value when the function returns.  Is this a bug?  If so, where do I
  report it?  If not, what am I doing wrong?  I have also moved the
  binding of x inside the try and it has the same behavior.

 For me, x and y are unbound after running either function on a recent
 master branch of Clojure.  What version of Clojure are you using?

 user= (clojure-version)
 1.3.0-master-SNAPSHOT

 If you're using something earlier than the 1.2 release, I'd suggest
 you upgrade to 1.2 and try again.

 --Chouserhttp://joyofclojure.com/

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

Re: possible bug

[doc]

I sent a reply earlier but I don't think it went through.  I tried it
again with 1.3.0-master-SNAPSHOT and it still had x and y bound after
the test-nested-binding function ran.  Not sure what I am doing wrong
or have misconfigured?  Any insight would be appreciated.

take care,

Mike

On Sep 13, 11:37 am, doc mdpendergr...@gmail.com wrote:
 it was on 1.2.0-master but I will upgrade to 1.3.0-master

 thanks! :-)

 On Sep 13, 3:01 am, Chouser chou...@gmail.com wrote:

  On Sun, Sep 12, 2010 at 3:58 PM, doc mdpendergr...@gmail.com wrote:
   Hello,

   I am relatively new to clojure and lispy languages in general.  I
   wrote a small program that manipulated thread vars using the binding
   macro and I am seeing what seems to be strange behavior.

   To illustrate, here is another small program that reproduces what I am
   seeing (without all the distraction of the original).  There is a
   reason for the nested bindings in the original code where it seems a
   bit contrived here.  Regardless, if it is something I am doing wrong,
   please let me know.

   

   (declare x y)

   (def rnd1 (java.util.Random.))
   (def rnd2 (java.util.Random.))

   (defn throw-random-exception [c]
    (let [value (.nextInt rnd1 100)]
      (if (= value 50)
        (throw (Exception. (str Random Exception after count = 
   c))

   (defn change-value-of-thread-local-var []
    (set! x (conj x (.nextInt rnd2 100

   (defn test-binding []
    (binding  [x [0 1 2 3 4 5 6]]
      (try
        (loop [c 0]
          (do
            (change-value-of-thread-local-var)
            (throw-random-exception c))
          (recur (inc c)))
        (catch Exception e (println (str x \n (.getMessage e)))

   (defn test-nested-binding []
    (binding  [x [0 1 2 3 4 5 6]]
      (try
        (loop [c 0]
          (binding [y [7 8 9]]
            (do
              (change-value-of-thread-local-var)
              (throw-random-exception c))
            (recur (inc c
        (catch Exception e (println (str x \n (.getMessage e)))

   

   If I load this as a file at the REPL and then run (test-binding) the
   value of x is unbound when the function returns.  However if you run
   (test-nested-binding) then the value of BOTH x and y have a bound
   value when the function returns.  Is this a bug?  If so, where do I
   report it?  If not, what am I doing wrong?  I have also moved the
   binding of x inside the try and it has the same behavior.

  For me, x and y are unbound after running either function on a recent
  master branch of Clojure.  What version of Clojure are you using?

  user= (clojure-version)
  1.3.0-master-SNAPSHOT

  If you're using something earlier than the 1.2 release, I'd suggest
  you upgrade to 1.2 and try again.

  --Chouserhttp://joyofclojure.com/

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

Re: possible bug

[doc]

OK, I upgraded to 1.3.0-master-SNAPSHOT but I am still getting a bound
x and y after running the test-nested-binding function.  There must be
something else not quite right.

for my REPL I am using:

ubuntu linux 10.04
java sdk 1.6.0_21
clojure 1.3.0-master-SNAPSHOT
clojure-contrib 1.3.0-SNAPSHOT
jLine 0.9.95-SNAPSHOT

here is a cut/paste of what I did at the repl:
---
Clojure 1.3.0-master-SNAPSHOT
user= (load-file TestBinding.clj)
#'user/test-nested-binding
user= (test-binding)
[0 1 2 3 4 5 6 40 80 19 72 31 73 40 61 99 25 13 14 91 81 22 94 87 25
33 11 60 3 6 14 13 77 94 77 83 16 88 38 7 59 79 74 5 98 57 95 90 86 14
64 63 2 34 52 30 86 72 14 25 7 54 83 53 86 66 57 86 55 52 97 8 20 3 21
7 6 66 73 48 16 43 3 43 91 42 21 49 95 25 31 71 4 21 18 78 79 1 57 55
76 42 82 99 49 54 41 3 34 27 26 65 33 37 68 18 88 64 23 81 13 99 55 14
94 61 35 36 32 54 97 26 34 8 26 60 7 97 38 18 84 24 74 57 95 67 4 18
25 75 42 21 75 87 21 94 82 64 80 56 28 34 88 42 3 13 20 28 97 87 68 76
46 33 38 33 22 9 97 37 63 26 13 9 55 52 91 55 74 12 99 69 4 96 0 9 54
60 41 82 4 0 99 24 38 30 74]
Random Exception after count = 199
nil
user= x
IllegalStateException Var user/x is unbound.  clojure.lang.Var.deref
(Var.java:142)
user= (test-nested-binding)
[0 1 2 3 4 5 6 52 76 96 80 15 52 35 56 66 78 59 72 36 80 59 52 15 56
65 92 41 68 59 64 42 40 77 78 95 34 51 28 23 99 40 45 2 82 21 11 6 52
28 28 98 19 76 90 79 87 65 71 35 19 29 1 52 96 94 51 49 69 24 54 76 87
88 52 48 64 56 71 64 72 86 22 37 63 10 85 20]
Random Exception after count = 80
nil
user= x
[0 1 2 3 4 5 6 52 76 96 80 15 52 35 56 66 78 59 72 36 80 59 52 15 56
65 92 41 68 59 64 42 40 77 78 95 34 51 28 23 99 40 45 2 82 21 11 6 52
28 28 98 19 76 90 79 87 65 71 35 19 29 1 52 96 94 51 49 69 24 54 76 87
88 52 48 64 56 71 64 72 86 22 37 63 10 85 20]
user= (clojure-version)
1.3.0-master-SNAPSHOT
user=
---

(I also ran this with just a plain clojure repl (no contrib or jline
jars in the classpath))

thanks for any help

take care,

Mike

On Sep 13, 11:37 am, doc mdpendergr...@gmail.com wrote:
 it was on 1.2.0-master but I will upgrade to 1.3.0-master

 thanks! :-)

 On Sep 13, 3:01 am, Chouser chou...@gmail.com wrote:

  On Sun, Sep 12, 2010 at 3:58 PM, doc mdpendergr...@gmail.com wrote:
   Hello,

   I am relatively new to clojure and lispy languages in general.  I
   wrote a small program that manipulated thread vars using the binding
   macro and I am seeing what seems to be strange behavior.

   To illustrate, here is another small program that reproduces what I am
   seeing (without all the distraction of the original).  There is a
   reason for the nested bindings in the original code where it seems a
   bit contrived here.  Regardless, if it is something I am doing wrong,
   please let me know.

   

   (declare x y)

   (def rnd1 (java.util.Random.))
   (def rnd2 (java.util.Random.))

   (defn throw-random-exception [c]
    (let [value (.nextInt rnd1 100)]
      (if (= value 50)
        (throw (Exception. (str Random Exception after count = 
   c))

   (defn change-value-of-thread-local-var []
    (set! x (conj x (.nextInt rnd2 100

   (defn test-binding []
    (binding  [x [0 1 2 3 4 5 6]]
      (try
        (loop [c 0]
          (do
            (change-value-of-thread-local-var)
            (throw-random-exception c))
          (recur (inc c)))
        (catch Exception e (println (str x \n (.getMessage e)))

   (defn test-nested-binding []
    (binding  [x [0 1 2 3 4 5 6]]
      (try
        (loop [c 0]
          (binding [y [7 8 9]]
            (do
              (change-value-of-thread-local-var)
              (throw-random-exception c))
            (recur (inc c
        (catch Exception e (println (str x \n (.getMessage e)))

   

   If I load this as a file at the REPL and then run (test-binding) the
   value of x is unbound when the function returns.  However if you run
   (test-nested-binding) then the value of BOTH x and y have a bound
   value when the function returns.  Is this a bug?  If so, where do I
   report it?  If not, what am I doing wrong?  I have also moved the
   binding of x inside the try and it has the same behavior.

  For me, x and y are unbound after running either function on a recent
  master branch of Clojure.  What version of Clojure are you using?

  user= (clojure-version)
  1.3.0-master-SNAPSHOT

  If you're using something earlier than the 1.2 release, I'd suggest
  you upgrade to 1.2 and try again.

  --Chouserhttp://joyofclojure.com/

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

Possible bug in with-symbol-macros, interacts badly with case

[icemaze]

I wrote a test case:

(use 'clojure.contrib.macro-utils)

(defn bug? []
  (with-symbol-macros
(case 0
  0 1)))

The REPL prints:
java.lang.ClassCastException: clojure.lang.PersistentVector cannot be
cast to clojure.lang.MapEntry (NO_SOURCE_FILE:4)

Can anyone confirm this, please?

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

possible bug

[doc]

Hello,

I am relatively new to clojure and lispy languages in general.  I
wrote a small program that manipulated thread vars using the binding
macro and I am seeing what seems to be strange behavior.

To illustrate, here is another small program that reproduces what I am
seeing (without all the distraction of the original).  There is a
reason for the nested bindings in the original code where it seems a
bit contrived here.  Regardless, if it is something I am doing wrong,
please let me know.



(declare x y)

(def rnd1 (java.util.Random.))
(def rnd2 (java.util.Random.))

(defn throw-random-exception [c]
  (let [value (.nextInt rnd1 100)]
(if (= value 50)
  (throw (Exception. (str Random Exception after count = 
c))

(defn change-value-of-thread-local-var []
  (set! x (conj x (.nextInt rnd2 100

(defn test-binding []
  (binding  [x [0 1 2 3 4 5 6]]
(try
  (loop [c 0]
(do
  (change-value-of-thread-local-var)
  (throw-random-exception c))
(recur (inc c)))
  (catch Exception e (println (str x \n (.getMessage e)))

(defn test-nested-binding []
  (binding  [x [0 1 2 3 4 5 6]]
(try
  (loop [c 0]
(binding [y [7 8 9]]
  (do
(change-value-of-thread-local-var)
(throw-random-exception c))
  (recur (inc c
  (catch Exception e (println (str x \n (.getMessage e)))




If I load this as a file at the REPL and then run (test-binding) the
value of x is unbound when the function returns.  However if you run
(test-nested-binding) then the value of BOTH x and y have a bound
value when the function returns.  Is this a bug?  If so, where do I
report it?  If not, what am I doing wrong?  I have also moved the
binding of x inside the try and it has the same behavior.

thanks,

take care,

Mike

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

Re: Possible bug in with-symbol-macros, interacts badly with case

[icemaze]

I found a workaround:

(use 'clojure.contrib.macro-utils)

(defsymbolmacro one 1)

(defn bug1 []
  (with-symbol-macros
(bug2)))

(defn bug2
  (case 0
    0 one)))


The one symbol macro is there just to show that everything works as
expected.

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

Clojure Map function possible bug.

[Ruben]

Hi all,

when I execute the following code:

(def users (ref []))

;works
(defn print-users []
  (with-query-results res [select id,username,password from users ]

(dorun
(dosync (ref-set users  res )  )
)
  )
)


and then execute (map #(println %) @users)  i get back this:

({:id 1, :username rpierich, :password test}
{:id 2, :username ruthpierich, :password test}
nil {:id 3, :username ruthpierich, :password test}
nil nil)

when i perform a @users i get:

({:id 1, :username rpierich, :password test} {:id 2, :username
ruthpierich, :password test} {:id 3, :username
ruthpierich, :password test})


Is this a bug with map or since it adds on those nils or am i missing
something in the call to map?

Cheers,
Ruben

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

Re: Clojure Map function possible bug.

[Laurent PETIT]

2010/7/21 Ruben ruben.pier...@gmail.com

 Hi all,

 when I execute the following code:

 (def users (ref []))

 ;works
 (defn print-users []
  (with-query-results res [select id,username,password from users ]

(dorun
(dosync (ref-set users  res )  )
)
  )
 )


 and then execute (map #(println %) @users)  i get back this:

 ({:id 1, :username rpierich, :password test}
 {:id 2, :username ruthpierich, :password test}
 nil {:id 3, :username ruthpierich, :password test}
 nil nil)

 when i perform a @users i get:

 ({:id 1, :username rpierich, :password test} {:id 2, :username
 ruthpierich, :password test} {:id 3, :username
 ruthpierich, :password test})


 Is this a bug with map or since it adds on those nils or am i missing
 something in the call to map?


C'mon, did you really thing that such a bug could be there in map and seen
by nobody ? :-) There's more than one or two persons that use clojure, these
days :-D

The nils are the values of the map, the *return* values from the three
consecutive calls to println

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

Re: Clojure Map function possible bug.

[Stuart Halloway]

Hi Ruben,

What you are missing is that map is the wrong function to use here. Map is 
lazy, and combining map with something side-effecty like println will lead to 
confusion.

doseq will give you what you want.

Stu

Stuart Halloway
Clojure/core
http://clojure.com

 Hi all,
 
 when I execute the following code:
 
 (def users (ref []))
 
 ;works
 (defn print-users []
  (with-query-results res [select id,username,password from users ]
 
(dorun
   (dosync (ref-set users  res )  )
   )
  )
 )
 
 
 and then execute (map #(println %) @users)  i get back this:
 
 ({:id 1, :username rpierich, :password test}
 {:id 2, :username ruthpierich, :password test}
 nil {:id 3, :username ruthpierich, :password test}
 nil nil)
 
 when i perform a @users i get:
 
 ({:id 1, :username rpierich, :password test} {:id 2, :username
 ruthpierich, :password test} {:id 3, :username
 ruthpierich, :password test})
 
 
 Is this a bug with map or since it adds on those nils or am i missing
 something in the call to map?
 
 Cheers,
 Ruben
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en




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

Re: Clojure Map function possible bug.

[Ruben]

Thanks for your response guys.

Ruben

On Jul 21, 9:30 am, Stuart Halloway stuart.hallo...@gmail.com wrote:
 Hi Ruben,

 What you are missing is thatmapis the wrong function to use here.Mapis lazy, 
 and combiningmapwith something side-effecty like println will lead to 
 confusion.

 doseq will give you what you want.

 Stu

 Stuart Halloway
 Clojure/corehttp://clojure.com



  Hi all,

  when I execute the following code:

  (def users (ref []))

  ;works
  (defn print-users []
   (with-query-results res [select id,username,password from users ]

         (dorun
             (dosync (ref-set users  res )  )
     )
   )
  )

  and then execute (map#(println %) @users)  i get back this:

  ({:id 1, :username rpierich, :password test}
  {:id 2, :username ruthpierich, :password test}
  nil {:id 3, :username ruthpierich, :password test}
  nil nil)

  when i perform a @users i get:

  ({:id 1, :username rpierich, :password test} {:id 2, :username
  ruthpierich, :password test} {:id 3, :username
  ruthpierich, :password test})

  Is this abugwithmapor since it adds on those nils or am i missing
  something in the call tomap?

  Cheers,
  Ruben

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

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

Re: Possible BUG: NPE

[Rich Hickey]

On Wed, Dec 9, 2009 at 10:39 PM, Feng hou...@gmail.com wrote:


 On Dec 7, 9:39 pm, David Nolen dnolen.li...@gmail.com wrote:
 http://github.com/jochu/swank-clojure/blob/master/src/main/clojure/sw...

 Is the offending line.

 It's really hard to reason about it in clojure source code. I see, in
 jswat debbuger, the root cause of NPE appears around byte code
 (putfield ...) for a mutual recursive letfn form.

 Here is a simple way to reproduce it. I did it this time with latest
 master branch. Can anybody else reproduce it on different OS/JVM
 version?

 (ns test.letfn)

 (defn debug [n]
  (letfn [(even [n]
                (if (== n 0)
                  true
                  (odd (- n 1
          (odd [n]
               (if (== n 0)
                 false
                 (even (- n 1]
    (odd n)))

 Listening for transport dt_socket at address: 
 Clojure 1.1.0-master-SNAPSHOT
 user= (require 'test.letfn)
 nil
 user= (test.letfn/debug 5)
 java.lang.NullPointerException (NO_SOURCE_FILE:0)

Fixed (new branch commit 42e45b9988bfa17584f2)

Thanks for the report and the isolating case.

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

Re: Possible BUG: NPE

[Feng]

On Dec 7, 9:39 pm, David Nolen dnolen.li...@gmail.com wrote:
 http://github.com/jochu/swank-clojure/blob/master/src/main/clojure/sw...

 Is the offending line.

It's really hard to reason about it in clojure source code. I see, in
jswat debbuger, the root cause of NPE appears around byte code
(putfield ...) for a mutual recursive letfn form.

Here is a simple way to reproduce it. I did it this time with latest
master branch. Can anybody else reproduce it on different OS/JVM
version?

(ns test.letfn)

(defn debug [n]
  (letfn [(even [n]
(if (== n 0)
  true
  (odd (- n 1
  (odd [n]
   (if (== n 0)
 false
 (even (- n 1]
(odd n)))

Listening for transport dt_socket at address: 
Clojure 1.1.0-master-SNAPSHOT
user= (require 'test.letfn)
nil
user= (test.letfn/debug 5)
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user= (.. *e getCause printStackTrace)
java.lang.NullPointerException
at test.letfn$debug__17.invoke(letfn.clj:3)
at user$eval__4.invoke(NO_SOURCE_FILE:2)
at clojure.lang.Compiler.eval(Compiler.java:4642)
at clojure.core$eval__5254.invoke(core.clj:2035)
at clojure.main$repl__7403$read_eval_print__7415.invoke
(main.clj:183)
at clojure.main$repl__7403.doInvoke(main.clj:200)
at clojure.lang.RestFn.invoke(RestFn.java:426)
at clojure.main$repl_opt__7449.invoke(main.clj:254)
at clojure.main$main__7484.doInvoke(main.clj:341)
at clojure.lang.RestFn.invoke(RestFn.java:402)
at clojure.lang.Var.invoke(Var.java:355)
at clojure.lang.AFn.applyToHelper(AFn.java:171)
at clojure.lang.Var.applyTo(Var.java:476)
at clojure.main.main(main.java:37)
nil
user=

macbook-wifi:/ fenghou$ uname -a
Darwin macbook-wifi 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10
18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
macbook-wifi:/ fenghou$ java -version
java version 1.5.0_19
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-
b02-306)
Java HotSpot(TM) Client VM (build 1.5.0_19-138, mixed mode, sharing)

- Feng

 On Mon, Dec 7, 2009 at 9:34 PM, David Nolen dnolen.li...@gmail.com wrote:
  Looking at the stacktrace it looks like this is because of swank_fuzzy.clj.
  I can start up the SLIME Repl no problem, I see your exact same stack trace
  only if I try to trigger fuzzy completion via C-c TAB.

  David

  On Mon, Dec 7, 2009 at 9:24 PM, Feng hou...@gmail.com wrote:

  On Dec 7, 8:57 pm, David Nolen dnolen.li...@gmail.com wrote:
   I was getting this as well, but this was before the last 3 commits to
  new.
   Did you wipe your old jars and class files and start afresh?

  Yes, just to make sure not waste Rich's time. I did doubt and triple
  checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ...

  I use Jeff's git master clone, not Phil's branch. No magic in emacs. I
  load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And
  always start swank from console repl in screen, then M-x slime-
  connect. So I'm pretty sure where everything is.

   David

   On Mon, Dec 7, 2009 at 8:31 PM, Feng hou...@gmail.com wrote:
Hi,

After git pull on new branch

commit 1da63ad10d2531264e86eb705a10b3cebc9b1067
Author: Rich Hickey richhic...@gmail.com
Date:   Mon Dec 7 16:44:41 2009 -0500

   init CLEAR_SITES

Got NPE in slime

java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.NullPointerException
 [Thrown class java.lang.RuntimeException]

Backtrace:
 0: clojure.lang.LazySeq.sval(LazySeq.java:47)
 1: clojure.lang.LazySeq.seq(LazySeq.java:56)
 2: clojure.lang.RT.seq(RT.java:440)
 3: clojure.core$seq__3970.invoke(core.clj:105)
 4: clojure.core$sort__4671.invoke(core.clj:1994)
 5: swank.commands.contrib.swank_fuzzy
$fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256)
 6: swank.commands.contrib.swank_fuzzy
$fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310)
 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke
(swank_fuzzy.clj:127)
 8: swank.commands.contrib.swank_fuzzy
$fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309)
 9: swank.commands.contrib.swank_fuzzy
$eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323)
 10: clojure.lang.Var.invoke(Var.java:385)
 11: user$eval__2042.invoke(NO_SOURCE_FILE)
 12: clojure.lang.Compiler.eval(Compiler.java:5256)
 13: clojure.lang.Compiler.eval(Compiler.java:5224)
 14: clojure.core$eval__4688.invoke(core.clj:2036)
 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58)
 16: swank.core$eval_for_emacs__468.invoke(core.clj:126)
 17: clojure.lang.Var.invoke(Var.java:373)
 18: clojure.lang.AFn.applyToHelper(AFn.java:182)
 19: clojure.lang.Var.applyTo(Var.java:482)
 20: 

Re: Possible BUG: NPE

[Richard Newman]

Does not happen for me through Slime or raw REPL.

user (ns test.letfn)

(defn debug [n]
  (letfn [(even [n]
(if (== n 0)
  true
  (odd (- n 1
  (odd [n]
   (if (== n 0)
 false
 (even (- n 1]
(odd n)))
#'test.letfn/debug
test.letfn (debug 5)
true
test.letfn (debug 4)
false


Clojure: 76e7c4317dc3eac80c4908ac5e5fb885e302b2a4

GNU Emacs 22.3.1 (i386-apple-darwin9.7.0, Carbon Version 1.6.0)
  of 2009-07-25 on gs674-seijiz.local

(Hmm, I thought I was running 23!)

$ uname -a
Darwin wheeljack 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15  
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

$ java -version
java version 1.6.0_17
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

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

Re: Possible BUG: NPE

[David Nolen]

You don't have the locals clearing changes Richard.

Rich Hickey, I confirm that this also causes an NPE on my setup.

Clojure new branch 6d40a76e8a012909f2d2a594ce66a78318889799
OS X 10.6 JDK 1.6 64bit

David

On Wed, Dec 9, 2009 at 10:46 PM, Richard Newman holyg...@gmail.com wrote:

 Does not happen for me through Slime or raw REPL.

 user (ns test.letfn)

 (defn debug [n]
  (letfn [(even [n]
(if (== n 0)
  true
  (odd (- n 1
  (odd [n]
   (if (== n 0)
 false
 (even (- n 1]
(odd n)))
 #'test.letfn/debug
 test.letfn (debug 5)
 true
 test.letfn (debug 4)
 false


 Clojure: 76e7c4317dc3eac80c4908ac5e5fb885e302b2a4

 GNU Emacs 22.3.1 (i386-apple-darwin9.7.0, Carbon Version 1.6.0)
  of 2009-07-25 on gs674-seijiz.local

 (Hmm, I thought I was running 23!)

 $ uname -a
 Darwin wheeljack 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

 $ java -version
 java version 1.6.0_17
 Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125)
 Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

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


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

Possible BUG: NPE

[Feng]

Hi,

After git pull on new branch

commit 1da63ad10d2531264e86eb705a10b3cebc9b1067
Author: Rich Hickey richhic...@gmail.com
Date:   Mon Dec 7 16:44:41 2009 -0500

init CLEAR_SITES

Got NPE in slime

java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.NullPointerException
  [Thrown class java.lang.RuntimeException]

Backtrace:
  0: clojure.lang.LazySeq.sval(LazySeq.java:47)
  1: clojure.lang.LazySeq.seq(LazySeq.java:56)
  2: clojure.lang.RT.seq(RT.java:440)
  3: clojure.core$seq__3970.invoke(core.clj:105)
  4: clojure.core$sort__4671.invoke(core.clj:1994)
  5: swank.commands.contrib.swank_fuzzy
$fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256)
  6: swank.commands.contrib.swank_fuzzy
$fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310)
  7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke
(swank_fuzzy.clj:127)
  8: swank.commands.contrib.swank_fuzzy
$fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309)
  9: swank.commands.contrib.swank_fuzzy
$eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323)
 10: clojure.lang.Var.invoke(Var.java:385)
 11: user$eval__2042.invoke(NO_SOURCE_FILE)
 12: clojure.lang.Compiler.eval(Compiler.java:5256)
 13: clojure.lang.Compiler.eval(Compiler.java:5224)
 14: clojure.core$eval__4688.invoke(core.clj:2036)
 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58)
 16: swank.core$eval_for_emacs__468.invoke(core.clj:126)
 17: clojure.lang.Var.invoke(Var.java:373)
 18: clojure.lang.AFn.applyToHelper(AFn.java:182)
 19: clojure.lang.Var.applyTo(Var.java:482)
 20: clojure.core$apply__4058.invoke(core.clj:437)
 21: swank.core$eval_from_control__401.invoke(core.clj:65)
 22: swank.core$eval_loop__403.invoke(core.clj:70)
 23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj:
179)
 24: clojure.lang.AFn.applyToHelper(AFn.java:172)
 25: clojure.lang.AFn.applyTo(AFn.java:164)
 26: clojure.core$apply__4058.invoke(core.clj:437)
 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176)
 28: clojure.lang.RestFn.invoke(RestFn.java:398)
 29: clojure.lang.AFn.run(AFn.java:37)
 30: java.lang.Thread.run(Thread.java:613)

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

Re: Possible BUG: NPE

[David Nolen]

I was getting this as well, but this was before the last 3 commits to new.
Did you wipe your old jars and class files and start afresh?

David

On Mon, Dec 7, 2009 at 8:31 PM, Feng hou...@gmail.com wrote:

 Hi,

 After git pull on new branch

 commit 1da63ad10d2531264e86eb705a10b3cebc9b1067
 Author: Rich Hickey richhic...@gmail.com
 Date:   Mon Dec 7 16:44:41 2009 -0500

init CLEAR_SITES

 Got NPE in slime

 java.lang.RuntimeException: java.lang.RuntimeException:
 java.lang.RuntimeException: java.lang.RuntimeException:
 java.lang.NullPointerException
  [Thrown class java.lang.RuntimeException]

 Backtrace:
  0: clojure.lang.LazySeq.sval(LazySeq.java:47)
  1: clojure.lang.LazySeq.seq(LazySeq.java:56)
  2: clojure.lang.RT.seq(RT.java:440)
  3: clojure.core$seq__3970.invoke(core.clj:105)
  4: clojure.core$sort__4671.invoke(core.clj:1994)
  5: swank.commands.contrib.swank_fuzzy
 $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256)
  6: swank.commands.contrib.swank_fuzzy
 $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310)
  7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke
 (swank_fuzzy.clj:127)
  8: swank.commands.contrib.swank_fuzzy
 $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309)
  9: swank.commands.contrib.swank_fuzzy
 $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323)
  10: clojure.lang.Var.invoke(Var.java:385)
  11: user$eval__2042.invoke(NO_SOURCE_FILE)
  12: clojure.lang.Compiler.eval(Compiler.java:5256)
  13: clojure.lang.Compiler.eval(Compiler.java:5224)
  14: clojure.core$eval__4688.invoke(core.clj:2036)
  15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58)
  16: swank.core$eval_for_emacs__468.invoke(core.clj:126)
  17: clojure.lang.Var.invoke(Var.java:373)
  18: clojure.lang.AFn.applyToHelper(AFn.java:182)
  19: clojure.lang.Var.applyTo(Var.java:482)
  20: clojure.core$apply__4058.invoke(core.clj:437)
  21: swank.core$eval_from_control__401.invoke(core.clj:65)
  22: swank.core$eval_loop__403.invoke(core.clj:70)
  23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj:
 179)
  24: clojure.lang.AFn.applyToHelper(AFn.java:172)
  25: clojure.lang.AFn.applyTo(AFn.java:164)
  26: clojure.core$apply__4058.invoke(core.clj:437)
  27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176)
  28: clojure.lang.RestFn.invoke(RestFn.java:398)
  29: clojure.lang.AFn.run(AFn.java:37)
  30: java.lang.Thread.run(Thread.java:613)

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

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

Re: Possible BUG: NPE

[Feng]

On Dec 7, 8:57 pm, David Nolen dnolen.li...@gmail.com wrote:
 I was getting this as well, but this was before the last 3 commits to new.
 Did you wipe your old jars and class files and start afresh?


Yes, just to make sure not waste Rich's time. I did doubt and triple
checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ...

I use Jeff's git master clone, not Phil's branch. No magic in emacs. I
load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And
always start swank from console repl in screen, then M-x slime-
connect. So I'm pretty sure where everything is.

 David

 On Mon, Dec 7, 2009 at 8:31 PM, Feng hou...@gmail.com wrote:
  Hi,

  After git pull on new branch

  commit 1da63ad10d2531264e86eb705a10b3cebc9b1067
  Author: Rich Hickey richhic...@gmail.com
  Date:   Mon Dec 7 16:44:41 2009 -0500

     init CLEAR_SITES

  Got NPE in slime

  java.lang.RuntimeException: java.lang.RuntimeException:
  java.lang.RuntimeException: java.lang.RuntimeException:
  java.lang.NullPointerException
   [Thrown class java.lang.RuntimeException]

  Backtrace:
   0: clojure.lang.LazySeq.sval(LazySeq.java:47)
   1: clojure.lang.LazySeq.seq(LazySeq.java:56)
   2: clojure.lang.RT.seq(RT.java:440)
   3: clojure.core$seq__3970.invoke(core.clj:105)
   4: clojure.core$sort__4671.invoke(core.clj:1994)
   5: swank.commands.contrib.swank_fuzzy
  $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256)
   6: swank.commands.contrib.swank_fuzzy
  $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310)
   7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke
  (swank_fuzzy.clj:127)
   8: swank.commands.contrib.swank_fuzzy
  $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309)
   9: swank.commands.contrib.swank_fuzzy
  $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323)
   10: clojure.lang.Var.invoke(Var.java:385)
   11: user$eval__2042.invoke(NO_SOURCE_FILE)
   12: clojure.lang.Compiler.eval(Compiler.java:5256)
   13: clojure.lang.Compiler.eval(Compiler.java:5224)
   14: clojure.core$eval__4688.invoke(core.clj:2036)
   15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58)
   16: swank.core$eval_for_emacs__468.invoke(core.clj:126)
   17: clojure.lang.Var.invoke(Var.java:373)
   18: clojure.lang.AFn.applyToHelper(AFn.java:182)
   19: clojure.lang.Var.applyTo(Var.java:482)
   20: clojure.core$apply__4058.invoke(core.clj:437)
   21: swank.core$eval_from_control__401.invoke(core.clj:65)
   22: swank.core$eval_loop__403.invoke(core.clj:70)
   23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj:
  179)
   24: clojure.lang.AFn.applyToHelper(AFn.java:172)
   25: clojure.lang.AFn.applyTo(AFn.java:164)
   26: clojure.core$apply__4058.invoke(core.clj:437)
   27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176)
   28: clojure.lang.RestFn.invoke(RestFn.java:398)
   29: clojure.lang.AFn.run(AFn.java:37)
   30: java.lang.Thread.run(Thread.java:613)

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

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

Re: Possible BUG: NPE

[David Nolen]

Looking at the stacktrace it looks like this is because of swank_fuzzy.clj.
I can start up the SLIME Repl no problem, I see your exact same stack trace
only if I try to trigger fuzzy completion via C-c TAB.

David

On Mon, Dec 7, 2009 at 9:24 PM, Feng hou...@gmail.com wrote:



 On Dec 7, 8:57 pm, David Nolen dnolen.li...@gmail.com wrote:
  I was getting this as well, but this was before the last 3 commits to
 new.
  Did you wipe your old jars and class files and start afresh?
 

 Yes, just to make sure not waste Rich's time. I did doubt and triple
 checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ...

 I use Jeff's git master clone, not Phil's branch. No magic in emacs. I
 load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And
 always start swank from console repl in screen, then M-x slime-
 connect. So I'm pretty sure where everything is.

  David
 
  On Mon, Dec 7, 2009 at 8:31 PM, Feng hou...@gmail.com wrote:
   Hi,
 
   After git pull on new branch
 
   commit 1da63ad10d2531264e86eb705a10b3cebc9b1067
   Author: Rich Hickey richhic...@gmail.com
   Date:   Mon Dec 7 16:44:41 2009 -0500
 
  init CLEAR_SITES
 
   Got NPE in slime
 
   java.lang.RuntimeException: java.lang.RuntimeException:
   java.lang.RuntimeException: java.lang.RuntimeException:
   java.lang.NullPointerException
[Thrown class java.lang.RuntimeException]
 
   Backtrace:
0: clojure.lang.LazySeq.sval(LazySeq.java:47)
1: clojure.lang.LazySeq.seq(LazySeq.java:56)
2: clojure.lang.RT.seq(RT.java:440)
3: clojure.core$seq__3970.invoke(core.clj:105)
4: clojure.core$sort__4671.invoke(core.clj:1994)
5: swank.commands.contrib.swank_fuzzy
   $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256)
6: swank.commands.contrib.swank_fuzzy
   $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310)
7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke
   (swank_fuzzy.clj:127)
8: swank.commands.contrib.swank_fuzzy
   $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309)
9: swank.commands.contrib.swank_fuzzy
   $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323)
10: clojure.lang.Var.invoke(Var.java:385)
11: user$eval__2042.invoke(NO_SOURCE_FILE)
12: clojure.lang.Compiler.eval(Compiler.java:5256)
13: clojure.lang.Compiler.eval(Compiler.java:5224)
14: clojure.core$eval__4688.invoke(core.clj:2036)
15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58)
16: swank.core$eval_for_emacs__468.invoke(core.clj:126)
17: clojure.lang.Var.invoke(Var.java:373)
18: clojure.lang.AFn.applyToHelper(AFn.java:182)
19: clojure.lang.Var.applyTo(Var.java:482)
20: clojure.core$apply__4058.invoke(core.clj:437)
21: swank.core$eval_from_control__401.invoke(core.clj:65)
22: swank.core$eval_loop__403.invoke(core.clj:70)
23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj:
   179)
24: clojure.lang.AFn.applyToHelper(AFn.java:172)
25: clojure.lang.AFn.applyTo(AFn.java:164)
26: clojure.core$apply__4058.invoke(core.clj:437)
27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176)
28: clojure.lang.RestFn.invoke(RestFn.java:398)
29: clojure.lang.AFn.run(AFn.java:37)
30: java.lang.Thread.run(Thread.java:613)
 
   --
   You received this message because you are subscribed to the Google
   Groups Clojure group.
   To post to this group, send email to clojure@googlegroups.com
   Note that posts from new members are moderated - please be patient with
   your first post.
   To unsubscribe from this group, send email to
   clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com
 clojure%2bunsubscr...@googlegroups.comclojure%252bunsubscr...@googlegroups.com
 
   For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en

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


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

Re: Possible BUG: NPE

[David Nolen]

http://github.com/jochu/swank-clojure/blob/master/src/main/clojure/swank/commands/contrib/swank_fuzzy.clj#L256

Is the offending line.

On Mon, Dec 7, 2009 at 9:34 PM, David Nolen dnolen.li...@gmail.com wrote:

 Looking at the stacktrace it looks like this is because of swank_fuzzy.clj.
 I can start up the SLIME Repl no problem, I see your exact same stack trace
 only if I try to trigger fuzzy completion via C-c TAB.

 David


 On Mon, Dec 7, 2009 at 9:24 PM, Feng hou...@gmail.com wrote:



 On Dec 7, 8:57 pm, David Nolen dnolen.li...@gmail.com wrote:
  I was getting this as well, but this was before the last 3 commits to
 new.
  Did you wipe your old jars and class files and start afresh?
 

 Yes, just to make sure not waste Rich's time. I did doubt and triple
 checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ...

 I use Jeff's git master clone, not Phil's branch. No magic in emacs. I
 load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And
 always start swank from console repl in screen, then M-x slime-
 connect. So I'm pretty sure where everything is.

  David
 
  On Mon, Dec 7, 2009 at 8:31 PM, Feng hou...@gmail.com wrote:
   Hi,
 
   After git pull on new branch
 
   commit 1da63ad10d2531264e86eb705a10b3cebc9b1067
   Author: Rich Hickey richhic...@gmail.com
   Date:   Mon Dec 7 16:44:41 2009 -0500
 
  init CLEAR_SITES
 
   Got NPE in slime
 
   java.lang.RuntimeException: java.lang.RuntimeException:
   java.lang.RuntimeException: java.lang.RuntimeException:
   java.lang.NullPointerException
[Thrown class java.lang.RuntimeException]
 
   Backtrace:
0: clojure.lang.LazySeq.sval(LazySeq.java:47)
1: clojure.lang.LazySeq.seq(LazySeq.java:56)
2: clojure.lang.RT.seq(RT.java:440)
3: clojure.core$seq__3970.invoke(core.clj:105)
4: clojure.core$sort__4671.invoke(core.clj:1994)
5: swank.commands.contrib.swank_fuzzy
   $fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256)
6: swank.commands.contrib.swank_fuzzy
   $fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310)
7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke
   (swank_fuzzy.clj:127)
8: swank.commands.contrib.swank_fuzzy
   $fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309)
9: swank.commands.contrib.swank_fuzzy
   $eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323)
10: clojure.lang.Var.invoke(Var.java:385)
11: user$eval__2042.invoke(NO_SOURCE_FILE)
12: clojure.lang.Compiler.eval(Compiler.java:5256)
13: clojure.lang.Compiler.eval(Compiler.java:5224)
14: clojure.core$eval__4688.invoke(core.clj:2036)
15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58)
16: swank.core$eval_for_emacs__468.invoke(core.clj:126)
17: clojure.lang.Var.invoke(Var.java:373)
18: clojure.lang.AFn.applyToHelper(AFn.java:182)
19: clojure.lang.Var.applyTo(Var.java:482)
20: clojure.core$apply__4058.invoke(core.clj:437)
21: swank.core$eval_from_control__401.invoke(core.clj:65)
22: swank.core$eval_loop__403.invoke(core.clj:70)
23:
 swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj:
   179)
24: clojure.lang.AFn.applyToHelper(AFn.java:172)
25: clojure.lang.AFn.applyTo(AFn.java:164)
26: clojure.core$apply__4058.invoke(core.clj:437)
27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176)
28: clojure.lang.RestFn.invoke(RestFn.java:398)
29: clojure.lang.AFn.run(AFn.java:37)
30: java.lang.Thread.run(Thread.java:613)
 
   --
   You received this message because you are subscribed to the Google
   Groups Clojure group.
   To post to this group, send email to clojure@googlegroups.com
   Note that posts from new members are moderated - please be patient
 with
   your first post.
   To unsubscribe from this group, send email to
   clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com
 clojure%2bunsubscr...@googlegroups.comclojure%252bunsubscr...@googlegroups.com
 
   For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en

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




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

Re: Possible BUG: NPE

[Feng]

Yes, fuzzy-completion seems the only way to trigger it.  For what it's
worth, it did not happen if reset to

commit a3e95cf5a72b22cd0728aba152d5f77603b722fc
Author: Rich Hickey richhic...@gmail.com
Date:   Fri Dec 4 11:22:04 2009 -0500

update example in reify doc

- Feng

On Dec 7, 9:34 pm, David Nolen dnolen.li...@gmail.com wrote:
 Looking at the stacktrace it looks like this is because of swank_fuzzy.clj.
 I can start up the SLIME Repl no problem, I see your exact same stack trace
 only if I try to trigger fuzzy completion via C-c TAB.

 David

 On Mon, Dec 7, 2009 at 9:24 PM, Feng hou...@gmail.com wrote:

  On Dec 7, 8:57 pm, David Nolen dnolen.li...@gmail.com wrote:
   I was getting this as well, but this was before the last 3 commits to
  new.
   Did you wipe your old jars and class files and start afresh?

  Yes, just to make sure not waste Rich's time. I did doubt and triple
  checks, ant clean, find $HOME -name clojure\*.jar |xargs rm ...

  I use Jeff's git master clone, not Phil's branch. No magic in emacs. I
  load everything (clojure-*.jar, swank-clojure/src) in clojure.sh. And
  always start swank from console repl in screen, then M-x slime-
  connect. So I'm pretty sure where everything is.

   David

   On Mon, Dec 7, 2009 at 8:31 PM, Feng hou...@gmail.com wrote:
Hi,

After git pull on new branch

commit 1da63ad10d2531264e86eb705a10b3cebc9b1067
Author: Rich Hickey richhic...@gmail.com
Date:   Mon Dec 7 16:44:41 2009 -0500

   init CLEAR_SITES

Got NPE in slime

java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.NullPointerException
 [Thrown class java.lang.RuntimeException]

Backtrace:
 0: clojure.lang.LazySeq.sval(LazySeq.java:47)
 1: clojure.lang.LazySeq.seq(LazySeq.java:56)
 2: clojure.lang.RT.seq(RT.java:440)
 3: clojure.core$seq__3970.invoke(core.clj:105)
 4: clojure.core$sort__4671.invoke(core.clj:1994)
 5: swank.commands.contrib.swank_fuzzy
$fuzzy_generate_matchings__1781.invoke(swank_fuzzy.clj:256)
 6: swank.commands.contrib.swank_fuzzy
$fuzzy_completion_set__1838$fn__1840.invoke(swank_fuzzy.clj:310)
 7: swank.commands.contrib.swank_fuzzy$call_with_timeout__1703.invoke
(swank_fuzzy.clj:127)
 8: swank.commands.contrib.swank_fuzzy
$fuzzy_completion_set__1838.invoke(swank_fuzzy.clj:309)
 9: swank.commands.contrib.swank_fuzzy
$eval__1849$fuzzy_completions__1851.invoke(swank_fuzzy.clj:323)
 10: clojure.lang.Var.invoke(Var.java:385)
 11: user$eval__2042.invoke(NO_SOURCE_FILE)
 12: clojure.lang.Compiler.eval(Compiler.java:5256)
 13: clojure.lang.Compiler.eval(Compiler.java:5224)
 14: clojure.core$eval__4688.invoke(core.clj:2036)
 15: swank.core$eval_in_emacs_package__399.invoke(core.clj:58)
 16: swank.core$eval_for_emacs__468.invoke(core.clj:126)
 17: clojure.lang.Var.invoke(Var.java:373)
 18: clojure.lang.AFn.applyToHelper(AFn.java:182)
 19: clojure.lang.Var.applyTo(Var.java:482)
 20: clojure.core$apply__4058.invoke(core.clj:437)
 21: swank.core$eval_from_control__401.invoke(core.clj:65)
 22: swank.core$eval_loop__403.invoke(core.clj:70)
 23: swank.core$spawn_repl_thread__526$fn__557$fn__559.invoke(core.clj:
179)
 24: clojure.lang.AFn.applyToHelper(AFn.java:172)
 25: clojure.lang.AFn.applyTo(AFn.java:164)
 26: clojure.core$apply__4058.invoke(core.clj:437)
 27: swank.core$spawn_repl_thread__526$fn__557.doInvoke(core.clj:176)
 28: clojure.lang.RestFn.invoke(RestFn.java:398)
 29: clojure.lang.AFn.run(AFn.java:37)
 30: java.lang.Thread.run(Thread.java:613)

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

For more options, visit this group at
   http://groups.google.com/group/clojure?hl=en

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

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

Re: Possible bug report

[Rich Hickey]

On Jul 29, 6:09 pm, Jason Wolfe jawo...@berkeley.edu wrote:
 Is this a bug?

 user (eval `(make-array ~Byte/TYPE 2))
 ; Evaluation aborted. (ExceptionInInitializerError)

 Compare:

 user (eval `(make-array ~Byte 2))
 #Byte[] [Ljava.lang.Byte;@26fcfd5c

 user (eval `(make-array Byte/TYPE 2))
 #byte[] [...@1f0feb6e

 user (make-array (eval Byte/TYPE) 2)
 #byte[] [...@7ce49289

 If not, can someone please help me understand what's going on here?


Yes, currently you cannot embed constants of primitive Class types.
This arises from an asymmetry in Java:

user= (.getName Byte)
java.lang.Byte

user= (Class/forName java.lang.Byte)
java.lang.Byte

user= (.getName Byte/TYPE)
byte

user= (Class/forName byte)
java.lang.ClassNotFoundException: byte (NO_SOURCE_FILE:0)

A patch to support reading, and embedded constants, of primitive Class
objects would be welcome. The current print-dup support won't do it.

If anyone is interested in contributing this patch please bring it up
on the clojure-dev group before proceeding and I can give you some
guidance as to what needs to be changed.

Thanks for the report,

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
-~--~~~~--~~--~--~---

Re: Possible bug report

[Aaron Cohen]

At my day job, we've always used a custom classloader to get around that
asymmetry.
-- Aaron


On Thu, Jul 30, 2009 at 9:51 AM, Rich Hickey richhic...@gmail.com wrote:




 On Jul 29, 6:09 pm, Jason Wolfe jawo...@berkeley.edu wrote:
  Is this a bug?
 
  user (eval `(make-array ~Byte/TYPE 2))
  ; Evaluation aborted. (ExceptionInInitializerError)
 
  Compare:
 
  user (eval `(make-array ~Byte 2))
  #Byte[] [Ljava.lang.Byte;@26fcfd5c
 
  user (eval `(make-array Byte/TYPE 2))
  #byte[] [...@1f0feb6e
 
  user (make-array (eval Byte/TYPE) 2)
  #byte[] [...@7ce49289
 
  If not, can someone please help me understand what's going on here?
 

 Yes, currently you cannot embed constants of primitive Class types.
 This arises from an asymmetry in Java:

 user= (.getName Byte)
 java.lang.Byte

 user= (Class/forName java.lang.Byte)
 java.lang.Byte

 user= (.getName Byte/TYPE)
 byte

 user= (Class/forName byte)
 java.lang.ClassNotFoundException: byte (NO_SOURCE_FILE:0)

 A patch to support reading, and embedded constants, of primitive Class
 objects would be welcome. The current print-dup support won't do it.

 If anyone is interested in contributing this patch please bring it up
 on the clojure-dev group before proceeding and I can give you some
 guidance as to what needs to be changed.

 Thanks for the report,

 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
-~--~~~~--~~--~--~---

Re: Possible bug report

[Jason Wolfe]

On Jul 30, 2009, at 6:51 AM, Rich Hickey wrote:
 On Jul 29, 6:09 pm, Jason Wolfe jawo...@berkeley.edu wrote:
 Is this a bug?

 user (eval `(make-array ~Byte/TYPE 2))
 ; Evaluation aborted. (ExceptionInInitializerError)

 Compare:

 user (eval `(make-array ~Byte 2))
 #Byte[] [Ljava.lang.Byte;@26fcfd5c

 user (eval `(make-array Byte/TYPE 2))
 #byte[] [...@1f0feb6e

 user (make-array (eval Byte/TYPE) 2)
 #byte[] [...@7ce49289

 If not, can someone please help me understand what's going on here?


 Yes, currently you cannot embed constants of primitive Class types.
 This arises from an asymmetry in Java:

 user= (.getName Byte)
 java.lang.Byte

 user= (Class/forName java.lang.Byte)
 java.lang.Byte

 user= (.getName Byte/TYPE)
 byte

 user= (Class/forName byte)
 java.lang.ClassNotFoundException: byte (NO_SOURCE_FILE:0)

 A patch to support reading, and embedded constants, of primitive Class
 objects would be welcome. The current print-dup support won't do it.

 If anyone is interested in contributing this patch please bring it up
 on the clojure-dev group before proceeding and I can give you some
 guidance as to what needs to be changed.

 Thanks for the report,

 Rich

Thanks for the clear explanation.

-Jason

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

Possible bug report

[Jason Wolfe]

Is this a bug?

user (eval `(make-array ~Byte/TYPE 2))
; Evaluation aborted. (ExceptionInInitializerError)

Compare:

user (eval `(make-array ~Byte 2))
#Byte[] [Ljava.lang.Byte;@26fcfd5c

user (eval `(make-array Byte/TYPE 2))
#byte[] [...@1f0feb6e

user (make-array (eval Byte/TYPE) 2)
#byte[] [...@7ce49289

If not, can someone please help me understand what's going on here?

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

Re: possible bug?

[Christophe Grand]

Cosmin Stejerean a écrit :
 On Wed, May 20, 2009 at 7:04 PM, George Jahad 
 andr...@blackbirdsystems.net mailto:andr...@blackbirdsystems.net 
 wrote:


 (def s1 (Symbol/create (.intern (first (.split user/n1 /)

 will fix your problem.


 That makes a lot of sense and I guess I should have paid attention to 
 the function definition for Symbol/create. Thanks!

You should also use Symbol/intern instead of Symbol/create.

Christophe


-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (en)



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

Re: possible bug?

[Michael Wood]

On Thu, May 21, 2009 at 9:15 AM, Christophe Grand christo...@cgrand.net wrote:

 Cosmin Stejerean a écrit :
 On Wed, May 20, 2009 at 7:04 PM, George Jahad
 andr...@blackbirdsystems.net mailto:andr...@blackbirdsystems.net
 wrote:


     (def s1 (Symbol/create (.intern (first (.split user/n1 /)

     will fix your problem.


 That makes a lot of sense and I guess I should have paid attention to
 the function definition for Symbol/create. Thanks!

 You should also use Symbol/intern instead of Symbol/create.

Is Symbol/create or Symbol/intern necessary?  This seems to work:

user= (def s1 (symbol (first (.split user/n1 /
#'user/s1
user= (def s2 (symbol user))
#'user/s2
user= (= s1 s2)
true
user= (class s1)
clojure.lang.Symbol
user= (class s2)
clojure.lang.Symbol
user= (ns-publics s1)
{s2 #'user/s2, s1 #'user/s1}
user= (ns-publics s2)
{s2 #'user/s2, s1 #'user/s1}
user=

-- 
Michael Wood esiot...@gmail.com

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

Re: possible bug?

[Cosmin Stejerean]

On Thu, May 21, 2009 at 3:35 AM, Michael Wood esiot...@gmail.com wrote:


 On Thu, May 21, 2009 at 9:15 AM, Christophe Grand christo...@cgrand.net
 wrote:
 
  Cosmin Stejerean a écrit :
  On Wed, May 20, 2009 at 7:04 PM, George Jahad
  andr...@blackbirdsystems.net mailto:andr...@blackbirdsystems.net
  wrote:
 
 
  (def s1 (Symbol/create (.intern (first (.split user/n1 /)
 
  will fix your problem.
 
 
  That makes a lot of sense and I guess I should have paid attention to
  the function definition for Symbol/create. Thanks!
 
  You should also use Symbol/intern instead of Symbol/create.

 Is Symbol/create or Symbol/intern necessary?  This seems to work:

 user= (def s1 (symbol (first (.split user/n1 /
 #'user/s1
 user= (def s2 (symbol user))
 #'user/s2
 user= (= s1 s2)
 true
 user= (class s1)
 clojure.lang.Symbol
 user= (class s2)
 clojure.lang.Symbol
 user= (ns-publics s1)
 {s2 #'user/s2, s1 #'user/s1}
 user= (ns-publics s2)
 {s2 #'user/s2, s1 #'user/s1}
 user=


I don't know how I missed the symbol function in the API. Thanks.

-- 
Cosmin Stejerean
http://offbytwo.com

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

possible bug?

[Cosmin Stejerean]

I have a feeling I'm doing something wrong bug I can't figure it out and I
can't rule out that it's not some kind of bug. I am trying to get the public
vars exposed by a namespace from a string. I am creating a symbol from the
string using Symbol/create and then calling ns-publics. This works just fine
if I create the symbol directly from a string, but it doesn't appear to work
when I create the symbol from the result of String.split(). I tried to
narrow this down to some problem in my code but I just can't figure it out.
Some help would be appreciated.
Example of reproducing this:

user= (import 'clojure.lang.Symbol)
nil
user= (def s1 (Symbol/create (first (.split user/n1 /
#'user/s1
user= (def s2 (Symbol/create user))
#'user/s2
user= (= (first (.split user/n1 /)) user)
true
user= (class (first (.split user/n1 /)))
java.lang.String
user= (ns-publics s1)
java.lang.Exception: No namespace: user found (NO_SOURCE_FILE:0)
user= (ns-publics s2)
{s2 #'user/s2, s1 #'user/s1}




-- 
Cosmin Stejerean
http://offbytwo.com

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

Re: possible bug?

[George Jahad]

Using cljdb I was able to step through the code and see that the
problem is
that symbol create is expecting an interned string.

Changing this:

(def s1 (Symbol/create (first (.split user/n1 /

to this:

(def s1 (Symbol/create (.intern (first (.split user/n1 /)

will fix your problem.

g

On May 20, 3:27 pm, Cosmin Stejerean cstejer...@gmail.com wrote:
 I have a feeling I'm doing something wrong bug I can't figure it out and I
 can't rule out that it's not some kind of bug. I am trying to get the public
 vars exposed by a namespace from a string. I am creating a symbol from the
 string using Symbol/create and then calling ns-publics. This works just fine
 if I create the symbol directly from a string, but it doesn't appear to work
 when I create the symbol from the result of String.split(). I tried to
 narrow this down to some problem in my code but I just can't figure it out.
 Some help would be appreciated.
 Example of reproducing this:

 user= (import 'clojure.lang.Symbol)
 nil
 user= (def s1 (Symbol/create (first (.split user/n1 /
 #'user/s1
 user= (def s2 (Symbol/create user))
 #'user/s2
 user= (= (first (.split user/n1 /)) user)
 true
 user= (class (first (.split user/n1 /)))
 java.lang.String
 user= (ns-publics s1)
 java.lang.Exception: No namespace: user found (NO_SOURCE_FILE:0)
 user= (ns-publics s2)
 {s2 #'user/s2, s1 #'user/s1}

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

Re: possible bug?

[Cosmin Stejerean]

On Wed, May 20, 2009 at 7:04 PM, George Jahad
andr...@blackbirdsystems.netwrote:


 Using cljdb I was able to step through the code and see that the
 problem is
 that symbol create is expecting an interned string.

 Changing this:

 (def s1 (Symbol/create (first (.split user/n1 /

 to this:

 (def s1 (Symbol/create (.intern (first (.split user/n1 /)

 will fix your problem.


That makes a lot of sense and I guess I should have paid attention to the
function definition for Symbol/create. Thanks!

-- 
Cosmin Stejerean
http://offbytwo.com

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

Possible bug of clojure.contrib.json.read

[Robert Luo]

the following code:

   (read-json-string (json-str {3 1}))

results NumberFormatException, I think maybe it does not expect
integer keys for a map.

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

Re: Possible bug of clojure.contrib.json.read

[Stuart Sierra]

On Apr 17, 10:00 am, Robert Luo robort...@gmail.com wrote:
 the following code:

    (read-json-string (json-str {3 1}))

 results NumberFormatException, I think maybe it does not expect
 integer keys for a map.

That's correct.  I was following the pure JSON spec at http://json.org/
which says that maps can only have strings as keys.  Maybe json-str
should enforce that.
-Stuart Sierra


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

Re: Possible bug in proxy: NPE for unqualified class

[Paul Drummond]

2009/4/3 Rich Hickey richhic...@gmail.com:
 Could you please submit an issue for that one?

No problem: http://code.google.com/p/clojure/issues/detail?id=102

Thanks,
Paul.
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
 Wear, DH5 8NE.

This message is intended only for the use of the person(s) (the
intended recipient(s)) to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

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

Possible bug in proxy: NPE for unqualified class

[Paul Drummond]

The following works - note ActionListener is fully qualified:

-
user= (.addActionListener (javax.swing.JButton.)
(proxy [java.awt.event.ActionListener] []
  (actionPerformed [evt]
   (println button press
nil
-
If I remove the package name I get a NullPointerException:

-
user= (.addActionListener (javax.swing.JButton.)
(proxy [ActionListener] []
  (actionPerformed [evt]
   (println button press
java.lang.NullPointerException (NO_SOURCE_FILE:161)
user=
--

Of course, I haven't imported ActionListener so I wouldn't expect it
to evaluate without error - I just wasn't expecting a
NullPointerException.

Paul
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
 Wear, DH5 8NE.

This message is intended only for the use of the person(s) (the
intended recipient(s)) to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

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

Re: Possible bug in proxy: NPE for unqualified class

[Rich Hickey]

On Apr 3, 10:33 am, Paul Drummond paul.drumm...@iode.co.uk wrote:
 The following works - note ActionListener is fully qualified:

 -
 user= (.addActionListener (javax.swing.JButton.)
 (proxy [java.awt.event.ActionListener] []
   (actionPerformed [evt]
(println button press
 nil
 -
 If I remove the package name I get a NullPointerException:

 -
 user= (.addActionListener (javax.swing.JButton.)
 (proxy [ActionListener] []
   (actionPerformed [evt]
(println button press
 java.lang.NullPointerException (NO_SOURCE_FILE:161)
 user=
 --

 Of course, I haven't imported ActionListener so I wouldn't expect it
 to evaluate without error - I just wasn't expecting a
 NullPointerException.


Could you please submit an issue for that one?

Thanks,

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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Possible Bug In clojure.zip/remove

[Jason Sankey]

Frantisek Sodomka wrote:
 On Mar 19, 12:58 pm, Jason Sankey ja...@zutubi.com wrote:
 Also, is there somewhere I can contribute test cases for this to
 prevent a future regression?
 
 Tests for clojure.zip can from now on go to test-clojure.clojure-zip:
 http://code.google.com/p/clojure-contrib/source/browse/trunk/src/clojure/contrib/test_clojure/clojure_zip.clj

Thanks, I plan on posting my CA today and can then look at adding a few 
cases.

 On Mar 20, 1:24 pm, Jason Sankey ja...@zutubi.com wrote:
 3) Test-is reports results for all (is ...) expressions separately, but
 there is no good way to name them separately.  At the moment I am
 reporting on each (is ...) as a separate test case by using the test
 name plus line number, but this is clunky.  I think combining the
 results so one deftest == one JUnit report test case would be more sensible.
 
 If there are any troubles with test-is, you can consult Stuart Sierra
 (the author of test-is).

Although it may have sounded that way, I didn't intend to suggest that 
the default test-is behaviour was wrong, I presumed it was intended that 
way, and I'm sure it has advantages.  For reporting the results in a CI 
server, though, and in particular when tracking the state of the same 
test across multiple builds, having each (is ...) as a separate case 
does not make sense.  My own reporting code can handle this be combining 
the results of multiple callbacks to (report ...) into a single test 
case result, which is what I plan to do.

Cheers,
Jason

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