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

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

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

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

Re: clojure.spec possible bug

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.

clojure.spec possible bug

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/+

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

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

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

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

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

(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

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

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

Re: Possible bug in clojure.set/union?

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

Re: Possible bug in clojure.set/union?

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

Possible bug in clojure.set/union?

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

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

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

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

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,

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

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

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

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,

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

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

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

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

Re: possible bug in 1.51?

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

possible bug in 1.51?

;; 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:

Re: Possible bug in LockingTransaction

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

Re: Possible bug in LockingTransaction

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

Possible bug in LockingTransaction

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

Re: Possible bug in LockingTransaction

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 -

Re: Possible bug in LockingTransaction

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

Re: Possible bug in LockingTransaction

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

Possible bug with realized? and cancelled futures

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

Re: Possible bug with realized? and cancelled futures

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

Re: Possible bug with realized? and cancelled futures

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

Re: Possible bug with realized? and cancelled futures

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

Re: Possible bug with realized? and cancelled futures

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

Re: Possible bug in clojure.java.jdbc

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

Re: Possible bug in clojure.java.jdbc

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

Possible bug in clojure.java.jdbc

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

Re: Possible bug in clojure.java.jdbc

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

Re: Possible bug in clojure.java.jdbc

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,

Re: Possible bug in clojure.java.jdbc

@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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Possible bug in CLJS `case` with quoted symbols

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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:

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

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]

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

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

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

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

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

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

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

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

Re: possible bug in `case'

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

Re: possible bug in `case'

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

possible bug in `case'

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

Re: possible bug in `case'

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

Re: possible bug

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

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

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*

Re: possible bug

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

Re: possible bug

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,

Re: possible bug

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

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

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

possible bug

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

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

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

Clojure Map function possible bug.

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

Re: Clojure Map function possible bug.

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

Re: Clojure Map function possible bug.

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

Re: Clojure Map function possible bug.

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

Re: Possible BUG: NPE

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

Re: Possible BUG: NPE

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

Re: Possible BUG: NPE

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

Re: Possible BUG: NPE

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

Possible BUG: NPE

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:

Re: Possible BUG: NPE

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

Re: Possible BUG: NPE

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

Re: Possible BUG: NPE

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,

Re: Possible BUG: NPE

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

Re: Possible BUG: NPE

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,

Re: Possible bug report

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

Re: Possible bug report

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)) ;

Re: Possible bug report

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[]

Possible bug report

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[]

Re: possible bug?

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

Re: possible bug?

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 /)

Re: possible bug?

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

possible bug?

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

Re: possible bug?

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

Re: possible bug?

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:

Possible bug of clojure.contrib.json.read

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

Re: Possible bug of clojure.contrib.json.read

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

Re: Possible bug in proxy: NPE for unqualified class

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,

Possible bug in proxy: NPE for unqualified class

The following works - note ActionListener is fully qualified: - user= (.addActionListener (javax.swing.JButton.) (proxy [java.awt.event.ActionListener] [] (actionPerformed [evt] (println button press nil

Re: Possible bug in proxy: NPE for unqualified class

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]

Re: Possible Bug In clojure.zip/remove

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:

  1   2   >