On Mon, Aug 24, 2009 at 6:15 PM, Ronald Spengler <ron.spengler at gmail.com>wrote:

> We're bumping up against the homoiconicity of the system, aren't we? That
> code is really just a kind of data. Has anyone ever done a diff tool for
> whole images, not just source methods? It would be fantabulous if I didn't
> have to write an installer script for my package, instead having the
> necessary objects brought over directly.
> Seems like the mother of all problems is: moving things around that way
> between images of different formats. Would some future descendant of
> SystemTracer perhaps be of use?
>

Why is this such a mother of a problem?  In VW we used a single parcel
format that could represent compiled code that could be loaded into either a
32-bit or a 64-bit image even when the size of SmallInteger, the number of
tag bits, the existence or not of SmallDouble, the size of identify hashes,
the way class references are encoded in instances, etc all differed between
the 32-bit and 64-bit systems.


>  - Ron
>
>
> On Sun, Aug 23, 2009 at 9:14 PM, Colin Putney <cputney at wiresong.ca> wrote:
>
>>
>> On 19-Aug-09, at 5:45 PM, Jecel Assumpcao Jr wrote:
>>
>>  http://wiki.squeak.org/squeak/584
>>>
>>> The idea is to be more like the Etoys users which can load binary
>>> projects containing not only the code they need but also hand crafted
>>> objects which have no source (like a drawing, some nested Morphs or even
>>> some text). This is very simplistic compared to Spoon, and my proposal
>>> was even more simplistic. In particular, this doesn't handle the case
>>> where any changes to bytecodes or object format are needed.
>>>
>>
>> Interesting.
>>
>> I note, though, that the wiki page you mention doesn't actually say much
>> about development. It's mostly concerned with efficient ways of moving
>> objects between images. Reliably reconstructing part of one image in another
>> is certainly a crucial part of collaborative development, but it's not
>> everything.
>>
>> The other key feature of Monticello is merging. If you and I have the same
>> chunk in different image, and we make differing but compatible changes, how
>> can we create a chunk that contains both sets of changes? I submit that any
>> tool that can do that will have explicit knowledge of the semantics of
>> objects it's merging, whether Smalltalk code, Etoys projects or something
>> else.
>>
>> So the wonderful generality of the Chunky Images idea only gets you so
>> far, and you still need a tool like Monticello to actually create
>> collaboratively. In Monticello 2 I've tried to address this idea explicitly:
>> the core versioning engine is knows nothing about the semantics of the
>> objects it's versioning, but it does rely on pluggable domain models that
>> do.
>>
>> Colin
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090824/3bd5165a/attachment.htm