Passing Arrays of Structs to NCI Subs
Chromatic
and from NCI? I have this signature:
extern DECLSPEC void SDLCALL SDL_UpdateRects
(SDL_Surface *screen, int numrects, SDL_Rect *rects);
That'd be *very* handy to expose.
(Yeah, Dan, I know you said you had something in mind.)
-- c
Leopold Toetsch
> What's the secret syntax for passing and retriving arrays of things to
> and from NCI? I have this signature:
There is no secret syntax:
,--[ docs/pmc/struct.pod ]-----------------------------------------
| Array Size
| The second initializer item, if set to a value greater
| then 1, defines the struct element to consist of an
| array of the given data type.
`------------------------------------------------------------------
*but* it's just not implemented for arrays of struct or struct* :)
Somewhere after unmanagedstruct.pmc:136 the C<count> has to be considered,
probably by incrementing C<p> by the needed size.
Can you provide some test code (s. t/pmc/nci.t and src/nci_test.c) for
signatures similar to the real:
> extern DECLSPEC void SDLCALL SDL_UpdateRects
> (SDL_Surface *screen, int numrects, SDL_Rect *rects);
leo
Chromatic
> Can you provide some test code (s. t/pmc/nci.t and src/nci_test.c) for
> signatures similar to the real:
> > extern DECLSPEC void SDLCALL SDL_UpdateRects
> > (SDL_Surface *screen, int numrects, SDL_Rect *rects);
No problem. Fair warning, though: nci_test doesn't build by default on
Linux PPC. I had to build it manually then copy it into
runtime/parrot/dynext/.
After commenting out the skipall() which doesn't like my platform, tests
5 and 27-29 fail. More importantly, the other tests pass.
After adding a signature for vpP to src/nci_call.txt and rebuilding,
only test 5 fails. That might be due to differences in the size of
shorts on this platform as compared to i386; just a guess. (The return
value is 128, while the test expects -128).
Anyhow, I've attached a new test which shows of more or less my idea for
what this should do. It may be horribly wrong, but it's wrong in a way
that has actual code, not just vague ideas.
On the other hand, I'm really *not* a C programmer.
-- c
Leopold Toetsch
> No problem. Fair warning, though: nci_test doesn't build by default on
> Linux PPC. I had to build it manually then copy it into
> runtime/parrot/dynext/.
That's the current procedure, yes. I don't know, if all platforms
support dynamic loading - probably not. So we need some config setting
for this.
> After adding a signature for vpP to src/nci_call.txt and rebuilding,
> only test 5 fails. That might be due to differences in the size of
> shorts on this platform as compared to i386; just a guess. (The return
> value is 128, while the test expects -128).
Signed vs unsigned char probably. I've changed the test bit.
> Anyhow, I've attached a new test which shows of more or less my idea for
> what this should do. It may be horribly wrong, but it's wrong in a way
> that has actual code, not just vague ideas.
Not very wrong, but ... Anyway the syntax is:
Px["Rect"; 0; "x"] # rect[0].x named access of "Rect"
Px[ 0 ; 2; "h"] # rect[2].h idx
Constructions differs too.
Please have a look at the test.
#29200 applied.
> On the other hand, I'm really *not* a C programmer.
> -- c
Thanks,
leo
Chromatic
> Not very wrong, but ... Anyway the syntax is:
>
> Px["Rect"; 0; "x"] # rect[0].x named access of "Rect"
> Px[ 0 ; 2; "h"] # rect[2].h idx
>
> Constructions differs too.
> Please have a look at the test.
Ahh, that makes sense after squinting the right way for a minute. I've
updated my SDL Parrot snapshot; the working code is now in
SDL::Surface::update_rects().
http://wgz.org/chromatic/parrot/sdl/
Building the array of rects is a little cumbersome, but now it's nicely
encapsulated where I don't have to think about it.
Thanks, Leo!
-- c