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

[Nicolas Cellier]

2010/9/30 Andreas Raab <andreas.raab at gmx.de>:
>
> On 9/29/2010 6:48 PM, Igor Stasenko wrote:
>>
>> On 30 September 2010 04:30, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>>
>>> See, in my experience that claim is simply wrong. How can you say that
>>> (for
>>> example) a little test program like the one that I just wrote to
>>> experiment
>>> with a Windows function would be faster to write using the FFI?
>>>
>>> ------------------------------ CredTest.cpp ----------------------------
>>>
>>> // CredTest.cpp : Defines the entry point for the console application.
>>> //
>>>
>>> #include "stdafx.h"
>>> #include<Windows.h>
>>> #include<wincred.h>
>>>
>>> LPTSTR readCredential(LPTSTR targetName) {
>>>        CREDENTIAL *cred;
>>>
>>>        if(CredRead(targetName, CRED_TYPE_GENERIC, 0,&cred)) {
>>>                LPTSTR result = (LPTSTR)
>>> calloc(cred->CredentialBlobSize+1,
>>> sizeof(TCHAR));
>>>                memcpy(result, cred->CredentialBlob,
>>> cred->CredentialBlobSize);
>>>                return result;
>>>        }
>>>        printf("CredRead failed: %d\n", GetLastError());
>>>        return NULL;
>>> }
>>>
>>> int _tmain(int argc, _TCHAR* argv[])
>>> {
>>>        LPTSTR credential = readCredential(L"TERMSRV/devmsapps01");
>>>        printf("Credential: %s\n", credential);
>>>        return 0;
>>> }
>>> ----------------------------------------------------------------------
>>>
>>> You can imagine that it took me some ten minutes or so (incl. firing up
>>> Visual Studio, creating a new project etc) to write this. Now do that in
>>> Squeak and keep in mind how much of your time you're wasting in the
>>> overhead
>>> of declaring the types, functions, defines. That's why I'm saying that
>>> unless you can get the equivalent of #include<windows.h>  you're not even
>>> in
>>> the same ballpark.
>>
>> Wait, in the above you forgot to show me the glue code which exposing
>> this function
>> via some primitive. And you forgot to write the list of steps (in
>> addition to opening Visual studio),
>> how you rebuilding VM using VMMaker , compiling and linking, and
>> finally deploying VM with new plugin,
>> and then telling others that they can download new version of VM, so
>> they could try your new stuff.
>> Now i doubt if you do that, it will take ten minutes or so.
>
> 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.
>
>>>> <sarcasm>
>>>> Why Croquet using FFI for OpenGL binding, why not writing a plugin? It
>>>> would be much more 'stable'
>>>> and 'robust' and secure.
>>>> </sarcasm>
>>>
>>> Only one reason: The poor integration APIs. I couldn't figure out how to
>>> generate proper plugin glue (and later I had lost the source for
>>> generating
>>> this stufF). And we *paid* for it. Weeks and weeks of obscure crash
>>> reports
>>> that we couldn't figure out until *finally* we realized that when using
>>> client state operations a GC may occur if the rendering is interrupted
>>> "just
>>> so". We fixed this by (guess what) moving these operations into a plugin.
>>
>> 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.
>
> Cheers,
>  - Andreas
>

Agree with some of your arguments, but certainly not the last one: you
can't presume of everybody else experience.

>From my personnal experience, in the restricted case of simple types
and no #include hell, my productivity did boost in VW with DLLCC
compared to writing user primitives. Simply because I didn't have to
deal with any C code at all...
This may vary with applications for sure.

Nicolas