in reply to Re: ExtUtils::ParseXS has changed
in thread ExtUtils::ParseXS has changed

What file?

Basic/Core/Core.xs.PL

I'm just finished compiling PDL-2.4.9_005 with ExtUtils::ParseXS: 3.03

Yes - it should build fine, but only because its Basic/Core/typemap has a pointless typemap entry for 'PDL_Long *'.
Well ... of course, it's *not* pointless .... it prevents xsubpp from complaining about the lack of a typemap entry. But the typemap has no INPUT or OUTPUT entry for 'PDL_Long *' - it therefore does nothing other than trick xsubpp into believing that the typemapping has been done, thereby silencing the complaint.
Of course, no such typemapping has been done and I don't think this is the right solution.

I guess I remembered correctly, must be the comments, use /**/

If you say so ....

Cheers,
Rob

UPDATE: I suppose I should take the time to point out that the function I gave by way of example doesn't contain literally // code that does stuff
That just stands for a block of code whose actual content is irrelevant to the question I've asked.
Anonymous Monk, if you want to see the failure, try building 2.4.9_004 with ExtUtils-ParseXS-3.03. The error should occur about one minute (if that) into the 'make' stage.

Replies are listed 'Best First'.
Re^3: ExtUtils::ParseXS has changed
by Anonymous Monk on Aug 17, 2011 at 07:33 UTC

    ...has a pointless typemap entry for 'PDL_Long *'... has no INPUT or OUTPUT ...

    I don't think there is any tricking going on

    The default typemap has 

    T_PTR
    $var = INT2PTR($type,SvIV($arg))

    [download]

    I don't think it needs INPUT/OUTPUT

    Since PDL_Long * pos is the RETVAL, and the return type is SV*, you need a typemap entry

    You might not need it if you specified T_PTR as return type 

    T_PTR
at_c(x,position)
   pdl*    x
   PDL_Long * pos = NO_INIT
   CODE:
    // code that does stuff
    OUTPUT:
     RETVAL

    [download]

    I would test it, but, PDL takes a while to compile :)

[reply]
[d/l]
[select]
      Since PDL_Long * pos is the RETVAL

      I don't think so.
      That //code... stuff specifies SET_RETVAL_NV(x); which I think does *not* set pos to the RETVAL.
      Afaik at no stage does a 'PDL_Long *' get passed from perl to XS (or vice-versa) which is precisely why there should be no need for any typemap entry for 'PDL_Long *'.

      I also find that it doesn't matter whether the typemap has: 
      PDL_Long * T_PTR

      [download]
      or 
      PDL_Long * T_FOO

      [download]
      I suspect you could specify just about anything.

      And why would we need this typemap entry only with ExtUtils-ParseXS-3.0x ?
      Even perl-5.14.1 ships with version 2.2210 - and it doesn't require any typemap entry.

      I would test it, but, PDL takes a while to compile

      Like I said, it doesn't take long to hit the error - about 1 minute into the 'make' stage is all it takes to find out what works and what doesn't. The thing that takes most time is the running of 'make realclean' between successive attempts :-)

      Cheers,
      Rob
[reply]
[d/l]
[select]

        Since PDL_Long * pos is the RETVAL

        I don't think so...

        Reading http://perldoc.perl.org/perlxs.html#The-NO_INIT-Keyword again, I see I have misread

        After checking the generated Basic/Core/Core.c, I'm guessing it is an regression

        Also, it seems to me that any initializations using NO_INIT need to go after CODE

[reply]

In Section Seekers of Perl Wisdom