[vwnc] [Fwd: Re: Port of GOODS database client on public StORE]

Stefan Schmiedl wrote: Bummer.  I've published 1.11 which fixes this bug.


David



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi David,

I tried committing some data structure to your GOODS client (1.11) and
found two problems with the goodsWriteTaggedOn: methods of classes
Boolean and Float. There are methods referenced which are undefined in
VW.

Float>>asIEEE32BitWord
...Stream>>boolean:

Thanks,
s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi David,

another question:

KKStringField>>writeField:onStream uses uint16: on the string's characters,
while the extension Character>>goodsWriteTaggedOn: uses nextInt32Put:.
Is this intentional?

Also: What is the idea behind

Object>>= anObject
        ^self == anObject yourself

vs. the original implementation of

        ^self == anObject

Thanks,
s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Stefan Schmiedl wrote:
> Hi David,
>
> another question:
>
> KKStringField>>writeField:onStream uses uint16: on the string's characters,
> while the extension Character>>goodsWriteTaggedOn: uses nextInt32Put:.
> Is this intentional?
>  
I don't think it is intentional.  Characters are stored as immediate
values using a "tagged pointer" requiring a 2 byte tag and 32 bits for
the pointer part even though it is just a single 16 bit character.  I
believe that the first two bytes of this 32 bits should be zero so maybe
a more explicit version would write the two zero bytes then the 16 bit
character.  GOODS has a special storage structure for strings and this
client tries to map Smalltalk strings onto that representation.  In that
structure each character is 16 bits....this part seems right.  I have
rewritten the character version as:

Character>>goodsWriteTaggedOn: aStream
    aStream nextPut: 5; nextPut: 0; nextPut: 0; uint16: self asInteger

and everything works as expected.  I will check with Konstantin to get
the final word on character and string representations.
> Also: What is the idea behind
>
> Object>>= anObject
> ^self == anObject yourself
>  
anObject might be a proxy so this ensures that #= properly answers true
in a comparison between an object and the proxy to that object.

David


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Stefan Schmiedl wrote: 1.12 fixes Booleans.

I've added test cases for Booleans, Floats (which fail) and Doubles
(which pass but they're not being stored as immediates so please don't
count on them yet).  The Float/Double solution will take me a bit of
time to sort out and some suggestions would be helpful.  I'm concerned
about the interaction of the conversion algorithm with the -ieeefp VM
option (and corresponding parcel) and I'd like to implement the
conversion in a way that will work correctly with or without this option.

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Wed, 25 Jun 2008 10:35:26 -0400
"C. David Shaffer" <[hidden email]> wrote:

> > Also: What is the idea behind
> >
> > Object>>= anObject
> > ^self == anObject yourself
> >  
> anObject might be a proxy so this ensures that #= properly answers true
> in a comparison between an object and the proxy to that object.

Ah, yes, that murky proxy stuff I never get my head around.

Thanks for explaining.

Just checking: Did you see the other message with the missing methods
for writing booleans and floats to the database?

s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

After giving my local fetchmail a swift kick, I now see that
on Wed, 25 Jun 2008 10:44:41 -0400
"C. David Shaffer" <[hidden email]> wrote:

> 1.12 fixes Booleans.

Great, thanks.

> I've added test cases for Booleans, Floats (which fail) and Doubles
> (which pass but they're not being stored as immediates so please don't
> count on them yet).  The Float/Double solution will take me a bit of
> time to sort out and some suggestions would be helpful.  I'm concerned
> about the interaction of the conversion algorithm with the -ieeefp VM
> option (and corresponding parcel) and I'd like to implement the
> conversion in a way that will work correctly with or without this option.

hmmm... I have no experience to offer in that area.

Is there a way to get something working for floats and doubles, even
if it might be slow? I'm not concerned about long-term storage here, I'd
just like to have a way to dump some application objects into the
database. Strictly for experimenting with a GOODS backend to a Seaside
frontend.

Thanks,
s.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Stefan Schmiedl wrote: Just for experimentation you can remove Float>>goodsIsImmediate and
Float>>goodsWriteTaggedOn: and floats will be written as normal object
references.  The (simple) test passes then.

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc