[squeak-dev] binary development (was: 3.11 and the trunk)
siguctua at gmail.com
Thu Aug 20 01:56:49 UTC 2009
2009/8/20 Eliot Miranda <eliot.miranda at gmail.com>:
> Hi Igor,
> On Wed, Aug 19, 2009 at 6:00 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> 2009/8/20 Jecel Assumpcao Jr <jecel at merlintec.com>:
>> > Colin Putney wrote on Wed, 19 Aug 2009 14:25:21 -0700:
>> >> On 19-Aug-09, at 10:15 AM, Jecel Assumpcao Jr wrote:
>> >> > For example, I would far prefer to
>> >> > see Squeak move to a binary based development model (I would mention
>> >> > Projects and Etoys here) than the current source based things we are
>> >> > doing (trunk, bob or whatever).
>> >> Forgive me for seizing on a throw-away comment like this, but would
>> >> you mind expanding on this a bit? Are you saying you prefer something
>> >> spoonish, where CompiledMethods are passed directly from image to
>> >> image? Something else?
>> > Heh, I got asked about this on IRC as well. Though I had actually
>> > started to explain this a little in the original email, I ended up
>> > deleting it to keep on topic. With a new subject line I don't feel I
>> > have to worry about that. Some details about this (with a few drawings)
>> > can be found in the Chunky Squeak wiki page:
>> > 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.
>> The central question, which arising immediately is, what is the
>> credible way(s) to reproduce such artifacts?
>> When we having a source code, we could (re)compile it on a different
>> system. But what you propose to do with pure binary data, a soup of
>> objects, in respect that it is incredibly hard to understand, what
>> bits you need and what's not, in case if you need to do clean-up ,
>> refactor, rewrite and simply analyze what is happening.
>> This is what making a huge difference, for instance, between
>> applications with open source code and applications shipped in binary
>> form - you can only report bugs, but can't realy make any suggestions
>> about what happening.
>> I don't think that developers of Squeak should be victims of such
> it is possible to have your cake and eat it too. One can create a
> binary format that includes source and includes the meta-source for its
> creation. But including a binary representation allows much faster loading,
> loading without a
> compiler, and source hiding if one choses not to include the source.
> There are other advantages, such as not cluttering up the changes file when one loads a package In the VW parcel system, to which I added source management, we replaced the SourceFiles with a SourceFileManager whose job was to manage the sources and changes file and an arbitrary number of source files for parcels, the binary format. In
> the parcel file the source pointers of compiled methods are the positions of
> their source in the parcel source file. When one loads a parcel the
> SourceFileManager adds the file to its set of managed files and assigns an
> index for the source file. The parcle loader then swizzles all the source
> pointers so that they include the source file index along with the position.
> So accessing the source for a method loaded form a parcel accesses that
> parcel's source file. We used a floating-point like format for source
> pointers, where the exponent was the source file index, and the mantissa was
> the position in the file.
> We didn't create a single file format, having two separate files for binary
> and source, which is probably a mistake. A format with a short header,
> followed by source, followed by binary, followed by metasource, would be
> easier to manage than three separate files.
> We didn't include any metasource, but we did include pre-read, load and
> unload actions. I did a very bad job on version numbering and prerequisite
> That's not the whole story but enough to start answering your question. If
> there is a well-defined definition of the objects in a package and that
> definition is included in the package as metasource, then one can comprehend
> the binary package's contents by examining the metasource and can reproduce
> creating the package, provided that the tools are careful to impose
> ordering, etc.
I think you inevitably made wrong decisions, because you went this way
by allowing an
arbitrary binary data , held by package.
In such situations it is much more easier to make a mistakes.
But sure, one who's making no mistakes is one who doing nothing :)
Obviously one of the side of such problem is uniform object memory,
where each object could
reference any other object and limited only by a imagination of people.
There is no layers or any other means which could establish a certain
barriers (which we calling a modules)
It means, that once you integrated the parcel into image, and started
using it, you may have a hard times trying to unload it.
It is possible to develop an image as an artifact, which contains both
binary & sources , but such approach
having a drawbacks, which we, by the way, trying to overcome nowadays.
Practice shows that such approach is credible only
for a small group of individuals, but becomes a bottleneck if you
adopt such scheme for a wider community.
So, i think , that before entering this domain (allowing binary data),
first we should solve more basic problems of smalltalk & its design -
modularity, name spaces, layering & etc etc.. Only the we could return
to original question and solve it.
Igor Stasenko AKA sig.
More information about the Squeak-dev