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

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 be

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. > Here is one example tha

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/+ (sp/a

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

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 I

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 m

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 perf

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 o

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, December 30, 2015 at 12:02:35 P

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

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

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 unmap-test

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 pr

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

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'

Re: Possible bug in LockingTransaction

Thanks for the confirmation, Alex. Ticket filed. :) 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, 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

Re: Possible bug in LockingTransaction

On Wed, Sep 11, 2013 at 2:47 AM, 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. :) > >

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 - http://dev.clojure.org/jira/secure/Signup!defaul

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 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 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 wrote: > Hey Peter, > > On 19 February 2013 17:55, Peter Taoussanis wrote: > >> Hi Alex, >> >> This is a problem because the print-method multimethod implementation for

Re: Possible bug with realized? and cancelled futures

Hey Peter, On 19 February 2013 17:55, Peter Taoussanis 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 r

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 exceptio

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

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 databas

Re: Possible bug in clojure.java.jdbc

On Feb 6, 11:42 am, 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? JDBC is an in

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 a

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

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

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 column-str

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 > writes: > > >>> user> ((some-fn) ) > >>> false > >>> user> ((every-pred) ) > >>> true > >>> > >>> e.g. (some-cn) was equivalent to (constantly fa

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

Tassilo Horn writes: >>> user> ((some-fn) ) >>> false >>> user> ((every-pred) ) >>> 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

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

Max Penet writes: Hi Max, >> user> ((some-fn) ) >> false >> user> ((every-pred) ) >> 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

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

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,

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

Max Penet 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 o

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 exam

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

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

On Fri, Sep 7, 2012 at 5:26 AM, Shantanu Kumar 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

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 ni

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, doin

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 57

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 > wrote: > > In increasing order of difficulty... > > > > Option 1: > > > > Extend your comparator to sort first o

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

On Sat, Mar 24, 2012 at 9:39 PM, Cedric Greevey 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 [p

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 pr

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 al

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 y

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 c

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

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

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

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'

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

Re: possible bug in `case'

"Eric Schulte" 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

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 clau

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 java.lang.IllegalAr

Re: possible bug

That works. Thanks! take care, Mike On Sep 14, 1:38 am, Meikel Brandmeyer 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

Re: possible bug

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.

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 j

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, 1

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 wrote: > On Sun, Sep 12, 2010 at 3:58 PM, doc wrote: > > Hello, > > > I am relatively new to clojure and lispy languages in general.  I > > wrote a small program that manipulated thread vars using

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* gets

Re: possible bug

On Sun, Sep 12, 2010 at 3:58 PM, doc 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 prog

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

On 13 Sep 2010, at 00:24, icemaze wrote: (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

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 sub

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 dis

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

Re: Clojure Map function possible bug.

Thanks for your response guys. Ruben On Jul 21, 9:30 am, Stuart Halloway 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 wan

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 t

Re: Clojure Map function possible bug.

2010/7/21 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

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 b

Re: Possible BUG: NPE

On Wed, Dec 9, 2009 at 10:39 PM, Feng wrote: > > > On Dec 7, 9:39 pm, David Nolen 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 ca

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 wrote: > Does not happen for me throug

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 1

Re: Possible BUG: NPE

On Dec 7, 9:39 pm, David Nolen 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 m

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 Date: Fri Dec 4 11:22:04 2009 -0500 update example in reify doc - Feng On Dec 7, 9:34 pm, David Nolen wrote: >

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 wrote: > Looking at the stacktrace it looks like this is because of swank_fuzzy.clj. > I can start up the SLIME Repl

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 wrote: > > > On Dec 7, 8:57 pm, David Nolen

Re: Possible BUG: NPE

On Dec 7, 8:57 pm, David Nolen 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\*.

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 wrote: > Hi, > > After git pull on new branch > > commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 > Author: Rich Hic

Possible BUG: NPE

Hi, After git pull on new branch commit 1da63ad10d2531264e86eb705a10b3cebc9b1067 Author: Rich Hickey 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

Re: Possible bug report

On Jul 30, 2009, at 6:51 AM, Rich Hickey wrote: > On Jul 29, 6:09 pm, Jason Wolfe wrote: >> Is this a bug? >> >> user> (eval `(make-array ~Byte/TYPE 2)) >> ; Evaluation aborted. (ExceptionInInitializerError) >> >> Compare: >> >> user> (eval `(make-array ~Byte 2)) >> # >> >> user> (eval `(make-ar

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 wrote: > > > > On Jul 29, 6:09 pm, Jason Wolfe wrote: > > Is this a bug? > > > > user> (eval `(make-array ~Byte/TYPE 2)) > > ; Evaluation aborted. (Exceptio

Re: Possible bug report

On Jul 29, 6:09 pm, Jason Wolfe wrote: > Is this a bug? > > user> (eval `(make-array ~Byte/TYPE 2)) > ; Evaluation aborted. (ExceptionInInitializerError) > > Compare: > > user> (eval `(make-array ~Byte 2)) > # > > user> (eval `(make-array Byte/TYPE 2)) > # > > user> (make-array (eval Byte/TYPE)

Re: Possible bug report

On Wed, Jul 29, 2009 at 6:09 PM, Jason Wolfe wrote: > > Is this a bug? > > user> (eval `(make-array ~Byte/TYPE 2)) > ; Evaluation aborted. (ExceptionInInitializerError) > > Compare: > > user> (eval `(make-array ~Byte 2)) > # > > user> (eval `(make-array Byte/TYPE 2)) > # > > user> (make-array (ev

Possible bug report

Is this a bug? user> (eval `(make-array ~Byte/TYPE 2)) ; Evaluation aborted. (ExceptionInInitializerError) Compare: user> (eval `(make-array ~Byte 2)) # user> (eval `(make-array Byte/TYPE 2)) # user> (make-array (eval Byte/TYPE) 2) # If not, can someone please help me understand what's going

Re: possible bug?

On Thu, May 21, 2009 at 3:35 AM, Michael Wood wrote: > > On Thu, May 21, 2009 at 9:15 AM, Christophe Grand > wrote: > > > > Cosmin Stejerean a écrit : > >> On Wed, May 20, 2009 at 7:04 PM, George Jahad > >> mailto:andr...@blackbirdsystems.net>> > >> wrote: > >> > >> > >> (def s1 (Symbol/crea

Re: possible bug?

On Thu, May 21, 2009 at 9:15 AM, Christophe Grand wrote: > > Cosmin Stejerean a écrit : >> On Wed, May 20, 2009 at 7:04 PM, George Jahad >> mailto:andr...@blackbirdsystems.net>> >> wrote: >> >> >>     (def s1 (Symbol/create (.intern (first (.split "user/n1" "/") >> >>     will fix your proble

Re: possible bug?

Cosmin Stejerean a écrit : > On Wed, May 20, 2009 at 7:04 PM, George Jahad > 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 at

Re: possible bug?

On Wed, May 20, 2009 at 7:04 PM, George Jahad wrote: > > 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 (Symb

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 probl

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 of clojure.contrib.json.read

On Apr 17, 10:00 am, Robert Luo 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

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

  1   2   >