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

[Andreas Raab]

On 5/18/2010 7:57 PM, Igor Stasenko wrote:
> P.S.
> by any means, if we want squeak to serve as a tool for professionals,
> lets grow up and make VM for professionals, where they would be easily
> able to do things, without much fuss.
> But if we treat an interpreted language as a kinder-garden for childs, where
> they can do whatever they want with their toys, without nuking a planet,
> then they'll never grow up, because being grown up means taking
> responsibility for own actions,
> and no parental control, who could save you from your own mistakes and
> buy you a new toy.

Can we please disagree without this silly polemic?

Cheers,
   - Andreas

> On 19 May 2010 05:41, Igor Stasenko<siguctua at gmail.com>  wrote:
>> 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.
>>
>
>
>