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

[Igor Stasenko]

On 30 September 2010 11:24, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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.
>

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?


>>>> <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.
>

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.


> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.