[Vm-dev] Re: [Pharo-project] how to change the default size of the Pharo host windows?

[Igor Stasenko]

On 19 May 2010 00:31, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> On 5/18/2010 1:36 PM, Igor Stasenko wrote:
>>
>> With such excuse, were ending up with a hacky shell scripts - an
>> ultimately afwul way to access
>> these attributes. It should be easier :)
>>
>> Its been always easy to make a mess:
>> Array setFormat: 88888.
>> Array new.
>> bye-bye vm&  image.
>>
>> Just give developers freedom, and then it is their own responsibility
>> to not make mess out of it, not yours.
>
> This isn't about "making a mess", it's about responsibilities. Currently,
> the VM and only the VM is responsible for handling the image file. This has
> several advantages because it allows some rather unsual 'file handling' on
> some platforms like Android (where there's not even an image file per se).
> Contrary to which, computing the class format is something that is within
> the responsibility of the image and not the VM.
>
> Of course, that could be changed - we could have some 'self-writing' and
> even 'self-reading' image code (the latter is a bit tricky, but not too much
> actually) that relieves the VM from having to ever read or write an image
> file, and that would be fine. But the point here is that the current
> distribution of responsibilities is such that the VM owns that part and it's
> got absolutely nothing to do with 'developers freedom' (you can after all
> change the VM!).
>

The problem, as i see it, that VM needs a set of startup options,
either for bootstrapping
interpreter's state or its modules, like display , network etc.
So as VM evolves and develops, you may require some new options. And
once you need that,
a question arises: where you should put that, and who is responsible
for initializing them
etc etc.. so you adding a bunch of C code in addition to existing bloat.

As i already repeated , multiple times, my vision is that VM should be
stupid and primitive as much as possible.
Whenever some operation requires some non-trivial logics, this should
belong to a language side.
In this way, i verifying all my ideas concerning changes to VM against
this rule of thumb.
If it doesn't pass that rule, then i doing things wrong.

My point, that we should put these responsibilities up to language
side: whether use display or not,
what modules to load or not, what initial display size should be , etc etc.
Then you having all levers of control at language side, and VM is
basically serving your requests,
unlike the current situation, when you often finding out, that there
is no way how you could
tell VM to use different option(s) , except from passing arguments
from command line or
altering an image file using hacky scripts.

So, my point is to keep a bare minimum options in image header,
while rest should use a uniform API, easy to use at both VM and language side.
Then adding an extra option won't cause you much pain.

Once you having an access to image file (or a bulk memory region),
technically, there is no
problem, where these options located, once you have a standartized way
how to extract them.

Saving an image with new set of options/header is merery a question of
providing an additional argument to primitive,
as simple as
self snapshotPrimitive: options
instead of
self snapshotPrimitive

I'm not saying that the above is best approach. But as i said, the
better is one which makes VM less clever and more stupid,
leaving the language side to decide what to do and when.

> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.