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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Possible bug in proxy: NPE for unqualified class

2009/4/3 Rich Hickey : > 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 8N

Re: Possible bug in proxy: NPE for unqualified class

On Apr 3, 10:33 am, Paul Drummond 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 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/brow

Re: Possible Bug In clojure.zip/remove

On Mar 19, 12:58 pm, Jason Sankey 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_c

Re: Possible Bug In clojure.zip/remove

Hi Frantisek, Frantisek Sodomka wrote: > On Mar 19, 11:37 pm, Jason Sankey wrote: >> I pretty much have it working for the test-clojure suite now, although >> I'm sure the code could use review by a more experienced eye. I've been >> looking at adding the other two top-level suites (test-contri

Re: Possible Bug In clojure.zip/remove

On Mar 19, 11:37 pm, Jason Sankey wrote: > I pretty much have it working for the test-clojure suite now, although > I'm sure the code could use review by a more experienced eye.  I've been > looking at adding the other two top-level suites (test-contrib and > datalog) too, but their test clojure

Re: Possible Bug In clojure.zip/remove

Hi Frantisek, Frantisek Sodomka wrote: > On Mar 19, 12:58 pm, Jason Sankey wrote: >> Also, is there somewhere I can contribute test cases for this to >> prevent a future regression? > > In order to contribute, you must fill-in and send The Contributor > Agreement (CA) to Rich Hickey: > http://c

Re: Possible Bug In clojure.zip/remove

On Mar 19, 12:58 pm, Jason Sankey wrote: > Also, is there somewhere I can contribute test cases for this to > prevent a future regression? In order to contribute, you must fill-in and send The Contributor Agreement (CA) to Rich Hickey: http://clojure.org/contributing Tests for clojure.core are

Re: Possible Bug In clojure.zip/remove

On Mar 19, 7:22 am, Christophe Grand wrote: > Jason Sankey a écrit : > > > (if (and (branch? loc) (not (empty? (children loc > > (recur (-> loc down rightmost)) > > loc)) > > > Being new to both clojure and zip I admit there's still a good chance > > that I have no idea what I'm talking

Re: Possible Bug In clojure.zip/remove

Hi Christophe, On Mar 19, 11:22 am, Christophe Grand wrote: > Jason Sankey a écrit : > > > (if (and (branch? loc) (not (empty? (children loc > >   (recur (-> loc down rightmost)) > >   loc)) > > > Being new to both clojure and zip I admit there's still a good chance > > that I have no idea w

Re: Possible Bug In clojure.zip/remove

Jason Sankey a écrit : > (if (and (branch? loc) (not (empty? (children loc > (recur (-> loc down rightmost)) > loc)) > > Being new to both clojure and zip I admit there's still a good chance > that I have no idea what I'm talking about :). > No you are right and there's the same bug in

Re: Possible bug in sorted-set, question about comparisons

Thanks for explanation, all! Frantisek On 20 Ún, 20:57, Jason Wolfe wrote: > It probably does an "identical?" call on a pair before calling > compare, for efficiency.  In other words, it may "work" on non- > comparable types, but only when passed n instances of the exact same > object: > > user

Re: Possible bug in sorted-set, question about comparisons

It probably does an "identical?" call on a pair before calling compare, for efficiency. In other words, it may "work" on non- comparable types, but only when passed n instances of the exact same object: user> (sorted-set '(1) '(1)) ; Exception user> (let [x '(1)] (sorted-set x x)) #{(1)} This

Re: Possible bug in sorted-set, question about comparisons

It looks that it is more complicated than that: user=> (sorted-set () ()) #{()} user=> (sorted-set {} {}) #{{}} user=> (sorted-set #{} #{}) #{#{}} Frantisek On 20 Ún, 20:33, Vincent Foley wrote: > I'm pretty sure that sorted-set works only with values that are > instances of a class that implem

Re: Possible bug in sorted-set, question about comparisons

I'm pretty sure that sorted-set works only with values that are instances of a class that implements Comparable. user=> (instance? Comparable []) true user=> (instance? Comparable {}) false user=> (instance? Comparable ()) false user=> On Feb 20, 2:21 pm, Frantisek Sodomka wrote: > sorted-set

Re: Possible bug in preduce

On Feb 3, 11:09 pm, Rich Hickey wrote: > On Feb 3, 4:43 pm, Anand Patil > wrote: > No, it's not. as the docs for preduce say:http://clojure.org/api#preduce > > "Also note that (f base an-element) might be performed many times" > > in fact, an arbitrary number of times depending on how many pa

Re: Possible bug in preduce

I got a 50% speedup using psort instead of sort with a compute- intensive comparator and a 100 element sequence on a dual-core machine. That said, I found a faster way to do it: I separated the intensive calculations from the comparator - just returning a numeric value. I used pmap to get a seque

Re: possible bug with doto and function literals

On Feb 3, 2009, at 10:32 PM, kyle smith wrote: (map #(doto %1 (.add 2)) (doto (new java.util.ArrayList) (.add 1))) user=> (map #(doto %1 (.add 2)) (doto (new java.util.ArrayList) (.add 1))) java.lang.IllegalArgumentException: No matching method found: add for class java.lang.Integer T

Re: Possible bug in preduce

A month or so ago, I installed the ForkJoin library, and played around with the clojure.parallel wrapper library, and I wasn't able to get a single test to show a speed improvement on my dual core machine. In contrast, pmap, which doesn't rely on the ForkJoin library, works just fine. It makes m

Re: Possible bug in preduce

On Feb 3, 4:43 pm, Anand Patil wrote: > Hi all, > > Messing around with preduce at the REPL I saw this: > > user=> (defn q [sofar new] (do (print new sofar"\n") (+ (+ 1 new) > sofar))) > #'user/q > user=> (reduce q 0 [1 2 > 3]) > 1 0 > 2 2 > 3 5 > 9 > user=> (preduce q 0 [1 2 > 3]) > 3 2 > 6 1

Re: possible bug with seq and Enumeration?

Using enumeration-seq does the trick! Thanks. user=> (enumeration-seq (.entries (java.util.zip.ZipFile. ""))) On Mon, Dec 15, 2008 at 5:14 PM, Rich Hickey wrote: > > > > On Dec 15, 6:01 pm, "Brian Doyle" wrote: > > According to the docs the seq function should be able to take an > > enumerati

Re: possible bug with seq and Enumeration?

On Dec 15, 6:01 pm, "Brian Doyle" wrote: > According to the docs the seq function should be able to take an > enumeration, > but here is what I see: > > user=> (seq (.elements (doto (java.util.Vector.) (.add "hello") (.add > "world" > java.lang.IllegalArgumentException: Don't know how to cr

Re: Possible bug? StringIndexOutOfBoundException

On Nov 20, 12:37 pm, Feng <[EMAIL PROTECTED]> wrote: > I start getting StringIndexOutOfBoundException since svn rev 1113 (use > source name in smap). Fixed - rev 1120 - thanks for the report. Rich --~--~-~--~~~---~--~~ You received this message because you are s

Re: Possible bug with accessing child classes

On Sep 24, 9:33 pm, ".Bill Smith" <[EMAIL PROTECTED]> wrote: > Try this: > > user=> (import '(java.util Map$Entry)) > nil > user=> Map$Entry > java.util.Map$Entry > user=> Perfect! Thanks! - James --~--~-~--~~~---~--~~ You received this message because you are sub

Re: Possible bug with accessing child classes

James, Try this: user=> (import '(java.util Map$Entry)) nil user=> Map$Entry java.util.Map$Entry user=> Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to cl