LPVOID and ExternalAddress (again)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

LPVOID and ExternalAddress (again)

Chris Uppal-3
I've been trying to get some external interfacing to work, and my head
is spinning.

<wistful>
What I'd like to see in Dolphin 6 is for the class comment of LPVOID and
ExternalAddress to be completely re-written.  In particular I'd like to
understand why ExternalAddress>>yourAddress doesn't do what I'd expect.
</wistful>

Given an external API that uses void* "opaque pointers", I'd like to express
those "pointers" as Custom Smalltalk objects (E.g. not as Integers), but I'm
having difficulty with it.  I'm sure I could do it if I took a while to calm
down, and then tried again, but I thought I'd ask how it's /supposed/ to work,
rather than suffer in silence.

Given an API like:

    void get(void **ptr_to_ptr);
    void use(void *ptr);
    void release(void *ptr);

where I'd write C code like:

    void *ptr = NULL;
    get(&ptr);        /* get a new "pointer" */
    use(ptr);         /* use it */
    release(ptr);    /* release it again */

I'd expect to be able to wrap the API with something vaguely like:

    someLib>>get: aSomething
        <stdcall void get void**).
    someLib>>use: aSomething
        <stdcall void use void*).
    someLib>>release: aSomething
        <stdcall void release void*).

And then use it like:

    ptr := new ExternalAddress.
    someLib default get: ptr yourAddress.
    someLib default release: ptr.

But, of course, that doesn't work.  I know I'll be able to /make/ it work if I
hack around for long enough (I've done precisely that before), but just for
once I'd like to do it the right way, and also to understand /why/ it's the
right way.

I may be asking for the Moon, but that's what I would like.

Please ?

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: LPVOID and ExternalAddress (again)

Bill Schwab
Chris,

> I've been trying to get some external interfacing to work, and my head
> is spinning.
>
> <wistful>
> What I'd like to see in Dolphin 6 is for the class comment of LPVOID and
> ExternalAddress to be completely re-written.  In particular I'd like to
> understand why ExternalAddress>>yourAddress doesn't do what I'd expect.
> </wistful>

My wish list for external interfacing includes a dirt simple mention of
which classes/methods copy and which ones attach to memory "in place".
In fairness, I recall some significant progress being made on that
front, if only in the archives.  When all is well, I have lots of time
to forget the details, so a quick refresher, whether it's an HTML table,
flow chart, painfully obvious class or method comments, etc., would be
welcome.


[snip]

> And then use it like:
>
>     ptr := new ExternalAddress.
>     someLib default get: ptr yourAddress.
>     someLib default release: ptr.
>
> But, of course, that doesn't work.  I know I'll be able to /make/ it work if I
> hack around for long enough (I've done precisely that before), but just for
> once I'd like to do it the right way, and also to understand /why/ it's the
> right way.

Have you read the class comment in ExternalLibrary?  It usually gives me
a big boost on which type to use when.  As far as hacking through the
details[*], I like to get everything ready to go and then save the
image, almost literally with the do-it text selected.  If anything goes
wrong, I exit w/o saving after some exploration in the debugger.

With that said, I think you will find that ptr w/o the #yourAddress will
do what you want w/ #get:.  Recall that Dolphin automatically passes
various critters by address.  It can be confusing at times, but in most
cases, I think it avoids more trouble than it causes.

Have a good one,

Bill

[*] I freely admit that I simply edit/crash/repeat until it works :(


--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: LPVOID and ExternalAddress (again)

Chris Uppal-3
Bill

> [snip]
> > And then use it like:
> >
> >     ptr := new ExternalAddress.
> >     someLib default get: ptr yourAddress.
> >     someLib default release: ptr.
> >
> > But, of course, that doesn't work.  I know I'll be able to /make/ it
> > work if I hack around for long enough (I've done precisely that
> > before), but just for once I'd like to do it the right way, and also to
> > understand /why/ it's the right way.
>
> Have you read the class comment in ExternalLibrary?  It usually gives me
> a big boost on which type to use when.

I had, but it was well worth a a re-read.  Thanks for the reminder.


> With that said, I think you will find that ptr w/o the #yourAddress will
> do what you want w/ #get:.  Recall that Dolphin automatically passes
> various critters by address.

As a follow-up: yes that works (but is highly counter-intuitive -- at least for
me).

I still don't understand ExternalAddress>>yourAddress, but at least my code is
now working without it.

(BTW, for anyone interested, it's a wrapper for the GNU/Aladdin Ghostscript
library.  I'm currently at the point where I can execute PostScript code and
read the generated graphics from Dolphin (at least for 16, 24, and 32-bit
data).  Now to turn that into a proper View....)

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: LPVOID and ExternalAddress (again)

Schwab,Wilhelm K
Chris,

> As a follow-up: yes that works (but is highly counter-intuitive -- at least for
> me).

Remember that Dolphin will pass by address for you, (almost) iff it is
appropriate to do so.   I have had a few weird cases of passing along an
address that didn't work w/o some care, but otherwise, it works well.


> (BTW, for anyone interested, it's a wrapper for the GNU/Aladdin Ghostscript
> library.  I'm currently at the point where I can execute PostScript code and
> read the generated graphics from Dolphin (at least for 16, 24, and 32-bit
> data).  Now to turn that into a proper View....)

It would be great to have an unencumbered way to display postscript!
Please keep us posted.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]