There is a gap here I think where the return gets needlessly boxed.
> You might try just putting a nil expr after the set! as a workaround.
> In any case, we should definitely get a ticket filed and track this down.
>
>
> On Sunday, May 15, 2022 at 7:11:31 AM UTC-5 pete windle wrote:
I don't think that void type hint is going to do anything there. The
deftype impl of apply here will (has to by Java requirements) return void
here. There is a gap here I think where the return gets needlessly boxed.
You might try just putting a nil expr after the set! as a workaround.
I
ed for 1.11,
>>
>> https://clojure.atlassian.net/browse/CLJ-2621
>>
>> Don’t know if that helps much, though.
>>
>> Erik.
>> --
>> i farta
>>
>> 15. mai 2022 kl. 14:11 skrev pete windle :
>>
>> Hey, I'm trying to
e code using Clojure
> together with the Carrotsearch HPPC library. I've come up against a weird
> behaviour of set! in conjunction with primitive maths.
>
>
> This example is a toy problem not a production problem, but there are
> things I might not be harder to do at wor
using Clojure
> together with the Carrotsearch HPPC library. I've come up against a weird
> behaviour of set! in conjunction with primitive maths.
>
> This example is a toy problem not a production problem, but there are things
> I might not be harder to d
Hey, I'm trying to work on some performance sensitive code using Clojure
together with the Carrotsearch HPPC library. I've come up against a weird
behaviour of set! in conjunction with primitive maths.
This example is a toy problem not a production problem, but there are
things I mi
n the middle of a
> piece of code:
>
> (list (range)) - works fine
> [(range)] - works fine
> {:a (range)} - works fine
> #{(range)} - blocks forever
>
> Basically, I needed to pass a few lazy sequences in a set, and it blocked.
>
>
> Many thanks for any info in advance
Hi guys,
Is this expected behaviour - the following statements in the middle of a
piece of code:
(list (range)) - works fine
[(range)] - works fine
{:a (range)} - works fine
#{(range)} - blocks forever
Basically, I needed to pass a few lazy sequences in a set, and it blocked.
Many thanks for
ion and John's at the same time.
>>
>> Schism does not try to manage state for you over time; there are a lot of
>> good tools for doing that already (atoms, refs, agents, channels, etc).
>> Schism is a set of collections that augment basic clojure collections
I'll try to answer this question and John's at the same time.
>
> Schism does not try to manage state for you over time; there are a lot of
> good tools for doing that already (atoms, refs, agents, channels, etc).
> Schism is a set of collections that augment basic clojure collecti
I'll try to answer this question and John's at the same time.
Schism does not try to manage state for you over time; there are a lot of
good tools for doing that already (atoms, refs, agents, channels, etc).
Schism is a set of collections that augment basic clojure collections wi
again!
> On Apr 18, 2018, at 5:57 PM, Alex Redington wrote:
>
> Good evening!
>
> I submit for your evaluation and reasoned feedback a library I've been
> working on to provide a set of convergent replicated data types to Clojure
> and ClojureScript:
>
>
just like this recently, so thanks!
V/r
John
On Wed, Apr 18, 2018, 9:05 PM Alex Redington wrote:
> Good evening!
>
> I submit for your evaluation and reasoned feedback a library I've been
> working on to provide a set of convergent replicated data types to Clojure
> and
Good evening!
I submit for your evaluation and reasoned feedback a library I've been
working on to provide a set of convergent replicated data types to Clojure
and ClojureScript:
https://github.com/aredington/schism
[com.holychao/schism "0.1.0"]
Schism provides convergent colle
r your comments. As suggested I ran a small benchmark of both
> > versions. Turns out that the difference between (ref-set ref @ref) and
> > ensure is huge ...
> > I'm running clojure 1.8.0 by the way. According to VisualVM the (ref-set
> ref @ref) version spends most
2017-03-09 12:34 GMT+01:00 'bertschi' via Clojure :
> Thanks for your comments. As suggested I ran a small benchmark of both
> versions. Turns out that the difference between (ref-set ref @ref) and
> ensure is huge ...
> I'm running clojure 1.8.0 by the way. According t
2017-01-29 21:15 GMT+01:00 Michael Lindon :
> Not quite what I'm looking for. There is an assigment in the Functional
> Programming in Scala coursera course called "funsets" - purely functional
> sets. A set is defined by its characteristic functions (a predicate) and
&g
Am 29.01.2017 um 21:15 schrieb Michael Lindon:
> Not quite what I'm looking for. There is an assigment in the Functional
> Programming in Scala coursera course called "funsets" - purely
> functional sets. A set is defined by its characteristic functions (a
> predicate) a
Not quite what I'm looking for. There is an assigment in the Functional
Programming in Scala coursera course called "funsets" - purely functional
sets. A set is defined by its characteristic functions (a predicate) and
source code can be found here
https://mwclearning.com/s
core.logic's CLP(FD) extensions, for finite domains, might also suit your
needs: https://github.com/clojure/core.logic/wiki/Features#clpfd
--
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
N
There is a talk by Alex Engelberg about constraint solvers and his clojure
interface to one of them: https://github.com/aengelberg/loco
https://www.youtube.com/watch?v=AEhULv4ruL4
I'm not quite familiar with it, but maybe it's relevant to your
requirements.
--
You received this message because
Hi All,
First time poster in this google group. I'm looking for a slightly
different kind of* set* than the set collection offered in clojure.core.
Whilst the latter is great for finite sets, I'm looking for a package that
implements uncountable sets i.e. the set of real numbers le
or to totally get rid of the
> framework, I dont know what is the righ way to set up the connection.
>
> I tried to write the connection details (such as URI, conn and db) in the
> route-handler file and it works.
> But I know that I'm doing something wrong, because I've read
y get rid of the
framework, I dont know what is the righ way to set up the connection.
I tried to write the connection details (such as URI, conn and db) in the
route-handler file and it works.
But I know that I'm doing something wrong, because I've read that some
setup is done by
IReduce is a Java interface that can be used to allow a data structure to
directly indicate participation in being self-reducible. In cases where you
control the type (ie you are making the data structure), implementing
IReduce (or really IReduceInit) is usually better as it is checked first.
C
I wasn't aware Clojure had an IReduce protocol! I thought CollReduce was just
what IReduce is called in Clojure.
--
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 me
All credit to Francis for the reduce patch! The perf win is really great.
Re: IReduce – thanks, indeed, I forgot about the special-casing in reduce.
I guess I'll tweak that for the next release.
Incidentally, I notice I left out the final result in the after-patch 1.5.1
benchmark run in the previ
Nice work! Esp on the reduce stuff - great to see that. Any reason you
didn't go the IReduce path in Clojure too instead of CollReduce? Generally,
I'd say that's preferred when you control the data structure.
On Monday, August 22, 2016 at 7:43:51 PM UTC-5, Michał Marczyk wrote:
>
> Hi,
>
> I am
Hi,
I am pleased to announce the 0.0.14 release of data.avl, a Clojure
Contrib library providing highly performant drop-in replacements for
Clojure(Script)'s built-in sorted maps and sets that support O(log n)
nth, rank-of, first-class submaps/subsets (like subseq, but preserving
collection type;
I’m not clear what you’re suggesting those should do…?
Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
On 8/8/16, 11:28 PM, "Isaac Zeng" wrote:
That good sugges
ojure
> *Subject: *Re: can clojure java.jdbc function 'result-set-seq' add option
> tosupportcustom 'result-set-read-column' ?
>
>
>
> hi Sean,
>
>
>
> Done. see http://dev.clojure.org/jira/browse/JDBC-137
>
>
>
> Joe.
>
> On Su
Thank you! I’ll take a look at this while I’m back at work this week.
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org
From: Xiangtao Zhou
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email t
#x27;s View -- http://corfield.org
>
>
>
> *From: *Xiangtao Zhou
> *Sent: *Saturday, August 6, 2016 7:15 PM
> *To: *Clojure
> *Subject: *can clojure java.jdbc function 'result-set-seq' add option to
> supportcustom 'result-set-read-column' ?
>
&g
Hi Joe,
I’m starting to see more requests for per-database customization in a
multi-database environment so this is definitely something I’d consider. Could
you create a JIRA issue for tracking purposes, along with any suggestions you
have about how this might work – and remain performant?
htt
Hello the contributor of jdbc,
Using java.jdbc with postgres composite type, the common way is extend the
IResultSetReadColumn
protocol. When there are multiple databases in use, every database should
specify it's own column reader.
Add option to 'result-set-seq' support cus
Sets are unordered data structures, so it's by design.
- James
On 31 May 2016 at 13:54, wrote:
> I would expect the returned set to be
>
> #{1 2 3} but i get the following. Copied from repl
>
>
> user=> (set [1 1 2 2 3 3])
>
> #{1 3 2}
>
>
> user=&
sets & maps make no guarantee about the order of their entries. In fact,
they deliberately use hash functions to keep simple keys like 1,2,3 "spread
out" in their hash-codes. This causes the "random" ordering when printed.
If you want a set to print in order (often worth th
I believe you may have meant sorted-set
<http://clojuredocs.org/clojure.core/sorted-set>
On Tue, May 31, 2016 at 6:10 AM, vandr0iy
wrote:
> You could use sorted-map, if you wish to have them ordered:
>
> https://clojuredocs.org/clojure.core/sorted-map
>
> there is also sort
expect the returned set to be
>
> #{1 2 3} but i get the following. Copied from repl
>
>
> user=> (set [1 1 2 2 3 3])
>
> #{1 3 2}
>
>
> user=> (set '(1 1 2 3 2 4 5 5))
>
> #{1 4 3 2 5}
>
> --
> You received this message because you are subscr
I would expect the returned set to be
#{1 2 3} but i get the following. Copied from repl
user=> (set [1 1 2 2 3 3])
#{1 3 2}
user=> (set '(1 1 2 3 2 4 5 5))
#{1 4 3 2 5}
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
There is another idiom to consider if you need to involve a side effect
like notification. See http://clojure.org/reference/agents. You use a ref
instead of an atom, you modify the ref and trigger the notification (by
sending a function to an agent) inside a transaction, and the agent runs
th
that the other contenders keep looping until they are able
to acquire the atom. And that means a potentially significant increase in
overhead. compare-and-set! and swap! only work well when the number of
contenders is small, and a slow swap! function increases the chance of
having other contenders more
, you take it. Otherwise not.
>
> Now as for suitability. Note that the function passed to swap! must return
> the replacement value of your immutable structure. So it important
> that your structure records who got the resource being requested. And it
> looks like your structure handles that
. And it
looks like your structure handles that.
No need to use compare and set. The swap! function is good enough. It is
really a convenience function layered over compare-and-set.
Sometimes swap! is not powerful enough, which is when you use
compare-and-set.
On Monday, February 1, 2016 at 7:29
om my
understanding, checking the box and then swaping if the box is free is not
enough.
So I guessed I should use compare and set but I only understand how it
works with simple atom like (atom 1).
2 questions then : Is my data structure adapted for that ?
How to compare and set only for a nested
To do my bit to spread the Clojure meme, I've put together the essence of
the finest resources in print that have helped me grok Clojure. I take a
look at the following (Clojure, and related) books, in turn:
1. *The Joy of Clojure*, Second edition (Manning), by Michael Fogus and
Chris Hou
You could define your own cons type, like Bodil Stokke did for her
microkanren
https://github.com/bodil/microkanrens/blob/77dbdc34cde580e26765138102cbdabbfad85b9d/mk.clj#L13
If you mark its fields with ^:volatile-mutable, you can call (set! (.-a
lst) new-car) on a cons instance.
cheers
--
You
There is no equivalent to set-car!, because conses are not mutable. Only
vars, refs, atoms, and agents are mutable, and they are simply containers
for immutable values. You could put a cons inside an atom and put a new
transformed list into the atom. (Note even among schemes set-car! is highly
on SICP chap4.
>
> Where I encounter a problem with adding/modifying a def var/fn in
> enviroment.
>
> according to chap4 4.1.3 the set-variable-value! function looks like the
> following in scheme:
> (define (set-variable-value! var val env)
> (define (env-loop env)
>
Hi everyone,
I am current trying to implement a scheme interpreter in clojure following
the instruction on SICP chap4.
Where I encounter a problem with adding/modifying a def var/fn in
enviroment.
according to chap4 4.1.3 the set-variable-value! function looks like the
following in scheme
Okay, just found my mistake: the dependency was not listed in the
project which checks out the other project.
On Fri, Feb 27, 2015 at 5:12 PM, Timur Sungur wrote:
> Thanks for the suggestion but I had already tried it and no success.
>
> On Fri, Feb 27, 2015 at 7:58 AM, Eldar Gabdullin wrote:
Thanks for the suggestion but I had already tried it and no success.
On Fri, Feb 27, 2015 at 7:58 AM, Eldar Gabdullin wrote:
> Go to your checked out project and run "lein install" there.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To po
Go to your checked out project and run "lein install" there.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
fi
Hi all,
I'm trying to create a multi-project set-up using checkouts. My problem is
the checked out project contains a dependency which is not satisfied by the
project which checks it out. Consequently, I receive a FileNotFound
exception.
Do you have suggestions to solve this pr
Thanks
I haven't seen that method of paging before. The trade offs are interesting.
I've been toying around with how we might make sweet liberty have more of a
pluggable architecture -- allowing you to choose a custom feature set. This
could allow features that are independent,
On Tuesday, February 17, 2015 at 11:24:48 AM UTC-5, Bill Piel wrote:
>
> Blog post:
> https://blog.rjmetrics.com/2015/02/15/sweet-liberty-set-your-data-free-with-clojure-and-rest/
>
>
> Sweet-Liberty is a library for building database-backed RESTful services
> using Cloj
Blog post:
https://blog.rjmetrics.com/2015/02/15/sweet-liberty-set-your-data-free-with-clojure-and-rest/
Sweet-Liberty is a library for building database-backed RESTful services
using Clojure. You can think of it as a means to build and configure
components that translate between REST and SQL
Obviously...
user=> (= (byte 1) (short 1) (long 1) 1)
true
user=>
http://clojure.org/rationale
Language as platform vs. language + platform
- Old way - each language defines its own runtime
GC, bytecode, type system, libraries etc
- New way (JVM, .Net)
- Common runtime independent o
And this is not a typeless language, it is a strongly dynamically typed
language.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be
of their types but would be
> silent about other operators.
>
> Testing equality with floats is seldom used in the context of heavy
> computations. Testing against a range is often preferred.
>
Often, but there can be exceptions. When floats appear as part of objects
put in a se
Danger vs flexibility.
< or > are safe. Should they throw an exception then ?
Compiler in some older typed languages would warn you about testing equality
between two float numbers irrelevant of their types but would be silent about
other operators.
Testing equality with floats is seldom used
If the underlying argument is that it is horribly dangerous to mix floats
and doubles in your code, then maybe (<= (float 1.5) (double 1.5)) should
have the semantics of (.compareTo (float 1.5) (double 1.5)), i.e., throw an
error.
I'm not certain that's a good idea for Clojure, but it does seem li
On Jan 23, 2015, at 11:51 AM, Andy Fingerhut wrote:
> Hash consistency is certainly nice, but if Clojure were changed such that (=
> float-val double-val) were always false, and no other changes were made, it
> would lead to this situation:
>
> user=> (<= (float 1.5) (double 1.5))
> true
> user
Not sure which properties you prefer to be true in programming languages
you use. Hash consistency is certainly nice, but if Clojure were changed
such that (= float-val double-val) were always false, and no other changes
were made, it would lead to this situation:
user=> (<= (float 1.5) (double 1
On Jan 23, 2015, at 8:23 AM, Andy Fingerhut wrote:
> You can try creating a JIRA ticket suggesting that Clojure's = should return
> false when comparing floats and doubles to each other.
CLJ-1649, for anyone interested.
--
You received this message because you are subscribed to the Google
Grou
Michael:
You can try creating a JIRA ticket suggesting that Clojure's = should
return false when comparing floats and doubles to each other. I have no
idea if it would go anywhere, but alternative (2) trying to get hashes to
be equal between = float/doubles has been suggested and declined. Witho
I'm sure we are all aware of the various issues with floating point math
(particularly equality comparisons); however none of that is relevant to this
discussion. The only issue here is an inconsistency between hashing and
equality testing in Clojure.
My claim is that the property "any two obje
public class TestClass {
public static void equality () {
double dd = 3.5;
float ff = 3.5f;
System.out.println(String.format("dd vs ff == %b", dd==ff));
double dd2 = 3.2;
float ff2 =
Well if it breaks elsewhere than in your code because you mix representations
and leak
them to some library in Java that you do not control I see my comments as
absolutely relevant.
It's not technical, it's failsafe. But that might not be of any interest to
your problem scope.
However it does i
If there's a technical reason why Clojure can't return false for all =
comparisons between floats and doubles, I'd like to hear it. Otherwise, I don't
see how your response is relevant.
> On Jan 23, 2015, at 3:10 AM, Luc Prefontaine
> wrote:
>
> Agree, it's broken... in java...
> Has it has b
On Fri, Jan 23, 2015 at 1:10 AM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
> Agree, it's broken... in java...
>
I think it's more frustrating in Clojure than in Java, though, because in
Java you have those big, ugly type annotations on every single variable,
input and output, so there
Agree, it's broken... in java...
Has it has been broken in the past in several architectures...
I understand your frustration but this is not something new. It's been a
problem for at least 30 years.
It is kind of a basic programming issue:
- Never compare floats with different representations.
On Jan 23, 2015, at 1:33 AM, Immo Heikkinen wrote:
>
> I actually ran into this while comparing nested data structures from two
> different sources and spent a good part of my day figuring out what's
> happening. While it is a good advice to avoid mixing floats and doubles, it
> is inevitable
I actually ran into this while comparing nested data structures from two
different sources and spent a good part of my day figuring out what's
happening. While it is a good advice to avoid mixing floats and doubles, it
is inevitable that Clojure users will get bitten by this once in a while
and hou
Part of what you wish were true is already true: Using = to compare a
double to a BigDecimal always returns false in Clojure, as does comparing a
float to a BigDecimal.
It is only (= float-value double-value) that can return true in Clojure,
even though hash does not guarantee the usual hash consi
On Thursday, January 22, 2015 at 2:12:52 PM UTC-5, Jozef Wagner wrote:
>
> As seen in CLJ-1372, this issue will probably cause some strong opinions.
> I think this is an example of a leaky abstraction and the current approach
> is to leave it as is, as there are some serious trade-offs and are th
As seen in CLJ-1372, this issue will probably cause some strong opinions. I
think this is an example of a leaky abstraction and the current approach is
to leave it as is, as there are some serious trade-offs and are there is no
rationale or real practical reason to fix this.
Current implementation
And how to you want to proceed knowing that floats and double can escape
elsewhere in your app and create the same chaotic effect like for example,
in some interop call to some obscure library ?
The best ... consistency here seems to reflect what's occurring underneath
instead
of giving the false
On the side of positive recommendations to avoid problems like this, here
is some advice:
+ Don't mix floats and doubles in the same Clojure program. Given that
Clojure uses double arithmetic by default, it is much easier to use doubles
everywhere than it is to try to use floats everywhere.
+ Do
My one cent:
But I think (and it's just my humble opinion) is in the scope of Clojure
keep its consistency, am I right?
I mean, if doubles and floats are different, and they are, I think we
should always get equality test as false. Or always as true, if they're
nominally the same value.
Regards
"It is out of scope for Clojure to fix this for Java types Float/Double"
-- comments in CLJ-1036: http://dev.clojure.org/jira/browse/CLJ-1036
Andy
On Thu, Jan 22, 2015 at 5:53 AM, Nicola Mometto wrote:
>
> Not sure if this is intended behaviour:
> user=> (= (float 1.6) (double 1.6))
> false
>
Not sure if this is intended behaviour:
user=> (= (float 1.6) (double 1.6))
false
user=> (= (float 1.5) (double 1.5))
true
I.e. = (and ==) will return true when comparing floats with doubles IFF
the float's .doubleValue roundtrips to the same double it's comparing to.
user=> (.doubleValue (float
More on this behavior http://dev.clojure.org/jira/browse/CLJ-1036
On Thu, Jan 22, 2015 at 2:00 PM, Nicola Mometto wrote:
>
> Looking at the PHM impl, this looks like it's caused by (float 0.5) and
> (double 0.5) hashing differently.
>
> user=> (= (float 0.5) (double 0.5))
> true
> user=> (map ha
Looking at the PHM impl, this looks like it's caused by (float 0.5) and
(double 0.5) hashing differently.
user=> (= (float 0.5) (double 0.5))
true
user=> (map hash [(float 0.5) (double 0.5)])
(1056964608 1071644672)
Nicola Mometto writes:
> Looks like it's a bug in PersistentHashMap:
> user=> (
Looks like it's a bug in PersistentHashMap:
user=> (contains? (hash-map {:a (float 0.5)} 1) {:a (double 0.5)})
false
user=> (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)})
true
Immo Heikkinen writes:
> (= (float 0.5) (double 0.5))
> => true
> (= #{(float 0.5)} #{(double 0.5)})
> =>
(= (float 0.5) (double 0.5))
=> true
(= #{(float 0.5)} #{(double 0.5)})
=> true
(= {:a (float 0.5)} {:a (double 0.5)})
=> true
(= #{{:a (float 0.5)}} #{{:a (double 0.5)}})
=> false
Tested with both 1.6.0 and 1.7.0-alpha5.
--
You received this message because you are subscribed to the Google
Gro
rom lack of trying.
>
> The best lead I've got thus far is that there is a disj call that
> returns a defective set, which returns a positive value for count, but
> does not seem to contain any elements.
>
> I've tried to capture the offending values, but I can't
Unfortunately, no, but not from lack of trying.
The best lead I've got thus far is that there is a disj call that returns a
defective set, which returns a positive value for count, but does not seem
to contain any elements.
I've tried to capture the offending values, but I can'
e]
> (let [rems (clojure.set/difference prev' state')
> adds (clojure.set/difference state' prev')]
> (reset! prev state')
> (assert (= (count rems) (count (set rems))
>
> (prev and state hold sets of maps.)
>
> After running for a fe
x27;)
(assert (= (count rems) (count (set rems))
(prev and state hold sets of maps.)
After running for a few minutes, the assert will fail. The 'rems' and
'adds' will report that their count is > 1, but when I try to access the
elements there are either none or onl
gt;>
>> On 13 May 2014 14:20, Michał Marczyk wrote:
>>> It's not just to facilitate inlining, but also to limit the perf hit
>>> for hashing non-collections, some of which make completely reasonable
>>> map keys and set members. I've used the classes Alex Mi
nly
> none at all for classes using identity hash codes.
>
> Cheers,
> Michał
>
>
> On 13 May 2014 14:20, Michał Marczyk wrote:
>> It's not just to facilitate inlining, but also to limit the perf hit
>> for hashing non-collections, some of which make completely re
2014 14:20, Michał Marczyk wrote:
> It's not just to facilitate inlining, but also to limit the perf hit
> for hashing non-collections, some of which make completely reasonable
> map keys and set members. I've used the classes Alex Miller mentioned
> he was interested in for ben
It's not just to facilitate inlining, but also to limit the perf hit
for hashing non-collections, some of which make completely reasonable
map keys and set members. I've used the classes Alex Miller mentioned
he was interested in for benchmarking: Class, Character, Var; these
are all goo
handle non-java.util collection implementations,
but push the "default" cases down into the bottom of that method.
On Tuesday, May 13, 2014 12:38:54 AM UTC-4, Michał Marczyk wrote:
>
> I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
> hashes consistent with t
I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
hashes consistent with those of appropriate Clojure collection types
on the ticket.
Performance of repeated hasheq lookups on a single PHM actually seems
to be slightly better with this patch applied. Adding the hasheqs of a
P
also want to keep the new better hash functions, then I think this
implies extending the new hash calculation to relevant Java collections.
>
>
>
>
>
>>
>> On Saturday, 10 May 2014 15:51:24 UTC+1, John Hume wrote:
>>>
>>> Thanks for the ticket po
On Mon, May 12, 2014 at 4:26 PM, John D. Hume wrote:
> On Mon, May 12, 2014 at 12:53 PM, Alex Miller wrote:
>
>> My recommendation in Java would be the same - using mutable objects as
>> keys in a map (where mutability changes the hashcode) is a bug waiting to
>> happen.
>>
>
> Although I used ja
On Mon, May 12, 2014 at 12:53 PM, Alex Miller wrote:
> My recommendation in Java would be the same - using mutable objects as
> keys in a map (where mutability changes the hashcode) is a bug waiting to
> happen.
>
Although I used java.util.ArrayList in the sample REPL session showing the
surpris
On Mon, May 12, 2014 at 12:15 PM, John Hume wrote:
> On Sunday, May 11, 2014 6:33:25 PM UTC-5, Alex Miller wrote:
>
>> On Sun, May 11, 2014 at 2:06 PM, Mikera wrote:
>>
>>> OK. this thread is a bit worrying. If I understand correctly, it
>>> means that we've now got inconsistent hash and equa
1 - 100 of 694 matches
Mail list logo
