[Pharo-dev] Consequence of NBExternalStructure refactorings
siguctua at gmail.com
Fri Aug 9 12:04:47 EDT 2013
On 9 August 2013 17:49, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
> 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.
it is not ready yet because it is not ready. i will tag it when it will.
> On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> 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)
>> 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