Re: ppc7400 instead ppc architecture when building on macosx
Hi, You could try to add the -mmacosx-version-min=10.4 I solve it by the argument Regards, Ben On Jun 11, 9:41 am, G.Angel george.georg...@citrixonline.com wrote: Hi, I’m trying to build the protocol buffers for macosx with fat support for i386 and ppc. I’m using this script to do it: # Configure with flags to build Universal binaries env CFLAGS='-arch i386 -arch ppc' LDFLAGS='-arch i386 -arch ppc' CXXFLAGS='-arch i386 -arch ppc' \ sh ./configure --prefix=$PWD/$OUTPUT_DIR --disable-dependency- tracking --enable-static --disable-shared # Make the various targets make make check make install It works perfect except that every application for ppc with dependency on this library magically is built for ppc7400. Can anyone help me figure out what might be the issue? G.Angel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Windows HANDLE and sockets / named pipes
It looks interesting, however because this is for commercial software the licence doesn't work for us. Thanks, Brodie On Jun 19, 12:45 pm, xiliu tang xiliu.t...@gmail.com wrote: 2009/6/19 brodie brofi...@gmail.com Hi all, Has anyone done any work to create a stream implementation for async use? In particular, Windows async sockets or async named pipes? I'm planning to implement PB as the messaging layer on top of a Windows sockets transport layer (therefore using HANDLE instead of a file descripter). We may additionally make this layer swappable with named pipes (also a HANDLE). Transport in both cases will be done async. On Linux/OSX we will just use async sockets. It would be nice if someone has already done some work in this area that I can leverage/build on. Any pointers? http://code.google.com/p/server1/ http://code.google.com/p/server1/It implement base on the boost asio, which is cross platform. Regards, Brodie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Windows HANDLE and sockets / named pipes
If the entire message needs to be in the buffer at one time before it
can be parsed out, then it makes parsing out the messages easier. i.e.
either the message is complete or not. Is there an interface to parse
a generic message from the buffer? There doesn't seem to be. I'm
envisaging usage something like this...
something buf;
Message * msg
while (receiveData(buf)) {
rc = Factory::parse(buf, msg);
if (rc == INCOMPLETE) continue;
switch (msg-type()) {
... process ...
}
}
The proto2 RPC doesn't appear to fit my usages because my message
stream is not strictly request/response. There can be multiple request
messages in a row, ditto for responses.
Regards,
Brodie
On Jun 19, 12:47 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com wrote:
Note that the protocol buffer parser is not asynchronous. That means you
either need to feed it an entire message at once, or it will need to block
waiting for mode data to arrive on
s/mode/more
the input stream. So if you want to do something asynchronous, you best
bet is probably to do your own buffering until you have received an entire
message, then pass the bytes off to the protobuf parser. You probably won't
need to implement any custom ZeroCopyStreams for that.
On Thu, Jun 18, 2009 at 8:30 PM, brodie brofi...@gmail.com wrote:
Hi all,
Has anyone done any work to create a stream implementation for async
use? In particular, Windows async sockets or async named pipes?
I'm planning to implement PB as the messaging layer on top of a
Windows sockets transport layer (therefore using HANDLE instead of a
file descripter). We may additionally make this layer swappable with
named pipes (also a HANDLE). Transport in both cases will be done
async. On Linux/OSX we will just use async sockets.
It would be nice if someone has already done some work in this area
that I can leverage/build on. Any pointers?
Regards,
Brodie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Windows HANDLE and sockets / named pipes
No, protocol buffers are not self-describing. The receiver needs to know
what type it is receiving, or you need to send the type information over the
wire separately.
On Fri, Jun 19, 2009 at 1:10 AM, brodie brofi...@gmail.com wrote:
If the entire message needs to be in the buffer at one time before it
can be parsed out, then it makes parsing out the messages easier. i.e.
either the message is complete or not. Is there an interface to parse
a generic message from the buffer? There doesn't seem to be. I'm
envisaging usage something like this...
something buf;
Message * msg
while (receiveData(buf)) {
rc = Factory::parse(buf, msg);
if (rc == INCOMPLETE) continue;
switch (msg-type()) {
... process ...
}
}
The proto2 RPC doesn't appear to fit my usages because my message
stream is not strictly request/response. There can be multiple request
messages in a row, ditto for responses.
Regards,
Brodie
On Jun 19, 12:47 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com wrote:
Note that the protocol buffer parser is not asynchronous. That means
you
either need to feed it an entire message at once, or it will need to
block
waiting for mode data to arrive on
s/mode/more
the input stream. So if you want to do something asynchronous, you
best
bet is probably to do your own buffering until you have received an
entire
message, then pass the bytes off to the protobuf parser. You probably
won't
need to implement any custom ZeroCopyStreams for that.
On Thu, Jun 18, 2009 at 8:30 PM, brodie brofi...@gmail.com wrote:
Hi all,
Has anyone done any work to create a stream implementation for async
use? In particular, Windows async sockets or async named pipes?
I'm planning to implement PB as the messaging layer on top of a
Windows sockets transport layer (therefore using HANDLE instead of a
file descripter). We may additionally make this layer swappable with
named pipes (also a HANDLE). Transport in both cases will be done
async. On Linux/OSX we will just use async sockets.
It would be nice if someone has already done some work in this area
that I can leverage/build on. Any pointers?
Regards,
Brodie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
NaN default value
Hi. Is there a way to specify NaN as a default value for a double type member in a .proto file . Regards, Dragan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Windows HANDLE and sockets / named pipes
(Sorry Kenton, I missed adding the list as recipient...)
We're using a very simple approach where we send only one type of
message containing a type-enum and one or more optional fields (I
think this technique is described in the manual). In order to be able
to read the message in full before parsing it, we first send a 32-bit
integer containing the size of the message, and then read that many
bytes. Really not very complicated.
On Fri, Jun 19, 2009 at 10:53 AM, Kenton Vardaken...@google.com wrote:
No, protocol buffers are not self-describing. The receiver needs to know
what type it is receiving, or you need to send the type information over the
wire separately.
On Fri, Jun 19, 2009 at 1:10 AM, brodie brofi...@gmail.com wrote:
If the entire message needs to be in the buffer at one time before it
can be parsed out, then it makes parsing out the messages easier. i.e.
either the message is complete or not. Is there an interface to parse
a generic message from the buffer? There doesn't seem to be. I'm
envisaging usage something like this...
something buf;
Message * msg
while (receiveData(buf)) {
rc = Factory::parse(buf, msg);
if (rc == INCOMPLETE) continue;
switch (msg-type()) {
... process ...
}
}
The proto2 RPC doesn't appear to fit my usages because my message
stream is not strictly request/response. There can be multiple request
messages in a row, ditto for responses.
Regards,
Brodie
On Jun 19, 12:47 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com wrote:
Note that the protocol buffer parser is not asynchronous. That means
you
either need to feed it an entire message at once, or it will need to
block
waiting for mode data to arrive on
s/mode/more
the input stream. So if you want to do something asynchronous, you
best
bet is probably to do your own buffering until you have received an
entire
message, then pass the bytes off to the protobuf parser. You probably
won't
need to implement any custom ZeroCopyStreams for that.
On Thu, Jun 18, 2009 at 8:30 PM, brodie brofi...@gmail.com wrote:
Hi all,
Has anyone done any work to create a stream implementation for async
use? In particular, Windows async sockets or async named pipes?
I'm planning to implement PB as the messaging layer on top of a
Windows sockets transport layer (therefore using HANDLE instead of a
file descripter). We may additionally make this layer swappable with
named pipes (also a HANDLE). Transport in both cases will be done
async. On Linux/OSX we will just use async sockets.
It would be nice if someone has already done some work in this area
that I can leverage/build on. Any pointers?
Regards,
Brodie
--
/Jesper
#include witty-quote.h
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Decoders for Network Analyzer (Wireshark/Ethereal)
Hello, I am evaluating using Protocol Buffers for objects that are shared across a distributed system. One key thing I would like is a way to look at these objects on the wire by sniffing the IP traffic in my network. Traditionally, we have written custom decoders for sniffers such as Wireshark/Ethereal to decode packets of our custom protcols into something human-friendly. Does anyone know if there is some sort of decoders for the Protocol Buffer encoding scheme? What have others done to view network traffic encoded using Protocol Buffers? Thanks, Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Decoders for Network Analyzer (Wireshark/Ethereal)
http://code.google.com/p/protobuf-wireshark/ I haven't tried it myself yet, but I believe it can generically dump any protobuf message (with no field names, and some ambiguity about types that share wire encodings), or if you give it a .proto file it can dump field names and accurate data types. -- Jeremy Leader jlea...@oversee.net Jon M wrote: Hello, I am evaluating using Protocol Buffers for objects that are shared across a distributed system. One key thing I would like is a way to look at these objects on the wire by sniffing the IP traffic in my network. Traditionally, we have written custom decoders for sniffers such as Wireshark/Ethereal to decode packets of our custom protcols into something human-friendly. Does anyone know if there is some sort of decoders for the Protocol Buffer encoding scheme? What have others done to view network traffic encoded using Protocol Buffers? Thanks, Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Windows HANDLE and sockets / named pipes
Yep, that's described here:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
On Fri, Jun 19, 2009 at 1:00 PM, Jesper Eskilson jes...@eskilson.se wrote:
(Sorry Kenton, I missed adding the list as recipient...)
We're using a very simple approach where we send only one type of
message containing a type-enum and one or more optional fields (I
think this technique is described in the manual). In order to be able
to read the message in full before parsing it, we first send a 32-bit
integer containing the size of the message, and then read that many
bytes. Really not very complicated.
On Fri, Jun 19, 2009 at 10:53 AM, Kenton Vardaken...@google.com wrote:
No, protocol buffers are not self-describing. The receiver needs to know
what type it is receiving, or you need to send the type information over
the
wire separately.
On Fri, Jun 19, 2009 at 1:10 AM, brodie brofi...@gmail.com wrote:
If the entire message needs to be in the buffer at one time before it
can be parsed out, then it makes parsing out the messages easier. i.e.
either the message is complete or not. Is there an interface to parse
a generic message from the buffer? There doesn't seem to be. I'm
envisaging usage something like this...
something buf;
Message * msg
while (receiveData(buf)) {
rc = Factory::parse(buf, msg);
if (rc == INCOMPLETE) continue;
switch (msg-type()) {
... process ...
}
}
The proto2 RPC doesn't appear to fit my usages because my message
stream is not strictly request/response. There can be multiple request
messages in a row, ditto for responses.
Regards,
Brodie
On Jun 19, 12:47 pm, Kenton Varda ken...@google.com wrote:
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda ken...@google.com
wrote:
Note that the protocol buffer parser is not asynchronous. That
means
you
either need to feed it an entire message at once, or it will need to
block
waiting for mode data to arrive on
s/mode/more
the input stream. So if you want to do something asynchronous, you
best
bet is probably to do your own buffering until you have received an
entire
message, then pass the bytes off to the protobuf parser. You
probably
won't
need to implement any custom ZeroCopyStreams for that.
On Thu, Jun 18, 2009 at 8:30 PM, brodie brofi...@gmail.com wrote:
Hi all,
Has anyone done any work to create a stream implementation for
async
use? In particular, Windows async sockets or async named pipes?
I'm planning to implement PB as the messaging layer on top of a
Windows sockets transport layer (therefore using HANDLE instead of
a
file descripter). We may additionally make this layer swappable
with
named pipes (also a HANDLE). Transport in both cases will be done
async. On Linux/OSX we will just use async sockets.
It would be nice if someone has already done some work in this area
that I can leverage/build on. Any pointers?
Regards,
Brodie
--
/Jesper
#include witty-quote.h
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: NaN default value
Currently, no, that is not supported. I'm happy to accept a patch which adds the ability to use infinity and nan as default values for doubles and floats. On Fri, Jun 19, 2009 at 6:53 AM, dragan mihajlovic mihajlovic.dra...@gmail.com wrote: Hi. Is there a way to specify NaN as a default value for a double type member in a .proto file . Regards, Dragan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
