[Vm-dev] Cog: A question about: setInterruptCheckChain()

[David T. Lewis]

On Thu, Sep 30, 2010 at 01:57:21AM -0700, Andreas Raab wrote:
> 
> On 9/30/2010 1:43 AM, Igor Stasenko wrote:
> >>But now you're complaining about the integration APIs (with which I 
> >>agree).
> >>But there is stuff we can do to make this easier, *much* easier. If you've
> >>ever looked at how Python deals with this stuff you'll get an idea about 
> >>how
> >>easy that can be - no slang, no VMMaker, no build files other than what is
> >>already in Visual Studio. In effect, we should be providing a squeak.h 
> >>and a
> >>squeak.lib and the primitives should look like this:
> >>
> >>#include<windows.h>
> >>#include<wincred.h>
> >>#include "squeak.h"
> >>
> >>/* Read a credential from the Windows credential store */
> >>OOP primitiveCredRead(VM *vm, OOP rcvr, OOP args) {
> >>        Credentials *cred;
> >>        char *target;
> >>
> >>        vm->parseArgs(1, "%s",&target);
> >>        if(!CredRead(targetName, CRED_TYPE_GENERIC, 0,&cred)) return
> >>vm->fail();
> >>        return vm->stringWithLength(cred->CredentialBlobSize+1,
> >>cred->CredentialBlob);
> >>}
> >>
> >>Voila, done.
> >>
> >
> >Yep. Been there , did that :)
> >I had implemented own automatic code generator which generated
> >bindings for my abandoned smalltalk interpreter.
> >I used SWIG C++ compiler by writing own plugin to it.
> >So, what is stopping us from either use SWIG, or write own C/C++
> >parser/compiler for automatic
> >generation of external library bindings?
> 
> Someone needs to do it :-)
> 
> >>>No objections here. Shit happens. And its really don't matters where:
> >>>either in language/FFI or in C. You still have to fix that.
> >>
> >>It's not so much that shit happens but rather that your sarcastic comment 
> >>is
> >>*completely* wrong and (I think) goes to show how little exposure to the
> >>resulting problems you (and pretty much everybody else arguing for that 
> >>kind
> >>of stuff) really have.
> >>
> >
> >Oh, please. I worked more than 2 years on single big C++ project, in
> >Visual Studio.
> >STL, templates, threads, 10 minutes of compilation time, incredibly
> >hard to move ahead,
> >incredibly hard to reproduce errors (since after 'fix' you were always
> >had to restart program and
> >repeat all steps which may possibly triggered bug). I am sick of C, really 
> >sick.
> >If it would be so easy to develop in C, then no one (including me)
> >would even look into smalltalk direction.
> 
> This isn't my claim. My claim is that for *platform integration tasks* C 
> is superior. Not for general software development. But for a plugin that 
> reads and writes the windows credential store, for a plugin that reads 
> and writes the Apple keychain, for a plugin that interfaces with 
> sockets, for a plugin that deals with platform windows, C/C++/C#/ObjC 
> are the better choices.

There's a certain amount of personal preference involved here, which is
a good thing IMHO. OSProcessPlugin, which is pure platform integration,
is written entirely in Slang, with some embedded #cCode: but no external
C sources. Why? Because I thought it was cool that it was possible to
do it in Smalltalk. If I had it to do over again, would I do it the same
way? Yes. Does that mean that this approach is better? No, it's just
my personal preference.

That said, I do think that there can be some unexpected benefits from
writing platform glue code in Smalltalk. I wrote MemoryAccess as a
Slang replacement for the low level C macros in the VM, and found to
my amazement that the performance of the Slang version was identical
to that of the cpp macros (on my system, YMMV). So I ended up thinking
that the macros are a performance enhancement in C that actually do
not improve performance, and that make the VM code harder to understand.
Of course, at the time the macros were done, they were very much needed
because the Slang inliner did not originally deliver this kind of
performance.

I like the SWIG idea a lot by the way.

$0.02

Dave