On Wed, 2012-10-24 at 10:32 -0400, Rafael Schloming wrote:
I think this may be related to the cmake version. Can you guys run cmake
-version and tell me what it reports?
I think it's more likely missing quotes around a variable expansion that
in this case expands to nothing.
Andrew
On Wed, 2012-10-24 at 11:27 -0400, Rafael Schloming wrote:
According to the cmake docs for 2.6.x, the install (DIRECTORY ...) command
doesn't have the OPTIONAL argument. Any ideas on how to work around this?
Why not force the doc build? That's what I did with the qpid cmake build
- it's
On Wed, 2012-10-24 at 13:44 -0400, Rafael Schloming wrote:
On Wed, Oct 24, 2012 at 12:54 PM, Andrew Stitcher astitc...@redhat.comwrote:
...
How do you force the doc build?
As below.
I couldn't figure out how to add
dependencies between built-in and custom targets.
There is no way to do
On Wed, 2012-11-14 at 09:19 -0500, Mary Hinton wrote:
...
I'd like to share the status of the Windows port of the proton code.
...
In the meantime, I would like to have a public place to put the port so that
others can join in with the Windows version.
What is the best way to do this
On Tue, 2012-12-04 at 17:46 +, Phil Harvey wrote:
...
Linking C shared module _cproton.so
/usr/bin/ld: /usr/local/lib/python2.6/config/libpython2.6.a(abstract.o):
relocation R_X86_64_32 against `a local symbol' can not be used when making
a shared object; recompile with -fPIC
On Thu, 2012-11-29 at 17:16 -0500, Darryl L. Pierce wrote:
I've pushed the Perl language bindings as well as the send/recv examples
for using the qpid::proton::Messenger and qpid::proton::Message classes.
These changes break make install for a developer build installing in a
non system
On Wed, 2012-12-05 at 11:12 -0500, Rafael Schloming wrote:
On Wed, Dec 5, 2012 at 9:52 AM, Darryl L. Pierce dpie...@redhat.com wrote:
On Wed, Dec 05, 2012 at 08:18:06AM -0500, Darryl L. Pierce wrote:
It seems like this new stuff just ignores CMAKE_INSTALL_PREFIX.
Yeah, it appears
I've committed some portability work on proton today.
At this point, proton should configure and compile without error on
FreeBSD and MacOS X.
I've also done a bit of work which improves compilation under gcc on
Solaris too, but this isn't finished (Solaris is missing any
functionality to easily
On Wed, 2012-12-05 at 17:51 -0500, Rafael Schloming wrote:
On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce dpie...@redhat.com wrote:
I disagree:
There are two scenarios that we care about:
1. The install prefix of proton is the same as the install prefix of the
perl/php/etc.
In this case
On Thu, 2012-12-06 at 13:24 -0500, Rafael Schloming wrote:
...
The best way to cater to the developer scenario you mention is to simply
look at install_manifest.txt. This file is generated whenever you type make
install and will provide a much more accurate check on whether the install
is
On Thu, 2012-12-06 at 13:35 -0500, Andrew Stitcher wrote:
On Thu, 2012-12-06 at 13:24 -0500, Rafael Schloming wrote:
...
The best way to cater to the developer scenario you mention is to simply
look at install_manifest.txt. This file is generated whenever you type make
install
On Wed, 2012-12-12 at 14:22 +, Keith W wrote:
Hi all
We are having problems building proton-c on our dev boxes (Red Hat
Enterprise Linux Server release 5.3 (Tikanga)). I've done a git
bisect and discovered that it was Andrew's commit last Wednesday (rev
1417553) that has
+1
Tested on FreeBSD 9.1:
+ cproton builds with gcc
+ cproton tests clean with manual PYTHONPATH setup.
But there are some install caveats (but not enough imo to nack this release)
- by default make install puts the libraries in the wrong place for
freebsd (in /usr/local/lib64 instead of
On Wed, 2013-02-20 at 12:31 -0800, Rafael Schloming wrote:
Source posted here:
- http://people.apache.org/~rhs/qpid-proton-0.4rc2/
Java binaries here:
- https://repository.apache.org/content/repositories/orgapacheqpid-280/
I'd like to call an official vote soon, e.g. tomorrow, so
On Thu, 2013-02-21 at 11:01 -0500, Andrew Stitcher wrote:
On Wed, 2013-02-20 at 12:31 -0800, Rafael Schloming wrote:
Source posted here:
- http://people.apache.org/~rhs/qpid-proton-0.4rc2/
Java binaries here:
- https://repository.apache.org/content/repositories/orgapacheqpid-280
[X] Yes, I believe we should make 0.4 RC3 into 0.4 final
[ ] No, because ...
On Fri, 2013-05-24 at 12:03 +0100, Robbie Gemmell wrote:
...
I also note it'd be nice to get the info in there retrospectively too.
Andrew
QPID:
Yes [ X ]
No [ ]
PROTON:
Yes [ X ]
No [ ]
Robbie
I messed up in not correctly coordinating my recent cmake changes across
proton and qpid, and now the beta Qpid 0.28 will not build against a
release or candidate Proton.
How possible would it be to put out RC2 very soon so that there would at
least be a release candidate of Proton to build Qpid
On Fri, 2014-04-11 at 10:31 +0200, Paolo Patierno wrote:
Hello,
I downloaded qpid-cpp-0.26 and installed all the necessary tools.
If you wanted to try Proton this is the wrong thing to download as
Proton is not included in the qpid source code, it is a separate
download.
[If you wanted help
On Mon, 2014-04-28 at 13:34 -0400, Alan Conway wrote:
I wouldn't instrument the code for this, there are tools that can
measure this kind of thing without code changes.
valgrind has cachegrind which profiles calls in general and can be used
to identify the sources of malloc calls - there's a
David,
Somewhat tangential to you original line of experiment: I've made a
couple of changes to the trunk version of proton in the last few days
that should completely eliminate static use of the .data section for
proton. There were a bunch of things that I've made const and so have
moved to
As part of QPID-619 [1]. The location of the developer script config.sh
has changed from the source tree to the build tree.
The runnable config.sh is now built by cmake as part of the tree
configuration. This allows the script to set the correct variables
without using fallible heuristics.
If
On Mon, 2014-06-30 at 14:56 -0400, Alan Conway wrote:
On Fri, 2014-06-27 at 12:08 -0400, Andrew Stitcher wrote:
As part of QPID-619 [1]. The location of the developer script config.sh
has changed from the source tree to the build tree.
The runnable config.sh is now built by cmake as part
On Wed, 2014-07-02 at 20:25 +, Hoda, Sahir wrote:
Hi all,
I've been working on getting the proton-c library to build on Solaris, and I
have had to implement a few workarounds. I'd like to get the group's opinion
on these changes, and hopefully get some sort of official Solaris support
On Wed, 2014-07-02 at 21:58 +, Hoda, Sahir wrote:
-Original Message-
From: Andrew Stitcher [mailto:astitc...@redhat.com]
Sent: Wednesday, July 02, 2014 3:53 PM
To: proton@qpid.apache.org
Subject: Re: Proton-c support for Solaris
On Wed, 2014-07-02 at 20:25 +, Hoda
I've been looking at fixing PROTON-635 (Not enough PN_TRANSPORT events
being generated for a driver).
It occurs to me that since the lifecycle of pn_transport_t and
pn_connection_t objects are completely independent it makes sense (to me
at least) that PN_TRANSPORT events get sent to a transport
On Wed, 2014-08-27 at 13:39 -0400, Michael Goulish wrote:
conclusion
=
Using the proton engine interface (in C) I am seeing two
aspects of credit management that can strongly affect
throughput.
The first is credit
On Wed, 2014-08-27 at 14:55 -0400, Andrew Stitcher wrote:
...
Of this only applies under the exact circumstances of these tests, until
we have more data points. I'd suspect it must also depend on the message
size too.
Just to reply to myself...
Keeping the credit window at around the MTU
On Sun, 2014-09-21 at 23:43 +0200, Bozo Dragojevic wrote:
On 18. 09. 14 16:55, Rafael Schloming wrote:
Hi Everyone,
I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
order to triage any remaining issues. If there are any particular issues
that you feel strongly
TL;DR: On Windows with Visual Studio, Remove CMakeCache.txt and rerun
CMake.
I've fixed a problem with the build just ignoring the BUILD_WITH_CXX
build setting - however it means that unless you remove that cached
setting and run cmake again or just run cmake from scratch you will get
errors in
On Wed, 2014-10-01 at 21:54 -0400, Michael Goulish wrote:
Link-time optimization can be turned on by adding the
-flto flag to the proton library build, in both compilation
and linking steps. It offers the possibility of optimizations
using deeper knowledge of the whole program than is
On Thu, 2014-11-06 at 11:41 -0500, Rafael Schloming wrote:
Hi Everyone,
The git migration is complete. The svn repo is now read only. You can find
instructions for accessing the git repo here:
https://git-wip-us.apache.org/
There appears to be a problem already with the migration!
On Thu, 2014-11-06 at 14:54 -0500, Andrew Stitcher wrote:
On Thu, 2014-11-06 at 11:41 -0500, Rafael Schloming wrote:
Hi Everyone,
The git migration is complete. The svn repo is now read only. You can find
instructions for accessing the git repo here:
https://git-wip
On Thu, 2014-11-06 at 20:53 +, Dominic Evans wrote:
Few minor things I noticed:
1) the github.com/Apache/qpid-proton mirror has been deleted, but the
git.apache.org mirror remains? Intentional? The GitHub mirror is still
useful for tracking forks...
Ouch, what will happen to existing
On Thu, 2014-11-06 at 16:00 -0500, Andrew Stitcher wrote:
On Thu, 2014-11-06 at 20:53 +, Dominic Evans wrote:
Few minor things I noticed:
1) the github.com/Apache/qpid-proton mirror has been deleted, but the
git.apache.org mirror remains? Intentional? The GitHub mirror is still
An off the cuff thought - worth what you paid for it -
On Wed, 2014-12-10 at 11:23 -0500, Ken Giusti wrote:
...
Furthermore, I think the event API would benefit from a way to 'opt-in' to
specific events. For example, for qpidd we would not want to receive
PN_TRANSPORT nor
On Thu, 2014-12-11 at 11:30 -0500, Darryl L. Pierce wrote:
Would it be possible for someone (Rafi?) to fix the merge commits in the
Short answer is no!
I think you are asking for master's history to be changed and that is:
1) Not possible (fortunately) as the repo is locked down.
2) Not
On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote:
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote:
Rebasing and pushing is not a good option IMO. We have been using pull
requests from GitHub and pushing them through Apache. It's working very
well for us.
On Fri, 2014-12-12 at 14:21 -0500, Clebert Suconic wrote:
..
On the other hand I agree that merging from master just before merging
to master is irritating and pointless.
The apache master can’t be rebased… Period! Work as you wish in your topic
branch, your master or whatever you
On Mon, 2014-12-15 at 11:51 -0500, Alan Conway wrote:
On Fri, 2014-12-12 at 15:09 -0500, Andrew Stitcher wrote:
Alan recently landed a change which stops the proton library from
writing directly to stderr/stdout - this is a good thing (IMO).
However I question a couple of things:
1
On Thu, 2015-01-22 at 10:50 -0500, Rafael Schloming wrote:
I just noticed that dispatch seems to have it's own copy of driver.c now. I
think that means the driver API is now dead code as messenger, the new
reactor stuff, etc all use the newer selector API.
Is anyone else using/aware of
On Mon, 2015-02-16 at 14:32 -0500, Alan Conway wrote:
I work on a mix of SVN and GIT-based projects so I switch between trunk
and master a lot. Proton used to be an SVN based project. I repeatedly
stub my toe on the old trunk branch which has been left lying around
with some random commit at
On Mon, 2015-03-02 at 20:00 +, Gordon Sim wrote:
On 03/02/2015 07:07 PM, Rafael Schloming wrote:
Hi Everyone,
I'd like to propose spinning the first beta (or possibly just RC) for 0.9
sometime next week. We've been using alphas to get some early eyes on some
of the new APIs in this
As many of you know I've been working on implementing a SASL AMQP
protocol layer that does more than PLAIN and ANONYMOUS for proton-c.
I'm currently in at a point where the work is reasonably functional
(with some gaps)
I've put together a fairly comprehensive account of this work on the
Apache
On Wed, 2015-02-25 at 10:27 +0100, Jakub Scholz wrote:
...
But I find this part a bit dangerous:
Classically in protocols where SASL was not optional the way to avoid
double authentication was to use the EXTERNAL SASL mechanism. With AMQP,
SASL is optional, so if SSL is used for client
On Tue, 2015-02-24 at 15:48 -0500, Andrew Stitcher wrote:
...
If you are at all interested please go and look at the proposal and
comment on it there.
Thank you very much to Alan and Jakub for commenting on my proposal.
The reason I asked people to comment over on the wiki is that it is very
On Wed, 2015-02-25 at 10:46 -0500, Alan Conway wrote:
...
One ignorant question: Qpid has a min/max Security Strength Factor for
encryption rather than a binary enable/disable. Is that relevant here?
(Hardly an ignorant question!) You make a very good point, and this
design may indeed be a
On Thu, 2015-02-26 at 12:28 +, Robbie Gemmell wrote:
...
I'm going to post my comments here and on the wiki, as I dont think
many (except maybe you) will actually see them on the wiki ;)
Thank you for the excellent feedback. I'm going to answer on the wiki -
as it'll save me from cutting
On Thu, 2015-02-26 at 15:09 -0500, Rafael Schloming wrote:
...
It sounds like one way or another we need at least some design changes. I
don't think it's workable to have overlapping/close but distinct semantics
for the API on different platforms (e.g. you can move sockets on one
platform but
On Thu, 2015-02-26 at 13:43 -0500, Alan Conway wrote:
On Thu, 2015-02-26 at 09:39 +, Dominic Evans wrote:
Hi Alan,
-Alan Conway acon...@redhat.com wrote: -
I plan to start working on a go golang.org binding for proton. I
envisage a SWIG binding similar to the other
On Tue, 2015-04-21 at 14:56 +0100, Robbie Gemmell wrote:
On 21 April 2015 at 14:48, Robbie Gemmell robbie.gemm...@gmail.com wrote:
On 21 April 2015 at 12:52, Rafael Schloming r...@alum.mit.edu wrote:
I'm seeing a couple of issues with the recently landed sasl changes. I'm
getting four test
On Wed, 2015-05-06 at 14:03 -0400, Rafael Schloming wrote:
We seem to have reached consensus here, but I haven't seen any commits on
this. We should probably fix this before 0.10 so we don't end up putting
out a new API and then deprecating it in the next release. Is anyone
actually working on
On Thu, 2015-05-07 at 11:09 -0400, Andrew Stitcher wrote:
On Wed, 2015-05-06 at 23:42 +0100, Gordon Sim wrote:
...
Apparently these are posix functions and are not included in c99. Using
the proton equivalents in util.h works. Let me know if you want me to
commit that.
Gah, sorry I
On Wed, 2015-05-06 at 22:22 +0100, Gordon Sim wrote:
[ 70%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/sasl/sasl.c.o
/home/gordon/projects/proton-git/proton-c/src/sasl/sasl.c:224:9: error:
implicit declaration of function 'strncasecmp' is
Since Rafi pushed 223bbc8bd50a34282ef02952392fd4321113f770 my Linux
(Fedora 21) builds have been failing [1]. I've finally tracked it down
to some problem with ccache-swig.
So if you have ccache installed (which is generally a good idea as it
speeds up builds a lot) you need to avoid the ccache
On Wed, 2015-05-06 at 23:42 +0100, Gordon Sim wrote:
...
Apparently these are posix functions and are not included in c99. Using
the proton equivalents in util.h works. Let me know if you want me to
commit that.
Gah, sorry I should have spotted that myself earlier.
I will fix it - I think
On Wed, 2015-04-15 at 07:13 -0400, Rafael Schloming wrote:
On Tue, Apr 14, 2015 at 1:27 PM, Alan Conway acon...@redhat.com wrote:
That works for me, now how do we manage the transition? I don't think we
can afford to inflict yum update proton; all proton apps crash on our
users. That
I've received no further feedback at all about this review request.
Do people want me to create a reviewboard item instead?
For reference, this proposed change incorporates all the discussion -
although I haven't necessarily agreed with everyone else's points!
For clarity the main issue that I
On Tue, 2015-04-07 at 09:38 -0400, Alan Conway wrote:
On Tue, 2015-03-31 at 19:17 +0200, Božo Dragojevič wrote:
Given the memory overhead of a pn_data_t before encoding, why not have it
own an encode buffer? it could get by with exactly that grow_buffer()
callback if ownership is the issue
On Wed, 2015-04-08 at 10:48 -0400, Alan Conway wrote:
...
The issue is that we need buffer growth AND control over allocation.
pn_buffer_t forces use of malloc/free/realloc. That won't help if you're
trying to get the data into a buffer allocated by Go for example. I
agree a growable buffer
On Mon, 2015-07-06 at 11:30 -0400, Rafael Schloming wrote:
I wired in allowSkip in a very minimal way just to restore the ability to
force the old behaviour. It would be a fairly trivial to change the name of
course,
I'm not sure if that really applies as the method is on a different
object
On Mon, 2015-07-06 at 13:14 -0400, Andrew Stitcher wrote:
On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
...
The old toggle only used to define whether sasl was required or not
(which it historically was once you enabled the sasl layer, and the
toggle was never implemented
On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
...
The old toggle only used to define whether sasl was required or not
(which it historically was once you enabled the sasl layer, and the
toggle was never implemented in proton-j), whereas IIRC the new
'requireAuth' governs that but
On Mon, 2015-07-06 at 11:28 -0700, Rafael Schloming wrote:
+1
The only issue that has me worried here is the sasl interop story between
proton-c and proton-j. I can cut a release later today just to give us
something to poke at, but there may still be sasl work needed.
I have a blocking fix
I like the way you're thinking - I expect to have real time to look at
your code Tomorrow/Wednesday.
One point that occurred to me over the weekend (that I think is
probably incorporated in what you've done here). Is that C++ code never
needs to use a shared_ptr to any Proton struct because
On Tue, 2015-08-18 at 07:38 -0400, Rafael Schloming wrote:
Nice writeup!
I agree.
Andrew
[Did you make a pass through the doc to ensure that the claimed API doc
is actually there? that is, doc on ownership and scope?]
On Thu, 2015-08-20 at 14:44 -0400, aconway wrote:
Here's the API doc, the code is coming. It is like previous proposals
which were well received but more correct. It has *two* conversion
types, pn_borrowed_ptr and pn_given_ptr. This both automates the
refcounting for smart pointers and acts as
Cyrus sasl is really
suitable to be used as part of a library.
[1] https://issues.apache.org/jira/browse/PROTON-979
On Wed, 2015-08-12 at 17:41 -0400, Andrew Stitcher wrote:
I've tested proton-c on ubuntu1404, ubuntu1204 FreeBSD 10.1p17
Ubuntu 1204 builds and ctests fine.
This is our the OS
I vote +1:
I've tested proton-c python on:
Ubuntu 12.04 (amd64)
Ubuntu 14.04 (amd64/i686)
Raspberry Pi2 (Raspbian Jesse)
FreeBSD 10.1p17
Windows 8.1 with Visual Studio 12 (2013)
[Some of these test have had Java tox as well but it's been uneven)
And modulo some (severe) irritations (see the
On Mon, 2015-11-09 at 13:26 -0500, Justin Ross wrote:
> Okay, I don't object to a respin to pick this up. If anyone else
> does,
> speak up. Alan, please line up a reviewer to comment on PROTON-949.
I've approved the fix for 0.11
Andrew
On Mon, 2015-10-12 at 16:05 -0400, aconway wrote:
> ...
> +1, that looks like the right fix. 3141 is an odd choice of default,
> even for a mathematician.
>
At this point, I'm desperately trying to find an appropriate pi joke :
-)
Andrew
On Wed, 2015-09-09 at 09:27 +, Clemens Vasters wrote:
> Hi Qpid Proton,
>
> tl;dr: I'm working with Proton-C 0.10 and would like to have explicit
> override options to keep Proton-C from automatically picking up on
> EXTERNAL when being offered by the server - while using the messenger
>
On Wed, 2015-09-30 at 18:58 -0400, aconway wrote:
> I'd like to create these two components, who can edit the project? I
> can be owner for go-binding, cjansen should probably be owner for cpp
> -binding.
Added with those suggested owners.
Would the 2 of you like to be the default assignees
On Wed, 2015-09-09 at 15:57 +, Clemens Vasters wrote:
> Hi Andrew,
>
> I agree that the server should only offer EXTERNAL when the client
> has presented a valid cert.
>
> We have the case that we still want to use PLAIN or ANONYMOUS even in
> that case, however, since we'll want to use a
On Mon, 2015-09-21 at 11:37 -0400, Andrew Stitcher wrote:
> On Mon, 2015-09-21 at 11:35 -0400, Andrew Stitcher wrote:
> > I worked on PROTON-996[1] last week, and added a new C API which
> > surfaced the allowed SASL mechanism into the Proton Messenger API.
>
> Sorry I f
I worked on PROTON-996[1] last week, and added a new C API which
surfaced the allowed SASL mechanism into the Proton Messenger API.
For simplicity I added a new API pn_messenger_sasl_allowed_mechs()
which just mirrored the pn_sasl_allowed_mechs() API.
However When I went to create a new API for
A small request for the release manager:
could you please add updating the appveyor.yml file to the correct
version to the release process.
I've just noticed that the appveyor build still thinks the build
version is 0.10-SNAPSHOT. This strongly implies that the master
appveyor.yml has not been
On Wed, 2016-02-03 at 07:10 -0800, Justin Ross wrote:
> The artifacts proposed for release:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/
>
> Please indicate your vote below. If you favor releasing the 0.12.0
> RC bits
> as 0.12.0 GA, vote +1. If you have reason to
Simple 1 line fix to the CMakefiles; looks bad for C++ on Windows if we
don't fix this!
https://issues.apache.org/jira/browse/PROTON-1127
Andrew
On Thu, 2016-01-28 at 12:43 -0500, Alan Conway wrote:
> The 0.12.x branch does not compile under c++11 (clang and gcc) with
> warnings, this fixes them
>
> https://github.com/apache/qpid-proton/commit/05502ad56f5a3860d5d19ab7
> c8
> 08ad43bd39274e
Unfortunately this breaks windows builds - I'm
On Thu, 2016-01-28 at 13:29 -0500, Andrew Stitcher wrote:
> On Thu, 2016-01-28 at 12:43 -0500, Alan Conway wrote:
> > The 0.12.x branch does not compile under c++11 (clang and gcc) with
> > warnings, this fixes them
> >
> > https://github.com/apache/qpid-proton/co
I've approved both of these for inclusion (in the JIRAs).
Andrew
On Thu, 2016-01-28 at 11:04 +, Robbie Gemmell wrote:
> Hi Justin,
>
> I'd like to request the following for inclusion in 0.12.0:
>
> Stop the proton-j transport from erroneously emitting various frame
> types after a Close
Approved for 0.12
On Tue, 2016-02-02 at 16:09 -0500, Alan Conway wrote:
> Very simple fix, potentially confusing bug. The implicit conversion
> to
> an excessivly lax template value ctor leads to very confusing error
> messages. Fix is to make it explicit, fancy type-deduction stuff
> coming
>
This is a potential crashing bug detected by Coverity
The fix is less than a line and I judge low risk.
https://issues.apache.org/jira/browse/PROTON-1121
Andrew
On Tue, 2016-02-02 at 11:46 +, Robbie Gemmell wrote:
> Andrew/Alan/Any-other-C-inclined-folks, can you look at this?
I've looked at it and commented at some length in the bug report
itself.
>
> I know a large sticking point is likely to be that we probably have
> no
> easy way to test
This [1] is really an interop bug, but I suspect it will be annoying to
anyone using earlier versions of ActiveMQ.
The fix is pretty small and seems low risk to me.
Andrew
[1] https://issues.apache.org/jira/browse/PROTON-1055
On Mon, 2016-02-29 at 17:46 +, Flores, Paul A. wrote:
> I am attempting to build QPID Proton 12 and seeing the following
> errors:
>
>
>
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked
I've now checked in the working version of the improved error work [1]
to master, and I'd like to check it in to 0.12.
The missing commits are:
80587567cc1c48e25fd69a6175667471e7c8
fa11ada8a804c2353633965ff756b9c5991d1cc6
9d3e995393a918b80aca5ef60061b27a387d053d
I mean request for inclusion in 0.12 - the beta has already branched!
On Tue, 2016-01-26 at 15:35 -0500, Andrew Stitcher wrote:
> I've now checked in the working version of the improved error work
> [1]
> to master, and I'd like to check it in to 0.12.
>
> The
I've been doing some build tree maintenance in Proton and a couple of
issues have come up:
1. Is anyone using/have a reason to want to keep proton-dump? It's a
somewhat odd program that seems to have been a debugging tool left over
from the very earliest days of proton.
It uses the internals of
On Mon, 2016-02-15 at 17:16 -0500, Chuck Rolke wrote:
> ..
>
> I use a minimum CMake of 2.8.11 on my windows systems.
Thanks for the info - FWIW I'd upgrade to atleast 2.8.12 If I were you
(it's the last 2.8 version before they jumped to 3.x)
Andrew
On Mon, 2016-02-15 at 17:36 -0500, Ken Giusti wrote:
> ...
> In general +1. What version does Windows use?
In general Windows builds will use whatever you install on them (as
CMake isn't packaged with Windows in anyway).
Specifically the version packaged by chocolatey (http://chocolatey.org)
is
On Wed, 2016-02-17 at 10:51 +, TRUFANOW Alexandre wrote:
> Hi,
>
> I am attempting to compile proton and the C++ binding using GCC 3.4
This is a very old compiler (from no later than 2006), and we don't
test on it (although we are striving currently to support C++03).
Going forward it is
Well I left it 3 days, heard no objections so I will remove proton-dump
and up the minimum version of cmake to 2.8.7.
Andrew
[
https://issues.apache.org/jira/browse/PROTON-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448109#comment-13448109
]
Andrew Stitcher commented on PROTON-4:
--
I have commited this patch now (somewhat
Andrew Stitcher created PROTON-8:
Summary: Proton header files don't have 'extern C ' which makes
them harder to use for C++ than necessary.
Key: PROTON-8
URL: https://issues.apache.org/jira/browse/PROTON-8
[
https://issues.apache.org/jira/browse/PROTON-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13473406#comment-13473406
]
Andrew Stitcher commented on PROTON-67:
---
Is it worth pointing out that regular brace
[
https://issues.apache.org/jira/browse/PROTON-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13473425#comment-13473425
]
Andrew Stitcher commented on PROTON-67:
---
I also second Cliff's point about the #ifdef
[
https://issues.apache.org/jira/browse/PROTON-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher reopened PROTON-48:
---
Adds the PROTON_INSTALL_LIBDIR macro to the Cmake environment
[
https://issues.apache.org/jira/browse/PROTON-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13475059#comment-13475059
]
Andrew Stitcher commented on PROTON-48:
---
Ok I see what the patch adds - reworked
1 - 100 of 415 matches
Mail list logo
