[Pharo-dev] Consequence of NBExternalStructure refactorings

Stéphane Ducasse stephane.ducasse at inria.fr
Fri Aug 9 11:49:55 EDT 2013

well if the bug entry is not tag as ready to include the chance to get it loaded is really low.
If people do not pay attention to basics like that….We will not make progress.


On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> Hello,
> lately we changed the object format of subject class from variableByte
> to normal one.
> All projects which using NBExternalStructure can meet certain problems with it,
> and first which comes is that it may load code cleanly but in fact
> result in bogus
> variable subclasses of NBExternalStructure , while it can't because
> superclass has instance variable.
> (i suspecting classbuilder bug, but need to verify first).
> To address that, you need to manually go over all subclasses and double-check.
> Another thing: since now instances NBExternalStructure can also point
> to external memory,
> special care should be taken for #copying.
> Sending #copy to instance which uses external memory, will create a
> copy on object memory
> (and copy all data from external memory into it). This is same
> behavior as in NBExternalArray.
> - there is a bugs in #initialize and #postCopy (fixed but not intergated yet)
> https://pharo.fogbugz.com/default.asp?11395#83020
> will do that in nearest time.
> also note, that in callouts, you cannot pass an instance of
> NBExternalStructure anymore
> to function, which uses raw pointer (like void*) anymore.
> For passing a pointer to structure data for callouts, use
> myStructure address
> idiom (or use right struct type, which is preferable).
> --
> Best regards,
> Igor Stasenko.

More information about the Pharo-dev mailing list