Re: VM images and working in the VM image

I agree :)
So people can have bth worlds advantage (image for saving when going  
for coffee breaks) and
rebuilding them from scratch for solid process.

Stef

>> 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
-~----------~----~----~----~------~----~------~--~---