Re: building an image

Dave,

And getting the VM to run without the UI on Linux was indeed my plan;
get a basic headless mode up and running, that basically provides a
command line "shell" to the VM.

I'll wait for your "command line arg" work and move forward from there.

thanks for the response.
-- the other Dave

On 3/5/07, David Griswold <[email protected]> wrote:
>
>
> Hi,
>
> Sorry I've been off the list for a while.  I'll be more engaged going
> forward.
>
> Yes, your description looks pretty accurate.  As you said, the method that
> is the hook for starting the Smalltalk level code executing is
> ProcessorScheduler>>start.  That calls SystemInitializer class>>run, which
> runs all the non-scheduling specific startup code, including class
> initializers (class initializers don't run automatically right now, you
> have
> to invoke them explicitely some where.  Critical library initializers are
> called from SystemInitializer class>>runBaseClassInitializers.  Other
> non-core initializers are currently called from
> SystemInitializer>>runNonCriticalClassInitializers.  A better method is
> needed for organizing class initializers.)  If there are no command line
> arguments, the UI is started when SystemInitializer class>>run by forking
> [UI start], the processorscheduler then enters into it's main loop which
> then schedules and executes the [UI start] block.  Generally, each
> application runs in a separate process.
>
> As much code as possible is written in Smalltalk, which of course means
> the
> UI code is *entirely* written in Smalltalk, including all the
> platform-dependent code.  However, that doesn't mean the GUI is
> non-portable, since while the UI implementation contains lots of Win32
> specific code, device dependent code is factored out by class or category
> and the interface it presents to applications is designed to be fully
> portable, with device independent ways of doing rendering, event
> processing,
> etc.  So obviously the GUI isn't going to run out-of-the-box on
> non-Windows
> systems; there is a big project involved to port the implementation,
> however
> none of the applications or interfaces should have to be modified (that I
> know of).
>
> But given that porting the GUI is a big project that isn't going to happen
> anytime real soon, I think the focus should be on getting the VM running
> without the UI on Linux, since that would still be useful for a Squeak
> port
> etc.   To do that, remember that the GUI only starts if there are no
> command
> line arguments.  So we need to modify SystemInitializer
> class>>processArguments: with another option that takes a filename to
> file-in and execute, then we can test the VM reasonably without the GUI
> (as
> well as use it to run scripts). I'll set that command-line arg up.  But
> there is still a significant piece of work to port the VM code that
> automatically loads and invokes external library DLLs, since all Smalltalk
> I/O goes through that.  And then the basic non-GUI I/O code must be ported
> to call Linux libs (not hard, although a socket implementation is
> missing).
> At that point we would be able to run headless code that does basic file
> manipulation.
>
> As for rebuilding the image file from within Smalltalk, that doesn't work
> yet, partly because there is a single method in the system right now that
> currently causes the bytecode compiler to crash.  I will be looking into
> getting image bootstrapping working again, so that we can recompile and
> bootstrap the entire image, which would be an excellent first piece of
> code
> for putting in an automated test suite for the VM, since it could be done
> without needing the UI.  As part of that, I've been looking into the image
> format, and I'll post some info on that when I set up the wiki, which I
> will
> do "Real Soon Now".
>
> -Dave
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of oe
> > Sent: Monday, March 05, 2007 8:57 AM
> > To: Strongtalk-general
> > Subject: Re: building an image
> >
> >
> >
> > Hello,
> >
> > I'm still trying to figure out, like a high level model of the VM. The
> > available documentation doesn't help me much here, I have to say, and
> > it took some time to get into this. So not sure what you mean exactly
> > with
> >
> > > trying to sort out how the image gets built so I can track the
> > > entrypoint into the runtime environment and see what how the UI gets
> > > loaded.
> >
> > , but I'll try to explain briefly what I've found out about how the VM
> > starts into the GUI.
> >
> > - VM starts in shell.cpp, initialization (bootstrap.cpp, mainly
> > bootstrap::parse_file())
> > - in process.cpp: VMProcess::activate_system(). This is where things
> > get interesting (and difficult, at least for me ;). The VM process
> > tries to retrieve a 'Delta level Processor' (see comments there) from
> > the system dictionary, which was (supposedly) previously loaded from
> > the image by the bootstrap code. I guess that the OOPs (processOop
> > etc.) involved are actually C++ representations of Smalltalk classes/
> > objects stored in the image (if this makes sense). You can inspect the
> > Smalltalk code by opening Strongtalk, then Browse->All Classes-
> > >Processor(->ProcessorScheduler).
> > - then, the "initial process" is created (new DeltaProcess) to call
> > the "start" method of scheduler just created (a method written in
> > Smalltalk, see Strongtalk class browser: Class ProcessorScheduler-
> > >Instance side->restricted->start).
> > - the actual call to "start" originates in the delta process once it
> > is run (that is, control is transfered by the scheduler): process.cpp
> > DeltaProcess::launch_delta, then delta.cpp Delta::call, all the way
> > down to interpreter_asm.asm call_delta, where the actual call takes
> > place. So I assume this is the point where Smalltalk code takes over
> > and drives further initialization of the system and GUI.
> > - also, if you look at the Smalltalk classes, especially
> > ExternalProxy, External* and Win32, I believe that there is a lot of
> > platform specific code written in Smalltalk, using Windows DLL calls
> > to interface with the OS (hence all the dll stuff/primitives in the C+
> > + code)... just speculating, though!
> >
> > So, that's about my quick tour of the VM startup, hope it helps -- or
> > maybe I've just missed the point of your post?  I haven't even manage
> > to build a new image file from within the Strongtalk GUI, but it's
> > been a while.Some information about the image file format and its
> > contents would definitely be helpful; I have to look at this again
> > when time permits.
> >
> > Oliver
> >
> >
> >
>
> >
>


-- 
A man's greatest treasure is his wife, she is a gift from the Lord
- Proverbs 18:22

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