Re: Deprecation of C++03 support - thoughts?

[Chet Murthy]

I ought to have noted that googletest works well with googlemock, and
*that* is one *lovely* C++ mock library.  Holey moley, so lovely.

Re: Deprecation of C++03 support - thoughts?

[Chet Murthy]

On Wed, Dec 27, 2017 at 6:31 PM, James E. King, III 
wrote:

> On Wed, Dec 27, 2017 at 6:06 PM, Roger Meier 
> wrote:
>
> > I would be happy to port tests from boost-test to googletest
>
>  Not certain I see a benefit there.  Replacing one third party library for
> another...


[Not saying this should convince you, but this is how I debug basically all
low-probability concurrency-related bugs -- don't bother understanding it,
just add log-lines and run gazillions of test-replays.]

Two advantages:

(1) at least with boost-test 1.58.0, it seems like even running individual
tests doesn't work.

But the real winner is (2) googletest supports out-of-the-box
"gtest-parallel", which is a way to run googletest tests that are suitably
non-self-interfering in parallel, many copies, many times, keeping track of
which ones fail.  The way I found the bug in  THRIFT-3877 was *not* to go
understand the code, but instead to iteratively

(a) add log-lines with glog

(b) rerun with gtest-parallel

As I added log-lines, the probability of the bug occurring dropped (b/c it
always does ;-) (but also b/c the log-lines "stretched-out" some of the
executions enough for packets to make it across the "network" (== "lo0
network" ;-)  But I just upped the gtest-parallel "# times to run test" to
ensure that I hadn't scared the bug away.

I didn't actually understand what was going wrong, until I had it pretty
much nailed in a log of the incident in excruciating detail.

gtest-parallel + logs FTW!

--chet--

Re: Deprecation of C++03 support - thoughts?

[James E. King, III]

On Wed, Dec 27, 2017 at 6:06 PM, Roger Meier 
wrote:

> +1 for C++11 on master and for upcoming releases
>
>
> Quoting Chet Murthy :
>
> I would be happy to port tests from boost-test to googletest -- and in the
>> process, we could arrange for running tests in parallel, e.g. the
>> cross-test.  I've found that googetest is much more . helpful for
>> debugging.  I'd also vote for (in the C++ code) putting in glog support,
>> for similar reasons.
>>
>

 Not certain I see a benefit there.  Replacing one third party library for
another...


>> On Fri, Dec 22, 2017 at 6:41 PM, Ben Craig  wrote:
>>
>> The main source of work on the Thrift side will be porting the tests.
>>> Many
>>> of them are based on boost test right now.
>>>
>>> Do we have to abandon boost entirely, or just the runtime?


> I'm generally fine with the idea, just be aware that this is a breaking
>>> change, though the break will often be easily dealt with by users
>>> (replacing std with boost).
>>>
>>> It's actually this work that is complicating things in some places,
especially where
detection of a C++11 compiler is in question.  If we continue to support
C++03 then
we should make a proper detector of C++11 (like Boost.Config has).


> If you want to be super nice to our users, you could provide a #define to
>>> switch between boost:: and std::.
>>>
>>> We currently do that with the stdcxx namespace.


> On Fri, Dec 22, 2017 at 3:14 PM, James E. King, III 
>>> wrote:
>>>
>>> > A pull request was submitted recently that is a work in progress to
>>> move
>>> > away from Boost.  This is something the team has expressed a desire for
>>> in
>>> > the past (although as a maintainer of two boost libraries it makes me
>>> sad!)
>>> > as will will reduce project dependencies.
>>> >
>>> > https://github.com/apache/thrift/pull/1448
>>> >
>>> > This work would be GREATLY simplified if we came to a decision to name
>>> > 0.11.0 as the last version that will support C++03, and the next
>>> release
>>> > will require C++11 and would not use boost in generated or library
>>> code.
>>> > I'm not sure I would be okay with such a decision, but I'm floating the
>>> > idea out there for general comment from anyone and everyone.
>>> >
>>> > This would probably force people up to gcc-4.8 or gcc-4.9 at a minimum
>>> on
>>> > Unix, not sure which version of clang (maybe 3.4?), and I believe we
>>> might
>>> > need to require Visual Studio 2013 or later, depending on how much
>>> C++11
>>> we
>>> > use it could go up to 2015.
>>> >
>>> > Libraries in Boost could be quite useful in the future, for example
>>> > boost::asio and boost::beast.  If we disconnect from boost completely
>>> then
>>> > we would not have access to these.  I suppose we could make them
>>> optional
>>> > servers or transports that would need to be enabled at build time, and
>>> if
>>> > enabled at build time would require boost, so perhaps I'm just being
>>> > paranoid there.
>>> >
>>> > Thanks,
>>> >
>>> > Jim
>>> >
>>>
>>>
>
>

Re: Deprecation of C++03 support - thoughts?

[Roger Meier]

+1 for C++11 on master and for upcoming releases

Quoting Chet Murthy :


I would be happy to port tests from boost-test to googletest -- and in the
process, we could arrange for running tests in parallel, e.g. the
cross-test.  I've found that googetest is much more . helpful for
debugging.  I'd also vote for (in the C++ code) putting in glog support,
for similar reasons.

On Fri, Dec 22, 2017 at 6:41 PM, Ben Craig  wrote:


The main source of work on the Thrift side will be porting the tests.  Many
of them are based on boost test right now.

I'm generally fine with the idea, just be aware that this is a breaking
change, though the break will often be easily dealt with by users
(replacing std with boost).

If you want to be super nice to our users, you could provide a #define to
switch between boost:: and std::.

On Fri, Dec 22, 2017 at 3:14 PM, James E. King, III 
wrote:

> A pull request was submitted recently that is a work in progress to move
> away from Boost.  This is something the team has expressed a desire for
in
> the past (although as a maintainer of two boost libraries it makes me
sad!)
> as will will reduce project dependencies.
>
> https://github.com/apache/thrift/pull/1448
>
> This work would be GREATLY simplified if we came to a decision to name
> 0.11.0 as the last version that will support C++03, and the next release
> will require C++11 and would not use boost in generated or library code.
> I'm not sure I would be okay with such a decision, but I'm floating the
> idea out there for general comment from anyone and everyone.
>
> This would probably force people up to gcc-4.8 or gcc-4.9 at a minimum on
> Unix, not sure which version of clang (maybe 3.4?), and I believe we
might
> need to require Visual Studio 2013 or later, depending on how much C++11
we
> use it could go up to 2015.
>
> Libraries in Boost could be quite useful in the future, for example
> boost::asio and boost::beast.  If we disconnect from boost completely
then
> we would not have access to these.  I suppose we could make them optional
> servers or transports that would need to be enabled at build time, and if
> enabled at build time would require boost, so perhaps I'm just being
> paranoid there.
>
> Thanks,
>
> Jim
>

[jira] [Commented] (THRIFT-4413) Publish a Maven artifact for Thrift v0.11

[Wang Xin (JIRA)]

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

Wang Xin commented on THRIFT-4413:
--

Looking forward to seeing version 0.11.0 in maven central as soon as possible

> Publish a Maven artifact for Thrift v0.11
> -
>
> Key: THRIFT-4413
> URL: https://issues.apache.org/jira/browse/THRIFT-4413
> Project: Thrift
>  Issue Type: Task
>  Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Buğra Gedik
>Assignee: Jake Farrell
> Fix For: 0.11.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (THRIFT-4435) When will the java libthrift 0.11.0 be published to central.maven.org/maven2

[James E. King, III (JIRA)]

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

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

Assignee: Jake Farrell  (was: James E. King, III)

> When will the java libthrift 0.11.0 be published to central.maven.org/maven2
> 
>
> Key: THRIFT-4435
> URL: https://issues.apache.org/jira/browse/THRIFT-4435
> Project: Thrift
>  Issue Type: Task
>  Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Wang Xin
>Assignee: Jake Farrell
> Fix For: 0.11.0
>
> Attachments: 111222.png
>
>
> Now I want to use the java dependency libthrift  version 0.11.0,but can't 
> found in central.maven.org/maven2
> http://thrift.apache.org/download page tell me it is published .
> {code:java}
> 
>   org.apache.thrift
>   libthrift
>   0.11.0
> 
> {code}
> When can i get it ???



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (THRIFT-4435) When will the java libthrift 0.11.0 be published to central.maven.org/maven2

[James E. King, III (JIRA)]

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

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

Assignee: James E. King, III

> When will the java libthrift 0.11.0 be published to central.maven.org/maven2
> 
>
> Key: THRIFT-4435
> URL: https://issues.apache.org/jira/browse/THRIFT-4435
> Project: Thrift
>  Issue Type: Task
>  Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Wang Xin
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: 111222.png
>
>
> Now I want to use the java dependency libthrift  version 0.11.0,but can't 
> found in central.maven.org/maven2
> http://thrift.apache.org/download page tell me it is published .
> {code:java}
> 
>   org.apache.thrift
>   libthrift
>   0.11.0
> 
> {code}
> When can i get it ???



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (THRIFT-4435) When will the java libthrift 0.11.0 be published to central.maven.org/maven2

[James E. King, III (JIRA)]

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

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

> When will the java libthrift 0.11.0 be published to central.maven.org/maven2
> 
>
> Key: THRIFT-4435
> URL: https://issues.apache.org/jira/browse/THRIFT-4435
> Project: Thrift
>  Issue Type: Task
>  Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Wang Xin
>Assignee: Jake Farrell
> Fix For: 0.11.0
>
> Attachments: 111222.png
>
>
> Now I want to use the java dependency libthrift  version 0.11.0,but can't 
> found in central.maven.org/maven2
> http://thrift.apache.org/download page tell me it is published .
> {code:java}
> 
>   org.apache.thrift
>   libthrift
>   0.11.0
> 
> {code}
> When can i get it ???



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4435) When will the java libthrift 0.11.0 be published to central.maven.org/maven2

[Wang Xin (JIRA)]

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

Wang Xin updated THRIFT-4435:
-
Description: 
Now I want to use the java dependency libthrift  version 0.11.0,but can't found 
in central.maven.org/maven2
http://thrift.apache.org/download page tell me it is published .

{code:java}

  org.apache.thrift
  libthrift
  0.11.0

{code}

When can i get it ???

  was:
Now I want to use the java dependency libthrift  version 0.11.0,but can't found 
in central.maven.org/maven2
http://thrift.apache.org/download page tell me it is released .

{code:java}

  org.apache.thrift
  libthrift
  0.11.0

{code}

When can i get it ???

Summary: When will the java libthrift 0.11.0 be published to 
central.maven.org/maven2  (was: When will the java libthrift 0.11.0 be released 
to central.maven.org/maven2)

> When will the java libthrift 0.11.0 be published to central.maven.org/maven2
> 
>
> Key: THRIFT-4435
> URL: https://issues.apache.org/jira/browse/THRIFT-4435
> Project: Thrift
>  Issue Type: Task
>  Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Wang Xin
> Fix For: 0.11.0
>
> Attachments: 111222.png
>
>
> Now I want to use the java dependency libthrift  version 0.11.0,but can't 
> found in central.maven.org/maven2
> http://thrift.apache.org/download page tell me it is published .
> {code:java}
> 
>   org.apache.thrift
>   libthrift
>   0.11.0
> 
> {code}
> When can i get it ???



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] thrift issue #1442: 0.11.0

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1442
  
@jfarrell please close this.


---

[jira] [Commented] (THRIFT-4415) Publish a PyPI artifact for Thrift Python v0.11

[James E. King, III (JIRA)]

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

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


This was closed as a duplicate.  See the duplicate for current status.

> Publish a PyPI artifact for Thrift Python v0.11
> ---
>
> Key: THRIFT-4415
> URL: https://issues.apache.org/jira/browse/THRIFT-4415
> Project: Thrift
>  Issue Type: Bug
>Reporter: Buğra Gedik
> Fix For: 0.11.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4437) JS WebSocket client callbacks invoked twice on parallel requests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4437:


GitHub user bananer opened a pull request:

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

THRIFT-4437: JavaScript WebSocket - fix duplicate callbacks



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

$ git pull https://github.com/bananer/thrift THRIFT-4437

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

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


commit 528b3d90434b8f0217bb5a5922de85483daf5304
Author: Philip Frank 
Date:   2017-12-27T11:54:28Z

THRIFT-4437: JavaScript WebSocket - fix duplicate callbacks




> JS WebSocket client callbacks invoked twice on parallel requests
> 
>
> Key: THRIFT-4437
> URL: https://issues.apache.org/jira/browse/THRIFT-4437
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Library
>Affects Versions: 0.11.0
>Reporter: Philip Frank
>
> When using a WebSocket Transport and doing two service calls immediately, 
> without waiting for the first to return, e.g. like this:
> {code:javascript}
> const t = new Thrift.TWebSocketTransport('ws://localhost:8338/hello');
>   const p = new Thrift.TJSONProtocol(t);
>   const client = new HelloSvcClient(p);
>   t.open();
>   client.test(function (res) {
>   console.log(1, res);
>   });
>   client.test(function (res) {
>   console.log(2, res);
>   });
> {code}
> The callback to the first invocation is called twice, and the second never, 
> i.e. console shows:
> {code}
> 1 "test result"
> 1 "test result"
> {code}
> instead of the expected
> {code}
> 1 "test result"
> 2 "test result"
> {code}
> I suspect this bug was introduced with the patch for 
> https://issues.apache.org/jira/browse/THRIFT-4131 where for some reason the 
> callback registered twice when set: 
> https://github.com/apache/thrift/pull/1372/files



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] thrift pull request #1450: THRIFT-4437: JavaScript WebSocket - fix duplicate...

[bananer]

GitHub user bananer opened a pull request:

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

THRIFT-4437: JavaScript WebSocket - fix duplicate callbacks



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

$ git pull https://github.com/bananer/thrift THRIFT-4437

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

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


commit 528b3d90434b8f0217bb5a5922de85483daf5304
Author: Philip Frank 
Date:   2017-12-27T11:54:28Z

THRIFT-4437: JavaScript WebSocket - fix duplicate callbacks




---

[jira] [Created] (THRIFT-4437) JS WebSocket client callbacks invoked twice on parallel requests

[Philip Frank (JIRA)]

Philip Frank created THRIFT-4437:


 Summary: JS WebSocket client callbacks invoked twice on parallel 
requests
 Key: THRIFT-4437
 URL: https://issues.apache.org/jira/browse/THRIFT-4437
 Project: Thrift
  Issue Type: Bug
  Components: JavaScript - Library
Affects Versions: 0.11.0
Reporter: Philip Frank


When using a WebSocket Transport and doing two service calls immediately, 
without waiting for the first to return, e.g. like this:

{code:javascript}
const t = new Thrift.TWebSocketTransport('ws://localhost:8338/hello');
const p = new Thrift.TJSONProtocol(t);
const client = new HelloSvcClient(p);

t.open();

client.test(function (res) {
console.log(1, res);
});
client.test(function (res) {
console.log(2, res);
});
{code}

The callback to the first invocation is called twice, and the second never, 
i.e. console shows:

{code}
1 "test result"
1 "test result"
{code}

instead of the expected

{code}
1 "test result"
2 "test result"
{code}

I suspect this bug was introduced with the patch for 
https://issues.apache.org/jira/browse/THRIFT-4131 where for some reason the 
callback registered twice when set: 
https://github.com/apache/thrift/pull/1372/files



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4435) When will the java libthrift 0.11.0 be released to central.maven.org/maven2

[Wang Xin (JIRA)]

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

Wang Xin updated THRIFT-4435:
-
Description: 
Now I want to use the java dependency libthrift  version 0.11.0,but can't found 
in central.maven.org/maven2
http://thrift.apache.org/download page tell me it is released .

{code:java}

  org.apache.thrift
  libthrift
  0.11.0

{code}

When can i get it ???

  was:
Now I want to use the java dependency libthrift  version 0.11.0,but ant found 
in central.maven.org/maven2
http://thrift.apache.org/download page tell me it is released .

{code:java}

  org.apache.thrift
  libthrift
  0.11.0

{code}

When can i get it ???


> When will the java libthrift 0.11.0 be released to central.maven.org/maven2
> ---
>
> Key: THRIFT-4435
> URL: https://issues.apache.org/jira/browse/THRIFT-4435
> Project: Thrift
>  Issue Type: Task
>  Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Wang Xin
> Fix For: 0.11.0
>
> Attachments: 111222.png
>
>
> Now I want to use the java dependency libthrift  version 0.11.0,but can't 
> found in central.maven.org/maven2
> http://thrift.apache.org/download page tell me it is released .
> {code:java}
> 
>   org.apache.thrift
>   libthrift
>   0.11.0
> 
> {code}
> When can i get it ???



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4436) Deserialization of nested list discards content

[Philip Frank (JIRA)]

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

Philip Frank updated THRIFT-4436:
-
Affects Version/s: 0.10.0

> Deserialization of nested list discards content
> ---
>
> Key: THRIFT-4436
> URL: https://issues.apache.org/jira/browse/THRIFT-4436
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Philip Frank
>
> I'm trying to transmit a list of lists, like this:
> {code}
> service HelloSvc {
>   list test()
> }
> {code}
> Using XHR Transport and JSON Protocol, with a service implementation in 
> Python like this:
> {code}
> class HelloSvcHandler:
> def __init__(self):
> pass
> def test(self,):
> return [
> ["s1", "s2"],
> ["s3", "s4"],
> ["s5"]
> ]
> {code}
> The serialized response looks good to me (seen in browser development tools):
> {code}
> [1,"test",2,0,{"0":{"lst":["lst",3,["str",2,"s1","s2"],["str",2,"s3","s4"],["str",1,"s5"]]}}]
> {code}
> However, when deserialized to JavaScript, the result looks like this:
> {code}
> [["s1","s2"],[],[]]
> {code}
> I would expect it to look like this:
> {code}
> [["s1","s2"],["s3","s4"],["s5"]]
> {code}
> It looks to me like during JSON deserialization, all but the first entry in 
> the list of lists lose their content.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (THRIFT-4436) Deserialization of nested list discards content

[Philip Frank (JIRA)]

Philip Frank created THRIFT-4436:


 Summary: Deserialization of nested list discards content
 Key: THRIFT-4436
 URL: https://issues.apache.org/jira/browse/THRIFT-4436
 Project: Thrift
  Issue Type: Bug
  Components: JavaScript - Library
Affects Versions: 0.11.0
Reporter: Philip Frank


I'm trying to transmit a list of lists, like this:

{code}
service HelloSvc {
  list test()
}
{code}

Using XHR Transport and JSON Protocol, with a service implementation in Python 
like this:

{code}
class HelloSvcHandler:
def __init__(self):
pass

def test(self,):
return [
["s1", "s2"],
["s3", "s4"],
["s5"]
]
{code}

The serialized response looks good to me (seen in browser development tools):

{code}
[1,"test",2,0,{"0":{"lst":["lst",3,["str",2,"s1","s2"],["str",2,"s3","s4"],["str",1,"s5"]]}}]
{code}

However, when deserialized to JavaScript, the result looks like this:

{code}
[["s1","s2"],[],[]]
{code}

I would expect it to look like this:

{code}
[["s1","s2"],["s3","s4"],["s5"]]
{code}

It looks to me like during JSON deserialization, all but the first entry in the 
list of lists lose their content.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)