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 a
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 hel
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
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 .ro
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 thi
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 runnabl
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 supp
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
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 "
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
On Wed, 2014-08-27 at 15:17 -0400, Ted Ross wrote:
>
> On 08/27/2014 03:05 PM, Andrew Stitcher wrote:
> > On Wed, 2014-08-27 at 14:55 -0400, Andrew Stitcher wrote:
> >> ...
> >> Of this only applies under the exact circumstances of these tests, until
> >> w
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
On Tue, 2014-09-23 at 09:50 +0200, Bozo Dragojevic wrote:
> On 22. 09. 14 19:57, Andrew Stitcher wrote:
> > On Sun, 2014-09-21 at 23:43 +0200, Bozo Dragojevic wrote:
> >> PROTON-660: Fix openssl.c build on windows
> > Are you planning to do this work yourself? If so please
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 yo
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 ava
[ X ] Yes, migrate the proton repo over to git.
[ ] No, keep it in svn.
Andrew
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:
&
On Thu, 2014-11-06 at 15:03 -0500, Andrew Stitcher wrote:
> 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
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 existin
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? Intent
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 PN_LINK_LOCAL_
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 desira
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
On Fri, 2014-12-12 at 14:37 -0500, Rafael Schloming wrote:
> ...
> > On the other hand I agree that merging from master just before merging
> > to master is irritating and pointless.
>
>
> So what was the right thing to do here? I have to admit I struggled a bit
> with the git portion of getting
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. This change adds to the external API and so should have been reviewed
(again IMO). reviews.apache.org now does work with the
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. This change adds to the external API and so should have been reviewed
(again IMO). reviews.apache.org now does work with the
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. This change adds to the external API and so should have been reviewed
(again IMO). reviews.apache.org now does work with the
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. This change adds to the external API and so should have been reviewed
(again IMO). reviews.apache.org now does work with the
I'll stop spamming the lists with this message now - Evolution just stopped
trying to send it (7 times it seems) and so I couldn't tell it had already gone.
Time to get a better mail client.
Sigh, still weekend soon.
- Original Message -----
From: "Andrew Stitch
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
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 a
On Wed, 2015-01-28 at 16:09 -0500, Alan Conway wrote:
> On Tue, 2015-01-27 at 09:46 -0500, Rafael Schloming wrote:
> > Do you have tracing turned on when they time out? With the protocol trace
> > enabled the tests slow down enough that some of them don't finish before
> > the various timeouts kick
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
On Mon, 2015-02-16 at 17:55 -0500, Alan Conway wrote:
> ... [Some really good advice]
> 2. Linux fans: set env. var. MALLOC_PRETURB_ (note trailing underscore)
Just to save any frustration that would be:
MALLOC_PERTURB_
Note the real English word in there!
Andrew
[CCing to Proton list as I think it's now started to be relevant to
everyone]
On Thu, 2015-02-19 at 09:03 -0500, Alan Conway wrote:
> ...
> To be honest, I don't like requiring people to check the flags
> everywhere because you can be sure at some point they won't, and here's
> the proof. I am tem
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 w
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 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 a
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 t
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 13:43 -0500, Alan Conway wrote:
> On Thu, 2015-02-26 at 09:39 +, Dominic Evans wrote:
> > Hi Alan,
> >
> > -Alan Conway wrote: -
> > > I plan to start working on a "go" binding for proton. I
> > > envisage a SWIG binding similar to the other swig-based bindings
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
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 API
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
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 buff
On Wed, 2015-04-15 at 07:13 -0400, Rafael Schloming wrote:
> On Tue, Apr 14, 2015 at 1:27 PM, Alan Conway 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 means we cann
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 h
On Tue, 2015-04-21 at 14:56 +0100, Robbie Gemmell wrote:
> On 21 April 2015 at 14:48, Robbie Gemmell wrote:
> > On 21 April 2015 at 12:52, Rafael Schloming wrote:
> >> I'm seeing a couple of issues with the recently landed sasl changes. I'm
> >> getting four test failures in the python tests (see
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 'strncasec
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 thi
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
>
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
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 ve
On Wed, 2015-06-03 at 16:57 +0100, Gordon Sim wrote:
> On 06/03/2015 04:14 PM, logty wrote:
> > I ran with PN_TRACE_FRM=1, and it returned the following log results. The
> > connection has been working with Python but not with C. It seems to be some
> > SASL issue, any thoughts?
>
> The c client i
On Mon, 2015-07-06 at 10:56 -0400, Rafael Schloming wrote:
> On Mon, Jul 6, 2015 at 9:52 AM, Robbie Gemmell
> wrote:
>
> > Is this change allowing clients to skip the SASL layer when connecting
> > to servers that have enabled the SASL layer? If so, how is the new
> > default behaviour disabled?
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 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 b
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
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
On Mon, 2015-08-03 at 18:40 +0100, Robbie Gemmell wrote:
> Hi folks,
>
> I have put up a 0.10 beta2 cut from the new 0.10.x branch. I'll be
> looking to cut RC1 in the next couple of days and immediately proceed
> to vote on it, so please give the beta a kick of the tyres and report
> back your fi
I've tested proton-c on ubuntu1404, ubuntu1204 & FreeBSD 10.1p17
Ubuntu 1204 builds and ctests fine.
This is our the OS on our travis CI so it's not a surprise it works.
Ubuntu 1404 - I'm having problems with the "python" tests and SSL -
investigating whether this is my config or something more.
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
penssl nor 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 ct
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 Proton
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
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
> layer
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 par
On Wed, 2015-09-09 at 17:03 +, Clemens Vasters wrote:
> ...
> https://www.oasis-open.org/committees/document.php?document_id=50506&;
> wg_abbrev=amqp
I looked at this and I agree it does seem quite powerful.
IUC you need an authenticated AMQP connection of some sort (ANON would
work) to send
So after adding
this new API any bindings of the messenger API will also get the new
API.
I'm not sure if that answers your question, as I'm not 100% sure what
the question was.
Andrew
>
> -Ursprüngliche Nachricht-
> Von: Andrew Stitcher [mailto:astitc...@redhat.com]
> G
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 t
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 forgot to add the link to the conversation there:
[1] https://issues.apache.org/jira/
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 forg
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 (resp
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 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
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 up
On Tue, 2016-01-19 at 10:39 +, Robbie Gemmell wrote:
> Can I suggest a more basic change of simply removing the release
> version from the Appveyor job id?
>
> None of the other CI jobs have that, and given it has been wrong for
> around 5 months it doesn't seem particularly noted by most folk
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
f066bd520cb2b43524c0e836ee8e8b
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.
>
>
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 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 wo
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 was
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 things
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
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
> for
On Tue, 2016-02-02 at 21:23 -0500, Alan Conway wrote:
> This is just the core dump issue from proton-1122 separated out for
> the
> 0.12 release.
I approve this for inclusion in 0.12
Andrew
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 think
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
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 t
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 no
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
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 or
On Tue, 2012-08-14 at 16:51 -0400, Rafael Schloming wrote:
> > I'm not sure we have a pressing need to support this mechanism. A
> > pattern that would potentially be more interesting is to run TLS and
> > non-TLS connections on the same port.
> >
>
> I believe the C++ broker supports this. Andre
1 - 100 of 555 matches
Mail list logo
