From: Andreas Koenig "Sisyphus via RT" <bug-Inline@rt.cpan.org> writes:

> Is that worth 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

From: Sisyphus via RT Sun May 19 01:37:37 2013: Request 85336 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Fails often when tested in parallel
Broken in: 0.53
Severity: (no value)
Owner: Nobody
Requestors: ANDK@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85336 >


On Sat May 18 10:40:47 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
> "Sisyphus via RT" <bug-Inline@rt.cpan.org> writes:
>
> > Is that worth 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;)

I don't think it's very relevant to real world usage - and hence my (personal) interest in this is nowhere near as keen as it would otherwise be.

However, David Oswald wants to write some patches that will put in place file locking. If there's no problem with those patches, I'll apply them (when I receive them) and release a new devel version of Inline.

Hopefully, that will keep everyone happy :-)

Cheers,
Rob

From: sisyphus1

-----Original Message-----
From: David Oswald

> Here's what I'll do: I'm going to release a dev release of Inline::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. :)

If you provide a patch, I'll certainly apply it and release a new Inline
devel version - providing, of course, that it doesn't break anything.

Cheers,
Rob

From: David Oswald I appreciate your point of view as well. Disagreeing is healthy. If
we all just fell in line with each other's whims and opinions we would
risk heading off on a path to irrelevancy.

I also agree that I'm hard-pressed to come up with a situation where a
normal use of Inline would result in concurrent compilation. Race
conditions only occur when there's a race. Perhaps if a script
included two or more modules that both relied upon Inline, and both
hadn't previously been compiled, but that's far-fetched.

On the one hand, we can reasonably assert that the CPAN testers are
testing incorrectly if they're testing with concurrency, and that our
failure to pass their tests is due to them not taking into
consideration the fact that some modules will never be used that way.
On the other hand, they have a monumental task in trying to test
everything that shows up on CPAN, and expecting special case treatment
for Inline might be more than they're able to accommodate. Yes,
that's broken. But people look at the test results when weighing
whether or not we're an appropriate solution, and unfortunately, they
don't always dig into the "why" when they see a FAIL.

The easiest solution for Inline would be to simply flock a semaphore
file before it compiles any target code, and unlock it after it's done
with the build directory. This would require only a single flock, and
would prevent concurrent use of the build resources. It would have
zero impact on normal users (it would never block since they would
never be compiling in parallel), but would cause the tests to block
for a moment occasionally. That should avoid all race conditions.

Here's what I'll do: I'm going to release a dev release of Inline::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, <sisyphus1@optusnet.com.au> wrote:
>
>
> -----Original Message----- From: David Oswald
>
>
>> Rob: I notice there are numerous places in the Inline distribution where
>> we're opening for output but not flocking. I didn't even look at possible
>> issues where we might be opening for input, reading, then opening for
>> output and expecting to not tromp on another process that may have gotten
>> in the middle of the cycle.
>
>
> The key thing for me is that this absence of flocking has never (afaik) been
> reported as an issue for any *user*.
> Not wishing to denigrate cpan-testers (who do a fantastic job), but I've
> always been loathe to address something that exists only in a smoking
> set-up, for fear it's going to open up a can of worms for those who actually
> want to make use of the module.
> I still see the occasional cpan-tester FAIL report where 'use diagnostics;'
> is a fatal error ... which only reinforces my resolve to be a little bit
> cautious about the significance of the failures that the cpan-testers throw
> up :-)
>
>
>> I think that Inline probably should be
>> implementing flocking on all outputs, and anytime an output follows a
>> read, we should use a flocked semaphore file to maintain the lock across
>> the read/write cycle.
>
>
> I can't see that this should be necessary except perhaps for the
> configuration file that gets written in the top level build directory.
> I don't insist on not implementing stuff that's pointless (as along as it
> comes at little cost), but I'm a bit wary of *flocking* across the board
> because I can never get the damn thing to work *portably* && *silently*.
> (Maybe that's just because I'm inexperienced in the use of flock.)
> If we do flock, I'd rather do it only where it's proven to be necessary.
>
>
>> I can confirm that even after fixing Inline::CPP,
>> we still have race conditions that must be coming from inside of Inline,
>> that rear their ugly head while executing tests in parallel.
>
>
> Can you give me an actual "use" case - one that's outside the
> cpan-tester/smoker/Test::Harness environment ?
> That would probably encourage me to become a more responsible and caring
> Inline maintainer :-)
>
>
>> The fixes
>> within Inline shouldn't be too difficult, but there are so many places
>> that Inline interacts with files, it will be hard to assure we've gotten
>> all of them.
>
>
> My thinking is that we can't be missing too much or we would've received at
> least one bug report about it from a user in the last 15 years.
>
>
>> I suppose I could implement a semaphore flock at the
>> beginning of compilation phase for Inline::CPP and 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. :)
>
>
> Well ... that'd be good enough for me. Does that work ?
>
> Although (as is clearly evident) I'm not all that passionate about this at
> the moment, I would probably find it hard to ignore any patch that:
> a) broke none of the current tests;
> &&
> b) created no noise.
>
> (But I'd still prefer that we flocked only where it's demonstrably needed.)
>
> And I still can't help feeling that cpan-testers/Test::Harness/smokers might
> be assuming something of Inline that it was never designed (or intended) to
> deliver ... dunno ... again, an actual "use" case demonstrating the problem
> would be helpful here.
>
> As you can see, David, I don't entirely agree with your POV at the moment.
> But I *do* appreciate that you took the time and effort to express it. (And
> I thank you for doing that !!)
>
> Cheers,
> Rob



--

David Oswald
daoswald@gmail.com

From: David Oswald via RT Sat May 18 11:23:47 2013: Request 85336 was acted upon.
Transaction: Correspondence added by daoswald
Queue: Inline
Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
Broken in: 0.53
Severity: (no value)
Owner: Nobody
Requestors: ANDK@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85336 >


I get test failures in Inline::CPP when running tests in parallel.
I've gone through Inline::CPP and implemented file locking to
eliminate race conditions, but the issue persists. That leads me to
believe that there needs to be a similar fix in Inline. Changing
Inline's tests to use separate build directories wouldn't fix the
underlying issue of Inline not supporting concurrency. Proper file
locking probably would resolve the issue, not only for Inline, but
also for plugins such as Inline::CPP.


On Sat, May 18, 2013 at 8:40 AM, (Andreas J. Koenig) via RT
<bug-Inline@rt.cpan.org> wrote:
> Sat May 18 10:40:47 2013: Request 85336 was acted upon.
> Transaction: Correspondence added by andreas.koenig.7os6VVqR@franz.ak.mind.de
> Queue: Inline
> Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
> Broken in: 0.53
> Severity: (no value)
> Owner: Nobody
> Requestors: ANDK@cpan.org
> Status: open
> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85336 >
>
>
> "Sisyphus via RT" <bug-Inline@rt.cpan.org> writes:
>
>> Is that worth 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
daoswald@gmail.com

From: via RT Sat May 18 10:40:47 2013: Request 85336 was acted upon.
Transaction: Correspondence added by andreas.koenig.7os6VVqR@franz.ak.mind.de
Queue: Inline
Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
Broken in: 0.53
Severity: (no value)
Owner: Nobody
Requestors: ANDK@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85336 >


"Sisyphus via RT" <bug-Inline@rt.cpan.org> writes:

> Is that worth 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

From: sisyphus1

-----Original Message-----
From: David Oswald

> Rob: I notice there are numerous places in the Inline distribution where
> we're opening for output but not flocking. I didn't even look at possible
> issues where we might be opening for input, reading, then opening for
> output and expecting to not tromp on another process that may have gotten
> in the middle of the cycle.

The key thing for me is that this absence of flocking has never (afaik) been
reported as an issue for any *user*.
Not wishing to denigrate cpan-testers (who do a fantastic job), but I've
always been loathe to address something that exists only in a smoking
set-up, for fear it's going to open up a can of worms for those who actually
want to make use of the module.
I still see the occasional cpan-tester FAIL report where 'use diagnostics;'
is a fatal error ... which only reinforces my resolve to be a little bit
cautious about the significance of the failures that the cpan-testers throw
up :-)

> I think that Inline probably should be
> implementing flocking on all outputs, and anytime an output follows a
> read, we should use a flocked semaphore file to maintain the lock across
> the read/write cycle.

I can't see that this should be necessary except perhaps for the
configuration file that gets written in the top level build directory.
I don't insist on not implementing stuff that's pointless (as along as it
comes at little cost), but I'm a bit wary of *flocking* across the board
because I can never get the damn thing to work *portably* && *silently*.
(Maybe that's just because I'm inexperienced in the use of flock.)
If we do flock, I'd rather do it only where it's proven to be necessary.

> I can confirm that even after fixing Inline::CPP,
> we still have race conditions that must be coming from inside of Inline,
> that rear their ugly head while executing tests in parallel.

Can you give me an actual "use" case - one that's outside the
cpan-tester/smoker/Test::Harness environment ?
That would probably encourage me to become a more responsible and caring
Inline maintainer :-)

> The fixes
> within Inline shouldn't be too difficult, but there are so many places
> that Inline interacts with files, it will be hard to assure we've gotten
> all of them.

My thinking is that we can't be missing too much or we would've received at
least one bug report about it from a user in the last 15 years.

> I suppose I could implement a semaphore flock at the
> beginning of compilation phase for Inline::CPP and 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. :)

Well ... that'd be good enough for me. Does that work ?

Although (as is clearly evident) I'm not all that passionate about this at
the moment, I would probably find it hard to ignore any patch that:
a) broke none of the current tests;
&&
b) created no noise.

(But I'd still prefer that we flocked only where it's demonstrably needed.)

And I still can't help feeling that cpan-testers/Test::Harness/smokers might
be assuming something of Inline that it was never designed (or intended) to
deliver ... dunno ... again, an actual "use" case demonstrating the problem
would be helpful here.

As you can see, David, I don't entirely agree with your POV at the moment.
But I *do* appreciate that you took the time and effort to express it. (And
I thank you for doing that !!)

Cheers,
Rob

From: Sisyphus via RT Sat May 18 02:20:38 2013: Request 85336 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Fails often when tested in parallel
Broken in: 0.53
Severity: (no value)
Owner: Nobody
Requestors: ANDK@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85336 >


On Wed May 15 23:11:13 2013, ANDK wrote:

> There seems to be a race condition somewhere.

Both of the affected test scripts (t/21read_DATA.t and t/22read_DATA.t) use the same Inline build directory (.Inline) - and they therefore need to access the same configuration file.

If you think that could be the source of the problem, I could work around that by designating 2 different (separate) build directories for those 2 test scripts - thereby assuring that each script has its own copy of the configuration details.
Is that worth trying ? (If so, let me know, and I'll upload a new developer version of Inline that does exactly that and we can see how that goes.)

Cheers,
Rob

From: David Oswald Inline::CPP v0.44 has been uploaded to CPAN.

This version implements flocking on the typemap output file within
CPP.pm, and on two temp files used by Makefile.PL. This should
eliminate race conditions that could possibly be caused within
Inline::CPP, particularly when testing under "HARNESS_OPTIONS=jX", or
by smokers that are testing more than one install at the same time.
The general use case is unlikely to encounter problems, but you never
know, so better safe than sorry.

Rob: I notice there are numerous places in the Inline distribution
where we're opening for output but not flocking. I didn't even look
at possible issues where we might be opening for input, reading, then
opening for output and expecting to not tromp on another process that
may have gotten in the middle of the cycle.

I think that Inline probably should be implementing flocking on all
outputs, and anytime an output follows a read, we should use a flocked
semaphore file to maintain the lock across the read/write cycle.

I can confirm that even after fixing Inline::CPP, we still have race
conditions that must be coming from inside of Inline, that rear their
ugly head while executing tests in parallel.

The fixes within Inline shouldn't be too difficult, but there are so
many places that Inline interacts with files, it will be hard to
assure we've gotten all of them.

I suppose I could implement a semaphore flock at the beginning of
compilation phase for Inline::CPP and 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
daoswald@gmail.com

From: David Mertens I am not sure about the underlying mechanics, but if you need a second set
of eyes on any of the code, feel free to drop a note with line numbers
where the code does funny things.


David


On Wed, May 15, 2013 at 11:15 PM, David Oswald <daoswald@gmail.com> wrote:

> I noticed Andreas Koenig opened a bug report on Inline (RT#85336)
> wherein he asserts there's probably a race condition present, as he's
> finding that operating several smokers in parallel will sometimes
> result in failures.
>
> This may be related to an issue I see, where running Inline::CPP's
> test suite with HARNESS_OPTIONS=j9 will also result in failures.
> Inline::CPP's tests are not sensitive to script order (tests within a
> script must be run in order, but it shouldn't matter what order the
> test scripts are run). As they're not order-sensitive, failure under
> harness parallel testing has to point to a race condition within
> Inline::CPP or Inline.
>
> I'm going to look over Inline::CPP's code base with added scrutiny to
> assure that any IO operations it owns are implementing flocking. But
> it doesn't own many IO operations; most IO is pushed off to Inline, 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
> daoswald@gmail.com
>



--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

From: David Oswald I noticed Andreas Koenig opened a bug report on Inline (RT#85336)
wherein he asserts there's probably a race condition present, as he's
finding that operating several smokers in parallel will sometimes
result in failures.

This may be related to an issue I see, where running Inline::CPP's
test suite with HARNESS_OPTIONS=j9 will also result in failures.
Inline::CPP's tests are not sensitive to script order (tests within a
script must be run in order, but it shouldn't matter what order the
test scripts are run). As they're not order-sensitive, failure under
harness parallel testing has to point to a race condition within
Inline::CPP or Inline.

I'm going to look over Inline::CPP's code base with added scrutiny to
assure that any IO operations it owns are implementing flocking. But
it doesn't own many IO operations; most IO is pushed off to Inline, 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
daoswald@gmail.com

From: Andreas Koenig via RT Wed May 15 23:11:13 2013: Request 85336 was acted upon.
Transaction: Ticket created by ANDK
Queue: Inline
Subject: Fails often when tested in parallel
Broken in: 0.53
Severity: (no value)
Owner: Nobody
Requestors: ANDK@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85336 >


Yesterday my smoker produced two fails while 4 processes were testing Inline 0.53:

http://www.cpantesters.org/cpan/report/62c114d6-bda4-11e2-874b-cb6a10d45c6b
http://www.cpantesters.org/cpan/report/64619edc-bda4-11e2-924f-916b10d45c6b

It's possible that these two were disturbing each other, they were both distrubed by some other, succeeding test run. I smoked with 4 parallel processes. It's not for the first time this happens, I have produced more fail reports in the past but not always they come in pairs. But I have not seen more than two in a row.

There seems to be a race condition somewhere.

HTH,

From: Sisyphus via RT Wed May 08 22:45:09 2013: Request 11748 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_msu@pisem.net
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=11748 >


Marking as resolved.
Fixed in Inline-0.53 (which was released to CPAN on 30th April 2013).

Cheers,
Rob

From: David Oswald I've released Inline::CPP v0.43 to CPAN. This is a mainstream release
that bumps the Inline dependency requirement to 0.53 to address the
"typemap clobbers inc" bug. As discussed here previously, this was
probably an Inline::CPP issue, but the easiest fix was to make Inline
more tolerant.

If anyone on the list is having trouble installing Inline::CPP
(especially after disabling any HARNESS_OPTIONS environment variable
settings -- concurrent tests seem to be a no-no) please let me know so
that we can work out a solution. We're still failing on Dragonfly,
and occasionally on what appears to be plain vanilla GNU/Linux.

Dave

--

David Oswald
daoswald@gmail.com

From: sisyphus1 Hi,

Inline-0.53 has just been pushed to CPAN, and should be available at the
various mirrors, soon.

No changes from 0.52_02, except for the inclusion of an additional test
script (C/t/23validate.t).

Cheers,
Rob

From: David Oswald Inline::CPP v0.42_002(dev) has been uploaded to CPAN. The primary
change is to require Inline::C version 0.52_02. This dev version of
Inline::C addresses the Inline RT#11748, which also solves Inline::C
RT#84762.

The issue was that the INC parameter was being clobbered by
Inline::CPP's typemap validation process. While it's likely that
Inline::CPP was at fault for abusing Inline::C's API, it turned out
that the simplest solution was to make Inline::C's API more tolerant
of abuse, which is what Rob essentially did.

The other change was to the POD, addressing how to avoid "Namespace
stuttering": (See the POD's new "The Perl Namespace Hack" section) --
this solution came from BrowserUk.

Once the dynamic duo of madness (Inline::C and Inline::CPP) make it
through the smokers I understand Rob will be releasing Inline::C
v0.43. Soon thereafter 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
daoswald@gmail.com

From: sisyphus1 Hi,

Only change is a small alteration to Inline::C::validate().
This is mainly for the benefit of Inline::CPP.

See:
https://rt.cpan.org/Ticket/Display.html?id=11748

Unless cpan-testers reports tell us that this change has broken something,
it will be released as 0.53 early next week.

Cheers,
Rob

From: Sisyphus via RT Tue Apr 23 23:49:15 2013: Request 11748 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_msu@pisem.net
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=11748 >


On Sat Apr 20 02:53:07 2013, iang wrote:

> I think the fault is in Inline::CPP, not Inline::C.

Yes, I now think that *is* right.

> If Inline::CPP
> generates typemap data (if $typemap has non-zero length in
> Inline::CPP::write_typemap) then Inline::CPP::validate is called
> with the generated TYPEMAP data passed, but this calls
> Inline::C::validate, which sets $o->{ILSM}{MAKEFILE}{INC}, unless
> $o->UNTAINT is set.
[snip]
> Part of the issue is that when validating TYPEMAP, all the other
> options are not passed to Inlince::C::validate. The initialization
> there sets INC and the previously passed value is not appended
> because it is not passed, only the TYPEMAP is passed.

Seems to me that Inline::C::validate is not really designed to receive that set of data, and Inline::CPP should probably not be passing that set of data to it.
Nevertheless, it can apparently be easily fixed by applying the suggested change to Inline::C::validate - so I'll go with the original fix.
A version of Inline containing this fix has been uploaded to CPAN as Inline-0.52_02. Unless, in the meantine, there's an issue found with Inline-0.52_02, it will be released as Inline-0.53 early next week.

Thanks again, Ian, for for the digging and the demo case.

Cheers,
Rob

From: Sisyphus via RT Sat Apr 20 07:06:17 2013: Request 11748 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_msu@pisem.net
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=11748 >


On Sat Apr 20 04:43:46 2013, iang wrote:
> I have looked at this a little further and, while I don't see any
> evidence of a bug in Inline::C, the bug in Inline::CPP (see Bug
> #84762) can be fixed by a change to Inline::C.

Thanks for the test case - and for digging around and providing ideas on how to fix this.
Now that I have a demo to study, I can see that the '-IC:/' gets lost inside Inline::C::validate (which is called near the end of Inline::CPP::validate). This would suggest to me that it *is* a bug in Inline::C.

I'll do something about this when I get the time to study more closely what's going on. (Should have some time for that within the next fortnight.)

Thanks again, Ian.

Cheers,
Rob

From: Ian Goodacre via RT Sat Apr 20 04:43:46 2013: Request 11748 was acted upon.
Transaction: Correspondence added by iang
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_msu@pisem.net
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=11748 >


I have looked at this a little further and, while I don't see any evidence of a bug in Inline::C, the bug in Inline::CPP (see Bug #84762) can be fixed by a change to Inline::C.

An alternative to the change previously suggested is to change Inline::C::validate

if (not $o->UNTAINT and not defined($o->{ILSM}{MAKEFILE}{INC})) {
require FindBin;
$o->{ILSM}{MAKEFILE}{INC} = "-I\"$FindBin::Bin\"";
}


This has the very small advantage of not requiring FindBin unless it will be used.

I don't understand what is happening to be confident this is the best way to fix the bug in Inline::CPP or that it doesn't cause other problems, but it is consistent with the other initializations in Inline::C::validate - only setting INC to default value if it is not already set.

From: Ian Goodacre via RT Sat Apr 20 02:53:07 2013: Request 11748 was acted upon.
Transaction: Correspondence added by iang
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_msu@pisem.net
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=11748 >


On Mon Jun 29 19:24:59 2009, SISYPHUS wrote:
> On Fri Mar 04 06:12:48 2005, guest wrote:
> > It had seemed that Inline::CPP ignores INC Config option, but the bug
> > has been discovered in Inline::C: $o->{ILSM}{MAKEFILE}{INC} gets
> > erased each time validate() sub is called (sometimes it occurs
> > several times per script execution).
>
> A simple script demonstrating the precise problem would be handy, just
> to make sure that we (I) understand correctly. I'm not sure that the
> suggested patch is really necessary ... though there's probably no
> compelling reason to reject it.
>
> Cheers,
> Rob

I think the fault is in Inline::CPP, not Inline::C. If Inline::CPP generates typemap data (if $typemap has non-zero length in Inline::CPP::write_typemap) then Inline::CPP::validate is called with the generated TYPEMAP data passed, but this calls Inline::C::validate, which sets $o->{ILSM}{MAKEFILE}{INC}, unless $o->UNTAINT is set.

A simple script which elicits the problem is as follows. The extra include directory is useless, but it is also lost. Sorry, but the real case I was working on is a lengthy mess at the moment and I don't know a simple case where the extra include is actually needed.

Part of the issue is that when validating TYPEMAP, all the other options are not passed to Inlince::C::validate. The initialization there sets INC and the previously passed value is not appended because it is not passed, only the TYPEMAP is passed.


#!C:/strawberry/perl/bin/perl.exe
#
use strict;
use warnings;
use Inline ('CPP' => 'DATA',
'INC' => '-IC:/',
);

print "9 + 16 = ", add(9, 16), "\n";

__END__
__CPP__

// change 7
int add(int x, int y) {
return x + y;
}

// Adding the following class causes Inline:CPP to generate
// typemap data which is validated. The validation of the
// typemap data causes the configuration of INC to be lost
// In this case, Inline::C::validate, which is called from
// Inline::CPP::validate, sets $o->{ILSM}{MAKEFILE}{INC}
// unless $o->UNTAINT is set.
class CRectangle {
int x, y;
public:
void set_values(int, int);
int area() { return(x*y); }
};

void CRectangle::set_values(int a, int b) {
x = a;
y = b;
}

From: sisyphus1 Hi,

Inline-0.52_01 has been uploaded to CPAN.
It contains just one change from Inline-0.52.

In Inline.pm's sub read_DATA() I've changed:

@{$DATA{$pkg}} = split /(?m)(__\S+?__\n)/, $data
to:
@{$DATA{$pkg}} = split /(?m)^[ \t]{0,}(__\S+?__\n)/, $data;

The bug that this addresses was discovered by Chris Nighswonger in some
Inline::Python code.
It can also affect Inline::C/Inline::CPP - but only if somewhat unorthodox
coding styles are adopted. (Not sure what other Inline::* modules might be
affected.)

By way of example, upto and including Inline-0.52 the following Inline::C
script would *not* compile:

##################
use Inline C => 'DATA';

foo();

__DATA__
__C__

#define __symbol__ 42

void foo() {
printf("%d: %s\n", __symbol__
, "Hello\n");
}

##################

As of Inline-0.52_01 it will work as intended.

Note that this change has the potential to break existing (albeit
ill-advisedly constructed) code.
For example, upto and including Inline-0.52 the following inline::C script
*would* compile (and run) fine, though it should probably have not:

##################
use Inline C => 'DATA';

foo();

__DATA__
some arbitrary garbage !@#$%^&*()_+++ __C__

#define __symbol__ 42

void foo() {
printf("%d: %s\n", __symbol__, "Hello\n");
}

##################

As of Inline-0.52_01 it will *not* compile. (And I think that is a step in
the right direction.)

Finally, this is not a complete fix. Even as of Inline-0.52_01 the following
Inline::C script will *not* compile (though it's valid C code):

##################
use Inline C => 'DATA';

foo();

__DATA__
__C__

#define __symbol__ 42

void foo() {
printf("%d: %s\n",
__symbol__
, "Hello\n");
}

##################

For this particular Inline::C script, '__symbol__' is still deemed by
0.52_01 to be a marker (as is also the case with 0.52 and earlier).

AFAIK the bug affects only those scripts that place their code under a
__DATA__ or __END__ marker.
If you do that and you have, in your code, some symbol (such as __symbol__
in the above examples, that's *not* a marker) that begins and ends with a
double underscore, then you need to ensure that whenever that symbol appears
on a line by itself, it is not immediately followed by a newline.
If the symbol never appears on a line by itself then (as of 0.52_01) you
have nothing to worry about.
If the symbol is never followed immediately by a newline, then you have
nothing to worry about.
If you don't place your code under a __DATA__ or __END__ marker then you
have nothing to worry about.
If you don't have symbols in your code that begin and end with double
underscores, then you have nothing to worry about.

So ... the conditions under which you can be bitten by this bug are quite
limited.

I guess we could make them even more limited ... I don't see any need to
rush into doing that. (Last thing I want to do is create breakage on a grand
scale.)

Thanks to Chris Nighswonger and Stefan Seifert for their assistance with
this.

It would be good if people could check that this change doesn't break other
Inline::* module test suites. (I've checked Inline-CPP-0.42, but no others.)

Cheers,
Rob

From: Chris Nighswonger On Tue, Apr 9, 2013 at 6:48 PM, <sisyphus1@optusnet.com.au> wrote:

>
>
> Thanks for pursuing this, Chris, Stefan.
>
>
Many thanks to Stefan for helping me along and to Rob for fixing things up.

Kind Regards,
Chris

From: sisyphus1
From: Chris Nighswonger

> This fixes the problem! Fantastic!

>> It's possibly a little convoluted at the moment ... maybe someone can
>> improve on that.
>
> Is there any case where the marker would not be on a line by itself?

If it's not on a line by itself, it will be deemed to *not* be a marker.
If it matches /__\S+?__\n/ and is on a line by itself, it *will* be regarded
as a marker.

There is therefore still an opening (in Inline::C, at least) to break
Inline.

Even after the alteration to sub read_DATA has been made, this Inline::C
code is still broken:

void foo() {
printf ("%d\n",
__MINGW32__
+ 7);
}

Similarly, if it's valid python to rewrite

return __version__

as

return
__version__

then Inline::Python would still be broken by the latter.

I reckon it's probably a real can of worms to try and fix that - so I'll
just leave it as is (until someone complains, anyway).
I think we would have to start checking for matches against known markers
(__C__, __Python__, etc.) as you originally suggested. Even then there would
be nothing to stop me from breaking Inline::C by defining a symbol named
__Python__ (or __CPP__, etc.) and using that symbol in my Inline::C code.

Hopefully, everyone writes their code *across* the page, not *down* the page
!!

> If not perhaps we could just do such as
>
> @{$DATA{$pkg}} = split /(?m)^(__\S+?__\n)/, $data;
>
> and eliminate the need to remove whitespace?

In the past, Inline has removed the whitespace that precedes the marker -
and it performs a check to verify that the whitespace has been removed.
So ... we need to remove the whitespace to satisfy that check.
(Alternatively, I could rewrite the check, but I think it's safer to stick
to the original formatting rules.)

In fact, in the past, Inline has removed everything (not just whitespace)
that precedes the marker on the line. So, in the past, you should have been
able to write:

__DATA__
some arbitrary stuff __Python__
......

Inline would then remove the " some arbitrary stuff " that precedes the
__Python__ marker.

This will no longer be the case. If the marker is preceded by anything other
than whitespace, it will be regarded as not being a marker.
So .... if anyone has been preceding the marker with anything other than
whitespace, they'll find their code broken.
Surely, no-one has been doing that ?

Anyway, I'll chew things over for a day or two - wait and see if there's any
other thoughts on what ought to be done.
Then I'll upload a 0.52_01 release that contains this amendment to
Inline.pm. (I'll let the list know when that happens.)

Thanks for pursuing this, Chris, Stefan.

Cheers,
Rob

From: Chris Nighswonger On Tue, Apr 9, 2013 at 4:15 AM, <sisyphus1@optusnet.com.au> wrote:

>
> -----Original Message----- From: sisyphus1@optusnet.com.au
> Sent: Tuesday, April 09, 2013 12:44 PM
> To: Chris Nighswonger ; inline@perl.org
>
> Subject: Re: Using Inline Python to import Python vars
>
>
>
> -----Original Message----- From: Chris Nighswonger
>
> @{$DATA{$pkg}} = split /(?m)(__\S+?__\n)/, $data;
>>
>
> Try replacing that line (in Inline.pm) with:
>
> #warn "\n########\n\$data:\n$data\n#**#######\n";
> @{$DATA{$pkg}} = split /(?m)(\n[ \t]{0,}__\S+?__\n)/, $data;
> for(@{$DATA{$pkg}}) {$_ = (split /\s/, $_)[-1] . "\n" if $_ =~
> /^\s{0,}__\S+?__\n$/} # remove any whitespace that precedes marker
> #warn "\n########\n", scalar(@{$DATA{$pkg}}), "\n";l
> #for(@{$DATA{$pkg}}) {warn ">>$_<<\n"}
>
> It's only 2 lines of code - the (commented out) warnings might be useful
> if things go awry. They won't appear in the final version of Inline.pm.
>
> That works ok for my failing Inline::C script, and without causing any of
> the Inline tests in the Inline-0.52 test suite to fail.
> I'm hopeful it will do the trick for your Inline::Python script, too.
>
>
This fixes the problem! Fantastic!


> It's possibly a little convoluted at the moment ... maybe someone can
> improve on that.
>

Is there any case where the marker would not be on a line by itself? If not
perhaps we could just do such as

@{$DATA{$pkg}} = split /(?m)^(__\S+?__\n)/, $data;

and eliminate the need to remove whitespace?

Kind Regards,
Chris

From: Chris Nighswonger Hi Rob,

On Tue, Apr 9, 2013 at 4:15 AM, <sisyphus1@optusnet.com.au> wrote:

>
>
> -----Original Message----- From: sisyphus1@optusnet.com.au
> Sent: Tuesday, April 09, 2013 12:44 PM
> To: Chris Nighswonger ; inline@perl.org
>
> Subject: Re: Using Inline Python to import Python vars
>
>
> -----Original Message----- From: Chris Nighswonger
>
> @{$DATA{$pkg}} = split /(?m)(__\S+?__\n)/, $data;
>>
>
> Try replacing that line (in Inline.pm) with:
>
> #warn "\n########\n\$data:\n$data\n#**#######\n";
> @{$DATA{$pkg}} = split /(?m)(\n[ \t]{0,}__\S+?__\n)/, $data;
> for(@{$DATA{$pkg}}) {$_ = (split /\s/, $_)[-1] . "\n" if $_ =~
> /^\s{0,}__\S+?__\n$/} # remove any whitespace that precedes marker
> #warn "\n########\n", scalar(@{$DATA{$pkg}}), "\n";l
> #for(@{$DATA{$pkg}}) {warn ">>$_<<\n"}
>
> It's only 2 lines of code - the (commented out) warnings might be useful
> if things go awry. They won't appear in the final version of Inline.pm.
>
> That works ok for my failing Inline::C script, and without causing any of
> the Inline tests in the Inline-0.52 test suite to fail.
> I'm hopeful it will do the trick for your Inline::Python script, too.
>
> It's possibly a little convoluted at the moment ... maybe someone can
> improve on that.
>

I'll be out of the office most of the day today, but will try this out
later this afternoon/evening and post back.

Kind Regards,
Chris

From: sisyphus1

-----Original Message-----
From: sisyphus1@optusnet.com.au
Sent: Tuesday, April 09, 2013 12:44 PM
To: Chris Nighswonger ; inline@perl.org
Subject: Re: Using Inline Python to import Python vars



-----Original Message-----
From: Chris Nighswonger

> @{$DATA{$pkg}} = split /(?m)(__\S+?__\n)/, $data;

Try replacing that line (in Inline.pm) with:

#warn "\n########\n\$data:\n$data\n########\n";
@{$DATA{$pkg}} = split /(?m)(\n[ \t]{0,}__\S+?__\n)/, $data;
for(@{$DATA{$pkg}}) {$_ = (split /\s/, $_)[-1] . "\n" if $_ =~
/^\s{0,}__\S+?__\n$/} # remove any whitespace that precedes marker
#warn "\n########\n", scalar(@{$DATA{$pkg}}), "\n";l
#for(@{$DATA{$pkg}}) {warn ">>$_<<\n"}

It's only 2 lines of code - the (commented out) warnings might be useful if
things go awry. They won't appear in the final version of Inline.pm.

That works ok for my failing Inline::C script, and without causing any of
the Inline tests in the Inline-0.52 test suite to fail.
I'm hopeful it will do the trick for your Inline::Python script, too.

It's possibly a little convoluted at the moment ... maybe someone can
improve on that.

Cheers,
Rob

From: sisyphus1

-----Original Message-----
From: Chris Nighswonger
Sent: Tuesday, April 09, 2013 6:39 AM
To: inline@perl.org
Subject: Re: Using Inline Python to import Python vars

>
> So it does look as though the DATA splitting algorithm is a bit "loose."
>
> In Inline.pm abt line 354:
>
> @{$DATA{$pkg}} = split /(?m)(__\S+?__\n)/, $data;
> shift @{$DATA{$pkg}} unless ($ {$DATA{$pkg}}[0] || '') =~
> /__\S+?__\n/;
> }
>
> It appears we split on anything prefixed and suffixed with double
> underscores.
>

A newline (immediately after the closing __) is also needed before any
splitting takes place:

######################
use warnings;

$data = "__DATA__ __C__ __other__ __Python__\n__version__";
@stuff = split /(?m)(__\S+?__\n)/, $data;

print ">>$_<<\n" for @stuff;
######################

Outputs:
>>__DATA__ __C__ __other__ <<
>>__Python__
<<
>>__version__<<

I can get the same type of failure with this (non-portable) Inline::C
script:

######################
use strict;
use warnings;

use Inline C => 'DATA';

foo();

1;

__DATA__

__C__

void foo() {
printf("%d %s\n",__MINGW32__
,"Hello");
}
######################

However, there's no problem at all if I rewrite foo() as:

void foo() {
printf("%d %s\n",__MINGW32__,
"Hello");
}

Thanks for digging this up, Chris !!

I don't personally use the "__DATA__" approach.
I'll do some digging myself right now, and see if I can come up with a
simple improvement to the regex.
(All the better if someone else beats me to it.)

As a quick guess, perhaps we split only if there's nothing other than
whitespace between the previous newline and the opening double underscore.

In the meantime, if (in Python) it's permissible to add whitespace at the
end of a line, then adding a space after __version__ should do the trick
methinks.

Cheers,
Rob

From: Chris Nighswonger On Mon, Apr 8, 2013 at 4:25 PM, Chris Nighswonger <
cnighswonger@foundations.edu> wrote:

> On Mon, Apr 8, 2013 at 3:14 PM, Stefan Seifert <nine@detonation.org>wrote:
>
>> I've never used DATA file handles in Perl much less with Inline::Python,
>> so
>> I'm not exactly sure. But the debug output looks like the Python source
>> code
>> ends at __version__. So I guess, the code reading the DATA file processes
>> everything from __Python__ to the next marker and treats every word
>> enclosed
>> in double underscores as such marker.
>>
>
>

So it does look as though the DATA splitting algorithm is a bit "loose."

In Inline.pm abt line 354:

@{$DATA{$pkg}} = split /(?m)(__\S+?__\n)/, $data;
shift @{$DATA{$pkg}} unless ($ {$DATA{$pkg}}[0] || '') =~ /__\S+?__\n/;
}

It appears we split on anything prefixed and suffixed with double
underscores.

Assuming that I'm not way off here:

I'm guessing that this is because we really don't know whether this is C,
Java, Python, or FooBar?

Can we have the language extension pass in what it is and actually search
for that marker rather than for __ANYTHING__?

Could we actually check for some specific end-of-code-block maker? Say
'__EOI__' for "end-of-inline" or some such?

Kind Regards,
Chris

From: Chris Nighswonger On Mon, Apr 8, 2013 at 3:14 PM, Stefan Seifert <nine@detonation.org> wrote:

> Hi Chris,
> Using perl Makefile.PL -debug when building Inline::Python gives a good
> hint.
> With this flag it will print loads of information including Python source
> code
> it compiles to stderr.
>
>
Thanks for that valuable piece of information. I was wondering how to get
the XS foo to spit out the Printf's.


> I've never used DATA file handles in Perl much less with Inline::Python, so
> I'm not exactly sure. But the debug output looks like the Python source
> code
> ends at __version__. So I guess, the code reading the DATA file processes
> everything from __Python__ to the next marker and treats every word
> enclosed
> in double underscores as such marker.
>

I really should have thought to look at the compiled module. Here is what
it is:

namespace : %
classes : %
functions : @
pykota_version
filtered : <<EOV-

def pykota_version():
import pykota.version
return
EOV


Clearly the problem is exactly as you point out.

I'll see if I can fix it.

Kind Regards,
Chris

From: Stefan Seifert Hi Chris,

On Monday 08 April 2013 14:45:40 Chris Nighswonger wrote:

> > However, this code borks:
> > ...
> > __DATA__
> >
> > __Python__
> >
> > def pykota_version():
> > from pykota.version import __version__
> > return __version__
> >
> > The error is:
> > File "<string>", line 3
> >
> > from pykota.version import
> >
> > ^
> >
> > SyntaxError: invalid syntax

Using perl Makefile.PL -debug when building Inline::Python gives a good hint.
With this flag it will print loads of information including Python source code
it compiles to stderr.

This gives us:

py_eval: code:
def pykota_version():
from pykota.version import
py_eval: main_module=0x7fd023985be8
py_eval: globals=0x229aac0
py_eval: type=1
py_eval: context=257
File "<string>", line 3
from pykota.version import
^
SyntaxError: invalid syntax

I've never used DATA file handles in Perl much less with Inline::Python, so
I'm not exactly sure. But the debug output looks like the Python source code
ends at __version__. So I guess, the code reading the DATA file processes
everything from __Python__ to the next marker and treats every word enclosed
in double underscores as such marker.

Indeed, every other way of giving Python source code to Inline::Python seems
to work ok.

Regards,
Stefan

From: Chris Nighswonger On Mon, Apr 1, 2013 at 12:57 PM, Chris Nighswonger <
cnighswonger@foundations.edu> wrote:

> However, this code borks:
>
> use Inline Python => 'DATA',
> DIRECTORY => '/usr/share/webmin/pykota/.Inline/',
> NAME => 'PyKota::Test';
>
> print pykota_version();
> 1;
>
> __DATA__
>
> __Python__
>
> def pykota_version():
> from pykota.version import __version__
> return __version__
>
>
> The error is:
>
> File "<string>", line 3
> from pykota.version import
> ^
> SyntaxError: invalid syntax
> Error -- py_eval raised an exception at
> /usr/local/lib/perl/5.14.2/Inline/Python.pm line 177.
> INIT failed--call queue aborted.
>

So I threw together some C to see if the problem was with my Python syntax
in the context of Inline::Python. Below is what I did and it works as
expected.

Any suggestions as to where I'm going wrong here?

Kind Regards,
Chris



#include <Python.h>

main( ) {
PyObject *pstr, *pmod, *pdict;
Py_Initialize( );

pmod = PyImport_ImportModule("__main__");
pdict = PyModule_GetDict(pmod);
pstr = PyRun_String(
"def pykota_version():\n"
" from pykota.version import __version__\n"
" return __version__\n"
"print pykota_version()\n"
, Py_file_input, pdict, pdict);

if (!pstr) {
PyErr_Print();
exit (1);
}

Py_DECREF(pmod);
Py_DECREF(pstr);
}

From: sisyphus1

-----Original Message-----
From: Piyush Verma
Sent: Wednesday, April 03, 2013 10:28 PM
To: sisyphus1@optusnet.com.au
Cc: inline@perl.org
Subject: Re: Hitting issue of Inline::Config existance


> I checked with Inline directory Inline:Config is not present.
> [root@prome-2s-dhcp82 5.10.0]# perl -MInline::Config -le
> 'for(keys(%INC)){print "$_: $INC{$_}"}'
> Can't locate Inline/Config.pm in @INC (@INC contains: /root/workspace/vtaf
> /usr/local/lib/perl5/5.10.0/i686-linux-thread-multi-64int
> /usr/local/lib/perl5/5.10.0
> /usr/local/lib/perl5/site_perl/5.10.0/i686-linux-thread-multi-64int
> /usr/local/lib/perl5/site_perl/5.10.0 .).
> BEGIN failed--compilation aborted.
>
>
> Could there be any other reason of this issue/ or at run time this module
> is generate while running the code.

This script demonstrates that Inline::Config does not have to be loaded for
%main::Inline::Config:: to be true:

#######################################
#!perl

$Inline::Config::some{'key'} = 'val';

if(%main::Inline::Config::) {
for(keys(%main::Inline::Config::)) {
print "$_\n";
}
}

#######################################

For me, that outputs:
some

So ... let's see the keys your %main::Inline::Config:: contains.
Find the lib/auto/Inline/check_config_file.al that was installed and, in
that file, just before the line:

croak M14_usage_Config() if %main::Inline::Config::;

insert this code (from above script):

if(%main::Inline::Config::) {
for(keys(%main::Inline::Config::)) {
print "$_\n";
}
}

Then run your troublesome script, and see if we can make any sense of the
keys that are reported.

(At this stage I have absolutely no idea what the problem is.)

Cheers,
Rob

From: Piyush Verma Hi,

Please find below the answer of above questions:-
>>> What OS are you using ? ... which versions of Inline and Inline::Java ?
... and which version of perl ?
[root@prome-2s-dhcp82 5.10.0]# cat /proc/version
Linux version 2.6.18-348.3.1.el5 (mockbuild@builder17.centos.org) (gcc
version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:40:14 EDT
2013
[root@prome-2s-dhcp82 5.10.0]# perl -MInline -e 'print "$Inline::VERSION\n"'
0.46
[root@prome-2s-dhcp82 5.10.0]# perl -MInline::Java -e 'print
"$Inline::Java::VERSION\n"'
0.52
[root@prome-2s-dhcp82 5.10.0]# perl -v

This is perl, v5.10.0 built for i686-linux-thread-multi-64int

Copyright 1987-2007, Larry Wall

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.



I checked with Inline directory Inline:Config is not present.
[root@prome-2s-dhcp82 5.10.0]# perl -MInline::Config -le
'for(keys(%INC)){print "$_: $INC{$_}"}'
Can't locate Inline/Config.pm in @INC (@INC contains: /root/workspace/vtaf
/usr/local/lib/perl5/5.10.0/i686-linux-thread-multi-64int
/usr/local/lib/perl5/5.10.0
/usr/local/lib/perl5/site_perl/5.10.0/i686-linux-thread-multi-64int
/usr/local/lib/perl5/site_perl/5.10.0 .).
BEGIN failed--compilation aborted.


Could there be any other reason of this issue/ or at run time this module
is generate while running the code.


Regards,
Piyush



On Wed, Apr 3, 2013 at 10:23 AM, <sisyphus1@optusnet.com.au> wrote:

>
>
> -----Original Message----- From: Piyush Verma
> Sent: Tuesday, April 02, 2013 3:27 PM
> To: inline@perl.org
> Subject: Hitting issue of Inline::Config existance
>
> Hi,
>>
>> I am hitting issue.
>> *
>> *
>> * Failed to load Inline Java:As of Inline v0.30, use of the Inline::Config
>> module is no longer supported*
>> *or allowed. If Inline::Config exists on your system, it can be removed.
>> See
>> *
>> *the Inline documentation for information on how to configure Inline.*
>> *(You should find it much more straightforward than Inline::Config :-)*
>>
>
> Wow - ancient history. I didn't know there ever was an Inline::Config
> module.
>
>
> Please let me know where to find Inline::Config, to resolve this issue.
>>
>
> Relative to where Inline.pm is installed, you would find this Config.pm in
> the ./Inline folder.
> But maybe something else is going on - surely, you cannot be using
> Inline-0.26 or earlier.
>
>
> Please point out if there is any other way of resolving this issue.
>>
>
> The error comes about from this line of code (in version 0.52 of
> Inline.pm):
>
> croak M14_usage_Config() if %main::Inline::Config::;
>
> So, for you, %main::Inline::Config:: is returning true. I guess that means
> Inline::Config got loaded. (Can it mean anything else ?)
>
> What do you get when you run:
>
> perl -MInline::Config -le 'for(keys(%INC)){print "$_: $INC{$_}"}'
>
> That should give at least confirm whether (and where) Inline::Config is to
> be found.
>
> NOTE:
> If you're on MS Windows, you need to instead run:
> perl -MInline::Config -le "for(keys(%INC)){print \"$_: $INC{$_}\"}"
>
> What OS are you using ? ... which versions of Inline and Inline::Java ?
> ... and which version of perl ?
>
> Cheers,
> Rob
>
>


--
*Piyush Verma*

From: sisyphus1

-----Original Message-----
From: Piyush Verma
Sent: Tuesday, April 02, 2013 3:27 PM
To: inline@perl.org
Subject: Hitting issue of Inline::Config existance

> Hi,
>
> I am hitting issue.
> *
> *
> * Failed to load Inline Java:As of Inline v0.30, use of the Inline::Config
> module is no longer supported*
> *or allowed. If Inline::Config exists on your system, it can be removed.
> See
> *
> *the Inline documentation for information on how to configure Inline.*
> *(You should find it much more straightforward than Inline::Config :-)*

Wow - ancient history. I didn't know there ever was an Inline::Config
module.

> Please let me know where to find Inline::Config, to resolve this issue.

Relative to where Inline.pm is installed, you would find this Config.pm in
the ./Inline folder.
But maybe something else is going on - surely, you cannot be using
Inline-0.26 or earlier.

> Please point out if there is any other way of resolving this issue.

The error comes about from this line of code (in version 0.52 of Inline.pm):

croak M14_usage_Config() if %main::Inline::Config::;

So, for you, %main::Inline::Config:: is returning true. I guess that means
Inline::Config got loaded. (Can it mean anything else ?)

What do you get when you run:

perl -MInline::Config -le 'for(keys(%INC)){print "$_: $INC{$_}"}'

That should give at least confirm whether (and where) Inline::Config is to
be found.

NOTE:
If you're on MS Windows, you need to instead run:
perl -MInline::Config -le "for(keys(%INC)){print \"$_: $INC{$_}\"}"

What OS are you using ? ... which versions of Inline and Inline::Java ? ...
and which version of perl ?

Cheers,
Rob

From: Piyush Verma Hi,

I am hitting issue.
*
*
* Failed to load Inline Java:As of Inline v0.30, use of the Inline::Config
module is no longer supported*
*or allowed. If Inline::Config exists on your system, it can be removed. See
*
*the Inline documentation for information on how to configure Inline.*
*(You should find it much more straightforward than Inline::Config :-)*

Please let me know where to find Inline::Config, to resolve this issue.
Please point out if there is any other way of resolving this issue.

Coding design I am using:-
I have written a wrapper of Inline Java which calls method Inline.
If any module want to use java method, it first load inline java.
(ps x|grep inlineJava and get port number if already running otherwise
start new inline java server in new port.)

I am using thread programming also in my project and this issue is coming
after thread module is successfully executed. After that I am not able to
load inline java.

--
*Piyush Verma*

From: Chris Nighswonger I seem to be misunderstanding something about importing Python package vars
with Inline. I'm thinking it may be some syntax problem.

This code returns the value of __version__ as expected:

use Inline Python => "from pykota.version import __version__; print
__version__;";



However, this code borks:

use Inline Python => 'DATA',
DIRECTORY => '/usr/share/webmin/pykota/.Inline/',
NAME => 'PyKota::Test';

print pykota_version();
1;

__DATA__

__Python__

def pykota_version():
from pykota.version import __version__
return __version__


The error is:

File "<string>", line 3
from pykota.version import
^
SyntaxError: invalid syntax
Error -- py_eval raised an exception at
/usr/local/lib/perl/5.14.2/Inline/Python.pm line 177.
INIT failed--call queue aborted.

Kind Regards,
Chris

From: Matthew Persico Wow. InlineX::C2XS is exactly what I want. Then I could reconstitute the
Devel::PL_ origargv as an XS module. If the author is unwilling, then I
could upload Devel::PL_origargvXS; not like that hasn't been done before.

Thanks. I'll keep you informed

On Friday, March 22, 2013, David Mertens wrote:

> What Rob suggested will work. Furthermore, if you manage to run your
> module like this during the build stage, you can use this approach to build
> your XS at build time. It'll work because the paths here are relative.
>
> However, due to cross-architecture concerns, Perl places binary module
> material in platform-specific directories. The approach Rob suggests
> side-steps this machinery and makes your module less robust. InlineX::C2XS
> is probably the better solution.
>
> David
> On Mar 22, 2013 4:51 AM, <sisyphus1@optusnet.com.au <javascript:_e({},
> 'cvml', 'sisyphus1@optusnet.com.au');>> wrote:
>
>> Hi Matthew,
>>
>> Like David, I'd probably go for using XS .
>> Unlike David, I'd use InlineX::C2XS to generate that XS file.
>>
>> If you really want to stick with Inline::C, something like this works for
>> me (on Win32):
>>
>> ##########################
>> package Some::FOO;
>>
>> BEGIN{
>> our $dir = $INC{'Some/FOO.pm'};
>> $dir =~ s/FOO\.pm\b//i;
>>
>> unless (-d "$dir/my_inline_build") {
>> mkdir "$dir/my_inline_build";
>> }
>>
>> };
>>
>> use Inline C => Config =>
>> DIRECTORY => "$dir/my_inline_build",
>> BUILD_NOISY => 1;
>>
>> use Inline C => <<'EOC';
>>
>> void greet() {
>> printf("Hello World\n");
>> }
>>
>> EOC
>>
>> $FOO::VERSION = 1.5;
>>
>> 1;
>> ##########################
>>
>> That will use the my_inline_build directory (which is located in the same
>> folder as Some/FOO.pm) for the Inline build directory.
>> And that will be the Inline build directory irrespective of what the
>> current working directory is.
>>
>> However, some considerations:
>>
>> 1) The my_inline_build directory needs to be in existence *before* Inline
>> is loaded. If it doesn't already exist, you could have
>> File::Path::make_path() create it (in the very same BEGIN{} block that has
>> determined the value for $dir). I've just used mkdir() as I know that's all
>> I need for my chose build directory.
>>
>> 2) The file path separator (in the above example it's a forward slash)
>> can change from one platform to another. That complicates things a bit when
>> it comes to examining %INC correctly ( and specifying directories) across
>> different platforms.
>>
>> Hope there's something there that helps.
>>
>> Cheers,
>> Rob
>>
>> -----Original Message----- From: Matthew Persico
>> Sent: Friday, March 22, 2013 3:27 AM
>> To: inline@perl.org <javascript:_e({}, 'cvml', 'inline@perl.org');>
>> Subject: Eliminating Inline
>>
>> Greetings.
>>
>> This is probably an RTFM, but I can't seem to find it in the FM.
>>
>> I want to use PL::origargv in the next version of Devel::ptkdb. I don't
>> want _Inline dirs all over the place for each person running the debugger.
>> I don't (for political reasons) want to set PERL_INLINE_DIRECTORY.
>>
>> What I want to do is force the _Inline for PL::origargv to be in
>> Devel:;ptkdb's installed directory tree when used by Devel:;ptkdb.
>>
>> Would my best bet be to cut n paste PL::origargv into Devel::ptkdb and
>> turn
>> THAT into an inline c consumer, setting and appropriate _Inline dir that
>> will be used by all?
>>
>> Could I get that dir created by the ptkdb installation somehow instead of
>> waiting for first use?
>>
>> Thanks
>>
>>
>> --
>> Matthew O. Persico
>>
>

--
Matthew O. Persico

From: David Mertens What Rob suggested will work. Furthermore, if you manage to run your module
like this during the build stage, you can use this approach to build your
XS at build time. It'll work because the paths here are relative.

However, due to cross-architecture concerns, Perl places binary module
material in platform-specific directories. The approach Rob suggests
side-steps this machinery and makes your module less robust. InlineX::C2XS
is probably the better solution.

David
On Mar 22, 2013 4:51 AM, <sisyphus1@optusnet.com.au> wrote:

> Hi Matthew,
>
> Like David, I'd probably go for using XS .
> Unlike David, I'd use InlineX::C2XS to generate that XS file.
>
> If you really want to stick with Inline::C, something like this works for
> me (on Win32):
>
> ##########################
> package Some::FOO;
>
> BEGIN{
> our $dir = $INC{'Some/FOO.pm'};
> $dir =~ s/FOO\.pm\b//i;
>
> unless (-d "$dir/my_inline_build") {
> mkdir "$dir/my_inline_build";
> }
>
> };
>
> use Inline C => Config =>
> DIRECTORY => "$dir/my_inline_build",
> BUILD_NOISY => 1;
>
> use Inline C => <<'EOC';
>
> void greet() {
> printf("Hello World\n");
> }
>
> EOC
>
> $FOO::VERSION = 1.5;
>
> 1;
> ##########################
>
> That will use the my_inline_build directory (which is located in the same
> folder as Some/FOO.pm) for the Inline build directory.
> And that will be the Inline build directory irrespective of what the
> current working directory is.
>
> However, some considerations:
>
> 1) The my_inline_build directory needs to be in existence *before* Inline
> is loaded. If it doesn't already exist, you could have
> File::Path::make_path() create it (in the very same BEGIN{} block that has
> determined the value for $dir). I've just used mkdir() as I know that's all
> I need for my chose build directory.
>
> 2) The file path separator (in the above example it's a forward slash) can
> change from one platform to another. That complicates things a bit when it
> comes to examining %INC correctly ( and specifying directories) across
> different platforms.
>
> Hope there's something there that helps.
>
> Cheers,
> Rob
>
> -----Original Message----- From: Matthew Persico
> Sent: Friday, March 22, 2013 3:27 AM
> To: inline@perl.org
> Subject: Eliminating Inline
>
> Greetings.
>
> This is probably an RTFM, but I can't seem to find it in the FM.
>
> I want to use PL::origargv in the next version of Devel::ptkdb. I don't
> want _Inline dirs all over the place for each person running the debugger.
> I don't (for political reasons) want to set PERL_INLINE_DIRECTORY.
>
> What I want to do is force the _Inline for PL::origargv to be in
> Devel:;ptkdb's installed directory tree when used by Devel:;ptkdb.
>
> Would my best bet be to cut n paste PL::origargv into Devel::ptkdb and turn
> THAT into an inline c consumer, setting and appropriate _Inline dir that
> will be used by all?
>
> Could I get that dir created by the ptkdb installation somehow instead of
> waiting for first use?
>
> Thanks
>
>
> --
> Matthew O. Persico
>