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

[Andreas Raab]

On 5/18/2010 5:58 PM, Igor Stasenko wrote:
> 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?

Of course not. You can always program yourself into a corner where 
there's no way out. It's a matter of the expected failure mode. When I 
use the term 'safety' I mean mostly referential integrity. In other 
words memory safety.

For example, the reason why I'm not in favor of advocating the use of 
the FFI instead of the use of plugins is that when using the FFI people 
do not understand what could go wrong because they don't understand the 
concepts of the underlying platform. However, when you write a plugin 
you're proving that at least you know how to use C and usually this 
means you know *something* about the related set of issues.

And of course, when the very same people who have no clue about C and 
memory management corrupt their heap by the use of the FFI you get these 
complaints about how 'unstable' the system is. How very ironic.

In any case, my definition of 'safety' is not the same you're implying 
above. It mostly relates to memory safety.

BTW, many of the sticky points you're mentioning could be fixed by 
having a 'panic' button for the VM that simply suspends all processes 
and fires up a single new process to listen on a port and take commands. 
SSH into the image and you can see what you can repair. And yet again, 
it's the VM that provides the way out here because your in-image 
handling of the panic button could already be compromised.

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

That's called a 'glue' or 'scripting' language. Python is having 
dramatic success with effectively just that.

Cheers,
   - Andreas