RE: building an image

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

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