slate gui slowness needs fixing before proceeding

[Brian Rice]

I didn't have this email account accessible at work today, so this  
reply has been delayed...

On Jun 14, 2006, at 8:12 AM, Timmy Douglas wrote:

> Brian Rice <water at tunes.org> writes:
>> On Jun 13, 2006, at 9:21 PM, Timmy Douglas wrote:
>>> 1. vm.c and vm.h is downloaded from the tunes site (why isn't it in
>>>    the darcs directory instead?). It is some sort of minimal slate
>>>    interpreter which uses <insert something about alpha vm boot
>>>    image?> and reads the special slate files:
>>>    src/mobius/vm/bootstrap.slate and blah and outputs another vm.c
>>>    file.
>>
>> vm.c and vm.h are only versioned in the alpha/ branch, and even then
>> they are dubious since the order of C functions generated from Pidgin
>> translation is somewhat non-deterministic, thereby raising the level
>> of noise in version diff's.
>
> Yeah, these looked autogenerated to me but I didn't know what they
> were coming from until I read the makefile. I guess I missed that part
> in the "Build Requirements" (maybe I was tempted to skim over it since
> it sort the title comes off as a system requirements section). My
> fault.



>> Did you not read what's in the INSTALL file? "Extending Slate" covers
>> the basics of this.
>
> "Extending Slate" points me to src/mobius/vm/post-bootstrap.slate and
> tells me how to extend or build a new VM. Since I would be more
> interested in knowing how the VM works or how it is built, I'd like to
> sort of have an overview on how 'make newboot' works rather than the
> commands I type in to generate a new image.

Okay, that's a good point. I'll put something together tonight.

>>> It'd be nice if you could go into more details with the files  
>>> used and
>>> what they do in a line of text if ever get time.
>>
>> Please ask specifically what the INSTALL file does not address.
>
> I don't know, maybe I'm approaching this the wrong way and I should
> grep for 'generate' in the mobius directory for something that
> specializes on VM definitons. I thought there would be something to
> tell me what actually generated the first vm.c that's in the alpha
> repository and then that src/mobius/vm/build.slate or whatever
> actually generates a vm.new.c/h file, which is compiled again.



> I don't think I would have guessed that from this:
>
> VM define: #new -> (VM Definition newNamed: 'vm.new') generate.
>
> since this is my first time looking at the bootstrapping level of a
> system I guess there were a lot of gaps that weren't already filled  
> by experience so maybe that's why I didn't think the docs had  
> everything.

Hm, well, no, it doesn't provide much information, but the #generate  
method is also in that file... anyway, you have to recurse to learn  
this stuff as it is.

Here's the rough summary:
The VM is built by constructing a definition expressed with object  
structure. The basics are outlined as VM Definition which lists the  
sources it's built from and then includes the primitive functions  
that are exposed as its interface (the primitives) to the image.  
*Unfortunately*, the structure of the objects used to generate the C  
sources is held elsewhere, basically by the Pidgin generator (src/ 
mobius/c/ generator.slate and cr.slate have most of it). But  
basically there are objects describing every type and function in the  
VM, which are held together in a module and processed as a whole to  
perform a little type-inference and flattening from methods to  
functions. The creation of this module from the reading of the source  
pidgin files (src/mobius/vm/*/*.slate) is the first phase, and the  
second is to process these to generate C sources.

The image is then constructed in terms of interfacing with this  
definition of the VM as a bunch of live Slate objects in the image.  
Image Definition describes what sources constitute the core image  
creation code, along with a pointer to the desired VM Definition and  
administrative details like endianness and filename. The VM and  
Images interface in terms of an array called the specialOops in the  
image and SpecialOopsArray in the VM. This tells the VM where the  
critical object pointers are that it needs for primitives, so that  
the VM and image link together at startup in order to run together.  
Image creation then consists of parsing and compiling the sources  
from the files listed into one huge bytecode method which is the sole  
non-special bit of content in the Slate core image. The image is then  
arranged to run this method when it is started. The method, of its  
own nature, when run will then perform all of the actions that the  
code in those Slate files would do... it's just frozen and replayed  
for that empty environment, to build it from scratch constructively.

The images that the bootstrap puts out are those core images, which  
is why the default "make" target runs the vm with the relevant image  
and then tells it to save itself at the end, so that the huge  
constructor method has already run and now you just have instant  
startup.

Whew - that's the bootstrap as-is (it has evolved quite a bit from a  
bunch of custom scripts - by no means should you consider any of the  
things I'm describing as desirable as conceptual end-goals). Okay, so  
how does that strike you? How / in what form would you like that  
related in the included documentation (or at least persisted on the  
wiki)?

>>> The readme has a lot of files in it that don't exist anymore.
>
> The readme mentions:
>
> src/mobius/bootstrap/ - Bootstrap code, for the future run-time
> builds.
>
> src/mop/ - Meta-object protocol.
>
> which don't exist in my repository. Sorry I guess 'a lot' was the
> wrong word here.

src/mop/ was removed since the contents didn't gel and form anything  
useful. The idea was to have slot meta-objects and so forth but we  
just hadn't found them compelling (or easy to implement, in the case  
of meta-level lookup overrides) yet.

src/mobius/bootstrap/ also existed but was wiped out since the  
contents were trivial and noisy.

Perhaps I'll note both of these as temporarily defunct or something.  
I'll patch it as soon as I decide about that. Thanks for mentioning  
these.

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060614/c8dd8c2b/PGP.pgp