RE: VM images and working in the VM image

>From: Richard <[email protected]>
>Reply-To: [email protected]
>To: Strongtalk-general <[email protected]>
>Subject: VM images and working in the VM image
>Date: Sat, 12 May 2007 14:24:08 -0700
>
>
>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.

Just because you are used to something doesn't mean it is the right way. :)

>This process involves selecting which
>packages you want to use and it also involves people sorting their
>software into packages and declairing package dependencies.

Yes, I did this in C, C++, Perl, Python, etc., etc., and it's always a lot 
of work.  Would be nice if it could be done programatically, no? :)

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

Now this point is more valid, which is why people have made solutions for 
it.  For example, in Dolphin smalltalk you declare a "project" and the 
system watches what classes/packages you are using, then when you are ready 
to deploy you can press a button and it generates an exe with only what is 
required, for publishing.  It can also detect if certain pieces of code are 
used by multiple projects and build DLL's from these.

http://www.object-arts.com/content/navigation/home.html

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

Strongtalk itself is pretty minimal at the moment, but having packages are 
pretty common in Smalltalk, afaik.  For example, in Squeak we use 
"Universes".  You define your package, what it expects to be in the image 
and you're all set.

>I also want to keep all my source code in files on the disk.

You could file them out.

>That way I can use existing source control systems.

IMO, Smalltalk's own source control system is the best way to manage this.  
It can be more advanced since it can completely understand what it is 
working with, in contrast to general 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.

This, indeed would probably be easy for you to write.  Though I suspect you 
would be about the only person who would use such a thing. :)  There is a 
lot of power in having Smalltalk be a "live" image [1], and I know I for one 
would not want to give that up.

[1] http://learningtotalk.blogspot.com/2006/10/game-engine-progress.html

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

This is actually wrong.  The fact is, most systems come with a normal file 
system (e.g. windows NTFS), so if you lose power while saving your Java text 
files you may not get it all.  I can't speak for all Smalltalks, but Squeak 
uses a journaling technique so that if you have an image crash, lose power 
or whatever you can use the in-image tools to recover your code.  You still 
have the exposure that the underlying file system didn't complete the write 
before power was lost, but you are certainly no worse off then the "cult of 
the dead" systems are.

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

And this is what is nice about Smalltalk.  Anyone can jump in and change as 
much of the system as they like for themselves.

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

Yes, you might read up on Package universes, which do this:

http://wiki.squeak.org/squeak/3785

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

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507


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