date:20180330

GitHub user zengqinglong opened a pull request:

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

Merge pull request #1 from apache/master

update 2018/3/31

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

$ git pull https://github.com/zengqinglong/thrift master

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

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


commit 3c6186da2f2ce4f9a6598d23b7c87f7c6bd4f46c
Author: zengqinglong 
Date:   2018-03-27T17:56:01Z

Merge pull request #1 from apache/master

update 2018/3/28




---

[GitHub] thrift issue #1526: Merge pull request #1 from apache/master

2018-03-30 Thread allengeorge

Github user allengeorge commented on the issue:

https://github.com/apache/thrift/pull/1526
  
Did you mean to make this PR? If so, why?


---

[GitHub] thrift pull request #1526: Merge pull request #1 from apache/master

Github user zengqinglong closed the pull request at:

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


---

[GitHub] thrift issue #1526: Merge pull request #1 from apache/master

Github user zengqinglong commented on the issue:

https://github.com/apache/thrift/pull/1526
  
2018/3/31


---

[GitHub] thrift issue #1526: Merge pull request #1 from apache/master

Github user zengqinglong commented on the issue:

https://github.com/apache/thrift/pull/1526
  
2018/3/31


---

[GitHub] thrift pull request #1526: Merge pull request #1 from apache/master

GitHub user zengqinglong opened a pull request:

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

Merge pull request #1 from apache/master

update 2018/3/31

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

$ git pull https://github.com/zengqinglong/thrift master

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

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


commit 3c6186da2f2ce4f9a6598d23b7c87f7c6bd4f46c
Author: zengqinglong 
Date:   2018-03-27T17:56:01Z

Merge pull request #1 from apache/master

update 2018/3/28




---

[GitHub] thrift pull request #1525: Merge pull request #1 from apache/master

Github user zengqinglong closed the pull request at:

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


---

[GitHub] thrift issue #1525: Merge pull request #1 from apache/master

Github user zengqinglong commented on the issue:

https://github.com/apache/thrift/pull/1525
  
2018/3/31


---

[GitHub] thrift pull request #1525: Merge pull request #1 from apache/master

GitHub user zengqinglong opened a pull request:

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

Merge pull request #1 from apache/master

update 2018/3/28

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

$ git pull https://github.com/zengqinglong/thrift master

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

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


commit 3c6186da2f2ce4f9a6598d23b7c87f7c6bd4f46c
Author: zengqinglong 
Date:   2018-03-27T17:56:01Z

Merge pull request #1 from apache/master

update 2018/3/28




---

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

2018-03-30 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-4535:


GitHub user cwe1ss opened a pull request:

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

THRIFT-4535: XML docs; code cleanup (tabs->spaces; String->string)

As discussed in 
[THRIFT-4535](https://issues.apache.org/jira/browse/THRIFT-4535) we'd like to 
go back to just one .NET library that supports .NET framework (including Mono) 
AND .NET Core. 

As I had to learn about the library before doing some actual changes, I 
updated the files to contain proper XML comments (which can be used for 
IntelliSense) and I did some code cleanup. I did NOT change any code.

Feel free to close this PR, if you prefer to not have such a cleanup commit 
(for the sake of better git file history).

/cc @Jens-G @jeking3 

PS: I'll submit actual code changes once this PR is merged or rejected.

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

$ git pull https://github.com/cwe1ss/thrift cweiss/csharp

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

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


commit 3ea256cd578e729759dfcd59698133f0cecc6729
Author: Christian Weiss 
Date:   2018-03-30T19:26:04Z

THRIFT-4535: XML docs; code cleanup (tabs->spaces; String->string)




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

[GitHub] thrift pull request #1524: THRIFT-4535: XML docs; code cleanup (tabs->spaces...

2018-03-30 Thread cwe1ss

GitHub user cwe1ss opened a pull request:

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

THRIFT-4535: XML docs; code cleanup (tabs->spaces; String->string)

As discussed in 
[THRIFT-4535](https://issues.apache.org/jira/browse/THRIFT-4535) we'd like to 
go back to just one .NET library that supports .NET framework (including Mono) 
AND .NET Core. 

As I had to learn about the library before doing some actual changes, I 
updated the files to contain proper XML comments (which can be used for 
IntelliSense) and I did some code cleanup. I did NOT change any code.

Feel free to close this PR, if you prefer to not have such a cleanup commit 
(for the sake of better git file history).

/cc @Jens-G @jeking3 

PS: I'll submit actual code changes once this PR is merged or rejected.

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

$ git pull https://github.com/cwe1ss/thrift cweiss/csharp

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

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


commit 3ea256cd578e729759dfcd59698133f0cecc6729
Author: Christian Weiss 
Date:   2018-03-30T19:26:04Z

THRIFT-4535: XML docs; code cleanup (tabs->spaces; String->string)




---

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

2018-03-30 Thread James E. King, III (JIRA)


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

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


These all sound good to me.

> 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")?


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

Christian Weiss commented on THRIFT-4535:
-

Thanks again for the quick response!

I've had a closer look at the code in the meantime and I identified the 
following main differences. I've not been comparing method implementations 
though, so I don't know if "netcore" e.g. fixes some implementation details.
 * "netcore" reorganizes files and namespaces - e.g.
 ** Thrift.Protocol -> Thrift.Protocols; a new Thrift.Protocols.Entities
 ** Thrift.Transport is split into Client & Server
 ** *Proposed solution:*
 *** DO keep the old structure and namespaces. While the "new" structure might 
be nice, there's no real benefit and it breaks everyone.
 * "netcore" uses different code styling - e.g.
 ** Some methods have been renamed from camelCase to PascalCase
 ** Some interfaces have an "I" prefix.
 ** Parameters, variables have been renamed (to not contain abbreviations)
 ** *Proposed solution:*
 *** DO rename methods from camelCase to PascalCase. This is a breaking change, 
but having camelCase for methods is completely untypical for C#.
 *** DO NOT append "I" prefix to interfaces. This would break too much (e.g. 
TBase, ...)
 *** DO rename variables and parameter names to not contain abbreviations. This 
does not break anything and helps for readability.
 * "netcore" has dropped a few transports and added others - e.g.
 ** Transports that depend on "System.Web" (as that's not available in .NET 
Core) and the Silverlight transport
 ** New transport that depends on "Microsoft.AspNetCore"
 ** *Proposed solution:*
 *** DO keep the old transports but only make them available on supported 
platforms (via #if cases).
 *** DO drop the Silverlight transport. Silverlight is dead. If someone really 
complains about this, we can try to add it again.
 *** DO NOT add the new ASP.NET Core based server to the main assembly. The 
main Thrift library should not depend on a specific web framework. Instead, the 
server should be delivered as a separate package - e.g. 
Thrift.Server.AspNetCore. 
 * "netcore" makes heavy usage of async/await.
 ** While this makes sense in some places, I was surprised to see async/await 
being used that much in "Protocol". As each "await" generates an internal state 
machine, I would think that doing this for pretty much every character must be 
much slower than the current code in "csharp". Am I wrong here and has this 
been proven faster?
 ** *Proposed solution:*
 *** DO carefully migrate async/await by doing some benchmarks and only apply 
it where it is useful.
 * "netcore" targets .NET Standard 2.0
 ** This does is too new and doesn't support older but popular versions of some 
platforms.
 ** *Proposed solution:*
 *** Convert "csharp" to new project format and target at least 
"net45;netstandard1.6;netstandard2.0". This gives us platform support for .NET 
4.5+, .NET Core 1.0+, Mono 4.6+, Xamarin and UWP. 

Given that I now know more about the code base, let me address your comments.
{quote}In fact, that's a nobrainer decision. The csharp part was there long 
before netcore (and it was the origin of it), so netcore should be the victim 
and be merged over to csharp.
{quote}
I agree. There's no need for unnecessary breaking changes (e.g. namespace 
changes etc).
{quote}And please, try to not scare people with whatever "modernize" means 
exactly, and have an eye on compatibility. Nobody wants to rewrite the whole 
application just because of an RPC library update.
{quote}
I thought that "netcore" would have more feature differences but as it does 
not, the main challenge is the usage of async/await. We should discuss any 
changes here as this definitely has an impact on users. However, we can also 
keep the synchronous versions at some places to let the user choose which one 
he wants to use.
{quote}There is no "predecessor" or "successor", they are both equally valid 
and alive.
{quote}
Even after having looked at the code, I do not really understand that if you've 
never intended to deprecate one. The two code bases are so similar that 
maintaining two versions seems very painful/unnecessary. And given that there 
is no release of "netcore" (at least I haven't seen one) I'd say it's not 
really "alive" yet. :)

Anyway, What do you think about my proposed solutions?

 

> 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

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

2018-03-30 Thread James E. King, III (JIRA)


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

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


I would agree that netcore came into play because dotnet was new and I'm not 
entirely sure it was all compatible with older projects as they rolled out the 
technical previews, and IIRC the build process for dotnet preview was quite 
different than it is now.  Sounds like we're aligned; let's get everything 
building inside "csharp" and carry whatever good functionality over from 
netcore we can, but attempt to leave the interfaces in csharp alone if at all 
possible to avoid clients needing massive rewrites.  Anything you can 
contribute in this space will be greatly appreciated.  I know we need to get a 
handle on the nuget distributions.  We could also work on releasing older nuget 
packages for older releases, possibly, but I would prefer to focus on getting 
an official 0.12.0 out there based on the work discussed here.

The linux CI build will use mono to build the csharp environment today and will 
use dotnet build to build the netcore environment.  What we could do as part of 
a merge here is to have the ubuntu-xenial (LTS 16.04) build environment use 
only mono, and have the ubuntu-artful (which will become ubuntu-bionic when LTS 
is released and I have time to support it) environment use dotnet-sdk to build 
it, and that would give us coverage.

The windows CI build does not currently build either the "csharp" or the 
"netcore" projects, sadly.

> 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-3773) Swift Library

2018-03-30 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on THRIFT-3773:


Github user yurikoles commented on the issue:

https://github.com/apache/thrift/pull/1084
  
Hi @apocolipse,
Please consider taking into account usage of reserved keywords in *.thrift 
files. For example back end developers may use field with name `description` in 
their structures. And this same keyword then redefined in generated extension 
file. This causes compile errors.


> Swift Library
> -
>
> Key: THRIFT-3773
> URL: https://issues.apache.org/jira/browse/THRIFT-3773
> Project: Thrift
>  Issue Type: New Feature
>  Components: Swift - Library
>Reporter: Thomas Bartelmess
>Assignee: Chris Simpson
>Priority: Major
>
> We already have the option to generate Swift code in the Cocoa compiler, 
> however large parts of the (Objective-C) Cocoa Library still depend on Cocoa 
> and  Objective-C.
> It would be good to have a native Swift library that doesn't depend on the 
> Cocoa libraries.
> Design goals:
> - Fully compatible with the code that is currently generated by the Cocoa 
> compiler (both Objective-C and Swift).
> - Ability to run on Linux
> - Pure Swift, no Objective-C code.
> - No dependencies on closed source apple libraries
> - Keep the same interface, so that the library is compatible with the code 
> the current cocoa compiler generates
> - Better server support that the current Objective-C library.
> - Follow the new Swift packaging format to be compatible with the Swift 
> Package manager



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

[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library

2018-03-30 Thread yurikoles

Github user yurikoles commented on the issue:

https://github.com/apache/thrift/pull/1084
  
Hi @apocolipse,
Please consider taking into account usage of reserved keywords in *.thrift 
files. For example back end developers may use field with name `description` in 
their structures. And this same keyword then redefined in generated extension 
file. This causes compile errors.


---

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

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

Jens Geyer edited comment on THRIFT-4535 at 3/30/18 2:50 PM:
-

{code}
Folks stuck needing to support older frameworks like .NET 3.5.1 can continue to
use Thrift 0.11.0 or earlier. We shouldn't be scared to drop older language
support because folks can continue to use older Thrift to make it work. One
can use Thrift 0.7.0 client with a Thrift 0.11.0 server, for example, if it
were truly necessary to support some ancient language level. So if you are
using an older CentOS with an older mono, you might need to use an older
thrift. That's reasonable.
{code}

I wasn't saying that. I was not saying that we should never drop support for
older versions, quite the opposite. What i I was saying is, that we should be
careful with that decision. There are people out there who are using
interesting combintaions of tools. It's easy to say "I know what the majority
of users is doing" but it may a) simply wrong, and b) even a minority of 5% are
still quite a lot of users. We should absolutlely think about what versions we
plan to support with the next release and e.g. drop Net < 4.5 if that makes
sense. I'm for it, everything less to support can be one special case less. But
I don't want to find myself in a shitstorm because we overlooked something not
being supported on CentOS, and you don't want either, believe me. And yes, I
picked that example very carefully and intentional.

{code}
This is all FOSS, so the notion of being "supported" at all is a best-effort
community driven exercise.
{code}

Correct.

{code}
Should I work on "csharp" and "modernize" it by taking stuff from "netcore"?
{code}

+1 .

In fact, that's a nobrainer decision. The csharp part was there long before
netcore (and it was the origin of it), so netcore should be the victim and be
merged over to csharp. And please, try to not scare people with whatever
"modernize" means exactly, and have an eye on compatibility. Nobody wants to
rewrite the whole application just because of an RPC library update.

{code}
Has this already been tried and failed, resulting in the decision to create the
new, distinct, "netcore" code base?
{code}

Why are you continuing thinking that? Nobody failed here. The first version
came in when netcore was quite new. A lot of things have changed since, e.g.
the project format to name just one. There is no "predecessor" or "successor",
they are both equally valid and alive.

was (Author: jensg):
{code}
Folks stuck needing to support older frameworks like .NET 3.5.1 can continue to
use Thrift 0.11.0 or earlier. We shouldn't be scared to drop older language
support because folks can continue to use older Thrift to make it work. One
can use Thrift 0.7.0 client with a Thrift 0.11.0 server, for example, if it
were truly necessary to support some ancient language level. So if you are
using an older CentOS with an older mono, you might need to use an older
thrift. That's reasonable.
{code}

{code}
This is all FOSS, so the notion of being "supported" at all is a best-effort
community driven exercise.
{code}

Correct.

{code}
Should I work on "csharp" and "modernize" it by taking stuff from "netcore"?
{code}

+1 .

{code}
Has this already been tried and failed, resulting in the decision to create the
new, distinct, "netcore" code base?
{code}

Why are you continuing thinking that? Nobody failed here. The first version
camne in when netcore was quite mnew. A lot of things habve changed since, e.g.
the project format to name just one. There is no predecessor or successor.

> Current

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

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

Jens Geyer edited comment on THRIFT-4535 at 3/30/18 2:49 PM:
-

{code}
This is all FOSS, so the notion of being "supported" at all is a best-effort
community driven exercise.
{code}

Correct.

{code}
Should I work on "csharp" and "modernize" it by taking stuff from "netcore"?
{code}

+1 .

{code}
Has this already been tried and failed, resulting in the decision to create the
new, distinct, "netcore" code base?
{code}

{code}
This is all FOSS, so the notion of being "supported" at all is a best-effort
community driven exercise.
{code}

Correct.

{code}
Should I work on "csharp" and "modernize" it by taking stuff from "netcore"?
Has this already been tried and failed, resulting in the decision to create the
new, distinct, "netcore" code base?
{code}

+1 .

> 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

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


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

Jens Geyer commented on THRIFT-4535:


{code}
Folks stuck needing to support older frameworks like .NET 3.5.1 can continue to 
use Thrift 0.11.0 or earlier.  We shouldn't be scared to drop older language 
support because folks can continue to use older Thrift to make it work.  One 
can use Thrift 0.7.0 client with a Thrift 0.11.0 server, for example, if it 
were truly necessary to support some ancient language level.  So if you are 
using an older CentOS with an older mono, you might need to use an older 
thrift.  That's reasonable.
{code}

I wasn't saying that. I was not saying that we should never drop support for 
older versions, quite the opposite. What i I was saying is, that we should be 
careful with that decision. There are people out there who are using 
interesting combintaions of tools. It's easy to say "I know what the majority 
of users is doing" but it may a) simply wrong, and b) even a minority of 5% are 
still quite a lot of users. We should absolutlely think about what versions we 
plan to support with the next release and e.g. drop Net < 4.5 if that makes 
sense. I'm for it, everything less to support can be one special case less. But 
I don't want to find myself in a shitstorm because we overlooked something not 
being supported on CentOS, and you don't want either, believe me. And yes, I 
picked that example very carefully and intentional.

{code}
This is all FOSS, so the notion of being "supported" at all is a best-effort 
community driven exercise.
{code}

Correct.

{code}
Should I work on "csharp" and "modernize" it by taking stuff from "netcore"? 
Has this already been tried and failed, resulting in the decision to create the 
new, distinct, "netcore" code base?
{code}

+1 .

In fact, that's a nobrainer decision. The csharp part was there long before 
netcore (and it was the origin of it), so netcore should be the victim and be 
merged over to csharp. And please, try to not scare people with whatever 
"modernize" means exactly, and have an eye on compatibility. Nobody wants to 
rewrite the whole application just because of an RPC library update.




> 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")?


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

Christian Weiss commented on THRIFT-4535:
-

Edit: 
{quote}I don't know your user base but supporting .NET 4.5+ and .NET Core seems 
like what most projects are doing right now. 
{quote}
I think I wasn't specific enough here. By supporting a ".NET Standard" version 
we can also support Xamarin, Mono and UWP - see  
[https://docs.microsoft.com/en-us/dotnet/standard/net-standard] for the support 
matrix. People have to be on the mentioned minimum versions of their platform 
though (e.g. Mono 4.6+).

It's also possible to target multiple things - we can e.g. target 
"netstandard20;net45" - which supports everything from the ".NET Standard 2.0" 
column AND ".NET 4.5". (.NET Standard 2.0 would only support .NET 4.6.1)

> 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")?


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

Christian Weiss commented on THRIFT-4535:
-

{quote}As long as we can have a single set of project files that will work both 
for, let's say, Visual Studio 2015 OR for dotnet core 2.0 (msbuild) on linux or 
windows, then okay.  If the project files are incompatible, they should 
probably remain separate.
{quote}
With the new project format, it's possible to do everything in one project 
file. See e.g. 
[Newtonsoft.Json|https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/Newtonsoft.Json.csproj]
 which supports pretty much every platform there is. The only requirement for 
this is that developers who want to contribute need Visual Studio 2017 (the 
free version is enough), Visual Studio Code or Visual Studio for Mac.

I don't know your user base but supporting .NET 4.5+ and .NET Core seems like 
what most projects are doing right now. As [~jking3] said, people can always 
stay on an older version if they are still working on Silverlight, Windows 
Phone or .NET 3.5. Given that there's a tag/branch for the last release you 
could also always create a patch-release for the old version if there is a 
critical problem.

I'd be happy to do some work, but you need to agree on what code base should be 
used as the base.
 * Should I work on "csharp" and "modernize" it by taking stuff from "netcore"? 
Has this already been tried and failed, resulting in the decision to create the 
new, distinct, "netcore" code base?
 * Should I work on "netcore" and add missing features from "csharp" (if there 
are any) and make it support more platforms (it currently only supports .NET 
Standard 2.0). Releasing this will result in whatever breaking changes there 
are between these APIs.

> 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")?

2018-03-30 Thread James E. King, III (JIRA)


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

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


Folks stuck needing to support older frameworks like .NET 3.5.1 can continue to 
use Thrift 0.11.0 or earlier.  We shouldn't be scared to drop older language 
support because folks can continue to use older Thrift to make it work.  One 
can use Thrift 0.7.0 client with a Thrift 0.11.0 server, for example, if it 
were truly necessary to support some ancient language level.  So if you are 
using an older CentOS with an older mono, you might need to use an older 
thrift.  That's reasonable.

This is an incredibly complex product and we need to think really hard about 
how far back we support languages and what that means to our ability to improve 
the code for each language.  There was a breaking change between go 1.6 and 1.7 
that we had to do a lot of work to support... however as of February 2018, 
support for go 1.8 was dropped by the golang project.  We should not have to 
support golang 1.8 or earlier, and I instructed folks as such in a PR where 
that came into question.  I'f quite sure anyone using go in production is 
regularly updating based on the golang project's aggressive EoL strategy.  If 
they are not, well, they are asking for trouble.

For csharp I would expect us to be supporting .NET Framework 4.5.2 or later at 
this point, based on Microsoft's support policy.  It looks like we're still 
checking in static visual studio and/or dotnet project files with our code 
today so those have to be updated, even though I would prefer that we generate 
the projects (using cmake) instead, since that is much more flexible, but we 
can't really pull the trigger on that until everything builds in cmake.  As 
long as we can have a single set of project files that will work both for, 
let's say, Visual Studio 2015 OR for dotnet core 2.0 (msbuild) on linux or 
windows, then okay.  If the project files are incompatible, they should 
probably remain separate.

And of course by "supporting" I mean we make a best effort to prove that things 
work with that language level through our CI and cross test infrastructure.  
This is all FOSS, so the notion of being "supported" at all is a best-effort 
community driven exercise.

For folks using mono today, I would highly recommend they start converting to 
dotnet core.

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

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

2018-03-30 Thread jeking3

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1523
  
Thanks for checking, we need to stabilize these CI builds so less effort is 
spent figuring out if a change is at least somewhat ok.


---

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


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

Jens Geyer edited comment on THRIFT-4535 at 3/30/18 11:44 AM:
--

{quote}
We should identify what, if anything, is in the csharp project that should be 
carried forward. 
 It is probably reasonable to use the current netcore as a starting point
{quote}

If we merge, then netcore into csharp, not the other way round. 

{quote}
e.g. to make the "netcore" code the official successor of the "csharp" code?
{quote}

No. Never.



was (Author: jensg):
{quote}
We should identify what, if anything, is in the csharp project that should be 
carried forward. 
{quote}

If we merge, then netcore into csharp, not the other way round. 

{quote}
e.g. to make the "netcore" code the official successor of the "csharp" code?
{quote}

No. Never.


> 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")?


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

Jens Geyer edited comment on THRIFT-4535 at 3/30/18 11:44 AM:
--

{quote}
We should identify what, if anything, is in the csharp project that should be 
carried forward. 
{quote}

If we merge, then netcore into csharp, not the other way round. 

{quote}
e.g. to make the "netcore" code the official successor of the "csharp" code?
{quote}

No. Never.



was (Author: jensg):
{quote}
We should identify what, if anything, is in the csharp project that should be 
carried forward. 
{quote}

If we merge, then netcore into csharp, not the other way round. 

> 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")?


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

Jens Geyer commented on THRIFT-4535:


{quote}
We should identify what, if anything, is in the csharp project that should be 
carried forward. 
{quote}

If we merge, then netcore into csharp, not the other way round. 

> 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")?


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

Jens Geyer commented on THRIFT-4535:


{quote}
This sounds like a good plan! What is your policy on backwards compatibility 
and supported .NET framework/platforms versions? If there were just one code 
base, would you still want to support Silverlight (Official Microsoft support 
will end in 2021) and .NET framework versions older than 4.5 in this new 
release?
{quote}

Good question. Maybe we should have a poll about this, because after the next 
release someone will come and complain if we throw something out, even if we 
announce it clearly six months in advance (and given the current release cycle 
this is an understatement).

Again, I'm 100% for it (to merge netcore back into csharp) , and I would agree 
to dropping support for older frameworks. We just ned to keep Mono in mind and 
distros like CentOS which are not always blessed with the newest stuff. 

TL;DR: If you need any support for the task, let us know.




> 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-4537) TSimpleServer can exit Accept loop with lock still acquired

2018-03-30 Thread Can Celasun (JIRA)


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

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

> 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
> Fix For: 0.12.0
>
>




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

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

2018-03-30 Thread dcelasun

Github user dcelasun commented on the issue:

https://github.com/apache/thrift/pull/1523
  
Travis failures are unrelated flaky tests (my own Travis build is fine).


---

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

2018-03-30 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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