date:20090730

Re: Add a protobuf-config script like the old gtk-config

2009-07-30 Thread Kenton Varda

New patch:  Use pkg-config instead.  Much simpler.

On Thu, Jul 30, 2009 at 10:05 AM, Jeff Bailey  wrote:

> I haven't done pkg-config stuff yet.  Maybe check in on #autotools in
> freenode.  I'm usually there, as are other people.
> Jeff Bailey >|< Google, Inc. >|< +1 514 670-8754
>
>
> On Thu, Jul 30, 2009 at 12:12 PM, Kenton Varda  wrote:
>
>> Yeargh, I'm behind the times.  pkg-config?  I guess I should be
>> integrating with that rather than writing my own script?
>>
>>
>> On Thu, Jul 30, 2009 at 9:05 AM, Jeff Bailey wrote:
>>
>>> lgtm
>>>
>>> 42 Packages which depend on Protocol Buffers should call this script
>>> automatically   43 as part of their own configure script.
>>>
>>> Provide an example with PKG_CONFIG or something like that.
>>>
>>> Otherwise, looks good.  Thanks!
>>>
>>> Jeff Bailey >|< Google, Inc. >|< +1 514 670-8754
>>>
>>>
>>> On Thu, Jul 30, 2009 at 12:00 PM, Kenton Varda wrote:
>>>
 (New patch set uploaded.)


 On Thu, Jul 30, 2009 at 8:59 AM, Kenton Varda wrote:

>
>
> On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey wrote:
>
>> *sigh*  It looks like the version at appspot.com isn't GA+ enabled,
>> so I sign in and it thinks I'm not signed in.
>> Anyhow, a few comments:
>>
>> Since it's generated by configure.ac, do you need it in bin_SCRIPTS?
>>  I think that might cause it to get looked at twice.
>>
>
> The purpose of putting it in bin_SCRIPTS is to make sure that it is
> installed, which configure is not going to do automatically.  The automake
> docs say that bin_SCRIPTS are by default not included in the dist, which 
> is
> what we want here (since configure generates it).
>
>
>> You should pretty much always do a set -e at the top of a shell script
>> to catch errors early on.
>>
>
> Oops, fixed.
>
>
>>
>>  *73* if test "@prefix@" != /usr -a "@prefix" != / -a "@prefix" !=
>> ""; then
>>
>> Should those all be @pre...@?
>>
>
> Yes.  :/
>
>
>> Also, I think test -a might be a bashism in this case.
>>
>
> Changed to "&& test".
>
>
>> Same for this line:
>>
>>
>>  *79* if test $full_library = true -o $explicit_library = false; then
>>
>
> Done.
>
> Also, I added --ldflags as a separate option since LDFLAGS and LIBS are
> traditionally separate.  Not sure why gtk-config itself does not do this.
>
> Also also, I expanded the help text.
>
> Also^3, I made --version strip the suffix ("-pre", "rc1", etc.) since I
> doubt anyone will correctly parse it otherwise (since people will code
> against official releases which have no suffix).
>


>>>
>>
>

--~--~-~--~~~---~--~~
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: Add a protobuf-config script like the old gtk-config

2009-07-30 Thread Jeff Bailey

I haven't done pkg-config stuff yet.  Maybe check in on #autotools in
freenode.  I'm usually there, as are other people.
Jeff Bailey >|< Google, Inc. >|< +1 514 670-8754

On Thu, Jul 30, 2009 at 12:12 PM, Kenton Varda  wrote:

> Yeargh, I'm behind the times.  pkg-config?  I guess I should be integrating
> with that rather than writing my own script?
>
>
> On Thu, Jul 30, 2009 at 9:05 AM, Jeff Bailey wrote:
>
>> lgtm
>>
>> 42 Packages which depend on Protocol Buffers should call this script
>> automatically   43 as part of their own configure script.
>>
>> Provide an example with PKG_CONFIG or something like that.
>>
>> Otherwise, looks good.  Thanks!
>>
>> Jeff Bailey >|< Google, Inc. >|< +1 514 670-8754
>>
>>
>> On Thu, Jul 30, 2009 at 12:00 PM, Kenton Varda  wrote:
>>
>>> (New patch set uploaded.)
>>>
>>>
>>> On Thu, Jul 30, 2009 at 8:59 AM, Kenton Varda  wrote:
>>>

 On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey wrote:

> *sigh*  It looks like the version at appspot.com isn't GA+ enabled, so
> I sign in and it thinks I'm not signed in.
> Anyhow, a few comments:
>
> Since it's generated by configure.ac, do you need it in bin_SCRIPTS?
>  I think that might cause it to get looked at twice.
>

 The purpose of putting it in bin_SCRIPTS is to make sure that it is
 installed, which configure is not going to do automatically.  The automake
 docs say that bin_SCRIPTS are by default not included in the dist, which is
 what we want here (since configure generates it).

> You should pretty much always do a set -e at the top of a shell script
> to catch errors early on.
>

 Oops, fixed.

>
>  *73* if test "@prefix@" != /usr -a "@prefix" != / -a "@prefix" != "";
> then
>
> Should those all be @pre...@?
>

 Yes.  :/

> Also, I think test -a might be a bashism in this case.
>

 Changed to "&& test".

> Same for this line:
>
>
>  *79* if test $full_library = true -o $explicit_library = false; then
>

 Done.

 Also, I added --ldflags as a separate option since LDFLAGS and LIBS are
 traditionally separate.  Not sure why gtk-config itself does not do this.

 Also also, I expanded the help text.

 Also^3, I made --version strip the suffix ("-pre", "rc1", etc.) since I
 doubt anyone will correctly parse it otherwise (since people will code
 against official releases which have no suffix).

>>>
>>>
>>
>

--~--~-~--~~~---~--~~
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: problem with the previous version

2009-07-30 Thread Kenton Varda

I need a lot more information to even begin speculating about this, such as
what language you are using and any error messages that were printed when it
"crashed".  A stack trace would also be nice.

On Thu, Jul 30, 2009 at 9:46 AM, muka  wrote:

>
> Hi,
>
> I have a problem with the previous version of google protocol buffer.
> I serialize an object of type X into a file A, then when trying to
> parse the file A with another object of type X, it crashs.
>
> The object of type X contains a lot of data, and repeated element. Is
> there some kind of possibility that it is linked to some security
> mechanisms ?
>
> cheers,
>
> pascal ly.
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

problem with the previous version

2009-07-30 Thread muka


Hi,

I have a problem with the previous version of google protocol buffer.
I serialize an object of type X into a file A, then when trying to
parse the file A with another object of type X, it crashs.

The object of type X contains a lot of data, and repeated element. Is
there some kind of possibility that it is linked to some security
mechanisms ?

cheers,

pascal ly.
--~--~-~--~~~---~--~~
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: Add a protobuf-config script like the old gtk-config

2009-07-30 Thread Kenton Varda

Yeargh, I'm behind the times.  pkg-config?  I guess I should be integrating
with that rather than writing my own script?

On Thu, Jul 30, 2009 at 9:05 AM, Jeff Bailey  wrote:

> lgtm
>
> 42 Packages which depend on Protocol Buffers should call this script
> automatically  43 as part of their own configure script.
>
> Provide an example with PKG_CONFIG or something like that.
>
> Otherwise, looks good.  Thanks!
>
> Jeff Bailey >|< Google, Inc. >|< +1 514 670-8754
>
>
> On Thu, Jul 30, 2009 at 12:00 PM, Kenton Varda  wrote:
>
>> (New patch set uploaded.)
>>
>>
>> On Thu, Jul 30, 2009 at 8:59 AM, Kenton Varda  wrote:
>>
>>>
>>>
>>> On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey wrote:
>>>
 *sigh*  It looks like the version at appspot.com isn't GA+ enabled, so
 I sign in and it thinks I'm not signed in.
 Anyhow, a few comments:

 Since it's generated by configure.ac, do you need it in bin_SCRIPTS?  I
 think that might cause it to get looked at twice.

>>>
>>> The purpose of putting it in bin_SCRIPTS is to make sure that it is
>>> installed, which configure is not going to do automatically.  The automake
>>> docs say that bin_SCRIPTS are by default not included in the dist, which is
>>> what we want here (since configure generates it).
>>>
>>>
 You should pretty much always do a set -e at the top of a shell script
 to catch errors early on.

>>>
>>> Oops, fixed.
>>>
>>>

  *73* if test "@prefix@" != /usr -a "@prefix" != / -a "@prefix" != "";
 then

 Should those all be @pre...@?

>>>
>>> Yes.  :/
>>>
>>>
 Also, I think test -a might be a bashism in this case.

>>>
>>> Changed to "&& test".
>>>
>>>
 Same for this line:


  *79* if test $full_library = true -o $explicit_library = false; then

>>>
>>> Done.
>>>
>>> Also, I added --ldflags as a separate option since LDFLAGS and LIBS are
>>> traditionally separate.  Not sure why gtk-config itself does not do this.
>>>
>>> Also also, I expanded the help text.
>>>
>>> Also^3, I made --version strip the suffix ("-pre", "rc1", etc.) since I
>>> doubt anyone will correctly parse it otherwise (since people will code
>>> against official releases which have no suffix).
>>>
>>
>>
>

--~--~-~--~~~---~--~~
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: Installation using cygwin fails

2009-07-30 Thread Kenton Varda

When you do it manually, does the program return an error code (even if it
"seems to work")?
Maybe you could run it in gdb to find out why it is returning an error?  (If
you do this, be sure to use a protoc that you compiled yourself, not the
prebuild one.)

Unfortunately since I can't reproduce this locally, I can't debug it myself.

On Thu, Jul 30, 2009 at 9:00 AM, Javier  wrote:

>
> doing it manually seems to work. the problem is that those
> instructions appear to be part of the make and even if I run them
> manually when I run the make command again it still tries to execute
> them and fails. I have also tried to find out what make Error 127
> means but I still haven't had any luck with that. And to think I did
> all of this on my Mac on the first try *sigh...
>
> On Jul 30, 10:14 am, Kenton Varda  wrote:
> > I don't see an actual error message in the log.  Did it not print one?
>  If
> > not, what happens when you run protoc manually?
> >
> > On Thu, Jul 30, 2009 at 7:17 AM, Javier 
> wrote:
> >
> > > So that fixed that. Sadly something else came up.
> >
> > > c:/mingw/bin/mingw32-make  all-recursive
> > > mingw32-make[1]: Entering directory `C:/appl/Cygwin/protobuf'
> > > Making all in .
> > > mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf'
> > > mingw32-make[2]: Nothing to be done for `all-am'.
> > > mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf'
> > > Making all in src
> > > mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf/src'./
> > > protoc.exe google/protobuf/unittest.proto google/protobuf/
> > > unittest_empty.proto
> > >  google/protobuf/unittest_import.proto google/protobuf/
> > > unittest_mset.proto google/protobuf/unittest_optimize_for.proto
> > > google/protobuf/unittest_embed_optimize_for.proto google/protobuf/
> > > unittest_custom_options.proto google/protobuf/compiler/cpp/
> > > cpp_test_bad_identifiers.proto -I. --cpp_out=.
> >
> > > mingw32-make[2]: *** [unittest_proto_middleman] Error 127
> > > mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf/src'
> > > mingw32-make[1]: *** [all-recursive] Error 1
> > > mingw32-make[1]: Leaving directory `C:/appl/Cygwin/protobuf'
> > > mingw32-make: *** [all] Error 2
> >
> > > My guess is the protoc compiler is failing at some point but I'm not
> > > sure why. I even tried changing the protoc.exe file for the one that's
> > > available for download but it gave me the same error.
> >
> > > On Jul 29, 3:28 pm, Kenton Varda  wrote:
> > > > Odd.  Here's a longshot idea:  Try compiling from inside the Cygwin
> tree,
> > > > e.g. create a /src directory and unpack the protobuf package there.
>  This
> > > > would avoid any possible confusion between "C:/" vs. "/cygdrive/c".
>  But
> > > I
> > > > don't know if it will actually help.
> > > > On Wed, Jul 29, 2009 at 12:27 PM, Javier <
> espinosa.javie...@gmail.com
> > > >wrote:
> >
> > > > > > > eventually it says there is a libprotobuf.a file inside /.libs
> dir
> > > > > > > that cannot be found (no such file or directory) and then stops
> > > > > > > executing. The file IS there, I checked.
> >
> > > > > > I have not seen that in my testing.  What exact arguments did you
> > > pass to
> > > > > > configure and make?  Can you send the full error log?  (I doubt
> I'll
> > > be
> > > > > able
> > > > > > to figure it out but maybe there's something there.)
> >
> > > > > I just did ./configure then make. no arguments.
> > > > > This is the error log (edited for readability):
> >
> > > > > libtool: link: ar cru .libs/libprotoc.a  code_generator.o
> > > > > command_line_interface.o cpp_enum.o cpp_enum_field.o
> cpp_extension.o
> > > > > cpp_field.o cpp_file.o cpp_generator.o
> > > > > cpp_helpers.o cpp_message.o cpp_message_field.o
> cpp_primitive_field.o
> > > > > cpp_service.o cpp_string_field.o java_enum.o java_enum_field.o
> > > > > java_extension.o java_field.o
> > > > > java_file.o java_generator.o java_helpers.o java_message.o
> > > > > java_message_field.o java_primitive_field.o java_service.o
> > > > > python_generator.o
> >
> > > > > libtool: link: ranlib .libs/libprotoc.a
> > > > > libtool: link: ( cd ".libs" && rm -f "libprotoc.la" && ln -s "../
> > > > > libprotoc.la" "libprotoc.la" )
> >
> > > > > C:/appl/Cygwin/bin/sh.exe ../libtool --tag=CXX   --mode=link g++  -
> > > > > Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g
> -
> > > > > DNDEBUG   -o protoc.exe main.o  libprotobuf.la libprotoc.la
> > > > > libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-
> > > > > sign-compare-O2 -g -DNDEBUG -o protoc.exe main.o  ./.libs/
> > > > > libprotobuf.a ./.libs/libprotoc.a
> > > > > /cygdrive/c/protobuf/src/.libs/libprotobuf.a
> > > > > g++.exe: /cygdrive/c/protobuf/src/.libs/libprotobuf.a: No such file
> or
> > > > > directory
> >
> > > > > mingw32-make[2]: *** [protoc.exe] Error 1
> > > > > mingw32-make[2]: Leaving directory `c:/protobuf/src'
> > > > > mingw32-make[1]: *** [all-recursive] Error 1
> > > > > mingw32-m

Re: Add a protobuf-config script like the old gtk-config

2009-07-30 Thread Jeff Bailey

lgtm

42 Packages which depend on Protocol Buffers should call this script
automatically  43 as part of their own configure script.

Provide an example with PKG_CONFIG or something like that.

Otherwise, looks good.  Thanks!

Jeff Bailey >|< Google, Inc. >|< +1 514 670-8754


On Thu, Jul 30, 2009 at 12:00 PM, Kenton Varda  wrote:

> (New patch set uploaded.)
>
>
> On Thu, Jul 30, 2009 at 8:59 AM, Kenton Varda  wrote:
>
>>
>>
>> On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey wrote:
>>
>>> *sigh*  It looks like the version at appspot.com isn't GA+ enabled, so I
>>> sign in and it thinks I'm not signed in.
>>> Anyhow, a few comments:
>>>
>>> Since it's generated by configure.ac, do you need it in bin_SCRIPTS?  I
>>> think that might cause it to get looked at twice.
>>>
>>
>> The purpose of putting it in bin_SCRIPTS is to make sure that it is
>> installed, which configure is not going to do automatically.  The automake
>> docs say that bin_SCRIPTS are by default not included in the dist, which is
>> what we want here (since configure generates it).
>>
>>
>>> You should pretty much always do a set -e at the top of a shell script to
>>> catch errors early on.
>>>
>>
>> Oops, fixed.
>>
>>
>>>
>>>  *73* if test "@prefix@" != /usr -a "@prefix" != / -a "@prefix" != "";
>>> then
>>>
>>> Should those all be @pre...@?
>>>
>>
>> Yes.  :/
>>
>>
>>> Also, I think test -a might be a bashism in this case.
>>>
>>
>> Changed to "&& test".
>>
>>
>>> Same for this line:
>>>
>>>
>>>  *79* if test $full_library = true -o $explicit_library = false; then
>>>
>>
>> Done.
>>
>> Also, I added --ldflags as a separate option since LDFLAGS and LIBS are
>> traditionally separate.  Not sure why gtk-config itself does not do this.
>>
>> Also also, I expanded the help text.
>>
>> Also^3, I made --version strip the suffix ("-pre", "rc1", etc.) since I
>> doubt anyone will correctly parse it otherwise (since people will code
>> against official releases which have no suffix).
>>
>
>

--~--~-~--~~~---~--~~
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: Message type scope resolution

2009-07-30 Thread Kenton Varda

In other words, the scoping semantics are just like C++ namespaces, but we
use . rather than :: as the scope separator.

On Thu, Jul 30, 2009 at 1:50 AM, Constantinos Michael
wrote:

> Try doing this:
> message foo {
>   message X { }
>   message bar {
> message X { }
> message abc {
>   *optional foo.X abc_x = 1;*
> }
>   }
> }
>
> You can also prefix the type with a dot, e.g.
>
> optional *.**foo.X* abc_x = 1;
>
> That has the effect of fully qualifying the message, as you can enclose the
> entire message foo above in another message foo, which also provides an X,
> and have these fields in the innermost message:
>
> optional *.**foo.X* x1 = 1;   // outer foo
> optional *.**foo.foo.X* x2 = 2;  // inner foo
> optional *foo.X* x3 = 3;  // inner foo
>
> -Constantinos
>
> On Thu, Jul 30, 2009 at 5:22 AM, naderp  wrote:
>
>>
>> Hi,
>>
>> Does the protocol buffer language have a mechanism for resolving types
>> across scopes. Eg, given
>>
>> message foo {
>>message X {}
>>
>>message bar {
>>message X{}
>>
>>message abc {
>>message foo:X<--- This is not legal, but how
>> do you do it?
>>
>>}
>>}
>> }
>>
>> Thanks.
>>
>>
>
>
> --
> - Constantinos Michael
>
> >
>

--~--~-~--~~~---~--~~
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: Installation using cygwin fails

2009-07-30 Thread Javier


doing it manually seems to work. the problem is that those
instructions appear to be part of the make and even if I run them
manually when I run the make command again it still tries to execute
them and fails. I have also tried to find out what make Error 127
means but I still haven't had any luck with that. And to think I did
all of this on my Mac on the first try *sigh...

On Jul 30, 10:14 am, Kenton Varda  wrote:
> I don't see an actual error message in the log.  Did it not print one?  If
> not, what happens when you run protoc manually?
>
> On Thu, Jul 30, 2009 at 7:17 AM, Javier  wrote:
>
> > So that fixed that. Sadly something else came up.
>
> > c:/mingw/bin/mingw32-make  all-recursive
> > mingw32-make[1]: Entering directory `C:/appl/Cygwin/protobuf'
> > Making all in .
> > mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf'
> > mingw32-make[2]: Nothing to be done for `all-am'.
> > mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf'
> > Making all in src
> > mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf/src'./
> > protoc.exe google/protobuf/unittest.proto google/protobuf/
> > unittest_empty.proto
> >  google/protobuf/unittest_import.proto google/protobuf/
> > unittest_mset.proto google/protobuf/unittest_optimize_for.proto
> > google/protobuf/unittest_embed_optimize_for.proto google/protobuf/
> > unittest_custom_options.proto google/protobuf/compiler/cpp/
> > cpp_test_bad_identifiers.proto -I. --cpp_out=.
>
> > mingw32-make[2]: *** [unittest_proto_middleman] Error 127
> > mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf/src'
> > mingw32-make[1]: *** [all-recursive] Error 1
> > mingw32-make[1]: Leaving directory `C:/appl/Cygwin/protobuf'
> > mingw32-make: *** [all] Error 2
>
> > My guess is the protoc compiler is failing at some point but I'm not
> > sure why. I even tried changing the protoc.exe file for the one that's
> > available for download but it gave me the same error.
>
> > On Jul 29, 3:28 pm, Kenton Varda  wrote:
> > > Odd.  Here's a longshot idea:  Try compiling from inside the Cygwin tree,
> > > e.g. create a /src directory and unpack the protobuf package there.  This
> > > would avoid any possible confusion between "C:/" vs. "/cygdrive/c".  But
> > I
> > > don't know if it will actually help.
> > > On Wed, Jul 29, 2009 at 12:27 PM, Javier  > >wrote:
>
> > > > > > eventually it says there is a libprotobuf.a file inside /.libs dir
> > > > > > that cannot be found (no such file or directory) and then stops
> > > > > > executing. The file IS there, I checked.
>
> > > > > I have not seen that in my testing.  What exact arguments did you
> > pass to
> > > > > configure and make?  Can you send the full error log?  (I doubt I'll
> > be
> > > > able
> > > > > to figure it out but maybe there's something there.)
>
> > > > I just did ./configure then make. no arguments.
> > > > This is the error log (edited for readability):
>
> > > > libtool: link: ar cru .libs/libprotoc.a  code_generator.o
> > > > command_line_interface.o cpp_enum.o cpp_enum_field.o cpp_extension.o
> > > > cpp_field.o cpp_file.o cpp_generator.o
> > > > cpp_helpers.o cpp_message.o cpp_message_field.o cpp_primitive_field.o
> > > > cpp_service.o cpp_string_field.o java_enum.o java_enum_field.o
> > > > java_extension.o java_field.o
> > > > java_file.o java_generator.o java_helpers.o java_message.o
> > > > java_message_field.o java_primitive_field.o java_service.o
> > > > python_generator.o
>
> > > > libtool: link: ranlib .libs/libprotoc.a
> > > > libtool: link: ( cd ".libs" && rm -f "libprotoc.la" && ln -s "../
> > > > libprotoc.la" "libprotoc.la" )
>
> > > > C:/appl/Cygwin/bin/sh.exe ../libtool --tag=CXX   --mode=link g++  -
> > > > Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -
> > > > DNDEBUG   -o protoc.exe main.o  libprotobuf.la libprotoc.la
> > > > libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-
> > > > sign-compare-O2 -g -DNDEBUG -o protoc.exe main.o  ./.libs/
> > > > libprotobuf.a ./.libs/libprotoc.a
> > > > /cygdrive/c/protobuf/src/.libs/libprotobuf.a
> > > > g++.exe: /cygdrive/c/protobuf/src/.libs/libprotobuf.a: No such file or
> > > > directory
>
> > > > mingw32-make[2]: *** [protoc.exe] Error 1
> > > > mingw32-make[2]: Leaving directory `c:/protobuf/src'
> > > > mingw32-make[1]: *** [all-recursive] Error 1
> > > > mingw32-make[1]: Leaving directory `c:/protobuf'
> > > > mingw32-make: *** [all] Error 2
--~--~-~--~~~---~--~~
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: Add a protobuf-config script like the old gtk-config

2009-07-30 Thread Kenton Varda

(New patch set uploaded.)

On Thu, Jul 30, 2009 at 8:59 AM, Kenton Varda  wrote:

>
>
> On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey wrote:
>
>> *sigh*  It looks like the version at appspot.com isn't GA+ enabled, so I
>> sign in and it thinks I'm not signed in.
>> Anyhow, a few comments:
>>
>> Since it's generated by configure.ac, do you need it in bin_SCRIPTS?  I
>> think that might cause it to get looked at twice.
>>
>
> The purpose of putting it in bin_SCRIPTS is to make sure that it is
> installed, which configure is not going to do automatically.  The automake
> docs say that bin_SCRIPTS are by default not included in the dist, which is
> what we want here (since configure generates it).
>
>
>> You should pretty much always do a set -e at the top of a shell script to
>> catch errors early on.
>>
>
> Oops, fixed.
>
>
>>
>>  *73* if test "@prefix@" != /usr -a "@prefix" != / -a "@prefix" != "";
>> then
>>
>> Should those all be @pre...@?
>>
>
> Yes.  :/
>
>
>> Also, I think test -a might be a bashism in this case.
>>
>
> Changed to "&& test".
>
>
>> Same for this line:
>>
>>
>>  *79* if test $full_library = true -o $explicit_library = false; then
>>
>
> Done.
>
> Also, I added --ldflags as a separate option since LDFLAGS and LIBS are
> traditionally separate.  Not sure why gtk-config itself does not do this.
>
> Also also, I expanded the help text.
>
> Also^3, I made --version strip the suffix ("-pre", "rc1", etc.) since I
> doubt anyone will correctly parse it otherwise (since people will code
> against official releases which have no suffix).
>

--~--~-~--~~~---~--~~
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: Add a protobuf-config script like the old gtk-config

2009-07-30 Thread Kenton Varda

On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey  wrote:

> *sigh*  It looks like the version at appspot.com isn't GA+ enabled, so I
> sign in and it thinks I'm not signed in.
> Anyhow, a few comments:
>
> Since it's generated by configure.ac, do you need it in bin_SCRIPTS?  I
> think that might cause it to get looked at twice.
>

The purpose of putting it in bin_SCRIPTS is to make sure that it is
installed, which configure is not going to do automatically.  The automake
docs say that bin_SCRIPTS are by default not included in the dist, which is
what we want here (since configure generates it).

> You should pretty much always do a set -e at the top of a shell script to
> catch errors early on.
>

Oops, fixed.

>
>  *73* if test "@prefix@" != /usr -a "@prefix" != / -a "@prefix" != "";
> then
>
> Should those all be @pre...@?
>

Yes.  :/

> Also, I think test -a might be a bashism in this case.
>

Changed to "&& test".

> Same for this line:
>
>
>  *79* if test $full_library = true -o $explicit_library = false; then
>

Done.

Also, I added --ldflags as a separate option since LDFLAGS and LIBS are
traditionally separate.  Not sure why gtk-config itself does not do this.

Also also, I expanded the help text.

Also^3, I made --version strip the suffix ("-pre", "rc1", etc.) since I
doubt anyone will correctly parse it otherwise (since people will code
against official releases which have no suffix).

--~--~-~--~~~---~--~~
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: How to sort the repeated element?

2009-07-30 Thread 李海波


thanks,this is what i looking for.

On Jul 30, 2:28 am, Kenton Varda  wrote:
> In C++, you can use the standard STL sort() 
> function:http://www.sgi.com/tech/stl/sort.html
>
> RepeatedPtrField supports iterators,
> so you can do something like:
>
>   #include 
>
>   struct StudentOrdering {
>     inline operator()(const Student* a, const Student* b) {
>       return a->score() < b->score();
>     }
>   }
>
>   void SortStudents(Class* cls) {
>     std::sort(cls->mutable_student()->begin(),
>               cls->mutable_student()->end(),
>               StudentOrdering());
>   }
>
>
>
> On Tue, Jul 28, 2009 at 8:03 PM, 李海波  wrote:
>
> > example:
> > ==.proto file 
> > message Class{
> >    message Student{
> >        required string name = 1;
> >        required int32 score  = 2;
> >    }
>
> >    repeated Student student = 1;
> > }
> > =
>
> > I want to sort students of the class by score,how can i do?- Hide quoted 
> > text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
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: ExtensionRegistry usage.

2009-07-30 Thread Kenton Varda

The Builder interface has a method setField() which takes a FieldDescriptor
and a value.  You can pass the FieldDescriptor for an extension to set an
extension, and pass the message object as the value.  You can get the
FieldDescriptor from ExtensionRegistry or from
GeneratedExtension.getDescriptor().

On Thu, Jul 30, 2009 at 3:29 AM, Brice Figureau

> wrote:

>
> Hi,
>
> I'm just starting using Protocol Buffers for Java for a network
> protocol.
>
> Here is how I designed my proto file:
>
> request.proto:
> message Message {
>enum Type {
>AUTH = 100;
>  CHAT = 101;
>...
>}
>
>required Type type = 1;
>optional int32 id = 2;
>
>extensions 100 to max;
> }
>
> message AuthRequest {
>extend Message {
>optional AuthRequest auth_request = 100;
>}
>required string name = 1;
>required string pass = 2;
> }
>
> message ChatRequest {
>extend Message {
>optional ChatRequest chat_request = 101;
>}
>required int32 player_id = 1;
>optional string message_string = 2;
> }
>
> This is based on the Union Types technique described in the
> documentation.
>
> Now, all is well, I can do:
> ChatRequest chat =
> ChatRequest.newBuilder().setMessage(msg).setPlayerId(id).build();
> Message request =
> Message.newBuilder().setType(Type.CHAT).setExtension(ChatRequest.chatRequest,
> fChatRequest).build();
> and then serialize request to the wire.
>
> What I'm trying to achieve now is to generalize this operation for all
> my defined request types, using the descriptors and registry extension:
>
> ExtensionRegistry registry = ExtensionRegistry.newInstance();
> Request.registerAllExtensions(registry);
> ...
>
> Then I can create "generically" a builder for a given type with:
>
> public Builder getBuilder(Type type)
> {
>  ExtensionRegistry.ExtensionInfo info =
> registry.findExtensionByNumber(Message.getDescriptor(), type.getNumber());
>  return info.defaultInstance.newBuilderForType();
> }
> And on client call site:
> ChatRequest chat = (ChatRequest.Builder)getBuilder(Type.CHAT);
> chat.setPlayerId(id)...
>
> Now, I'm trying to generically associate this ChatRequest to the correct
> Extension field in the Message type, but unfortunately I can't find a
> way of doing that, because setExtension() requires a
> GeneratedMessage.GeneratedExtension which I can't have generically (ie
> the extension registry even though generated with this information,
> doesn't keep it).
> What's worse is tha the Extension Registry has all the information, but
> I can't recreate this specific generic type or add the extension from
> the Registry information.
>
> First question: how can I solve this?
> Second question: if it's not solvable, then that means I'm not using PB
> as it was intended. In this case, how should I use it?
>
> Thanks,
> --
> Brice Figureau
> My Blog: http://www.masterzen.fr/
>
>
> >
>

--~--~-~--~~~---~--~~
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: Installation using cygwin fails

2009-07-30 Thread Kenton Varda

I don't see an actual error message in the log.  Did it not print one?  If
not, what happens when you run protoc manually?

On Thu, Jul 30, 2009 at 7:17 AM, Javier  wrote:

>
> So that fixed that. Sadly something else came up.
>
> c:/mingw/bin/mingw32-make  all-recursive
> mingw32-make[1]: Entering directory `C:/appl/Cygwin/protobuf'
> Making all in .
> mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf'
> mingw32-make[2]: Nothing to be done for `all-am'.
> mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf'
> Making all in src
> mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf/src'./
> protoc.exe google/protobuf/unittest.proto google/protobuf/
> unittest_empty.proto
>  google/protobuf/unittest_import.proto google/protobuf/
> unittest_mset.proto google/protobuf/unittest_optimize_for.proto
> google/protobuf/unittest_embed_optimize_for.proto google/protobuf/
> unittest_custom_options.proto google/protobuf/compiler/cpp/
> cpp_test_bad_identifiers.proto -I. --cpp_out=.
>
> mingw32-make[2]: *** [unittest_proto_middleman] Error 127
> mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf/src'
> mingw32-make[1]: *** [all-recursive] Error 1
> mingw32-make[1]: Leaving directory `C:/appl/Cygwin/protobuf'
> mingw32-make: *** [all] Error 2
>
> My guess is the protoc compiler is failing at some point but I'm not
> sure why. I even tried changing the protoc.exe file for the one that's
> available for download but it gave me the same error.
>
> On Jul 29, 3:28 pm, Kenton Varda  wrote:
> > Odd.  Here's a longshot idea:  Try compiling from inside the Cygwin tree,
> > e.g. create a /src directory and unpack the protobuf package there.  This
> > would avoid any possible confusion between "C:/" vs. "/cygdrive/c".  But
> I
> > don't know if it will actually help.
> > On Wed, Jul 29, 2009 at 12:27 PM, Javier  >wrote:
> >
> >
> >
> > > > > eventually it says there is a libprotobuf.a file inside /.libs dir
> > > > > that cannot be found (no such file or directory) and then stops
> > > > > executing. The file IS there, I checked.
> >
> > > > I have not seen that in my testing.  What exact arguments did you
> pass to
> > > > configure and make?  Can you send the full error log?  (I doubt I'll
> be
> > > able
> > > > to figure it out but maybe there's something there.)
> >
> > > I just did ./configure then make. no arguments.
> > > This is the error log (edited for readability):
> >
> > > libtool: link: ar cru .libs/libprotoc.a  code_generator.o
> > > command_line_interface.o cpp_enum.o cpp_enum_field.o cpp_extension.o
> > > cpp_field.o cpp_file.o cpp_generator.o
> > > cpp_helpers.o cpp_message.o cpp_message_field.o cpp_primitive_field.o
> > > cpp_service.o cpp_string_field.o java_enum.o java_enum_field.o
> > > java_extension.o java_field.o
> > > java_file.o java_generator.o java_helpers.o java_message.o
> > > java_message_field.o java_primitive_field.o java_service.o
> > > python_generator.o
> >
> > > libtool: link: ranlib .libs/libprotoc.a
> > > libtool: link: ( cd ".libs" && rm -f "libprotoc.la" && ln -s "../
> > > libprotoc.la" "libprotoc.la" )
> >
> > > C:/appl/Cygwin/bin/sh.exe ../libtool --tag=CXX   --mode=link g++  -
> > > Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -
> > > DNDEBUG   -o protoc.exe main.o  libprotobuf.la libprotoc.la
> > > libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-
> > > sign-compare-O2 -g -DNDEBUG -o protoc.exe main.o  ./.libs/
> > > libprotobuf.a ./.libs/libprotoc.a
> > > /cygdrive/c/protobuf/src/.libs/libprotobuf.a
> > > g++.exe: /cygdrive/c/protobuf/src/.libs/libprotobuf.a: No such file or
> > > directory
> >
> > > mingw32-make[2]: *** [protoc.exe] Error 1
> > > mingw32-make[2]: Leaving directory `c:/protobuf/src'
> > > mingw32-make[1]: *** [all-recursive] Error 1
> > > mingw32-make[1]: Leaving directory `c:/protobuf'
> > > mingw32-make: *** [all] Error 2
> >
>

--~--~-~--~~~---~--~~
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: Installation using cygwin fails

2009-07-30 Thread Javier


So that fixed that. Sadly something else came up.

c:/mingw/bin/mingw32-make  all-recursive
mingw32-make[1]: Entering directory `C:/appl/Cygwin/protobuf'
Making all in .
mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf'
mingw32-make[2]: Nothing to be done for `all-am'.
mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf'
Making all in src
mingw32-make[2]: Entering directory `C:/appl/Cygwin/protobuf/src'./
protoc.exe google/protobuf/unittest.proto google/protobuf/
unittest_empty.proto
 google/protobuf/unittest_import.proto google/protobuf/
unittest_mset.proto google/protobuf/unittest_optimize_for.proto
google/protobuf/unittest_embed_optimize_for.proto google/protobuf/
unittest_custom_options.proto google/protobuf/compiler/cpp/
cpp_test_bad_identifiers.proto -I. --cpp_out=.

mingw32-make[2]: *** [unittest_proto_middleman] Error 127
mingw32-make[2]: Leaving directory `C:/appl/Cygwin/protobuf/src'
mingw32-make[1]: *** [all-recursive] Error 1
mingw32-make[1]: Leaving directory `C:/appl/Cygwin/protobuf'
mingw32-make: *** [all] Error 2

My guess is the protoc compiler is failing at some point but I'm not
sure why. I even tried changing the protoc.exe file for the one that's
available for download but it gave me the same error.

On Jul 29, 3:28 pm, Kenton Varda  wrote:
> Odd.  Here's a longshot idea:  Try compiling from inside the Cygwin tree,
> e.g. create a /src directory and unpack the protobuf package there.  This
> would avoid any possible confusion between "C:/" vs. "/cygdrive/c".  But I
> don't know if it will actually help.
> On Wed, Jul 29, 2009 at 12:27 PM, Javier wrote:
>
>
>
> > > > eventually it says there is a libprotobuf.a file inside /.libs dir
> > > > that cannot be found (no such file or directory) and then stops
> > > > executing. The file IS there, I checked.
>
> > > I have not seen that in my testing.  What exact arguments did you pass to
> > > configure and make?  Can you send the full error log?  (I doubt I'll be
> > able
> > > to figure it out but maybe there's something there.)
>
> > I just did ./configure then make. no arguments.
> > This is the error log (edited for readability):
>
> > libtool: link: ar cru .libs/libprotoc.a  code_generator.o
> > command_line_interface.o cpp_enum.o cpp_enum_field.o cpp_extension.o
> > cpp_field.o cpp_file.o cpp_generator.o
> > cpp_helpers.o cpp_message.o cpp_message_field.o cpp_primitive_field.o
> > cpp_service.o cpp_string_field.o java_enum.o java_enum_field.o
> > java_extension.o java_field.o
> > java_file.o java_generator.o java_helpers.o java_message.o
> > java_message_field.o java_primitive_field.o java_service.o
> > python_generator.o
>
> > libtool: link: ranlib .libs/libprotoc.a
> > libtool: link: ( cd ".libs" && rm -f "libprotoc.la" && ln -s "../
> > libprotoc.la" "libprotoc.la" )
>
> > C:/appl/Cygwin/bin/sh.exe ../libtool --tag=CXX   --mode=link g++  -
> > Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -
> > DNDEBUG   -o protoc.exe main.o  libprotobuf.la libprotoc.la
> > libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-
> > sign-compare-O2 -g -DNDEBUG -o protoc.exe main.o  ./.libs/
> > libprotobuf.a ./.libs/libprotoc.a
> > /cygdrive/c/protobuf/src/.libs/libprotobuf.a
> > g++.exe: /cygdrive/c/protobuf/src/.libs/libprotobuf.a: No such file or
> > directory
>
> > mingw32-make[2]: *** [protoc.exe] Error 1
> > mingw32-make[2]: Leaving directory `c:/protobuf/src'
> > mingw32-make[1]: *** [all-recursive] Error 1
> > mingw32-make[1]: Leaving directory `c:/protobuf'
> > mingw32-make: *** [all] Error 2
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

ExtensionRegistry usage.

2009-07-30 Thread Brice Figureau


Hi,

I'm just starting using Protocol Buffers for Java for a network
protocol.

Here is how I designed my proto file:

request.proto:
message Message {
enum Type {
AUTH = 100;
  CHAT = 101;
...
}

required Type type = 1;
optional int32 id = 2;

extensions 100 to max;
}

message AuthRequest {
extend Message {
optional AuthRequest auth_request = 100;
}   
required string name = 1;
required string pass = 2;
}

message ChatRequest {
extend Message {
optional ChatRequest chat_request = 101;
}
required int32 player_id = 1;
optional string message_string = 2;
}

This is based on the Union Types technique described in the
documentation.

Now, all is well, I can do:
ChatRequest chat = 
ChatRequest.newBuilder().setMessage(msg).setPlayerId(id).build();
Message request = 
Message.newBuilder().setType(Type.CHAT).setExtension(ChatRequest.chatRequest, 
fChatRequest).build();
and then serialize request to the wire.

What I'm trying to achieve now is to generalize this operation for all
my defined request types, using the descriptors and registry extension:

ExtensionRegistry registry = ExtensionRegistry.newInstance();
Request.registerAllExtensions(registry);
...

Then I can create "generically" a builder for a given type with:

public Builder getBuilder(Type type)
{
  ExtensionRegistry.ExtensionInfo info = 
registry.findExtensionByNumber(Message.getDescriptor(), type.getNumber());
  return info.defaultInstance.newBuilderForType();
}
And on client call site:
ChatRequest chat = (ChatRequest.Builder)getBuilder(Type.CHAT);
chat.setPlayerId(id)...

Now, I'm trying to generically associate this ChatRequest to the correct
Extension field in the Message type, but unfortunately I can't find a
way of doing that, because setExtension() requires a
GeneratedMessage.GeneratedExtension which I can't have generically (ie
the extension registry even though generated with this information,
doesn't keep it).
What's worse is tha the Extension Registry has all the information, but
I can't recreate this specific generic type or add the extension from
the Registry information.

First question: how can I solve this?
Second question: if it's not solvable, then that means I'm not using PB
as it was intended. In this case, how should I use it?

Thanks,
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/


--~--~-~--~~~---~--~~
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: Message type scope resolution

2009-07-30 Thread Constantinos Michael

Try doing this:
message foo {
  message X { }
  message bar {
message X { }
message abc {
  *optional foo.X abc_x = 1;*
}
  }
}

You can also prefix the type with a dot, e.g.

optional *.**foo.X* abc_x = 1;

That has the effect of fully qualifying the message, as you can enclose the
entire message foo above in another message foo, which also provides an X,
and have these fields in the innermost message:

optional *.**foo.X* x1 = 1;   // outer foo
optional *.**foo.foo.X* x2 = 2;  // inner foo
optional *foo.X* x3 = 3;  // inner foo

-Constantinos

On Thu, Jul 30, 2009 at 5:22 AM, naderp  wrote:

>
> Hi,
>
> Does the protocol buffer language have a mechanism for resolving types
> across scopes. Eg, given
>
> message foo {
>message X {}
>
>message bar {
>message X{}
>
>message abc {
>message foo:X<--- This is not legal, but how
> do you do it?
>
>}
>}
> }
>
> Thanks.
> >
>


-- 
- Constantinos Michael

--~--~-~--~~~---~--~~
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: Add a protobuf-config script like the old gtk-config

Re: Add a protobuf-config script like the old gtk-config

Re: problem with the previous version

problem with the previous version

Re: Add a protobuf-config script like the old gtk-config

Re: Installation using cygwin fails

Re: Add a protobuf-config script like the old gtk-config

Re: Message type scope resolution

Re: Installation using cygwin fails

Re: Add a protobuf-config script like the old gtk-config

Re: Add a protobuf-config script like the old gtk-config

Re: How to sort the repeated element?

Re: ExtensionRegistry usage.

Re: Installation using cygwin fails

Re: Installation using cygwin fails

ExtensionRegistry usage.

Re: Message type scope resolution

17 matches

Site Navigation

Mail list logo

Footer information