[Vm-dev] Re: [Pharo-project] how to change the default size of
the Pharo host windows?
andreas.raab at gmx.de
Wed May 19 00:40:06 UTC 2010
On 5/18/2010 5:06 PM, Igor Stasenko wrote:
> As i already repeated , multiple times, my vision is that VM should be
> stupid and primitive as much as possible.
And I have often pointed out that I do not share that vision.
My idea of the VM is that it provides a safe abstraction layer in which
it is hard to break anything so I can experiment freely and without fear
of losing my valuable data. Since I'm not a language bigot, I don't mind
dropping into C for the weird stuff. It actually suits me fine as a
reminder that I'm entering unsafe grounds where I need to go slowly and
carefully because even the most superficial error will crash me beyond a
means of recovery. That's for example why I like JITs and why I like
stuff like context-to-stack mapping; it provides a safe ground where I'm
allowed to make mistakes without being unduly punished for a mere typo.
> 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.
There are ways of doing this properly. You can add the abstractions to
the VM; it's not that the VM is not accessible. Your snapshot primitive
is actually just such an abstraction - instead of reading and writing
'header bits' you are passing a set of options that the VM can interpret
in any way it sees fit. That is an abstraction which still keeps the
handling of the image file itself plainly in the VM - the VM can decide
(for example) to store such options on Android in a completely different
place than 'the image file'.
More information about the Vm-dev