<br><br><div class="gmail_quote">On Mon, Aug 24, 2009 at 6:15 PM, Ronald Spengler <span dir="ltr"><<a href="mailto:ron.spengler@gmail.com">ron.spengler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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. <div>
<br></div><div>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?</div></blockquote><div><br></div>
<div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div><div><br></div><div> - Ron<div><div></div><div class="h5"><br>
<br><div class="gmail_quote">On Sun, Aug 23, 2009 at 9:14 PM, Colin Putney <span dir="ltr"><<a href="mailto:cputney@wiresong.ca" target="_blank">cputney@wiresong.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 19-Aug-09, at 5:45 PM, Jecel Assumpcao Jr wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://wiki.squeak.org/squeak/584" target="_blank">http://wiki.squeak.org/squeak/584</a><br>
<br>
The idea is to be more like the Etoys users which can load binary<br>
projects containing not only the code they need but also hand crafted<br>
objects which have no source (like a drawing, some nested Morphs or even<br>
some text). This is very simplistic compared to Spoon, and my proposal<br>
was even more simplistic. In particular, this doesn't handle the case<br>
where any changes to bytecodes or object format are needed.<br>
</blockquote>
<br></div>
Interesting.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<font color="#888888">
<br>
Colin<br>
<br>
</font></blockquote></div><br></div></div></div>
<br><br>
<br></blockquote></div><br>