[jira] [Commented] (THRIFT-3389) (type int8) as type byte in argument to oprot.WriteByte

2015-10-18 Thread Alex Lobunets (JIRA) 

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

Alex Lobunets commented on THRIFT-3389:
---

[~nsuke] [~jensg] - thank you for clarification. Updating the Go library has 
fixed everything.

> (type int8) as type byte in argument to oprot.WriteByte
> ---
>
> Key: THRIFT-3389
> URL: https://issues.apache.org/jira/browse/THRIFT-3389
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.9.3
> Environment: OS X 10.11 / thrift: stable 0.9.3 (bottled), HEAD
>Reporter: Alex Lobunets
>
> The following structure:
>  struct SomeData {
> 1: byte pos,
>  //...
> }
> leads to the following error when compiling:
> ttypes.go:274: cannot use int8(p.Pos) (type int8) as type byte in argument to 
> oprot.WriteByte



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3003) Missing LICENSE file prevents package from being installed

2015-10-18 Thread Jake Farrell (JIRA) 

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

Jake Farrell commented on THRIFT-3003:
--

published: https://hackage.haskell.org/package/thrift-0.9.3

> Missing LICENSE file prevents package from being installed
> --
>
> Key: THRIFT-3003
> URL: https://issues.apache.org/jira/browse/THRIFT-3003
> Project: Thrift
>  Issue Type: Bug
>  Components: Haskell - Library
>Affects Versions: 0.9.2
>Reporter: Geraud Boyer
>Assignee: Jake Farrell
>Priority: Blocker
> Fix For: 0.9.3
>
>
> When installing the package, the compilation fails because the LICENSE file 
> is missing.
> {code:none}
> $ mkdir thrift
> $ cd thrift
> $ cabal sandbox init
> $ cabal install thrift==0.9.2
> Resolving dependencies...
> Notice: installing into a sandbox located at
> [...]/thrift/.cabal-sandbox
> Configuring thrift-0.9.2...
> Building thrift-0.9.2...
> Failed to install thrift-0.9.2
> Build log ( [...]/thrift/.cabal-sandbox/logs/thrift-0.9.2.log ):
> Configuring thrift-0.9.2...
> Warning: The 'license-file' field refers to the file '../../LICENSE' which
> does not exist.
> Building thrift-0.9.2...
> Preprocessing library thrift-0.9.2...
> [ 1 of 14] Compiling Thrift.Transport.IOBuffer ( 
> src/Thrift/Transport/IOBuffer.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/IOBuffer.o )
> [ 2 of 14] Compiling Thrift.Arbitraries ( src/Thrift/Arbitraries.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Arbitraries.o )
> [ 3 of 14] Compiling Thrift.Types ( src/Thrift/Types.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Types.o )
> [ 4 of 14] Compiling Thrift.Transport ( src/Thrift/Transport.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport.o )
> [ 5 of 14] Compiling Thrift.Protocol  ( src/Thrift/Protocol.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol.o )
> [ 6 of 14] Compiling Thrift.Protocol.Binary ( src/Thrift/Protocol/Binary.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol/Binary.o )
> [ 7 of 14] Compiling Thrift.Protocol.Compact ( 
> src/Thrift/Protocol/Compact.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol/Compact.o )
> src/Thrift/Protocol/Compact.hs:59:15: Warning:
> Literal 130 is out of the Int8 range -128..127
> src/Thrift/Protocol/Compact.hs:62:15: Warning:
> Literal 224 is out of the Int8 range -128..127
> [ 8 of 14] Compiling Thrift.Protocol.JSON ( src/Thrift/Protocol/JSON.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol/JSON.o )
> [ 9 of 14] Compiling Thrift.Transport.Handle ( 
> src/Thrift/Transport/Handle.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/Handle.o )
> [10 of 14] Compiling Thrift.Transport.Empty ( src/Thrift/Transport/Empty.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/Empty.o )
> [11 of 14] Compiling Thrift.Transport.Framed ( 
> src/Thrift/Transport/Framed.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/Framed.o )
> [12 of 14] Compiling Thrift.Transport.HttpClient ( 
> src/Thrift/Transport/HttpClient.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/HttpClient.o )
> [13 of 14] Compiling Thrift   ( src/Thrift.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift.o )
> [14 of 14] Compiling Thrift.Server( src/Thrift/Server.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Server.o )
> In-place registering thrift-0.9.2...
> Creating package registration file:
> /var/folders/w9/qpxdhlxd6xqc7nhhk0lrj_xcgn/T/pkgConf-thrift-0.917566.2
> setup-Simple-Cabal-1.20.0.2-x86_64-osx-ghc-7.8.3: ../../LICENSE: does not
> exist
> cabal: Error: some packages failed to install:
> thrift-0.9.2 failed during the final install step. The exception was:
> ExitFailure 1
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

2015-10-18 Thread JIRA 

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

Antonio García updated THRIFT-3392:
---
Description: 
While setting up a short demo project using the new Java TZlibTransport in 
0.9.3, I wrote code like this:

{code:java}
try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
  Blog blog = new Blog();
  // set up fields in blog
  proto.write(blog);
}
{code}

However, when I went to look at the file, I found it mostly empty (with only 
the header bytes). I had a look at the TZlibTransport code, which seems to be a 
subclass of TIOStreamTransport that wraps its underlying transport using Java 
inflater/deflater streams:

{code:java}
public TZlibTransport(TTransport transport, int compressionLevel) {
  transport_ = transport;
  inputStream_ = new InflaterInputStream(new TTransportInputStream(transport_), 
new Inflater());
  outputStream_ = new DeflaterOutputStream(new 
TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
true);
}
{code}

However, on its close method it only closes the transport and not the 
underlying streams, forcing users to flush the transport before closing if they 
really want to write everything:

{code:java}
public void close() {
  if (transport_.isOpen()) {
  transport_.close();
}
{code}

I think it would be better if we simply relied on the close() method of the 
TIOStreamTransport, which closes the input and output streams if they have been 
created. Additionally, it would be better to create the input stream on the 
first read and the output stream on the first write: otherwise, we will get an 
error during closing if we're only reading (as TIOStreamTransport will still 
try to close the output side, resulting in writes from the deflater).

I have a first version of a fix for these issues: I'll turn it into a pull 
request on Github.

  was:
While setting up a short demo project using the new Java TZlibTransport in 
0.9.3, I wrote code like this:

try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
  Blog blog = new Blog();
  // set up fields in blog
  proto.write(blog);
}

However, when I went to look at the file, I found it mostly empty (with only 
the header bytes). I had a look at the TZlibTransport code, which seems to be a 
subclass of TIOStreamTransport that wraps its underlying transport using Java 
inflater/deflater streams:

 public TZlibTransport(TTransport transport, int compressionLevel) {
 transport_ = transport;
inputStream_ = new InflaterInputStream(new 
TTransportInputStream(transport_), new Inflater());
outputStream_ = new DeflaterOutputStream(new 
TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
true);
 }

However, on its close method it only closes the transport and not the 
underlying streams, forcing users to flush the transport before closing if they 
really want to write everything:

  public void close() {
if (transport_.isOpen()) {
transport_.close();
  }

I think it would be better if we simply relied on the close() method of the 
TIOStreamTransport, which closes the input and output streams if they have been 
created. Additionally, it would be better to create the input stream on the 
first read and the output stream on the first write: otherwise, we will get an 
error during closing if we're only reading (as TIOStreamTransport will still 
try to close the output side, resulting in writes from the deflater).

I have a first version of a fix for these issues: I'll turn it into a pull 
request on Github.


> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> {code:java}
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> {code}
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
> {code:java}
> public TZlibTransport(TTransport transport, int compressionLevel) {
>   transport_ = transport;
>   inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
>   outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
>

[jira] [Commented] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

2015-10-18 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-3392:


GitHub user bluezio opened a pull request:

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

[THRIFT-3392] Java TZlibTransport: ensure inflater/deflater are closed upon 
close()

More information available on the JIRA issue:

https://issues.apache.org/jira/browse/THRIFT-3392

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

$ git pull https://github.com/bluezio/thrift THRIFT-3392

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

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


commit e413701b53a4aa0069b5e5d873847c147308581e
Author: Antonio García-Domínguez 
Date:   2015-10-18T13:16:02Z

[THRIFT-3392] Java TZlibTransport: ensure inflater/deflater are closed upon 
close()




> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
>  public TZlibTransport(TTransport transport, int compressionLevel) {
>  transport_ = transport;
> inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
> outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
> true);
>  }
> However, on its close method it only closes the transport and not the 
> underlying streams, forcing users to flush the transport before closing if 
> they really want to write everything:
>   public void close() {
> if (transport_.isOpen()) {
> transport_.close();
>   }
> I think it would be better if we simply relied on the close() method of the 
> TIOStreamTransport, which closes the input and output streams if they have 
> been created. Additionally, it would be better to create the input stream on 
> the first read and the output stream on the first write: otherwise, we will 
> get an error during closing if we're only reading (as TIOStreamTransport will 
> still try to close the output side, resulting in writes from the deflater).
> I have a first version of a fix for these issues: I'll turn it into a pull 
> request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: [THRIFT-3392] Java TZlibTransport: ensure inf...

2015-10-18 Thread bluezio 
GitHub user bluezio opened a pull request:

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

[THRIFT-3392] Java TZlibTransport: ensure inflater/deflater are closed upon 
close()

More information available on the JIRA issue:

https://issues.apache.org/jira/browse/THRIFT-3392

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

$ git pull https://github.com/bluezio/thrift THRIFT-3392

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

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


commit e413701b53a4aa0069b5e5d873847c147308581e
Author: Antonio García-Domínguez 
Date:   2015-10-18T13:16:02Z

[THRIFT-3392] Java TZlibTransport: ensure inflater/deflater are closed upon 
close()




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

[jira] [Created] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

2015-10-18 Thread JIRA 
Antonio García created THRIFT-3392:
--

 Summary: Java TZlibTransport does not close its wrapper streams 
upon close()
 Key: THRIFT-3392
 URL: https://issues.apache.org/jira/browse/THRIFT-3392
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.9.3
Reporter: Antonio García


While setting up a short demo project using the new Java TZlibTransport in 
0.9.3, I wrote code like this:

try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
  Blog blog = new Blog();
  // set up fields in blog
  proto.write(blog);
}

However, when I went to look at the file, I found it mostly empty (with only 
the header bytes). I had a look at the TZlibTransport code, which seems to be a 
subclass of TIOStreamTransport that wraps its underlying transport using Java 
inflater/deflater streams:

 public TZlibTransport(TTransport transport, int compressionLevel) {
 transport_ = transport;
inputStream_ = new InflaterInputStream(new 
TTransportInputStream(transport_), new Inflater());
outputStream_ = new DeflaterOutputStream(new 
TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
true);
 }

However, on its close method it only closes the transport and not the 
underlying streams, forcing users to flush the transport before closing if they 
really want to write everything:

  public void close() {
if (transport_.isOpen()) {
transport_.close();
  }

I think it would be better if we simply relied on the close() method of the 
TIOStreamTransport, which closes the input and output streams if they have been 
created. Additionally, it would be better to create the input stream on the 
first read and the output stream on the first write: otherwise, we will get an 
error during closing if we're only reading (as TIOStreamTransport will still 
try to close the output side, resulting in writes from the deflater).

I have a first version of a fix for these issues: I'll turn it into a pull 
request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

2015-10-18 Thread Randy Abernethy (JIRA) 

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

Randy Abernethy resolved THRIFT-3392.
-
   Resolution: Fixed
Fix Version/s: 0.9.4

committed, thanks for the issue, patch and especially the test!

I modified the patch to super.close() on close() to preserve the close of the 
underlying transport (which could be a file, socket, named pipe, etc.).

> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> {code:java}
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> {code}
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
> {code:java}
> public TZlibTransport(TTransport transport, int compressionLevel) {
>   transport_ = transport;
>   inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
>   outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
> true);
> }
> {code}
> However, on its close method it only closes the transport and not the 
> underlying streams, forcing users to flush the transport before closing if 
> they really want to write everything:
> {code:java}
> public void close() {
>   if (transport_.isOpen()) {
>   transport_.close();
> }
> {code}
> I think it would be better if we simply relied on the close() method of the 
> TIOStreamTransport, which closes the input and output streams if they have 
> been created. Additionally, it would be better to create the input stream on 
> the first read and the output stream on the first write: otherwise, we will 
> get an error during closing if we're only reading (as TIOStreamTransport will 
> still try to close the output side, resulting in writes from the deflater).
> I have a first version of a fix for these issues: I'll turn it into a pull 
> request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

2015-10-18 Thread Hudson (JIRA) 

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

Hudson commented on THRIFT-3392:


SUCCESS: Integrated in Thrift #1692 (See 
[https://builds.apache.org/job/Thrift/1692/])
THRIFT-3392:ZLib does not flush wrapper streams on close Client: Java (ra: rev 
f593dd3a96dddbcd4063690d20fee98d395bb360)
* lib/java/src/org/apache/thrift/transport/TZlibTransport.java
* lib/java/test/org/apache/thrift/transport/TestTZlibTransport.java


> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> {code:java}
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> {code}
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
> {code:java}
> public TZlibTransport(TTransport transport, int compressionLevel) {
>   transport_ = transport;
>   inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
>   outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
> true);
> }
> {code}
> However, on its close method it only closes the transport and not the 
> underlying streams, forcing users to flush the transport before closing if 
> they really want to write everything:
> {code:java}
> public void close() {
>   if (transport_.isOpen()) {
>   transport_.close();
> }
> {code}
> I think it would be better if we simply relied on the close() method of the 
> TIOStreamTransport, which closes the input and output streams if they have 
> been created. Additionally, it would be better to create the input stream on 
> the first read and the output stream on the first write: otherwise, we will 
> get an error during closing if we're only reading (as TIOStreamTransport will 
> still try to close the output side, resulting in writes from the deflater).
> I have a first version of a fix for these issues: I'll turn it into a pull 
> request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3393) Introduce i8 to provide consistent set of Thrift IDL integer types

2015-10-18 Thread Jens Geyer (JIRA) 
Jens Geyer created THRIFT-3393:
--

 Summary: Introduce i8 to provide consistent set of Thrift IDL 
integer types
 Key: THRIFT-3393
 URL: https://issues.apache.org/jira/browse/THRIFT-3393
 Project: Thrift
  Issue Type: Improvement
  Components: Compiler (General)
Reporter: Jens Geyer
Assignee: Jens Geyer


In following up a recent email discussion and the consistent stream of problems 
with the signedness of the Thrift IDL  {{byte}} datatype, we should 

* add an {{i8}} data type to provide a consistent set
* keep the {{byte}} type for tghe sake of compatibility
* internally map all references to {{byte}} to {{i8}}

This patch is solely about the changes needed in the IDL and the compiler 
infrastructure, changing only what's necessary in the various target languages 
to let {{make check}} succeed. Any additional changes to be made in the 
language libs should be added as a sub-task as necessary. This procedure allows 
us to make the changes in a more granular way while still maintaining a 
shippable product.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

2015-10-18 Thread Randy Abernethy (JIRA) 

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

Randy Abernethy reassigned THRIFT-3392:
---

Assignee: Randy Abernethy

> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>Assignee: Randy Abernethy
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> {code:java}
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> {code}
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
> {code:java}
> public TZlibTransport(TTransport transport, int compressionLevel) {
>   transport_ = transport;
>   inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
>   outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
> true);
> }
> {code}
> However, on its close method it only closes the transport and not the 
> underlying streams, forcing users to flush the transport before closing if 
> they really want to write everything:
> {code:java}
> public void close() {
>   if (transport_.isOpen()) {
>   transport_.close();
> }
> {code}
> I think it would be better if we simply relied on the close() method of the 
> TIOStreamTransport, which closes the input and output streams if they have 
> been created. Additionally, it would be better to create the input stream on 
> the first read and the output stream on the first write: otherwise, we will 
> get an error during closing if we're only reading (as TIOStreamTransport will 
> still try to close the output side, resulting in writes from the deflater).
> I have a first version of a fix for these issues: I'll turn it into a pull 
> request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: [THRIFT-3392] Java TZlibTransport: ensure inf...

2015-10-18 Thread asfgit 
Github user asfgit closed the pull request at:

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


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

[jira] [Commented] (THRIFT-3392) Java TZlibTransport does not close its wrapper streams upon close()

2015-10-18 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-3392:


Github user asfgit closed the pull request at:

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


> Java TZlibTransport does not close its wrapper streams upon close()
> ---
>
> Key: THRIFT-3392
> URL: https://issues.apache.org/jira/browse/THRIFT-3392
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Antonio García
>Assignee: Randy Abernethy
>
> While setting up a short demo project using the new Java TZlibTransport in 
> 0.9.3, I wrote code like this:
> {code:java}
> try (TProtocol proto = new TJSONProtocol(new TZlibTransport(...))) {
>   Blog blog = new Blog();
>   // set up fields in blog
>   proto.write(blog);
> }
> {code}
> However, when I went to look at the file, I found it mostly empty (with only 
> the header bytes). I had a look at the TZlibTransport code, which seems to be 
> a subclass of TIOStreamTransport that wraps its underlying transport using 
> Java inflater/deflater streams:
> {code:java}
> public TZlibTransport(TTransport transport, int compressionLevel) {
>   transport_ = transport;
>   inputStream_ = new InflaterInputStream(new 
> TTransportInputStream(transport_), new Inflater());
>   outputStream_ = new DeflaterOutputStream(new 
> TTransportOutputStream(transport_), new Deflater(compressionLevel, false), 
> true);
> }
> {code}
> However, on its close method it only closes the transport and not the 
> underlying streams, forcing users to flush the transport before closing if 
> they really want to write everything:
> {code:java}
> public void close() {
>   if (transport_.isOpen()) {
>   transport_.close();
> }
> {code}
> I think it would be better if we simply relied on the close() method of the 
> TIOStreamTransport, which closes the input and output streams if they have 
> been created. Additionally, it would be better to create the input stream on 
> the first read and the output stream on the first write: otherwise, we will 
> get an error during closing if we're only reading (as TIOStreamTransport will 
> still try to close the output side, resulting in writes from the deflater).
> I have a first version of a fix for these issues: I'll turn it into a pull 
> request on Github.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3393) Introduce i8 to provide consistent set of Thrift IDL integer types

2015-10-18 Thread Jens Geyer (JIRA) 

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

Jens Geyer updated THRIFT-3393:
---
Description: 
In following up a [recent email 
discussion|https://mail-archives.apache.org/mod_mbox/thrift-dev/201412.mbox/%3cdub110-ds46454ddd3a90974be62d69b1...@phx.gbl%3e]
 and the consistent stream of problems with the [signedness of the Thrift IDL  
{{byte}} datatype|https://thrift.apache.org/docs/types], we should 

* add an {{i8}} data type to provide a consistent set
* keep the {{byte}} type for the sake of compatibility
* internally map all references to {{byte}} to {{i8}}

I'm hesitant though about printing a warning for {{byte}} at this stage. A lot 
of third-party-tools rely on Thrift IDL and I don't want to introduce any 
breaking changes. IMHO we should promote i8 instead of byte wherever possible, 
but not hammer that nail too much.

This patch is solely about the changes needed in the IDL and the compiler 
infrastructure, changing only what's necessary in the various target languages 
to let {{make check}} succeed. Any additional changes to be made in the 
language libs should be added as a sub-task as necessary. This procedure allows 
us to make the changes in a more granular way while still maintaining a 
shippable product.

  was:
In following up a recent email discussion and the consistent stream of problems 
with the signedness of the Thrift IDL  {{byte}} datatype, we should 

* add an {{i8}} data type to provide a consistent set
* keep the {{byte}} type for tghe sake of compatibility
* internally map all references to {{byte}} to {{i8}}

This patch is solely about the changes needed in the IDL and the compiler 
infrastructure, changing only what's necessary in the various target languages 
to let {{make check}} succeed. Any additional changes to be made in the 
language libs should be added as a sub-task as necessary. This procedure allows 
us to make the changes in a more granular way while still maintaining a 
shippable product.


> Introduce i8 to provide consistent set of Thrift IDL integer types
> --
>
> Key: THRIFT-3393
> URL: https://issues.apache.org/jira/browse/THRIFT-3393
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>  Labels: i8
>
> In following up a [recent email 
> discussion|https://mail-archives.apache.org/mod_mbox/thrift-dev/201412.mbox/%3cdub110-ds46454ddd3a90974be62d69b1...@phx.gbl%3e]
>  and the consistent stream of problems with the [signedness of the Thrift IDL 
>  {{byte}} datatype|https://thrift.apache.org/docs/types], we should 
> * add an {{i8}} data type to provide a consistent set
> * keep the {{byte}} type for the sake of compatibility
> * internally map all references to {{byte}} to {{i8}}
> I'm hesitant though about printing a warning for {{byte}} at this stage. A 
> lot of third-party-tools rely on Thrift IDL and I don't want to introduce any 
> breaking changes. IMHO we should promote i8 instead of byte wherever 
> possible, but not hammer that nail too much.
> This patch is solely about the changes needed in the IDL and the compiler 
> infrastructure, changing only what's necessary in the various target 
> languages to let {{make check}} succeed. Any additional changes to be made in 
> the language libs should be added as a sub-task as necessary. This procedure 
> allows us to make the changes in a more granular way while still maintaining 
> a shippable product.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3003) Missing LICENSE file prevents package from being installed

2015-10-18 Thread Yogesh Sajanikar (JIRA) 

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

Yogesh Sajanikar commented on THRIFT-3003:
--

Will 0.9.3 be rolled for haskell sooner? It would be good to fix it. 

This issue is stopping it from moving to newer build systems like stackage. 

> Missing LICENSE file prevents package from being installed
> --
>
> Key: THRIFT-3003
> URL: https://issues.apache.org/jira/browse/THRIFT-3003
> Project: Thrift
>  Issue Type: Bug
>  Components: Haskell - Library
>Affects Versions: 0.9.2
>Reporter: Geraud Boyer
>Assignee: Jake Farrell
>Priority: Blocker
> Fix For: 0.9.3
>
>
> When installing the package, the compilation fails because the LICENSE file 
> is missing.
> {code:none}
> $ mkdir thrift
> $ cd thrift
> $ cabal sandbox init
> $ cabal install thrift==0.9.2
> Resolving dependencies...
> Notice: installing into a sandbox located at
> [...]/thrift/.cabal-sandbox
> Configuring thrift-0.9.2...
> Building thrift-0.9.2...
> Failed to install thrift-0.9.2
> Build log ( [...]/thrift/.cabal-sandbox/logs/thrift-0.9.2.log ):
> Configuring thrift-0.9.2...
> Warning: The 'license-file' field refers to the file '../../LICENSE' which
> does not exist.
> Building thrift-0.9.2...
> Preprocessing library thrift-0.9.2...
> [ 1 of 14] Compiling Thrift.Transport.IOBuffer ( 
> src/Thrift/Transport/IOBuffer.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/IOBuffer.o )
> [ 2 of 14] Compiling Thrift.Arbitraries ( src/Thrift/Arbitraries.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Arbitraries.o )
> [ 3 of 14] Compiling Thrift.Types ( src/Thrift/Types.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Types.o )
> [ 4 of 14] Compiling Thrift.Transport ( src/Thrift/Transport.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport.o )
> [ 5 of 14] Compiling Thrift.Protocol  ( src/Thrift/Protocol.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol.o )
> [ 6 of 14] Compiling Thrift.Protocol.Binary ( src/Thrift/Protocol/Binary.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol/Binary.o )
> [ 7 of 14] Compiling Thrift.Protocol.Compact ( 
> src/Thrift/Protocol/Compact.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol/Compact.o )
> src/Thrift/Protocol/Compact.hs:59:15: Warning:
> Literal 130 is out of the Int8 range -128..127
> src/Thrift/Protocol/Compact.hs:62:15: Warning:
> Literal 224 is out of the Int8 range -128..127
> [ 8 of 14] Compiling Thrift.Protocol.JSON ( src/Thrift/Protocol/JSON.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Protocol/JSON.o )
> [ 9 of 14] Compiling Thrift.Transport.Handle ( 
> src/Thrift/Transport/Handle.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/Handle.o )
> [10 of 14] Compiling Thrift.Transport.Empty ( src/Thrift/Transport/Empty.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/Empty.o )
> [11 of 14] Compiling Thrift.Transport.Framed ( 
> src/Thrift/Transport/Framed.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/Framed.o )
> [12 of 14] Compiling Thrift.Transport.HttpClient ( 
> src/Thrift/Transport/HttpClient.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Transport/HttpClient.o )
> [13 of 14] Compiling Thrift   ( src/Thrift.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift.o )
> [14 of 14] Compiling Thrift.Server( src/Thrift/Server.hs, 
> dist/dist-sandbox-b6b86a31/build/Thrift/Server.o )
> In-place registering thrift-0.9.2...
> Creating package registration file:
> /var/folders/w9/qpxdhlxd6xqc7nhhk0lrj_xcgn/T/pkgConf-thrift-0.917566.2
> setup-Simple-Cabal-1.20.0.2-x86_64-osx-ghc-7.8.3: ../../LICENSE: does not
> exist
> cabal: Error: some packages failed to install:
> thrift-0.9.2 failed during the final install step. The exception was:
> ExitFailure 1
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3393 Introducing i8 to provide consist...

2015-10-18 Thread Jens-G 
GitHub user Jens-G opened a pull request:

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

THRIFT-3393 Introducing i8 to provide consistent set of Thrift integers

THRIFT-3393 Introducing i8 to provide consistent set of Thrift integers
Client: Compiler (general)
Patch: Jens Geyer



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

$ git pull https://github.com/Jens-G/thrift THRIFT-3393

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

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


commit debe89e99a2be191bcc5d70a886bdb12153af293
Author: Jens Geyer 
Date:   2015-10-16T18:21:54Z

THRIFT-3393 Introducing i8 to provide consistent set of Thrift integers
Client: Compiler (general)
Patch: Jens Geyer




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

[jira] [Commented] (THRIFT-3393) Introduce i8 to provide consistent set of Thrift IDL integer types

2015-10-18 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-3393:


GitHub user Jens-G opened a pull request:

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

THRIFT-3393 Introducing i8 to provide consistent set of Thrift integers

THRIFT-3393 Introducing i8 to provide consistent set of Thrift integers
Client: Compiler (general)
Patch: Jens Geyer



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

$ git pull https://github.com/Jens-G/thrift THRIFT-3393

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

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


commit debe89e99a2be191bcc5d70a886bdb12153af293
Author: Jens Geyer 
Date:   2015-10-16T18:21:54Z

THRIFT-3393 Introducing i8 to provide consistent set of Thrift integers
Client: Compiler (general)
Patch: Jens Geyer




> Introduce i8 to provide consistent set of Thrift IDL integer types
> --
>
> Key: THRIFT-3393
> URL: https://issues.apache.org/jira/browse/THRIFT-3393
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>  Labels: i8
>
> In following up a [recent email 
> discussion|https://mail-archives.apache.org/mod_mbox/thrift-dev/201412.mbox/%3cdub110-ds46454ddd3a90974be62d69b1...@phx.gbl%3e]
>  and the consistent stream of problems with the [signedness of the Thrift IDL 
>  {{byte}} datatype|https://thrift.apache.org/docs/types], we should 
> * add an {{i8}} data type to provide a consistent set
> * keep the {{byte}} type for the sake of compatibility
> * internally map all references to {{byte}} to {{i8}}
> I'm hesitant though about printing a warning for {{byte}} at this stage. A 
> lot of third-party-tools rely on Thrift IDL and I don't want to introduce any 
> breaking changes. IMHO we should promote i8 instead of byte wherever 
> possible, but not hammer that nail too much.
> This patch is solely about the changes needed in the IDL and the compiler 
> infrastructure, changing only what's necessary in the various target 
> languages to let {{make check}} succeed. Any additional changes to be made in 
> the language libs should be added as a sub-task as necessary. This procedure 
> allows us to make the changes in a more granular way while still maintaining 
> a shippable product.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)