Sixx problems

Dale,

I tried to copy any of my pier instances to a new host. That didn't work. I found two glitches. The serialization of SimpleBlock produces something like

<sixxtag>{(^[:value| value anything])}</sixxtag>

The braces are removed on read but the parenthesis are not. This leads to a compile error in my case. Removing the parenthesis from the serialization fixed it for me.

And KeyValueDictionary is not working. It recurrs to Collection>>sixxDo: and only the values are serialized. I copied to Dictonary>>sixxDo: but I have doubts that this is the right solution. I added a test but that assumes as well that it does the handling by using Associations.

I checked in a new version of Sixx. It would be good if you could review this.

With those two changes I can serialize my PRKernel>>root and I'm able to read it back in into my second gemstone installation. For reading I'm using your old script that chunks  the input string in order not to exceed temporary memory. But if I try to serialze a whole kernel it always exceeds to temporary memory. I tried it from the shell with 'topaz -l -T200000' but then I get a stack overflow. Didn't you make this work in arbitrary depths back then?

Any hints how to be able to serialize are welcome,

Norbert

I'll double check on you SIXX changes, but if they work for you, then they're probably good changes.

Without seeing the exact errors being thrown, I can't guess what might be happening.

Have you looked at Ken's XML PullParser post?

  http://kentreis.wordpress.com/2009/06/01/deep-sixx-with-xml-pull-parser/

Rewriting the recursive algorithms _was_ the bulk of the work in porting SIXX to GemStone, so perhaps you've run into a case I didn't cover.

Send me a stack and I'll see if I can figure out what's up.

Dale

----- "Norbert Hartl" <[hidden email]> wrote:

| Dale,
|
| I tried to copy any of my pier instances to a new host. That didn't
| work. I found two glitches. The serialization of SimpleBlock produces
| something like
|
| <sixxtag>{(^[:value| value anything])}</sixxtag>
|
| The braces are removed on read but the parenthesis are not. This leads
| to a compile error in my case. Removing the parenthesis from the
| serialization fixed it for me.
|
| And KeyValueDictionary is not working. It recurrs to
| Collection>>sixxDo: and only the values are serialized. I copied to
| Dictonary>>sixxDo: but I have doubts that this is the right solution.
| I added a test but that assumes as well that it does the handling by
| using Associations.
|
| I checked in a new version of Sixx. It would be good if you could
| review this.
|
| With those two changes I can serialize my PRKernel>>root and I'm able
| to read it back in into my second gemstone installation. For reading
| I'm using your old script that chunks  the input string in order not
| to exceed temporary memory. But if I try to serialze a whole kernel it
| always exceeds to temporary memory. I tried it from the shell with
| 'topaz -l -T200000' but then I get a stack overflow. Didn't you make
| this work in arbitrary depths back then?
|
| Any hints how to be able to serialize are welcome,
|
| Norbert

Norbert,

Your SIXX changes looke good ... I moved #sixxDo: up to AbstractDictionary (the common superclass). Next time you update 1.0-beta.8 you'll pick up my (minor) change.

Thanks,

Dale
----- "Dale Henrichs" <[hidden email]> wrote:

| I'll double check on you SIXX changes, but if they work for you, then
| they're probably good changes.
|
| Without seeing the exact errors being thrown, I can't guess what might
| be happening.
|
| Have you looked at Ken's XML PullParser post?
|
|  
| http://kentreis.wordpress.com/2009/06/01/deep-sixx-with-xml-pull-parser/
|
| Rewriting the recursive algorithms _was_ the bulk of the work in
| porting SIXX to GemStone, so perhaps you've run into a case I didn't
| cover.
|
| Send me a stack and I'll see if I can figure out what's up.
|
| Dale
|
| ----- "Norbert Hartl" <[hidden email]> wrote:
|
| | Dale,
| |
| | I tried to copy any of my pier instances to a new host. That didn't
| | work. I found two glitches. The serialization of SimpleBlock
| produces
| | something like
| |
| | <sixxtag>{(^[:value| value anything])}</sixxtag>
| |
| | The braces are removed on read but the parenthesis are not. This
| leads
| | to a compile error in my case. Removing the parenthesis from the
| | serialization fixed it for me.
| |
| | And KeyValueDictionary is not working. It recurrs to
| | Collection>>sixxDo: and only the values are serialized. I copied to
| | Dictonary>>sixxDo: but I have doubts that this is the right
| solution.
| | I added a test but that assumes as well that it does the handling by
| | using Associations.
| |
| | I checked in a new version of Sixx. It would be good if you could
| | review this.
| |
| | With those two changes I can serialize my PRKernel>>root and I'm
| able
| | to read it back in into my second gemstone installation. For reading
| | I'm using your old script that chunks  the input string in order not
| | to exceed temporary memory. But if I try to serialze a whole kernel
| it
| | always exceeds to temporary memory. I tried it from the shell with
| | 'topaz -l -T200000' but then I get a stack overflow. Didn't you make
| | this work in arbitrary depths back then?
| |
| | Any hints how to be able to serialize are welcome,
| |
| | Norbert

Dale,

On 02.03.2010, at 23:06, Dale Henrichs wrote:

> Norbert,
>
> Your SIXX changes looke good ... I moved #sixxDo: up to AbstractDictionary (the common superclass). Next time you update 1.0-beta.8 you'll pick up
> my (minor) change.
>
thanks. I was also thinking about moving up the sixxDo: but as I'm not that familiar with the whole hierarchy I didn't dare.

I took your advize and reread Ken Treis' blog post about the pull parser. Well my problems are on serializing time I really like to try to pull parser. In his updated blog post he expresses the wish to synchronize your and his work. Has anything done in that direction so far? I hope I can start tomorrow porting the new xml parser stuff to gemstone. A good idea will than be to check sixx and the pull parser in one go and make it work. All of these projects are available on pharo/squeak and gemstone. I think it would be a good idea to combine them in the ConfigurationOfXMLSupport or another configuration. Only if the exist close to each other they will proceed to interoperate.

Norbert

That's not a bad idea ... Not sure which ConfigurationOf should be used... Why don't you bring up the naming question on the Pharo list and see what happens ...

Now that I think on it. separate configs is probably a good idea since each of the packages may depend upon a particular version of XML-Parser and separate configs makes it easy to manage the dependencies...

Dale

----- "Norbert Hartl" <[hidden email]> wrote:

| Dale,
|
| On 02.03.2010, at 23:06, Dale Henrichs wrote:
|
| > Norbert,
| >
| > Your SIXX changes looke good ... I moved #sixxDo: up to
| AbstractDictionary (the common superclass). Next time you update
| 1.0-beta.8 you'll pick up
| > my (minor) change.
| >
| thanks. I was also thinking about moving up the sixxDo: but as I'm not
| that familiar with the whole hierarchy I didn't dare.
|
| I took your advize and reread Ken Treis' blog post about the pull
| parser. Well my problems are on serializing time I really like to try
| to pull parser. In his updated blog post he expresses the wish to
| synchronize your and his work. Has anything done in that direction so
| far? I hope I can start tomorrow porting the new xml parser stuff to
| gemstone. A good idea will than be to check sixx and the pull parser
| in one go and make it work. All of these projects are available on
| pharo/squeak and gemstone. I think it would be a good idea to combine
| them in the ConfigurationOfXMLSupport or another configuration. Only
| if the exist close to each other they will proceed to interoperate.
|
| Norbert
| > Thanks,
| >
| > Dale
| > ----- "Dale Henrichs" <[hidden email]> wrote:
| >
| > | I'll double check on you SIXX changes, but if they work for you,
| then
| > | they're probably good changes.
| > |
| > | Without seeing the exact errors being thrown, I can't guess what
| might
| > | be happening.
| > |
| > | Have you looked at Ken's XML PullParser post?
| > |
| > |  
| > |
| http://kentreis.wordpress.com/2009/06/01/deep-sixx-with-xml-pull-parser/
| > |
| > | Rewriting the recursive algorithms _was_ the bulk of the work in
| > | porting SIXX to GemStone, so perhaps you've run into a case I
| didn't
| > | cover.
| > |
| > | Send me a stack and I'll see if I can figure out what's up.
| > |
| > | Dale
| > |
| > | ----- "Norbert Hartl" <[hidden email]> wrote:
| > |
| > | | Dale,
| > | |
| > | | I tried to copy any of my pier instances to a new host. That
| didn't
| > | | work. I found two glitches. The serialization of SimpleBlock
| > | produces
| > | | something like
| > | |
| > | | <sixxtag>{(^[:value| value anything])}</sixxtag>
| > | |
| > | | The braces are removed on read but the parenthesis are not.
| This
| > | leads
| > | | to a compile error in my case. Removing the parenthesis from
| the
| > | | serialization fixed it for me.
| > | |
| > | | And KeyValueDictionary is not working. It recurrs to
| > | | Collection>>sixxDo: and only the values are serialized. I copied
| to
| > | | Dictonary>>sixxDo: but I have doubts that this is the right
| > | solution.
| > | | I added a test but that assumes as well that it does the
| handling by
| > | | using Associations.
| > | |
| > | | I checked in a new version of Sixx. It would be good if you
| could
| > | | review this.
| > | |
| > | | With those two changes I can serialize my PRKernel>>root and
| I'm
| > | able
| > | | to read it back in into my second gemstone installation. For
| reading
| > | | I'm using your old script that chunks  the input string in order
| not
| > | | to exceed temporary memory. But if I try to serialze a whole
| kernel
| > | it
| > | | always exceeds to temporary memory. I tried it from the shell
| with
| > | | 'topaz -l -T200000' but then I get a stack overflow. Didn't you
| make
| > | | this work in arbitrary depths back then?
| > | |
| > | | Any hints how to be able to serialize are welcome,
| > | |
| > | | Norbert