[Vm-dev] Re: [Pharo-project] how to change the default size of
the Pharo host windows?
siguctua at gmail.com
Wed May 19 02:57:30 UTC 2010
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.
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
>>>> 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
>>>> 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.
> 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.
>> - Andreas
> Best regards,
> Igor Stasenko AKA sig.
Igor Stasenko AKA sig.
More information about the Vm-dev