Compiling on AIX 5.3 using xlC 3.55 compiler
Hello guys,
I am actually attempting to compile protocol buffer source on
AIX 5.3 and xlC 3.55 .
It seems that I am able to compile it correctly but when it tried to
use created protoc compiler it fails.
So following it the snapshot of what happens when I do make. basically
it can not replace ./$^ with appropriate prerequisites
bash-3.00$ make
make all-recursive
Making all in .
Target "all-am" is up to date.
Making all in src
./ -I. --cpp_out=.
/bin/sh: ./: 0403-006 Execute permission denied.
make: 1254-004 The error code from the last command is 126.
Stop.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 2.
Stop.
While when I do gmake it works but then it goes in to infinite loop
some where
bash-3.00$ gmake
gmake all-recursive
gmake[1]: Entering directory `/work/vpatil/protobuf-2.1.0'
Making all in .
gmake[2]: Entering directory `/work/vpatil/protobuf-2.1.0'
gmake[2]: Leaving directory `/work/vpatil/protobuf-2.1.0'
Making all in src
gmake[2]: Entering directory `/work/vpatil/protobuf-2.1.0/src'
./protoc google/protobuf/test.proto -I. --cpp_out=.
* test.proto is the the simplest proto file we can have
test.proto :
package testPackage;
// option optimize_for = SPEED;
message TestAllTypes {
optionaluint32 optional_int32= 1;
}
I created this simplest proto file to check whether it works fine. But
when I tried tocompile it with create protoc binary ( .libs/lt-
protoc ) it blocked in infinite loop.
But with "option" uncommented it creates coredump
./src/.libs/lt-protoc src/google/protobuf/test.proto -I. --cpp_out=.
Assertion failed: f == NULL || dynamic_cast(f) != NULL, file ./
google/protobuf/stubs/common.h, line 282
IOT/Abort trap (core dumped)
In dbx I found following things
File: userid=1104, groupid=1000
pthread_kill(??, ??) at 0xd01246b4
_p_raise(??) at 0xd0124124
raise.raise(??) at 0xd0375b28
abort() at 0xd03d3e78
__assert_c99(??, ??, ??, ??) at 0xd03ded6c
down_cast__Q3_6google8protobuf8internalHPQ3_6google8protobuf19UninterpretedOptionQ3_6google8protobuf7Message_PQ3_6google8protobuf7Message_PQ3_6google8protobuf19UninterpretedOption
(0x2000edb8) at 0xd1d08844
ParseOptionAssignment__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf7Message
(0x2ff223b8, 0x2000dd58) at 0xd1d08ad0
ParseOption__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf7Message
(0x2ff223b8, 0x2000dd58) at 0xd1d09090
ParseTopLevelStatement__Q4_6google8protobuf8compiler6ParserFPQ3_6google8protobuf19FileDescriptorProto
(0x2ff223b8, 0x2ff22450) at 0xd1d0f1e0
Parse__Q4_6google8protobuf8compiler6ParserFPQ4_6google8protobuf2io9TokenizerPQ3_6google8protobuf19FileDescriptorProto
(0x2ff223b8, 0x2ff22368, 0x2ff22450) at 0xd1d0f7d0
FindFileByName__Q4_6google8protobuf8compiler28SourceTreeDescriptorDatabaseFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__PQ3_6google8protobuf19FileDescriptorProto
(0x2ff22678, 0x2000b5c8, 0x2ff22450) at 0xd1d25c28
TryFindFileInFallbackDatabase__Q3_6google8protobuf14DescriptorPoolCFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__
(0x2ff2269c, 0x2000b5c8) at 0xd1b34004
FindFileByName__Q3_6google8protobuf14DescriptorPoolCFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__
(0x2ff2269c, 0x2000b5c8) at 0xd1b34344
Import__Q4_6google8protobuf8compiler8ImporterFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__
(0x2ff22678, 0x2000b5c8) at 0xd1d24144
Run__Q4_6google8protobuf8compiler20CommandLineInterfaceFiPCPCc
(0x2ff22880, 0x4, 0x2ff22a24) at 0xd1755294
main(0x4, 0x2ff22a24) at 0x10002730
while gdb shows up
bash-3.00$ gdb src/.libs/lt-protoc core
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "powerpc-ibm-aix4.3.2.0"...(no debugging
symbols found)...
Core was generated by `lt-protoc'.
Program terminated with signal 6, Aborted.
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
#0 0xd01246b4 in pthread_kill () from /usr/lib/libpthreads.a
(shr_xpg5.o)
(gdb) where
#0 0xd01246b4 in pthread_kill () from /usr/lib/libpthreads.a
(shr_xpg5.o)
#1 0xd0124128 in _p_raise () from /usr/lib/libpthreads.a(shr_xpg5.o)
#2 0xd0375b2c in raise () from /usr/lib/libc.a(shr.o)
#3 0xd03d3e7c in abort () from /usr/lib/libc.a(shr.o)
#4 0xd03ded70 in __assert_c99 () from /usr
Re: JavaScript
One problem with javascript and protobuf is that you need a lot of support code to parse the messages. Unless you end up sending quite a lot of stuff back and forth, making the user download a JS protobuf codec library may be a net loss. It may be better to use JSON or XML because browsers already have built-in support for those. That said, I think various people inside google have been playing with javascript + protocol buffers for awhile and if we end up with anything that works well enough, we'll release it. On Thu, Jun 25, 2009 at 3:23 PM, rthompson.dtisoft@gmail.com < rthompson.dtisoft@gmail.com> wrote: > > Is there anything in the works that would allow us to output > JavaScript along with C++, Java, and Python? > > > --~--~-~--~~~---~--~~ 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: JavaScript
That one doesn't look complete. I've got one that almost is. On Thu, Jun 25, 2009 at 3:53 PM, Marc Gravell wrote: > > I haven't tried it, but > http://code.google.com/p/protobuf/wiki/OtherLanguages > lists javascript support here: http://code.google.com/p/protobuf-js/ > > (this is one of many unofficial independent implementations - not > google's; don't blame them ;-p) > > Marc > > > -- Alek Storm --~--~-~--~~~---~--~~ 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: JavaScript
I haven't tried it, but http://code.google.com/p/protobuf/wiki/OtherLanguages lists javascript support here: http://code.google.com/p/protobuf-js/ (this is one of many unofficial independent implementations - not google's; don't blame them ;-p) Marc --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
JavaScript
Is there anything in the works that would allow us to output JavaScript along with C++, Java, and Python? --~--~-~--~~~---~--~~ 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: Warnings with member variables in C++
Oh, excellent stuff. Thanks a lot for the quick response Kenton. I'll
try to be more diligent as well with the search in previous issues and
posts.
I'll read up on that link to see if I can justify the removal of the
effective c++ checks or agree to cope with the cost of maintaining the
fix I put in.
Many thanks again,
Dan.
On Jun 25, 8:56 pm, Kenton Varda wrote:
> BTW, this was also reported awhile ago as issue
> 86:http://code.google.com/p/protobuf/issues/detail?id=86
>
> On Thu, Jun 25, 2009 at 12:55 PM, Kenton Varda wrote:
> > The problem is that GCC emits two or three copies of each constructor. In
> > order to keep generated code size down, we moved the constructor code into a
> > separate method which could then be shared by the multiple copies that GCC
> > emits.
> >http://gcc.gnu.org/bugs.html#nonbugs_cxx
>
> > There is nothing "harmful" about this -- all fields are still being
> > initialized properly. It's just happening somewhere other than the
> > constructor.
>
> > I recommend disabling the warning. Perhaps you can disable it just for
> > .pb.cc files?
>
> > On Thu, Jun 25, 2009 at 12:11 PM, dan.schmidt.valle <
> > dan.schmidt.va...@gmail.com> wrote:
>
> >> Hi there,
>
> >> I'm developing an app in C++ and I use PB for lots of things. I'm also
> >> in an environment that requires me to make sure the code passes very
> >> strict warning levels. I found out when I started using them that PB
> >> didn't include the _unknown_fields_ or any of the repeated field
> >> containers in the member initialisation list. This resulted in me
> >> having warnings all over the place (of the **should be initialized in
> >> the member initialization list** sort), so I amended the
> >> cpp_message.cc method
>
> >> void MessageGenerator::GenerateInitializerList(io::Printer* printer)
>
> >> to include the following line: printer->Print("_unknown_fields_
> >> (),\n");
>
> >> and all the cpp_*_field.cc files to include initialisation for the
> >> repeated files with:
>
> >> void RepeatedEnumFieldGenerator::GenerateInitializer(io::Printer*
> >> printer) const {
> >> printer->Print(variables_, ",\n$name$_()");
> >> }
>
> >> This was enough up to version 2.0.3. I now see that version 2.1.0 has
> >> removed the initialisation of members from the constructor altogether.
> >> I was wondering what the rationale for that had been, because I've
> >> read that not doing that initialisation can be very harmful.
>
> >> Thanks a lot.
>
> >> Dan
--~--~-~--~~~---~--~~
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: Warnings with member variables in C++
BTW, this was also reported awhile ago as issue 86:
http://code.google.com/p/protobuf/issues/detail?id=86
On Thu, Jun 25, 2009 at 12:55 PM, Kenton Varda wrote:
> The problem is that GCC emits two or three copies of each constructor. In
> order to keep generated code size down, we moved the constructor code into a
> separate method which could then be shared by the multiple copies that GCC
> emits.
> http://gcc.gnu.org/bugs.html#nonbugs_cxx
>
> There is nothing "harmful" about this -- all fields are still being
> initialized properly. It's just happening somewhere other than the
> constructor.
>
> I recommend disabling the warning. Perhaps you can disable it just for
> .pb.cc files?
>
> On Thu, Jun 25, 2009 at 12:11 PM, dan.schmidt.valle <
> dan.schmidt.va...@gmail.com> wrote:
>
>>
>> Hi there,
>>
>> I'm developing an app in C++ and I use PB for lots of things. I'm also
>> in an environment that requires me to make sure the code passes very
>> strict warning levels. I found out when I started using them that PB
>> didn't include the _unknown_fields_ or any of the repeated field
>> containers in the member initialisation list. This resulted in me
>> having warnings all over the place (of the **should be initialized in
>> the member initialization list** sort), so I amended the
>> cpp_message.cc method
>>
>> void MessageGenerator::GenerateInitializerList(io::Printer* printer)
>>
>> to include the following line: printer->Print("_unknown_fields_
>> (),\n");
>>
>> and all the cpp_*_field.cc files to include initialisation for the
>> repeated files with:
>>
>> void RepeatedEnumFieldGenerator::GenerateInitializer(io::Printer*
>> printer) const {
>> printer->Print(variables_, ",\n$name$_()");
>> }
>>
>> This was enough up to version 2.0.3. I now see that version 2.1.0 has
>> removed the initialisation of members from the constructor altogether.
>> I was wondering what the rationale for that had been, because I've
>> read that not doing that initialisation can be very harmful.
>>
>> Thanks a lot.
>>
>> Dan
>> >>
>>
>
--~--~-~--~~~---~--~~
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: Warnings with member variables in C++
The problem is that GCC emits two or three copies of each constructor. In
order to keep generated code size down, we moved the constructor code into a
separate method which could then be shared by the multiple copies that GCC
emits.
http://gcc.gnu.org/bugs.html#nonbugs_cxx
There is nothing "harmful" about this -- all fields are still being
initialized properly. It's just happening somewhere other than the
constructor.
I recommend disabling the warning. Perhaps you can disable it just for
.pb.cc files?
On Thu, Jun 25, 2009 at 12:11 PM, dan.schmidt.valle <
dan.schmidt.va...@gmail.com> wrote:
>
> Hi there,
>
> I'm developing an app in C++ and I use PB for lots of things. I'm also
> in an environment that requires me to make sure the code passes very
> strict warning levels. I found out when I started using them that PB
> didn't include the _unknown_fields_ or any of the repeated field
> containers in the member initialisation list. This resulted in me
> having warnings all over the place (of the **should be initialized in
> the member initialization list** sort), so I amended the
> cpp_message.cc method
>
> void MessageGenerator::GenerateInitializerList(io::Printer* printer)
>
> to include the following line: printer->Print("_unknown_fields_
> (),\n");
>
> and all the cpp_*_field.cc files to include initialisation for the
> repeated files with:
>
> void RepeatedEnumFieldGenerator::GenerateInitializer(io::Printer*
> printer) const {
> printer->Print(variables_, ",\n$name$_()");
> }
>
> This was enough up to version 2.0.3. I now see that version 2.1.0 has
> removed the initialisation of members from the constructor altogether.
> I was wondering what the rationale for that had been, because I've
> read that not doing that initialisation can be very harmful.
>
> Thanks a lot.
>
> Dan
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
C# port now working with Mono 2.4
I'm delighted to announce that the C# port at http://code.google.com/p/protobuf-csharp-port/ now works with Mono 2.4. There have been a few oddities along the way: - I've had to abandon using the NAnt/MSBuild files for building on Mono at the moment; xbuild isn't really ready yet - A bug (I believe!) in the Mono 2.4 compiler was worked around - a really odd situation... see Mono bug 516379 - I've fixed various warnings which only showed up in Mono - I've had to disable one unit test (with an Ignore attribute) as it made the Mono VM blow up Currently there are *very* rudimentary build scripts (that would make a Makefile look like rocket science) in the "mono" directory. See mono/ readme.txt for more details. All feedback welcome - I'm hoping to make all this smoother over time. Next stop is probably Silverlight though... 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 -~--~~~~--~~--~--~---
Warnings with member variables in C++
Hi there,
I'm developing an app in C++ and I use PB for lots of things. I'm also
in an environment that requires me to make sure the code passes very
strict warning levels. I found out when I started using them that PB
didn't include the _unknown_fields_ or any of the repeated field
containers in the member initialisation list. This resulted in me
having warnings all over the place (of the **should be initialized in
the member initialization list** sort), so I amended the
cpp_message.cc method
void MessageGenerator::GenerateInitializerList(io::Printer* printer)
to include the following line: printer->Print("_unknown_fields_
(),\n");
and all the cpp_*_field.cc files to include initialisation for the
repeated files with:
void RepeatedEnumFieldGenerator::GenerateInitializer(io::Printer*
printer) const {
printer->Print(variables_, ",\n$name$_()");
}
This was enough up to version 2.0.3. I now see that version 2.1.0 has
removed the initialisation of members from the constructor altogether.
I was wondering what the rationale for that had been, because I've
read that not doing that initialisation can be very harmful.
Thanks a lot.
Dan
--~--~-~--~~~---~--~~
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: bizarre crash report on freebsd
libprotobuf generally does not rely on dynamic initialization, and instead uses pthread_once to initialize globals. The stack trace in that bug report points at an object which is allocated by a pthread_once, so I don't think initialization ordering can be the culprit here. On Wed, Jun 24, 2009 at 8:45 PM, daveb wrote: > > Protobuf-c has a small bit in its test-suite that uses protobuf's c++ > binding to generate packed versions of several messages that are > compared with c binding packed data. > > I'm almost tempted to get rid of these fragile tests b/c they are such > a build annoyance. But I'm going to try to keep them just to make > certain testing easier (e.g. packed-repeated will be much easier to > validate if i can test c v c++ directly). > > Anyways, the latest build issue is this mystifying bug report on > freebsd (i have no idea if the OS is relevant really). > >http://code.google.com/p/protobuf-c/issues/detail?id=22 > > Since I don't have a freebsd box convenient i can't reproduce, which > means i am stuck guessing from the bug report. > > The crash occurs in the static initializers (see backtrace in the bug > report). > > My best guess is that static initializers in protobuf and the > generated code need to be run in a certain order (ie generated code > before libprotobuf, or maybe vice versa), and that isn't happening in > this user's environment. > > Any ideas? > > > --~--~-~--~~~---~--~~ 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: encoding of embedded messages and repeated elements
Yes, "groups" are never going to fully go away. But we recommend against using them in new code. On Thu, Jun 25, 2009 at 9:13 AM, Piotr Findeisen wrote: > > Hi! > > On Jun 24, 8:42 pm, Kenton Varda wrote: > > The end-tag approach is more efficient than your idea -- it's faster (no > > need to count elements at all) and it takes no more space (no need to > write > > a count, which makes up for the extra space taken by the end tag). > > But in any case, the encoding is not something we can change at this > point, > > since protocol buffers is nothing without backwards-compatibility. > > As I read the code of C++ protobuf deserializer I found it supports > end-tag approach using END_GROUP constant -- or I just misunderstood > the code and/or this thread? > > From my experiments it looks like I can stream messages one by one > separating them with END_GROUP tag, but -- again from comments in the > code -- it's deprecated. If "protocol buffers is nothing without > backwards-compatibility", can I assume that existing and future > implementation of C++ and also Java/Python deserializers will support > this approach? > > best regards, > Piotr > > > > --~--~-~--~~~---~--~~ 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: unknown fields in TextFormat
TextFormat is intentionally designed to refuse unknown fields because otherwise simple spelling errors would be silently ignored. Since TextFormat is used for communicating with fallible humans rather than other computers, catching errors seems more important than forward-compatibility. What I suggest you do is "compile" your configs into binary messages. You can use a command like: protoc --encode=MyMessageType my_proto.proto < config.txt > compiled_config Then distribute compiled_config to your servers, and have them parse it as a binary protocol buffer. If you need to inspect the contents of a compiled config, converting it back to text format is as easy as: protoc --decode=MyMessageType my_proto.proto < compiled_config On Thu, Jun 25, 2009 at 9:19 AM, Piotr Findeisen wrote: > > Hi! > > While PB binary format makes messages protocol extendable, the text > format is not. > I already use binary format as my network protocol "language" and text > format for configuration files and wonder if extendable/backwards- > compatible text format is at possible. > > (Or there is some not-very-exposed option for TextFormat parser that > makes it silently skip unknown messages?) > > best regards, > Piotr > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
unknown fields in TextFormat
Hi! While PB binary format makes messages protocol extendable, the text format is not. I already use binary format as my network protocol "language" and text format for configuration files and wonder if extendable/backwards- compatible text format is at possible. (Or there is some not-very-exposed option for TextFormat parser that makes it silently skip unknown messages?) best regards, Piotr --~--~-~--~~~---~--~~ 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: encoding of embedded messages and repeated elements
Hi! On Jun 24, 8:42 pm, Kenton Varda wrote: > The end-tag approach is more efficient than your idea -- it's faster (no > need to count elements at all) and it takes no more space (no need to write > a count, which makes up for the extra space taken by the end tag). > But in any case, the encoding is not something we can change at this point, > since protocol buffers is nothing without backwards-compatibility. As I read the code of C++ protobuf deserializer I found it supports end-tag approach using END_GROUP constant -- or I just misunderstood the code and/or this thread? >From my experiments it looks like I can stream messages one by one separating them with END_GROUP tag, but -- again from comments in the code -- it's deprecated. If "protocol buffers is nothing without backwards-compatibility", can I assume that existing and future implementation of C++ and also Java/Python deserializers will support this approach? best regards, Piotr --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
