I've put together some mock ups of a few different codec strategies both to
compare from an API/usability perspective and to get a rough idea of some
of the performance implications of the different choices. Please see the
attached code for the full details. I'll summarize the different strategies
That's most definitely a bug in the Perl binding. It should properly
introspect the types of keys/values just like the other bindings. If you
file a JIRA I'll see what I can do about fixing it or poking someone else
to fix it. ;-)
--Rafael
On Fri, May 16, 2014 at 11:45 AM, Fraser Adams <
fraser.
This mysterious incarnation seems to be able to tell the difference:
sub isnum ($) {
return 0 if $_[0] eq '';
$_[0] ^ $_[0] ? 0 : 1
}
If you want to know why then have a look at this thread:
http://www.perlmonks.org/?node=How%20to%20check%20if%20a%20scalar%20value%20is%20numeric
Hi Everyone,
I've been doing a bit more exploration around some of the codec strategies
I posted about a few weeks ago and I'd like to share some results.
There are still some gaps to fill in, but all the complex data types
(lists, maps, arrays, described types, etc) are dealt with for both
encod
On Tue, May 27, 2014 at 5:15 PM, Robbie Gemmell wrote:
> I haven't had time to run any of this or look through it properly yet, but
> after a very very quick scroll through...
>
> - Should we not use LinkedHashMap instances, due to the ordering
> restriction on equality checks for amqp maps?
>
Pr
On Wed, May 28, 2014 at 9:13 AM, TheLoneStranger wrote:
> Just an update on the progress..
>
> The 581 patch for Proton works and I now have publisher that publishes to
> the server via amqps.
> However we cannot see any messages arriving at the ServiceBus queue(s).
>
> In essence, the call to pn
What sort of problems did you run into with proton-j?
--Rafael
On Thu, May 29, 2014 at 11:21 AM, Jimmy Campbell
wrote:
> Proton-j was my first choice but I was unable to connect to the Azure
> Service Bus, which is my end goal. There are tutorials and support for
> connecting proton-c to the a
dropped the connection" in system error.
>
> Proton-c is able to send without any issues.
>
> -Original Message-----
> From: Rafael Schloming [mailto:r...@alum.mit.edu]
> Sent: Tuesday, June 3, 2014 8:26 AM
> To: proton@qpid.apache.org
> Subject: Re: Proton-c on android
&g
Based on what you've posted it looks to me like you need to factor in
Transport.capacity() into your code somehow. Transport.capacity() will
return the number of bytes you can currently pump into the transport, or it
will return Transport.END_OF_STREAM if it is no longer legal to pump in
more bytes
Yeah, there was a discussion on the list a while back. They were originally
created for testing purposes, and were proving to be difficult to maintain.
We opted to remove them and have more resources to focus on bringing the
pure Java implementation up to parity with C. As far as I know you are the
android.
>
> -Jimmy
>
> -Original Message-
> From: Rafael Schloming [mailto:r...@alum.mit.edu]
> Sent: Thursday, June 12, 2014 10:38 AM
> To: proton@qpid.apache.org
> Subject: Re: Swig java bindings proton0.7
>
> Yeah, there was a discussion on the list a while back. Th
On Thu, Jun 12, 2014 at 2:50 PM, Jimmy Campbell
wrote:
> All you have to do to replicate my problem is try to send a message to a
> queue hosted on the service bus. If you can get the message to send then
> you've done what I can't. I would like to give you an endpoint but that's
> out of my reac
That's a good point. I suspect something (extra) funny is going on here. I
really want to see line numbers against that stack trace. I'm not sure I
believe it's a real trace, there may be some sort of stack corruption
happening here.
On Wed, Jul 2, 2014 at 10:54 AM, Cliff Jansen wrote:
> As far
Hi Everyone,
Apologies for being a bit quiet recently. I've been heads down working on
some improvements to the events API. I've put together a little demo that
showcases what I've been doing.
Apologies for the teaser, but I'd like to encourage people to have a look.
;-) You can find the code for
On Fri, Jul 4, 2014 at 10:23 AM, Bozo Dragojevic wrote:
> On 2. 07. 14 21:24, Rafael Schloming wrote:
>
>> Hi Everyone,
>>
>> Apologies for being a bit quiet recently. I've been heads down working on
>> some improvements to the events API. I've put toget
On Mon, Jul 7, 2014 at 9:06 AM, Gordon Sim wrote:
> On 07/02/2014 08:24 PM, Rafael Schloming wrote:
>
>> My goal with this demo has been to explore a couple of distinct themes.
>> The
>> toolkit is intended in part to illustrate how the events API allows use of
Hi Everyone,
I wanted to give people a quick heads up. I would like to land the events
branch soon. If you don't use the events API then this probably won't
impact you, however if you do then you may experience some compilation
failures. This is because of the following changes:
The PN_{CONNECTIO
FYI, the events branch is now landed on trunk. Please let me know if you
run into any issues.
--Rafael
On Thu, Jul 10, 2014 at 2:10 PM, Božo Dragojevič wrote:
> On Jul 10, 2014 6:41 PM, "Rafael Schloming" wrote:
> >
> > Hi Everyone,
> >
> > I wanted to
Hi Matheus,
I don't know of anyone working on bindings for go. Your post prompted me to
read the go tutorial and to look briefly at cgo, and it looks like it would
be a nice fit. Are you interested in contributing to such a project or
simply looking for a way to speak AMQP from go?
--Rafael
On
I did think about the possibility of doing this initially, however the
notion of having a transport bound to a connection where each have two
distinct collectors struck me as kind of odd/problematic. I don't know that
it's a meaningful thing to do since you would lose ordering between events
genera
Hi Bozo,
I closed the JIRA before I noticed your issue. Please feel free to reopen
it if your investigations turns up any problems with it.
--Rafael
On Thu, Sep 4, 2014 at 11:33 AM, Bozo Dragojevic wrote:
> Hi!
>
> Just a headsup. This commit breaks pn_accept() for me, it fails all the
> time
The Qpid PMC has voted to grant Bozo Dragojevic commit rights to Qpid for
his long standing interest in and involvement in Proton.
Welcome Bozo, and thanks for all the contributions!
--Rafael
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 should be included in 0.8, please follow up on this
thread and bring them to my attention.
--Rafael
re working with this patch
> without any error.
> We supose that it can be useful for others.
>
> Miguel da Rocha Correia Lima
> miguel at landix dot com dot br
>
> Em 18/09/2014 11:55, Rafael Schloming escreveu:
>
> Hi Everyone,
>>
>> I'd like t
Hi,
On Wed, Sep 24, 2014 at 10:59 AM, Fugitt, Jesse
wrote:
> Our team is currently using Proton 0.7 and ran into an issue on Windows
> while testing where we could not successfully reconnect to a broker once it
> was taken down and brought back up (we are using a pn_driver_t in C). It
> appears
Hi,
The situation with settlement isn't quite analogous to the open/close
handshake because at the protocol settlement is not an actual handshake,
it's a truly one way operation. Conceptually, settling a delivery consists
of forgetting everything about that delivery. When this happens the
protocol
Hi Everyone,
I've created 0.8 RC1 and posted it in the usual locations. The source can
be found here:
http://people.apache.org/~rhs/qpid-proton-0.8rc1/
Java binaries are available here:
https://repository.apache.org/content/repositories/orgapacheqpid-1015/
Please check it out and follow up
On Wed, Oct 8, 2014 at 1:30 PM, Fraser Adams
wrote:
> On 08/10/14 08:16, xavier wrote:
>
>> Hi Frase,
>>
>> Thanks for your explanation, but here, my code:
>>
>> In the requester:
>>
>> char * corrId;
>> .
>> .
>> pn_bytes_t bytes = pn_bytes(correlationId.size(), corrId);
>> pn_atom_t id
On Thu, Oct 9, 2014 at 8:44 AM, Dominic Evans
wrote:
> fadams wrote
> > On 08/10/14 18:49, Rafael Schloming wrote:
> >> Actually I think it is possible to do this with messenger now that
> >> dominic's patches are in. You can access the link associated with a
Can you include a bit more context? The 6-7 seconds for 100,000 messages
seems a bit slow compared to what I've been able to measure. Was it over
loopback or a real network? Was the profiler running when those
measurements were made? How big are the messages, etc?
---Rafael
On Thu, Oct 9, 2014 at
> - Original Message -
> > From: "Rafael Schloming"
> > To: proton@qpid.apache.org
> > Sent: Thursday, October 9, 2014 10:43:09 AM
> > Subject: Re: jprofiler hotspot results for java engine clients
> >
> > Can you include a bit more context? The 6
Hi Everyone,
I've put up 0.8 RC2 at the usual places. The source code can be found here:
http://people.apache.org/~rhs/qpid-proton-0.8rc2/
Java binaries here:
https://repository.apache.org/content/repositories/orgapacheqpid-1016
Notable changes since RC1 are:
- fix to cmake detection
Hi Everyone,
As usual the call for a formal vote flushed out a few last minute issues,
so here is a quick respin with the following items fixed.
- PROTON-708
- PROTON-711 (fixed for Java6)
- PROTON-712
- PROTON-714
- PROTON-715
The sources can be found at the usual location:
http:
Hi Everyone,
I've put together RC4. This is pretty much the same as RC3 with a number of
fixes to disable those SSL versions that are vulnerable to attack.
The sources are available here:
- http://people.apache.org/~rhs/qpid-proton-0.8rc4/
Java binaries are here:
- https://repository.apach
andle.cpp:280
> >> #20 0x7f130b08d4f2 in process (this=0x176cc90) at
> >> /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/Poller.h:131
> >> #21 qpid::sys::Poller::run (this=0x176cc90) at
> >> /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/epoll/EpollPoller.cpp:522
> &g
;
> Best regards,
>
> 24.10.2014 22:24, Rafael Schloming пишет:
> > Hi Michael,
> >
> > I just committed the change Ken suggested to at least fix the abort. Is
> > there any way you could retest with trunk?
> >
> > If the problem still occurs (I expect
ink-credit=100, drain=false]
> [0x129d770]:0 <- @flow(19) [next-incoming-id=3,
> incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0,
> delivery-count=3, link-credit=100, drain=false]
> [0x12862d0]:0 <- @open(16)
> [container-id="e5584c39-
ending messages from signal
> handler allowed?
>
> Best regards,
>
> 25.10.2014 00:41, Rafael Schloming пишет:
> > Hi Michael,
> >
> > Sorry for misleading you. I think the way qpidd integrates proton must
> > override the PN_TRACE_FRM configuration. I believe you
up. If I don't hear anything I
will put out another (hopefully final) RC shortly.
Thanks,
--Rafael
On Mon, Oct 27, 2014 at 8:43 AM, Rafael Schloming wrote:
> Hi Michael,
>
> That sounds very much like the root of the issue. If the signal handler is
> triggered from inside a c
If this turns out to be the problem then please file a JIRA for it. That
code is some of the oldest code in proton and there has been a nice
efficient circular buffer implementation available in the codebase for ages
now.
--Rafael
On Mon, Oct 27, 2014 at 1:35 PM, Gordon Sim wrote:
> On 10/27/20
On Mon, Oct 27, 2014 at 12:12 PM, Dominic Evans
wrote:
> When using messenger in non-blocking mode, it is possible to ensure that
> the
> empty frame heartbeats are sent by calling pn_messenger_work(timeout) on a
> regular interval (when no other send / recv operations are happening).
>
> However
Hi Everyone,
Sorry for the delay, there seemed to be some kind of Nexus outage today, so
I was unable to generate the java binaries until just now.
I've posted RC5 in the usual places. The only difference from RC4 is a one
line delta that replaces the assertion failure when we receive
out-of-sequ
Hi Everyone,
I'd like to try to get the proton releases to be a bit more frequent, and
I'm also trying to get a bit more up front planning into them. To that end
I've put together a quick description of what I'd propose for timeline and
scope of the next release here:
http://qpid.apache.org/pro
On Wed, Oct 29, 2014 at 10:13 AM, Ken Giusti wrote:
> Hey Rafi - thanks for doing this.
>
> Can we add support for Python 3 in the timeline?
>
Without a patch or some exploratory work on it, I'm not really sure where
I'd slot it in.
--Rafael
t 27, 2014 at 9:51 PM, Rafael Schloming wrote:
> Hi Everyone,
>
> Sorry for the delay, there seemed to be some kind of Nexus outage today,
> so I was unable to generate the java binaries until just now.
>
> I've posted RC5 in the usual places. The only difference from RC4 is
Hi Everyone,
I'm planning on updating the release script for 0.9 to automate the last
few details of the release process and to do proper branching. Given that
the release script must make use of the canonical repo to work properly, it
occurs to me that if we're going to switch over to git then no
I like the gradual migration concept. I do use git-blame / git-annotate
enough for a wholesale changeover to be problematic.
Is there an easy way to see what the actual diffs are so we have an idea of
what the various format policies actually mean?
--Rafael
On Fri, Oct 31, 2014 at 11:15 AM, Domi
Just for the record...
[ X ] Yes, migrate the proton repo over to git.
--Rafael
On Thu, Oct 30, 2014 at 6:59 AM, Rafael Schloming wrote:
> Hi Everyone,
>
> I'm planning on updating the release script for 0.9 to automate the last
> few details of the release process and to do
The vote passes with 11 binding votes for, and 1 non-binding vote against.
--Rafael
On Thu, Oct 30, 2014 at 6:59 AM, Rafael Schloming wrote:
> Hi Everyone,
>
> I'm planning on updating the release script for 0.9 to automate the last
> few details of the release process
Hi there,
First off, thanks for bringing this to the list. I would love to see Proton
have better support for embedded environments, so any contributions you
could make in that area would be very welcome.
I've got a bunch of more detailed questions/comments inline, so please read
on...
On Wed, N
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/
The repo name is qpid-proton:
https://git-wip-us.apache.org/repos/asf/qpid-proton.git
--Rafael
On Thu, Nov 6, 2014 at 4:09 PM, Andrew Stitcher
wrote:
> 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
> > >
Hi Everyone,
Qpid Proton 0.8 is now officially available. You can find it here:
- http://qpid.apache.org/releases/qpid-proton-0.8/index.html
The release includes numerous bug fixes and improvements. Full details can
be found here:
-
https://issues.apache.org/jira/secure/ReleaseNote.jspa?pro
On Mon, Nov 17, 2014 at 10:11 AM, Dominic Evans
wrote:
> Can someone explain why there is a check on
> `pn_messenger_get_outgoing_window` / `pn_messenger_get_incoming_window` to
> confirm they are >0 before applying the messenger settlement modes to the
> link that is being created?
>
Near as I
Hi Alan,
See inline for a few minor comments...
On Mon, Nov 24, 2014 at 3:00 PM, wrote:
> Repository: qpid-proton
> Updated Branches:
> refs/heads/master 3ac2e3bd3 -> 061da30be
>
>
> NO-JIRA: Fix protocol tracing for transactional states.
>
> Add transactions.xml to the set of files processed
Hi Everyone,
I managed to take advantage of a bit of my thanksgiving downtime to give
fadams' javascript branch some attention. I'm happy to report that thanks
mostly to his excellent work, it was fairly straightforward to bring his
branch up to date with respect to trunk. I've done this and pushe
On Wed, Dec 10, 2014 at 11:23 AM, Ken Giusti wrote:
> Hi,
>
> I've been working on a simple patch to qpidd that ports the AMQP 1.0
> module to the new event interface provided by proton 0.8. See
> https://issues.apache.org/jira/browse/QPID-6255 for the patch.
>
> With the above patch, I've notic
On Wed, Dec 10, 2014 at 5:10 PM, Andrew Stitcher
wrote:
> 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 qpi
We are currently working towards the 0.9 release in the upcoming weeks. The
roadmap is here:
- http://qpid.apache.org/proton/development.html
--Rafael
On Thu, Dec 11, 2014 at 9:11 AM, xavier wrote:
> Hi all,
>
> Do you where can I find the roadmap for qpid-proton library?
>
> Regards
>
>
>
>
Can you provide a bit more detail? I'm not the most expert git user, so I'm
not sure exactly what you're asking for, much less how to do it.
--Rafael
On Thu, Dec 11, 2014 at 11:30 AM, Darryl L. Pierce
wrote:
>
> Would it be possible for someone (Rafi?) to fix the merge commits in the
> Git repo?
On Thu, Dec 11, 2014 at 6:34 PM, Ken Giusti wrote:
>
>
>
> - Original Message -
> > From: "Rafael Schloming"
> > To: proton@qpid.apache.org
> > Sent: Wednesday, December 10, 2014 5:41:20 PM
> > Subject: Re: Observations on the performance of
On Fri, Dec 12, 2014 at 2:15 PM, Andrew Stitcher
wrote:
>
> 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 pushin
On Fri, Dec 12, 2014 at 10:56 AM, Ken Giusti wrote:
>
>
>
> - Original Message -
> > From: "Rafael Schloming"
> > To: proton@qpid.apache.org
> > Sent: Friday, December 12, 2014 10:21:04 AM
> > Subject: Re: Observations on the performance of
On Tue, Dec 16, 2014 at 10:48 AM, Andrew Stitcher
wrote:
>
> 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 while back I implemented a relatively complete standalone codec here:
https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2
It's quite a bit faster than the existing codec. I believe any new codec
work should probably be based on this. It's rela
Hi Everyone,
I've put together an alpha for proton 0.9. There are a couple of motivating
factors for introducing an alpha stage into the release process this time:
- there are some new APIs as well as changes to existing APIs that are
worthy of some extra review
- the install has changed a bi
Hi Andreas,
The x-amqp-foo output you see reported by the messaging API actually
correspond to message header values which are not the same thing as message
properties. There should be specific accessors on the message for all of
those fields, e.g. pn_message_get/set_creation_time(...).
--Rafael
em seems to be related to how the messaging client interacts
> with proton.
> The same client-server programs, same broker, run 2 messages OK using
> amqp0-10.
>
> I have not bisected or anything but a trunk build of 2014-12-10 worked.
>
> -Chuck
>
>
> - Origina
You should be able to call pn_messenger_accept(...) or
messenger.accpet(...) on the tracker of the message depending on what
flavor of the API you are using. In python, the tracker is returned when
you call get(...) in C you can access the tracker for the most recently
received message by using pn_
Hi Everyone,
I've been doing some work on a C reactor API for proton that is intended to
fit both alongside and underneath what gordon has been doing in pure
python. I have several goals with this work.
- Simplify/enable a reactive style of programming in C that is similar to
what gordon has bui
Attapattu <
> > rajit...@gmail.com> wrote:
> >
> >> Thanks Rafi, for the link.
> >> I agree that any work should use this as a basis.
> >>
> >> I plan to take a closer look at this in the next week or so.
> >>
> >> Rajith
> &g
My guess is we should probably be there in roughly a month. I am hoping to
get an alpha2 out later today and historically it's been about 3 weeks once
we reach roughly this point in the process.
--Rafael
On Fri, Jan 16, 2015 at 3:05 AM, xavier wrote:
> Hi all,
>
> Do you know when the qpid-proo
My intention is to support a variety of scenarios for I/O. I believe it is
a key requirement that we can create sockets/fds in either python or C and
regardless of where they are created, they need to be serviceable by a
single I/O loop written either buy us or by others in C or in pure python.
(I
On Mon, Jan 19, 2015 at 11:52 AM, Alan Conway wrote:
> On Wed, 2015-01-14 at 08:28 -0500, Rafael Schloming wrote:
> > Hi Everyone,
> >
> > I've been doing some work on a C reactor API for proton that is
> > intended to fit both alongside and underneath what g
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 anyone using this code in anyway? I would
like to at a minimum depreca
Yes, those are part of the driver API.
--Rafael
On Thu, Jan 22, 2015 at 11:08 AM, Darryl L. Pierce
wrote:
> On Thu, Jan 22, 2015 at 10:50:22AM -0500, Rafael Schloming wrote:
> > I just noticed that dispatch seems to have it's own copy of driver.c
> now. I
> > think that
The most important thing to get worked out for this is the memory
management semantics between C and Ruby. From what I can tell from your
branch, it looks like you haven't done that yet.
As I've said before, the first step to wrapping the engine API is to work
out a simple strategy for wrapping C
nd that
actually explain how to keep a reference from C to a Ruby object.
[1]
http://clalance.blogspot.com/2013/11/writing-ruby-extensions-in-c-part-13.html
--Rafael
On Fri, Jan 23, 2015 at 9:01 AM, Darryl L. Pierce
wrote:
> On Thu, Jan 22, 2015 at 12:08:52PM -0500, Rafael Schloming wrote:
>
, Darryl L. Pierce
wrote:
> On Fri, Jan 23, 2015 at 11:02:59AM -0500, Rafael Schloming wrote:
>
> > For more info on how to integrate with Ruby's GC you can read this
> > article[1]. It's one of the few pieces of documentation I've found that
> > actually
On Fri, Jan 23, 2015 at 12:18 PM, Alan Conway wrote:
> Sorry, I'm behind on this but - I have some small but very useful
> extensions to the new proton/utils.py that are used in dispatch. I
> would VERY much like to get them into proton 0.9.
>
> I will get them on master ASAP, is there another b
On Fri, Jan 23, 2015 at 2:08 PM, Darryl L. Pierce
wrote:
> On Fri, Jan 23, 2015 at 01:49:34PM -0500, Rafael Schloming wrote:
> > It does talk about what swig does, but it also talks about the other
> > direction:
> >
> > "If the C structure references other ruby
Hi Everyone,
I've put together an alpha 2 for Proton 0.9. I believe the memory issues
identified in alpha 1 are addressed. Source and binaries are posted in the
usual locations:
Source artifacts:
http://people.apache.org/~rhs/qpid-proton-0.9-alpha-2/
Java binaries:
https://repository.apac
Oops, my bad. I will follow up with an alpha 3 shortly...
--Rafael
On Mon, Jan 26, 2015 at 6:57 AM, Gordon Sim wrote:
> On 01/23/2015 09:27 PM, Rafael Schloming wrote:
>
>> Hi Everyone,
>>
>> I've put together an alpha 2 for Proton 0.9. I believe the memory issues
On Mon, Jan 26, 2015 at 8:53 AM, Gordon Sim wrote:
> On 01/26/2015 12:35 PM, Rafael Schloming wrote:
>
>> Oops, my bad. I will follow up with an alpha 3 shortly...
>>
>
> Though not related to the alpha specifically, it was pointed out to me
> that e.g. setting t
On Mon, Jan 26, 2015 at 9:43 AM, Alan Conway wrote:
> On Mon, 2015-01-19 at 13:57 -0500, Rafael Schloming wrote:
> > On Mon, Jan 19, 2015 at 11:52 AM, Alan Conway
> wrote:
> >
> > > On Wed, 2015-01-14 at 08:28 -0500, Rafael Schloming wrote:
> > > > Hi Ev
; new codec is a real improvement over the existing one.
> > > > Great job Rafi!
> > > >
> > > > Rajith
> > > >
> > > > On Tue, Jan 6, 2015 at 10:28 AM, Rajith Muditha Attapattu <
> > > > rajit...@gmail.com> wrote:
&g
Hi Alan,
The recently added stuff in utils.py seems to have broken the java build.
It uses the 'with' keyword which is apparently not supported in jython.
--Rafael
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 in.
--Rafael
On Tue, Jan 27, 2015 at 9:29 AM, Alan Conway wrote:
> On Tue, 2015-01-27 at 09:00 -0500, Rafael S
On Tue, Jan 27, 2015 at 5:35 PM, Darryl L. Pierce
wrote:
> On Fri, Jan 23, 2015 at 03:46:34PM -0500, Darryl L. Pierce wrote:
> > +1 Though, I was hoping we could avoid having to manually do things...
>
> So I have a working POC that assigns a Ruby object to a C struct in such
> a way as to keep t
On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce
wrote:
> On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote:
> > On the face of it this sounds like it could be quite brittle and probably
> > more complicated than just forgetting about swig for the one pn_rubyref_t
Why did you reject it then?
--Rafael
On Wed, Jan 28, 2015 at 9:54 AM, Darryl L. Pierce
wrote:
> On Wed, Jan 28, 2015 at 09:19:29AM -0500, Rafael Schloming wrote:
> > On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce
> > wrote:
> >
> > > On Wed, Jan 28, 20
On Wed, Jan 28, 2015 at 1:05 PM, Darryl L. Pierce
wrote:
> On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote:
> > Why did you reject it then?
>
> Reject it? I don't recall rejecting any option.
>
I meant why did you post about the global array thing and
n
you intentionally comment out the line of code that keeps the reference
alive?
--Rafael
On Wed, Jan 28, 2015 at 1:12 PM, Darryl L. Pierce
wrote:
> On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote:
> > Why did you reject it then?
>
> Are you referring to this?
>
> &quo
On Wed, Jan 28, 2015 at 2:01 PM, Rajith Muditha Attapattu <
rajit...@gmail.com> wrote:
> Rafi,
>
> I just checked in some skeleton code to explore a particular approach.
> It avoids the intermediate objects we have in proton now (Ex FlowType.java)
> Instead the Flow class is directly used by the e
On Thu, Jan 29, 2015 at 11:42 AM, Andrew Stitcher
wrote:
> 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
> > &g
On Thu, Jan 29, 2015 at 12:28 PM, Rajith Muditha Attapattu <
rajit...@gmail.com> wrote:
> Rafi could u pls answer the two questions I had in the code?
>
> 1. Your uint method only takes an int .. shouldn't it take a long? Bcos it
> could contain a value larger than a java int?
>
To be honest I do
I pushed some basic reactor examples into the proton tree under
examples/reactor/py. These are geared mostly towards
understanding/explaining the basic processing model of the event loop.
Please have a look. They are still a bit of a work in progress, as is the
API itself, but all feedback is welc
Hi,
I recently uncovered a puzzling issue with the Javascript bindings. If I
fire up the simple recv.js example and then run send.js, it works fine the
first time, but the second time around I get the error below. This
apparently has been happening for a while (possibly a few months), however
I ha
On Sat, Jan 31, 2015 at 7:29 AM, Fraser Adams wrote:
> Thanks for the heads up Rafi.
> I'll take a look when I've got a moment, that's not actually something
> I've noticed before.
>
> TBH I'm *pretty sure* that when I was developing this stuff I'd have done
> what you've done, so I'm a bit baffl
omething weird.
>
> I'll update my emscripten/fastcomp versions and see if that introduces
> this quirk.
>
> On the plus side, at least it wasn't my imagination and I really haven't
> seen this behaviour before :-D
>
> If it *is* an emscripten issue it'd b
101 - 200 of 629 matches
Mail list logo
