Re: VM images and working in the VM image

>
> (*) 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?

Have a look in the code. Each time you add an instance variable to a  
class, its instances
are migrated. The system is based on that. All the time.....all the  
time. This is a living system.
BTW CLOS is doing exactly the same.

> Do existing objects receive the change? And what happens if methods
> are invoked in the middle of the reload?

you have to pay attention. IN VW you have a transaction mechanism, in  
gemstone objects
are transient (but I never programmed with it).
>
> (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.)

ask the seasiders. They debug their image with their clients running  
the app
for certain bugs,

> (*) 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?

You can version to your external file systems/package without problem.

> (*) 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. :-)

Well...... running JPMorgan bank data or AMD 64 bit production or 20%  
of the world container
shipping flow should be enough!


> 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. :-)

So take VW7.5 and give a try, you can try Dolphin (this is also  
excellent on PC).
Squeak is wilder :)

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


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