Re: [protobuf] Support for J2ME
Hi Kenton,
*It seems to me that combining them would only be more work for both of us.
I would need you to be available...*
I haven't thought the whole thing through. You're right. It makes more sense
to keep my implementation in a separated project. Thanks for all the
advices.
Thanks,
-Gatis
On Mon, Mar 15, 2010 at 7:54 PM, Kenton Varda ken...@google.com wrote:
I wonder if we should consider making mutable-message mode a feature of the
base implementation, rather than j2me-specific. Some people have requested
this, even though I personally think the builder-based design is better.
On Fri, Mar 12, 2010 at 7:13 PM, Igor Gatis igorga...@gmail.com wrote:
My experience with J2ME says performance is not the most important feature
for the majority of the applications. Trust me when I say JAR size is the
one people care the most.
OK, you would know better than me.
I still need to go over all files to check code compliance with the style
guide and write tests. But besides that, do you think I still need to change
the design?
Based on my high-level look, what you have seems good. But, you don't need
my approval for anything.
Are you still hoping to add this to the official distribution? If so, can
I ask why you prefer this over maintaining your own project? It seems to me
that combining them would only be more work for both of us. I would need
you to be available to update and test your implementation any time I'm
trying to do a release or making Java code generator changes. Also, you
would not be able to release updates to your implementation separately from
the protobuf release cycle, which is probably far too slow for a new
project. With the decentralized approach, you do not have to depend on me
and I do not have to depend on you.
On Fri, Mar 12, 2010 at 9:10 PM, Kenton Varda ken...@google.com wrote:
This may solve the problem but adding code to every setter may have a
significant cost. It's harder to inline the setter this way. But it's hard
to say exactly what the cost will be without some sort of benchmarks.
On Fri, Mar 12, 2010 at 12:12 PM, Igor Gatis igorga...@gmail.comwrote:
I think I have a solution for the readonly messages.
Message.java now includes the following header:
public abstract class Message {
private boolean readOnly;
protected Message(boolean noInit) {
this.readOnly = true;
}
public Message() {}
protected void assertNotReadOnly() {
if (readOnly) {
throw new RuntimeException(Read only message!);
}
}
A generated message, HelloRequest, has:
public final class HelloRequest extends com.google.protobuf.Message {
public HelloRequest() {
initFields();
}
private HelloRequest(boolean noInit) { super(true); }
All methods that can modify HelloRequest look like this:
public void setName(java.lang.String value) {
assertNotReadOnly();
hasName = true;
name_ = value;
}
In other words, that example:
myMessage.getSubMessage().setFoo(1);
Would through an exception. just like
Collections.unmodifiableList(java.util.List)http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)
does.
Do you think this solves the problem?
On Fri, Mar 12, 2010 at 4:16 PM, Igor Gatis igorga...@gmail.comwrote:
myMessage.getSubMessage().setFoo(1);
If they haven't previously called setSubMessage(new SubMessage()) then
this code will actually modify the shared default instance of SubMessage
which could cause all sorts of bugs around the system. Have you
considered
how to avoid this problem?
Uh, not really. But yeah, that's definitely a problem. Let me think
about that. I'll get back to you when I have a solution for this problem.
So the bottom line is that I had to squeeze the runtime to get it as
small as possible - this is a fully functional protobuf runtime
implementation that occupies 26KB against 173KB of standard Java
implementation.
Did you start from the lite implementation or the full one?
26k is pretty impressive.
Yep, I though LITE_RUNTIME would solve all my problems but generics and
for-each loops were a problem.
Flattening the Message class has a few side effects I haven't noticed
until I implemented equals() and hashCode() methods.
A bad effect is that now that there is no way to handle fields in a
generic way, these methods are generated for each message, which makes the
size per message bigger. For a small set of messages, that's not a
problem -
and that is the most common scenario for J2ME apps.
A good one is that obfuscators usually removed unused methods. If user
never uses equals or hashCode, they will be selectively removed. That was
not possible when AbstractMessage was there.
BTW, I removed the generic services generation too.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to
[protobuf] kInitialSize in RepeatedField
Hi all,
let's say you have a large number of messages of the same type in
memory. One field of this type is marked as repeated:
message Test {
repeated uint64 foo = 1;
}
RepeatedField defines the default size to be 4. If most of my objects
have 5 foos, I waste a lot of memory.
Is it possible to make kInitialSize into a template parameter of
RepeatedField? Thatway I could have different default sizes for
different message types. The message description could provide an
option for setting a new default length:
message Test {
repeated uint64 foo = 1 [default_size=5];
}
Cheers,
Thorsten
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@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: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
appearantly I didn't notice that when I clicked the .sln file, it opened with VS2005... I only started looking into it when compilation failed with the 2005 version. Linking with the 2005 version failed, the linker error I got was something to do with std::Base_container contstructor/destructor. I guess that's what changed between VS2005 and VS2008. On Tue, Mar 16, 2010 at 12:16 AM, Kenton Varda ken...@google.com wrote: I actually maintain the project files using VS2008, but I run a hack script that downgrades them to VS2005 (by simply replacing the version number) before release so that VS2005 users can use the package. I'm confused about how you managed to compile the project using VS2008 without it automatically upgrading the files. Doesn't VS immediately prompt you to upgrade when you open them? I'm also confused why compilation would fail, considering that the only difference between the 2005 and 2008 versions of the project files is the version number. I definitely do not want to try to maintain two separate copies of the VS project files. Maintaining one set is already painful enough. I really dislike the MSVC build system. On Sun, Mar 14, 2010 at 2:49 PM, Austin Ziegler halosta...@gmail.comwrote: On Sun, Mar 14, 2010 at 3:15 PM, Marc Gravell marc.grav...@gmail.com wrote: I'm really glad you found the cause of this; you had me worried I'd done something horrible with the .NET encoding ;-p Probably one for Kenton, but I wonder if it might be prudent to include VS2008 (and presumably VS2010) project files for the core project? We've got some VS2008 versions we can contribute; we deliberately created them in parallel to to the existing vs/ directory. -austin -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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: [protobuf] Support for J2ME
Great! I look forward to seeing it.
On Tue, Mar 16, 2010 at 6:38 AM, Igor Gatis igorga...@gmail.com wrote:
Hi Kenton,
*It seems to me that combining them would only be more work for both of
us. I would need you to be available...*
I haven't thought the whole thing through. You're right. It makes more
sense to keep my implementation in a separated project. Thanks for all the
advices.
Thanks,
-Gatis
On Mon, Mar 15, 2010 at 7:54 PM, Kenton Varda ken...@google.com wrote:
I wonder if we should consider making mutable-message mode a feature of
the base implementation, rather than j2me-specific. Some people have
requested this, even though I personally think the builder-based design is
better.
On Fri, Mar 12, 2010 at 7:13 PM, Igor Gatis igorga...@gmail.com wrote:
My experience with J2ME says performance is not the most important
feature for the majority of the applications. Trust me when I say JAR size
is the one people care the most.
OK, you would know better than me.
I still need to go over all files to check code compliance with the style
guide and write tests. But besides that, do you think I still need to change
the design?
Based on my high-level look, what you have seems good. But, you don't
need my approval for anything.
Are you still hoping to add this to the official distribution? If so, can
I ask why you prefer this over maintaining your own project? It seems to me
that combining them would only be more work for both of us. I would need
you to be available to update and test your implementation any time I'm
trying to do a release or making Java code generator changes. Also, you
would not be able to release updates to your implementation separately from
the protobuf release cycle, which is probably far too slow for a new
project. With the decentralized approach, you do not have to depend on me
and I do not have to depend on you.
On Fri, Mar 12, 2010 at 9:10 PM, Kenton Varda ken...@google.com wrote:
This may solve the problem but adding code to every setter may have a
significant cost. It's harder to inline the setter this way. But it's
hard
to say exactly what the cost will be without some sort of benchmarks.
On Fri, Mar 12, 2010 at 12:12 PM, Igor Gatis igorga...@gmail.comwrote:
I think I have a solution for the readonly messages.
Message.java now includes the following header:
public abstract class Message {
private boolean readOnly;
protected Message(boolean noInit) {
this.readOnly = true;
}
public Message() {}
protected void assertNotReadOnly() {
if (readOnly) {
throw new RuntimeException(Read only message!);
}
}
A generated message, HelloRequest, has:
public final class HelloRequest extends com.google.protobuf.Message {
public HelloRequest() {
initFields();
}
private HelloRequest(boolean noInit) { super(true); }
All methods that can modify HelloRequest look like this:
public void setName(java.lang.String value) {
assertNotReadOnly();
hasName = true;
name_ = value;
}
In other words, that example:
myMessage.getSubMessage().setFoo(1);
Would through an exception. just like
Collections.unmodifiableList(java.util.List)http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)
does.
Do you think this solves the problem?
On Fri, Mar 12, 2010 at 4:16 PM, Igor Gatis igorga...@gmail.comwrote:
myMessage.getSubMessage().setFoo(1);
If they haven't previously called setSubMessage(new SubMessage())
then this code will actually modify the shared default instance of
SubMessage which could cause all sorts of bugs around the system. Have
you
considered how to avoid this problem?
Uh, not really. But yeah, that's definitely a problem. Let me think
about that. I'll get back to you when I have a solution for this problem.
So the bottom line is that I had to squeeze the runtime to get it as
small as possible - this is a fully functional protobuf runtime
implementation that occupies 26KB against 173KB of standard Java
implementation.
Did you start from the lite implementation or the full one?
26k is pretty impressive.
Yep, I though LITE_RUNTIME would solve all my problems but generics
and for-each loops were a problem.
Flattening the Message class has a few side effects I haven't noticed
until I implemented equals() and hashCode() methods.
A bad effect is that now that there is no way to handle fields in a
generic way, these methods are generated for each message, which makes
the
size per message bigger. For a small set of messages, that's not a
problem -
and that is the most common scenario for J2ME apps.
A good one is that obfuscators usually removed unused methods. If user
never uses equals or hashCode, they will be selectively removed. That was
not possible when AbstractMessage was there.
BTW, I removed the generic services generation too.
--
You received this message
Re: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
I do test each release with both VS2005 and VS2008, and haven't seen that problem before. Odd. On Mon, Mar 15, 2010 at 10:54 PM, Roey Lehman roey...@gmail.com wrote: appearantly I didn't notice that when I clicked the .sln file, it opened with VS2005... I only started looking into it when compilation failed with the 2005 version. Linking with the 2005 version failed, the linker error I got was something to do with std::Base_container contstructor/destructor. I guess that's what changed between VS2005 and VS2008. On Tue, Mar 16, 2010 at 12:16 AM, Kenton Varda ken...@google.com wrote: I actually maintain the project files using VS2008, but I run a hack script that downgrades them to VS2005 (by simply replacing the version number) before release so that VS2005 users can use the package. I'm confused about how you managed to compile the project using VS2008 without it automatically upgrading the files. Doesn't VS immediately prompt you to upgrade when you open them? I'm also confused why compilation would fail, considering that the only difference between the 2005 and 2008 versions of the project files is the version number. I definitely do not want to try to maintain two separate copies of the VS project files. Maintaining one set is already painful enough. I really dislike the MSVC build system. On Sun, Mar 14, 2010 at 2:49 PM, Austin Ziegler halosta...@gmail.comwrote: On Sun, Mar 14, 2010 at 3:15 PM, Marc Gravell marc.grav...@gmail.com wrote: I'm really glad you found the cause of this; you had me worried I'd done something horrible with the .NET encoding ;-p Probably one for Kenton, but I wonder if it might be prudent to include VS2008 (and presumably VS2010) project files for the core project? We've got some VS2008 versions we can contribute; we deliberately created them in parallel to to the existing vs/ directory. -austin -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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: [protobuf] kInitialSize in RepeatedField
You can, of course, modify the value all you want in your copy of the code.
However, the value is only useful if it is a compile-time constant, so we
can't really parameterize it in general. Note that if you change the value,
you must recompile libprotobuf and anything you have that depends on it.
On Tue, Mar 16, 2010 at 5:39 AM, Thorsten schu...@gmail.com wrote:
Hi all,
let's say you have a large number of messages of the same type in
memory. One field of this type is marked as repeated:
message Test {
repeated uint64 foo = 1;
}
RepeatedField defines the default size to be 4. If most of my objects
have 5 foos, I waste a lot of memory.
Is it possible to make kInitialSize into a template parameter of
RepeatedField? Thatway I could have different default sizes for
different message types. The message description could provide an
option for setting a new default length:
message Test {
repeated uint64 foo = 1 [default_size=5];
}
Cheers,
Thorsten
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@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.
[protobuf] LNK2019 and LNK2001 problems in MSVS2008
Hi. I use MSVS2008 and I have next problem: I installed protocol buffers from vsprojects folder in Debug mode, like it was recomended in readme.txt. Next step I took example proto-file addressbook.proto and I had compiled it by using proto.exe (that i had got above). I created new solution and added in it next files: addressbook.pb.h, addressbook.pb.cc, add_person.cc (from examples folder) Solution comiles fine, but while linking process I have many errors like this: addressbook.pb.obj : error LNK2019: unresolved external symbol public: __thiscall google::protobuf::internal::GeneratedMessageReflection::GeneratedMessageReflection(class google::protobuf::Descriptor const *,class google::protobuf::Message const *,int const * const,int,int,int,class google::protobuf::DescriptorPool const *,class google::protobuf::MessageFactory *,int) (?? 0generatedmessagereflect...@internal@proto...@google@@q...@pbvdescriptor@2...@pbvmessage@2...@qbpbvdescriptorpool@2...@pavmessagefactory@2...@h@Z) referenced in function void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void) (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2019: unresolved external symbol public: static class google::protobuf::MessageFactory * __cdecl google::protobuf::MessageFactory::generated_factory(void) (? generated_fact...@messagefactory@proto...@google@@sapav...@xz) referenced in function void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void) (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2019: unresolved external symbol public: __thiscall google::protobuf::internal::LogMessage::~LogMessage(void) (?? 1logmess...@internal@proto...@google@@q...@xz) referenced in function void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void) (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2001: unresolved external symbol public: virtual class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall google::protobuf::Message::GetTypeName(void)const (? gettypen...@message@proto...@google@@ube?av?$basic_str...@du? $char_tra...@d@std@@v?$alloca...@d@2@@std@@XZ) total 69 errors. I cannot solve this probelm. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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: [protobuf] kInitialSize in RepeatedField
We can't make it a template parameter because it would break reflection,
which depends on being able to find the RepeatedField objects via pointer
offsets. If it doesn't know exactly which template instance of
RepeatedField it is looking for it wouldn't work.
On Tue, Mar 16, 2010 at 2:00 PM, Kenton Varda ken...@google.com wrote:
You can, of course, modify the value all you want in your copy of the code.
However, the value is only useful if it is a compile-time constant, so we
can't really parameterize it in general. Note that if you change the value,
you must recompile libprotobuf and anything you have that depends on it.
On Tue, Mar 16, 2010 at 5:39 AM, Thorsten schu...@gmail.com wrote:
Hi all,
let's say you have a large number of messages of the same type in
memory. One field of this type is marked as repeated:
message Test {
repeated uint64 foo = 1;
}
RepeatedField defines the default size to be 4. If most of my objects
have 5 foos, I waste a lot of memory.
Is it possible to make kInitialSize into a template parameter of
RepeatedField? Thatway I could have different default sizes for
different message types. The message description could provide an
option for setting a new default length:
message Test {
repeated uint64 foo = 1 [default_size=5];
}
Cheers,
Thorsten
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@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: [protobuf] LNK2019 and LNK2001 problems in MSVS2008
You need to link the example against libprotobuf.lib. On Tue, Mar 16, 2010 at 1:43 PM, mohito moh...@inbox.ru wrote: Hi. I use MSVS2008 and I have next problem: I installed protocol buffers from vsprojects folder in Debug mode, like it was recomended in readme.txt. Next step I took example proto-file addressbook.proto and I had compiled it by using proto.exe (that i had got above). I created new solution and added in it next files: addressbook.pb.h, addressbook.pb.cc, add_person.cc (from examples folder) Solution comiles fine, but while linking process I have many errors like this: addressbook.pb.obj : error LNK2019: unresolved external symbol public: __thiscall google::protobuf::internal::GeneratedMessageReflection::GeneratedMessageReflection(class google::protobuf::Descriptor const *,class google::protobuf::Message const *,int const * const,int,int,int,class google::protobuf::DescriptorPool const *,class google::protobuf::MessageFactory *,int) (?? 0generatedmessagereflect...@internal@proto...@google@@q...@pbvdescriptor @2...@pbvmessage@2...@qbpbvdescriptorpool@2...@pavmessagefactory@2...@h@Z) referenced in function void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void) (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2019: unresolved external symbol public: static class google::protobuf::MessageFactory * __cdecl google::protobuf::MessageFactory::generated_factory(void) (? generated_fact...@messagefactory@proto...@google@@sapav...@xz) referenced in function void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void) (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2019: unresolved external symbol public: __thiscall google::protobuf::internal::LogMessage::~LogMessage(void) (?? 1logmess...@internal@proto...@google@@q...@xz) referenced in function void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void) (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2001: unresolved external symbol public: virtual class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall google::protobuf::Message::GetTypeName(void)const (? gettypen...@message@proto...@google@@ube?av?$basic_str...@du? $char_tra...@d@std@@v?$alloca...@d@2@@std@@XZ) total 69 errors. I cannot solve this probelm. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
On Tue, Mar 16, 2010 at 3:24 PM, Kenton Varda ken...@google.com wrote: I do test each release with both VS2005 and VS2008, and haven't seen that problem before. Odd. Do you have 2005 and 2008 on a single system, or are they on independent systems? If they're on the same system, VS does not always offer to upgrade, but opens the VS projects in the same VS that they were created in. You have to explicitly force them to upgrade. I agree that if you can avoid it, you shouldn't maintain two different sets of vsproj files, but if all you're doing is downconverting a vs2008 vsproj to vs2005, then it couldn't hurt to ship both in the tarball, even in separate directories. -austin -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
On Tue, Mar 16, 2010 at 6:11 PM, Austin Ziegler halosta...@gmail.comwrote: On Tue, Mar 16, 2010 at 3:24 PM, Kenton Varda ken...@google.com wrote: I do test each release with both VS2005 and VS2008, and haven't seen that problem before. Odd. Do you have 2005 and 2008 on a single system, or are they on independent systems? If they're on the same system, VS does not always offer to upgrade, but opens the VS projects in the same VS that they were created in. You have to explicitly force them to upgrade. Different systems. I agree that if you can avoid it, you shouldn't maintain two different sets of vsproj files, but if all you're doing is downconverting a vs2008 vsproj to vs2005, then it couldn't hurt to ship both in the tarball, even in separate directories. It also wouldn't help, because they are exactly the same except for the version number, and if a VS2008 user tries to open them, it auto-converts them to VS2008. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
On Tue, Mar 16, 2010 at 10:21 PM, Kenton Varda ken...@google.com wrote: On Tue, Mar 16, 2010 at 6:11 PM, Austin Ziegler halosta...@gmail.com wrote: On Tue, Mar 16, 2010 at 3:24 PM, Kenton Varda ken...@google.com wrote: I do test each release with both VS2005 and VS2008, and haven't seen that problem before. Odd. Do you have 2005 and 2008 on a single system, or are they on independent systems? If they're on the same system, VS does not always offer to upgrade, but opens the VS projects in the same VS that they were created in. You have to explicitly force them to upgrade. Different systems. I agree that if you can avoid it, you shouldn't maintain two different sets of vsproj files, but if all you're doing is downconverting a vs2008 vsproj to vs2005, then it couldn't hurt to ship both in the tarball, even in separate directories. It also wouldn't help, because they are exactly the same except for the version number, and if a VS2008 user tries to open them, it auto-converts them to VS2008. Except in the case where the user has both VS2005 and VS2008 installed on the same system. As many of the developers at my place of work do. If you give me VS2005 projects and I have both VS2005 and VS2008 installed, I have to explicitly open the VS2005 projects with VS2008 to make them work. This also may not work in scenarios where someone may need to provide compiled versions that work with VS2005 and VS2008 (separately built versions). It's able to be worked around (we copied the VS2005 projects to a new directory and forced them to be opened with VS2008), but it is a little annoying. -austin -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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.
