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

Andreas Raab andreas.raab at gmx.de
Thu Sep 30 08:24:21 UTC 2010


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


More information about the Vm-dev mailing list