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

[Igor Stasenko]

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

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

That's not ironic. That's plain stupid.
If people using FFI, and don't realizing what is 'direct memory
access', and all consequences
of it, then you will simply waste your time arguing with them about
'safety', whatever meaning they putting in it.

But i doubt you'll find such people. The point is, that there always
should be a wrapping layer,
written either in form of plugin or using FFI , which provides such safety.
And i don't care, which language used to implement that - smalltalk or C.
In both you have a very same chances to do stupid things and crash your system.
Except that with FFI, you don't need to recompile plugin/VM each time
you fixed the bug.

> 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.
>
panic button won't help if you do
Array setFormat: 88888. or Object become: nil.

So, i'd rather focus on a such design, where direct manipulation with
critical parts
of environment is sufficiently guarded against fools, by using safety
wrappers or
multi-level capability-based mechanisms.

>> 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.
>
Yeah.. scripting language is cool, when you having a host application,
specialized in doing something good, and leaving a window of
flexibility by providing scripting frontend.
But VM is apparently wrong place for that.

If you would ask me, how one could use smalltalk for scripting , then
first thing, what we should do
is to change VM to be a dynamically loadable library, with nice and
consistent API.
And, obviously,  everything except interpreter should be separated from VM core.
There should be no windowing, events, networking and many other things
, which hardcoded by default
in current VM.
A host application should be able to easily provide own, in case of need.

> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.