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
>> situation(s).
>
>     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
> selection.
> 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.
> best
> Eliot

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)
in smalltalk.
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.

-- 
Best regards,
Igor Stasenko AKA sig.