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

[Igor Stasenko]

On 19 May 2010 03:40, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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.
>

Image having a lot of places which require you to be very careful:
 - bitblt & canvas code
 - morphic event handling
 - compiler & debugger
 - processes, semaphores etc
 - ... many many other places

so, by following your logic, since its unsafe to alter the behavior in
these places, then they should be moved to C code?
A JIT is an exceptional example , mainly it is something, which you
can't do without low-level access to machinery.

What i don't like to happen is to see that eventually all smalltalk
code consists from lines like:

  result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz
andDontForgetAbout: zork andRideAPonyWith: that.


>> 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'.
>
Right.

> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.