[jira] [Closed] (THRIFT-3674) Java generated deep copy is shallow

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III closed THRIFT-3674.
--
Resolution: Duplicate
  Assignee: James E. King, III

Closing as a duplicate of another report, which has a pull request.

> Java generated deep copy is shallow
> ---
>
> Key: THRIFT-3674
> URL: https://issues.apache.org/jira/browse/THRIFT-3674
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.9.2
>Reporter: Mykhailo Kozik
>Assignee: James E. King, III
>
> Minimum reproducible scenario
> I have an IDL called test.thrift
> {code}
> struct A {
>   1: required B b;
> }
> struct B {
>   1: required string id;
> }
> {code}
> Then I generate java file
> {code}
> thrift -gen java -out src/main/java/gen src/main/resources/test.thrift
> {code}
> Generated object for A contains method called deepCopy, which is calling copy 
> constructor, which is actually just shallow copy (copy references)
> {code}
> class A {
> //...
> public A(A other) {
> if (other.isSetB()) {
>   this.b = other.b;
> }
>   }
>   public A deepCopy() {
> return new A(this);
>   }
> //...
> }
> {code}
> Instead of copying references we need copy deepCopy recursively.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (THRIFT-4177) Java compiler produces deep copy constructor that could make shallow copy instead

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-4177:
---
Affects Version/s: 0.9.2

> Java compiler produces deep copy constructor that could make shallow copy 
> instead
> -
>
> Key: THRIFT-4177
> URL: https://issues.apache.org/jira/browse/THRIFT-4177
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.9.2
>Reporter: Deniss Afonin
>
> Java compiler produces deep copy constructor that makes shallow copies for 
> referenced objects from collections when they are defined after the root 
> object in the thrift file.
> For example, consider following thrift file:
> struct Foo {
> 1: optional list bars,
> }
> struct Bar {
> 1: optional string value,
> }
> new Foo().deepCopy() will produce a copy of Foo with a copy of a list that 
> reference the same Bar object.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (THRIFT-4176) Implement a threaded and threadpool server type for Rust

[Allen George (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973260#comment-15973260
 ] 

Allen George edited comment on THRIFT-4176 at 4/18/17 6:44 PM:
---

[~codesf] That's a very fair point. For some reason I assumed it was a 
requirement to have different server implementations.

I think most Rust users would really like to see both a server and client based 
on async sockets in [Tokio|https://tokio.rs]. Unfortunately Tokio is fairly 
new, and, I need some time getting up to speed on it. It's mostly the "needs to 
mature a bit" aspect that keeps me from using it. I have been working a bit on 
this ticket 
[here|https://github.com/allengeorge/thrift/commit/66198a10a8e243cc73478af89fa3fb137acbfd8c]
 (ignore the commit date - I'm rebasing), but most of the changes center around 
making components threadsafe and more ergonomic.

With that in mind, how about this as a plan forward:

# Replace the current  single-threaded, synchronous {{TSimpleServer}} with a 
{{TThreadpoolServer}} based on Rust stdlib synchronous sockets. A 
threadpool-based server is probably good enough for most people right now, 
because you can configure it to get either simple-server-like behavior or 
unbounded-threaded-server behavior.
# As soon as the new threadpool-server is in, work on a Tokio-based 
replacement. This is a much longer-term project because I'll have to rework 
many IO components to be async.

This means that at any point and time we'll only have a single Rust server type 
and avoid the situation in THRIFT-3096. Does that sound like a reasonable 
approach?

And, [~jking3] hopefully we don't have the same issue with the Rust codebase :)


was (Author: allengeorge):
[~codesf] That's a very fair point. For some reason I assumed it was a 
requirement to have different server implementations.

I think most Rust users would really like to see both a server and client based 
on async sockets in [Tokio|tokio.rs]. Unfortunately Tokio is fairly new, and, I 
need some time getting up to speed on it. It's mostly the "needs to mature a 
bit" aspect that keeps me from using it. I have been working a bit on this 
ticket 
[here|https://github.com/allengeorge/thrift/commit/66198a10a8e243cc73478af89fa3fb137acbfd8c]
 (ignore the commit date - I'm rebasing), but most of the changes center around 
making components threadsafe and more ergonomic.

With that in mind, how about this as a plan forward:

# Replace the current  single-threaded, synchronous {{TSimpleServer}} with a 
{{TThreadpoolServer}} based on Rust stdlib synchronous sockets. A 
threadpool-based server is probably good enough for most people right now, 
because you can configure it to get either simple-server-like behavior or 
unbounded-threaded-server behavior.
# As soon as the new threadpool-server is in, work on a Tokio-based 
replacement. This is a much longer-term project because I'll have to rework 
many IO components to be async.

This means that at any point and time we'll only have a single Rust server type 
and avoid the situation in THRIFT-3096. Does that sound like a reasonable 
approach?

And, [~jking3] hopefully we don't have the same issue with the Rust codebase :)

> Implement a threaded and threadpool server type for Rust
> 
>
> Key: THRIFT-4176
> URL: https://issues.apache.org/jira/browse/THRIFT-4176
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>
> Currently the Rust client library only provides a single-threaded server. Add 
> both a multi-threaded server and a threadpool-based server and add the 
> relevant options to the cross-test code as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4176) Implement a threaded and threadpool server type for Rust

[Allen George (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973260#comment-15973260
 ] 

Allen George commented on THRIFT-4176:
--

[~codesf] That's a very fair point. For some reason I assumed it was a 
requirement to have different server implementations.

I think most Rust users would really like to see both a server and client based 
on async sockets in [Tokio|tokio.rs]. Unfortunately Tokio is fairly new, and, I 
need some time getting up to speed on it. It's mostly the "needs to mature a 
bit" aspect that keeps me from using it. I have been working a bit on this 
ticket 
[here|https://github.com/allengeorge/thrift/commit/66198a10a8e243cc73478af89fa3fb137acbfd8c]
 (ignore the commit date - I'm rebasing), but most of the changes center around 
making components threadsafe and more ergonomic.

With that in mind, how about this as a plan forward:

# Replace the current  single-threaded, synchronous {{TSimpleServer}} with a 
{{TThreadpoolServer}} based on Rust stdlib synchronous sockets. A 
threadpool-based server is probably good enough for most people right now, 
because you can configure it to get either simple-server-like behavior or 
unbounded-threaded-server behavior.
# As soon as the new threadpool-server is in, work on a Tokio-based 
replacement. This is a much longer-term project because I'll have to rework 
many IO components to be async.

This means that at any point and time we'll only have a single Rust server type 
and avoid the situation in THRIFT-3096. Does that sound like a reasonable 
approach?

And, [~jking3] hopefully we don't have the same issue with the Rust codebase :)

> Implement a threaded and threadpool server type for Rust
> 
>
> Key: THRIFT-4176
> URL: https://issues.apache.org/jira/browse/THRIFT-4176
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>
> Currently the Rust client library only provides a single-threaded server. Add 
> both a multi-threaded server and a threadpool-based server and add the 
> relevant options to the cross-test code as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4177) Java compiler produces deep copy constructor that could make shallow copy instead

[Deniss Afonin (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973206#comment-15973206
 ] 

Deniss Afonin commented on THRIFT-4177:
---

Yes, this issue is definitely a duplicate of THRIFT-3674, my bad.
And yes, it might be more reasonable to mark THRIFT-3674 as duplicate, cause of 
PR.

> Java compiler produces deep copy constructor that could make shallow copy 
> instead
> -
>
> Key: THRIFT-4177
> URL: https://issues.apache.org/jira/browse/THRIFT-4177
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>
> Java compiler produces deep copy constructor that makes shallow copies for 
> referenced objects from collections when they are defined after the root 
> object in the thrift file.
> For example, consider following thrift file:
> struct Foo {
> 1: optional list bars,
> }
> struct Bar {
> 1: optional string value,
> }
> new Foo().deepCopy() will produce a copy of Foo with a copy of a list that 
> reference the same Bar object.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4177) Java compiler produces deep copy constructor that could make shallow copy instead

[James E. King, III (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973067#comment-15973067
 ] 

James E. King, III commented on THRIFT-4177:


Hi, I misread the meaning of the title.  I assumed you were saying we didn't 
need deep copy in the title text.
It looks like this is a duplicate of THRIFT-3674; or we can make THRIFT-3674 a 
duplicate of this since this has a PR now.  Thoughts?

> Java compiler produces deep copy constructor that could make shallow copy 
> instead
> -
>
> Key: THRIFT-4177
> URL: https://issues.apache.org/jira/browse/THRIFT-4177
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>
> Java compiler produces deep copy constructor that makes shallow copies for 
> referenced objects from collections when they are defined after the root 
> object in the thrift file.
> For example, consider following thrift file:
> struct Foo {
> 1: optional list bars,
> }
> struct Bar {
> 1: optional string value,
> }
> new Foo().deepCopy() will produce a copy of Foo with a copy of a list that 
> reference the same Bar object.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4177) Java compiler produces deep copy constructor that could make shallow copy instead

[James E. King, III (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973063#comment-15973063
 ] 

James E. King, III commented on THRIFT-4177:


I just linked a number of issues in the backlog, some already done and some 
not, to this issue.
It looks like there has been a desire to have a deep copy mechanism for a long 
time.
Folks who use Java more should comment on this PR.

> Java compiler produces deep copy constructor that could make shallow copy 
> instead
> -
>
> Key: THRIFT-4177
> URL: https://issues.apache.org/jira/browse/THRIFT-4177
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>
> Java compiler produces deep copy constructor that makes shallow copies for 
> referenced objects from collections when they are defined after the root 
> object in the thrift file.
> For example, consider following thrift file:
> struct Foo {
> 1: optional list bars,
> }
> struct Bar {
> 1: optional string value,
> }
> new Foo().deepCopy() will produce a copy of Foo with a copy of a list that 
> reference the same Bar object.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4177) Java compiler produces deep copy constructor that could make shallow copy instead

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973016#comment-15973016
 ] 

ASF GitHub Bot commented on THRIFT-4177:


GitHub user afds opened a pull request:

https://github.com/apache/thrift/pull/1254

THRIFT-4177 fix java deep copy

Java compiler produces deep copy constructor that could make shallow copy 
instead.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afds/thrift THRIFT-4177

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1254.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1254


commit b4c56d19504f705a02df2ddd68680017e45979f1
Author: Deniss Afonin 
Date:   2017-04-18T16:27:49Z

THRIFT-4177 fix java deep copy

Java compiler produces deep copy constructor that could make shallow copy 
instead.




> Java compiler produces deep copy constructor that could make shallow copy 
> instead
> -
>
> Key: THRIFT-4177
> URL: https://issues.apache.org/jira/browse/THRIFT-4177
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>
> Java compiler produces deep copy constructor that makes shallow copies for 
> referenced objects from collections when they are defined after the root 
> object in the thrift file.
> For example, consider following thrift file:
> struct Foo {
> 1: optional list bars,
> }
> struct Bar {
> 1: optional string value,
> }
> new Foo().deepCopy() will produce a copy of Foo with a copy of a list that 
> reference the same Bar object.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] thrift pull request #1254: THRIFT-4177 fix java deep copy

[afds]

GitHub user afds opened a pull request:

https://github.com/apache/thrift/pull/1254

THRIFT-4177 fix java deep copy

Java compiler produces deep copy constructor that could make shallow copy 
instead.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afds/thrift THRIFT-4177

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1254.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1254


commit b4c56d19504f705a02df2ddd68680017e45979f1
Author: Deniss Afonin 
Date:   2017-04-18T16:27:49Z

THRIFT-4177 fix java deep copy

Java compiler produces deep copy constructor that could make shallow copy 
instead.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-2221:
---
Issue Type: Improvement  (was: Task)

> 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
>Priority: Minor
>  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] [Updated] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-2221:
---
Priority: Major  (was: Minor)

> 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-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[James E. King, III (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972998#comment-15972998
 ] 

James E. King, III commented on THRIFT-2221:


It should be fairly easy to to.  I can add it.  I'll assign this one to myself 
for now.

> 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: Task
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Priority: Minor
>  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] [Assigned] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III reassigned THRIFT-2221:
--

Assignee: James E. King, III

> 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: Task
>  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
>Priority: Minor
>  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-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972900#comment-15972900
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

This looks like a very suitable solution, and only moderate effort to make. I 
think many
people nowadays use std::shared_ptr so I think the benefit is worthwhile, what 
do you think?

Could you implement this change? Or should I give it a try, and would a PR with 
this change
be accepted?


> 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: Task
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Priority: Minor
>  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)

[GitHub] thrift issue #1247: MSYS-appveyor-install.bat: use mingw-w64-xxx variants

[emmenlau]

Github user emmenlau commented on the issue:

https://github.com/apache/thrift/pull/1247
  
Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-4176) Implement a threaded and threadpool server type for Rust

[James E. King, III (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972819#comment-15972819
 ] 

James E. King, III commented on THRIFT-4176:


Sounds like THRIFT-3096. :)

> Implement a threaded and threadpool server type for Rust
> 
>
> Key: THRIFT-4176
> URL: https://issues.apache.org/jira/browse/THRIFT-4176
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>
> Currently the Rust client library only provides a single-threaded server. Add 
> both a multi-threaded server and a threadpool-based server and add the 
> relevant options to the cross-test code as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4176) Implement a threaded and threadpool server type for Rust

[Randy Abernethy (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972684#comment-15972684
 ] 

Randy Abernethy commented on THRIFT-4176:
-

I would argue for a single great rust server. Multiple servers confuse users, 
they don't want to have to figure out which server to use and in most cases 
there is one server model that performs best or close enough in the vast 
majority of cases. If users need hyper performance or special cases they will 
probably write their own anyway. One server will reduce testing burden and 
focus all improvements iin one place. Some of our languages (Java/c++) look 
like a server science project and have caused users to waste huge sums of time 
trying to compare performance and features (often without the necessary 
context).. just my 2 cents



> Implement a threaded and threadpool server type for Rust
> 
>
> Key: THRIFT-4176
> URL: https://issues.apache.org/jira/browse/THRIFT-4176
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>
> Currently the Rust client library only provides a single-threaded server. Add 
> both a multi-threaded server and a threadpool-based server and add the 
> relevant options to the cross-test code as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4177) Java compiler produces deep copy constructor that could make shallow copy instead

[Deniss Afonin (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972648#comment-15972648
 ] 

Deniss Afonin commented on THRIFT-4177:
---

Will provide a patch soon.

> Java compiler produces deep copy constructor that could make shallow copy 
> instead
> -
>
> Key: THRIFT-4177
> URL: https://issues.apache.org/jira/browse/THRIFT-4177
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Reporter: Deniss Afonin
>
> Java compiler produces deep copy constructor that makes shallow copies for 
> referenced objects from collections when they are defined after the root 
> object in the thrift file.
> For example, consider following thrift file:
> struct Foo {
> 1: optional list bars,
> }
> struct Bar {
> 1: optional string value,
> }
> new Foo().deepCopy() will produce a copy of Foo with a copy of a list that 
> reference the same Bar object.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] thrift pull request #1247: MSYS-appveyor-install.bat: use mingw-w64-xxx vari...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1247


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (THRIFT-4177) Java compiler produces deep copy constructor that could make shallow copy instead

[Deniss Afonin (JIRA)]

Deniss Afonin created THRIFT-4177:
-

 Summary: Java compiler produces deep copy constructor that could 
make shallow copy instead
 Key: THRIFT-4177
 URL: https://issues.apache.org/jira/browse/THRIFT-4177
 Project: Thrift
  Issue Type: Bug
  Components: Java - Compiler
Reporter: Deniss Afonin


Java compiler produces deep copy constructor that makes shallow copies for 
referenced objects from collections when they are defined after the root object 
in the thrift file.

For example, consider following thrift file:

struct Foo {
1: optional list bars,
}

struct Bar {
1: optional string value,
}

new Foo().deepCopy() will produce a copy of Foo with a copy of a list that 
reference the same Bar object.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (THRIFT-4158) minor issue in README-MSYS2.md

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-4158.

   Resolution: Fixed
Fix Version/s: 0.11.0

> minor issue in README-MSYS2.md
> --
>
> Key: THRIFT-4158
> URL: https://issues.apache.org/jira/browse/THRIFT-4158
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.11.0
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> In README-MSYS2.md there are recommended cmake build flags:
> {code}
> cmake -G"MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=/mingw64/bin/mingw32-make \
>-DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc.exe \
>-DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-g++.exe \
>-DWITH_BOOSTTHREADS=ON -DWITH_LIBEVENT=OFF \
>-DWITH_SHARED_LIB=OFF -DWITH_STATIC_LIB=ON \
>-DWITH_JAVA=OFF -DWITH_PYTHON=OFF -DWITH_PERL=OFF \
> {code}
> However I think they are not really correct, or am I overlooking something?
> The options WITH_JAVA, WITH_PYTHON and WITH_PERL should be
> BUILD_JAVA, BUILD_PYTHON and BUILD_PERL, respectively. At least
> I could not find the WITH_XXX variants in CMakeLists.txt.
> The options CMAKE_MAKE_PROGRAM, CMAKE_C_COMPILER and
> CMAKE_CXX_COMPILER should be optional and not required. I think
> they are rather confusing since these compilers should be the default for
> a MINGW build shell.
> Finally, the readme recommends to install
> {code}
> $ pacman -S bison flex openssl openssl-devel \
> mingw-w64-x86_64-boost mingw-w64-x86_64-cmake \
> mingw-w64-x86_64-toolchain zlib zlib-devel
> {code}
> The openssl and zlib variants used here are from MSYS2, not MinGW64.
> If there is no strong reason to use those, I think its recommended to use
> the MinGW46 variants instead:
> {code}
> $ pacman -S bison flex mingw-w64-x86_64-openssl \
> mingw-w64-x86_64-boost mingw-w64-x86_64-cmake \
> mingw-w64-x86_64-toolchain mingw-w64-x86_64-zlib
> {code}
> My suggested options "build for me" so they come with at least a bit
> of testing...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] thrift issue #1252: [Ruby] Logging server-side exception message on Applicat...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1252
  
This looks okay to me, but I don't have any ruby experience; hopefully 
someone else who does can review it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[James E. King, III (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972558#comment-15972558
 ] 

James E. King, III commented on THRIFT-2221:


I think it would be better to use something like this as a new header similar 
to cxxfunctional:
{noformat}
#pragma once

#include 

#if defined(BOOST_NO_CXX11_SMART_PTR) || defined(FORCE_BOOST_SMART_PTR)
#include 
#else
#include 
#endif

namespace apache
{
namespace thrift
{
namespace cxx
{
#if defined(BOOST_NO_CXX11_SMART_PTR) || defined(FORCE_BOOST_SMART_PTR)
using ::boost::shared_ptr;
#else
using ::std::shared_ptr;
#endif
}
}
}
{noformat}

Then in implementations one would change boost::shared_ptr to cxx::shared_ptr, 
which would be an alias to the correct type.  Note that the library still 
requires other boost components.  It also allows the user to force use of boost 
smart pointer for backwards compatibility.

> 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: Task
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Priority: Minor
>  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] [Created] (THRIFT-4176) Implement a threaded and threadpool server type for Rust

[Allen George (JIRA)]

Allen George created THRIFT-4176:


 Summary: Implement a threaded and threadpool server type for Rust
 Key: THRIFT-4176
 URL: https://issues.apache.org/jira/browse/THRIFT-4176
 Project: Thrift
  Issue Type: Improvement
  Components: Rust - Library
Reporter: Allen George
Assignee: Allen George


Currently the Rust client library only provides a single-threaded server. Add 
both a multi-threaded server and a threadpool-based server and add the relevant 
options to the cross-test code as well.



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

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972322#comment-15972322
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

Maybe its possible to have both options available with the help of defines? 
I.e. one could use a dedicated header with something like
{code}
#if USE_BOOST_SHARED_PTR
#include 
#define shared_ptr_namespace boost
#else
#include 
#define shared_ptr_namespace std
#endif
{code}

And in the code change:
{code}
-boost::shared_ptr socket(new TSocket("127.0.0.1", port));
+shared_ptr_namespace::shared_ptr socket(new TSocket("127.0.0.1", 
port));
{code}

Admittedly, this does not read as fluent as the current code does, but I think 
it would
encapsulate the boost namespace quite nicely, and allow users to switch. 
Personally
I use std::shared_ptr everywhere in my code, and nowadays many users have a 
c++11
compiler?


> 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: Task
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Priority: Minor
>  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)

[GitHub] thrift issue #1247: MSYS-appveyor-install.bat: use mingw-w64-xxx variants

[emmenlau]

Github user emmenlau commented on the issue:

https://github.com/apache/thrift/pull/1247
  
Should be working now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---