outFiler := STBOutFiler nextPut: (ListModel on: someSortedCollection)

Hi all,

    I'm having some trouble trying to store in binary format a collection
that holds near 11K objects.

    The collection is aListModel with a sorted collection inside and the
code to file out it is this:

"Writting:"

obj := aBigListModelWithASortedCollection.
str := FileStream write:'BigCollection.stb' text:false.
out := STBOutFiler on: str reset.
out nextPut: obj.
str close.
obj := nil.
"Reading:"
str := FileStream read:'BigCollection.stb' text:false.
in := STBInFiler on: str reset.
obj := in next

    Can anyone explain me why it can't deserialize?

    The exception it bring in this winXP is 'Failed to create window'

    Right now I'm saving only the collection asOrderedCollection because of
this.

    best regards,

Seb

hi all

Smalltalkiano <[hidden email]> escribió en el mensaje de noticias
b74ilt$avbjo$[hidden email]...
 try

 str := FileStream write:'BigCollection.stb' text:false.
 str  nextPutAll: obj binaryStoreBytes.
 str close.


> "Reading:"
> str := FileStream read:'BigCollection.stb' text:false.
> in := STBInFiler on: str reset.
> obj := in next

str := FileStream read:'BigCollection.stb' text:false.
 in := STBInFiler on: str.
 obj := in next

works for my.

    best regards
    MDC


>
>     Can anyone explain me why it can't deserialize?
>
>     The exception it bring in this winXP is 'Failed to create window'
>
>     Right now I'm saving only the collection asOrderedCollection because
of
> this.
>
>     best regards,
>
> Seb
>
>

Seb,

>     Can anyone explain me why it can't deserialize?
>     The exception it bring in this winXP is 'Failed to create window'
>     Right now I'm saving only the collection asOrderedCollection because
of
> this.

There at least was a problem serializing list models, with the sort block
being the culprit.  The archives will contain specifics, and possibly an
indication of whether it's been fixed.

Have a good one,

Bill

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

Seb,

>     The collection is aListModel with a sorted collection inside and
> the code to file out it is this:
[]
>     Can anyone explain me why it can't deserialize?
>
>     The exception it bring in this winXP is 'Failed to create window'

That sounds like the old problem where the SortBlock is defined within a
View resource and the exported SortedCollection retains a reference to
the View (as the context for the SortBlock?). When you file the
ListModel back in the SC tries to access a View that doesn't exists and
an error occurs (or something like that).

IIRC, there is a page on the WIKI about this and it has been mentioned a
few times in the n/g so it might be worth a trawl through the archive.

[aside] I can vaguely remember some comment being made about how this
won't be a problem in the future but I can't remember the details (and
might have been dreaming)

>     Right now I'm saving only the collection asOrderedCollection
> because of this.

Which might well be the safest way to go.

One other thing.  I don't know if it will help in this case but there is
a built in debugger (tracer really) for STB.  If you replace the next to
last line in your example with the following then the Trancript will
show a trace of the objects as they are reconstituted from the file.  In
some cases it can be a help in pinpointing where a problem is occurring.

in := STBDebugger on: str reset.

--
Ian

"Smalltalkiano" <[hidden email]> wrote in message
news:b74ilt$avbjo$[hidden email]...
>     I'm having some trouble trying to store in binary format a collection
> that holds near 11K objects.
>
>     The collection is aListModel with a sorted collection inside and the
> code to file out it is this:
...
>     Can anyone explain me why it can't deserialize?
>
>     The exception it bring in this winXP is 'Failed to create window'

For some reason this sounds familiar to me, but I don't remember any
details.  I wonder if you may accidentally be storing a view with your
objects.  Perhaps one of your objects unexpectedly references a view.  Debug
into the exception and see why it is trying to create a window.  You may
also try loading your stb bytes with the STBDebugger to see exactly what is
being stored.  Perhaps you have more than you think you have.

Chris

Ian,

> [aside] I can vaguely remember some comment being made about how this
> won't be a problem in the future but I can't remember the details (and
> might have been dreaming)

Then I think we both had the same dream :)  What I don't remember is whether
the discussion included "it's fixed now" or "it will be fixed when".

Have a good one,

Bill

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

Ian, Bill

"Bill Schwab" <[hidden email]> wrote in message
news:b7524j$b37ng$[hidden email]...
> Ian,
>
> > [aside] I can vaguely remember some comment being made about how this
> > won't be a problem in the future but I can't remember the details (and
> > might have been dreaming)
>
> Then I think we both had the same dream :)  What I don't remember is
whether
> the discussion included "it's fixed now" or "it will be fixed when".

The issue of the "self" reference of a block causing unexpected objects to
be referenced is a consequence of the Smalltalk-80 style blocks in current
versions of Dolphin. Basically all blocks will have a self reference,
regardless of whether 'self' (or an instance variable) is actually
referenced from the block. A workaround for this (if it is not needed) is to
explicitly nil out the self slot by sending #receiver: to the block object.

Another related issue is that of blocks retaining a reference to their last
argument(s). This is because the arguments are implemented as slots in a
shared MethodContext. A workaround for this problem is to assign nil to the
arguments before exit from the block.

These issues with old-style blocks are "fixed" in D6 in that the blocks are
proper closures and only retain as much context as they absolutely need to
be evaluated. In the case of sort blocks, these are usually completely
"clean" (that is they reference only their arguments, and not any other
variables, and they don't contain ^-returns), and D6 will treat these as
shared literals.

In D6 block arguments, and the majority of temporaries, are always stored in
stack slots. This means that the references from these variables are only
live for the duration of the block evaluation. Assignment to block arguments
is no longer legal and will result in a compilation error.

Regards

Blair

Hi all,

    I'm using right now the Diaz Cortez approach, because for some reason it
works fine on the listModel.

    Dear Blair perhaps you could bring some light to this matter.

    The only significative difference is to store the object like this

 str := FileStream write:'BigCollection.stb' text:false.
 str  nextPutAll: obj binaryStoreBytes.
 str close.

    Instead usig a STBOutFiler directly.

    best regards & thank you Marcelo


Seb


"Blair McGlashan" <blair@no spam object-arts.com> escribió en el mensaje
news:[hidden email]... to
> explicitly nil out the self slot by sending #receiver: to the block
object.
>
> Another related issue is that of blocks retaining a reference to their
last
> argument(s). This is because the arguments are implemented as slots in a
> shared MethodContext. A workaround for this problem is to assign nil to
the
> arguments before exit from the block.
>
> These issues with old-style blocks are "fixed" in D6 in that the blocks
are
> proper closures and only retain as much context as they absolutely need to
> be evaluated. In the case of sort blocks, these are usually completely
> "clean" (that is they reference only their arguments, and not any other
> variables, and they don't contain ^-returns), and D6 will treat these as
> shared literals.
>
> In D6 block arguments, and the majority of temporaries, are always stored
in
> stack slots. This means that the references from these variables are only
> live for the duration of the block evaluation. Assignment to block
arguments
> is no longer legal and will result in a compilation error.
>
> Regards
>
> Blair
>
>