[jira] [Commented] (THRIFT-4243) Go TSimpleServer race on wait in Stop() method

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4243:


Github user dcelasun commented on the issue:

https://github.com/apache/thrift/pull/1523
  
Thanks for the PR. Seems like this was 
[introduced](https://github.com/apache/thrift/blame/930428438c0b6c8f60560cbb7dcad79042badacb/lib/go/thrift/simple_server.go#L131)
 by THRIFT-4243 (PR #1302) and unfortunately made its way into the 0.11 release.


> Go TSimpleServer race on wait in Stop() method
> --
>
> Key: THRIFT-4243
> URL: https://issues.apache.org/jira/browse/THRIFT-4243
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Reporter: Zach Wasserman
>Assignee: Zach Wasserman
>Priority: Major
> Fix For: 0.11.0
>
>
> Synchronization issues with the use of {{sync.WaitGroup}} in the 
> {{TSimpleServer}} implementation set off the race detector. Note the docs 
> (https://godoc.org/sync#WaitGroup.Add) specify "calls with a positive delta 
> that occur when the counter is zero must happen before a Wait".
> The following unit test demonstrates the issue:
> {code}
> package thrift
> import (
>   "testing"
>   "time"
> )
> type mockProcessor struct {
>   ProcessFunc func(in, out TProtocol) (bool, TException)
> }
> func (m *mockProcessor) Process(in, out TProtocol) (bool, TException) {
>   return m.ProcessFunc(in, out)
> }
> type mockServerTransport struct {
>   ListenFuncfunc() error
>   AcceptFuncfunc() (TTransport, error)
>   CloseFunc func() error
>   InterruptFunc func() error
> }
> func (m *mockServerTransport) Listen() error {
>   return m.ListenFunc()
> }
> func (m *mockServerTransport) Accept() (TTransport, error) {
>   return m.AcceptFunc()
> }
> func (m *mockServerTransport) Close() error {
>   return m.CloseFunc()
> }
> func (m *mockServerTransport) Interrupt() error {
>   return m.InterruptFunc()
> }
> type mockTTransport struct {
>   TTransport
> }
> func (m *mockTTransport) Close() error {
>   return nil
> }
> func TestWaitRace(t *testing.T) {
>   proc := {
>   ProcessFunc: func(in, out TProtocol) (bool, TException) {
>   return false, nil
>   },
>   }
>   trans := {
>   ListenFunc: func() error {
>   return nil
>   },
>   AcceptFunc: func() (TTransport, error) {
>   return {}, nil
>   },
>   CloseFunc: func() error {
>   return nil
>   },
>   InterruptFunc: func() error {
>   return nil
>   },
>   }
>   serv := NewTSimpleServer2(proc, trans)
>   go serv.Serve()
>   time.Sleep(1)
>   serv.Stop()
> }
> {code}
> When run with the race detector, this test produces the following output:
> {code}
> go test -race -v -run TestWaitRace -count 1
> === RUN   TestWaitRace
> ==
> WARNING: DATA RACE
> Write at 0x00c4200849f4 by goroutine 6:
>   internal/race.Write()
>   /usr/local/Cellar/go/1.8/libexec/src/internal/race/race.go:41 +0x38
>   sync.(*WaitGroup).Wait()
>   /usr/local/Cellar/go/1.8/libexec/src/sync/waitgroup.go:129 +0x14b
>   git.apache.org/thrift.git/lib/go/thrift.(*TSimpleServer).Stop.func1()
>   
> /Users/zwass/dev/go/src/git.apache.org/thrift.git/lib/go/thrift/simple_server.go:164
>  +0x9b
>   sync.(*Once).Do()
>   /usr/local/Cellar/go/1.8/libexec/src/sync/once.go:44 +0xe1
>   git.apache.org/thrift.git/lib/go/thrift.(*TSimpleServer).Stop()
>   
> /Users/zwass/dev/go/src/git.apache.org/thrift.git/lib/go/thrift/simple_server.go:166
>  +0x8c
>   git.apache.org/thrift.git/lib/go/thrift.TestWaitRace()
>   
> /Users/zwass/dev/go/src/git.apache.org/thrift.git/lib/go/thrift/simple_server_test.go:134
>  +0x1be
>   testing.tRunner()
>   /usr/local/Cellar/go/1.8/libexec/src/testing/testing.go:657 +0x107
> Previous read at 0x00c4200849f4 by goroutine 7:
>   internal/race.Read()
>   /usr/local/Cellar/go/1.8/libexec/src/internal/race/race.go:37 +0x38
>   sync.(*WaitGroup).Add()
>   /usr/local/Cellar/go/1.8/libexec/src/sync/waitgroup.go:71 +0x26b
>   git.apache.org/thrift.git/lib/go/thrift.(*TSimpleServer).AcceptLoop()
>   
> /Users/zwass/dev/go/src/git.apache.org/thrift.git/lib/go/thrift/simple_server.go:139
>  +0xa6
>   git.apache.org/thrift.git/lib/go/thrift.(*TSimpleServer).Serve()
>   
> /Users/zwass/dev/go/src/git.apache.org/thrift.git/lib/go/thrift/simple_server.go:154
>  +0x86
> Goroutine 6 (running) created at:
>   testing.(*T).Run()
>   /usr/local/Cellar/go/1.8/libexec/src/testing/testing.go:697 +0x543
>   

[GitHub] thrift issue #1523: Fix condition where TSimpleServer could exit AcceptLoop(...

[dcelasun]

Github user dcelasun commented on the issue:

https://github.com/apache/thrift/pull/1523
  
Thanks for the PR. Seems like this was 
[introduced](https://github.com/apache/thrift/blame/930428438c0b6c8f60560cbb7dcad79042badacb/lib/go/thrift/simple_server.go#L131)
 by THRIFT-4243 (PR #1302) and unfortunately made its way into the 0.11 release.


---

[jira] [Commented] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Chao Sun (JIRA)]

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

Chao Sun commented on THRIFT-4536:
--

Good to hear! yes I was planning to but is waiting to see if there's any 
progress on the [Rust discussion|https://github.com/rust-lang/rust/pull/49305] 
- they were talking about removing this from the prelude to avoid the breakage.

> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift pull request #1523: Fix condition where TSimpleServer could exit Acce...

[mdubbyap]

GitHub user mdubbyap opened a pull request:

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

 Fix condition where TSimpleServer could exit AcceptLoop() without 
releasing lock.

…easing lock

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

$ git pull https://github.com/signalfx/thrift THRIFT-4537

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

https://github.com/apache/thrift/pull/1523.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 #1523


commit 7d646414ff8570e8d38492176c45c2111b028a4a
Author: Matthew Pound 
Date:   2018-03-29T21:03:50Z

Fix condition where TSimpleServer could exit AcceptLoop() without releasing 
lock




---

[jira] [Commented] (THRIFT-4537) TSimpleServer can exit Accept loop with lock still acquired

[Matthew W Pound (JIRA)]

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

Matthew W Pound commented on THRIFT-4537:
-

The most likely case is the Accept loop exits on error on Accept() and then you 
try to run Stop() which will hang.

> TSimpleServer can exit Accept loop with lock still acquired
> ---
>
> Key: THRIFT-4537
> URL: https://issues.apache.org/jira/browse/THRIFT-4537
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.11.0
>Reporter: Matthew W Pound
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4537) TSimpleServer can exit Accept loop with lock still acquired

[Matthew W Pound (JIRA)]

Matthew W Pound created THRIFT-4537:
---

 Summary: TSimpleServer can exit Accept loop with lock still 
acquired
 Key: THRIFT-4537
 URL: https://issues.apache.org/jira/browse/THRIFT-4537
 Project: Thrift
  Issue Type: Bug
  Components: Go - Library
Affects Versions: 0.11.0
Reporter: Matthew W Pound






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Allen George (JIRA)]

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

Allen George commented on THRIFT-4536:
--

At some point I'd like to bump the minimum rust version to take advantage of 
{{impl Trait}} and any {{async/await}} stabilizations, but I don't think this 
is the time :) Agree that the try_from crate should be fixed. I see that you've 
already filed an [issue](https://github.com/derekjw/try_from/issues/7) [~csun]?

> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Allen George (JIRA)]

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

Allen George edited comment on THRIFT-4536 at 3/29/18 9:04 PM:
---

At some point I'd like to bump the minimum rust version to take advantage of 
{{impl Trait}} and any {{async/await}} stabilizations, but I don't think this 
is the time :) Agree that the try_from crate should be fixed. I see that you've 
already filed an [issue|https://github.com/derekjw/try_from/issues/7] [~csun]?


was (Author: allengeorge):
At some point I'd like to bump the minimum rust version to take advantage of 
{{impl Trait}} and any {{async/await}} stabilizations, but I don't think this 
is the time :) Agree that the try_from crate should be fixed. I see that you've 
already filed an [issue](https://github.com/derekjw/try_from/issues/7) [~csun]?

> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-4527) Upgrade byteorder version in Rust lib

[Allen George (JIRA)]

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

Allen George resolved THRIFT-4527.
--
Resolution: Fixed

> Upgrade byteorder version in Rust lib
> -
>
> Key: THRIFT-4527
> URL: https://issues.apache.org/jira/browse/THRIFT-4527
> Project: Thrift
>  Issue Type: Dependency upgrade
>  Components: Rust - Library
>Affects Versions: 0.11.0
>Reporter: Joshua
>Priority: Major
>
> The Rust library was depending on byteorder v1.1.0, upgraded to v1.2.1 to 
> prevent dependency conflicts in a project I was working on, works fine and 
> would be useful for other users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Chao Sun (JIRA)]

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

Chao Sun commented on THRIFT-4536:
--

{quote}
Would such a change allow compilation on older rustc?
{quote}
Yes if we are targeting stable rustc releases then I guess the only solution to 
make this work with nightly is to fix the `try_from` crate. 

> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[James E. King, III (JIRA)]

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

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


Would such a change allow compilation on older rustc?

> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Chao Sun (JIRA)]

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

Chao Sun commented on THRIFT-4536:
--

Oops  - just realized this is an issue for `try_from` crate. I'll file an issue 
in that repo but still wondering whether we can remove this dependency...

> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Chao Sun (JIRA)]

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

Chao Sun commented on THRIFT-4536:
--

Yes seems related to this PR: https://github.com/rust-lang/rust/pull/49305
As a quick fix, maybe we should add qualifiers to the call like suggested in 
the error message? not sure we should consider removing the dependency 
`try_from` since this feature is stabilized.



> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Allen George (JIRA)]

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

Allen George commented on THRIFT-4536:
--

Hmm. I wonder if this is because of the just-stablized TryFrom trait
in the stdlib?


> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Chao Sun (JIRA)]

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

Chao Sun updated THRIFT-4536:
-
Description: 
When trying to build the library with rustc nightly, I got the following error:
{code}
Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.2.40
   Compiling cfg-if v0.1.2
   Compiling integer-encoding v1.0.5
   Compiling byteorder v1.2.1
   Compiling try_from v0.2.2
   Compiling log v0.4.1
error[E0034]: multiple applicable items in scope
  --> 
/Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
   |
46 | match u32::try_from(n)? {
   |   ^ multiple `try_from` found
...
58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
   | -- in this 
macro invocation
   |
note: candidate #1 is defined in the trait `TryFrom`
  --> 
/Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
   |
11 | fn try_from(T) -> Result;
   | ^^
   = help: to disambiguate the method call, write `TryFrom::try_from(...)` 
instead
note: candidate #2 is defined in the trait `std::convert::TryFrom`
   = help: to disambiguate the method call, write 
`std::convert::TryFrom::try_from(...)` instead

error: aborting due to previous error

For more information about this error, try `rustc --explain E0034`.
error: Could not compile `try_from`.
warning: build failed, waiting for other jobs to finish...
error: build failed
{code}

cc [~allengeorge]

  was:
When trying to build the library, I got the following error:
{code}
Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.2.40
   Compiling cfg-if v0.1.2
   Compiling integer-encoding v1.0.5
   Compiling byteorder v1.2.1
   Compiling try_from v0.2.2
   Compiling log v0.4.1
error[E0034]: multiple applicable items in scope
  --> 
/Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
   |
46 | match u32::try_from(n)? {
   |   ^ multiple `try_from` found
...
58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
   | -- in this 
macro invocation
   |
note: candidate #1 is defined in the trait `TryFrom`
  --> 
/Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
   |
11 | fn try_from(T) -> Result;
   | ^^
   = help: to disambiguate the method call, write `TryFrom::try_from(...)` 
instead
note: candidate #2 is defined in the trait `std::convert::TryFrom`
   = help: to disambiguate the method call, write 
`std::convert::TryFrom::try_from(...)` instead

error: aborting due to previous error

For more information about this error, try `rustc --explain E0034`.
error: Could not compile `try_from`.
warning: build failed, waiting for other jobs to finish...
error: build failed
{code}

cc [~allengeorge]


> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library with rustc nightly, I got the following 
> error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> 

[jira] [Updated] (THRIFT-4536) [Rust] library fails to build with nightly due to try_from error

[Chao Sun (JIRA)]

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

Chao Sun updated THRIFT-4536:
-
Summary: [Rust] library fails to build with nightly due to try_from error  
(was: [Rust] library fails to build due to try_from error)

> [Rust] library fails to build with nightly due to try_from error
> 
>
> Key: THRIFT-4536
> URL: https://issues.apache.org/jira/browse/THRIFT-4536
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Chao Sun
>Priority: Major
>
> When trying to build the library, I got the following error:
> {code}
> Updating registry `https://github.com/rust-lang/crates.io-index`
>Compiling libc v0.2.40
>Compiling cfg-if v0.1.2
>Compiling integer-encoding v1.0.5
>Compiling byteorder v1.2.1
>Compiling try_from v0.2.2
>Compiling log v0.4.1
> error[E0034]: multiple applicable items in scope
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
>|
> 46 | match u32::try_from(n)? {
>|   ^ multiple `try_from` found
> ...
> 58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
>| -- in 
> this macro invocation
>|
> note: candidate #1 is defined in the trait `TryFrom`
>   --> 
> /Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
>|
> 11 | fn try_from(T) -> Result;
>| ^^
>= help: to disambiguate the method call, write `TryFrom::try_from(...)` 
> instead
> note: candidate #2 is defined in the trait `std::convert::TryFrom`
>= help: to disambiguate the method call, write 
> `std::convert::TryFrom::try_from(...)` instead
> error: aborting due to previous error
> For more information about this error, try `rustc --explain E0034`.
> error: Could not compile `try_from`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> {code}
> cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4536) [Rust] library fails to build due to try_from error

[Chao Sun (JIRA)]

Chao Sun created THRIFT-4536:


 Summary: [Rust] library fails to build due to try_from error
 Key: THRIFT-4536
 URL: https://issues.apache.org/jira/browse/THRIFT-4536
 Project: Thrift
  Issue Type: Bug
  Components: Rust - Library
Reporter: Chao Sun


When trying to build the library, I got the following error:
{code}
Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.2.40
   Compiling cfg-if v0.1.2
   Compiling integer-encoding v1.0.5
   Compiling byteorder v1.2.1
   Compiling try_from v0.2.2
   Compiling log v0.4.1
error[E0034]: multiple applicable items in scope
  --> 
/Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/char.rs:46:23
   |
46 | match u32::try_from(n)? {
   |   ^ multiple `try_from` found
...
58 | impl_int_to_char!(i8, i16, i32, i64, isize, u16, u32, u64, usize);
   | -- in this 
macro invocation
   |
note: candidate #1 is defined in the trait `TryFrom`
  --> 
/Users/chao/.cargo/registry/src/github.com-1ecc6299db9ec823/try_from-0.2.2/src/lib.rs:11:5
   |
11 | fn try_from(T) -> Result;
   | ^^
   = help: to disambiguate the method call, write `TryFrom::try_from(...)` 
instead
note: candidate #2 is defined in the trait `std::convert::TryFrom`
   = help: to disambiguate the method call, write 
`std::convert::TryFrom::try_from(...)` instead

error: aborting due to previous error

For more information about this error, try `rustc --explain E0034`.
error: Could not compile `try_from`.
warning: build failed, waiting for other jobs to finish...
error: build failed
{code}

cc [~allengeorge]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (THRIFT-4535) Current state and future of .NET libraries ("csharp" and "netcore")?

[Jens Geyer (JIRA)]

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

Jens Geyer edited comment on THRIFT-4535 at 3/29/18 5:02 PM:
-

{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pull request to merge both into one? Can't be too 
hard, right?

{quote}
Was this a deliberate decision - e.g. to make the "netcore" code the official 
successor of the "csharp" code? 
{quote}

Depends on how you define "deliberate". It was just how it started ...

Let me put it this way: There are already way too many special cases with the 
C# library. The generator code covers a lot of them, which makes it sometimes 
hard to maintain it properly. As you might notice, there are also two different 
lib projects for framework 4.5 and below. They exist for a reason. Of course 
one could go for the smallest common denominator but you may lose some 
important things on that way, just because that denominator does  not suport a 
particular feature.

OTOH two NET libs implies that there is duplicated code, which is also bad in 
terms of maintenance.

So there are pros and cons to both solutions. I have no problems with merging 
them, but we should not sacrifice anything from the feature set(s).






was (Author: jensg):
{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pull request to merge both into one? Can't be too 
hard, right?

{quote}
Was this a deliberate decision - e.g. to make the "netcore" code the official 
successor of the "csharp" code? 
{quote}

Depends on how you define "deliberate". It was just how it started *shrug*

Let me put it this way: There are already way too many special cases with the 
C# library. The generator code covers a lot of them, which makes it sometimes 
hard to maintain it properly. As you might notice, there are also two different 
lib projects for framework 4.5 and below. They exist for a reason. Of course 
one could go for the smallest common denominator but you may lose some 
important things on that way, just because that denominator does  not suport a 
particular feature.

OTOH two NET libs implies that there is duplicated code, which is also bad in 
terms of maintenance.

So there are pros and cons to both solutions. I have no problems with merging 
them, but we should not sacrifice anything from the feature set(s).





> Current state and future of .NET libraries ("csharp" and "netcore")?
> 
>
> Key: THRIFT-4535
> URL: https://issues.apache.org/jira/browse/THRIFT-4535
> Project: Thrift
>  Issue Type: Question
>  Components: C# - Library, netcore - Library
>Reporter: Christian Weiss
>Priority: Major
>
> Hi,
> We are trying to use Thrift in one of our projects but we ran into some very 
> fundamental issues:
>  * The "csharp" project does not target ".NET Standard" and there's only a 
> very old release on nuget.org ( if [https://www.nuget.org/packages/Thrift/] 
> is the official one).
>  * The "netcore" project does target ".NET Standard" but there's no release 
> yet ( https://issues.apache.org/jira/browse/THRIFT-4512 ) and it also has a 
> dependency on ASP.NET Core ( 
> https://issues.apache.org/jira/browse/THRIFT-4534 ) which makes it unusable 
> in non-web projects.
> I'm wondering why there even are 2 separate projects for .NET? It's important 
> to understand that ".NET Core" is not a new programming API - It's just a new 
> platform - very similar to Silverlight, Mono, Windows Phone. This means that 
> it would also be possible to support .NET Core and the new ".NET Standard" 
> (which represents a common set of APIs for all platforms) with the existing 
> "csharp" project. 
> Was this a deliberate decision - e.g. to make the "netcore" code the official 
> successor of the "csharp" code? 
> Would you be interested in merging the code back into one library? I'd be 
> willing to help if you want!
> It would be great to get one proper, up to date and official .NET library 
> soon as there's 

[jira] [Comment Edited] (THRIFT-4535) Current state and future of .NET libraries ("csharp" and "netcore")?

[Jens Geyer (JIRA)]

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

Jens Geyer edited comment on THRIFT-4535 at 3/29/18 5:01 PM:
-

{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pull request to merge both into one? Can't be too 
hard, right?

{quote}
Was this a deliberate decision - e.g. to make the "netcore" code the official 
successor of the "csharp" code? 
{quote}

Depends on how you define "deliberate". It was just how it started *shrug*

Let me put it this way: There are already way too many special cases with the 
C# library. The generator code covers a lot of them, which makes it sometimes 
hard to maintain it properly. As you might notice, there are also two different 
lib projects for framework 4.5 and below. They exist for a reason. Of course 
one could go for the smallest common denominator but you may lose some 
important things on that way, just because that denominator does  not suport a 
particular feature.

OTOH two NET libs implies that there is duplicated code, which is also bad in 
terms of maintenance.

So there are pros and cons to both solutions. I have no problems with merging 
them, but we should not sacrifice anything from the feature set(s).






was (Author: jensg):
{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pull request to merge both into one? Can't be too 
hard, right?

{quote}
Was this a deliberate decision - e.g. to make the "netcore" code the official 
successor of the "csharp" code? 
{quote}

Depends on how you define "deliberate". The point is, that there are already 
way too many special cases with the C# library. The generator code covers a lot 
of them, which makes it sometimes hard to maintain that properly. As you might 
notice, there are also two different lib projects for framework 4.5 and below. 
They exist for a reason. Of course one could go for the smallest common 
denominator but you may lose some important things on that way, just because 
that denominator does  not suport a particular feature.

OTOH two NET libs implies that there is duplicated code, which is also bad in 
terms of maintenance.

So there are pros and cons to both solutions. I have no problems with merging 
them, but we should not sacrifice anything from the feature set(s).





> Current state and future of .NET libraries ("csharp" and "netcore")?
> 
>
> Key: THRIFT-4535
> URL: https://issues.apache.org/jira/browse/THRIFT-4535
> Project: Thrift
>  Issue Type: Question
>  Components: C# - Library, netcore - Library
>Reporter: Christian Weiss
>Priority: Major
>
> Hi,
> We are trying to use Thrift in one of our projects but we ran into some very 
> fundamental issues:
>  * The "csharp" project does not target ".NET Standard" and there's only a 
> very old release on nuget.org ( if [https://www.nuget.org/packages/Thrift/] 
> is the official one).
>  * The "netcore" project does target ".NET Standard" but there's no release 
> yet ( https://issues.apache.org/jira/browse/THRIFT-4512 ) and it also has a 
> dependency on ASP.NET Core ( 
> https://issues.apache.org/jira/browse/THRIFT-4534 ) which makes it unusable 
> in non-web projects.
> I'm wondering why there even are 2 separate projects for .NET? It's important 
> to understand that ".NET Core" is not a new programming API - It's just a new 
> platform - very similar to Silverlight, Mono, Windows Phone. This means that 
> it would also be possible to support .NET Core and the new ".NET Standard" 
> (which represents a common set of APIs for all platforms) with the existing 
> "csharp" project. 
> Was this a deliberate decision - e.g. to make the "netcore" code the official 
> successor of the "csharp" code? 
> Would you be interested in merging the code back into one library? I'd be 
> willing to help if you want!
> It would be great to get one proper, up to date and official .NET library 
> soon as there's already quite a lot of weird forks on 

[jira] [Comment Edited] (THRIFT-4535) Current state and future of .NET libraries ("csharp" and "netcore")?

[Jens Geyer (JIRA)]

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

Jens Geyer edited comment on THRIFT-4535 at 3/29/18 5:00 PM:
-

{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pull request to merge both into one? Can't be too 
hard, right?

{quote}
Was this a deliberate decision - e.g. to make the "netcore" code the official 
successor of the "csharp" code? 
{quote}

Depends on how you define "deliberate". The point is, that there are already 
way too many special cases with the C# library. The generator code covers a lot 
of them, which makes it sometimes hard to maintain that properly. As you might 
notice, there are also two different lib projects for framework 4.5 and below. 
They exist for a reason. Of course one could go for the smallest common 
denominator but you may lose some important things on that way, just because 
that denominator does  not suport a particular feature.

OTOH two NET libs implies that there is duplicated code, which is also bad in 
terms of maintenance.

So there are pros and cons to both solutions. I have no problems with merging 
them, but we should not sacrifice anything from the feature set(s).






was (Author: jensg):
{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pull request to merge both into one? Can'r be too 
hard.


> Current state and future of .NET libraries ("csharp" and "netcore")?
> 
>
> Key: THRIFT-4535
> URL: https://issues.apache.org/jira/browse/THRIFT-4535
> Project: Thrift
>  Issue Type: Question
>  Components: C# - Library, netcore - Library
>Reporter: Christian Weiss
>Priority: Major
>
> Hi,
> We are trying to use Thrift in one of our projects but we ran into some very 
> fundamental issues:
>  * The "csharp" project does not target ".NET Standard" and there's only a 
> very old release on nuget.org ( if [https://www.nuget.org/packages/Thrift/] 
> is the official one).
>  * The "netcore" project does target ".NET Standard" but there's no release 
> yet ( https://issues.apache.org/jira/browse/THRIFT-4512 ) and it also has a 
> dependency on ASP.NET Core ( 
> https://issues.apache.org/jira/browse/THRIFT-4534 ) which makes it unusable 
> in non-web projects.
> I'm wondering why there even are 2 separate projects for .NET? It's important 
> to understand that ".NET Core" is not a new programming API - It's just a new 
> platform - very similar to Silverlight, Mono, Windows Phone. This means that 
> it would also be possible to support .NET Core and the new ".NET Standard" 
> (which represents a common set of APIs for all platforms) with the existing 
> "csharp" project. 
> Was this a deliberate decision - e.g. to make the "netcore" code the official 
> successor of the "csharp" code? 
> Would you be interested in merging the code back into one library? I'd be 
> willing to help if you want!
> It would be great to get one proper, up to date and official .NET library 
> soon as there's already quite a lot of weird forks on NuGet.org: 
> https://www.nuget.org/packages?q=Thrift 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (THRIFT-4535) Current state and future of .NET libraries ("csharp" and "netcore")?

[Jens Geyer (JIRA)]

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

Jens Geyer edited comment on THRIFT-4535 at 3/29/18 4:53 PM:
-

{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pull request to merge both into one? Can'r be too 
hard.



was (Author: jensg):
{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pul request to merge both into one?


> Current state and future of .NET libraries ("csharp" and "netcore")?
> 
>
> Key: THRIFT-4535
> URL: https://issues.apache.org/jira/browse/THRIFT-4535
> Project: Thrift
>  Issue Type: Question
>  Components: C# - Library, netcore - Library
>Reporter: Christian Weiss
>Priority: Major
>
> Hi,
> We are trying to use Thrift in one of our projects but we ran into some very 
> fundamental issues:
>  * The "csharp" project does not target ".NET Standard" and there's only a 
> very old release on nuget.org ( if [https://www.nuget.org/packages/Thrift/] 
> is the official one).
>  * The "netcore" project does target ".NET Standard" but there's no release 
> yet ( https://issues.apache.org/jira/browse/THRIFT-4512 ) and it also has a 
> dependency on ASP.NET Core ( 
> https://issues.apache.org/jira/browse/THRIFT-4534 ) which makes it unusable 
> in non-web projects.
> I'm wondering why there even are 2 separate projects for .NET? It's important 
> to understand that ".NET Core" is not a new programming API - It's just a new 
> platform - very similar to Silverlight, Mono, Windows Phone. This means that 
> it would also be possible to support .NET Core and the new ".NET Standard" 
> (which represents a common set of APIs for all platforms) with the existing 
> "csharp" project. 
> Was this a deliberate decision - e.g. to make the "netcore" code the official 
> successor of the "csharp" code? 
> Would you be interested in merging the code back into one library? I'd be 
> willing to help if you want!
> It would be great to get one proper, up to date and official .NET library 
> soon as there's already quite a lot of weird forks on NuGet.org: 
> https://www.nuget.org/packages?q=Thrift 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4535) Current state and future of .NET libraries ("csharp" and "netcore")?

[Jens Geyer (JIRA)]

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

Jens Geyer commented on THRIFT-4535:


{quote}
I'm wondering why there even are 2 separate projects for .NET? It's important 
to understand that ".NET Core" is not a new programming API - It's just a new 
platform - very similar to Silverlight, Mono, Windows Phone. This means that it 
would also be possible to support .NET Core and the new ".NET Standard" (which 
represents a common set of APIs for all platforms) with the existing "csharp" 
project. 
{quote}

Why don't you just submit a pul request to merge both into one?


> Current state and future of .NET libraries ("csharp" and "netcore")?
> 
>
> Key: THRIFT-4535
> URL: https://issues.apache.org/jira/browse/THRIFT-4535
> Project: Thrift
>  Issue Type: Question
>  Components: C# - Library, netcore - Library
>Reporter: Christian Weiss
>Priority: Major
>
> Hi,
> We are trying to use Thrift in one of our projects but we ran into some very 
> fundamental issues:
>  * The "csharp" project does not target ".NET Standard" and there's only a 
> very old release on nuget.org ( if [https://www.nuget.org/packages/Thrift/] 
> is the official one).
>  * The "netcore" project does target ".NET Standard" but there's no release 
> yet ( https://issues.apache.org/jira/browse/THRIFT-4512 ) and it also has a 
> dependency on ASP.NET Core ( 
> https://issues.apache.org/jira/browse/THRIFT-4534 ) which makes it unusable 
> in non-web projects.
> I'm wondering why there even are 2 separate projects for .NET? It's important 
> to understand that ".NET Core" is not a new programming API - It's just a new 
> platform - very similar to Silverlight, Mono, Windows Phone. This means that 
> it would also be possible to support .NET Core and the new ".NET Standard" 
> (which represents a common set of APIs for all platforms) with the existing 
> "csharp" project. 
> Was this a deliberate decision - e.g. to make the "netcore" code the official 
> successor of the "csharp" code? 
> Would you be interested in merging the code back into one library? I'd be 
> willing to help if you want!
> It would be great to get one proper, up to date and official .NET library 
> soon as there's already quite a lot of weird forks on NuGet.org: 
> https://www.nuget.org/packages?q=Thrift 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-4530) proposal: add nullability annotations to generated Java code

[Can Celasun (JIRA)]

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

Can Celasun resolved THRIFT-4530.
-
   Resolution: Fixed
Fix Version/s: 0.12.0

> proposal: add nullability annotations to generated Java code
> 
>
> Key: THRIFT-4530
> URL: https://issues.apache.org/jira/browse/THRIFT-4530
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Manu Sridharan
>Priority: Major
> Fix For: 0.12.0
>
>
> I'd like to propose (optionally) including {{@Nullable}} annotations in 
> Thrift-generated Java code.  I'm the main author of NullAway 
> ([https://github.com/uber/NullAway)] and we'd like to better support users 
> who are using Thrift.  The change would involve changing the Java code 
> generator to include {{@Nullable}} annotations on every field, method return 
> value, and method parameter in the public API of generated code that may be 
> null.  With these annotations, NullAway users will get warnings when their 
> client code is missing appropriate null checks.  Also, IDEs like IntelliJ 
> will give better warnings about missing null checks.  As part of this change, 
> I would also add support to NullAway for understanding {{isSetX()}} methods 
> to avoid excessive false positives.
> Regarding which {{@Nullable}} annotation to use, Thrift seems to try to 
> minimize third-party dependencies, but we could simply include a new Thrift 
> {{@Nullable}} annotation, and it will work fine with NullAway and most other 
> tools.
> I have a WIP patch to generate these annotations, but I wanted to get 
> feedback from the maintainers before opening a PR.  We could of course make 
> the annotation generation optional and default it to being off, if desired.  
> Anyway, thoughts / feedback welcome.  Thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4530) proposal: add nullability annotations to generated Java code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4530:


Github user asfgit closed the pull request at:

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


> proposal: add nullability annotations to generated Java code
> 
>
> Key: THRIFT-4530
> URL: https://issues.apache.org/jira/browse/THRIFT-4530
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Manu Sridharan
>Priority: Major
>
> I'd like to propose (optionally) including {{@Nullable}} annotations in 
> Thrift-generated Java code.  I'm the main author of NullAway 
> ([https://github.com/uber/NullAway)] and we'd like to better support users 
> who are using Thrift.  The change would involve changing the Java code 
> generator to include {{@Nullable}} annotations on every field, method return 
> value, and method parameter in the public API of generated code that may be 
> null.  With these annotations, NullAway users will get warnings when their 
> client code is missing appropriate null checks.  Also, IDEs like IntelliJ 
> will give better warnings about missing null checks.  As part of this change, 
> I would also add support to NullAway for understanding {{isSetX()}} methods 
> to avoid excessive false positives.
> Regarding which {{@Nullable}} annotation to use, Thrift seems to try to 
> minimize third-party dependencies, but we could simply include a new Thrift 
> {{@Nullable}} annotation, and it will work fine with NullAway and most other 
> tools.
> I have a WIP patch to generate these annotations, but I wanted to get 
> feedback from the maintainers before opening a PR.  We could of course make 
> the annotation generation optional and default it to being off, if desired.  
> Anyway, thoughts / feedback welcome.  Thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift pull request #1522: THRIFT-4530: add @Nullable annotations to generat...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (THRIFT-4530) proposal: add nullability annotations to generated Java code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4530:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1522
  
That is an intermittent test failure that I thought I resolved.  :)  it is 
C++ only


> proposal: add nullability annotations to generated Java code
> 
>
> Key: THRIFT-4530
> URL: https://issues.apache.org/jira/browse/THRIFT-4530
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Manu Sridharan
>Priority: Major
>
> I'd like to propose (optionally) including {{@Nullable}} annotations in 
> Thrift-generated Java code.  I'm the main author of NullAway 
> ([https://github.com/uber/NullAway)] and we'd like to better support users 
> who are using Thrift.  The change would involve changing the Java code 
> generator to include {{@Nullable}} annotations on every field, method return 
> value, and method parameter in the public API of generated code that may be 
> null.  With these annotations, NullAway users will get warnings when their 
> client code is missing appropriate null checks.  Also, IDEs like IntelliJ 
> will give better warnings about missing null checks.  As part of this change, 
> I would also add support to NullAway for understanding {{isSetX()}} methods 
> to avoid excessive false positives.
> Regarding which {{@Nullable}} annotation to use, Thrift seems to try to 
> minimize third-party dependencies, but we could simply include a new Thrift 
> {{@Nullable}} annotation, and it will work fine with NullAway and most other 
> tools.
> I have a WIP patch to generate these annotations, but I wanted to get 
> feedback from the maintainers before opening a PR.  We could of course make 
> the annotation generation optional and default it to being off, if desired.  
> Anyway, thoughts / feedback welcome.  Thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #1522: THRIFT-4530: add @Nullable annotations to generated Java...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1522
  
That is an intermittent test failure that I thought I resolved.  :)  it is 
C++ only


---