[jira] [Created] (THRIFT-4425) Publish Thrift v0.11 to packagist.org

[Robert Lu (JIRA)]

Robert Lu created THRIFT-4425:
-

 Summary: Publish Thrift v0.11 to packagist.org
 Key: THRIFT-4425
 URL: https://issues.apache.org/jira/browse/THRIFT-4425
 Project: Thrift
  Issue Type: Bug
  Components: PHP - Library
Reporter: Robert Lu
Assignee: Jake Farrell
 Fix For: 0.11.0


Please release 0.11.0 to [https://packagist.org/packages/apache/thrift]



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

[jira] [Commented] (THRIFT-4423) migrate php library to psr-4

[Robert Lu (JIRA)]

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

Robert Lu commented on THRIFT-4423:
---

[~jking3] The directory is too deep to navigate.

Before, `TBufferedTransport.php` is located at `lib/php/lib/Thrift/Transport`, 
which is five level. and `lib/php/lib` has only `Thrift` folder. So, I think 
it's unnecessary.

After, `lib/php/lib/Transport` is four level.
And ClassLoader works.

BTW, if the deep directory is necessary, I can add it back.


> migrate php library to psr-4
> 
>
> Key: THRIFT-4423
> URL: https://issues.apache.org/jira/browse/THRIFT-4423
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.11.0
>Reporter: Robert Lu
>
> The latest autoload standard is [http://www.php-fig.org/psr/psr-4/].
> So, I migrate thrift to PSR-4.



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

[jira] [Resolved] (THRIFT-4422) Add Async implementation via IFuture

[Jens Geyer (JIRA)]

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

Jens Geyer resolved THRIFT-4422.

   Resolution: Fixed
Fix Version/s: 0.12.0

> Add Async implementation via IFuture
> 
>
> Key: THRIFT-4422
> URL: https://issues.apache.org/jira/browse/THRIFT-4422
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
> Fix For: 0.12.0
>
>
> Add optional implementation of an {{IAsync}} interface loosely modeled after 
> the C# implementation. Delphi supports IFuture starting with Delphi XE7, 
> hence it should be an optional feature to be enabled via {{-gen 
> delphi:async}}, again just like C# does.



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

[jira] [Commented] (THRIFT-4422) Add Async implementation via IFuture

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4422:


Github user asfgit closed the pull request at:

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


> Add Async implementation via IFuture
> 
>
> Key: THRIFT-4422
> URL: https://issues.apache.org/jira/browse/THRIFT-4422
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>
> Add optional implementation of an {{IAsync}} interface loosely modeled after 
> the C# implementation. Delphi supports IFuture starting with Delphi XE7, 
> hence it should be an optional feature to be enabled via {{-gen 
> delphi:async}}, again just like C# does.



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

[jira] [Commented] (THRIFT-4423) migrate php library to psr-4

[James E. King, III (JIRA)]

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

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


Was it necessary to move all the files around?

> migrate php library to psr-4
> 
>
> Key: THRIFT-4423
> URL: https://issues.apache.org/jira/browse/THRIFT-4423
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.11.0
>Reporter: Robert Lu
>
> The latest autoload standard is [http://www.php-fig.org/psr/psr-4/].
> So, I migrate thrift to PSR-4.



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

[jira] [Commented] (THRIFT-4422) Add Async implementation via IFuture

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4422:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1444
  
@Jens-G the go issues are likely resolved by #1443.  I'd recommend merging 
that, rebasing your PR, and waiting for another round.


> Add Async implementation via IFuture
> 
>
> Key: THRIFT-4422
> URL: https://issues.apache.org/jira/browse/THRIFT-4422
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>
> Add optional implementation of an {{IAsync}} interface loosely modeled after 
> the C# implementation. Delphi supports IFuture starting with Delphi XE7, 
> hence it should be an optional feature to be enabled via {{-gen 
> delphi:async}}, again just like C# does.



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

[jira] [Comment Edited] (THRIFT-4230) Thrift server connection may hang forever

[Jeremy Egenberger (JIRA)]

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

Jeremy Egenberger edited comment on THRIFT-4230 at 12/13/17 8:18 PM:
-

Does anybody know if this is fixed in a subsequent version of Thrift? I don't 
see anything in the release notes but could it have been fixed inadvertently? 
Priority is "Major" and it does sound like a major issue, but this record 
hasn't been updated in a while and I'm having trouble finding other references 
to it.


was (Author: jegenberger):
Does anybody know if this is fixed in a subsequent version of Thrift? I don't 
see anything in the release notes but could it have been fixed inadvertently? 
Priority is "Major" and it does sound like major issue, but this record hasn't 
been updated in a while and I'm having trouble finding other references to it.

> Thrift server connection may hang forever
> -
>
> Key: THRIFT-4230
> URL: https://issues.apache.org/jira/browse/THRIFT-4230
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
> Environment: OS: RHEL 7.2
>Reporter: Egor Kromberg
>
> After a lot of tests with HBASE Thrift server we found a problem.
> If the connection is dropped on the client side (using route or iptables) it 
> may be still opened on the Thrift server side. Such situation will occur in 
> case of unstable connection.
> After several iterations the Thrift server application will have a lot of 
> opened connections and *will not accept *any new one. The only WA found is to 
> restart the Thrift server.
> I believe Thrift server should have something like socket timeouts and 
> heartbeats.



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

[jira] [Commented] (THRIFT-1507) Maven can't download resource from central when behind a proxy and won't use local repository

[Artem Glotov (JIRA)]

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

Artem Glotov commented on THRIFT-1507:
--

[~ioan] My workaround is to download dependency jar files to the host with 
available Internet connection (your notebook maybe). And manually copy them to 
the target server to folder lib/java/build/lib:
* commons-codec-1.9.jar
* httpclient-4.4.1.jar
* junit-4.4.jar
* mockito-all-1.9.5.jar
* slf4j-api-1.7.12.jar
* commons-logging-1.2.jar
* httpcore-4.4.1.jar
* log4j-1.2.17.jar
* servlet-api-2.5.jar
* slf4j-log4j12-1.7.12.jar

Then you should delete *mvn.init* dependency in build.xml:
{code:xml}{code}
it looks like:
{code:xml}{code}

Enjoy!

> Maven can't download resource from central when behind a proxy and won't use 
> local repository
> -
>
> Key: THRIFT-1507
> URL: https://issues.apache.org/jira/browse/THRIFT-1507
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.8
> Environment: Ubuntu 10.04 LTS, running in a VM in VMWare Player 
> hosted on Windows XP Pro which is behind a proxy server.
>Reporter: Mark Anderson
>Assignee: Jake Farrell
>  Labels: build, maven
>
> When 'make' enters lib/java, the build fails on the mvn.init target with:
> . . .
> [artifact:dependencies] [WARNING] Overriding profile: 
> 'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: 
> pom
> [artifact:dependencies] Downloading: 
> org/slf4j/slf4j-api/1.5.8/slf4j-api-1.5.8.pom from repository central at 
> http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Connection refused
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'org.slf4j:slf4j-api:pom:1.5.8' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Connection refused
> . . .
> This occurs for every dependency in the 'pom' artifact (on some files, the 
> error is "Connection timed out").
> The preceding target, mvn.ant.tasks.download, succeeds (the 
> maven-ant-tasks-2.1.3.jar file is sitting in the tools directory).
> I have added to build.xml:
> proxy.host=proxy1.domain.com
> proxy.port=80
> proxy.user=
> proxy.pass=
> proxy.enabled=true
> and to /etc/maven2/settings.xml:
>  
>   proxy1
>   true
>   http
>   proxy1.domain.com
>   80
>   localhost
> 
> Maven does not seem to be picking up the proxy.  If I manually download all 
> the resources and install them into my local repository (~/.m2/repository) as 
> suggested and re-run make, I still get the errors -- Maven doesn't try to use 
> the local repository.
> If I move the machine out from behind the firewall, everything works fine: 
> Maven downloads all the dependencies and the Java stuff is able to be built.  
> If I then put the machine back behind the firewall and run 'sudo make 
> install', Maven again tries to download the dependencies from central and 
> that, of course, fails.  It doesn't realize that all the dependencies have 
> been downloaded and the Java files have been compiled.



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

[jira] [Commented] (THRIFT-4230) Thrift server connection may hang forever

[Jeremy Egenberger (JIRA)]

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

Jeremy Egenberger commented on THRIFT-4230:
---

Does anybody know if this is fixed in a subsequent version of Thrift? I don't 
see anything in the release notes but could it have been fixed inadvertently? 
Priority is "Major" and it does sound like major issue, but this record hasn't 
been updated in a while and I'm having trouble finding other references to it.

> Thrift server connection may hang forever
> -
>
> Key: THRIFT-4230
> URL: https://issues.apache.org/jira/browse/THRIFT-4230
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
> Environment: OS: RHEL 7.2
>Reporter: Egor Kromberg
>
> After a lot of tests with HBASE Thrift server we found a problem.
> If the connection is dropped on the client side (using route or iptables) it 
> may be still opened on the Thrift server side. Such situation will occur in 
> case of unstable connection.
> After several iterations the Thrift server application will have a lot of 
> opened connections and *will not accept *any new one. The only WA found is to 
> restart the Thrift server.
> I believe Thrift server should have something like socket timeouts and 
> heartbeats.



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

[jira] [Commented] (THRIFT-3467) Go Maps for Thrift Sets Should Have Values of Type struct{}

[Renan DelValle (JIRA)]

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

Renan DelValle commented on THRIFT-3467:


Hi all,
Sorry for raising this from the dead but  just wanted to point out that this 
change first landed in 0.10.0 instead of 0.11.0. 
It took me a while to find out why my bindings broke in so many places when 
upgrading from 0.9.3 to 0.10.0 so it might be a good idea to update the fix 
version in this ticket.

> Go Maps for Thrift Sets Should Have Values of Type struct{} 
> 
>
> Key: THRIFT-3467
> URL: https://issues.apache.org/jira/browse/THRIFT-3467
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Tom Deering
>Assignee: artem antonenko
>  Labels: golang
> Fix For: 0.11.0
>
>
> Sets in Thrift are currently turned into maps with boolean values in Go. 
> Example:
> Thrift
> {code}
> namespace go bug
> service FooService{
>   void bar (1:set foos)
> }
> {code}
> Go
> {code}
> func (p *FooServiceClient) Bar(foos map[string]bool) (err error) 
> {code}
> Boolean map values waste memory. Map values should be of the zero-byte 
> struct{} type.



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

[jira] [Commented] (THRIFT-4408) Some unicode characters can't be parsed with Thrift Java

[Sergey Krutsko (JIRA)]

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

Sergey Krutsko commented on THRIFT-4408:


I didn't notice thrift-0.11.0 release. But, it is reproducible 0.11.0 and 
master.

> Some unicode characters can't be parsed with Thrift Java
> 
>
> Key: THRIFT-4408
> URL: https://issues.apache.org/jira/browse/THRIFT-4408
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.10.0
>Reporter: Sergey Krutsko
> Attachments: thrift_unicode_patch.patch
>
>
> If string field of thrift object contains character 
> ＜ 
> encoded as "\uff1c then parser can't parse such object at all and fails with: 
> {code}
> java.lang.IllegalArgumentException: -228
>   at java.lang.String.(String.java:266)
>   at 
> org.apache.thrift.protocol.TJSONProtocol.readJSONString(TJSONProtocol.java:691)
> {code}
> Here the unit test to reproduce it:
> {code}
> @Test
> public void readUnicode_uff1c() throws Exception {
> String jsonEncodedEntity = "{\"1\":{\"str\":\"\\uff1c\"}}";
> byte[] bytesEntity = jsonEncodedEntity.getBytes();
> TMemoryBuffer memoryBuffer = new TMemoryBuffer(bytesEntity.length);
> memoryBuffer.write(bytesEntity);
> memoryBuffer.close();
> TJSONProtocol protocol = new TJSONProtocol(memoryBuffer);
> protocol.readStructBegin();
> protocol.readFieldBegin();
> assertEquals("＜", protocol.readString());
> }
> {code}



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

Re: [jira] [Commented] (THRIFT-4421) golang tests rely on gomock, which has change behaviour, causing tests to fail

[Chet Murthy]

Uh, I wouldn't ask about it so soon after submitting the PR, but ... since
the build is currently broken, and this *only* fixes that, could somebody
take a look and see if this is ready-to-be committed?

--chet--

[jira] [Updated] (THRIFT-4424) Flush in TWebSocketTransport pushes callbacks twice if transport is open

[Markus Hocke (JIRA)]

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

Markus Hocke updated THRIFT-4424:
-
Description: 
The flush code looks like this (see also comments in this snippet):

{code:javascript}
   flush: function(async, callback) {
  var self = this;
  if (this.isOpen()) {
//Send data and register a callback to invoke the client callback
this.socket.send(this.send_buf);
this.callbacks.push((function() {
  var clientCallback = callback;
  return function(msg) {
self.setRecvBuffer(msg);
clientCallback();
  };
}()));
// Here the callback gets pushed a second time.
if(callback) { // What is the intention of this code section?
  this.callbacks.push((function() {
var clientCallback = callback;
return function(msg) {
  self.setRecvBuffer(msg);
  clientCallback();
};
  }()));
}
  } else {
//Queue the send to go out __onOpen
this.send_pending.push({
  buf: this.send_buf,
  cb: callback
});
  }
}
{code}


We're having trouble with callbacks called twice in our web client 
implementation that assumes that the callback is only called once. This should 
be a default behaviour in my opinion. I'd suggest to remove this if-clause.

  was:
The flush code looks like this (see also comments in this snippet):
{{flush: function(async, callback) {
  var self = this;
  if (this.isOpen()) {
//Send data and register a callback to invoke the client callback
this.socket.send(this.send_buf);
this.callbacks.push((function() {
  var clientCallback = callback;
  return function(msg) {
self.setRecvBuffer(msg);
clientCallback();
  };
}()));
// Here the callback gets pushed a second time.
if(callback) { // What is the intention of this code section?
  this.callbacks.push((function() {
var clientCallback = callback;
return function(msg) {
  self.setRecvBuffer(msg);
  clientCallback();
};
  }()));
}
  } else {
//Queue the send to go out __onOpen
this.send_pending.push({
  buf: this.send_buf,
  cb: callback
});
  }
},}}

We're having trouble with callbacks called twice in our web client 
implementation that assumes that the callback is only called once. This should 
be a default behaviour in my opinion. I'd suggest to remove this if-clause.


> Flush in TWebSocketTransport pushes callbacks twice if transport is open
> 
>
> Key: THRIFT-4424
> URL: https://issues.apache.org/jira/browse/THRIFT-4424
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Library
>Affects Versions: 0.11.0
>Reporter: Markus Hocke
>
> The flush code looks like this (see also comments in this snippet):
> {code:javascript}
>flush: function(async, callback) {
>   var self = this;
>   if (this.isOpen()) {
> //Send data and register a callback to invoke the client callback
> this.socket.send(this.send_buf);
> this.callbacks.push((function() {
>   var clientCallback = callback;
>   return function(msg) {
> self.setRecvBuffer(msg);
> clientCallback();
>   };
> }()));
> // Here the callback gets pushed a second time.
> if(callback) { // What is the intention of this code section?
>   this.callbacks.push((function() {
> var clientCallback = callback;
> return function(msg) {
>   self.setRecvBuffer(msg);
>   clientCallback();
> };
>   }()));
> }
>   } else {
> //Queue the send to go out __onOpen
> this.send_pending.push({
>   buf: this.send_buf,
>   cb: callback
> });
>   }
> }
> {code}
> We're having trouble with callbacks called twice in our web client 
> implementation that assumes that the callback is only called once. This 
> should be a default behaviour in my opinion. I'd suggest to remove this 
> if-clause.



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

[jira] [Created] (THRIFT-4424) Flush in TWebSocketTransport pushes callbacks twice if transport is open

[Markus Hocke (JIRA)]

Markus Hocke created THRIFT-4424:


 Summary: Flush in TWebSocketTransport pushes callbacks twice if 
transport is open
 Key: THRIFT-4424
 URL: https://issues.apache.org/jira/browse/THRIFT-4424
 Project: Thrift
  Issue Type: Bug
  Components: JavaScript - Library
Affects Versions: 0.11.0
Reporter: Markus Hocke


The flush code looks like this (see also comments in this snippet):
{{flush: function(async, callback) {
  var self = this;
  if (this.isOpen()) {
//Send data and register a callback to invoke the client callback
this.socket.send(this.send_buf);
this.callbacks.push((function() {
  var clientCallback = callback;
  return function(msg) {
self.setRecvBuffer(msg);
clientCallback();
  };
}()));
// Here the callback gets pushed a second time.
if(callback) { // What is the intention of this code section?
  this.callbacks.push((function() {
var clientCallback = callback;
return function(msg) {
  self.setRecvBuffer(msg);
  clientCallback();
};
  }()));
}
  } else {
//Queue the send to go out __onOpen
this.send_pending.push({
  buf: this.send_buf,
  cb: callback
});
  }
},}}

We're having trouble with callbacks called twice in our web client 
implementation that assumes that the callback is only called once. This should 
be a default behaviour in my opinion. I'd suggest to remove this if-clause.



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

[jira] [Updated] (THRIFT-4423) migrate php library to psr-4

[Robert Lu (JIRA)]

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

Robert Lu updated THRIFT-4423:
--
External issue URL: https://github.com/apache/thrift/pull/1445

> migrate php library to psr-4
> 
>
> Key: THRIFT-4423
> URL: https://issues.apache.org/jira/browse/THRIFT-4423
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.11.0
>Reporter: Robert Lu
>
> The latest autoload standard is [http://www.php-fig.org/psr/psr-4/].
> So, I migrate thrift to PSR-4.



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

[jira] [Created] (THRIFT-4423) migrate php library to psr-4

[Robert Lu (JIRA)]

Robert Lu created THRIFT-4423:
-

 Summary: migrate php library to psr-4
 Key: THRIFT-4423
 URL: https://issues.apache.org/jira/browse/THRIFT-4423
 Project: Thrift
  Issue Type: Improvement
  Components: PHP - Library
Affects Versions: 0.11.0
Reporter: Robert Lu


The latest autoload standard is [http://www.php-fig.org/psr/psr-4/].

So, I migrate thrift to PSR-4.



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

[GitHub] thrift pull request #1445: migrate to psr-4

[RobberPhex]

GitHub user RobberPhex opened a pull request:

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

migrate to psr-4



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

$ git pull https://github.com/RobberPhex/thrift psr-4

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

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


commit 82a3323d80f6f1fbdf98fee17675d74ff24df219
Author: Robert Lu 
Date:   2017-11-03T04:27:31Z

migrate to psr-4

commit 1b08f39a19c3ffdf8d3a143ae8b7457eb7459031
Author: Robert Lu 
Date:   2017-11-11T01:53:28Z

add phpunit to require-dev

commit d775d602e7067c49057d0a65bbccba4b51f339bf
Author: Robert Lu 
Date:   2017-11-11T01:55:17Z

adjust classloader of test

commit ef1df4b8e0b4c551cf5997ca83d8b5b5db1220e6
Author: Robert Lu 
Date:   2017-11-11T02:26:05Z

fix path

commit 48e5fb54754f023fca4ad712e641b0b2046bb3d7
Author: Robert Lu 
Date:   2017-11-11T08:52:58Z

fix test directory structure

commit ff857fe0f8d3ff5bcc89ac00cf06fa69347535ec
Author: Robert Lu 
Date:   2017-11-12T07:18:37Z

remove sys info

commit c2fff0c1d4c3d2a3e7e687254544ef187bb048ef
Author: Robert Lu 
Date:   2017-11-13T09:40:53Z

fix test classloader

commit 0ceccf67d2d06b19bb654d2ebfd38f5e424d38b4
Author: Robert Lu 
Date:   2017-11-13T10:28:42Z

add composer

commit 8562d4591abb859dfe10e9838d7486d7e55a91eb
Author: Robert Lu 
Date:   2017-12-13T10:28:57Z

fix permission

commit 6e75076c0cb64e1300aeb77c79d93a7238589abb
Author: Robert Lu 
Date:   2017-12-13T10:29:08Z

add autoload-dev

commit 4a8423020da3d9c96e549dda885529c4853d724d
Author: Robert Lu 
Date:   2017-12-13T10:55:23Z

add composer install




---

[GitHub] thrift issue #1440: Enhancement binary_protocol with frametransport

[zhiyu-he]

Github user zhiyu-he commented on the issue:

https://github.com/apache/thrift/pull/1440
  
@jeking3 with go programing, [the function call stack may more 
expensive.](https://github.com/zhiyu-he/go_performance/blob/master/build_in/func_call_test.go)


---

[jira] [Commented] (THRIFT-4422) Add Async implementation via IFuture

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4422:


Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/1444
  
Travis errors seem unrelated. Go library? C++ library? I didn't even touch 
those ...


> Add Async implementation via IFuture
> 
>
> Key: THRIFT-4422
> URL: https://issues.apache.org/jira/browse/THRIFT-4422
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>
> Add optional implementation of an {{IAsync}} interface loosely modeled after 
> the C# implementation. Delphi supports IFuture starting with Delphi XE7, 
> hence it should be an optional feature to be enabled via {{-gen 
> delphi:async}}, again just like C# does.



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

[GitHub] thrift issue #1444: THRIFT-4422 Add Async implementation via IFuture

[Jens-G]

Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/1444
  
Travis errors seem unrelated. Go library? C++ library? I didn't even touch 
those ...


---