On Sun, Aug 18, 2013 at 09:54:41PM +0200, Jimmy Jones wrote:
Are you available to chat in IRC (Freenode #qpid channel) sometime?
I can do around 8.30-9.30pm UK time most days, if that doesn't work might
have to be email, sorry :(
That works, that's 3:30-4:30 EDT for me. Ping me in IRC (I'm
On Fri, Aug 16, 2013 at 01:55:15PM +0100, Gordon Sim wrote:
On 08/16/2013 01:15 PM, Darryl L. Pierce wrote:
I reverted my changes, and would like to collaborate with you on a
better, more considered solution to the problem of sending properties
from Perl and the other dynamic languages.
For
On 08/19/2013 03:21 PM, Darryl L. Pierce wrote:
On Fri, Aug 16, 2013 at 01:55:15PM +0100, Gordon Sim wrote:
On 08/16/2013 01:15 PM, Darryl L. Pierce wrote:
I reverted my changes, and would like to collaborate with you on a
better, more considered solution to the problem of sending properties
On Mon, Aug 19, 2013 at 04:20:01PM +0100, Gordon Sim wrote:
On 08/19/2013 03:21 PM, Darryl L. Pierce wrote:
The fundamental issue is that, regardless of the dynamic language,
properties aren't being encoded as UTF-8 at all.
Even if, in Perl, they are being set as UTF8? Are you saying that
On 08/19/2013 04:39 PM, Darryl L. Pierce wrote:
On Mon, Aug 19, 2013 at 04:20:01PM +0100, Gordon Sim wrote:
On 08/19/2013 03:21 PM, Darryl L. Pierce wrote:
The fundamental issue is that, regardless of the dynamic language,
properties aren't being encoded as UTF-8 at all.
Even if, in Perl,
On 08/19/2013 05:00 PM, Gordon Sim wrote:
On 08/19/2013 04:39 PM, Darryl L. Pierce wrote:
On Mon, Aug 19, 2013 at 04:20:01PM +0100, Gordon Sim wrote:
On 08/19/2013 03:21 PM, Darryl L. Pierce wrote:
The fundamental issue is that, regardless of the dynamic language,
properties aren't being
On 08/19/2013 05:36 PM, Gordon Sim wrote:
On 08/19/2013 05:00 PM, Gordon Sim wrote:
So, my question is whether you are saying that the test above (i.e. the
if statement) does not in fact work for some reason as a way to
determine whether to encode as str or bin?
Answering my own question
The code for the perl binding has the following test:
STRLEN len;
char *ptr = SvPV(value, len);
qpid::types::Variant v = qpid::types::Variant(std::string(ptr,len));
if (SvUTF8(value)) {
v.setEncoding(utf8);
}
I presume this is supposed to test whether the value passed in is UTF8
(this
The fundamental issue is that, regardless of the dynamic language,
properties aren't being encoded as UTF-8 at all.
I got bitten by this when running 0.18, but QPID-4442 provided a solution.
However I can see it might not be so easy with payload maps.
Jimmy
I'm a user of binary data in maps!
I created the patch to handle UTF8 in perl. Removing the check will cause
non-UTF8 strings to be casted into UTF8 which is probably a bad idea unless
by luck they are 7 bit ASCII.
Hey, Jimmy. I've been in training this week so haven't been able to
On Mon, Aug 12, 2013 at 08:52:20PM +0200, Jimmy Jones wrote:
I'm a user of binary data in maps!
I created the patch to handle UTF8 in perl. Removing the check will cause
non-UTF8 strings to be casted into UTF8 which is probably a bad idea unless
by luck they are 7 bit ASCII.
Hey, Jimmy.
On 08/16/2013 01:15 PM, Darryl L. Pierce wrote:
On Mon, Aug 12, 2013 at 08:52:20PM +0200, Jimmy Jones wrote:
I'm a user of binary data in maps!
I created the patch to handle UTF8 in perl. Removing the check will cause
non-UTF8 strings to be casted into UTF8 which is probably a bad idea unless
For python, this is indeed the solution we used when a user wanted the Java
client to recognize a python string sent in a map or an application
property.
On Fri, Aug 16, 2013 at 8:55 AM, Gordon Sim g...@redhat.com wrote:
On 08/16/2013 01:15 PM, Darryl L. Pierce wrote:
On Mon, Aug 12, 2013 at
On 08/12/2013 07:52 PM, Jimmy Jones wrote:
I'm a user of binary data in maps!
I created the patch to handle UTF8 in perl. Removing the check will
cause non-UTF8 strings to be casted into UTF8 which is probably a bad
idea unless by luck they are 7 bit ASCII.
That's a definite 'no' for 0.24
On 08/09/2013 09:55 PM, Darryl L. Pierce wrote:
The fix was to default encode strings from Ruby, Python and Perl using
UTF-8.
I have a couple of questions about this. While I certainly agree that
sending data as vstr is nearly always the right thing, the changes you
made - assuming I read
On 08/12/2013 11:26 AM, Gordon Sim wrote:
(Also, minor nit, you checked
in commented out code rather than removing it).
What's worse, you left a printf statement in for the ruby which I assume
was just for debug:
Modified: qpid/trunk/qpid/cpp/include/qpid/swig_ruby_typemaps.i
URL:
On 08/12/2013 11:31 AM, Gordon Sim wrote:
On 08/12/2013 11:26 AM, Gordon Sim wrote:
Modified: qpid/trunk/qpid/cpp/include/qpid/swig_ruby_typemaps.i
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/include/qpid/swig_ruby_typemaps.i?rev=1512482r1=1512481r2=1512482view=diff
/12/13 11:26 AM
To: dev@qpid.apache.org
Subject: Re: RFQ 0.24: Two JIRAs
On 08/09/2013 09:55 PM, Darryl L. Pierce wrote:
The fix was to default encode strings from Ruby, Python and Perl using
UTF-8.
I have a couple of questions about this. While I certainly agree that
sending data as vstr
The fix was to default encode strings from Ruby, Python and Perl using
UTF-8. I verified it with the Perl and Ruby clients again the Java Drain
tool and it works correctly.
The JIRAs are:
QPID-5067: Default string encoding for dynamic languages should be UTF-8
QPID-4835: JMS client is unable to
I saw no issues with the fix. Looks good to me.
Regards,
Weston
On Aug 9, 2013, at 4:55 PM, Darryl L. Pierce dpie...@redhat.com wrote:
The fix was to default encode strings from Ruby, Python and Perl using
UTF-8. I verified it with the Perl and Ruby clients again the Java Drain
tool and it
20 matches
Mail list logo
