perl.inline

perl.inline http://www.nntp.perl.org/group/perl.inline/ ... Copyright 1998-2013 perl.org Sun, 26 May 2013 07:27:30 +0000 ask@perl.org Re: [rt.cpan.org #85336] Fails often when tested in parallel by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4456.html Wed, 22 May 2013 19:32:52 +0000 [rt.cpan.org #85336] Fails often when tested in parallel by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4455.html Sun, 19 May 2013 05:37:50 +0000 Re: Inline::CPP v0.44: Implement flocking by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4454.html Sun, 19 May 2013 02:15:11 +0000 Re: Inline::CPP v0.44: Implement flocking by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4453.html Sat, 18 May 2013 15:44:18 +0000 Re: [rt.cpan.org #85336] Fails often when tested in parallel by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4452.html Sat, 18 May 2013 15:23:58 +0000 Re: [rt.cpan.org #85336] Fails often when tested in parallel by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4451.html Sat, 18 May 2013 14:41:00 +0000 Re: Inline::CPP v0.44: Implement flocking by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4450.html Sat, 18 May 2013 09:00:49 +0000 [rt.cpan.org #85336] Fails often when tested in parallel by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4449.html Sat, 18 May 2013 06:20:47 +0000 Inline::CPP v0.44: Implement flocking by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4448.html Sat, 18 May 2013 05:07:11 +0000 Re: Inline RT #85336 (Race Condition) by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4447.html Fri, 17 May 2013 15:36:20 +0000 Inline RT #85336 (Race Condition) by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4446.html Thu, 16 May 2013 04:16:05 +0000 [rt.cpan.org #85336] Fails often when tested in parallel by 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, http://www.nntp.perl.org/group/perl.inline/2013/05/msg4445.html Thu, 16 May 2013 03:11:25 +0000 [rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4444.html Thu, 09 May 2013 02:45:19 +0000 Inline::CPP v0.43 released by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4443.html Sat, 04 May 2013 15:12:52 +0000 Inline-0.53 released by 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 http://www.nntp.perl.org/group/perl.inline/2013/05/msg4442.html Wed, 01 May 2013 08:49:56 +0000 Inline::CPP v0.42_002(dev) uploaded to CPAN by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4441.html Wed, 24 Apr 2013 07:20:11 +0000 Inline-0.52_02 released by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4440.html Wed, 24 Apr 2013 05:15:16 +0000 [rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4439.html Wed, 24 Apr 2013 03:49:30 +0000 [rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4438.html Sat, 20 Apr 2013 11:06:28 +0000 [rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug by 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. http://www.nntp.perl.org/group/perl.inline/2013/04/msg4437.html Sat, 20 Apr 2013 08:43:58 +0000 [rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug by 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; } http://www.nntp.perl.org/group/perl.inline/2013/04/msg4436.html Sat, 20 Apr 2013 06:53:18 +0000 Inline-0.52_01 released to CPAN by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4435.html Thu, 11 Apr 2013 06:38:35 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4434.html Tue, 09 Apr 2013 23:29:43 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4433.html Tue, 09 Apr 2013 22:49:30 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4432.html Tue, 09 Apr 2013 19:29:29 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4431.html Tue, 09 Apr 2013 10:36:24 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4430.html Tue, 09 Apr 2013 08:16:06 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4429.html Tue, 09 Apr 2013 02:45:26 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4428.html Mon, 08 Apr 2013 20:39:47 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4427.html Mon, 08 Apr 2013 20:26:10 +0000 Re: Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4426.html Mon, 08 Apr 2013 19:15:16 +0000 Re: Using Inline Python to import Python vars by 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); } http://www.nntp.perl.org/group/perl.inline/2013/04/msg4425.html Mon, 08 Apr 2013 18:46:13 +0000 Re: Hitting issue of Inline::Config existance by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4424.html Thu, 04 Apr 2013 07:15:32 +0000 Re: Hitting issue of Inline::Config existance by 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* http://www.nntp.perl.org/group/perl.inline/2013/04/msg4423.html Wed, 03 Apr 2013 11:28:21 +0000 Re: Hitting issue of Inline::Config existance by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4422.html Wed, 03 Apr 2013 04:53:42 +0000 Hitting issue of Inline::Config existance by 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* http://www.nntp.perl.org/group/perl.inline/2013/04/msg4421.html Tue, 02 Apr 2013 16:45:17 +0000 Using Inline Python to import Python vars by 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 http://www.nntp.perl.org/group/perl.inline/2013/04/msg4420.html Mon, 01 Apr 2013 16:57:48 +0000 [rt.cpan.org #84181] Akses internet broadband - Upload Extreme by marketing via RT Sun Mar 24 21:30:39 2013: Request 84181 was acted upon. Transaction: Ticket created by marketing@bagusnet.net.id Queue: Inline Subject: Akses internet broadband - Upload Extreme Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: marketing@bagusnet.net.id Status: new Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84181 > Dengan Hormat, All Customer, Sebelumnya Kami ucapkan terima kasih atas kesempatan yang telah diberikan. Ijinkan lah kami memperkenalkan diri. Kami adalah PT. Borneo Broadband Technology â Bagusnet, adalah perusahaan yang bergerak dalam bidang Sistem Integrator dan Internet Service Provider menawarkan layanan kami, berupa IT solution, akses internet berkecepatan tinggi dan produk-produk network wire maupun wireless yang di dukung oleh principal kami. Pada kesempatan ini kami bermaksud untuk menawarkan bantuan solusi kepada perusahaan anda, dimana banyak terdapat kantor cabang yang mau dihubungkan dengan kantor pusat. Link yang kami hubungkan dengan menggunakan radio link ini sangat diperlukan untuk: Mengirimkan Data, Fax, Voice, maupun Gambar Video (CCTV) pada sebuah infrastruktur jaringan berbasis IP untuk perusahaan dengan lokasi yang tersebar baik di dalam maupun diluar pulau kalimantan (Memudahkan akses data antar cabang dengan kantor pusat). Dengan beberapa alternatif kecepatan akses, jasa IP ini dapat digunakan baik oleh perusahaan dengan skala kecil, menengah, maupun besar. Akan menurunkan biaya komunikasi secara signifikan dibandingkan dengan teknologi tradisional yang umum digunakan oleh perusahaan saat ini. Efisiensi budget untuk komunikasi antar cabang (Telp/Fax) dengan komunikasi VOIP gratis melalui jaringan IP. VOIP dapat dikembangkan untuk koneksi antar ruangan dengan menambahkan PABX. Instalasi dan maintenance dilakukan oleh tenaga ahli kami yang memang sudah berpengalaman di bidang radio link ini. sehingga pelanggan akan mendapatkan lebih banyak efisiensi budget. Bersama ini juga kami ingin memperkenalkan produk kami yaitu akses internet broadband : Upload Extreme Pilihan Paket: 1. Upload 2 Mbps Single, - Maximum Upload = ut 2 Mbps - Maximum Download = ut 1 Mbps - Gratis email : namapelanggan@bagusnet.net.id (50 MB x 5 account email) = Rp660.000 / bulan 2. Upload 3 Mbps Double, - Maximum Upload = ut 3 Mbps - Maximum Download = ut 2 Mbps - Gratis email : namapelanggan@bagusnet.net.id (50 MB x 5 account email) = Rp990.000 / bulan Biaya Setup: a. Registrasi & aktifasi = --- hubungi marketing kami --- b. Instalasi Perangkat WLAN = --- hubungi marketing kami --- c. Outdoor pipa monopole / tower triangle & STP Cable = --- (beradasarkan hasil survey ke lokasi) Perangkat WLAN (radio + antena + Adaptor + poe) dipinjamkan selama berlangganan, bila persediaan masih ada. Demikian kami sampaikan, apabila Bapak/ibu membutuhkan informasi lebih lanjut dapat menghubungi kami setiap saat. Atas perhatian dan kerjasamanya saya ucapkan terima kasih. wassalam, Internet Service Provider (ISP)- Bagusnet PT. Borneo Broadband Technology (BBT) Jl. K. S. Tubun No. 163 RT. 15, Kelurahan Pekauman Kecamatan Banjar Selatan, Kota Banjarmasin, Propinsi Kalimantan Selatan - 70243 Indonesia website = www.bagusnet.net.id Email = marketing2@bagusnet.net.id YM ID = bbt_bagusnet HP. Telkomsel = +62 813 4820 7813 HP. Indosat = +62 858 2817 7669 HP. XL = +62 878 1445 2624 / +62 878 1618 2524 (SMS Only) = +62 853 9329 7245 Telp. = +62 511 3265 327 / +62 511 3265 328 Fax. = +62 511 3265 329 --------------------------------------------------------------------------------------------------------------------------- Legal aspec PT. Borneo Broadband Technology, berdasarkan : Akte notaris no 528/BH/16-10/VI/2006 yang di perkuat dengan, Ijin departemen postel No. 197/DIRJEN/2008 (DEPKOMINFO), tergabung anggota APJII (Asosiasi Penyelenggaraan Jasa Internet Indonesia) sejak tahun 2007. --------------------------------------------------------------------------------------------------------------------------- Berminat jadi reseller internet ISP Bagusnet? setiap bulan dapat komisi insentif hingga juta-an rupiah dari pembayaran bulanan pelanggan yang di dapat. segera lah hubungi kami. --------------------------------------------------------------------------------------------------------------------------- Kami juga menyediakan peralatan jaringan komputer baik wire maupun wireless sekaligus pemasangan & instalasinya untuk penggunaan jaringan komputer bersama (LAN) dan aplikasi internet yang didukung banyak vendor sebagai berikut : > VoIP: 1. Internet Telephony Gateway / IP PABX 2. Internet Video Conferencing 3. VoIP Adapter > Wireless Application: 1. Wireless Access Point 2. Hot Spot Billing untuk cafÃ©, hotel dan public spot 3. Wireless Point to Point 4. Instalasi ( Setting dan Pointing ) > Network Solution: 1. Fiber Optik Interkoneksi 2. Switch Manage / Unmanage (1000/100/10 Mbps) 3. Router Mikrotik 4. Bandwith Management / Limiter 5. Server Application (WEB/Mail/Database) 6. Cable (UTP/STP/Fiber Optic) 7. VSAT C-Band & Ku-Band 8. Storage / Back up Solution 9. Rack Server 10. CCTV, IP-Cam 11. ADSL Telkom 12. Etc. http://www.nntp.perl.org/group/perl.inline/2013/03/msg4419.html Mon, 25 Mar 2013 01:30:51 +0000 Re: Eliminating Inline by 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 http://www.nntp.perl.org/group/perl.inline/2013/03/msg4418.html Fri, 22 Mar 2013 19:12:10 +0000 Re: Eliminating Inline by 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 > http://www.nntp.perl.org/group/perl.inline/2013/03/msg4417.html Fri, 22 Mar 2013 11:15:27 +0000