On 25.09.2013 20:56, Jan Dubois wrote:
> On Wed, Sep 25, 2013 at 11:50 AM, Torsten Schoenfeld
> wrote:
>>
>> newSVpv (string, PL_na) // do not do this
>
> Is this recomended anywhere?
Probably not. But <http://grep.cpan.me/?q=newSVpv.*PL_na> does show
quite a
I recently tracked down a difficult bug that occured only when one of my
XS modules was used in conjunction with certain other XS modules (e.g.,
XML::Parser or String::Approx). It turned out to be due to the
incorrect assumption that PL_na will always be zero. Specifically, we used
newSVpv (st
On 14.10.2011 08:11, Jeffrey Ratcliffe wrote:
On 12 October 2011 16:00, Torsten Schoenfeld wrote:
Looks like Glib's mechanism is not C++-safe: specifically, the "extern XS"
trick does not work because boot_Foo is already inside an
section. Try this:
It didn't help
On 12.10.2011 15:24, Jeffrey Ratcliffe wrote:
On 12 October 2011 13:11, Torsten Schoenfeld wrote:
You have to call Foo_Bar.xs' BOOT section (which wires up the xsubs) from
Foo.xs' BOOT section. Look at Glib.xs' BOOT section for an example. For
Gtk2 and below, this is handled b
On 12.10.2011 12:38, Jeffrey Ratcliffe wrote:
Assuming we have
Foo.xs
Fo.pm
Foo_Bar.xs
how do I get Foo::Bar to load/boot/import at the same time as Foo on use Foo?
You have to call Foo_Bar.xs' BOOT section (which wires up the xsubs)
from Foo.xs' BOOT section. Look at Glib.xs' BOOT section
On 10.06.2011 00:15, NormW wrote:
AV *results;
results = newAV();
something = (AV *)SvRV(*other_av_thing);
av_store(results,i, something);
RETVAL = results;
sv_2mortal((SV *)RETVAL);
Have seen that method in several XS programs (and PerlXSTut iirc) but it
is unclear if that works
On 19.07.2010 12:52, ravips wrote:
1. Should a "CLEANUP" tag be added which cleans up the array
( av_clear; av_undef;)?
No, you return the AV to the caller who then assumes ownership, so you
mustn't free it. I think you should even be able to get rid of the
sv_2mortal call since the AV* type
On 07.06.2010 10:43, Florian Weimer wrote:
Is the following the correct code sequence to return an array
reference or nothing (if result is 0) from an XS function?
PPCODE:
AV *result = 0;
if (some_condition) {
result = newAV();
av_push(resu
Jeffrey Ratcliffe wrote:
I attach the ExtUtils::Constant example from the blog.
Try changing, in Test.pm, this:
sub test {
print XST_ENUM_1, "\n";
}
to this:
sub test {
print XST_ENUM_1(), "\n";
}
-Torsten
Jan Dubois wrote:
> [Any reason you removed the CC to the perl-xs list?]
Oops, no, that was accidental. Adding it back, and quoting your reply below for
the benefit of the public.
I don't see a way to avoid this if you use PPCODE sections to return more
than
one value.
>>> Yes, s
Jan Dubois wrote:
>> SANE_Handle T_OPAQUEPTR
If you want the handle to be represented by a blessed scalar reference, you can
use T_PTROBJ. Or, if the package name chosen by T_OPAQUEPTR doesn't suit you,
define your own typemap and use sv_setref_pv yourself. See the implementati
On Mon, 2007-09-10 at 11:15 +0200, Scott Lanning wrote:
> I think it's a bug (or lack of C++ functionality) in xsubpp,
> but I'm not ruling out a self-introduced problem. :)
Yep, xsubpp's OVERLOAD support is broken.
Here's what's lacking:
> XS(XS_Ogre__Animation_nil); /* prototype to pass -Wmi
On Fri, 2007-10-26 at 23:33 +1000, Sisyphus wrote:
> During compilation I get the errors:
>
> _64bit_pl_498e.xs:20: error: syntax error before "SvGUInt64"
> _64bit_pl_498e.xs:30: error: syntax error before "value"
> _64bit_pl_498e.xs: In function `newSVGUInt64':
> _64bit_pl_498e.xs:40: error: `va
On Wed, 2007-10-24 at 21:49 +0100, William S Fulton wrote:
> Any portable solutions for extracting the unsigned long long number?
The best effort I can provide is what's in Glib. They do what Sisyphus
suggests: represent big numbers as strings if necessary.
#ifdef _MSC_VER
# include
#endif
#i
On Wed, 2006-10-04 at 17:15 -0400, Lobsingerp,Peter [CIS] wrote:
> I have tinkered with it and the code bellow works properly, although
> it should be equivalent to the above code. The only modification is
> holding the result of av_shift(Timeseries) in an intermediate pointer.
SvNV is a macro.
On Wed, 2005-05-25 at 11:38 +1000, Sisyphus wrote:
> > is there any way to reliably convert long longs (64bit integers) to SVs
> > (and back) on 32bit platforms without losing information, and without
> > compiling with -Duse64bitint? Both, IV and NV don't seem to provide
> > enough room to store
Aloha,
is there any way to reliably convert long longs (64bit integers) to SVs
(and back) on 32bit platforms without losing information, and without
compiling with -Duse64bitint? Both, IV and NV don't seem to provide
enough room to store large values.
--
Thanks for any pointers,
-Torsten
On Mon, 2004-03-01 at 09:38, Vadim O. Ustiansky wrote:
> If, as you said, you store a pointer to the C struct somewhere in an SV, the
> raw memory address becomes available at the perl level. The perl programmer
> may simply change this value and your C code will not notice it. This just
> opens a
On Tue, 2003-11-18 at 14:56, Tom wrote:
> I'd like to write a C routin which will handle an array reference and a
> string as parameter.
If you want to have an array *reference*, you've to treat it like one.
> SV *
> GenHash(params, key)
> PREINIT:
> char **pparam;
> int pnum;
>
19 matches
Mail list logo
