go once
I return home to a more capable computer. :)
Thanks!!!
Dave
--
David Oswald
daosw...@gmail.com
Excellent community involvement. I hope Inline::CPP becomes the target of
similar attention someday.
In particular, strange test-concurrency related failures (it's possible
that the changes in Inline fixed this for me) problems with multiple
inheritance, better compatibility with template program
DDLFLAGS config option might not be explicitly documented in the
> Inline::CPP docs
> (I haven't looked), but you'll find it documented in the Inline::C docs.
>
> The "BUILD_NOISY => 1," insertion is not part of the solution. It will
> enable you to see that the "-nodefaultlib" option is missing during the
> build process.
>
> Cheers,
> Rob
>
>
>
--
David Oswald
daosw...@gmail.com
7;s question, what environment variables or make
> variables do I need to set to install Inline *without* Inline::C and
> to specify a python for Inline::Python to do both of these make /
> installs non-interactively?
>
> Thanks,
> Jean
>
--
David Oswald
daosw...@gmail.com
the problem.
Hoping for a miracle (since this level of madness is nearly
indistinguishable from magic;)
Dave
--
David Oswald
daosw...@gmail.com
;
int count;
ENTER;
SAVETMPS;
PUSHMARK(SP);
// We're not passing params.
PUTBACK;
sv_setsv(get_sv("a",0),needle);
sv_setsv(get_sv("b",0),hay);
count = call_sv(block, G_SCALAR);
SPAGAIN;
if (count != 1)
croak("Callback had improper return value count.\n");
ret = POPi;
PUTBACK;
FREETMPS;
LEAVE;
}
return ret;
}
So, if anyone knows what I ought to try in eliminating the leak, or to
avoid clobbering $a and $b, I'd appreciate hearing.
Dave
--
David Oswald
daosw...@gmail.com
-----Original Message- From: David Oswald
> Sent: Wednesday, August 14, 2013 7:24 AM
> To: inline
> Subject: Implementing a callback with Inline::C
>
> See also http://www.perlmonks.org/index.pl?node_id=976632 for some other
> ideas.
>
> The "perfect" approach
s, at perlguts, perlcall, and so on, and
each time I think I've got it right I end up getting partway into it
and thinking, "Nah, this can't be right either." lol
--
David Oswald
daosw...@gmail.com
>> ashiva@ubuntu:~/Parrot/rakudo/Inline-0.44/Math-Simple$ cat
>>> lib/Math/Simple.pm
>>> package Math::Simple;
>>> $VERSION = '1.23';
>>>
>>> use base 'Exporter';
>>> @EXPORT_OK = qw(add subtract);
>>> use strict;
>>>
>>> use Inline C => 'DATA',
>>>VERSION => '1.23',
>>>NAME => 'Math::Simple';
>>>
>>> 1;
>>>
>>> __DATA__
>>>
>>> =pod
>>>
>>> =cut
>>>
>>> __C__
>>> int add(int x, int y) {
>>> return x + y;
>>> }
>>>
>>> int subtract(int x, int y) {
>>> return x - y;
>>> }
>>>
>>>
>>> But I keep getting this error :
>>>
>>> ashiva@ubuntu:~/Parrot/rakudo/Inline-0.44/Math-Simple$ perl6 math.pl
>>> ===SORRY!===
>>> arglist case of use not yet implemented. Sorry.
>>> at math.pl:3
>>> ashiva@ubuntu:~/Parrot/rakudo/Inline-0.44/Math-Simple$
>>>
>>> Does anyone know anything about it ?
>>>
>>> Please reply.
>>>
>>> Thanks & Regards,
>>> Ashraya S Shiva
>>
>>
>>
>>
>> --
>> Will "Coke" Coleda
>
>
--
David Oswald
daosw...@gmail.com
ne::CPP
that does just that. If its smoke testing doesn't get any worse than
it already is, I'll submit a patch for Inline that does the same
thing. If you want to use it you can, and if you don't, no hard
feelings. :)
Dave
On Sat, May 18, 2013 at 2:59 AM, wrote:
>
>
&
trying ?
>
> This, or maybe apply some locking? Depends on how much work it is, and
> on how relevant for later real world behaviour it is.
>
> Except for this, I'd leave the judgement to the implementor;)
>
> --
> andreas
>
--
David Oswald
daosw...@gmail.com
d release it after compilation
phase finishes. That would make Inline::CPP concurrency-safe even if
Inline were to remain not concurrency-safe. But that's just sweeping
the dust under the carpet. :)
--
David Oswald
daosw...@gmail.com
nline, or
the compilers themselves.
One area I hadn't previously considered is Makefile.PL itself, which
opens a file for output. That should be fine under normal user
conditions, but could present a problem for smokers running in
parallel.
Dave
--
David Oswald
daosw...@gmail.com
ally on what appears to be plain vanilla GNU/Linux.
Dave
--
David Oswald
daosw...@gmail.com
fter I'll bump the minimum Inline requirement to
0.43, and will release Inline::CPP v0.53 (confusing; I hope I got that
right).
Dave
--
David Oswald
daosw...@gmail.com
many compilers are not happy with being run in parallel, so
probably the best way to handle it is to have our Makefile.PL set 'make
test' to temporarily unset HARNESS_OPTIONS. Does anyone have any idea how
to do that?
Dave
--
David Oswald
daosw...@gmail.com
n, and also not sure how to specify reliably to Perl
(and later to Inline::CPP) where to find them.
use Inline CPP => Config => AUTO_INCLUDE => qq{#include
"$some_base_dir/boost/dynamic_bitset.hpp"};
How should I detect and specify $some_base_dir in a way that is robust
and
. Return an iterator, or return a value, or return a list, or a
Perl container.
So the short answer is feel free to use Tuples internally, and expose
to Perl either Perl containers or plain old data types, just as you
would do with vectors, maps, etc.
I hope this helps.
Dave
--
David Oswald
daosw...@gmail.com
ey're
deprecated. When they were introduced in C++03 most people almost
immediately considered them to be a really "bad idea" anyway, and I
don't think they ever found their way into mainstream use.
Inline::CPP's refusal to bind functions that use exception specifiers
can now be seen as a "feature." ;)
Dave
--
David Oswald
daosw...@gmail.com
; they are perfectly legal in Inline::CPP
whether or not they're intended for Perl binding. There's even a set
of tests in grammar/t/03inline.t that verify they work as they should.
The 'inline' keyword in specific will be honored to the same degree
that your compiler honors it
rammar for Inline::CPP to take a stab at the late
return type specification syntax?
I'm happy to add unit tests for the new syntax, and apply patches that
pass without breaking any existing tests. If anyone wants to tinker
with it, fork the Github repo, and issue a pull request if you're
successful.
Dave
--
David Oswald
daosw...@gmail.com
needs, you're done. Celebrate. Enjoy.
=cut
-
If anyone has any comments or suggestions, please let me know. In a
day or two I'll push the POD enhancement to github, and it will be
staged for the next release of Inline::CPP v0.42 (no timeframe planned
yet).
Dave
--
David Oswald
daosw...@gmail.com
em to have further improved our install success rate)
have now become Inline::CPP v0.41.
I've uploaded to CPAN, and it should be on your local mirrors soonish.
If anyone's using it for anything useful, I'd love to hear.
Dave
--
David Oswald
daosw...@gmail.com
t it's not heavily used has little to
do with the module's code, and a lot to do with the hurdle people have
to overcome in learning to write C or C++ code targeting Perl, so I'll
probably start working on cookbook examples next.
Dave
--
David Oswald
daosw...@gmail.com
7;m not
breaking something.
Strawberry won't be affected, because it gets trapped by a different
logic branch in Makefile.PL.
Thanks for your input!
Dave
--
David Oswald
daosw...@gmail.com
r maybe an issue that will only turn up if someone tries
to use iostream in their C++ extension code.
Dave
--
David Oswald
daosw...@gmail.com
686:0,
from _02basic_t_bc90.xs:15:
/usr/include/unistd.h:767:12: error: from previous declaration ‘int
setresgid(__gid_t, __gid_t, __gid_t) throw ()’
_02basic_t_bc90.xs: In constructor ‘Soldier::Soldier(char*, char*, int)’:
Dave
--
David Oswald
daosw...@gmail.com
anyone still reading: Do you know how to pull the
gitpan history for Inline::CPP into my existing Github repo? The
gitpan history ends at 0.27, and my repo's history starts at 0.25, I
think.
Dave
--
David Oswald
daosw...@gmail.com
g++ got upgraded without upgrading libraries to the
same version).
Multi-dimensional arrays as class member data. (Stalled bug report).
Dave
--
David Oswald
daosw...@gmail.com
at enabled
single-dimensional member arrays, but I haven't figured out the P::RD
grammar to achieve multi-dimensional.
Get your name mentioned in the CHANGES log! Fame! Fortune! (or just
my sincere thanks). It would be nice to get this out of "stalled"
status.
Dave
--
David Oswald
daosw...@gmail.com
7;ve been scratching my head over
this for a day or so now, and finally encouraged the OP to post here.
But it became clearer -- hopefully -- with a cleaner paste of the
error message.)
--
David Oswald
daosw...@gmail.com
figurations.
If anyone else could let me know what happens when they execute "cpanm
Inline::CPP --reinstall" (or if it's a fresh install, just leave off
the --reinstall flag), I'd appreciate it.
Dave
--
David Oswald
daosw...@gmail.com
of cpan minus), it works:
cpan Inline::CPP
...works fine.
Any thoughts? Can anyone confirm the behavior?
--
David Oswald
daosw...@gmail.com
There's what I think is probably just a typo in Makefile.PL for InlineX::CPP2XS
The prereq for Test::Warn is specified as Test::warn
This causes cpanm to fail to install InlineX::CPP2XS, since it treats
module names case-sensitively (as it should).
Dave
--
David Oswald
daosw...@gmail.com
your
module, removing the Inline::CPP dependency. In other words, use
Inline::CPP to do the dirty work of creating the XS, but then turn
your module into an XS module rather than an Inline::CPP-based module.
There's a module called InlineX::CPP2XS that can do the conversion
for you.
Sorry to say that as much work as has gone into it, there's still a
small "cross your fingers and hope" factor involved.
Dave
--
David Oswald
daosw...@gmail.com
currently. I'd love to see the future bring
a larger subset of C++ to Inline::CPP's understanding.
Dave
--
David Oswald
daosw...@gmail.com
toolkit on CPAN.
As before, this module depends on Inline::CPP and Inline::MakeMaker.
--
David Oswald
daosw...@gmail.com
gs as return type in some cases. However,
whenever I try to specify unsigned long as a parameter type,
compilation fails. I think it may be an Inline::C or Inline::CPP
issue, either in the grammar parsing or in the typemaps.
Dave
--
David Oswald
daosw...@gmail.com
ific case of my user, the user was trying to install
Math::Prime::FastSieve, which has an Inline::CPP dependency, which has
an Inline dependency, which has a Digest::MD5 dependency. The user
was trying to install on Perl 5.6.1.
I guess my question is "What has to happen next?" :)
Dave
On Fri, May 18, 2012 at 5:45 PM, Sisyphus wrote:
>
> - Original Message - From: "David Oswald"
>
>> Next: Dana identified that Inline will not install on Perl version
>> 5.8.0 or earlier.
>
>
> This is not quite correct.
> Digest::MD5 is core b
n corresponding with mentioned
the following:
"With 5.8.0 (64-bit), Digest::MD5 fails testing because it is using
utf8::is_utf8 without checking the version (this was added in 5.8.1)."
I'm not on the p5p list. Is there a p5p list-member here who would
like to raise the
ully we can get this fixed, and then put into our Makefile.PL's
a minimum version number for Digest::MD5 that overcomes the issue.
Dave
--
David Oswald
daosw...@gmail.com
rning, but I
really don't want it happening to my module when I don't even use
Inline. So for now I've disabled use of MPFS to avoid it.
That message is coming from Inline, but I can't figure out how one
might squelch it. Are there
eing DIRECTORIES the way it's being set in the
snippet you provided.
I'm away from my development systems today, and don't have
Inline::Java installed anyway (and if I did, wouldn't know what to do
with it since I don't know the first thing about Java). But perhaps
someone who is qualified could test that snippet under DEBUG mode, and
try to trace out whether validate() is even seeing DIRECTORY.
--
David Oswald
daosw...@gmail.com
ably won't have a chance to work with it for a few days, but
when I do I'll be sure to discuss my experiences here on the Inline
list (hopefully on-topic since I'll use Inline::C or maybe Inline::CPP
and then possibly Rob's c2xs or cpp2xs.
Dave
--
David Oswald
daosw...@gmail.com
ion to the
Inline::C cookbook. Any existing example code that shows how easy it
is to pass Perl strings as C-strings is glossing over the fact that as
soon as the user's data is utf8 encoded the code breaks.
--
David Oswald
daosw...@gmail.com
an XS version
of my List::BinarySearch module. It would be named
List::BinarySearch::XS, and I would convert List::BinarySearch to
auto-detect the XS version's presence, substituting the XS versions in
place of the Pure Perl versions if the XS module exists. Not
surprisingly, the documentation on dealing with strings in extension
code is a bit opaque.
Dave
--
David Oswald
daosw...@gmail.com
toring the
compiler and libs guess logic in Makefile.PL, and want to establish
v0.39 as a usable base in case my Makefile.PL refactoring breaks
something in an upcoming dev release.
By the way: Does anyone know a "best practice" for where example code
should go within a distributi
On Sun, Apr 22, 2012 at 6:38 AM, David Mertens wrote:
> This is a long shot, and likely a red herring, but I hear that the newest
> version of XCode changed the location of a number of developer tools.
>
> I have a Macbook with perlbrew. What versions of Perl and compiler options
> should I try? T
#x27;s only happening (so far) with that one Darwin smoker. There are a
handful of Linux issues too, but my frequently-wrong senses persuaded
me that the Darwin issue is lower hanging fruit than the Linux one.
Dave
On Sat, Apr 21, 2012 at 5:15 PM, Sisyphus wrote:
>
> - Original Messa
ile.PL
If there are any OS-X/Darwin users out there who have some idea of
what needs to happen to fix the Darwin failure I'd appreciate hearing.
Dave
--
David Oswald
daosw...@gmail.com
Mf_PL.diff
Description: Binary data
lineX::CPP2XS would benefit from similar treatment.
Would it make sense for the command-line version to exist within the
App:: namespace? App::InlineX::CPP2XS, for example.
As for how it should be invoked... sane defaults, easily overridden
from the command line (my vote).
--
David Oswald
daosw...@gmail.com
"libstdc++*" | grep $( uname -p )';
my $stdcpp =
`$stdlib_query`; + $stdcpp =~ s/^(.*)\/[^\/]+$/$1/;
$cc_guess = 'g++';
$libs_guess = "-L$stdcpp -lstdc++";
But as usual, I'm looking for suggestions that will target this
specific failure.
Dave
--
David Oswald
daosw...@gmail.com
anything outside of testing.
Dave
--
David Oswald
daosw...@gmail.com
dav...@cpan.org
As seen in a recent thread here (cross-posted to
module-auth...@perl.org), I was thinking of moving the Makefile.PL
"C++ guess" logic to a separate module to decouple development from
the core Inline::CPP module. The discussion that followed led me to
find ExtUtils::CppGuess, which looks like a re
gt; Either ExtUtils or Devel namespaces come to mind. I'll think more, but those
> are a start.
>
> David
>
> On Mar 23, 2012 4:49 PM, "David Oswald" wrote:
--
David Oswald
daosw...@gmail.com
I maintain Inline::CPP. Currently that module's Makefile.PL jumps
through a bunch of hoops to detect the C++ compiler most compatible
with the C compiler that built perl, and to detect what default C++
libraries should be linked in when building Inline::CPP client code.
A lot of work has gone into
Wed Mar 14 08:03:46 2012: Request 75664 was acted upon.
Transaction: Correspondence added by daoswald
Queue: Inline
Subject: Re: [rt.cpan.org #75664] Fails 09parser test in Cygwin with ***
fatal error
Broken in: 0.50
Severity: Important
Owner: Nobody
Requestors: starryc
at configuration/install
time. Config::General could help to avoid rolling a new solution.
--
David Oswald
daosw...@gmail.com
gcc_s
-lgcc
-lc
I could then specify those specific default libraries in Makefile.PL,
and should get a clean build on my system.
I'm not sure if this technique would be portable across other flavors
of compilers though. But if it is, it seems like a good way to get
rid of a lot of a big if(){} elsif(){} elsif(){} chain.
Dave
--
David Oswald
daosw...@gmail.com
e to inline C++ code.
As always I'm open to suggestions on some of the ongoing smoke test
and usability issues.
My github repo for Inline::CPP is under user daoswald on Github.com.
Dave
--
David Oswald
daosw...@gmail.com
ut not 100%) Perl::Critic level 4 compliance for CPP.pm and grammar.pm.
Let's hope for the best as the smoke tests roll in.
Dave
--
David Oswald
daosw...@gmail.com
project.
Dave
--
David Oswald
daosw...@gmail.com
module is the one generating the actual 'extern "C"' linkage
modifier, so here I am.
If anyone has any idea on what should happen next... whether
EU::ParseXS needs some help, or whether I should be digging more into
Inline::CPP and Inline's source, I'd appreciate some suggestions.
Dave Oswald
--
David Oswald
daosw...@gmail.com
dav...@cpan.org
t seems some of the generated code has syntax that is no longer valid
> under a recent g++.
>
> Patrick
>
> On 2/21/12, David Oswald wrote:
>> The great thing about how Chris Williams runs his smokers is that he
>> rotates through what seems to be hundreds of different
PP passing
95%+ of the smokers. I doubt we'll ever see 100% over a large set of
smoke tests (there will always be a new configuration that catches us
by surprise), but solving these two issues will get us close.
--
David Oswald
daosw...@gmail.com
://catalina.homedns.org:80/axs/u:c727b4d957b64adc8d9c6dd1c4810179/gv.png
Kinda makes me wish I hadn't asked. ;)
Dave
--
David Oswald
daosw...@gmail.com
.
--
David Oswald
daosw...@gmail.com
On Wed, Feb 15, 2012 at 4:21 PM, Sisyphus wrote:
>
> - Original Message - From: "David Oswald"
>
>
>> If someone with an understanding of MacOSX/Darwin could have a look at
>> the FAIL report here:
>>
>> http://www.cpantesters.org/cpan/re
passed
121 of 123 smokers, and 0.34_002 will have resolved at least one of
the two failures.
Dave
--
David Oswald
daosw...@gmail.com
ut << c->do_another() << endl;
void *x = c ;
cout << static_cast< Child* >(x)->do_something() << endl;
cout << static_cast< Child* >(x)->do_another() << endl;
return 0;
}
Though I'm not much closer to a solution, at least your message
reminded me that we're dealing with void pointers to objects. Maybe I
need to start looking at how and where the casting is being
accomplished.
Dave
--
David Oswald
daosw...@gmail.com
(the code I'm using to tickle this bug)
another.pl (a non-Test::More version that tries to keep it as
simple as possible)
If anyone has the energy and willingness, please run 11minhrt.t and
see what happens. Some theories I might chase down would be even
better! :)
Dave
--
David Oswald
daosw...@gmail.com
another.pl
Description: Binary data
e in some cases the C++
compiler can't be found as detected by Makefile.PL. Thanks sisyphus
for the suggestion.
As usual this is also on github in the dev branch of my Inline-CPP
repo (daoswald).
Dave
--
David Oswald
daosw...@gmail.com
yone wanting to see the full Makefile.PL with modifications can pull
it from the dev branch of my github repo (daoswald).
Dave
On Thu, Feb 9, 2012 at 9:07 PM, Sisyphus wrote:
>
> ----- Original Message - From: "David Oswald"
>
>> But if I remove that test and
On Thu, Feb 9, 2012 at 5:26 PM, Sisyphus wrote:
>
> - Original Message - From: "David Oswald"
>
>
>> It looks to me like the 'if( $config{cc} eq 'gcc' ) " code is
>> falling through to the else clause that sets $cc_guess to
aults for other (probably unix-like) operating systems
else {
$cc_guess = 'g++';
$libs_guess = '-lstdc++';
}
Any Solaris gurus out there who might know why we're not correctly
detecting the compiler for Solaris 2.11?
It looks to me like the 'if( $config{cc} eq 'gcc' ) " code is
falling through to the else clause that sets $cc_guess to 'CC', and in
this case probably shouldn't be.
Dave
--
David Oswald
daosw...@gmail.com
robust test
suite. ...and apparently it's paying off as it led me to discover
this issue.
Neil: I'm CC'ing you out of a long-shot hope that you might remember
enough about how grammar.pm deals with multiple inheritance to spot
the problem.
Dave
--
David Oswald
daosw...@gmail.com
o said bug.
Thanks go to sisypus for tracking down a fix within Inline that makes
it possible for me to get meaningful reports back from smokers, thus
facilitating further work progress on Inline::CPP.
Dave
--
David Oswald
daosw...@gmail.com
testing();
__DATA__
__CPP__
int myfunc( void )
{
return 100;
}
I guess I wasn't aware that this hadn't been implemented yet (and
haven't checked to verify either). But if this is what you're looking
for please let me know and I'll get to it pronto.
Dave
--
David Oswald
daosw...@gmail.com
; store that, of course, but the return value of the accessor will not
> properly mark the SV with the UTF-8 flag.
>
> David
>
> On Feb 6, 2012 3:00 AM, "David Oswald" wrote:
>>
>> I stumbled across a strange issue in Inline::CPP. Here's a test to
>> i
Here are some additional facts: There is no
failure if we pass a basic data type instead of a pointer to a
c-string. That's because when passing basic data types copies are
made, whereas when passing pointers around there is no additional copy
of the data pointed to.
I'm trying to decide if this is a Test::More::use_ok bug, a bug in my
test C++ code, a bug in Inline::CPP, a bug in the typemap for char*,
or a bug in Inline::C.
If anyone wishes to play with it, you can find it in my github repo:
g...@github.com:daoswald/Inline-CPP.git
Check out the 'cstr-test' branch. The specific test is t/16charptr.t
Dave
--
David Oswald
daosw...@gmail.com
the Parse::RecDescent isue.
Dave
--
David Oswald
daosw...@gmail.com
add multi-dimensional arrays to the grammar, but
for now this is a step toward resolving the outstanding RT.
If this version fares well in smoke tests I'll re-release it as 0.34 stable.
The github repo can be found at g...@github.com:daoswald/Inline-CPP.git
Dave
--
David Oswald
daosw...@gmail.com
t's going on... or maybe we'll still be scratching our
heads.
Dave
--
David Oswald
daosw...@gmail.com
moke
tests and the install phase, and that once Inline::CPP is actually
installed it clears itself up. That's only a hunch, but it really
does just look like there's a problem in how the smokers are dealing
with this particular dependency.
Of course the final code would clean up 'or die&
Things just got much worse...
Smoke test results for Inline::CPP v0.33_005 are looking awful.
Things are really going the wrong direction, and I'm beginning to
believe it has nothing to do with Inline::CPP at all.
If you have a look at the test reports linked to here:
http://static.cpantesters.o
Rob / Dean:
I added a test: t/00load_prereqs.t for Inline::CPP, bumped the dev
version to 0.33_005, and pushed it to github and CPAN.
Instead of using "warn" as Rob suggested, I used Test::More's
"diag()" function. it guarantees output will not interfere with the
TAP harness, and also guarantees
> just with Inline::CPP ?
>
> Cheers,
> Rob
If we learn that the PERL5LIB env variable needs to be massaged I
could at least put some explanation into the INSTALL section of
I::CPP's POD. That's not ideal, but it would be a start. I think it
would be helpful to see that "BEGIN {warn..." output.
Dave
--
David Oswald
daosw...@gmail.com
better isolate the point of failure.
If anyone has some additional insight I'm sitting on the edge of my
seat in anticipation. ;)
Thanks again!
Dave
--
David Oswald
daosw...@gmail.com
way once we're satisfied with the stability of
the dev branch it can be merged back to the main branch culminating in
the next stable release (0.34).
Feel free to fork, explore, commit. :)
Dave
--
David Oswald
daosw...@gmail.com
ToDo list.
Dave
On Fri, Dec 23, 2011 at 12:05 AM, Sisyphus wrote:
>
> - Original Message - From: "David Oswald"
> To: "Sisyphus"
> Sent: Friday, December 23, 2011 2:55 PM
>
> Subject: Re: Inline::CPP development version 0.33_003 uploaded to CPAN
&
s learned would be helpful here?
Dave
--
David Oswald
daosw...@gmail.com
BrowserUk and I mostly discussed this via /msg, however he did paste
his output into his scratchpad on PerlMonks, here:
http://www.perlmonks.org/?viewmode=public;node_id=358718
I think he has joined the Inline list, as of a few hours ago.
David Oswald
daosw...@gmail.com
. That way, a user can easily #undef
them before any other includes. I don't know why that last feature
would be helpful, but it may have some merit in testing.
Dave
--
David Oswald
daosw...@gmail.com
. And, even if we're including namespace std
by default we aren't forcing the user to NOT use other namespaces.
If it is a concern, I could also create an "AUTO_NAMESPACE_STD"
configuration option: 1 default, 0 optional to disable the smartness
again.
I'm more or less sold on applying both of these upgrades. But I'd be
interested in opinions first.
Dave
--
David Oswald
daosw...@gmail.com
#x27;.
That's fine for the ActiveState people, but anyone else who has their
own build based on a newer MS Visual C++ has a problem.
--
David Oswald
daosw...@gmail.com
n to META.yml and META.json that is interpreted by 'cpan',
'cpan', and 'cpanp' such that they will pull in these dependencies
prior to attempting to run Makefile.PL.
Thanks!
Dave
--
David Oswald
daosw...@gmail.com
#x27;m talking about. Take a look at the smoke
tests, say, tomorrow. If we stop seeing the "unknown" test results
then we'll know this approach succeeded.
Dave
--
David Oswald
daosw...@gmail.com
ine::C presentation (with some discussion on
Inline::CPP as well) are here:
http://www.box.com/s/svecm9hq1tam27ggdjds
Dave
--
David Oswald
daosw...@gmail.com
is installed. If
anyone has any thoughts I'm scratching my head on this one.
--
David Oswald
daosw...@gmail.com
1 - 100 of 104 matches
Mail list logo
