<br><br><div class="gmail_quote">On Tue, Aug 25, 2009 at 12:35 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">2009/8/25 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
><br>
><br>
> On Tue, Aug 25, 2009 at 3:57 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
>><br>
>> 2009/8/25 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
>> ><br>
>> ><br>
>> > On Wed, Aug 19, 2009 at 6:56 PM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> 2009/8/20 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
>> >> > Hi Igor,<br>
>> >> ><br>
>> >> > On Wed, Aug 19, 2009 at 6:00 PM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> 2009/8/20 Jecel Assumpcao Jr <<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>>:<br>
>> >> >> > Colin Putney wrote on Wed, 19 Aug 2009 14:25:21 -0700:<br>
>> >> >> >> On 19-Aug-09, at 10:15 AM, Jecel Assumpcao Jr wrote:<br>
>> >> >> >><br>
>> >> >> >> > For example, I would far prefer to<br>
>> >> >> >> > see Squeak move to a binary based development model (I would<br>
>> >> >> >> > mention<br>
>> >> >> >> > Projects and Etoys here) than the current source based things<br>
>> >> >> >> > we<br>
>> >> >> >> > are<br>
>> >> >> >> > doing (trunk, bob or whatever).<br>
>> >> >> >><br>
>> >> >> >> Forgive me for seizing on a throw-away comment like this, but<br>
>> >> >> >> would<br>
>> >> >> >> you mind expanding on this a bit? Are you saying you prefer<br>
>> >> >> >> something<br>
>> >> >> >> spoonish, where CompiledMethods are passed directly from image<br>
>> >> >> >> to<br>
>> >> >> >> image? Something else?<br>
>> >> >> ><br>
>> >> >> > Heh, I got asked about this on IRC as well. Though I had actually<br>
>> >> >> > started to explain this a little in the original email, I ended up<br>
>> >> >> > deleting it to keep on topic. With a new subject line I don't feel<br>
>> >> >> > I<br>
>> >> >> > have to worry about that. Some details about this (with a few<br>
>> >> >> > drawings)<br>
>> >> >> > can be found in the Chunky Squeak wiki page:<br>
>> >> >> ><br>
>> >> >> > <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<br>
>> >> >> > crafted<br>
>> >> >> > objects which have no source (like a drawing, some nested Morphs<br>
>> >> >> > or<br>
>> >> >> > even<br>
>> >> >> > some text). This is very simplistic compared to Spoon, and my<br>
>> >> >> > proposal<br>
>> >> >> > was even more simplistic. In particular, this doesn't handle the<br>
>> >> >> > case<br>
>> >> >> > where any changes to bytecodes or object format are needed.<br>
>> >> >> ><br>
>> >> >><br>
>> >> >> The central question, which arising immediately is, what is the<br>
>> >> >> credible way(s) to reproduce such artifacts?<br>
>> >> >> When we having a source code, we could (re)compile it on a different<br>
>> >> >> system. But what you propose to do with pure binary data, a soup of<br>
>> >> >> objects, in respect that it is incredibly hard to understand, what<br>
>> >> >> bits you need and what's not, in case if you need to do clean-up ,<br>
>> >> >> refactor, rewrite and simply analyze what is happening.<br>
>> >> >> This is what making a huge difference, for instance, between<br>
>> >> >> applications with open source code and applications shipped in<br>
>> >> >> binary<br>
>> >> >> form - you can only report bugs, but can't realy make any<br>
>> >> >> suggestions<br>
>> >> >> about what happening.<br>
>> >> >> I don't think that developers of Squeak should be victims of such<br>
>> >> >> situation(s).<br>
>> >> ><br>
>> >> > it is possible to have your cake and eat it too. One can create<br>
>> >> > a<br>
>> >> > binary format that includes source and includes the meta-source for<br>
>> >> > its<br>
>> >> > creation. But including a binary representation allows much faster<br>
>> >> > loading,<br>
>> >> > loading without a<br>
>> >> > compiler, and source hiding if one choses not to include the source.<br>
>> >> ><br>
>> >> ><br>
>> >> > 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<br>
>> >> > the parcel file the source pointers of compiled methods are the<br>
>> >> > positions of<br>
>> >> > their source in the parcel source file. When one loads a parcel the<br>
>> >> > SourceFileManager adds the file to its set of managed files and<br>
>> >> > assigns<br>
>> >> > an<br>
>> >> > index for the source file. The parcle loader then swizzles all the<br>
>> >> > source<br>
>> >> > pointers so that they include the source file index along with the<br>
>> >> > position.<br>
>> >> > So accessing the source for a method loaded form a parcel accesses<br>
>> >> > that<br>
>> >> > parcel's source file. We used a floating-point like format for<br>
>> >> > source<br>
>> >> > pointers, where the exponent was the source file index, and the<br>
>> >> > mantissa<br>
>> >> > was<br>
>> >> > the position in the file.<br>
>> >> > We didn't create a single file format, having two separate files for<br>
>> >> > binary<br>
>> >> > and source, which is probably a mistake. A format with a short<br>
>> >> > header,<br>
>> >> > followed by source, followed by binary, followed by metasource, would<br>
>> >> > be<br>
>> >> > easier to manage than three separate files.<br>
>> >> > We didn't include any metasource, but we did include pre-read, load<br>
>> >> > and<br>
>> >> > unload actions. I did a very bad job on version numbering and<br>
>> >> > prerequisite<br>
>> >> > selection.<br>
>> >> > That's not the whole story but enough to start answering your<br>
>> >> > question.<br>
>> >> > If<br>
>> >> > there is a well-defined definition of the objects in a package and<br>
>> >> > that<br>
>> >> > definition is included in the package as metasource, then one can<br>
>> >> > comprehend<br>
>> >> > the binary package's contents by examining the metasource and can<br>
>> >> > reproduce<br>
>> >> > creating the package, provided that the tools are careful to impose<br>
>> >> > ordering, etc.<br>
>> >> > best<br>
>> >> > Eliot<br>
>> >><br>
>> >> I think you inevitably made wrong decisions, because you went this way<br>
>> >> by allowing an<br>
>> >> arbitrary binary data , held by package.<br>
>> >> In such situations it is much more easier to make a mistakes.<br>
>> >> But sure, one who's making no mistakes is one who doing nothing :)<br>
>> ><br>
>> > We didn't disallow representation of arbitrary data but we also didn't<br>
>> > support it. The only thing the Parcel system supports (as in the tool<br>
>> > set,<br>
>> > rather than what one can extend the framework to do in specific<br>
>> > circumstances) is to represent code, which it does very well.<br>
>> > What are these mistakes? Can you be specific? I think the parcel<br>
>> > system<br>
>> > has been a major success. VW is now deployed as a system of components,<br>
>> > the<br>
>> > base image and a much larger suite of parcels. Parcels are not tied to<br>
>> > a<br>
>> > particular version or implementation and yet are still fast to publish<br>
>> > and<br>
>> > load. What's not to like?<br>
>><br>
>> I referred mainly to your own statements about mistake(s).<br>
><br>
> Ah, ok, Sorry :)<br>
><br>
>><br>
>> I don't know about parcels so much to tell exactly where is the flaws.<br>
>> I'm still wondering, how you could unload a parcel if its not longer<br>
>> needed, but<br>
>> there are still object(s) which used/created by parcel sitting in image.<br>
><br>
> Smalltalk has this problem with or without binary loading; they're called<br>
> obsolete classes :) However, the problem of knowing what to remove when the<br>
> user says "unload" means that a loaded parcel requires a data structure that<br>
> names the classes and methods it loaded. In addition we maintain overrides,<br>
> the older versions of methods and class definitions, in a stack, so that<br>
> these can be restored when unloading a parcel. I made lots of mistakes here<br>
> (not allowing the tools to publish a parcel that has code overridden by<br>
> others, not integrating source management and browsing queries with<br>
> overridden code, not compressing the changes correctly with overridden code,<br>
> etc, etc). Tests would have helped :/<br>
> VW did (does?) test for open instances of applications when we unload a<br>
> parcel so that if the parcel contains a subclass(s) of ApplicationModel<br>
> (VW's top-level GUI app class) all open applications are tested to see if<br>
> they contain instances of the class(es) and a warning is issued.<br>
>><br>
>> A basic use case is: developer needs some specific tool (like UI<br>
>> design tool) when he working<br>
>> on application. But at the moment when he ships the application, it is<br>
>> no longer needed.<br>
><br>
> Right. I don't know of an automatic solution, but a good convention is to<br>
> split all packages into a development and deployment pair where<br>
> the deployment half is a prerequisite of the development half. Sticking to<br>
> the convention and using good names makes it easier to remember to remove<br>
> deevelopment components and to guess which parts of someone else's<br>
> components are development only.<br>
<br>
</div></div>Yes, and this is what i really missing in smalltalk-80 based<br>
environments: distinction between development<br>
and deployment modes & models.<br>
It would be cool to have some basic things to behave different when in<br>
deployed mode (like preventing access & data overrides).<br>
The main problem in open system (such as smalltalk object memory) is<br>
that when something goes wrong, often you<br>
having two choices: reboot the system or debug and fix the problem in<br>
a living environment.<br>
Often, none of the choices is acceptable, because if we are talking<br>
about end-user application, we don't expect that<br>
user is able to debug & fix the issue. As well as rebooting an image<br>
means loss of data and/or interruption of serving other jobs.</blockquote><div><br></div><div>Yes, I agree. One of the things the headless support in VW allows which is quite nice is taking a shapshot which can then be restarted in a headless mode for debugging. This can easily be mailed or ftp'ed back for analysis.</div>
<div><br></div><div>Not quite the same, but very neat: The other day at Qwaq Craig Latta had a VM crash while running in a Parallels Linux VM under gdb. He was able to give me a copy of the VM snapshot at the point where gdb stopped the process, giving me the opportunity to debug the live app at my leisure. A cool idea.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
But, if system modelled in modular layers , like kernel -> services -><br>
interfaces -> working set, then things<br>
would be much easier to handle.</blockquote><div><br></div><div>Yes, yes, yes!! The system should be like an onion where each layer of the onion is a set of interlocking techtonic plates of modules of functionality.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div class="im"><br>
> I added a bulk instancesOf primitive that answered all instances of an Array<br>
> of classes that my colleague Steve Dahl wanted to use in instance migration<br>
> on class redefinition. This could be used to look for all instances of the<br>
> classes defined by a parcel prior to unload. Do a GC, collect all instaces<br>
> of classes defined (rather than redefined) by a parcel and warn if non-empty<br>
> (if in a dev image).<br>
<br>
</div>I think that independent tiny layers (isles/vats) is the future system<br>
organization in smalltalk-like VMs.<br>
First, it gives the strong answer to question, what belongs to what.<br>
There is no possibility to reference a foreign object<br>
other than by far ref. You can count/enumerate them easily, and this<br>
approach also makes possible to run code in vats concurrently.<br>
The problem here is how to handle the shared behavior, like Arrays,<br>
Collections etc in order to avoid duplication. Since in smalltalk<br>
everything is objects, and so methods & classes too, they can belong<br>
only to a single island/vat, and therefore , only owning island can<br>
manipulate with it. This creates a major bottleneck in effective<br>
implementation of concurrently (and independently) running the code.<br>
Trade space for speed? Allow each island to have own Array class with<br>
own implementation?<br>
This question remains open for me.</blockquote><div><br></div><div>Yes, this is a cool radical idea that I haven't got my head around yet. I need to think about this at length. The obvious approach to the duplication is copy-on-write where any modifications to the root Array class get propagated to the copies, assuming there is some hierarchical control organization. I think this approach is taken in Alex's worlds where modifications to a parent world are seen my children. But then the merge problem rears its head when trying to propagate modifications to a child that has made its own local modifications in the same region.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div class="im"><br>
>><br>
>> >> Obviously one of the side of such problem is uniform object memory,<br>
>> >> where each object could<br>
>> >> reference any other object and limited only by a imagination of people.<br>
>> >> There is no layers or any other means which could establish a certain<br>
>> >> barriers (which we calling a modules)<br>
>> >> in smalltalk.<br>
>> >> It means, that once you integrated the parcel into image, and started<br>
>> >> using it, you may have a hard times trying to unload it.<br>
>> >> It is possible to develop an image as an artifact, which contains both<br>
>> >> binary & sources , but such approach<br>
>> >> having a drawbacks, which we, by the way, trying to overcome nowadays.<br>
>> >> Practice shows that such approach is credible only<br>
>> >> for a small group of individuals, but becomes a bottleneck if you<br>
>> >> adopt such scheme for a wider community.<br>
>> >><br>
>> >> So, i think , that before entering this domain (allowing binary data),<br>
>> >> first we should solve more basic problems of smalltalk & its design -<br>
>> >> modularity, name spaces, layering & etc etc.. Only the we could return<br>
>> >> to original question and solve it.<br>
>> >><br>
>> >> --<br>
>> >> Best regards,<br>
>> >> Igor Stasenko AKA sig.<br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Best regards,<br>
>> Igor Stasenko AKA sig.<br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
</div>--<br>
<div><div></div><div class="h5">Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>