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

[Igor Stasenko]

On 30 September 2010 04:30, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> [Side note: Please don't quote entire posts if you're going to reply 2/3rds
> of the way down. I had to scroll three times through this post to even find
> what you replied to]
>
> On 9/29/2010 5:50 PM, Igor Stasenko wrote:
>>>
>>> 1) The "mechanics" of writing a plugin, i.e., slang and compilation. This
>>> is
>>> the part where the FFI would help, but so would better APIs for
>>> marshaling.
>>> While it's "cool" that one can run slang plugins in Squeak it is also
>>> completely and utterly *useless* when it comes to integrating platform
>>> specific stuff and having to deal with Slang, VMMaker and the awful build
>>> setups, and then -on top of that- the actual work you're trying to do is
>>> just a bit too much.
>>
>> And i am here looking for a way to make it less painful.
>> If one can make own stuff to work with OS via FFI,
>> why he needs to go into slang , VMMaker, cmake, gcc jungles?
>
> One word: Memory safety. Oh, that's two :-)
>
>> Probably, when he consider that FFI is good, but have to use more
>> safer solution,
>> then he free to go and implement plugin or change VM, whatever.
>> But for prototyping and fast implementation, FFI much better.
>
> 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.


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

> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.