On 12/19/2016 01:27 AM, Andres Valloud wrote:
At first glance, that the failure code only sees "two" things when it
should see "eight" seems to be problematic.
Perhaps the primitive insists on hashing byte objects, and there is a
distinction between "byte" objects and "word" objects (whatever
On 12/18/2016 02:29 AM, Andres Valloud wrote:
The primitive and the primitive failure code should behave the same?
You think the primitive is faulty? I haven't looked at the primitive
code, but it just fails when given a Float. From the name, I'd guess
that it's designed for a byte object.
Hi andres
I did not follow the discussion. My remark is just that a good discussion
without code for integration
does not improve Pharo and we will have people facing again the problem.
Stef
On Sun, 18 Dec 2016 11:29:11 +0100, Andres Valloud
wrote:
The primitive and the primitive failure code should behave the same?
On 12/18/16 2:13 , stepharong wrote:
Sorry but how can we improve the situation concretely
Stef
On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud
wrote:
Oh, ok... then the failure code
Sorry but how can we improve the situation concretely
Stef
On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud
wrote:
Oh, ok... then the failure code isn't doing what was intended :).
On 12/13/16 15:16 , Martin McClure wrote:
On 12/13/2016 08:39 AM,
On 12/13/2016 08:39 AM, Andres Valloud wrote:
> I would have expected the floats to be a byte object of size 8. Why is
> this conversion needed? Is somehow the primitive thinking the float has
> size 2? Or is the primitive hashing 32 bits at a time? The prim used
> to be a C version of the
On 12/10/16 10:36 , Martin McClure wrote:
On 12/09/2016 09:45 AM, Ben Coman wrote:
The suggested fix depended on being willing to let go of byte ordering
(which we might not want different results on different platforms)
Float>>hash
^ByteArray
hashBytes: self
startingWith: self
On 12/09/2016 09:45 AM, Ben Coman wrote:
The suggested fix depended on being willing to let go of byte ordering
(which we might not want different results on different platforms)
Float>>hash
^ByteArray
hashBytes: self
startingWith: self species hash
This fix contains a good idea,
If you do not really care about performance because there are not that may
geometric objects (say thousands), I guess that this would work (bit
pattern as string).
{
0.5 binaryLiteralString hash.
-0.5 binaryLiteralString hash.
}
Phil
On Fri, Dec 9, 2016 at 6:45 PM, Ben Coman
On Fri, Dec 9, 2016 at 10:51 PM, Hilaire wrote:
> Hi,
>
> In Dr. Geo I rely a lot on hash value for the geometric object. It
> largely improves speed up to compare geometric items (to avoid
> duplicated items). For example to detect when the user is building an
> already
Hi,
In Dr. Geo I rely a lot on hash value for the geometric object. It
largely improves speed up to compare geometric items (to avoid
duplicated items). For example to detect when the user is building an
already created object.
Also when describing geometric sketch with Smalltalk code, hundred
11 matches
Mail list logo