[jira] [Commented] (PROTON-810) Publish javascript binding on npm
[ https://issues.apache.org/jira/browse/PROTON-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14299841#comment-14299841 ] Fraser Adams commented on PROTON-810: - Matteo, I've made the changes to the package name and published qpid-proton-messenger to npm central. Publish javascript binding on npm - Key: PROTON-810 URL: https://issues.apache.org/jira/browse/PROTON-810 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.8 Environment: NodeJS Reporter: Matteo Murgida Labels: javascript, nodejs, npm Fix For: 0.9 It would be very useful to the nodejs community to have the javascript binding published on npm as qpid-proton. If you prefer, I can maintain that release for you :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-813) Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings.
Fraser Adams created PROTON-813: --- Summary: Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings. Key: PROTON-813 URL: https://issues.apache.org/jira/browse/PROTON-813 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Assignee: Fraser Adams Priority: Blocker It looks like some change in the ws WebSocket library in npm central has broken something. From what I've been able to ascertain it was the change between 0.5.0 and 0.6.0 where the issue lies (sometime around 5th December by the looks of it). TBH I probably should have been a bit more explicit with versions of dependencies, but I'm kind of learning with npm and rather making up as I go but I've now pushed a change to trunk https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git that pins the ws version to 0.5.0 for now. If you get bitten by this and don't want to update to the latest proton in trunk just yet it's fairly easy to sort out, the following should do the trick: cd proton-root rm -rf node_modules/ws npm install ws@0.5.0 It'll clearly be good to work out what has actually changed, but I'll need a bit of quality time to do more digging, it might be something in the binding code, but it *could* be something in the emscripten network code that has been borked, for now pinning the ws version seems the best approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-813) Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings.
[ https://issues.apache.org/jira/browse/PROTON-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams closed PROTON-813. --- Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings. --- Key: PROTON-813 URL: https://issues.apache.org/jira/browse/PROTON-813 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Assignee: Fraser Adams Priority: Blocker It looks like some change in the ws WebSocket library in npm central has broken something. From what I've been able to ascertain it was the change between 0.5.0 and 0.6.0 where the issue lies (sometime around 5th December by the looks of it). TBH I probably should have been a bit more explicit with versions of dependencies, but I'm kind of learning with npm and rather making up as I go but I've now pushed a change to trunk https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git that pins the ws version to 0.5.0 for now. If you get bitten by this and don't want to update to the latest proton in trunk just yet it's fairly easy to sort out, the following should do the trick: cd proton-root rm -rf node_modules/ws npm install ws@0.5.0 It'll clearly be good to work out what has actually changed, but I'll need a bit of quality time to do more digging, it might be something in the binding code, but it *could* be something in the emscripten network code that has been borked, for now pinning the ws version seems the best approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-813) Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings.
[ https://issues.apache.org/jira/browse/PROTON-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-813. - Resolution: Fixed Sorry - I should've raised this Jira *before* I fixed things for tracking purposes, my bad! Fixed here: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=e9db8dfba24646d17e7caf17c7e1fea3319cc603 Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings. --- Key: PROTON-813 URL: https://issues.apache.org/jira/browse/PROTON-813 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Assignee: Fraser Adams Priority: Blocker It looks like some change in the ws WebSocket library in npm central has broken something. From what I've been able to ascertain it was the change between 0.5.0 and 0.6.0 where the issue lies (sometime around 5th December by the looks of it). TBH I probably should have been a bit more explicit with versions of dependencies, but I'm kind of learning with npm and rather making up as I go but I've now pushed a change to trunk https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git that pins the ws version to 0.5.0 for now. If you get bitten by this and don't want to update to the latest proton in trunk just yet it's fairly easy to sort out, the following should do the trick: cd proton-root rm -rf node_modules/ws npm install ws@0.5.0 It'll clearly be good to work out what has actually changed, but I'll need a bit of quality time to do more digging, it might be something in the binding code, but it *could* be something in the emscripten network code that has been borked, for now pinning the ws version seems the best approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-774) Fix warnings in log.c and url.c and re-enable -Werror
Fraser Adams created PROTON-774:
---
Summary: Fix warnings in log.c and url.c and re-enable -Werror
Key: PROTON-774
URL: https://issues.apache.org/jira/browse/PROTON-774
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Fraser Adams
Priority: Trivial
The files log.c and url.c generate warnings when compiled with CLang/emscripten
this prevents -Werror being used.
The warnings were:
[ 56%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/log.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/log.c:38:13: warning: explicitly
assigning a variable of type 'bool' to itself [-Wself-assign]
enabled = enabled;
and
[ 58%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/url.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/url.c:133:19: warning: unused
function 'len' [-Wunused-function]
static inline int len(const char *str) { return str ? strlen(str) : 0; }
The trivial fixes were to remove the spurious function in url.c and rename the
formal parameter to pn_log_enable in log.c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-774) Fix warnings in log.c and url.c and re-enable -Werror
[
https://issues.apache.org/jira/browse/PROTON-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fraser Adams resolved PROTON-774.
-
Resolution: Fixed
Fix warnings in log.c and url.c and re-enable -Werror
-
Key: PROTON-774
URL: https://issues.apache.org/jira/browse/PROTON-774
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Fraser Adams
Priority: Trivial
The files log.c and url.c generate warnings when compiled with
CLang/emscripten this prevents -Werror being used.
The warnings were:
[ 56%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/log.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/log.c:38:13: warning:
explicitly
assigning a variable of type 'bool' to itself [-Wself-assign]
enabled = enabled;
and
[ 58%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/url.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/url.c:133:19: warning: unused
function 'len' [-Wunused-function]
static inline int len(const char *str) { return str ? strlen(str) : 0; }
The trivial fixes were to remove the spurious function in url.c and rename
the formal parameter to pn_log_enable in log.c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-760) Improve the JavaScript binding's internal Event loop and add additional tests
Fraser Adams created PROTON-760: --- Summary: Improve the JavaScript binding's internal Event loop and add additional tests Key: PROTON-760 URL: https://issues.apache.org/jira/browse/PROTON-760 Project: Qpid Proton Issue Type: Improvement Reporter: Fraser Adams Improve the JavaScript binding's internal Event loop and add additional tests. The addition of JavaScript soak/performance tests msgr-send.js and msgr-recv.js, which mirror tests of the same name in C and Python flagged up a few edge cases that caused sporadic failures. The problems seem to be related to the ws WebSocket library directly calling some callbacks rather than posting to the JavaScript internal Event queue. The effect of calling directly mean that the main message handler and the close handler could actually get called *concurrently* which is clearly a bad thing and somewhat undexpected in JavaScript. The improvements here add a number of guard tests and introduce a setTimeout that allows the real close handler to be deferred by posting it onto the Event queue. msgr-send and msgr-recv have been run with counts of several million messages and also with message sizes of up to 2MB and everything seems stable now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-662) decoder.c pn_decoder_decode_value has a test that won't correctly execute.
Fraser Adams created PROTON-662: --- Summary: decoder.c pn_decoder_decode_value has a test that won't correctly execute. Key: PROTON-662 URL: https://issues.apache.org/jira/browse/PROTON-662 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Fraser Adams Priority: Minor In decoder.c pn_decoder_decode_value there is a block of code: pn_type_t type = pn_code2type(acode); if (type 0) return type; The test will not execute correctly because pn_type_t is an unsigned enumeration. The reason for the test seems to be to trap the case where pn_code2type does: return (pn_type_t) PN_ARG_ERR; rather than returning the type. Compiling with Clang rather than gcc flags this warning (which prevents using warnings as errors with Clang): warning: comparison of unsigned enum expression 0 is always false [-Wtautological-compare] if (type 0) return type; ^ ~ Trivial fix is to use correct casting: if ((int)type 0) return (int)type; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-662) decoder.c pn_decoder_decode_value has a test that won't correctly execute.
[ https://issues.apache.org/jira/browse/PROTON-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-662. - Resolution: Fixed Added the correct casting. Now compiles cleanly on both gcc and Clang. decoder.c pn_decoder_decode_value has a test that won't correctly execute. -- Key: PROTON-662 URL: https://issues.apache.org/jira/browse/PROTON-662 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Fraser Adams Priority: Minor In decoder.c pn_decoder_decode_value there is a block of code: pn_type_t type = pn_code2type(acode); if (type 0) return type; The test will not execute correctly because pn_type_t is an unsigned enumeration. The reason for the test seems to be to trap the case where pn_code2type does: return (pn_type_t) PN_ARG_ERR; rather than returning the type. Compiling with Clang rather than gcc flags this warning (which prevents using warnings as errors with Clang): warning: comparison of unsigned enum expression 0 is always false [-Wtautological-compare] if (type 0) return type; ^ ~ Trivial fix is to use correct casting: if ((int)type 0) return (int)type; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-436) pn_data_dump is broken for complex types
[ https://issues.apache.org/jira/browse/PROTON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004965#comment-14004965 ] Fraser Adams commented on PROTON-436: - Aha - glad I spotted this Jiira, so I'm not going mad then :-) I was trying this out last weekend and wondering was it me or was this how it was supposed to work. pn_data_dump is broken for complex types Key: PROTON-436 URL: https://issues.apache.org/jira/browse/PROTON-436 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 0001-PROTON-436-pni_inspect_atom-can-do-better-than-asser.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-570) Missing Ruby gem dependencies result in a fatal error of Proton build.
Fraser Adams created PROTON-570: --- Summary: Missing Ruby gem dependencies result in a fatal error of Proton build. Key: PROTON-570 URL: https://issues.apache.org/jira/browse/PROTON-570 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Priority: Blocker I did an update to r1589121 and I'm getting a fatal build error when I do cmake .. in a clean build directory CMake Error at proton-c/bindings/ruby/CMakeLists.txt:21 (message): Ruby bindings cannot be tested while missing dependencies In my case I had -- Missing Ruby gem dependency: rspec -- Missing Ruby gem dependency: simplecov and installing those gems sorted the problem out, but I don't believe that missing dependencies for one of the language bindings should fatally stop the entire build. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-569) Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe
Fraser Adams created PROTON-569: --- Summary: Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe Key: PROTON-569 URL: https://issues.apache.org/jira/browse/PROTON-569 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Priority: Minor In messenger the pipe file descriptors are not initialised prior to the call to pn_pipe. In most cases this isn't an issue as the call to pipe should do something, however there is no check made for pn_pipe failing and indeed the control pipe/interrupt stuff is essentially not an essential part of messenger so that is reasonable. The issue I've seen though is for the JavaScript bindings I'm working on, in emscripten the pipe call essentially does nothing and just returns -1, the problem however is that the uninitialised pipe file descriptors are zero, in other words m-ctrl[0] = 0, which is the filedescriptor for stdin!!! I kept on getting PN_INTR errors until I worked out what was going on. See also https://github.com/kripken/emscripten/issues/2313 Simply doing m-ctrl[0] = -1; m-ctrl[1] = -1; before pn_pipe(m-io, m-ctrl); Makes things behave as expected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PROTON-569) Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe
[ https://issues.apache.org/jira/browse/PROTON-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-569. - Resolution: Fixed Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe Key: PROTON-569 URL: https://issues.apache.org/jira/browse/PROTON-569 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Priority: Minor In messenger the pipe file descriptors are not initialised prior to the call to pn_pipe. In most cases this isn't an issue as the call to pipe should do something, however there is no check made for pn_pipe failing and indeed the control pipe/interrupt stuff is essentially not an essential part of messenger so that is reasonable. The issue I've seen though is for the JavaScript bindings I'm working on, in emscripten the pipe call essentially does nothing and just returns -1, the problem however is that the uninitialised pipe file descriptors are zero, in other words m-ctrl[0] = 0, which is the filedescriptor for stdin!!! I kept on getting PN_INTR errors until I worked out what was going on. See also https://github.com/kripken/emscripten/issues/2313 Simply doing m-ctrl[0] = -1; m-ctrl[1] = -1; before pn_pipe(m-io, m-ctrl); Makes things behave as expected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-535) make docs results in several warnings and an error
Fraser Adams created PROTON-535: --- Summary: make docs results in several warnings and an error Key: PROTON-535 URL: https://issues.apache.org/jira/browse/PROTON-535 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Fraser Adams Priority: Minor When I tried make docs it mostly looks like it works but I saw several warnings: warning: ignoring unsupported tag `INLINE_SIMPLE_STRUCTS =' at line 313, file user.doxygen warning: ignoring unsupported tag `CITE_BIB_FILES =' at line 583, file user.doxygen warning: ignoring unsupported tag `MATHJAX_EXTENSIONS =' at line 1166, file user.doxygen warning: ignoring unsupported tag `LATEX_BIB_STYLE=' at line 1285, file user.doxygen warning: ignoring unsupported tag `INTERACTIVE_SVG=' at line 1699, file user.doxygen and Scanning dependencies of target docs-py +-- | In /home/fadams/qpid/qpid-trunk/proton/proton-c/bindings/python/ | proton.py: | Import failed (but source code parsing was successful). | Error: NameError: name 'PN_CONNECTION_STATE' is not defined (line |3292) | -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314 ] Fraser Adams commented on PROTON-488: - Oh to be clear either struct in and out, or separate size_t and char* in and out what I meant in my previous comment was that the separate size_t and char* in and out is what LLVM le32 is happiest with, the structs seem to confuse it, I hadn't realised that you'd changed your original patch to now do all 'z' encodings to be passed as a single pn_bytes_t struct and retrieved as a single pn_bytes_t struct - although this arguably looks neater I'd definitely prefer your first approach. Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883328#comment-13883328 ] Fraser Adams commented on PROTON-488: - For info I managed to pull out the bits that were affecting me as a cut down reproducer in a GitHub gist, you might notice something of a familiarity. https://gist.github.com/fadams/8315263 The pn_string_get_bytes(), was what caused me the pain (I tried retrieving the struct too but the only things that work were pushing up the separate parts of the struct or messing with the LLVM front end) I'd have preferred the former like your original patch but hadn't got round to doing that as I could work around it and I had a few other things to sort out. Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883472#comment-13883472 ] Fraser Adams commented on PROTON-488: - Hey Cliff, Re can you test if the review board patch (with the struct in and out strategy) works in your case with the unhacked llvm setup? - I could check it again, though it'll be a couple of days before I can get coding time to try it I'm afraid. I did actually try that approach out previously though on the off-chance - and it didn't work, the only two things that worked for me were passing the two basic types or messing with the LLVM front end. I've copied a link to the issue I raised on the emscripten mailing list on this, mainly for interest, but you'll note a painful similarity with what you've experienced :-D https://github.com/kripken/emscripten/issues/1988 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PROTON-465) FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection
Fraser Adams created PROTON-465: --- Summary: FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection Key: PROTON-465 URL: https://issues.apache.org/jira/browse/PROTON-465 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Environment: Ubuntu 11.10 (at least) Reporter: Fraser Adams Priority: Minor With Proton when I do cmake .. it barfs with -- Trying alternative search for Perl -- PerlLibs Not Found Though I can get it to play nicely by doing cmake .. -DPERL_LIBRARY=`locate -n 1 libperl.so` This might not be so unreasonable as I'm using a fairly old version of Ubuntu that needs upgrading, however the Perl detection on Qpid works perfectly well for me (and I'd assume for others too) which suggests that it's possibly more thorough. At the very least it would seem sensible to maintain consistency with the cmake modules across various Qpid components. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-465) FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection
[ https://issues.apache.org/jira/browse/PROTON-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams updated PROTON-465: Assignee: Darryl L. Pierce FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection Key: PROTON-465 URL: https://issues.apache.org/jira/browse/PROTON-465 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Environment: Ubuntu 11.10 (at least) Reporter: Fraser Adams Assignee: Darryl L. Pierce Priority: Minor With Proton when I do cmake .. it barfs with -- Trying alternative search for Perl -- PerlLibs Not Found Though I can get it to play nicely by doing cmake .. -DPERL_LIBRARY=`locate -n 1 libperl.so` This might not be so unreasonable as I'm using a fairly old version of Ubuntu that needs upgrading, however the Perl detection on Qpid works perfectly well for me (and I'd assume for others too) which suggests that it's possibly more thorough. At the very least it would seem sensible to maintain consistency with the cmake modules across various Qpid components. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-442) Running swig generates Warning(451): Setting a const char * variable may leak memory.
[ https://issues.apache.org/jira/browse/PROTON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-442. - Resolution: Fixed Running swig generates Warning(451): Setting a const char * variable may leak memory. --- Key: PROTON-442 URL: https://issues.apache.org/jira/browse/PROTON-442 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Fraser Adams Priority: Minor When building proton after doing cmake .. the make process is quite noisy generating a number of warnings that ought to be corrected. One such warning is: Warning(451): Setting a const char * variable may leak memory. This relates to the const char *bytes; in the pn_delivery_tag_t struct in engine.h The swig documentation in http://www.swig.org/Doc1.3/Warnings.html suggests how to suppress this warning (due to the way the code works I believe that it's safe to suppress this case) by doing: %warnfilter(451) pn_delivery_tag_t; in the various python.i, perl.i etc. I've make the changes locally and this indeed works. I'll put together a review board request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (PROTON-442) Running swig generates Warning(451): Setting a const char * variable may leak memory.
Fraser Adams created PROTON-442: --- Summary: Running swig generates Warning(451): Setting a const char * variable may leak memory. Key: PROTON-442 URL: https://issues.apache.org/jira/browse/PROTON-442 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Fraser Adams Priority: Minor When building proton after doing cmake .. the make process is quite noisy generating a number of warnings that ought to be corrected. One such warning is: Warning(451): Setting a const char * variable may leak memory. This relates to the const char *bytes; in the pn_delivery_tag_t struct in engine.h The swig documentation in http://www.swig.org/Doc1.3/Warnings.html suggests how to suppress this warning (due to the way the code works I believe that it's safe to suppress this case) by doing: %warnfilter(451) pn_delivery_tag_t; in the various python.i, perl.i etc. I've make the changes locally and this indeed works. I'll put together a review board request. -- This message was sent by Atlassian JIRA (v6.1#6144)
