[jira] [Commented] (THRIFT-4364) Website contributing guide erroneously recommends submitting patches in JIRA
[ https://issues.apache.org/jira/browse/THRIFT-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16211249#comment-16211249 ] Konrad Grochowski commented on THRIFT-4364: --- try adding space to the page which includes `CONTRIBUTING.md` ;) > Website contributing guide erroneously recommends submitting patches in JIRA > > > Key: THRIFT-4364 > URL: https://issues.apache.org/jira/browse/THRIFT-4364 > Project: Thrift > Issue Type: Bug > Components: Documentation, Website >Reporter: Neia Neutuladh > > https://thrift.apache.org/docs/HowToContribute > The first recommended way to submit patches is through JIRA. I've been told > to resubmit patches as pull requests. > CONTRIBUTING.md seems to be more thorough and up to date. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-3055) Apache Thrift Logo
[ https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988818#comment-15988818 ] Konrad Grochowski commented on THRIFT-3055: --- yhm, something like that :) (but that was a general idea) big challenge would be to find proper font :D > Apache Thrift Logo > -- > > Key: THRIFT-3055 > URL: https://issues.apache.org/jira/browse/THRIFT-3055 > Project: Thrift > Issue Type: Brainstorming > Components: Wish List >Reporter: Jake Farrell >Assignee: Jake Farrell > Attachments: ThriftLogo-UMLConnection.JPG > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3055) Apache Thrift Logo
[ https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988697#comment-15988697 ] Konrad Grochowski commented on THRIFT-3055: --- Following [~jensg] on animal thing: homing pigeon? ;) But seriously: Thrift is light and simple-to-use so IMHO logo should also be as simple as possible: maybe something like "component iface connection" in UML (circle embedded in semicircle - probably in two different colors/shades to indicate "different platfroms")? > Apache Thrift Logo > -- > > Key: THRIFT-3055 > URL: https://issues.apache.org/jira/browse/THRIFT-3055 > Project: Thrift > Issue Type: Brainstorming > Components: Wish List >Reporter: Jake Farrell >Assignee: Jake Farrell > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
[ https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979967#comment-15979967 ] Konrad Grochowski commented on THRIFT-2221: --- quick note: `scoped_ptr` to `shared_ptr` will result in major performance degradation. In C++11 mode we could use `using` construct to "rename" `unique_ptr` to `apache::stdcxx::scoped_ptr`. > Generate c++ code with std::shared_ptr instead of boost::shared_ptr. > > > Key: THRIFT-2221 > URL: https://issues.apache.org/jira/browse/THRIFT-2221 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler >Affects Versions: 0.9.1 > Environment: C++11 compilers with std::shared_ptr support >Reporter: Chris Stylianou >Assignee: James E. King, III > Labels: c++11, compiler, thrift > > Most modern compilers now have full support for std::shared_ptr when enable > with c++11 flags. It would be nice to have the option to generate code that > uses this instead of boost::shared_ptr. This would enable us to remove > another boost dependency, on the road to a dependency-free thrift library :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-2717) C++V2 generator/library
[
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868201#comment-15868201
]
Konrad Grochowski commented on THRIFT-2717:
---
Assistance is always welcome :)
Truth be told - I've changed job during development of CPP V2, I couldn't find
time to finish it and in result branch become more or less dead. I'm not even
sure it would compile right now if merged with master.
Still - I hope someday I will return to it and finish it - branch and fork
stays open ;)
> C++V2 generator/library
> ---
>
> Key: THRIFT-2717
> URL: https://issues.apache.org/jira/browse/THRIFT-2717
> Project: Thrift
> Issue Type: New Feature
> Components: C++ - Compiler
>Reporter: Konrad Grochowski
>
> instead of adding another set of options to 'old' cpp generator I've started
> creating new one in:
> https://github.com/hcorg/thrift/tree/cpp_v2
> using old as an reference
> main goals (for generator):
> * code compatible with old librart (at least for first tests, new lib and
> compiler switches can be added later)
> * no more ugly {{__isset}} structure -> boost::optional for optional values
> * as a result - no more {{__}} in names, which violates C++ standard
> * all generation code will have own unit tests (TDD used wherever possible)
> * generated types headers independent from Thrift header, to allow other
> layers of application using generated types without dependency leaks
> * each type will generate own header/cpp file - easier for user to include
> only used parts.
> * unordered map/sets
> * returning using move semantics, no more ugly 'return via output parameter'
> (still possible as option thou - sometimes it's needed for performance)
> * async client using boost::future
> * enum classes
> * initializer lists for constants (maybe)
> main goals (for library):
> * minimizing boost deps
> * using C++11 features to simplify lib
> * be base for new generator
> I'm aiming in C++11 subset available in gcc 4.8 and MSVC 2013
> currently I have only complete enum generation, but work is in progress
> all comments etc are very welcome :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863569#comment-15863569
]
Konrad Grochowski commented on THRIFT-4060:
---
IMHO: ifdef is still better because it allows implementers to make decision
about `ostream<<` later in development process (for example: when thrift files
are somehow shared and can't be easily modified etc.)
I also recall some very old discussion about keeping thrift compiler
options/switches to minimum.
But that's just opinion - don't treat it "blocking" :)
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862503#comment-15862503
]
Konrad Grochowski commented on THRIFT-4060:
---
ok, I did not get that {{MyHigher}} etc. was a try to override {{operator<<}}
behavior. Now I do see a need for such extension point :) But instead of
annotation (which makes .thrift file "language aware") I'd go with some
{{ifdef}} in generated source code. Something along
{{THRIFT_NO_GENERATED_OSTREAM_OPERATOR}} and {{ifndef}}. It would keep compiler
code simpler and (more importantly) service/data definition clean.
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861577#comment-15861577
]
Konrad Grochowski edited comment on THRIFT-4060 at 2/10/17 5:45 PM:
I do not completely follow your example: {{set}} will always
contain {{Lower}}, even if you put {{MyLower}} there are you get is object
splicing (http://stackoverflow.com/questions/274626/what-is-object-slicing). So
there is no way for {{MyHigher}} to print out {{MyLower}} via {{lowers}}.
So I'm not against introducing this annotation, but I'd like to see proper
use-case :) (because for now all use-cases I see could rely on {{printTo}}, and
it's better to keep thrift compiler simple - without too many annotations)
was (Author: hcorg):
I do not completely follow your example: `set` will always
contain `Lower`, even if you put `MyLower` there are you get is object splicing
(http://stackoverflow.com/questions/274626/what-is-object-slicing). So there is
no way for `MyHigher` to print out `MyLower` via `lowers`.
So I'm not against introducing this annotation, but I'd like to see proper
use-case :) (because for now all use-cases I see could rely on `printTo`, and
it's better to keep thrift compiler simple - without too many annotations)
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861577#comment-15861577
]
Konrad Grochowski commented on THRIFT-4060:
---
I do not completely follow your example: `set` will always
contain `Lower`, even if you put `MyLower` there are you get is object splicing
(http://stackoverflow.com/questions/274626/what-is-object-slicing). So there is
no way for `MyHigher` to print out `MyLower` via `lowers`.
So I'm not against introducing this annotation, but I'd like to see proper
use-case :) (because for now all use-cases I see could rely on `printTo`, and
it's better to keep thrift compiler simple - without too many annotations)
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (THRIFT-2342) Add __FILE__ and __LINE__ to Thrift C++ excpetions
[ https://issues.apache.org/jira/browse/THRIFT-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski closed THRIFT-2342. - Resolution: Won't Fix > Add __FILE__ and __LINE__ to Thrift C++ excpetions > -- > > Key: THRIFT-2342 > URL: https://issues.apache.org/jira/browse/THRIFT-2342 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler, C++ - Library >Reporter: George Godik >Assignee: James E. King, III >Priority: Minor > Labels: newbie > Fix For: 0.10.0 > > > Thrift exceptions are somewhat difficult to trace from debug logs. I'd like > to add __FILE__AND__LINE__ as a second parameter to some exceptions to make > them easier to find. > For example: > Every time a required field is not set, the exception that gets generated is > a very generic > throw TProtocolException(TProtocolException::INVALID_DATA) > see - > https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372 > I think I'll start with patching up TProtocolExcpetion in the compiler and if > people like this I can make a separate issue and patch for other exceptions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (THRIFT-2342) Add __FILE__ and __LINE__ to Thrift C++ excpetions
[ https://issues.apache.org/jira/browse/THRIFT-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reopened THRIFT-2342: --- > Add __FILE__ and __LINE__ to Thrift C++ excpetions > -- > > Key: THRIFT-2342 > URL: https://issues.apache.org/jira/browse/THRIFT-2342 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler, C++ - Library >Reporter: George Godik >Assignee: James E. King, III >Priority: Minor > Labels: newbie > Fix For: 0.10.0 > > > Thrift exceptions are somewhat difficult to trace from debug logs. I'd like > to add __FILE__AND__LINE__ as a second parameter to some exceptions to make > them easier to find. > For example: > Every time a required field is not set, the exception that gets generated is > a very generic > throw TProtocolException(TProtocolException::INVALID_DATA) > see - > https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372 > I think I'll start with patching up TProtocolExcpetion in the compiler and if > people like this I can make a separate issue and patch for other exceptions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3415) include unistd.h conditionally
[ https://issues.apache.org/jira/browse/THRIFT-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3415. --- Resolution: Fixed Fix Version/s: 0.9.4 Fixed (unistd.h was removed completely). Thanks for catching that :) > include unistd.h conditionally > -- > > Key: THRIFT-3415 > URL: https://issues.apache.org/jira/browse/THRIFT-3415 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.4 >Reporter: Pascal Bach >Assignee: Konrad Grochowski > Fix For: 0.9.4 > > Attachments: unistd_include.patch > > > THeaderTransport.h includes unistd.h unconidionaly. > This breaks on non posix systems. > The solution is to include it only when the corresponding define is set, like > it is done in the rest of the codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3415) include unistd.h conditionally
[ https://issues.apache.org/jira/browse/THRIFT-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002232#comment-15002232 ] Konrad Grochowski commented on THRIFT-3415: --- I'll do some scans with clang's iwyu (include-what-you-use) and clean a little bit around in THeader* related includes > include unistd.h conditionally > -- > > Key: THRIFT-3415 > URL: https://issues.apache.org/jira/browse/THRIFT-3415 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.4 >Reporter: Pascal Bach >Assignee: Konrad Grochowski > Attachments: unistd_include.patch > > > THeaderTransport.h includes unistd.h unconidionaly. > This breaks on non posix systems. > The solution is to include it only when the corresponding define is set, like > it is done in the rest of the codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3415) include unistd.h conditionally
[ https://issues.apache.org/jira/browse/THRIFT-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002192#comment-15002192 ] Konrad Grochowski commented on THRIFT-3415: --- do you think this include is needed at all? I'm building on Fedora, and Thrift lib builds without issue. > include unistd.h conditionally > -- > > Key: THRIFT-3415 > URL: https://issues.apache.org/jira/browse/THRIFT-3415 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.4 >Reporter: Pascal Bach >Assignee: Konrad Grochowski > Attachments: unistd_include.patch > > > THeaderTransport.h includes unistd.h unconidionaly. > This breaks on non posix systems. > The solution is to include it only when the corresponding define is set, like > it is done in the rest of the codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-3415) include unistd.h conditionally
[ https://issues.apache.org/jira/browse/THRIFT-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-3415: - Assignee: Konrad Grochowski > include unistd.h conditionally > -- > > Key: THRIFT-3415 > URL: https://issues.apache.org/jira/browse/THRIFT-3415 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.4 >Reporter: Pascal Bach >Assignee: Konrad Grochowski > Attachments: unistd_include.patch > > > THeaderTransport.h includes unistd.h unconidionaly. > This breaks on non posix systems. > The solution is to include it only when the corresponding define is set, like > it is done in the rest of the codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3382) TBase class for C++ Library
[
https://issues.apache.org/jira/browse/THRIFT-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski updated THRIFT-3382:
--
Assignee: Adam Beberg (was: Konrad Grochowski)
> TBase class for C++ Library
> ---
>
> Key: THRIFT-3382
> URL: https://issues.apache.org/jira/browse/THRIFT-3382
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.3
>Reporter: Adam Beberg
>Assignee: Adam Beberg
> Fix For: 0.9.4
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Unlike Other languages, C++ is missing a TBase class (the majority of other
> langugaes call it that) that all generated structs always inherit from. This
> prevents simple utility functions, and forces ugly template use.
> Something like this:
> {code:title=thtift/TBase.h}
> class TBase {
> public:
> virtual ~TBase();
> virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
> virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3382) TBase class for C++ Library
[
https://issues.apache.org/jira/browse/THRIFT-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski resolved THRIFT-3382.
---
Resolution: Fixed
Fix Version/s: 0.9.4
Commited, thanks!
> TBase class for C++ Library
> ---
>
> Key: THRIFT-3382
> URL: https://issues.apache.org/jira/browse/THRIFT-3382
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.3
>Reporter: Adam Beberg
>Assignee: Konrad Grochowski
> Fix For: 0.9.4
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Unlike Other languages, C++ is missing a TBase class (the majority of other
> langugaes call it that) that all generated structs always inherit from. This
> prevents simple utility functions, and forces ugly template use.
> Something like this:
> {code:title=thtift/TBase.h}
> class TBase {
> public:
> virtual ~TBase();
> virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
> virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (THRIFT-3382) TBase class for C++ Library
[
https://issues.apache.org/jira/browse/THRIFT-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski reassigned THRIFT-3382:
-
Assignee: Konrad Grochowski (was: Adam Beberg)
> TBase class for C++ Library
> ---
>
> Key: THRIFT-3382
> URL: https://issues.apache.org/jira/browse/THRIFT-3382
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.3
>Reporter: Adam Beberg
>Assignee: Konrad Grochowski
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Unlike Other languages, C++ is missing a TBase class (the majority of other
> langugaes call it that) that all generated structs always inherit from. This
> prevents simple utility functions, and forces ugly template use.
> Something like this:
> {code:title=thtift/TBase.h}
> class TBase {
> public:
> virtual ~TBase();
> virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
> virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3393) Introduce i8 to provide consistent set of Thrift IDL integer types
[
https://issues.apache.org/jira/browse/THRIFT-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14965625#comment-14965625
]
Konrad Grochowski commented on THRIFT-3393:
---
+1
> Introduce i8 to provide consistent set of Thrift IDL integer types
> --
>
> Key: THRIFT-3393
> URL: https://issues.apache.org/jira/browse/THRIFT-3393
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Reporter: Jens Geyer
>Assignee: Jens Geyer
> Labels: i8
>
> In following up a [recent email
> discussion|https://mail-archives.apache.org/mod_mbox/thrift-dev/201412.mbox/%3cdub110-ds46454ddd3a90974be62d69b1...@phx.gbl%3e]
> and the consistent stream of problems with the [signedness of the Thrift IDL
> {{byte}} datatype|https://thrift.apache.org/docs/types], we should
> * add an {{i8}} data type to provide a consistent set
> * keep the {{byte}} type for the sake of compatibility
> * internally map all references to {{byte}} to {{i8}}
> I'm hesitant though about printing a warning for {{byte}} at this stage. A
> lot of third-party-tools rely on Thrift IDL and I don't want to introduce any
> breaking changes. IMHO we should promote i8 instead of byte wherever
> possible, but not hammer that nail too much.
> This patch is solely about the changes needed in the IDL and the compiler
> infrastructure, changing only what's necessary in the various target
> languages to let {{make check}} succeed. Any additional changes to be made in
> the language libs should be added as a sub-task as necessary. This procedure
> allows us to make the changes in a more granular way while still maintaining
> a shippable product.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-2411) C++: UTF-8 sent by PHP as JSON is not understood by TJsonProtocol
[ https://issues.apache.org/jira/browse/THRIFT-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-2411. --- Resolution: Fixed Assignee: Phongphan Phuttha (was: Konrad Grochowski) Fix Version/s: 0.9.4 Committed, thanks! > C++: UTF-8 sent by PHP as JSON is not understood by TJsonProtocol > - > > Key: THRIFT-2411 > URL: https://issues.apache.org/jira/browse/THRIFT-2411 > Project: Thrift > Issue Type: Sub-task > Components: C++ - Library >Reporter: Jens Geyer >Assignee: Phongphan Phuttha > Fix For: 0.9.4 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-2411) C++: UTF-8 sent by PHP as JSON is not understood by TJsonProtocol
[ https://issues.apache.org/jira/browse/THRIFT-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-2411: - Assignee: Konrad Grochowski > C++: UTF-8 sent by PHP as JSON is not understood by TJsonProtocol > - > > Key: THRIFT-2411 > URL: https://issues.apache.org/jira/browse/THRIFT-2411 > Project: Thrift > Issue Type: Sub-task > Components: C++ - Library >Reporter: Jens Geyer >Assignee: Konrad Grochowski > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3382) TBase class for C++ Library
[
https://issues.apache.org/jira/browse/THRIFT-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959125#comment-14959125
]
Konrad Grochowski commented on THRIFT-3382:
---
TTransport and TProtocol does it when objects are generated with template
support, TBase class will not be added when generating in "template" mode.
As much as I do not like general TBase class, I think it should not add a lot
to existing stack
> TBase class for C++ Library
> ---
>
> Key: THRIFT-3382
> URL: https://issues.apache.org/jira/browse/THRIFT-3382
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.3
>Reporter: Adam Beberg
>Assignee: Adam Beberg
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Unlike Other languages, C++ is missing a TBase class (the majority of other
> langugaes call it that) that all generated structs always inherit from. This
> prevents simple utility functions, and forces ugly template use.
> Something like this:
> {code:title=thtift/TBase.h}
> class TBase {
> public:
> virtual ~TBase();
> virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
> virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3382) TBase class for C++ Library
[
https://issues.apache.org/jira/browse/THRIFT-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956503#comment-14956503
]
Konrad Grochowski commented on THRIFT-3382:
---
please remember that in C++ lib in thrift there was a lot of effort put to
remove virtual methods in exchange for templates. I'm not really sure if
efficiency gain justified those actions, but nevertheless we can't just ignore
that. IMHO: TBase should not be added when generating C++ code in template mode.
> TBase class for C++ Library
> ---
>
> Key: THRIFT-3382
> URL: https://issues.apache.org/jira/browse/THRIFT-3382
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.3
>Reporter: Adam Beberg
>Assignee: Adam Beberg
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Unlike Other languages, C++ is missing a TBase class (the majority of other
> langugaes call it that) that all generated structs always inherit from. This
> prevents simple utility functions, and forces ugly template use.
> Something like this:
> {code:title=thtift/TBase.h}
> class TBase {
> public:
> virtual ~TBase();
> virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
> virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3382) TBase class for C++ Library
[
https://issues.apache.org/jira/browse/THRIFT-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski updated THRIFT-3382:
--
Description:
Unlike Other languages, C++ is missing a TBase class (the majority of other
langugaes call it that) that all generated structs always inherit from. This
prevents simple utility functions, and forces ugly template use.
Something like this:
{code:title=thtift/TBase.h}
class TBase {
public:
virtual ~TBase();
virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
}
{code}
was:
Unlike Other languages, C++ is missing a TBase class (the majority of other
langugaes call it that) that all generated structs always inherit from. This
prevents simple utility functions, and forces ugly template use.
Something like this:
class TBase {
public:
virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
}
In thrift/TBase.h
> TBase class for C++ Library
> ---
>
> Key: THRIFT-3382
> URL: https://issues.apache.org/jira/browse/THRIFT-3382
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.3
>Reporter: Adam Beberg
>Assignee: Adam Beberg
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Unlike Other languages, C++ is missing a TBase class (the majority of other
> langugaes call it that) that all generated structs always inherit from. This
> prevents simple utility functions, and forces ugly template use.
> Something like this:
> {code:title=thtift/TBase.h}
> class TBase {
> public:
> virtual ~TBase();
> virtual uint32_t read(::apache::thrift::protocol::TProtocol* iprot);
> virtual uint32_t write(::apache::thrift::protocol::TProtocol* oprot) const;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-1712) Add TBase class for c++
[
https://issues.apache.org/jira/browse/THRIFT-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955243#comment-14955243
]
Konrad Grochowski commented on THRIFT-1712:
---
It was closed by original reporter, probably turned out patch can't be
implemented or something.
BTW: I personally think, that common base class in language like C++ is really
not necessary, especially for structs - it can lead to errors as structs are
often 'value objects' but 'common base' indicates 'polymorphism' and those two
don't like each other...
> Add TBase class for c++
> ---
>
> Key: THRIFT-1712
> URL: https://issues.apache.org/jira/browse/THRIFT-1712
> Project: Thrift
> Issue Type: New Feature
> Components: C++ - Compiler
>Affects Versions: 0.8
>Reporter: Martin Vogt
>Assignee: Ben Craig
>Priority: Minor
> Labels: base, c++, class
> Attachments: 000_line_first_140628v1.patch,
> 010_base_struct_gen_140629v1.patch, 011_base_struct_rest_140619v2.patch
>
>
> The generated c++ classes for struct's do not have a common base class.
> The patch adds two options to the compiler:
> - line_first : first line before all includes
> - base_struct : custom base class for structs
> For example:
> {code:title=MyService.thrift}
> struct MyStruct {
>1:i32 val;
> }
> service MyService {
>void doSomething();
> }
> {code}
> thrift --gen cpp:line_first='#include ',base_struct=':public
> TBase' ./MyService.thrift
> {code:title=MyService_types.h}
> #ifndef MyService_TYPES_H
> #define MyService_TYPES_H
> #include
> #include
> []
> class MyStruct:public TBase {
> [...]
> {code}
> The default, without any option:
> thrift --gen cpp ./MyService.thrift
> {code:title=MyService_types.h}
> #ifndef MyService_TYPES_H
> #define MyService_TYPES_H
> /* first line (modifier:off) */
> #include
> []
> class MyStruct /* base_struct (modifier:off) */ {
> [...
> {code}
> The idea is to have a base class for typecasting, which can be done with:
> {code}
> void processSignal(const TBase& tBase) {
> if (typeid(tBase).name() == typeid(MyStruct).name())
> printf("MyStruct found!\n")
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2342) Add __FILE__ and __LINE__ to Thrift C++ excpetions
[ https://issues.apache.org/jira/browse/THRIFT-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935958#comment-14935958 ] Konrad Grochowski commented on THRIFT-2342: --- +1 > Add __FILE__ and __LINE__ to Thrift C++ excpetions > -- > > Key: THRIFT-2342 > URL: https://issues.apache.org/jira/browse/THRIFT-2342 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler, C++ - Library >Reporter: George Godik >Priority: Minor > Labels: newbie > > Thrift exceptions are somewhat difficult to trace from debug logs. I'd like > to add __FILE__AND__LINE__ as a second parameter to some exceptions to make > them easier to find. > For example: > Every time a required field is not set, the exception that gets generated is > a very generic > throw TProtocolException(TProtocolException::INVALID_DATA) > see - > https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372 > I think I'll start with patching up TProtocolExcpetion in the compiler and if > people like this I can make a separate issue and patch for other exceptions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2242) Generate C++11 code
[ https://issues.apache.org/jira/browse/THRIFT-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14934886#comment-14934886 ] Konrad Grochowski commented on THRIFT-2242: --- thrift map & set are unordered by definition. So by default (to finally be consistent) C++V2 will use std::unordered_xxx, yet std::set & std::map will probably be available somehow > Generate C++11 code > --- > > Key: THRIFT-2242 > URL: https://issues.apache.org/jira/browse/THRIFT-2242 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.1 >Reporter: Vitali Lovich > > unordered_map instead of map, unordered_set instead of set, noexcept instead > of throw() (unless the exact semantics of throw() are needed which seems > unlikely). > It should use the shared_ptr implementation that the library is configured > with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2242) Generate C++11 code
[ https://issues.apache.org/jira/browse/THRIFT-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933971#comment-14933971 ] Konrad Grochowski commented on THRIFT-2242: --- this issue just waits for C++V2 implementation (THRIFT-2717) - adding macros etc would make code unreadable, so std::xxx_ptrs will be used in new lib. (as soon as I find some time to finish it... any help is welcomed ;) ) as for unordered - Thrift specifies that it's containers are not sorted. Nobody intends to change current lib, but new one will probably use unordered (imho annotation could be used here) > Generate C++11 code > --- > > Key: THRIFT-2242 > URL: https://issues.apache.org/jira/browse/THRIFT-2242 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.1 >Reporter: Vitali Lovich > > unordered_map instead of map, unordered_set instead of set, noexcept instead > of throw() (unless the exact semantics of throw() are needed which seems > unlikely). > It should use the shared_ptr implementation that the library is configured > with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3317) cpp namespace org.apache issue appears in 0.9
[ https://issues.apache.org/jira/browse/THRIFT-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3317. --- Resolution: Fixed Assignee: Konrad Grochowski Fix Version/s: 0.9.4 Commited, thanks! > cpp namespace org.apache issue appears in 0.9 > - > > Key: THRIFT-3317 > URL: https://issues.apache.org/jira/browse/THRIFT-3317 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2 >Reporter: Carrey Zhan >Assignee: Konrad Grochowski > Fix For: 0.9.4 > > Attachments: thrift_3317_add_colons_to_to_string.patch > > > This is an old issue which has been solved in THRIFT-621, but I met it while > using thrift 0.9.2, and after I digged into the source, I confirmed that it > is the same issue. It can be fixed by a tiny patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3329) C++ library unit tests don't compile against the new boost-1.59 unit test framework
[ https://issues.apache.org/jira/browse/THRIFT-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3329. --- Resolution: Fixed Assignee: James E. King, III (was: Konrad Grochowski) Fix Version/s: 0.9.4 pushed, thanks! > C++ library unit tests don't compile against the new boost-1.59 unit test > framework > --- > > Key: THRIFT-3329 > URL: https://issues.apache.org/jira/browse/THRIFT-3329 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.3 >Reporter: James E. King, III >Assignee: James E. King, III > Fix For: 0.9.4 > > > BOOST_MESSAGE was deprecated in the past and has finally been removed (tried > boost-1.59, possibly removed in an earlier release, but it all works in > boost-1.54). Some of the C++ library unit test code uses BOOST_MESSAGE so it > won't compile any more. In addition, the method to make a test has changed > slightly and needs version specific code to handle both old and new. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3336) Thrift generated streaming operators added in 0.9.2 cannot be overridden
[ https://issues.apache.org/jira/browse/THRIFT-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski updated THRIFT-3336: -- Fix Version/s: (was: 1.0) 0.9.4 > Thrift generated streaming operators added in 0.9.2 cannot be overridden > > > Key: THRIFT-3336 > URL: https://issues.apache.org/jira/browse/THRIFT-3336 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2, 0.9.3 >Reporter: James E. King, III >Assignee: James E. King, III > Fix For: 0.9.4 > > > I work on one project that has been using thrift-0.8.0 and I am updating it > to 0.9.3. The project defines streaming operators for "operator <<" on a > variety of thrift-generated types. > The fix added in THRIFT-2067 provides similar but not identical functionality > however it was done in a way that cannot be overridden, and this causes > projects upgrading from versions prior to 0.9.2 with their own streaming > operators to fail to compile. > One way to make the streaming operator virtual is to follow the example > provided in > http://stackoverflow.com/questions/5189614/operator-and-inheritance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3336) Thrift generated streaming operators added in 0.9.2 cannot be overridden
[ https://issues.apache.org/jira/browse/THRIFT-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3336. --- Resolution: Fixed Assignee: James E. King, III (was: Konrad Grochowski) Fix Version/s: 1.0 Commited, thanks! I've changed generated method name to `printTo` to make it name more self-explainable. > Thrift generated streaming operators added in 0.9.2 cannot be overridden > > > Key: THRIFT-3336 > URL: https://issues.apache.org/jira/browse/THRIFT-3336 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2, 0.9.3 >Reporter: James E. King, III >Assignee: James E. King, III > Fix For: 1.0 > > > I work on one project that has been using thrift-0.8.0 and I am updating it > to 0.9.3. The project defines streaming operators for "operator <<" on a > variety of thrift-generated types. > The fix added in THRIFT-2067 provides similar but not identical functionality > however it was done in a way that cannot be overridden, and this causes > projects upgrading from versions prior to 0.9.2 with their own streaming > operators to fail to compile. > One way to make the streaming operator virtual is to follow the example > provided in > http://stackoverflow.com/questions/5189614/operator-and-inheritance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-3329) C++ library unit tests don't compile against the new boost-1.59 unit test framework
[ https://issues.apache.org/jira/browse/THRIFT-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-3329: - Assignee: Konrad Grochowski (was: James E. King, III) > C++ library unit tests don't compile against the new boost-1.59 unit test > framework > --- > > Key: THRIFT-3329 > URL: https://issues.apache.org/jira/browse/THRIFT-3329 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.3 >Reporter: James E. King, III >Assignee: Konrad Grochowski > > BOOST_MESSAGE was deprecated in the past and has finally been removed (tried > boost-1.59, possibly removed in an earlier release, but it all works in > boost-1.54). Some of the C++ library unit test code uses BOOST_MESSAGE so it > won't compile any more. In addition, the method to make a test has changed > slightly and needs version specific code to handle both old and new. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3336) Thrift generated streaming operators added in 0.9.2 cannot be overridden
[ https://issues.apache.org/jira/browse/THRIFT-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908332#comment-14908332 ] Konrad Grochowski commented on THRIFT-3336: --- disregard this comment > Thrift generated streaming operators added in 0.9.2 cannot be overridden > > > Key: THRIFT-3336 > URL: https://issues.apache.org/jira/browse/THRIFT-3336 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2, 0.9.3 >Reporter: James E. King, III >Assignee: James E. King, III > > I work on one project that has been using thrift-0.8.0 and I am updating it > to 0.9.3. The project defines streaming operators for "operator <<" on a > variety of thrift-generated types. > The fix added in THRIFT-2067 provides similar but not identical functionality > however it was done in a way that cannot be overridden, and this causes > projects upgrading from versions prior to 0.9.2 with their own streaming > operators to fail to compile. > One way to make the streaming operator virtual is to follow the example > provided in > http://stackoverflow.com/questions/5189614/operator-and-inheritance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-3336) Thrift generated streaming operators added in 0.9.2 cannot be overridden
[ https://issues.apache.org/jira/browse/THRIFT-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-3336: - Assignee: Konrad Grochowski (was: James E. King, III) > Thrift generated streaming operators added in 0.9.2 cannot be overridden > > > Key: THRIFT-3336 > URL: https://issues.apache.org/jira/browse/THRIFT-3336 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2, 0.9.3 >Reporter: James E. King, III >Assignee: Konrad Grochowski > > I work on one project that has been using thrift-0.8.0 and I am updating it > to 0.9.3. The project defines streaming operators for "operator <<" on a > variety of thrift-generated types. > The fix added in THRIFT-2067 provides similar but not identical functionality > however it was done in a way that cannot be overridden, and this causes > projects upgrading from versions prior to 0.9.2 with their own streaming > operators to fail to compile. > One way to make the streaming operator virtual is to follow the example > provided in > http://stackoverflow.com/questions/5189614/operator-and-inheritance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3336) Thrift generated streaming operators added in 0.9.2 cannot be overridden
[ https://issues.apache.org/jira/browse/THRIFT-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904949#comment-14904949 ] Konrad Grochowski commented on THRIFT-3336: --- I personally quite like generation options, *but* I saw this discussion quite often on Jira or maillist and usually consensus was: "keep generation options at minimum, if really needed - use annotations". I do not think that generating operator<< in C++ is something that should go into annotations (present in IDL file). Option would probably be frown upon... As nobody before complained about it, and your solution should improve extendability (and I do see any potential new problems it could introduce) - I'd leave it for now as default and possibly return to discussion if somebody find some new issue - no need to do more work than necessary. off-topic: probably providing thrift compiler with ability to read options from some file, or introducing some special format of "options per language in IDL file" (comments, top-level annotations, new grammar construct?) would solve a lot of such discussions... > Thrift generated streaming operators added in 0.9.2 cannot be overridden > > > Key: THRIFT-3336 > URL: https://issues.apache.org/jira/browse/THRIFT-3336 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2, 0.9.3 >Reporter: James E. King, III >Assignee: James E. King, III > > I work on one project that has been using thrift-0.8.0 and I am updating it > to 0.9.3. The project defines streaming operators for "operator <<" on a > variety of thrift-generated types. > The fix added in THRIFT-2067 provides similar but not identical functionality > however it was done in a way that cannot be overridden, and this causes > projects upgrading from versions prior to 0.9.2 with their own streaming > operators to fail to compile. > One way to make the streaming operator virtual is to follow the example > provided in > http://stackoverflow.com/questions/5189614/operator-and-inheritance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3336) Thrift generated streaming operators added in 0.9.2 cannot be overridden
[ https://issues.apache.org/jira/browse/THRIFT-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904806#comment-14904806 ] Konrad Grochowski commented on THRIFT-3336: --- oh, that's a bug, nice catch I'll fix it after this issue - no need to creating merge conflicts :) > Thrift generated streaming operators added in 0.9.2 cannot be overridden > > > Key: THRIFT-3336 > URL: https://issues.apache.org/jira/browse/THRIFT-3336 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2, 0.9.3 >Reporter: James E. King, III >Assignee: James E. King, III > > I work on one project that has been using thrift-0.8.0 and I am updating it > to 0.9.3. The project defines streaming operators for "operator <<" on a > variety of thrift-generated types. > The fix added in THRIFT-2067 provides similar but not identical functionality > however it was done in a way that cannot be overridden, and this causes > projects upgrading from versions prior to 0.9.2 with their own streaming > operators to fail to compile. > One way to make the streaming operator virtual is to follow the example > provided in > http://stackoverflow.com/questions/5189614/operator-and-inheritance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3336) Thrift generated streaming operators added in 0.9.2 cannot be overridden
[ https://issues.apache.org/jira/browse/THRIFT-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904708#comment-14904708 ] Konrad Grochowski commented on THRIFT-3336: --- as I wrote in THRIFT-2067 - `operator<<` on internal structures was generated by design - to help debug/log incoming function arguments etc. > Thrift generated streaming operators added in 0.9.2 cannot be overridden > > > Key: THRIFT-3336 > URL: https://issues.apache.org/jira/browse/THRIFT-3336 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9.2, 0.9.3 >Reporter: James E. King, III >Assignee: James E. King, III > > I work on one project that has been using thrift-0.8.0 and I am updating it > to 0.9.3. The project defines streaming operators for "operator <<" on a > variety of thrift-generated types. > The fix added in THRIFT-2067 provides similar but not identical functionality > however it was done in a way that cannot be overridden, and this causes > projects upgrading from versions prior to 0.9.2 with their own streaming > operators to fail to compile. > One way to make the streaming operator virtual is to follow the example > provided in > http://stackoverflow.com/questions/5189614/operator-and-inheritance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2067) Thrift objects should have a default string representation
[
https://issues.apache.org/jira/browse/THRIFT-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904671#comment-14904671
]
Konrad Grochowski commented on THRIFT-2067:
---
"internal structures" are also normal structs and they can be treated similary
:) - especially, printing them might help debugging/logging operations.
as for making printing virtual and extendable/overridable - sound like a good
plan, those are not protocol related methods so nobody should care about
`virtual` keyword ;)
just remember - introducing new method added to generated classes will break
some people code (for example for those who use `print` field), AFAIR you had
such problems with methd `what` in exceptions, so please think carefully about
name for that virtual function (`toString`? `printTo`? something that shall not
sound like field name :) )
good luck :)
> Thrift objects should have a default string representation
> --
>
> Key: THRIFT-2067
> URL: https://issues.apache.org/jira/browse/THRIFT-2067
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler, C++ - Library
>Reporter: Vitali Lovich
>Assignee: Konrad Grochowski
> Fix For: 0.9.2
>
>
> Just like thrift objects implement a custom toString in Java, there should be
> an inline friend function that writes a text representation of the struct to
> a std::ostream. Probably makes sense for the text representation to be
> similar to C++:
> {code}
> class MyThriftClass {
> friend std::ostream& operator<<(std::ostream& o, MyThriftClass) {
> o << "MyThriftClass[";
> o << "field1=" << field1;
> if (__isset.field2) {
> o << ", field2=" << field2;
> }
> o << ", list1=" << apache::thrift::util::to_string(list1);
> return o << "]";
> }
> // ...
> }
> {code}
> There will also probably be a util.h file to include that implements generic
> template to_string for lists, maps, & sets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native C++ language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630267#comment-14630267
]
Konrad Grochowski commented on THRIFT-727:
--
in Binary/Compact protocols only id of field is used. I have no idea how other
protocols are implemented :/
now I get what you mean by backward compatibility :) - forcing users to change
variable names. Still 'what' is just a wrong name for any variable ;)
> support native C++ language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Assignee: Anna Dymek
>Priority: Minor
> Fix For: 0.9.3
>
> Attachments: THRIFT-727-AddOn-Fix-GoTutorial-broken.patch
>
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native C++ language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630229#comment-14630229
]
Konrad Grochowski commented on THRIFT-727:
--
tutorials were updated in project. Tutorials are not part of API, so there is
no break in backward compatibility.
I'm strongly against reverting.
Even more against another compiler flag
> support native C++ language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Assignee: Anna Dymek
>Priority: Minor
> Fix For: 0.9.3
>
> Attachments: THRIFT-727-AddOn-Fix-GoTutorial-broken.patch
>
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native C++ language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14553234#comment-14553234
]
Konrad Grochowski commented on THRIFT-727:
--
thanks!
tutorial is not checked by any CI? nor Travis nor Jenkins?
> support native C++ language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Assignee: Anna Dymek
>Priority: Minor
> Fix For: 0.9.3
>
> Attachments: THRIFT-727-AddOn-Fix-GoTutorial-broken.patch
>
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-727) support native C++ language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski resolved THRIFT-727.
--
Resolution: Fixed
Fix Version/s: 0.9.3
Assignee: Anna Dymek (was: Konrad Grochowski)
I've simplified a little generated `what()` body and renamed internal message
holder (names starting with underscore and uppercase letter should be avoided -
in global scope by standard requirements, in local scope by good practice ;) ).
Still - committed, thanks :)
> support native C++ language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Assignee: Anna Dymek
>Priority: Minor
> Fix For: 0.9.3
>
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-727) support native C++ language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski updated THRIFT-727:
-
Component/s: (was: Compiler (General))
C++ - Compiler
Summary: support native C++ language specific exception message (was:
support native language specific exception message)
> support native C++ language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Assignee: Konrad Grochowski
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (THRIFT-727) support native language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski reassigned THRIFT-727:
Assignee: Konrad Grochowski
> support native language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Assignee: Konrad Grochowski
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3135) Hive table creation from hive query doesn't work
[ https://issues.apache.org/jira/browse/THRIFT-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3135. --- Resolution: Invalid Assignee: Konrad Grochowski Please report it to https://issues.apache.org/jira/browse/HIVE/ as it does not seems connected with Thrift protocol itself > Hive table creation from hive query doesn't work > > > Key: THRIFT-3135 > URL: https://issues.apache.org/jira/browse/THRIFT-3135 > Project: Thrift > Issue Type: Bug > Components: PHP - Library >Reporter: Mindaugas Mačiulaitis >Assignee: Konrad Grochowski > > When executing even simple hive table creation from query query (i.e. "CREATE > TABLE temp_table AS SELECT * FROM other_table" I get folowing error: > [ThriftSQL\Exception] > Query is in an error state: ERROR_STATE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536493#comment-14536493
]
Konrad Grochowski commented on THRIFT-727:
--
Unfortunately we can't fill it in constructor as fields in struct can change.
Maybe we should resign from including fields values in what message in favor of
noexcept safety and just returning const char with exception name.
Oryginalna wiadomość
Od: "James E. King, III (JIRA)"
Data:09.05.2015 13:54 (GMT+01:00)
Do: hc...@apache.org
Temat: [jira] [Commented] (THRIFT-727) support native language specific
exception message
James E. King, III commented on THRIFT-727
Re: support native language specific exception message
A unit test needs to be added for the new functionality, and what() needs to
change so it does not call any code that can throw an exception which means no
std::stringstream and no std::string (unless exception handling is used) -
better to allocate a buffer in the exception constructor and fill it in, then
return the buffer pointer in the body of what().
Add Comment
This message was sent by Atlassian JIRA (v6.3.4#6332-sha1:51bc225)
> support native language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3132) Properly format date in Java @Generated annotations
[ https://issues.apache.org/jira/browse/THRIFT-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3132. --- Resolution: Fixed Fix Version/s: 0.9.3 Assignee: Stig Bakken (was: Konrad Grochowski) Commited, thanks! > Properly format date in Java @Generated annotations > --- > > Key: THRIFT-3132 > URL: https://issues.apache.org/jira/browse/THRIFT-3132 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler >Affects Versions: 0.9.2 >Reporter: Stig Bakken >Assignee: Stig Bakken >Priority: Trivial > Fix For: 0.9.3 > > > This has been bugging me for some time, so I finally got around to fixing it > :-P -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-3132) Properly format date in Java @Generated annotations
[ https://issues.apache.org/jira/browse/THRIFT-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-3132: - Assignee: Konrad Grochowski > Properly format date in Java @Generated annotations > --- > > Key: THRIFT-3132 > URL: https://issues.apache.org/jira/browse/THRIFT-3132 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler >Affects Versions: 0.9.2 >Reporter: Stig Bakken >Assignee: Konrad Grochowski >Priority: Trivial > > This has been bugging me for some time, so I finally got around to fixing it > :-P -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3130) Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
[ https://issues.apache.org/jira/browse/THRIFT-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3130. --- Resolution: Fixed Fix Version/s: 0.9.3 Assignee: James E. King, III (was: Konrad Grochowski) Commited, thanks! > Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316 > --- > > Key: THRIFT-3130 > URL: https://issues.apache.org/jira/browse/THRIFT-3130 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Minor > Fix For: 0.9.3 > > > In THRIFT-1316 some macros were added that have proven to be unnecessary. > They were partially eliminated in THRIFT-3083, and this traces the removal of > what was left. In addition, TOutput was moved to its own class, and since > TThrift.cpp only contained TOutput code, it was renamed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-3130) Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
[ https://issues.apache.org/jira/browse/THRIFT-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-3130: - Assignee: Konrad Grochowski (was: James E. King, III) > Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316 > --- > > Key: THRIFT-3130 > URL: https://issues.apache.org/jira/browse/THRIFT-3130 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: James E. King, III >Assignee: Konrad Grochowski >Priority: Minor > > In THRIFT-1316 some macros were added that have proven to be unnecessary. > They were partially eliminated in THRIFT-3083, and this traces the removal of > what was left. In addition, TOutput was moved to its own class, and since > TThrift.cpp only contained TOutput code, it was renamed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3130) Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
[
https://issues.apache.org/jira/browse/THRIFT-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14532258#comment-14532258
]
Konrad Grochowski commented on THRIFT-3130:
---
after short investigation: when THRIFT_OVERLOAD_IF was added, Thrift required
boost 1.33.0, which did not have 'is convertible' in it's shared_ptr
copy-convert constructor.
{code}
template
shared_ptr(shared_ptr const & r): px(r.px), pn(r.pn) // never throws
{
}
{code}
So this 'overload if' was required, or compiler get lost.
I've checked boost repo - proper constructor is definitely present in 1.53.0,
which is current base line for Thrift, so THRIFT_OVERLOAD_IF may die finally!
I wonder when boost introduced it... I've just checked if we're safe, didn't
want to go through all boost git log ;)
-
Please add TOutput.h to proper _HEADERS directive in Makefile.am and I'll merge
it.
> Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
> ---
>
> Key: THRIFT-3130
> URL: https://issues.apache.org/jira/browse/THRIFT-3130
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> In THRIFT-1316 some macros were added that have proven to be unnecessary.
> They were partially eliminated in THRIFT-3083, and this traces the removal of
> what was left. In addition, TOutput was moved to its own class, and since
> TThrift.cpp only contained TOutput code, it was renamed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3130) Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
[
https://issues.apache.org/jira/browse/THRIFT-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14532214#comment-14532214
]
Konrad Grochowski commented on THRIFT-3130:
---
oh, there is a confusion (at least for compiler) :D
it seems it in is resolved in boost API (they've included something like
THRIFT_OVERLOAD_IF inside shared_ptr)
{code}
#if !defined( BOOST_SP_NO_SP_CONVERTIBLE )
shared_ptr( shared_ptr const & r, typename
boost::detail::sp_enable_if_convertible::type = boost::detail::sp_empty() )
#else
shared_ptr( shared_ptr const & r )
#endif
{code}
BUT - why thrift needed OVERLOAD_IF? At least once I've encountered a
compilation error due to lack of it... What changed?
> Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
> ---
>
> Key: THRIFT-3130
> URL: https://issues.apache.org/jira/browse/THRIFT-3130
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> In THRIFT-1316 some macros were added that have proven to be unnecessary.
> They were partially eliminated in THRIFT-3083, and this traces the removal of
> what was left. In addition, TOutput was moved to its own class, and since
> TThrift.cpp only contained TOutput code, it was renamed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3130) Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
[ https://issues.apache.org/jira/browse/THRIFT-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531532#comment-14531532 ] Konrad Grochowski commented on THRIFT-3130: --- unfortunately - it does not seem to: you create boost::shared_ptr explicitly, no template copy constructor is called then, just simple copy constructor. Try with make_shared, it will create shared_ptr and compiler will probably fail to find matching proper TServerIntegrationTestFixture constructor > Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316 > --- > > Key: THRIFT-3130 > URL: https://issues.apache.org/jira/browse/THRIFT-3130 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Minor > > In THRIFT-1316 some macros were added that have proven to be unnecessary. > They were partially eliminated in THRIFT-3083, and this traces the removal of > what was left. In addition, TOutput was moved to its own class, and since > TThrift.cpp only contained TOutput code, it was renamed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3130) Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
[
https://issues.apache.org/jira/browse/THRIFT-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531426#comment-14531426
]
Konrad Grochowski commented on THRIFT-3130:
---
if you remove THRIFT_OVERLOAD_IF thensuch code might not compile:
{code}
Server(make_shared(), .);
{code}
shared_ptr has template copy constructor (needed as shared_ptr
is different type than shared_ptr), but that template does not
require any dependency between type in constructor and in shared_ptr
So compiler will not know, which overload to use - one with
shared_ptr or shared_ptr. They're both good
enough. Or it will report that SomeProcessor* cannot be converted to
TProcessorFactory*.
I'd reintroduce those macros to TSimpleServer (as imho it's a degradation of
API)... I don't like them, once I've tried to remove them, but I've lerned hard
way they're necessary.
as fi\or new header - in Makefile.am there are ..._HEADERS directives - if it
goes there it will be installed.
> Remove the last vestiges of THRIFT_OVERLOAD_IF from THRIFT-1316
> ---
>
> Key: THRIFT-3130
> URL: https://issues.apache.org/jira/browse/THRIFT-3130
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> In THRIFT-1316 some macros were added that have proven to be unnecessary.
> They were partially eliminated in THRIFT-3083, and this traces the removal of
> what was left. In addition, TOutput was moved to its own class, and since
> TThrift.cpp only contained TOutput code, it was renamed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2000) TNonblocking server does not compile with libevent 2.0.21-stable
[ https://issues.apache.org/jira/browse/THRIFT-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531185#comment-14531185 ] Konrad Grochowski commented on THRIFT-2000: --- no idea - I had to reproduce make behaviour in SCons and after moving to windows it just worked (with hardcoded config.h etc,) - I do love SCons ;) I hope that in cpp_v2 (if I finally have time to finish it..) Nonblocking server will be replaced either by something based on Boost.Asio (it might be a little bit slower, yet easier to target multiplatforms) or Server2 from fbthrift (which fbthrift team claims to be faster that nonblocking, yet I've never checked what internals it uses) > TNonblocking server does not compile with libevent 2.0.21-stable > > > Key: THRIFT-2000 > URL: https://issues.apache.org/jira/browse/THRIFT-2000 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: libevent 2.0.21 > gcc 4.7 >Reporter: Konrad Grochowski >Assignee: Konrad Grochowski > Attachments: libevent_2_0_21.patch > > > problem lays in usage of deprecated libevent API, which is still available > but in different headers > In patch there's ifdef based on libevent version, which will include missing > headers, but maybe some refactoring for future will be needed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2000) TNonblocking server does not compile with libevent 2.0.21-stable
[ https://issues.apache.org/jira/browse/THRIFT-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531174#comment-14531174 ] Konrad Grochowski commented on THRIFT-2000: --- It can be reproduced on Linux if you do not do "make install" on libevent, but instead somehow add it to include path (and add - as I - wrong dir). As I was building both libevent and thrift as a internal parts of bigger system I used SCons build tool and configure everything manually (including include paths) On Windows I've just reused config.h generated on linux - I do not remember if I had to modify it... (at that time we were building with msvc2010) I've put libevent include path high on includes list, so event.h was properly resolved - this include was configured only for thrift server builds, so even if other parts of system were using event.h from PlatformSDK there were no conflicts. I'm no longer working on that project, so it's hard for me to double check all the details. > TNonblocking server does not compile with libevent 2.0.21-stable > > > Key: THRIFT-2000 > URL: https://issues.apache.org/jira/browse/THRIFT-2000 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: libevent 2.0.21 > gcc 4.7 >Reporter: Konrad Grochowski >Assignee: Konrad Grochowski > Attachments: libevent_2_0_21.patch > > > problem lays in usage of deprecated libevent API, which is still available > but in different headers > In patch there's ifdef based on libevent version, which will include missing > headers, but maybe some refactoring for future will be needed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (THRIFT-2000) TNonblocking server does not compile with libevent 2.0.21-stable
[ https://issues.apache.org/jira/browse/THRIFT-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski closed THRIFT-2000. - Resolution: Not A Problem Fix Version/s: (was: 0.9.3) Assignee: Konrad Grochowski (was: James E. King, III) > TNonblocking server does not compile with libevent 2.0.21-stable > > > Key: THRIFT-2000 > URL: https://issues.apache.org/jira/browse/THRIFT-2000 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: libevent 2.0.21 > gcc 4.7 >Reporter: Konrad Grochowski >Assignee: Konrad Grochowski > Attachments: libevent_2_0_21.patch > > > problem lays in usage of deprecated libevent API, which is still available > but in different headers > In patch there's ifdef based on libevent version, which will include missing > headers, but maybe some refactoring for future will be needed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2000) TNonblocking server does not compile with libevent 2.0.21-stable
[ https://issues.apache.org/jira/browse/THRIFT-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14530303#comment-14530303 ] Konrad Grochowski commented on THRIFT-2000: --- ohhh I see what happened - on Windows I've set include path to LIBEVENT/include/event2, yet there's also event.h directly in LIBEVENT directory, which includes deprecated 1.x libevent structures. So - Thrift really still depends on libevent 1.x and that's all... This patch is unnecessary, but might be usefull if we move to event2 > TNonblocking server does not compile with libevent 2.0.21-stable > > > Key: THRIFT-2000 > URL: https://issues.apache.org/jira/browse/THRIFT-2000 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: libevent 2.0.21 > gcc 4.7 >Reporter: Konrad Grochowski >Assignee: James E. King, III > Attachments: libevent_2_0_21.patch > > > problem lays in usage of deprecated libevent API, which is still available > but in different headers > In patch there's ifdef based on libevent version, which will include missing > headers, but maybe some refactoring for future will be needed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2000) TNonblocking server does not compile with libevent 2.0.21-stable
[ https://issues.apache.org/jira/browse/THRIFT-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14530290#comment-14530290 ] Konrad Grochowski commented on THRIFT-2000: --- I have no idea how TNonblockingServer can compile without event_compat.h include, as we use event_set and it is defined only in that include. Probably on some linuxes event_compat.h is somehow implicitly included by other deps. On Windows I need that patch to compile TNonblockingServer and even in 2.0.15 libevent version (as even then event_set was deprecated) > TNonblocking server does not compile with libevent 2.0.21-stable > > > Key: THRIFT-2000 > URL: https://issues.apache.org/jira/browse/THRIFT-2000 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: libevent 2.0.21 > gcc 4.7 >Reporter: Konrad Grochowski >Assignee: James E. King, III > Fix For: 0.9.3 > > Attachments: libevent_2_0_21.patch > > > problem lays in usage of deprecated libevent API, which is still available > but in different headers > In patch there's ifdef based on libevent version, which will include missing > headers, but maybe some refactoring for future will be needed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3129) Unexpected include behavior
[
https://issues.apache.org/jira/browse/THRIFT-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14530282#comment-14530282
]
Konrad Grochowski commented on THRIFT-3129:
---
all types from included file has to be forwarded by file name:
{code}
include "types.thrift"
struct NewStruct {
1: types.StructFromAnotherFile t;
}
{code}
just like in tutorial :)
> Unexpected include behavior
> ---
>
> Key: THRIFT-3129
> URL: https://issues.apache.org/jira/browse/THRIFT-3129
> Project: Thrift
> Issue Type: Bug
>Affects Versions: 0.9.2
>Reporter: David Ehrmann
>Priority: Minor
>
> I have the following directory structure:
> {code}
> ./project0/wrapper.thrift
> ./project1/struct.thrift
> {code}
> {code:title=project0/wrapper.thrift}
> include "struct.thrift"
> struct UserProfileResponse {
> 1: i32 responseCode,
> 2: UserProfile userProfile
> }
> {code}
> {code:title=project1/struct.thrift}
> struct UserProfile {
> 1: i32 uid,
> 2: string name
> }
> {code}
> While in project0 this command fails:
> {code}
> project0]$ thrift -I ../project1/struct.thrift --gen java wrapper.thrift
> [WARNING:/.../project0/wrapper.thrift:1] Could not find include file
> struct.thrift
>
> [ERROR:/.../project0/wrapper.thrift:5] (last token was 'UserProfile')
> Type "UserProfile" has not been defined.
> {code}
> This isn't what I expected. Since project1 is on the include path, I thought
> it would be searched when includes happen (like how gcc does it).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-1676) Allow specifying IP/hostname in TServer::serve
[
https://issues.apache.org/jira/browse/THRIFT-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14530208#comment-14530208
]
Konrad Grochowski commented on THRIFT-1676:
---
If I remember corectly TNonblockingServer does not use TServerSocket, so
THRIFT-1025 those not resolve this issue.
As is mentioned in comments above: it would be nice to refactor
TNonblockingServer to use TServerSocket, yet it might not be possible due to
libevent requirements.
> Allow specifying IP/hostname in TServer::serve
> --
>
> Key: THRIFT-1676
> URL: https://issues.apache.org/jira/browse/THRIFT-1676
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.8
> Environment: Mac OS X. Thrift 0.8.0.
>Reporter: Diwaker Gupta
>Assignee: Jake Farrell
> Fix For: 1.0
>
> Attachments:
> 0001-Allow-TNonBlockingServer-to-bind-a-specific-host.patch
>
>
> Thrift doesn't allow users to specify which IP/hostname to use for bind. As a
> result, a Thrift server usually ends up listening on ALL interfaces on a
> machine (bind uses INADDR_ANY). This is clearly undesirable in many cases
> where we may want to restrict connectivity to localhost or to within a
> particular subnet or targeted towards a specific host or IP.
> Here's a example of what TNonblockingServer does:
> {code}
> // Wildcard address
> error = getaddrinfo(NULL, port, &hints, &res0);
> if (error) {
> throw TException("TNonblockingServer::serve() getaddrinfo " +
> string(gai_strerror(error)));
> }
> // Pick the ipv6 address first since ipv4 addresses can be mapped
> // into ipv6 space.
> for (res = res0; res; res = res->ai_next) {
> if (res->ai_family == AF_INET6 || res->ai_next == NULL)
> break;
> }
> {code}
> As can be seen, the above code fragment provides NULL as the first param to
> getaddrinfo and always specifies AI_PASSIVE. This results in the behavior I
> described above.
> A better approach IMO is to provide the following interface instead:
> {code}
> TServer::serve(const char* hostOrIp, int port)
> {code}
> This is consistent with what other modern server frameworks do (node.js,
> netty etc.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3129) Unexpected include behavior
[
https://issues.apache.org/jira/browse/THRIFT-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14530204#comment-14530204
]
Konrad Grochowski commented on THRIFT-3129:
---
try {{-I../project1}} - it should point to include directory, not include itself
btw: struct might be a bad name for file as it's a keyword in couple languages
> Unexpected include behavior
> ---
>
> Key: THRIFT-3129
> URL: https://issues.apache.org/jira/browse/THRIFT-3129
> Project: Thrift
> Issue Type: Bug
>Affects Versions: 0.9.2
>Reporter: David Ehrmann
>Priority: Minor
>
> I have the following directory structure:
> {code}
> ./project0/wrapper.thrift
> ./project1/struct.thrift
> {code}
> wrapper.thrift:
> {code}
> include "struct.thrift"
> struct UserProfileResponse {
> 1: i32 responseCode,
> 2: UserProfile userProfile
> }
> {code}
> struct.thrift:
> {code}
> struct UserProfile {
> 1: i32 uid,
> 2: string name
> }
> {code}
> While in project0 this command fails:
> {code}
> project0]$ thrift -I ../project1/struct.thrift --gen java wrapper.thrift
> [WARNING:/.../project0/wrapper.thrift:1] Could not find include file
> struct.thrift
>
> [ERROR:/.../project0/wrapper.thrift:5] (last token was 'UserProfile')
> Type "UserProfile" has not been defined.
> {code}
> This isn't what I expected. Since project1 is on the include path, I thought
> it would be searched when includes happen (like how gcc does it).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (THRIFT-2000) TNonblocking server does not compile with libevent 2.0.21-stable
[ https://issues.apache.org/jira/browse/THRIFT-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reopened THRIFT-2000: --- I still need those ifdefs from patch - I'll double check it later. > TNonblocking server does not compile with libevent 2.0.21-stable > > > Key: THRIFT-2000 > URL: https://issues.apache.org/jira/browse/THRIFT-2000 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: libevent 2.0.21 > gcc 4.7 >Reporter: Konrad Grochowski >Assignee: James E. King, III > Fix For: 0.9.3 > > Attachments: libevent_2_0_21.patch > > > problem lays in usage of deprecated libevent API, which is still available > but in different headers > In patch there's ifdef based on libevent version, which will include missing > headers, but maybe some refactoring for future will be needed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3123) Missing include in compiler/cpp/src/main.h breaks build in some environments
[ https://issues.apache.org/jira/browse/THRIFT-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3123. --- Resolution: Fixed Fix Version/s: 0.9.3 I've changed patch a little (to include cstdio instead of stdio.h). Thanks for catching it! > Missing include in compiler/cpp/src/main.h breaks build in some environments > > > Key: THRIFT-3123 > URL: https://issues.apache.org/jira/browse/THRIFT-3123 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Reporter: David Ehrmann >Assignee: Konrad Grochowski >Priority: Minor > Fix For: 0.9.3 > > > main.h uses FILE. In a build environment where stdio.h isn't implicitly > included, this will be undefined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3124) Some signed/unsigned warnings while building compiler
[ https://issues.apache.org/jira/browse/THRIFT-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-3124. --- Resolution: Fixed Fix Version/s: 0.9.3 > Some signed/unsigned warnings while building compiler > - > > Key: THRIFT-3124 > URL: https://issues.apache.org/jira/browse/THRIFT-3124 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) > Environment: gcc 4.9.2 >Reporter: Konrad Grochowski >Assignee: Konrad Grochowski > Fix For: 0.9.3 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (THRIFT-3124) Some signed/unsigned warnings while building compiler
Konrad Grochowski created THRIFT-3124: - Summary: Some signed/unsigned warnings while building compiler Key: THRIFT-3124 URL: https://issues.apache.org/jira/browse/THRIFT-3124 Project: Thrift Issue Type: Bug Components: Compiler (General) Environment: gcc 4.9.2 Reporter: Konrad Grochowski Assignee: Konrad Grochowski -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3123) Missing include in compiler/cpp/src/main.h breaks build in some environments
[ https://issues.apache.org/jira/browse/THRIFT-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski updated THRIFT-3123: -- Component/s: Compiler (General) > Missing include in compiler/cpp/src/main.h breaks build in some environments > > > Key: THRIFT-3123 > URL: https://issues.apache.org/jira/browse/THRIFT-3123 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Reporter: David Ehrmann >Assignee: Konrad Grochowski >Priority: Minor > > main.h uses FILE. In a build environment where stdio.h isn't implicitly > included, this will be undefined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-3123) Missing include in compiler/cpp/src/main.h breaks build in some environments
[ https://issues.apache.org/jira/browse/THRIFT-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-3123: - Assignee: Konrad Grochowski > Missing include in compiler/cpp/src/main.h breaks build in some environments > > > Key: THRIFT-3123 > URL: https://issues.apache.org/jira/browse/THRIFT-3123 > Project: Thrift > Issue Type: Bug >Reporter: David Ehrmann >Assignee: Konrad Grochowski >Priority: Minor > > main.h uses FILE. In a build environment where stdio.h isn't implicitly > included, this will be undefined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski resolved THRIFT-3105.
---
Resolution: Fixed
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski closed THRIFT-3105.
-
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski updated THRIFT-3105:
--
Assignee: James E. King, III (was: Konrad Grochowski)
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523246#comment-14523246
]
Konrad Grochowski commented on THRIFT-3105:
---
and assignee cannot be changed on closed issue, and [~jking3] was not in proper
Jira group yesterday yet (not every Jira user can be assignee).
So I *did* remember it's important to leave resolved issue for a while ;)
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski reopened THRIFT-3105:
---
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523012#comment-14523012
]
Konrad Grochowski commented on THRIFT-3105:
---
If [~jfarrell] said so than ok, my bad. I was just used to him doing it :)
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski closed THRIFT-3105.
-
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski reopened THRIFT-3105:
---
Please do not close resolved(fixed) issues - they're closed as part of release
process (as far as I remember)
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski resolved THRIFT-3105.
---
Resolution: Fixed
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski resolved THRIFT-3105.
---
Resolution: Fixed
Fix Version/s: 0.9.3
commited, thanks!
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
> Fix For: 0.9.3
>
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (THRIFT-3105) C++ libthriftnb library on Windows build failure
[
https://issues.apache.org/jira/browse/THRIFT-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski reassigned THRIFT-3105:
-
Assignee: Konrad Grochowski
> C++ libthriftnb library on Windows build failure
>
>
> Key: THRIFT-3105
> URL: https://issues.apache.org/jira/browse/THRIFT-3105
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Visual Studio 2010, Boost 1.53, OpenSSL 1.0.1b, libevent
> 2.0.22
>Reporter: James E. King, III
>Assignee: Konrad Grochowski
>
> Attempted to build libthriftnb and got a build failure:
> {noformat}1>-- Build started: Project: libthriftnb, Configuration: Debug
> Win32 --
> 1> TNonblockingServer.cpp
> 1>c:\users\jim\workspace\thrift\lib\cpp\src\thrift\server\tnonblockingserver.cpp(1110):
> error C2664: 'getsockname' : cannot convert parameter 3 from 'unsigned int
> *' to 'int *'
> 1> Types pointed to are unrelated; conversion requires
> reinterpret_cast, C-style cast or function-style cast
> 1> TEvhttpServer.cpp
> 1> TEvhttpClientChannel.cpp
> 1> Generating Code...
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> {noformat}
> The type for the size should be changed to "socklen_t", it is declared as
> "unsigned int". TSocket uses this as well, and it works across platforms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520076#comment-14520076
]
Konrad Grochowski commented on THRIFT-727:
--
If the API is public users already have access to everything dump would
contain. By dump in this situation I mean results of {{operator<<}} so just all
fields transported by an exception, not memory dump (that indeed would expose
too much about server).
Maybe "dump" was a bad choice of word - I hoped it was clear in context of
"dumping contents" of exception.
> support native language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518213#comment-14518213
]
Konrad Grochowski commented on THRIFT-727:
--
Modifying tutorial requires changes in all languages examples.
I personally do not think that "what" is a good name for member variable, so
I'd change it... (something like 'failedOperation' sound more descriptive. Also
'why' could become 'reason').
So please continue, submit patch/pull request and we'll see if somebody opposes
;)
> support native language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518202#comment-14518202
]
Konrad Grochowski commented on THRIFT-727:
--
Hmmm, it would be exposure if shown to somebody not privileged to see it. I was
thinking, that this error message would be a good step in learning how to use
thrift, understanding service etc. How much that information will be finally
shown to end-user - that's the decision of developer. If it'd be decided to
show "what" output to public that means application has a very bad design and
there's nothing Thrift can do about it. It can help develop proper application
(that catches all errors and provides i18n messages depending on contents of
exception etc.).
Still I think that such "what" implementation could be useful even in final
application for logging/tracing (assuming only proper subset of users has read
access to logs).
> support native language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14516999#comment-14516999
]
Konrad Grochowski commented on THRIFT-727:
--
Good luck :)
> support native language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-727) support native language specific exception message
[
https://issues.apache.org/jira/browse/THRIFT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513851#comment-14513851
]
Konrad Grochowski commented on THRIFT-727:
--
I can see one situation in which overriding "what()" in C++ generated
exceptions could make sense - catching all errors via std::exception:
{code}
try {
performOperationsOnServer();
}
catch (const std::exception& e) {
std::cerr << "Unexpected error: " << e.what() << std::endl;
}
{code}
It's rather a bad practice not to catch method specific errors, yet it might be
used in some scratch code used in test client for service not maintained by
client creator. In such situations client might want to know better what went
wrong and "TException::Default" in log does not help a lot. I think that
overriding "what" in generated C++ exceptions to contain string like
"TException - MyException(code=4, message="Have a nice day")" is not that bad
idea - exeptions are usually small struct, so messages should be quite compact
and yet it would give 'test client writers' more information about 'how they
used service wrong'. Users experienced with given service will just use proper
per-case exceptions and their members.
As for better reason of exception: maybe message should state something like -
"TException - service thrown: RESULTS_OF_OBJ_DUMP"
Yet in C++ problems start with "what" returning "const char*"...
Also - this issue seems to focus on C++ implementation, I think it should
either be renamed (+1) or analysis of other languages should be performed (too
huge IMHO)
> support native language specific exception message
> --
>
> Key: THRIFT-727
> URL: https://issues.apache.org/jira/browse/THRIFT-727
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.2
> Environment: all
>Reporter: Ping Li
>Priority: Minor
>
> The current exception implement requires the error message to be declared and
> referenced explicitly, especially when it's sent from server to the client.
> On client side, this error message cannot be accessed via a native API like
> exception::what() in C++.
> Example,
> {code}
> exception MyException {
> 1: i32 code;
> 2: string message;
> }
> {code}
> On client side, it can only be accessed like this,
> {code}
> try {
> server->someMethod();
> } catch (MyException &e) {
> cout << "MyException: " << e.message << endl; // this will print the
> exception message
> cout << "MyException: " << e.what() << endl; // this will print
> TException::Default
> }
> {code}
> At the same time, if TException::message_ is initialized, exception::what()
> does work when the exception is caught locally.
> It's a little confusing when to use the native method, and when to use Thrift
> exception message data member.
> It'll be really nice if all exception messages can be accessed the same way
> thru the navtive language on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3014) AppVeyor support
[ https://issues.apache.org/jira/browse/THRIFT-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350106#comment-14350106 ] Konrad Grochowski commented on THRIFT-3014: --- Looks great, especially that current Travis Windows cross-build forces very old gcc (without any C++11 support) > AppVeyor support > > > Key: THRIFT-3014 > URL: https://issues.apache.org/jira/browse/THRIFT-3014 > Project: Thrift > Issue Type: Bug > Components: Build Process > Environment: Windows >Reporter: Roger Meier >Assignee: Roger Meier > Attachments: appveyor.yml > > > same as travis on linux is appveyor for WIndows > see it in action here: https://ci.appveyor.com/project/bufferoverflow/thrift/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-2870) C++ TJSONProtocol using locale dependent formatting
[ https://issues.apache.org/jira/browse/THRIFT-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-2870. --- Resolution: Fixed Fix Version/s: 0.9.3 Commited, thanks for help with testing :) > C++ TJSONProtocol using locale dependent formatting > --- > > Key: THRIFT-2870 > URL: https://issues.apache.org/jira/browse/THRIFT-2870 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: Linux, Boost 1.51 >Reporter: Simon Falsig >Assignee: Konrad Grochowski > Fix For: 0.9.3 > > Attachments: failing.txt, fixed.txt, initial.txt, > json_double_with_boost_math.patch, use-classic-locale-for-cpp-json_4.patch > > > I'm using Thrift for serializing objects (in C++) into JSON strings, which I > then store as files. This usually works fine, but if the locale of my system > is set to a locale where the decimal separator is ',' instead of '.' (for > instance in Denmark), then the TJSONProtocol (specifically the > writeJSONDouble function that does the double to string conversion through a > boost::lexical_cast) will also use this separator when serializing doubles. > This kinda plays havoc with the JSON specification, which does not allow for > localized formatting, and depends on always using '.' as a decimal separator. > I could imagine that there may be other more subtle places where the local > can have an effect, but this is currently the only place I've been having > trouble with. > I can see that the same problem has been fixed for C# (commit > 3da317bda100130b2f615034c46b0944888f0f14 / THRIFT-1245 C# JSON Protocol uses > culture-dependant decimal separator for double) but it doesn't seem as if > there's a similarly easy way to fix boost::lexical_cast... > Note that I'm using Thrift 0.9.0, but as far as I can see there hasn't been > any relevant changes to TJSONProtocol.cpp since. > Relevant thread on thrift-user mailing list can be found here: > http://mail-archives.apache.org/mod_mbox/thrift-user/201412.mbox/%3c7c2463f510dbb7548b4718e202ac1...@mail.gmail.com%3e > I've also attached a quick patch that works on my setup (see the patch file > comments for more information). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (THRIFT-2870) C++ TJSONProtocol using locale dependent formatting
[ https://issues.apache.org/jira/browse/THRIFT-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski reassigned THRIFT-2870: - Assignee: Konrad Grochowski > C++ TJSONProtocol using locale dependent formatting > --- > > Key: THRIFT-2870 > URL: https://issues.apache.org/jira/browse/THRIFT-2870 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: Linux, Boost 1.51 >Reporter: Simon Falsig >Assignee: Konrad Grochowski > Attachments: failing.txt, fixed.txt, initial.txt, > json_double_with_boost_math.patch, use-classic-locale-for-cpp-json_4.patch > > > I'm using Thrift for serializing objects (in C++) into JSON strings, which I > then store as files. This usually works fine, but if the locale of my system > is set to a locale where the decimal separator is ',' instead of '.' (for > instance in Denmark), then the TJSONProtocol (specifically the > writeJSONDouble function that does the double to string conversion through a > boost::lexical_cast) will also use this separator when serializing doubles. > This kinda plays havoc with the JSON specification, which does not allow for > localized formatting, and depends on always using '.' as a decimal separator. > I could imagine that there may be other more subtle places where the local > can have an effect, but this is currently the only place I've been having > trouble with. > I can see that the same problem has been fixed for C# (commit > 3da317bda100130b2f615034c46b0944888f0f14 / THRIFT-1245 C# JSON Protocol uses > culture-dependant decimal separator for double) but it doesn't seem as if > there's a similarly easy way to fix boost::lexical_cast... > Note that I'm using Thrift 0.9.0, but as far as I can see there hasn't been > any relevant changes to TJSONProtocol.cpp since. > Relevant thread on thrift-user mailing list can be found here: > http://mail-archives.apache.org/mod_mbox/thrift-user/201412.mbox/%3c7c2463f510dbb7548b4718e202ac1...@mail.gmail.com%3e > I've also attached a quick patch that works on my setup (see the patch file > comments for more information). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-2870) C++ TJSONProtocol using locale dependent formatting
[ https://issues.apache.org/jira/browse/THRIFT-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski updated THRIFT-2870: -- Attachment: json_double_with_boost_math.patch There were some problems with your patch: - it didn't apply on master (at least git apply refused it, I haven't check exactly why, I'd still have to change it - see second point) - it was using C++11 features, which we have to avoid in default C++ lib (new one is in development...) - JSONProtocolTest was failing - readDouble also had to be changed Please check attached patch if it solves your problem (it's made against master) and if so I'll commit it. > C++ TJSONProtocol using locale dependent formatting > --- > > Key: THRIFT-2870 > URL: https://issues.apache.org/jira/browse/THRIFT-2870 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: Linux, Boost 1.51 >Reporter: Simon Falsig > Attachments: failing.txt, fixed.txt, initial.txt, > json_double_with_boost_math.patch, use-classic-locale-for-cpp-json_4.patch > > > I'm using Thrift for serializing objects (in C++) into JSON strings, which I > then store as files. This usually works fine, but if the locale of my system > is set to a locale where the decimal separator is ',' instead of '.' (for > instance in Denmark), then the TJSONProtocol (specifically the > writeJSONDouble function that does the double to string conversion through a > boost::lexical_cast) will also use this separator when serializing doubles. > This kinda plays havoc with the JSON specification, which does not allow for > localized formatting, and depends on always using '.' as a decimal separator. > I could imagine that there may be other more subtle places where the local > can have an effect, but this is currently the only place I've been having > trouble with. > I can see that the same problem has been fixed for C# (commit > 3da317bda100130b2f615034c46b0944888f0f14 / THRIFT-1245 C# JSON Protocol uses > culture-dependant decimal separator for double) but it doesn't seem as if > there's a similarly easy way to fix boost::lexical_cast... > Note that I'm using Thrift 0.9.0, but as far as I can see there hasn't been > any relevant changes to TJSONProtocol.cpp since. > Relevant thread on thrift-user mailing list can be found here: > http://mail-archives.apache.org/mod_mbox/thrift-user/201412.mbox/%3c7c2463f510dbb7548b4718e202ac1...@mail.gmail.com%3e > I've also attached a quick patch that works on my setup (see the patch file > comments for more information). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2870) C++ TJSONProtocol using locale dependent formatting
[
https://issues.apache.org/jira/browse/THRIFT-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327397#comment-14327397
]
Konrad Grochowski commented on THRIFT-2870:
---
I don't recall right now, but I've probably just executed {{make check}} on
whole repo. Probably some tests in test/cpp (not in lib/cpp/test) failed.
> C++ TJSONProtocol using locale dependent formatting
> ---
>
> Key: THRIFT-2870
> URL: https://issues.apache.org/jira/browse/THRIFT-2870
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9
> Environment: Linux, Boost 1.51
>Reporter: Simon Falsig
> Attachments: failing.txt, fixed.txt, initial.txt,
> use-classic-locale-for-cpp-json_4.patch
>
>
> I'm using Thrift for serializing objects (in C++) into JSON strings, which I
> then store as files. This usually works fine, but if the locale of my system
> is set to a locale where the decimal separator is ',' instead of '.' (for
> instance in Denmark), then the TJSONProtocol (specifically the
> writeJSONDouble function that does the double to string conversion through a
> boost::lexical_cast) will also use this separator when serializing doubles.
> This kinda plays havoc with the JSON specification, which does not allow for
> localized formatting, and depends on always using '.' as a decimal separator.
> I could imagine that there may be other more subtle places where the local
> can have an effect, but this is currently the only place I've been having
> trouble with.
> I can see that the same problem has been fixed for C# (commit
> 3da317bda100130b2f615034c46b0944888f0f14 / THRIFT-1245 C# JSON Protocol uses
> culture-dependant decimal separator for double) but it doesn't seem as if
> there's a similarly easy way to fix boost::lexical_cast...
> Note that I'm using Thrift 0.9.0, but as far as I can see there hasn't been
> any relevant changes to TJSONProtocol.cpp since.
> Relevant thread on thrift-user mailing list can be found here:
> http://mail-archives.apache.org/mod_mbox/thrift-user/201412.mbox/%3c7c2463f510dbb7548b4718e202ac1...@mail.gmail.com%3e
> I've also attached a quick patch that works on my setup (see the patch file
> comments for more information).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2724) Coding standards page
[ https://issues.apache.org/jira/browse/THRIFT-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305304#comment-14305304 ] Konrad Grochowski commented on THRIFT-2724: --- branch squashed, pull request added: https://github.com/apache/thrift/pull/371 > Coding standards page > - > > Key: THRIFT-2724 > URL: https://issues.apache.org/jira/browse/THRIFT-2724 > Project: Thrift > Issue Type: Improvement > Components: Documentation >Reporter: Konrad Grochowski > Attachments: coding_standards.patch > > > it would be nice to have some basic coding standards for all langs used by > thrift, especially those that do not come with 'built-in' standards. > I'm suggesting some simple, short guidelines, just to help contributors > prepare good patch > preferably: new doc in docs folder, linked from doc/contributing.md -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2724) Coding standards page
[ https://issues.apache.org/jira/browse/THRIFT-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304031#comment-14304031 ] Konrad Grochowski commented on THRIFT-2724: --- All changes should be available in my branch: https://github.com/hcorg/thrift/tree/coding_standards I've never had time to finish C++ coding standards, maybe if it's get public I'll finally force myself to do it ;) I can rebase branch and merge it, making it a good starting point for future contributions (I was hoping to complete all subtasks before merging, but I can't provide standards for langs I'm not actively using, so making it public and waiting for feedback might be a better idea). As for linters etc: "make style" already works (I'm pretty sure it was merged to master on some point) - as it introduces some new dependencies it is not merged with 'make check', but it runs clang-format on C++ code and codespell on whole repo. clang-format could be also configured to work with JS code > Coding standards page > - > > Key: THRIFT-2724 > URL: https://issues.apache.org/jira/browse/THRIFT-2724 > Project: Thrift > Issue Type: Improvement > Components: Documentation >Reporter: Konrad Grochowski > Attachments: coding_standards.patch > > > it would be nice to have some basic coding standards for all langs used by > thrift, especially those that do not come with 'built-in' standards. > I'm suggesting some simple, short guidelines, just to help contributors > prepare good patch > preferably: new doc in docs folder, linked from doc/contributing.md -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-2907) 'ntohll' macro redefined
[
https://issues.apache.org/jira/browse/THRIFT-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski resolved THRIFT-2907.
---
Resolution: Fixed
Fix Version/s: 0.9.3
Commited, thanks!
> 'ntohll' macro redefined
>
>
> Key: THRIFT-2907
> URL: https://issues.apache.org/jira/browse/THRIFT-2907
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.9.2
> Environment: Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM
> 3.5svn)
> Target: x86_64-apple-darwin14.0.0
> Thread model: posix
>Reporter: Jon Parise
>Assignee: Konrad Grochowski
>Priority: Trivial
> Fix For: 0.9.3
>
>
> The {{ntohll}} macro is already defined in {{/usr/include/sys/_endian.h}} on
> Mac OS X.
> {code}
> In file included from gen-cpp/shared_constants.cpp:7:
> In file included from gen-cpp/shared_constants.h:10:
> In file included from gen-cpp/shared_types.h:14:
> ../../lib/cpp/src/thrift/protocol/TProtocol.h:131:11: warning: 'ntohll' macro
> redefined
> # define ntohll(n) ( (((uint64_t)ntohl((uint32_t)n)) << 32) +
> ntohl((uint32_t)(n >> 32)) )
> ^
> /usr/include/sys/_endian.h:140:9: note: previous definition is here
> #define ntohll(x) __DARWIN_OSSwapInt64(x)
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (THRIFT-2907) 'ntohll' macro redefined
[
https://issues.apache.org/jira/browse/THRIFT-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski reassigned THRIFT-2907:
-
Assignee: Konrad Grochowski
> 'ntohll' macro redefined
>
>
> Key: THRIFT-2907
> URL: https://issues.apache.org/jira/browse/THRIFT-2907
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.9.2
> Environment: Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM
> 3.5svn)
> Target: x86_64-apple-darwin14.0.0
> Thread model: posix
>Reporter: Jon Parise
>Assignee: Konrad Grochowski
>Priority: Trivial
>
> The {{ntohll}} macro is already defined in {{/usr/include/sys/_endian.h}} on
> Mac OS X.
> {code}
> In file included from gen-cpp/shared_constants.cpp:7:
> In file included from gen-cpp/shared_constants.h:10:
> In file included from gen-cpp/shared_types.h:14:
> ../../lib/cpp/src/thrift/protocol/TProtocol.h:131:11: warning: 'ntohll' macro
> redefined
> # define ntohll(n) ( (((uint64_t)ntohl((uint32_t)n)) << 32) +
> ntohl((uint32_t)(n >> 32)) )
> ^
> /usr/include/sys/_endian.h:140:9: note: previous definition is here
> #define ntohll(x) __DARWIN_OSSwapInt64(x)
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-2799) Build Problem(s): ld: library not found for -l:libboost_unit_test_framework.a
[ https://issues.apache.org/jira/browse/THRIFT-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-2799. --- Resolution: Duplicate > Build Problem(s): ld: library not found for -l:libboost_unit_test_framework.a > - > > Key: THRIFT-2799 > URL: https://issues.apache.org/jira/browse/THRIFT-2799 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.9.1 > Environment: Mac OS X Yosemite >Reporter: David Laxer >Assignee: Jake Farrell > Labels: boost > Fix For: 0.9.3 > > Attachments: 0001-THRIFT-2799-C-Fix-build-on-OS-X.patch, Makefile, > Makefile, Makefile, Makefile.am, Makefile.am, config.log > > > /bin/sh ../../../libtool --tag=CXX --mode=link g++ -Wall -Wextra -pedantic > -g -O2 -std=c++11 -L/usr/local/lib -o processor_test > processor/ProcessorTest.o processor/EventLog.o processor/ServerThread.o > libprocessortest.la ../../../lib/cpp/libthrift.la > ../../../lib/cpp/libthriftnb.la -L/usr/local/lib -levent > -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread > libtool: link: g++ -Wall -Wextra -pedantic -g -O2 -std=c++11 -o > .libs/processor_test processor/ProcessorTest.o processor/EventLog.o > processor/ServerThread.o -Wl,-bind_at_load -L/usr/local/lib > ./.libs/libprocessortest.a ../../../lib/cpp/.libs/libthrift.dylib > ../../../lib/cpp/.libs/libthriftnb.dylib /usr/local/lib/libevent.dylib > -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread > ld: library not found for -l:libboost_unit_test_framework.a > collect2: error: ld returned 1 exit status > make[4]: *** [processor_test] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > David-Laxers-MacBook-Pro:thrift davidlaxer$ sudo port list select boost > Password: > boost @1.56.0 devel/boost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-2906) library not found for -l:libboost_unit_test_framework.a
[
https://issues.apache.org/jira/browse/THRIFT-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski resolved THRIFT-2906.
---
Resolution: Fixed
Fix Version/s: 0.9.3
It worked on my env, so - pushed :)
I've changed it a little bit - I've added BOOST_TEST_LDADD variable, so future
changes in linking (if needed) should be made easier.
Thanks for patch!
> library not found for -l:libboost_unit_test_framework.a
> ---
>
> Key: THRIFT-2906
> URL: https://issues.apache.org/jira/browse/THRIFT-2906
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, C++ - Compiler
>Affects Versions: 0.9.2
> Environment: Mac OS X 10.10.1 (Darwin 14.0.0)
> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
> Target: x86_64-apple-darwin14.0.0
> Thread model: posix
>Reporter: Jon Parise
>Assignee: Konrad Grochowski
>Priority: Minor
> Labels: build, patch
> Fix For: 0.9.3
>
>
> The {{ld(1)}} (clang) that ships with Mac OS X 10.10.1 doesn't understand the
> {{-l:libfoo.a}} syntax that it used to link
> {{libboost_unit_test_framework.a}}:
> {code}
> /bin/sh ../../../libtool --tag=CXX --mode=link g++ -Wall -Wextra -pedantic
> -g -O2 -std=c++11 -L/usr/local/lib -o processor_test
> processor/ProcessorTest.o processor/EventLog.o processor/ServerThread.o
> libprocessortest.la ../../../lib/cpp/libthrift.la
> ../../../lib/cpp/libthriftnb.la -L/usr/local/lib -levent
> -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread
> libtool: link: g++ -Wall -Wextra -pedantic -g -O2 -std=c++11 -o
> .libs/processor_test processor/ProcessorTest.o processor/EventLog.o
> processor/ServerThread.o -Wl,-bind_at_load -L/usr/local/lib
> ./.libs/libprocessortest.a ../../../lib/cpp/.libs/libthrift.dylib
> -L/usr/local/Cellar/openssl/1.0.1j_1/lib
> ../../../lib/cpp/.libs/libthriftnb.dylib -levent
> -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread
> ld: library not found for -l:libboost_unit_test_framework.a
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (THRIFT-2906) library not found for -l:libboost_unit_test_framework.a
[
https://issues.apache.org/jira/browse/THRIFT-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Grochowski reassigned THRIFT-2906:
-
Assignee: Konrad Grochowski
> library not found for -l:libboost_unit_test_framework.a
> ---
>
> Key: THRIFT-2906
> URL: https://issues.apache.org/jira/browse/THRIFT-2906
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, C++ - Compiler
>Affects Versions: 0.9.2
> Environment: Mac OS X 10.10.1 (Darwin 14.0.0)
> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
> Target: x86_64-apple-darwin14.0.0
> Thread model: posix
>Reporter: Jon Parise
>Assignee: Konrad Grochowski
>Priority: Minor
> Labels: build, patch
>
> The {{ld(1)}} (clang) that ships with Mac OS X 10.10.1 doesn't understand the
> {{-l:libfoo.a}} syntax that it used to link
> {{libboost_unit_test_framework.a}}:
> {code}
> /bin/sh ../../../libtool --tag=CXX --mode=link g++ -Wall -Wextra -pedantic
> -g -O2 -std=c++11 -L/usr/local/lib -o processor_test
> processor/ProcessorTest.o processor/EventLog.o processor/ServerThread.o
> libprocessortest.la ../../../lib/cpp/libthrift.la
> ../../../lib/cpp/libthriftnb.la -L/usr/local/lib -levent
> -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread
> libtool: link: g++ -Wall -Wextra -pedantic -g -O2 -std=c++11 -o
> .libs/processor_test processor/ProcessorTest.o processor/EventLog.o
> processor/ServerThread.o -Wl,-bind_at_load -L/usr/local/lib
> ./.libs/libprocessortest.a ../../../lib/cpp/.libs/libthrift.dylib
> -L/usr/local/Cellar/openssl/1.0.1j_1/lib
> ../../../lib/cpp/.libs/libthriftnb.dylib -levent
> -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread
> ld: library not found for -l:libboost_unit_test_framework.a
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2906) library not found for -l:libboost_unit_test_framework.a
[
https://issues.apache.org/jira/browse/THRIFT-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253601#comment-14253601
]
Konrad Grochowski commented on THRIFT-2906:
---
maybe it would be better to just change all includes to "boost/test/include"
and remove linking at all. I'm pretty sure direct linking was already tested
and it too didn't work on some envs
> library not found for -l:libboost_unit_test_framework.a
> ---
>
> Key: THRIFT-2906
> URL: https://issues.apache.org/jira/browse/THRIFT-2906
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, C++ - Compiler
>Affects Versions: 0.9.2
> Environment: Mac OS X 10.10.1 (Darwin 14.0.0)
> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
> Target: x86_64-apple-darwin14.0.0
> Thread model: posix
>Reporter: Jon Parise
>Priority: Minor
> Labels: build, patch
>
> The {{ld(1)}} (clang) that ships with Mac OS X 10.10.1 doesn't understand the
> {{-l:libfoo.a}} syntax that it used to link
> {{libboost_unit_test_framework.a}}:
> {code}
> /bin/sh ../../../libtool --tag=CXX --mode=link g++ -Wall -Wextra -pedantic
> -g -O2 -std=c++11 -L/usr/local/lib -o processor_test
> processor/ProcessorTest.o processor/EventLog.o processor/ServerThread.o
> libprocessortest.la ../../../lib/cpp/libthrift.la
> ../../../lib/cpp/libthriftnb.la -L/usr/local/lib -levent
> -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread
> libtool: link: g++ -Wall -Wextra -pedantic -g -O2 -std=c++11 -o
> .libs/processor_test processor/ProcessorTest.o processor/EventLog.o
> processor/ServerThread.o -Wl,-bind_at_load -L/usr/local/lib
> ./.libs/libprocessortest.a ../../../lib/cpp/.libs/libthrift.dylib
> -L/usr/local/Cellar/openssl/1.0.1j_1/lib
> ../../../lib/cpp/.libs/libthriftnb.dylib -levent
> -l:libboost_unit_test_framework.a -lssl -lcrypto -lpthread
> ld: library not found for -l:libboost_unit_test_framework.a
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-2888) import of is missing in JSON generator
[ https://issues.apache.org/jira/browse/THRIFT-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Grochowski resolved THRIFT-2888. --- Resolution: Fixed Fix Version/s: 0.9.3 Assignee: Pascal Bach My bad, thanks for catching it :) Commited. > import of is missing in JSON generator > --- > > Key: THRIFT-2888 > URL: https://issues.apache.org/jira/browse/THRIFT-2888 > Project: Thrift > Issue Type: Bug > Components: JSON - Compiler >Affects Versions: 1.0 >Reporter: Pascal Bach >Assignee: Pascal Bach > Fix For: 0.9.3 > > Attachments: > 0001-Add-missing-import-for-limits-to-JSON-generator.patch > > > The JSON generator uses std::numeric_limits which is part of limits. But this > is not importet. This doesn't work on some compilers. > The file should be included to be on the save side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2800) error in running make : error in thrifty.cc the method yyparse() reserch the method strdup() (not declared)
[ https://issues.apache.org/jira/browse/THRIFT-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240105#comment-14240105 ] Konrad Grochowski commented on THRIFT-2800: --- if anything I'd try applying configure.ac changes - forcing [ext] usage. Maybe in some "if on cygwin" conditional. Strdup removal was not solving all problems and sooner or later someone else will use strdup, and will not know there is any problem until some other person tries compiling on cygwin. > error in running make : error in thrifty.cc the method yyparse() reserch the > method strdup() (not declared) > --- > > Key: THRIFT-2800 > URL: https://issues.apache.org/jira/browse/THRIFT-2800 > Project: Thrift > Issue Type: Bug > Components: Build Process > Environment: cygwin64 > Windows 7 _ 64 bits >Reporter: saber hattay > Labels: build, github-import > Attachments: ConfigureAndMake.txt, ConfigureResult.jpg, > ErrorMake.txt, FileNoError.jpg, MakeAndFlex.jpg, MakeResult.jpg, TutoJS.jpg, > TutoJS_gen.jpg, bootstrapShResult.jpg, commandDos.jpg, commandeMake.jpg, > errorMake.jpg, strdup.patch, strdup.patch, strdup_removed.patch, > thriftyNewVersion.yy, thriftyOldVersion.yy, tutorial_types.js > > > Hello, > When I tape this command : configure && make > I receive this result : > make : *** error 2 > cause by the appel of this function strdup() (function not declared). > It's the first time I want to build thrift. > Thank you in advance for you help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
