RE: VM images and working in the VM image

I'm talking about Cincom Smalltalk (VisualWorks specifically, but 
most of what I said applies to Squeak as well).  When I change class 
definitions, existing objects change shape as well - even as methods 
are running.  I've not worried about that, because it's not been an issue.

As to how I persist those changes, I do things like this:

1) Export the changes code from my test server as a Smalltalk file-out

2) Export the new versions of all the packages changed

3) Upload the patch and the new packages to the server

4) Put the new packages into the directory used when the image 
starts, and put the patch into the patch directory

5) Kick the server (via a web console) to load the patch (and then delete it)

I patch in place, and also make sure to have all the most current 
startup packages in place in case the server needs a restart.

I would also argue that most of the "high end" Java app servers you 
speak of could be done quite easily in Smalltalk.  We have plenty of 
customers with complex applications.


>(*) No argument on the dynamic nature of the image vs. the static nature of
>the Java app server (though, in theory, the app server doesn't need to go
>down just to change code, either--all that is handled through ClassLoaders
>in the JVM, which are far more dynamic than you might expect). This may be
>more complicated than what we can approach in this email, but... When you
>change the shape of objects in memory, though, how does the ST image handle
>that? Do existing objects receive the change? And what happens if methods
>are invoked in the middle of the reload?
>
>(BTW, you and I, I think we've had this discussion on the usefulness of the
>ST image before, over blogs--I'm not arguing against the idea, just trying
>to understand it better.)
>
>(*) You're referring to your Cincomm Smalltalk flavor, correct? VisualWorks?
>Not Strongtalk?
>
>(*) How do you persist those changes to the image so that if the machine
>crashes, the image doesn't lose all those changes? Do you periodically have
>to flush the image to disk? And is that transactional somehow?
>
>(*) Hopefully you'll also allow me to assert that running a blog engine
>isn't exactly the high-scale requirement environment that some of the Java
>(and .NET) app servers are asked to handle. :-) What I'd *really* love,
>though, in order to move this particular point out of the realm of the
>abstract, is to know *exactly* what the runtime footprint of your "app
>server image" takes up, so as to hopefully compare/contrast it against the
>runtime footprint of a Java app server stack. (I'd much rather argue facts
>than assertions, and numbers against "belief".)
>
>Heck, for that matter, I'm not trying to "argue" at all. Just learn. :-)
>
>Ted Neward
>Java, .NET, XML Services
>Consulting, Teaching, Speaking, Writing
>http://www.tedneward.com
>
> > -----Original Message-----
> > From: [email protected] [mailto:strongtalk-
> > [email protected]] On Behalf Of James Robertson
> > Sent: Saturday, May 12, 2007 7:19 PM
> > To: [email protected]
> > Subject: RE: VM images and working in the VM image
> >
> >
> > Oh?  My blog: http://www.cincomsmalltalk.com/blog
> >
> > runs on an image, as do all the others hosted there:
> >
> > http://www.cincomsmalltalk.com/userblogs
> >
> > Any arbitrary application server for Java you pick is going to chew
> > resources as well; claiming that the image is some kind of resource
> > hog is just silly.  Running a Smalltalk image w/o the GUI is fairly
> > easy to do (at least using the flavor I use) - and having the
> > compiler present allows me to add patches (including ones that change
> > the shape of objects in memory) as the image runs - I don't have to
> > play the "take it down, update, bring it up" game.
> >
> > To build my runtime I start with a base image, and start with a
> > command line like this:
> >
> > visual baseImage.im -filein startupScript.st - nogui
> >
> > Where startupScript.st has Smalltalk code that loads in the
> > components I need to run, and configures the system for runtime.
> >
> > >Case in point: ST's notion of the IDE-in-the-image is pretty lame when
> > >looking to deploy an image within a "headless" environment. Is there
> > another
> > >approach when trying to build a server? Surely when running Seaside, for
> > >example, I don't want or need the overhead of the IDE hanging around....
> > It
> > >might be useful in certain scenarios, but most of the time, it's just
> > going
> > >to be useless overhead....
> > >
> > >I recognize that it's probably impossible to summarize the ST philosophy
> > >down into a single email of reasonable proportions, and of course it's up
> > to
> > >Richard to go read more about the ST philosophy if he wants to "get" ST
> > in
> > >any reasonable sense. But it's not too much to ask, I don't think, to
> > answer
> > >in single-sentence form the specific issues being raised--plus, that way,
> > >it's in the archives for others to discover later when they come to ST
> > with
> > >their own questions.
> > >
> > >Ted Neward
> > >Java, .NET, XML Services
> > >Consulting, Teaching, Speaking, Writing
> > >http://www.tedneward.com
> > >
> > > > -----Original Message-----
> > > > From: [email protected] [mailto:strongtalk-
> > > > [email protected]] On Behalf Of tim Rowledge
> > > > Sent: Saturday, May 12, 2007 2:50 PM
> > > > To: [email protected]
> > > > Subject: Re: VM images and working in the VM image
> > > >
> > > >
> > > >
> > > > On 12-May-07, at 2:24 PM, 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
> > > > That imply isn't the way Smalltalk works Richard. It sounds as if you
> > > > would gain a lot by reading up on how Smalltalk works and how it is
> > > > very different to old ways of doing things.
> > > >
> > > > Try  Smalltalk Central (http://www.smalltalk-central.com/
> > > > showDocument.ssp?section=Articles&name=Documentation), http://
> > > > www.iam.unibe.ch/~ducasse/FreeBooks.html etc.
> > > >
> > > > Basically we just don't do dead code. As one wag put it "source code
> > > > in files? How quaint."
> > > >
> > > >
> > > > tim
> > > > --
> > > > tim Rowledge; [email protected]; http://www.rowledge.org/tim
> > > > There can never be a computer language in which you cannot write a
> > > > bad program.
> > > >
> > > >
> > > >
> > > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG Free Edition.
> > > > Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date:
> > 5/11/2007
> > > > 7:34 PM
> > > >
> > >
> > >No virus found in this outgoing message.
> > >Checked by AVG Free Edition.
> > >Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date: 5/11/2007
> > >7:34 PM
> > >
> > >
> > >
> > >
> > <Talk Small and Carry a Big Class Library>
> > James Robertson, Product Manager, Cincom Smalltalk
> > http://www.cincomsmalltalk.com/blog/blogView
> >
> >
> > >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date: 5/11/2007
> > 7:34 PM
> >
>
>No virus found in this outgoing message.
>Checked by AVG Free Edition.
>Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date: 5/11/2007
>7:34 PM
>
>
>
>
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView


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