[Vm-dev] Re: [Pharo-project] how to change the default size of
the Pharo host windows?
andreas.raab at gmx.de
Wed May 19 01:38:55 UTC 2010
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.
More information about the Vm-dev