[jira] [Updated] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-06 Thread Andy Schlaikjer (JIRA) 

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

Andy Schlaikjer updated THRIFT-1328:


Attachment: fix-bytebuffer-access.patch

> TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer 
> range
> ---
>
> Key: THRIFT-1328
> URL: https://issues.apache.org/jira/browse/THRIFT-1328
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.5
> Environment: Java 1.6, Mac OSX 10.6.8 64-bit
>Reporter: Andy Schlaikjer
> Attachments: fix-bytebuffer-access.patch
>
>
> I have a Thrift struct T which declares a binary field f3 after two other 
> fields f1 and f2. After successful deserialization of a T instance, f3 
> references a ByteBuffer which wraps the raw byte[] containing all T instance 
> data and has position and limit set to scope reads to valid f3 bytes. This is 
> great because it means less copying of raw byte[] data.
> However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
> Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
> bytes to sb which lie outside f3's valid range in the backing byte[].
> It seems like this logic is also present in latest version of TBaseHelper: 
> http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-06 Thread Andy Schlaikjer (JIRA) 

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

Andy Schlaikjer updated THRIFT-1328:


Patch Info: [Patch Available]

> TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer 
> range
> ---
>
> Key: THRIFT-1328
> URL: https://issues.apache.org/jira/browse/THRIFT-1328
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.5
> Environment: Java 1.6, Mac OSX 10.6.8 64-bit
>Reporter: Andy Schlaikjer
> Attachments: fix-bytebuffer-access.patch
>
>
> I have a Thrift struct T which declares a binary field f3 after two other 
> fields f1 and f2. After successful deserialization of a T instance, f3 
> references a ByteBuffer which wraps the raw byte[] containing all T instance 
> data and has position and limit set to scope reads to valid f3 bytes. This is 
> great because it means less copying of raw byte[] data.
> However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
> Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
> bytes to sb which lie outside f3's valid range in the backing byte[].
> It seems like this logic is also present in latest version of TBaseHelper: 
> http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1323) TFramedTransport should throw an exception that distinguishes an oversized frame from a dead client, servers should log that exception

2011-09-06 Thread Jim Ancona (JIRA) 

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

Jim Ancona commented on THRIFT-1323:


That's right, this is using Java for both client and server. I think either a 
subclass or a specific TTransportException.type_ would be fine. When I added 
logging to Cassandra in place of the swallowed exception, I saw quite a few 
logged. But I think logging at DEBUG level is appropriate, and I've created an 
issue and patch for Cassandra to do that in its CustomTThreadPoolServer. If you 
can distinguish between frame to large and other TTransportExceptions, I would 
suggest INFO or WARNING for the frame too large case.

> TFramedTransport should throw an exception that distinguishes an oversized 
> frame from a dead client, servers should log that exception
> --
>
> Key: THRIFT-1323
> URL: https://issues.apache.org/jira/browse/THRIFT-1323
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Reporter: Jim Ancona
>
> When TFramedTransport receives a frame that is larger than the maximum frame 
> size, it throws a TTransportException. This makes that error 
> indistinguishable from a failed client. Because such errors are common, many 
> servers (TSimpleServer, TThreadPoolServer, and Cassandra's 
> CustomTThreadPoolServer) swallow TTransportException without a log message, 
> making it difficult to diagnose this problem. I'm not familiar enough with 
> the code base to suggest which exception to throw in its place, although a 
> subclass of TTransportException, or a new TTransportException.type_ value 
> might work. In any case, the corresponding server implementations should log 
> that condition when it occurs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-06 Thread Andy Schlaikjer (JIRA) 
TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range
---

 Key: THRIFT-1328
 URL: https://issues.apache.org/jira/browse/THRIFT-1328
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.5
 Environment: Java 1.6, Mac OSX 10.6.8 64-bit
Reporter: Andy Schlaikjer


I have a Thrift struct T which declares a binary field f3 after two other 
fields f1 and f2. After successful deserialization of a T instance, f3 
references a ByteBuffer which wraps the raw byte[] containing all T instance 
data and has position and limit set to scope reads to valid f3 bytes. This is 
great because it means less copying of raw byte[] data.

However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
bytes to sb which lie outside f3's valid range in the backing byte[].

It seems like this logic is also present in latest version of TBaseHelper: 
http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1327) Fix Spec Suite under Ruby-1.8.7 (works for MRI Ruby-1.9.2)

2011-09-06 Thread Scott Gonyea (JIRA) 

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

Scott Gonyea updated THRIFT-1327:
-

Description: 
The Spec suite is currently exhibiting issues, when run under Ruby 1.8.7. Ruby 
1.8.7 interpreters MRI, JRuby, and Rubinius should all be tested and verified 
as working.

In addition, it would make sense to use something like RVM, on the CI server, 
so we can easily test compatibility across different Ruby versions and 
interpreters.

This does not affect Ruby-1.9.2 MRI, and has not been tested under JRuby's 1.9 
mode.  CI should run JRuby twice, under both the 1.8 and 1.9 
compatibility-modes.


  was:
The Spec suite is currently exhibiting issues, when run under Ruby 1.8.7. Ruby 
1.8.7 interpreters MRI, JRuby, and Rubinius should all be tested and verified 
as working.

In addition, it would make sense to use something like RVM, on the CI server, 
so we can easily test compatibility across different Ruby versions and 
interpreters.

Summary: Fix Spec Suite under Ruby-1.8.7 (works for MRI Ruby-1.9.2)  
(was: Fix Spec suite under Ruby-1.8.7)

> Fix Spec Suite under Ruby-1.8.7 (works for MRI Ruby-1.9.2)
> --
>
> Key: THRIFT-1327
> URL: https://issues.apache.org/jira/browse/THRIFT-1327
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.8
> Environment: Ruby-1.8.7 (MRI/JRuby/Rubinius)
>Reporter: Scott Gonyea
> Fix For: 0.8
>
>
> The Spec suite is currently exhibiting issues, when run under Ruby 1.8.7. 
> Ruby 1.8.7 interpreters MRI, JRuby, and Rubinius should all be tested and 
> verified as working.
> In addition, it would make sense to use something like RVM, on the CI server, 
> so we can easily test compatibility across different Ruby versions and 
> interpreters.
> This does not affect Ruby-1.9.2 MRI, and has not been tested under JRuby's 
> 1.9 mode.  CI should run JRuby twice, under both the 1.8 and 1.9 
> compatibility-modes.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1327) Fix Spec suite under Ruby-1.8.7

2011-09-06 Thread Scott Gonyea (JIRA) 

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

Scott Gonyea updated THRIFT-1327:
-

Summary: Fix Spec suite under Ruby-1.8.7  (was: Fix RSpec suite under 
Ruby-1.8.7)

> Fix Spec suite under Ruby-1.8.7
> ---
>
> Key: THRIFT-1327
> URL: https://issues.apache.org/jira/browse/THRIFT-1327
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.8
> Environment: Ruby-1.8.7 (MRI/JRuby/Rubinius)
>Reporter: Scott Gonyea
> Fix For: 0.8
>
>
> The Spec suite is currently exhibiting issues, when run under Ruby 1.8.7. 
> Ruby 1.8.7 interpreters MRI, JRuby, and Rubinius should all be tested and 
> verified as working.
> In addition, it would make sense to use something like RVM, on the CI server, 
> so we can easily test compatibility across different Ruby versions and 
> interpreters.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1327) Fix RSpec suite under Ruby-1.8.7

2011-09-06 Thread Scott Gonyea (JIRA) 
Fix RSpec suite under Ruby-1.8.7


 Key: THRIFT-1327
 URL: https://issues.apache.org/jira/browse/THRIFT-1327
 Project: Thrift
  Issue Type: Bug
  Components: Ruby - Library
Affects Versions: 0.8
 Environment: Ruby-1.8.7 (MRI/JRuby/Rubinius)
Reporter: Scott Gonyea
 Fix For: 0.8


The Spec suite is currently exhibiting issues, when run under Ruby 1.8.7. Ruby 
1.8.7 interpreters MRI, JRuby, and Rubinius should all be tested and verified 
as working.

In addition, it would make sense to use something like RVM, on the CI server, 
so we can easily test compatibility across different Ruby versions and 
interpreters.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

2011-09-06 Thread Scott Gonyea (JIRA) 

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

Scott Gonyea commented on THRIFT-1312:
--

I probably shouldn't have derailed my feature-issue (what do I call this? I 
want to say pull request, but this isn't Github.)

Does this work for you in Ruby 1.9.2?  Everything has issues in 1.8.7, so maybe 
we should make a separate issue?  I'll be happy to look into it.

> Add MutexableThreadPoolServer and ProcessPoolServer
> ---
>
> Key: THRIFT-1312
> URL: https://issues.apache.org/jira/browse/THRIFT-1312
> Project: Thrift
>  Issue Type: New Feature
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Scott Gonyea
> Fix For: 0.8
>
> Attachments: thrift-1312.patch, thrift-1312.patch, thrift-1312.patch, 
> thrift-1312.patch, thrift-1312.patch
>
>
> Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" 
> and "ProcessPoolServer" to the Thrift Ruby Library.
> The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, 
> as well as an example file that demonstrates its use.
> Below is a lengthy description of how we make use of the MTPServer.  But 
> before getting into that, you can find the code here, or in the included 
> patch.
> https://github.com/sgonyea/thrift/tree/mtps/lib/rb
> This draws very heavily from the ThreadPoolServer, except that it introduces 
> the use of Mutexes as one way to stop the server from spawning threads.  
> Further, it offers a #stop_threads method, that will check the state of each 
> thread and release control once all threads have finished serving requests to 
> clients.
> Internally, this MTPServer is used in conjunction with HAProxy to shut down 
> and start up, cleanly, and to avoid all sorts of crazy race conditions that 
> often arise when serving over a raw socket.
> When the MTPServer is started, it will fill the ThreadPool with N threads.  
> Once done, it is ready to receive requests and will yield to a callback if 
> one is supplied.  In this callback, we call out to HAProxy and signal that we 
> are ready to begin accepting connections from API clients.
> The parent application can be setup to trap any signals, as we do, and to 
> then lock the mutex (to prevent new threads from pooling).  It then calls 
> @server.stop_threads.  It also spins off another thread that will hard shut 
> down the server if Threads continue past an arbitrary amount of time.
> The other benefit in using HAProxy is that it will close connections from 
> clients, if they are idle for some period of time.  This prevents another 
> common issue, where a client remains connected and causes our Thread to 
> block, until the sun explodes.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1324) TFramedTransport should enforce frame size limits on writes

2011-09-06 Thread Bryan Duxbury (JIRA) 

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

Bryan Duxbury updated THRIFT-1324:
--

  Component/s: Java - Library
Fix Version/s: 0.8

This is a really good idea.

> TFramedTransport should enforce frame size limits on writes
> ---
>
> Key: THRIFT-1324
> URL: https://issues.apache.org/jira/browse/THRIFT-1324
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Reporter: Jim Ancona
> Fix For: 0.8
>
>
> Currently TFramedTransport only enforces the maximum frame size when it 
> receives a frame larger than its configured maxLength_ value. so there is no 
> way to enforce a maximum frame size on the client. Because servers typically 
> deal with oversized frames by silently dropping them (see THRIFT-1323), 
> problems caused by oversized frames can be very hard to diagnose. Enforcing 
> the maximum frame size on writes would enable clients to detect the frame 
> size mismatch, assuming the client and server are configured with the same 
> value.
> Note that the exception thrown in this case should not be a generic 
> TTransportException--it should be either a subclass or a new 
> TTransportException.type_ value so that clients can distinguish the frame too 
> large error. This is important because most other TTransportException causes 
> reflect transient conditions where retry may be appropriate, but a too-large 
> frame will never succeed if retried.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1323) TFramedTransport should throw an exception that distinguishes an oversized frame from a dead client, servers should log that exception

2011-09-06 Thread Bryan Duxbury (JIRA) 

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

Bryan Duxbury commented on THRIFT-1323:
---

I think it would be hard to make this any other exception than a 
TTransportException, though we could make a subclass if that would be more 
helpful. As far as just swallowing the exception, I guess that's really up to 
the implementing server. You could make the argument that you should never 
swallow an exception. I would commit a patch that unconditionally logged all 
exceptions, especially if it was at a log level that was easier to silence if 
the messages were too superfluous.

> TFramedTransport should throw an exception that distinguishes an oversized 
> frame from a dead client, servers should log that exception
> --
>
> Key: THRIFT-1323
> URL: https://issues.apache.org/jira/browse/THRIFT-1323
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Reporter: Jim Ancona
>
> When TFramedTransport receives a frame that is larger than the maximum frame 
> size, it throws a TTransportException. This makes that error 
> indistinguishable from a failed client. Because such errors are common, many 
> servers (TSimpleServer, TThreadPoolServer, and Cassandra's 
> CustomTThreadPoolServer) swallow TTransportException without a log message, 
> making it difficult to diagnose this problem. I'm not familiar enough with 
> the code base to suggest which exception to throw in its place, although a 
> subclass of TTransportException, or a new TTransportException.type_ value 
> might work. In any case, the corresponding server implementations should log 
> that condition when it occurs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1323) TFramedTransport should throw an exception that distinguishes an oversized frame from a dead client, servers should log that exception

2011-09-06 Thread Bryan Duxbury (JIRA) 

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

Bryan Duxbury updated THRIFT-1323:
--

Component/s: Java - Library

Since you're talking about Cassandra, I assume this is in the Java library.

> TFramedTransport should throw an exception that distinguishes an oversized 
> frame from a dead client, servers should log that exception
> --
>
> Key: THRIFT-1323
> URL: https://issues.apache.org/jira/browse/THRIFT-1323
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Reporter: Jim Ancona
>
> When TFramedTransport receives a frame that is larger than the maximum frame 
> size, it throws a TTransportException. This makes that error 
> indistinguishable from a failed client. Because such errors are common, many 
> servers (TSimpleServer, TThreadPoolServer, and Cassandra's 
> CustomTThreadPoolServer) swallow TTransportException without a log message, 
> making it difficult to diagnose this problem. I'm not familiar enough with 
> the code base to suggest which exception to throw in its place, although a 
> subclass of TTransportException, or a new TTransportException.type_ value 
> might work. In any case, the corresponding server implementations should log 
> that condition when it occurs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

2011-09-06 Thread Bryan Duxbury (JIRA) 

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

Bryan Duxbury commented on THRIFT-1312:
---

Hm, I tried this in 1.8.7 and it didn't work for me either. Any sense of why?

> Add MutexableThreadPoolServer and ProcessPoolServer
> ---
>
> Key: THRIFT-1312
> URL: https://issues.apache.org/jira/browse/THRIFT-1312
> Project: Thrift
>  Issue Type: New Feature
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Scott Gonyea
> Fix For: 0.8
>
> Attachments: thrift-1312.patch, thrift-1312.patch, thrift-1312.patch, 
> thrift-1312.patch, thrift-1312.patch
>
>
> Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" 
> and "ProcessPoolServer" to the Thrift Ruby Library.
> The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, 
> as well as an example file that demonstrates its use.
> Below is a lengthy description of how we make use of the MTPServer.  But 
> before getting into that, you can find the code here, or in the included 
> patch.
> https://github.com/sgonyea/thrift/tree/mtps/lib/rb
> This draws very heavily from the ThreadPoolServer, except that it introduces 
> the use of Mutexes as one way to stop the server from spawning threads.  
> Further, it offers a #stop_threads method, that will check the state of each 
> thread and release control once all threads have finished serving requests to 
> clients.
> Internally, this MTPServer is used in conjunction with HAProxy to shut down 
> and start up, cleanly, and to avoid all sorts of crazy race conditions that 
> often arise when serving over a raw socket.
> When the MTPServer is started, it will fill the ThreadPool with N threads.  
> Once done, it is ready to receive requests and will yield to a callback if 
> one is supplied.  In this callback, we call out to HAProxy and signal that we 
> are ready to begin accepting connections from API clients.
> The parent application can be setup to trap any signals, as we do, and to 
> then lock the mutex (to prevent new threads from pooling).  It then calls 
> @server.stop_threads.  It also spins off another thread that will hard shut 
> down the server if Threads continue past an arbitrary amount of time.
> The other benefit in using HAProxy is that it will close connections from 
> clients, if they are idle for some period of time.  This prevents another 
> common issue, where a client remains connected and causes our Thread to 
> block, until the sun explodes.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Build failed in Jenkins: Thrift-cpp #152

2011-09-06 Thread Jake Farrell 
Roger
Thoughts on removing the -Wextra flag from the hudson test script to avoid this?

- Jake



On Sep 6, 2011, at 11:40 AM, Apache Jenkins Server wrote:

> See 
> 
> Changes:
> 
> [jfarrell] Thrift-1322: OCaml lib fail to compile: Thrift.ml line 305, int vs 
> int32 mismatch
> Client: OCaml
> 
> Updates the ocaml lib INTERNAL and PROTOCOL error enums to use the correct 
> numeric values
> 
> --
> [...truncated 459 lines...]
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src 
> -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
> -Werror -Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overflow -Werror -MT THttpTransport.lo -MD -MP -MF 
> .deps/THttpTransport.Tpo -c src/transport/THttpTransport.cpp -o 
> THttpTransport.o >/dev/null 2>&1
> mv -f .deps/THttpTransport.Tpo .deps/THttpTransport.Plo
> /bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
> -I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpClient.lo 
> -MD -MP -MF .deps/THttpClient.Tpo -c -o THttpClient.lo `test -f 
> 'src/transport/THttpClient.cpp' || echo './'`src/transport/THttpClient.cpp
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src 
> -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
> -Werror -Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overflow -Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
> src/transport/THttpClient.cpp  -fPIC -DPIC -o .libs/THttpClient.o
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src 
> -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
> -Werror -Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overflow -Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
> src/transport/THttpClient.cpp -o THttpClient.o >/dev/null 2>&1
> mv -f .deps/THttpClient.Tpo .deps/THttpClient.Plo
> /bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
> -I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpServer.lo 
> -MD -MP -MF .deps/THttpServer.Tpo -c -o THttpServer.lo `test -f 
> 'src/transport/THttpServer.cpp' || echo './'`src/transport/THttpServer.cpp
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src 
> -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
> -Werror -Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overflow -Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
> src/transport/THttpServer.cpp  -fPIC -DPIC -o .libs/THttpServer.o
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src 
> -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
> -Werror -Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overflow -Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
> src/transport/THttpServer.cpp -o THttpServer.o >/dev/null 2>&1
> mv -f .deps/THttpServer.Tpo .deps/THttpServer.Plo
> /bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
> -I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSocket.lo -MD 
> -MP -MF .deps/TSocket.Tpo -c -o TSocket.lo `test -f 
> 'src/transport/TSocket.cpp' || echo './'`src/transport/TSocket.cpp
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src 
> -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
> -Werror -Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overflow -Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
> src/transport/TSocket.cpp  -fPIC -DPIC -o .libs/TSocket.o
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src 
> -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
> -Werror -Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overflow -Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
> src/transport/TSocket.cpp -o TSocket.o >/dev/null 2>&1
> mv -f .deps/TSocket.Tpo .deps/TSocket.Plo
> /bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
> -I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSSLS

[jira] [Commented] (THRIFT-1322) OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch

2011-09-06 Thread Hudson (JIRA) 

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

Hudson commented on THRIFT-1322:


Integrated in Thrift #251 (See [https://builds.apache.org/job/Thrift/251/])
Thrift-1322: OCaml lib fail to compile: Thrift.ml line 305, int vs int32 
mismatch
Client: OCaml

Updates the ocaml lib INTERNAL and PROTOCOL error enums to use the correct 
numeric values


> OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch
> 
>
> Key: THRIFT-1322
> URL: https://issues.apache.org/jira/browse/THRIFT-1322
> Project: Thrift
>  Issue Type: Bug
>  Components: OCaml - Library
> Environment: Mac OS 10.6.8, 64bits x86_64
>Reporter: Philippe STRAUSS
>Assignee: Jake Farrell
>Priority: Blocker
> Fix For: 0.8
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> Between SVN of 20110418 and today, the lib/ocaml has ceased to build.
> I mean it did build on april 18, not lately.
> The build die in this way:
> -- 8< --
> philou@air:~/src/thrift-svn/lib/ocaml$ make
> cd src; make; cd ..
> ocamlopt -c -thread Thrift.ml
> File "Thrift.ml", line 305, characters 6-8:
> Error: This pattern matches values of type int
>   but a pattern was expected which matches values of type int32
> -- 8< --
> The lib/ocaml changes between 20110418 and 20110905 are listed below, and 
> rather thin, should not be a big deal to fix :
> diff -ur thrift-svn-20110418/lib/ocaml/src/Thrift.ml 
> thrift-svn/lib/ocaml/src/Thrift.ml
> --- thrift-svn-20110418/lib/ocaml/src/Thrift.ml 2011-04-13 18:38:21.0 
> +0200
> +++ thrift-svn/lib/ocaml/src/Thrift.ml  2011-08-03 16:10:25.0 +0200
> @@ -292,6 +292,8 @@
>| WRONG_METHOD_NAME
>| BAD_SEQUENCE_ID
>| MISSING_RESULT
> +  | INTERNAL_ERROR
> +  | PROTOCOL_ERROR
>  
>let typ_of_i = function
>0l -> UNKNOWN
> @@ -300,6 +302,8 @@
>  | 3l -> WRONG_METHOD_NAME
>  | 4l -> BAD_SEQUENCE_ID
>  | 5l -> MISSING_RESULT
> +| 61 -> INTERNAL_ERROR
> +| 71 -> PROTOCOL_ERROR
>  | _ -> raise Thrift_error;;
>let typ_to_i = function
>  | UNKNOWN -> 0l
> @@ -308,6 +312,8 @@
>  | WRONG_METHOD_NAME -> 3l
>  | BAD_SEQUENCE_ID -> 4l
>  | MISSING_RESULT -> 5l
> +| INTERNAL_ERROR -> 61
> +| PROTOCOL_ERROR -> 71
>  
>class t =
>object (self)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: Thrift-cpp #152

2011-09-06 Thread Apache Jenkins Server 
See 

Changes:

[jfarrell] Thrift-1322: OCaml lib fail to compile: Thrift.ml line 305, int vs 
int32 mismatch
Client: OCaml

Updates the ocaml lib INTERNAL and PROTOCOL error enums to use the correct 
numeric values

--
[...truncated 459 lines...]
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpTransport.lo -MD -MP -MF .deps/THttpTransport.Tpo -c 
src/transport/THttpTransport.cpp -o THttpTransport.o >/dev/null 2>&1
mv -f .deps/THttpTransport.Tpo .deps/THttpTransport.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpClient.lo 
-MD -MP -MF .deps/THttpClient.Tpo -c -o THttpClient.lo `test -f 
'src/transport/THttpClient.cpp' || echo './'`src/transport/THttpClient.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
src/transport/THttpClient.cpp  -fPIC -DPIC -o .libs/THttpClient.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
src/transport/THttpClient.cpp -o THttpClient.o >/dev/null 2>&1
mv -f .deps/THttpClient.Tpo .deps/THttpClient.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpServer.lo 
-MD -MP -MF .deps/THttpServer.Tpo -c -o THttpServer.lo `test -f 
'src/transport/THttpServer.cpp' || echo './'`src/transport/THttpServer.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
src/transport/THttpServer.cpp  -fPIC -DPIC -o .libs/THttpServer.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
src/transport/THttpServer.cpp -o THttpServer.o >/dev/null 2>&1
mv -f .deps/THttpServer.Tpo .deps/THttpServer.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSocket.lo -MD 
-MP -MF .deps/TSocket.Tpo -c -o TSocket.lo `test -f 'src/transport/TSocket.cpp' 
|| echo './'`src/transport/TSocket.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
src/transport/TSocket.cpp  -fPIC -DPIC -o .libs/TSocket.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
src/transport/TSocket.cpp -o TSocket.o >/dev/null 2>&1
mv -f .deps/TSocket.Tpo .deps/TSocket.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSSLSocket.lo -MD 
-MP -MF .deps/TSSLSocket.Tpo -c -o TSSLSocket.lo `test -f 
'src/transport/TSSLSocket.cpp' || echo './'`src/transport/TSSLSocket.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wal

[jira] [Closed] (THRIFT-1322) OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch

2011-09-06 Thread Jake Farrell (JIRA) 

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

Jake Farrell closed THRIFT-1322.


Resolution: Fixed

Didnt understand what the patch was for at first, I've updated the ocaml driver 
with the necessary changes.

For contributions please attach patches with asf inclusion rather than pasting 
full diffs to the ticket. http://wiki.apache.org/thrift/HowToContribute

> OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch
> 
>
> Key: THRIFT-1322
> URL: https://issues.apache.org/jira/browse/THRIFT-1322
> Project: Thrift
>  Issue Type: Bug
>  Components: OCaml - Library
> Environment: Mac OS 10.6.8, 64bits x86_64
>Reporter: Philippe STRAUSS
>Assignee: Jake Farrell
>Priority: Blocker
> Fix For: 0.8
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> Between SVN of 20110418 and today, the lib/ocaml has ceased to build.
> I mean it did build on april 18, not lately.
> The build die in this way:
> -- 8< --
> philou@air:~/src/thrift-svn/lib/ocaml$ make
> cd src; make; cd ..
> ocamlopt -c -thread Thrift.ml
> File "Thrift.ml", line 305, characters 6-8:
> Error: This pattern matches values of type int
>   but a pattern was expected which matches values of type int32
> -- 8< --
> The lib/ocaml changes between 20110418 and 20110905 are listed below, and 
> rather thin, should not be a big deal to fix :
> diff -ur thrift-svn-20110418/lib/ocaml/src/Thrift.ml 
> thrift-svn/lib/ocaml/src/Thrift.ml
> --- thrift-svn-20110418/lib/ocaml/src/Thrift.ml 2011-04-13 18:38:21.0 
> +0200
> +++ thrift-svn/lib/ocaml/src/Thrift.ml  2011-08-03 16:10:25.0 +0200
> @@ -292,6 +292,8 @@
>| WRONG_METHOD_NAME
>| BAD_SEQUENCE_ID
>| MISSING_RESULT
> +  | INTERNAL_ERROR
> +  | PROTOCOL_ERROR
>  
>let typ_of_i = function
>0l -> UNKNOWN
> @@ -300,6 +302,8 @@
>  | 3l -> WRONG_METHOD_NAME
>  | 4l -> BAD_SEQUENCE_ID
>  | 5l -> MISSING_RESULT
> +| 61 -> INTERNAL_ERROR
> +| 71 -> PROTOCOL_ERROR
>  | _ -> raise Thrift_error;;
>let typ_to_i = function
>  | UNKNOWN -> 0l
> @@ -308,6 +312,8 @@
>  | WRONG_METHOD_NAME -> 3l
>  | BAD_SEQUENCE_ID -> 4l
>  | MISSING_RESULT -> 5l
> +| INTERNAL_ERROR -> 61
> +| PROTOCOL_ERROR -> 71
>  
>class t =
>object (self)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (THRIFT-1322) OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch

2011-09-06 Thread Jake Farrell (JIRA) 

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

Jake Farrell reopened THRIFT-1322:
--

  Assignee: Jake Farrell

> OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch
> 
>
> Key: THRIFT-1322
> URL: https://issues.apache.org/jira/browse/THRIFT-1322
> Project: Thrift
>  Issue Type: Bug
>  Components: OCaml - Library
> Environment: Mac OS 10.6.8, 64bits x86_64
>Reporter: Philippe STRAUSS
>Assignee: Jake Farrell
>Priority: Blocker
> Fix For: 0.8
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> Between SVN of 20110418 and today, the lib/ocaml has ceased to build.
> I mean it did build on april 18, not lately.
> The build die in this way:
> -- 8< --
> philou@air:~/src/thrift-svn/lib/ocaml$ make
> cd src; make; cd ..
> ocamlopt -c -thread Thrift.ml
> File "Thrift.ml", line 305, characters 6-8:
> Error: This pattern matches values of type int
>   but a pattern was expected which matches values of type int32
> -- 8< --
> The lib/ocaml changes between 20110418 and 20110905 are listed below, and 
> rather thin, should not be a big deal to fix :
> diff -ur thrift-svn-20110418/lib/ocaml/src/Thrift.ml 
> thrift-svn/lib/ocaml/src/Thrift.ml
> --- thrift-svn-20110418/lib/ocaml/src/Thrift.ml 2011-04-13 18:38:21.0 
> +0200
> +++ thrift-svn/lib/ocaml/src/Thrift.ml  2011-08-03 16:10:25.0 +0200
> @@ -292,6 +292,8 @@
>| WRONG_METHOD_NAME
>| BAD_SEQUENCE_ID
>| MISSING_RESULT
> +  | INTERNAL_ERROR
> +  | PROTOCOL_ERROR
>  
>let typ_of_i = function
>0l -> UNKNOWN
> @@ -300,6 +302,8 @@
>  | 3l -> WRONG_METHOD_NAME
>  | 4l -> BAD_SEQUENCE_ID
>  | 5l -> MISSING_RESULT
> +| 61 -> INTERNAL_ERROR
> +| 71 -> PROTOCOL_ERROR
>  | _ -> raise Thrift_error;;
>let typ_to_i = function
>  | UNKNOWN -> 0l
> @@ -308,6 +312,8 @@
>  | WRONG_METHOD_NAME -> 3l
>  | BAD_SEQUENCE_ID -> 4l
>  | MISSING_RESULT -> 5l
> +| INTERNAL_ERROR -> 61
> +| PROTOCOL_ERROR -> 71
>  
>class t =
>object (self)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1322) OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch

2011-09-06 Thread Philippe STRAUSS (JIRA) 

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

Philippe STRAUSS commented on THRIFT-1322:
--

This is the patch to apply on top of THRIFT-690:

--- Thrift.ml.orig  2011-09-06 17:59:44.0 +0200
+++ Thrift.ml   2011-09-06 17:58:39.0 +0200
@@ -302,8 +302,8 @@
 | 3l -> WRONG_METHOD_NAME
 | 4l -> BAD_SEQUENCE_ID
 | 5l -> MISSING_RESULT
-| 61 -> INTERNAL_ERROR
-| 71 -> PROTOCOL_ERROR
+| 6l -> INTERNAL_ERROR
+| 7l -> PROTOCOL_ERROR
 | _ -> raise Thrift_error;;
   let typ_to_i = function
 | UNKNOWN -> 0l
@@ -312,8 +312,8 @@
 | WRONG_METHOD_NAME -> 3l
 | BAD_SEQUENCE_ID -> 4l
 | MISSING_RESULT -> 5l
-| INTERNAL_ERROR -> 61
-| PROTOCOL_ERROR -> 71
+| INTERNAL_ERROR -> 6l
+| PROTOCOL_ERROR -> 7l
 
   class t =
   object (self)

-- 8< --


6 and 7 L, el, not one, 1 :-)






> OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch
> 
>
> Key: THRIFT-1322
> URL: https://issues.apache.org/jira/browse/THRIFT-1322
> Project: Thrift
>  Issue Type: Bug
>  Components: OCaml - Library
> Environment: Mac OS 10.6.8, 64bits x86_64
>Reporter: Philippe STRAUSS
>Priority: Blocker
> Fix For: 0.8
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> Between SVN of 20110418 and today, the lib/ocaml has ceased to build.
> I mean it did build on april 18, not lately.
> The build die in this way:
> -- 8< --
> philou@air:~/src/thrift-svn/lib/ocaml$ make
> cd src; make; cd ..
> ocamlopt -c -thread Thrift.ml
> File "Thrift.ml", line 305, characters 6-8:
> Error: This pattern matches values of type int
>   but a pattern was expected which matches values of type int32
> -- 8< --
> The lib/ocaml changes between 20110418 and 20110905 are listed below, and 
> rather thin, should not be a big deal to fix :
> diff -ur thrift-svn-20110418/lib/ocaml/src/Thrift.ml 
> thrift-svn/lib/ocaml/src/Thrift.ml
> --- thrift-svn-20110418/lib/ocaml/src/Thrift.ml 2011-04-13 18:38:21.0 
> +0200
> +++ thrift-svn/lib/ocaml/src/Thrift.ml  2011-08-03 16:10:25.0 +0200
> @@ -292,6 +292,8 @@
>| WRONG_METHOD_NAME
>| BAD_SEQUENCE_ID
>| MISSING_RESULT
> +  | INTERNAL_ERROR
> +  | PROTOCOL_ERROR
>  
>let typ_of_i = function
>0l -> UNKNOWN
> @@ -300,6 +302,8 @@
>  | 3l -> WRONG_METHOD_NAME
>  | 4l -> BAD_SEQUENCE_ID
>  | 5l -> MISSING_RESULT
> +| 61 -> INTERNAL_ERROR
> +| 71 -> PROTOCOL_ERROR
>  | _ -> raise Thrift_error;;
>let typ_to_i = function
>  | UNKNOWN -> 0l
> @@ -308,6 +312,8 @@
>  | WRONG_METHOD_NAME -> 3l
>  | BAD_SEQUENCE_ID -> 4l
>  | MISSING_RESULT -> 5l
> +| INTERNAL_ERROR -> 61
> +| PROTOCOL_ERROR -> 71
>  
>class t =
>object (self)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1322) OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch

2011-09-06 Thread Philippe STRAUSS (JIRA) 

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

Philippe STRAUSS commented on THRIFT-1322:
--

Jake,

You got wrong (the other way around) understanding, the patch I attached is 
exactly the one added by THRIFT-690 (just discorering this fact by reading the 
case on jira), and **is the change that now makes ocaml lib _fail_ to compile**.

also, is there some 





> OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch
> 
>
> Key: THRIFT-1322
> URL: https://issues.apache.org/jira/browse/THRIFT-1322
> Project: Thrift
>  Issue Type: Bug
>  Components: OCaml - Library
> Environment: Mac OS 10.6.8, 64bits x86_64
>Reporter: Philippe STRAUSS
>Priority: Blocker
> Fix For: 0.8
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> Between SVN of 20110418 and today, the lib/ocaml has ceased to build.
> I mean it did build on april 18, not lately.
> The build die in this way:
> -- 8< --
> philou@air:~/src/thrift-svn/lib/ocaml$ make
> cd src; make; cd ..
> ocamlopt -c -thread Thrift.ml
> File "Thrift.ml", line 305, characters 6-8:
> Error: This pattern matches values of type int
>   but a pattern was expected which matches values of type int32
> -- 8< --
> The lib/ocaml changes between 20110418 and 20110905 are listed below, and 
> rather thin, should not be a big deal to fix :
> diff -ur thrift-svn-20110418/lib/ocaml/src/Thrift.ml 
> thrift-svn/lib/ocaml/src/Thrift.ml
> --- thrift-svn-20110418/lib/ocaml/src/Thrift.ml 2011-04-13 18:38:21.0 
> +0200
> +++ thrift-svn/lib/ocaml/src/Thrift.ml  2011-08-03 16:10:25.0 +0200
> @@ -292,6 +292,8 @@
>| WRONG_METHOD_NAME
>| BAD_SEQUENCE_ID
>| MISSING_RESULT
> +  | INTERNAL_ERROR
> +  | PROTOCOL_ERROR
>  
>let typ_of_i = function
>0l -> UNKNOWN
> @@ -300,6 +302,8 @@
>  | 3l -> WRONG_METHOD_NAME
>  | 4l -> BAD_SEQUENCE_ID
>  | 5l -> MISSING_RESULT
> +| 61 -> INTERNAL_ERROR
> +| 71 -> PROTOCOL_ERROR
>  | _ -> raise Thrift_error;;
>let typ_to_i = function
>  | UNKNOWN -> 0l
> @@ -308,6 +312,8 @@
>  | WRONG_METHOD_NAME -> 3l
>  | BAD_SEQUENCE_ID -> 4l
>  | MISSING_RESULT -> 5l
> +| INTERNAL_ERROR -> 61
> +| PROTOCOL_ERROR -> 71
>  
>class t =
>object (self)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1279) type set is handled incorrectly when writing object

2011-09-06 Thread Hudson (JIRA) 

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

Hudson commented on THRIFT-1279:


Integrated in Thrift #250 (See [https://builds.apache.org/job/Thrift/250/])
Thrift-1279: type set is handled incorrectly when writing object
Client: php
Patch: Darius Staisiunas

Fixes issue to iIterate through scalar types correctly.


> type set is handled incorrectly when writing object
> ---
>
> Key: THRIFT-1279
> URL: https://issues.apache.org/jira/browse/THRIFT-1279
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler, PHP - Library
>Affects Versions: 0.7
>Reporter: Darius Staisiunas
> Fix For: 0.8
>
> Attachments: thrift-1279.patch
>
>
> Patch provided in https://issues.apache.org/jira/browse/THRIFT-342 doesn't 
> handle object writing correctly:
> if one of the parameters is set
> struct MyStruct {
> 10: string id,
> 20: string name,
> 30: set setOfIDs
> }
> in generated file de-serialization of object is
> public function read($input)
> ...
> $xfer += $input->readString($elem5);
> if (is_scalar($elem5)) {
>   $this->setOfIDs[$elem5] = true;
> } else {
>   $this->setOfIDs []= $elem5;
> }
> ...
> but when serializing, we are looping only through values of array:
> public function write($input) 
> ...
> foreach ($this->setOfIDs as $iter6)
> {
>   if (is_scalar($iter6)) {
> $this->setOfIDs[$iter6] = true;
>   }
> $xfer += $output->writeString($iter6);
>   }
> }
> ...
> But if our element is scalar - we should be iterating through keys.
> it should look like:
> foreach ($this->terminalIds as $iter6 => $iter7)
> {
>   if (is_scalar($iter7)) {
> $xfer += $output->writeString($iter6);
>   } else {
> $xfer += $output->writeString($iter7);
>   }
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: Thrift-cpp #151

2011-09-06 Thread Apache Jenkins Server 
See 

Changes:

[jfarrell] Thrift-1279: type set is handled incorrectly when writing object
Client: php
Patch: Darius Staisiunas

Fixes issue to iIterate through scalar types correctly.

--
[...truncated 481 lines...]
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpTransport.lo -MD -MP -MF .deps/THttpTransport.Tpo -c 
src/transport/THttpTransport.cpp -o THttpTransport.o >/dev/null 2>&1
mv -f .deps/THttpTransport.Tpo .deps/THttpTransport.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpClient.lo 
-MD -MP -MF .deps/THttpClient.Tpo -c -o THttpClient.lo `test -f 
'src/transport/THttpClient.cpp' || echo './'`src/transport/THttpClient.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
src/transport/THttpClient.cpp  -fPIC -DPIC -o .libs/THttpClient.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
src/transport/THttpClient.cpp -o THttpClient.o >/dev/null 2>&1
mv -f .deps/THttpClient.Tpo .deps/THttpClient.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpServer.lo 
-MD -MP -MF .deps/THttpServer.Tpo -c -o THttpServer.lo `test -f 
'src/transport/THttpServer.cpp' || echo './'`src/transport/THttpServer.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
src/transport/THttpServer.cpp  -fPIC -DPIC -o .libs/THttpServer.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
src/transport/THttpServer.cpp -o THttpServer.o >/dev/null 2>&1
mv -f .deps/THttpServer.Tpo .deps/THttpServer.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSocket.lo -MD 
-MP -MF .deps/TSocket.Tpo -c -o TSocket.lo `test -f 'src/transport/TSocket.cpp' 
|| echo './'`src/transport/TSocket.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
src/transport/TSocket.cpp  -fPIC -DPIC -o .libs/TSocket.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
src/transport/TSocket.cpp -o TSocket.o >/dev/null 2>&1
mv -f .deps/TSocket.Tpo .deps/TSocket.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSSLSocket.lo -MD 
-MP -MF .deps/TSSLSocket.Tpo -c -o TSSLSocket.lo `test -f 
'src/transport/TSSLSocket.cpp' || echo './'`src/transport/TSSLSocket.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno

[jira] [Closed] (THRIFT-1322) OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch

2011-09-06 Thread Jake Farrell (JIRA) 

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

Jake Farrell closed THRIFT-1322.


Resolution: Duplicate

THRIFT-690 applied this same patch to OCaml lib. This is available in trunk 
since 2011-08-03 04:49:27

> OCaml lib fail to compile: Thrift.ml line 305, int vs int32 mismatch
> 
>
> Key: THRIFT-1322
> URL: https://issues.apache.org/jira/browse/THRIFT-1322
> Project: Thrift
>  Issue Type: Bug
>  Components: OCaml - Library
> Environment: Mac OS 10.6.8, 64bits x86_64
>Reporter: Philippe STRAUSS
>Priority: Blocker
> Fix For: 0.8
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> Between SVN of 20110418 and today, the lib/ocaml has ceased to build.
> I mean it did build on april 18, not lately.
> The build die in this way:
> -- 8< --
> philou@air:~/src/thrift-svn/lib/ocaml$ make
> cd src; make; cd ..
> ocamlopt -c -thread Thrift.ml
> File "Thrift.ml", line 305, characters 6-8:
> Error: This pattern matches values of type int
>   but a pattern was expected which matches values of type int32
> -- 8< --
> The lib/ocaml changes between 20110418 and 20110905 are listed below, and 
> rather thin, should not be a big deal to fix :
> diff -ur thrift-svn-20110418/lib/ocaml/src/Thrift.ml 
> thrift-svn/lib/ocaml/src/Thrift.ml
> --- thrift-svn-20110418/lib/ocaml/src/Thrift.ml 2011-04-13 18:38:21.0 
> +0200
> +++ thrift-svn/lib/ocaml/src/Thrift.ml  2011-08-03 16:10:25.0 +0200
> @@ -292,6 +292,8 @@
>| WRONG_METHOD_NAME
>| BAD_SEQUENCE_ID
>| MISSING_RESULT
> +  | INTERNAL_ERROR
> +  | PROTOCOL_ERROR
>  
>let typ_of_i = function
>0l -> UNKNOWN
> @@ -300,6 +302,8 @@
>  | 3l -> WRONG_METHOD_NAME
>  | 4l -> BAD_SEQUENCE_ID
>  | 5l -> MISSING_RESULT
> +| 61 -> INTERNAL_ERROR
> +| 71 -> PROTOCOL_ERROR
>  | _ -> raise Thrift_error;;
>let typ_to_i = function
>  | UNKNOWN -> 0l
> @@ -308,6 +312,8 @@
>  | WRONG_METHOD_NAME -> 3l
>  | BAD_SEQUENCE_ID -> 4l
>  | MISSING_RESULT -> 5l
> +| INTERNAL_ERROR -> 61
> +| PROTOCOL_ERROR -> 71
>  
>class t =
>object (self)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1279) type set is handled incorrectly when writing object

2011-09-06 Thread Jake Farrell (JIRA) 

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

Jake Farrell closed THRIFT-1279.


Resolution: Fixed

Committed, thanks for the patch

> type set is handled incorrectly when writing object
> ---
>
> Key: THRIFT-1279
> URL: https://issues.apache.org/jira/browse/THRIFT-1279
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler, PHP - Library
>Affects Versions: 0.7
>Reporter: Darius Staisiunas
> Fix For: 0.8
>
> Attachments: thrift-1279.patch
>
>
> Patch provided in https://issues.apache.org/jira/browse/THRIFT-342 doesn't 
> handle object writing correctly:
> if one of the parameters is set
> struct MyStruct {
> 10: string id,
> 20: string name,
> 30: set setOfIDs
> }
> in generated file de-serialization of object is
> public function read($input)
> ...
> $xfer += $input->readString($elem5);
> if (is_scalar($elem5)) {
>   $this->setOfIDs[$elem5] = true;
> } else {
>   $this->setOfIDs []= $elem5;
> }
> ...
> but when serializing, we are looping only through values of array:
> public function write($input) 
> ...
> foreach ($this->setOfIDs as $iter6)
> {
>   if (is_scalar($iter6)) {
> $this->setOfIDs[$iter6] = true;
>   }
> $xfer += $output->writeString($iter6);
>   }
> }
> ...
> But if our element is scalar - we should be iterating through keys.
> it should look like:
> foreach ($this->terminalIds as $iter6 => $iter7)
> {
>   if (is_scalar($iter7)) {
> $xfer += $output->writeString($iter6);
>   } else {
> $xfer += $output->writeString($iter7);
>   }
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1326) on some platforms, #include is necessary to be included in Thrift.h

2011-09-06 Thread Philippe STRAUSS (JIRA) 
on some platforms, #include  is necessary to be included in Thrift.h
--

 Key: THRIFT-1326
 URL: https://issues.apache.org/jira/browse/THRIFT-1326
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
 Environment: Mac OSX 10.6.8 / x86_64 / GCC 4.6.1 for building thrift 
and server code generated by thrift
Reporter: Philippe STRAUSS
 Fix For: 0.8


building server code generated by thrift, I needed to add #include  
in main Thrift.h to prevent an "error: uint32_t does not define a type" error. 
Maybe it does not show on linux, or with earlier GCC.

Maybe there is a better place than the main Thrift.h for thins #include 


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1325) Thrift SVN and latest GCC issue: Undefined symbols: "apache::thrift::protocol::TBinaryProtocolT::VERSION_MASK"

2011-09-06 Thread Philippe STRAUSS (JIRA) 
Thrift SVN and latest GCC issue: Undefined symbols: 
"apache::thrift::protocol::TBinaryProtocolT::VERSION_MASK"
-

 Key: THRIFT-1325
 URL: https://issues.apache.org/jira/browse/THRIFT-1325
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
 Environment: Mac OS 10.6.8 x86_64, GNU GCC 4.6.1 hand compiled
Reporter: Philippe STRAUSS
Priority: Blocker
 Fix For: 0.8


I need latest gcc for a pet project of mine using intrisics. Using GCC 4.6.1, 
building code generated by thrift for a C++ server, I always get the error cut 
and pasted below at link time. Using apple shipped gcc 4.2.1 it build (link) 
fine, but cannot use it for another part of my project :(

+ /opt/gnucc/bin/g++ -g -DDEBUG -I/usr/local/include -I/opt/local/include 
-I/opt/misc/include -I/opt/misc/include/thrift -I/opt/av/include 
-I/opt/num/include -o jack_preamp.nat jack_preamp.o rc_types.o rc_constants.o 
Control.o ../common_c/libcommon.a ../jackc/libjackc.a ../config/libcf.a 
../libsigpath/libsigpath.a -framework CoreAudio -framework CoreServices 
-framework AudioUnit -L/usr/local/lib -ljack -L/opt/local/lib -lsndfile 
-L/opt/misc/lib -lconfig -L/opt/misc/lib -lthrift -L/opt/av/lib -L/opt/num/lib 
-lconvolve -lsndfile -lsamplerate -lfftw3f
Undefined symbols:
  
"apache::thrift::protocol::TBinaryProtocolT::VERSION_MASK",
 [==referenced 
from:==  ] 
00225 / 00227
  
apache::thrift::protocol::TBinaryProtocolT::readMessageBegin(std::basic_string, std::allocator >&, 
apache::thrift::protocol::TMessageType&, int&) in jack_preamp.o
  
"apache::thrift::protocol::TBinaryProtocolT::VERSION_1",
 referenced from:
  
apache::thrift::protocol::TBinaryProtocolT::writeMessageBegin(std::basic_string, std::allocator > const&, 
apache::thrift::protocol::TMessageType, int) in jack_preamp.o
  
apache::thrift::protocol::TBinaryProtocolT::readMessageBegin(std::basic_string, std::allocator >&, 
apache::thrift::protocol::TMessageType&, int&) in jack_preamp.o
ld: symbol(s) not found
collect2: ld a retourné 1 code d'état d'exécution



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira