Cog: A question about: setInterruptCheckChain()

 
Anything I can say on this topic is that it works well
to move more and more stuff moved from the VM to the image
and once you are used to it you will see that writing
external DLL's/plugins is cumbersome and only required
in special cases.

Writing a plugin doesnt mean you have more memory security
since it can have a bug too. Also look at the long development
cycle using C/C++ and the need to set up the tools correctly.

Yes, I know there is Smalltalk/X where you can write C directly
in the method body - but I still think Smalltalk has more power
here.

And it works well to do most stuff in Smalltalk itself:

Look at Smalltalk/MT - you can easily call API functions
in Smalltalk style:

  WINAPI MessageBox: 0 with: szText with: szTitle with: 0.

Here is an example method and since it is directly in
Smalltalk(MT) it is easily changeable and debuggable:


formatError: uError
        "
        Formats an error string, given the error code.
        Parameters:
                uError A system error code
        Return Value:
                A String with an error description.
        "
        | count pBuffer answer|
        pBuffer := LONG localNew.
        count := WINAPI FormatMessage: FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER
                with: NULL " ignored "
                with: uError
                with: NULL " language identifier "
                with: pBuffer basicAddress
                with: 1 " minimum number of characters "
                with: NULL.
        count == 0 ifTrue: [
                _DEBUG_USER == TRUE ifTrue: [
                        (WINAPI GetLastError) ~= uError ifTrue: [
                                ^self formatLastError
                        ].
                ].
                ^String wsprintf: 'System Error 0x%x' with: uError
        ].
        answer := String fromAddress: pBuffer.
        WINAPI LocalFree: pBuffer.
        ^answer

Smalltalk MT also provides the ability to expose a method/block as
callback to external code - just put it in a special "callback" method
category.

In Smallscript/S# it was even more easier to do since David
Simmons allowed you to mix syntax styles and import libs
into namespaces:

   User32::RegisterWindowMessage('WM_ATLGETCONTROL').

Also see http://double.co.nz/smallscript/unofficialfaq.htm   

With an easy to use FFI/Callback mechanism Smalltalkers would be
able to integrate more with the platform. I think this is one
of the major problems for acceptance of Smalltalk. Where is
Squeak's COM binding, interfacing with the window system, ...

Currently only a few of us really integrate with the outside world
because they know how to write plugins...
It is just to cumbersome how it is today!

I agree with others here: we have the power and tools in Smalltalk
and should move more and more stuff to the image.
Make it run, make it right and then make it fast (and only in the
worst case with a custom plugin written in C).

Bye
T.

--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

On 01.10.2010, at 09:50, Torsten Bergmann wrote:

We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet.

What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism.

Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us.

Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so.

There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.

- Bert -