Re: VM images and working in the VM image

Thanks all for taking the time to answers my questions and provide the
pointers and links. It is much appreciated from my end. I'm presuming
that any who don't want to read the thread, can just decide not to
read it (sorry for the extra page load and the unfulfilled expectation
of some juicy conversation).

It's good to hear that some Smalltalk systems have notions of packages
(universes) and that there are ways of working that allow one to
source in, and source out and so interface with existing source
control systems. I'll have to lookup in-image mechanisms for source
control and see how it is that if you're working in your image and fix
a bug or add a feature, how I can pick up that change in my image.

One point about packages (only relevant to some of the replies to my
initial question): packages allow you make a statement, in this class
or method, that: when I say Widget, I mean GTK2.Widget not one of the
hundred or so other Widget classes defined in other packages.

  using GTK2, BLAS;
  x = Widget.new # if Widget is ambiguously defined maybe I want an
exception, maybe resolve by choosing the one in BLAS rather than the
one in GTK2.

It is also true that packages have versions and being able to run a
system that can includes two versions of a package and have stuff just
work would be very cool, but as I understand it, this is a problem at
least for Java, C++ and Ruby. Why would you want to do this? Because
someone made a backward incompatible change to Wisiwig and Superthing
hasn't been patched yet to use the new version of Wisiwig, but
Coolthing requires the latest version of Wisiwig. If Coolthing and
Superthing don't pass objects from Wisiwig back and forth probably
this would be ok.Sounds a bit risky though doesn't it?

One of the nice aspects of Ruby on Rails is that it watches for
changes to source files and reloads them if they change. This moves
one a little in the direction of smalltalk. It's better than having to
restart the entire program (because that can take more than a second),
but not as good as running directly in the VM I suppose. For example,
in the VM, while in development mode, when you load a webpage and so
invoke Rails (or perhaps Seaside) the IDE could load the action, and
view classes you just invoked and also have the object instances right
there ready for you to inspect on the off chance that you've got a
bug.

It also interesting to discover that a lot of the state of a VM (in
some ways of working) is in the objects not the class definitions. So
for example some of your application data, e.g. configuration, might
be captured in the current state of objects, so to pick up your
changes to configuration I would also need to synchronize object
instances, not just class definitions. I'm used to systems that have a
clear distinction between startup state and runtime state. I
understood that the discipline of starting afresh each morning with a
startup image (and presumably running regression tests) is the way to
make sure the distinction is properly enforced.

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