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] |
Free forum by Nabble | Edit this page |