I am trying to catch up with you to reproduce your problem. So far I
can build on linux with "cmake -DBUILD_WITH_CXX=ON". That works, so
we know the problem is unrelated to swig itself or the switch to C++.
It is either some problem with Visual Studio or a lack of strictness
with g++.
The warnin
Oh crap, you're right.
I have to remember what I saw in the API, and what I saw only in the code.
OK, re-writing.
- Original Message -
From: "Rafael Schloming"
I think as soon as you start talking about credit you're already at much
lower level than is appropriate for the messe
Hi Cliff,
Thanks for looking into this.
Simply setting the BUILD_WITH_CXX flag with a clean checkout doesn't expose
the problem because it doesn't affect the language that Swig uses. You'd
need to also:
- Edit bindings/java/CMakeLists.txt to tell Swig to honour the
BUILD_WITH_CXX flag and use C
- Original Message -
>I think as soon as you start talking about credit you're already at much
>lower level than is appropriate for the messenger API. The messenger
>interface has API doc in both C and python and they both describe the
>semantics of recv without making any mention of the te
I think Rafi brought up a kind of unassailable point when he
suggested that a document about the Messenger API should
probably confine itself to concepts that are ... in the Messenger API.
I would be happy to explain the use of credit sometime (after the impl
settles down...) but the Messenger
I did all that and verified the c++ swig call was used and g++ on
javaJAVA_wrap.cxx. I also needed the fix in PROTON-249 to progress on
Windows.
Let me know if you have made further progress. Otherwise, I will keep digging.
Cliff
On Fri, Mar 1, 2013 at 4:31 AM, Phil Harvey wrote:
> Hi Cliff,
- Original Message -
> On Tue, Feb 26, 2013 at 12:18 PM, Ken Giusti
> wrote:
>
> > Hi Mick
> >
> > - Original Message -
> > >
> > > One hole that I feel like I'm seeing in the messenger
> > > interface concerns credit.
> > >
> > > I have a way of using credit to set a max number
The code is all coming together nicely. Wanted to drop some status on
where I am with the code before going on a week's PTO.
The Perl wrapper for the qpid::proton::Data class are mostly together
with unit test coverage. What's giving me a pain now, though, is packing
a DECIMAL32 value.
Right now
I've been using the proton-j 0.3 and I was surprised to find
out that the context type of a connector returned from Listener.accept()
is created with the context object type of the parent listener.
I am wondering why that is that enforced.