Re: VM images and working in the VM image

Hi Stephane,

> I rebuild my image from scratch each time I start programming.

I also work rebuilding the image each time I start to work.
Working with objects are not related with snapshot mechanism
 and it is very powerfull to have both. The image based mechanism
 for people/situations that want/need to save the image,
 and a more modular approach for framework based work
 (and as a result of cristalization of domain models).

> We could have a Smalltalk (squeak on day) or I guess that GNU is
> doing that, that starts
> with a minikernel seed and load compiled code. There is nothing at
> the model level that prevents that.

In 1995 Visual Smalltalk has support for it and some tools
 to support layered integration of development based on
 "compiled behavior".
I has had implemented them for Smalltalk/V in 1993/94
 and really appreciate the value of modular construction
 from this point in time.
When you start to work this way it is difficult to feel confortable
 with image based development and also
 with source code based programming.

Starting from scratch is very interesting to be alerted when
 we forget to initialize something properly.
To be forced to initialize always before using objects is really
 too restrictive and distract when you really do not want to
 be distracted with implementation details. On the other hand,
 initializing one time (e.g. in an inspector) and never initialize
 again is the risk of working with images (make systems non
 portable, state dependent or ported at higer costs).
Rebuilding on each startime is the right place to "be surprised",
 because you are starting the work (early in the morning? :)
 and has an instructive effect that make people correct
 the way they are working (paying for the mistake but not
 been distracted when they are thinking in the system).

cheers,
Ale.



----- Original Message ----- 
From: "stephane ducasse" <[email protected]>
To: <[email protected]>
Sent: Sunday, May 13, 2007 7:20 AM
Subject: Re: VM images and working in the VM image


>
> from a model point of view, what you can do in java is the same in
> smalltalk.
> S# for example has a mini core (bytecode+ objects) and load package
> on the fly.
> Now in Smalltalk you can save your code in files and versionned them
> if you want.
>
> What you should know is that you have other mechanisms that help you:
> - in VW I used a DB backend
> in VW (because they have engineers you can load parcel = bytecode
> and serialized objects
> without compiling the code at load time
> - in Squeak I used monticello that version source files
>
> Normally these approaches are more adpated since they know that there
> are versioning
> Smalltalk code so the underluying metamodel is cleverer than mere
> text file.
>
> Now what I want to say is that the idea of an image = a cache of
> method and objects
> is good but it is not really a good engineering metaphor. It is cool
> and cosy (imagine I can
> send you my image on Mac and you can see exactly where my PC pointer
> is on the stack is, then you can proceed.....debug webserver on the
> fly while they are running) but usually
> I rebuild my image from scratch each time I start programming.
> We could have a Smalltalk (squeak on day) or I guess that GNU is
> doing that, that starts
> with a minikernel seed and load compiled code. There is nothing at
> the model level that prevents
> that.
>
> Stef
> On 12 mai 07, at 23:24, Richard wrote:
>
>>
>> Coming from a background of C++, Ruby and Java I'm used the idea that
>> you program in an IDE and then you output a Jar, or a bunch of shared
>> libraries and executables. This process involves selecting which
>> packages you want to use and it also involves people sorting their
>> software into packages and declairing package dependencies. It seems
>> to me (and I don't have much experience with smalltalk) that  one has
>> one big VM image containing the IDE and the program being developed,
>> but if I write a webserver for instance when I deploy the webserver in
>> production I don't want the IDE as part of it (probably I want to be
>> able to attach a debugger via a TCP connection, but that is another
>> issue).
>>
>> Does strongtalk support the notion of packages in a similar way to
>> Java? Can I write a package in strongtalk, declare its dependencies,
>> then create a VM image that just contains my software and its
>> dependencies (transitive closure obviously)?
>>
>> I also want to keep all my source code in files on the disk. That way
>> I can use existing source control systems. It must be easy to have the
>> VM (well some objects probably) watching the source files and reload
>> them if they change. That way at least one can operate even if one
>> doesn't yet have a GUI (e.g. the present situation with linux and
>> strongtalk). The file system is also a bit more trustworthy than a
>> running executable, e.g. if my power goes off then files are ok, but
>> the VM image is gone. Also source files normally don't get corrupted,
>> but I'm afraid that if the power goes off while I'm saving a VM image
>> it might get corrupted.
>>
>> I think its an advantage to support more than one GUI system because
>> not everyone wants the same thing (some people want a GUI system that
>> behaves like the common ones, some people want to try something
>> radiacally new). In the beginning lots of people can start making GUI
>> systems, but after a while those that are good become apparent and
>> more effort goes into them.
>>
>> It seems to me that package dependancies are as simple as nominating
>> one package for each class, and some number of dependent packages.
>> Then having the class loader disallow the loading of any class who's
>> dependent packages can't be located. It is quite usefull to make
>> packages into a tree, i.e. java.swing.controllers being a subpackage
>> of java.swing.
>>
>> Packages can do other things, like static initialization, but I don't
>> know of too many situations where one really needs static
>> initialization other than for factories which seems to be a less
>> important idiom in languages that support reflection.
>>
>> regards,
>>
>> Richard.
>>
>>
>> >
>
>
> > 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---