T and L parameter types for NCI

[Dan Sugalski]

I just went, after ages, and sync'd up with a current parrot for my
work project. Fixing things to work with the changes has been...
interesting.

The big hang up has been the removal of the T and L parameter types
for NCI calls. T was a string pointer array and L was a long array.
They're still documented in call_list.txt, there are still references
to them in parts of the library, and there are fragments of the code
for them in nativecall.pl.

Change 9260 did this back in september (yes, it has been ages, I'm
just syncing up now). This breaks the postgres.pir interface code --
making calls into postgres now isn't possible, as the interpreter
pukes and dies when you try.

Are there alternatives? The documentation for this stuff is worse now
than when I wrote it originally, and it's not clear what needs to be
done to duplicate the functionality of the removed call types.
--
Dan

--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Leopold Toetsch]

On Jan 2, 2006, at 19:36, Dan Sugalski wrote:

> The big hang up has been the removal of the T and L parameter types
> for NCI calls. T was a string pointer array and L was a long array.

[ ... ]

> Are there alternatives? The documentation for this stuff is worse now
> than when I wrote it originally, and it's not clear what needs to be
> done to duplicate the functionality of the removed call types.

Sorry for the documentation mismatch, but you know that's the hardest
part. Anyway using {Un,}ManagedStruct for any item more complex than a
simple type (incl. C-strings) is the way to go. There are by far too
many possible permutations of foo* items to be covered with just one or
two plain signature chars.

This pod:

$ perldoc docs/pmc/struct.pod

should cover most of it.

Some examples are e.g. t/pmc/nci.t: nci_pi - struct with ints
or runtime/parrot/library/libpcre.pir, which is using array of ints too.
The SDL libraries are also using rather complex structures built with
the *Struct interface.

BTW: while looking at runtime/parrot/library/postgres.pir and
runtime/parrot/library/postgres.declarations I discovered some
inconsistencies, especially with these more complex structures, e.g.:

dlfunc $P2, $P1, 'PQexecParams', 'pptiLTLLi'
dlfunc $P2, $P1, 'PQexecPrepared', 'pptit33i'

whike the C declarations are vastly the same, the PIR counterparts are
totally different.

HTH,
leo