[ANN] SIXX 0.1d release

Hi,

SIXX (Smalltalk Instance eXchange in XML) has been updated. (now 0.1d).
http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html

 From this version, variable-but-not-bits objects can be (de)serialized.
(Thanks to Steve Waring).
Also error handling has been improved. So it is rare to encounter errors
when using SIXX.

SIXX runs on Squeak. VW, and Dolphin Smalltalk.
Try SIXX for storing/loading Smalltalk objects in a neutral XML format!

---
[:masashi | ^umezawa]

On Fri, 1 Nov 2002 01:48:53 +0900, "Masashi Umezawa"
<[hidden email]> wrote:

>SIXX runs on Squeak. VW, and Dolphin Smalltalk.
>Try SIXX for storing/loading Smalltalk objects in a neutral XML format!

On Dolphin XP, restoring the serialized objects from an XML file
greater than 8192 bytes in size fails. XMLTokenizer>>peek uses
Stream>>nextOrNil, which doesn't attempt to read in the next buffered
page from the file when it hits the end of the first buffered page.

I don't know exactly what nextOrNil is supposed to do (the comment in
my image refers to 'Squeak compatibility'), but for this specific
usage, it should probably be overridden in FileStream to try do
something similar to FileStream>>next before it thinks about returning
nil.

Then again, it is late here. :-)

Regards,
--
Jason Shannon http://www.araxis.com

Hi Jason,

> On Dolphin XP, restoring the serialized objects from an XML file
> greater than 8192 bytes in size fails. XMLTokenizer>>peek uses
> Stream>>nextOrNil, which doesn't attempt to read in the next buffered
> page from the file when it hits the end of the first buffered page.

Thanks, this is the Dolphin YAXO bug that was reported by Bill Schwab last
month.

> I don't know exactly what nextOrNil is supposed to do (the comment in
> my image refers to 'Squeak compatibility'), but for this specific
> usage, it should probably be overridden in FileStream to try do
> something similar to FileStream>>next before it thinks about returning
> nil.

Yes, a quick fix would be to re-implement FileStream>>next so that instead
of signalling the EndOfStreamSignal, it answers nil.

I think a proper fix is to modify Yaxo to remove the need for the #nextOrNil
method, but I have not had the time to look into this. If you do make any
fixes to the Yaxo packages, please email them through to me, and I will
update the download.

Thanks,
Steve

==========
Steve Waring
[hidden email]
http://www.dolphinharbor.org/dh/harbor/steve.html

Steve,

> > I don't know exactly what nextOrNil is supposed to do (the comment in
> > my image refers to 'Squeak compatibility'), but for this specific
> > usage, it should probably be overridden in FileStream to try do
> > something similar to FileStream>>next before it thinks about returning
> > nil.
>
> Yes, a quick fix would be to re-implement FileStream>>next so that instead
> of signalling the EndOfStreamSignal, it answers nil.

:(

> I think a proper fix is to modify Yaxo to remove the need for the
#nextOrNil
> method,

Dolphin has it right in signalling exceptions.  Unfortunately, Squeak isn't
helping.  It appears to have a good exception handling system (has for a
while IIRC), but the streams are still work the way one would expect in the
days before structured exceptions.  One bold step would be to patch Squeak's
read streams to signal exceptions on exhaustion, and then write in terms of
#next etc.  A _very_ quick test in my Squeak 3.2 image seemed ok with the
exceptions, but it would require a lot more testing to be certain.

If you don't fix Squeak's streams, then I think you are either going to need
#nextOrNil, or will have to maintain two versions.  The Dolphin #nextOrNil
could be written in terms of #next with an #on:do:, but it will be
inefficient.  My inclination (easy to say since it's *your* code<g>) is to
try to fix the Squeak streams; if the resulting system doesn't work, maybe
we can find and fix the problems.

Comments?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Bill and Jason,

I have uploaded a fixed version of DolphinYaxo to:

  http://www.dolphinharbor.org/dh/projects/goodies/yaxo.html

> If you don't fix Squeak's streams,

 ... that is taking a bigger bite than I can chew :)

> then I think you are either going to need
> #nextOrNil, or will have to maintain two
> versions.  The Dolphin #nextOrNil could be
> written in terms of #next with an #on:do:,
> but it will be inefficient.

Performance was the reason for the bug. After the initial port, I did a fair
bit of profiling testing its speed against MSXML, however there is no point
in being fast if it is not correct.

In the version I uploaded, rather than setting up an exception handler, I am
doing an #atEnd test. I also added some tests for FileStreams.

FWIW: If anybody is interested in doing any work with Yaxo, I have a large
Test package for it, based on Roger Whitney's test suite for the XML tests
by James Clark, Sun, and OASIS. It takes a bit of work to setup, but if you
are interested, email me, and I will send it through.

Thanks,
Steve

==========
Steve Waring
[hidden email]
http://www.dolphinharbor.org/dh/harbor/steve.html

Steve,

> > If you don't fix Squeak's streams,
>
>  ... that is taking a bigger bite than I can chew :)

Not necessarily - you could provide a separate file-in that does it, with
the caveat that to use YAXO, you need to have an image that tolerates
correct stream behavior.  With that said, I can easily understand why you
would choose not to try to chew it :)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]