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?

 - 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/27972442/attachment.htm