[jira] [Commented] (THRIFT-1355) Running make in lib/rb doesn't build the native extensions

2011-09-22 Thread Takashi Yonebayashi (JIRA) 

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

Takashi Yonebayashi commented on THRIFT-1355:
-

To clarify, this likely won't reproduce the failure unless you have a version 
of the native extensions installed from another location that fails the tests.  
You can reproduce the lack of compilation of the files in the ext directory.  

> Running make in lib/rb doesn't build the native extensions
> --
>
> Key: THRIFT-1355
> URL: https://issues.apache.org/jira/browse/THRIFT-1355
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Takashi Yonebayashi
>Assignee: Jake Farrell
>Priority: Minor
>


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

[jira] [Commented] (THRIFT-1355) Running make in lib/rb doesn't build the native extensions

2011-09-22 Thread Takashi Yonebayashi (JIRA) 

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

Takashi Yonebayashi commented on THRIFT-1355:
-

1)
Thrift::ProtocolException in 'Thrift::CompactProtocol should deserialize an 
empty map to an empty hash'
Required field i32_map is unset!
./spec/../test/debug_proto/gen-rb/debug_proto_test_types.rb:385:in `validate'
./spec/../lib/thrift/serializer/deserializer.rb:29:in `read'
./spec/../lib/thrift/serializer/deserializer.rb:29:in `deserialize'
./spec/compact_protocol_spec.rb:125:

Finished in 3.057992 seconds

This isn't likely to help you since I only get this error because I have thrift 
installed elsewhere that fails this test.  This means that the ext that was 
installed from that directory is still there after I run make.  This makes 
sense since when I check the ext directory after running rake build_ext (or 
make, etc) there are no object files.  Running make in the ext directory before 
running make in lib/rb fixes the tests.  

If you want to reproduce this, run make clean from lib/rb/ext then run make 
from lib/rb.  If you check lib/rb/ext, the extensions will not have been 
compiled.  



> Running make in lib/rb doesn't build the native extensions
> --
>
> Key: THRIFT-1355
> URL: https://issues.apache.org/jira/browse/THRIFT-1355
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Takashi Yonebayashi
>Assignee: Jake Farrell
>Priority: Minor
>


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

[jira] [Commented] (THRIFT-1355) Running make in lib/rb doesn't build the native extensions

2011-09-22 Thread Jake Farrell (JIRA) 

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

Jake Farrell commented on THRIFT-1355:
--

Can you attach the error that you are seeing when you run "rake build_ext" from 
the lib/rb folder

> Running make in lib/rb doesn't build the native extensions
> --
>
> Key: THRIFT-1355
> URL: https://issues.apache.org/jira/browse/THRIFT-1355
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Takashi Yonebayashi
>Assignee: Jake Farrell
>Priority: Minor
>


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

[jira] [Commented] (THRIFT-1355) Running make in lib/rb doesn't build the native extensions

2011-09-22 Thread Takashi Yonebayashi (JIRA) 

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

Takashi Yonebayashi commented on THRIFT-1355:
-

This was against 1174393.  This is the current head.  The problem isn't with 
building the gem, it's with running 'ruby extconf.rb && make' from lib/rb/ext.  

> Running make in lib/rb doesn't build the native extensions
> --
>
> Key: THRIFT-1355
> URL: https://issues.apache.org/jira/browse/THRIFT-1355
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Takashi Yonebayashi
>Assignee: Jake Farrell
>Priority: Minor
>


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

[jira] [Issue Comment Edited] (THRIFT-1031) Patch to compile Thrift for vc++ 9.0 and 10.0

2011-09-22 Thread alexandre parenteau (JIRA) 

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

alexandre parenteau edited comment on THRIFT-1031 at 9/22/11 11:59 PM:
---

Hi, thanks all for making this happen!

I had a chance finally to compile/run it (using the Calculator), and here are 
my comments/questions for @James:

1- overall definitively this looks good: I guess there is no WIN64 target, 
because there is no pthread for WIN64?

2- Cosmetic: something needs to define "#define HAVE_GETTIMEOFDAY" 
(windows/config.h?)

3- Cosmetic: #define __BYTE_ORDER: this is not necessary anymore, another patch 
of mine previously fixed the auto detection on win32 using boost. The README 
may also reflect that (double should be fine).

4- Cosmetic: typedef __kernel_size_t  size_t, typedef __kernel_ssize_t ssize_t: 
I found this easier version: typedef  ptrdiff_t   ssize_t; (don't think size_t 
needs to be defined AFAIK)

5- Cosmetic: #define NOMINMAX (before Windows.h, because std::min is used in 
thrift)

6- Cosmetic warning: #pragma warning(disable: 4996) and #pragma 
warning(disable: 4250) could be nice ("POSIX name for this item is deprecated", 
"inherits via dominance")

7- config.h: here is my biggest concern: you decided (honorably!) to re-use 
config.h (and define HAVE_CONFIG_H): I find it in practice annoying because it 
assumes "config.h" is at the same level of "Thrift.h". This forces in turn to 
add /windows to the include path. What happens is when mixing 
with other libraries who also use config.h, it may take precedence over 
thrift's config.h. Ideally, I would prefer if *not* using HAVE_CONFIG_H, and do 
something like this instead:

#ifdef _WIN32
#include "windows/config.h"
$endif

When included from Thrift.h, this guarantees to pick the right config.h (and 
not Python's one for example).

Now what happens for the source code .cpp which does not include Thrift.h? Well 
since you are using already force-compilation, you could add windows/config.h 
to the list for forced headers. I found this to work in practice.

Again, thanks a lot for the patch!


  was (Author: aubonbeurre):
Hi, thanks all for making this happen!

I had a chance finally to compile/run it (using the Calculator), and here are 
my comments/questions for @James:

1- overall definitively this looks good: I guess there is no WIN64 target, 
because there is no pthread for WIN64?

2- Cosmetic: something needs to define "#define HAVE_GETTIMEOFDAY" 
(windows/config.h?)

3- Cosmetic: #define __BYTE_ORDER: this is not necessary anymore, another patch 
of mine previously fixed the auto detection on win32 using boost. The README 
may also reflect that (double should be fine).

4- Cosmetic: typedef __kernel_size_t  size_t, typedef __kernel_ssize_t ssize_t: 
I found this easier version: typedef  ptrdiff_t   ssize_t; (don't think size_t 
needs to be defined AFAIK)

5- Cosmetic: #define NOMINMAX (before Windows.h, because std::min is used in 
thrift)

6- Cosmetic warning: #pragma warning(disable: 4996) and #pragma 
warning(disable: 4250) could be nice ("POSIX name for this item is deprecated", 
"inherits via dominance")

7- config.h: here is my biggest concern: you decided (honorably!) to re-use 
config.h (and define HAVE_CONFIG_H): I find it in practice annoying because it 
assumes "config.h" is at the same level of "Thrift.h". This forces in turn to 
add /windows to the include path. What happens is when mixing 
with other libraries who also use config.h, it may take precedence over 
thrift's config.h. Ideally, I would prefer if *not* using HAVE_CONFIG_H, and do 
something like this instead:

#ifdef _WIN32
#include "windows/config.h"
$endif

When included from Thrift.h, this guarantees to pick the right config.h (and 
not Python's one for example).

Now what happens for the source code .cpp? Well since you are using already 
force-compilation, you could add windows/config.h to the list for forced 
headers.

Again, thanks a lot for the patch!

  
> Patch to compile Thrift for vc++ 9.0 and 10.0
> -
>
> Key: THRIFT-1031
> URL: https://issues.apache.org/jira/browse/THRIFT-1031
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
> Environment: Windows XP 32bit, vc++ 9.0, 10.0
>Reporter: James Dickson
>Assignee: Roger Meier
>Priority: Trivial
> Fix For: 0.8
>
> Attachments: thrift_msvc.patch, thrift_msvc_v0_1.patch, 
> thrift_msvc_v0_2.patch, thrift_msvc_v0_3.patch, thrift_msvc_v0_4.patch, 
> thrift_msvc_v0_5.patch, thrift_msvc_v0_6.patch
>
>
> At our company we need clients running on Windows being able to connect to 
> our linux servers running hypertable. The attached patch enables the parts 
> needed by Hyp

[jira] [Commented] (THRIFT-1031) Patch to compile Thrift for vc++ 9.0 and 10.0

2011-09-22 Thread alexandre parenteau (JIRA) 

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

alexandre parenteau commented on THRIFT-1031:
-

Hi, thanks all for making this happen!

I had a chance finally to compile/run it (using the Calculator), and here are 
my comments/questions for @James:

1- overall definitively this looks good: I guess there is no WIN64 target, 
because there is no pthread for WIN64?

2- Cosmetic: something needs to define "#define HAVE_GETTIMEOFDAY" 
(windows/config.h?)

3- Cosmetic: #define __BYTE_ORDER: this is not necessary anymore, another patch 
of mine previously fixed the auto detection on win32 using boost. The README 
may also reflect that (double should be fine).

4- Cosmetic: typedef __kernel_size_t  size_t, typedef __kernel_ssize_t ssize_t: 
I found this easier version: typedef  ptrdiff_t   ssize_t; (don't think size_t 
needs to be defined AFAIK)

5- Cosmetic: #define NOMINMAX (before Windows.h, because std::min is used in 
thrift)

6- Cosmetic warning: #pragma warning(disable: 4996) and #pragma 
warning(disable: 4250) could be nice ("POSIX name for this item is deprecated", 
"inherits via dominance")

7- config.h: here is my biggest concern: you decided (honorably!) to re-use 
config.h (and define HAVE_CONFIG_H): I find it in practice annoying because it 
assumes "config.h" is at the same level of "Thrift.h". This forces in turn to 
add /windows to the include path. What happens is when mixing 
with other libraries who also use config.h, it may take precedence over 
thrift's config.h. Ideally, I would prefer if *not* using HAVE_CONFIG_H, and do 
something like this instead:

#ifdef _WIN32
#include "windows/config.h"
$endif

When included from Thrift.h, this guarantees to pick the right config.h (and 
not Python's one for example).

Now what happens for the source code .cpp? Well since you are using already 
force-compilation, you could add windows/config.h to the list for forced 
headers.

Again, thanks a lot for the patch!


> Patch to compile Thrift for vc++ 9.0 and 10.0
> -
>
> Key: THRIFT-1031
> URL: https://issues.apache.org/jira/browse/THRIFT-1031
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
> Environment: Windows XP 32bit, vc++ 9.0, 10.0
>Reporter: James Dickson
>Assignee: Roger Meier
>Priority: Trivial
> Fix For: 0.8
>
> Attachments: thrift_msvc.patch, thrift_msvc_v0_1.patch, 
> thrift_msvc_v0_2.patch, thrift_msvc_v0_3.patch, thrift_msvc_v0_4.patch, 
> thrift_msvc_v0_5.patch, thrift_msvc_v0_6.patch
>
>
> At our company we need clients running on Windows being able to connect to 
> our linux servers running hypertable. The attached patch enables the parts 
> needed by Hypertable to be compiled on Windows using either the VC++ 9.0 or 
> 10.0 compilers.
> Having read previous posts about ports using boost::asio we found these to be 
> too intrusive for our needs. This version uses pthreads_win32 and winsock2 
> and is as designed to be as un-intrusive as is possible to the original unix 
> code base. It is mostly #defines between unix sockets and winsock2 sockets. 
> We also tried to follow the folder structuring of the C# runtime that has 
> visual studio solutions to be consistent.
> More details are in the README as not all the functionality of the original 
> unix code base is available to windows users. We will add the missing 
> functionality, we just wanted to share what we had as for a Windows based 
> client for us it is sufficient.
> The patch is based on the latest revision in SVN, we would love feedback and 
> any code reviews. If there is any possibility of this being added to the main 
> trunk then that would be much appreciated, however we don't expect that.

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

[jira] [Assigned] (THRIFT-1355) Running make in lib/rb doesn't build the native extensions

2011-09-22 Thread Jake Farrell (JIRA) 

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

Jake Farrell reassigned THRIFT-1355:


Assignee: Jake Farrell

> Running make in lib/rb doesn't build the native extensions
> --
>
> Key: THRIFT-1355
> URL: https://issues.apache.org/jira/browse/THRIFT-1355
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Takashi Yonebayashi
>Assignee: Jake Farrell
>Priority: Minor
>


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

[jira] [Commented] (THRIFT-1355) Running make in lib/rb doesn't build the native extensions

2011-09-22 Thread Jake Farrell (JIRA) 

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

Jake Farrell commented on THRIFT-1355:
--

What version is this bug against? I committed a change earlier today which will 
generate the gem by default when building the rb library

> Running make in lib/rb doesn't build the native extensions
> --
>
> Key: THRIFT-1355
> URL: https://issues.apache.org/jira/browse/THRIFT-1355
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Takashi Yonebayashi
>Priority: Minor
>


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

[jira] [Commented] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser

2011-09-22 Thread Wade Simmons (JIRA) 

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

Wade Simmons commented on THRIFT-1353:
--

I'm the author of this upstream branch (and the original author of the Node.js 
support). I plan to spend some time this weekend working on getting a patch 
made from this branch so we can get it merged upstream. There are a few things 
that aren't backwards compatible, so we will need to make sure that is properly 
described in the 0.8 release.

> Switch to performance branch, get rid of BinaryParser
> -
>
> Key: THRIFT-1353
> URL: https://issues.apache.org/jira/browse/THRIFT-1353
> Project: Thrift
>  Issue Type: Improvement
>  Components: Node.js - Library
>Affects Versions: 0.7
>Reporter: Hans Duedal
>  Labels: node, nodejs
> Fix For: 0.8
>
>
> I vote that the thrift library switches to the performance branch at 
> https://github.com/wadey/node-thrift/tree/performance
> I much prefer using the node.js buffers over the BinaryParser class, the 
> performance branch seems focused on this very issue. Also it includes the 
> excellent int64 implementation from broofa. What's not to like?

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

[jira] [Created] (THRIFT-1355) Running make in lib/rb doesn't build the native extensions

2011-09-22 Thread Takashi Yonebayashi (JIRA) 
Running make in lib/rb doesn't build the native extensions
--

 Key: THRIFT-1355
 URL: https://issues.apache.org/jira/browse/THRIFT-1355
 Project: Thrift
  Issue Type: Bug
  Components: Ruby - Library
Reporter: Takashi Yonebayashi
Priority: Minor




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

[jira] [Commented] (THRIFT-1354) Add rake task to build just the gem file

2011-09-22 Thread Hudson (JIRA) 

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

Hudson commented on THRIFT-1354:


Integrated in Thrift #273 (See [https://builds.apache.org/job/Thrift/273/])
Thrift-1354: Add rake task to build just the gem file
Client: rb
Patch: jfarrell

Updates ruby build to now build the gem by default and adds a rake task to 
create the gem.


> Add rake task to build just the gem file
> 
>
> Key: THRIFT-1354
> URL: https://issues.apache.org/jira/browse/THRIFT-1354
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Jake Farrell
>Assignee: Jake Farrell
> Fix For: 0.8
>
> Attachments: thrift-1354.patch
>
>


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

Build failed in Jenkins: Thrift #273

2011-09-22 Thread Apache Jenkins Server 
See 

Changes:

[jfarrell] Thrift-1354: Add rake task to build just the gem file
Client: rb
Patch: jfarrell

Updates ruby build to now build the gem by default and adds a rake task to 
create the gem.

--
[...truncated 773 lines...]
[WARNING::183]
 64-bit constant "9223372036854775807" may not work in all languages.

[WARNING::192]
 64-bit constant "4294967295" may not work in all languages.

[WARNING::192]
 64-bit constant "1099511627775" may not work in all languages.

[WARNING::192]
 64-bit constant "281474976710655" may not work in all languages.

[WARNING::192]
 64-bit constant "72057594037927935" may not work in all languages.

[WARNING::192]
 64-bit constant "9223372036854775807" may not work in all languages.

[WARNING::201]
 64-bit constant "9223372036854775807" may not work in all languages.

[WARNING::208]
 64-bit constant "9223372036854775807" may not work in all languages.

/bin/bash ../../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../../.. -I../../../lib/cpp/src -I/usr/include  -Wall -g -O2 -MT 
DebugProtoTest_types.lo -MD -MP -MF .deps/DebugProtoTest_types.Tpo -c -o 
DebugProtoTest_types.lo `test -f 'gen-cpp/DebugProtoTest_types.cpp' || echo 
'./'`gen-cpp/DebugProtoTest_types.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src 
-I/usr/include -Wall -g -O2 -MT DebugProtoTest_types.lo -MD -MP -MF 
.deps/DebugProtoTest_types.Tpo -c gen-cpp/DebugProtoTest_types.cpp  -fPIC -DPIC 
-o .libs/DebugProtoTest_types.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src 
-I/usr/include -Wall -g -O2 -MT DebugProtoTest_types.lo -MD -MP -MF 
.deps/DebugProtoTest_types.Tpo -c gen-cpp/DebugProtoTest_types.cpp -o 
DebugProtoTest_types.o >/dev/null 2>&1
mv -f .deps/DebugProtoTest_types.Tpo .deps/DebugProtoTest_types.Plo
../../../compiler/cpp/thrift --gen cpp:dense 
../../../test/OptionalRequiredTest.thrift
/bin/bash ../../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../../.. -I../../../lib/cpp/src -I/usr/include  -Wall -g -O2 -MT 
OptionalRequiredTest_types.lo -MD -MP -MF .deps/OptionalRequiredTest_types.Tpo 
-c -o OptionalRequiredTest_types.lo `test -f 
'gen-cpp/OptionalRequiredTest_types.cpp' || echo 
'./'`gen-cpp/OptionalRequiredTest_types.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src 
-I/usr/include -Wall -g -O2 -MT OptionalRequiredTest_types.lo -MD -MP -MF 
.deps/OptionalRequiredTest_types.Tpo -c gen-cpp/OptionalRequiredTest_types.cpp  
-fPIC -DPIC -o .libs/OptionalRequiredTest_types.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src 
-I/usr/include -Wall -g -O2 -MT OptionalRequiredTest_types.lo -MD -MP -MF 
.deps/OptionalRequiredTest_types.Tpo -c gen-cpp/OptionalRequiredTest_types.cpp 
-o OptionalRequiredTest_types.o >/dev/null 2>&1
mv -f .deps/OptionalRequiredTest_types.Tpo .deps/OptionalRequiredTest_types.Plo
../../../compiler/cpp/thrift --gen cpp:dense ../../../test/ThriftTest.thrift
/bin/bash ../../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../../.. -I../../../lib/cpp/src -I/usr/include  -Wall -g -O2 -MT 
ThriftTest_types.lo -MD -MP -MF .deps/ThriftTest_types.Tpo -c -o 
ThriftTest_types.lo `test -f 'gen-cpp/ThriftTest_types.cpp' || echo 
'./'`gen-cpp/ThriftTest_types.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src 
-I/usr/include -Wall -g -O2 -MT ThriftTest_types.lo -MD -MP -MF 
.deps/ThriftTest_types.Tpo -c gen-cpp/ThriftTest_types.cpp  -fPIC -DPIC -o 
.libs/ThriftTest_types.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src 
-I/usr/include -Wall -g -O2 -MT ThriftTest_types.lo -MD -MP -MF 
.deps/ThriftTest_types.Tpo -c gen-cpp/ThriftTest_types.cpp -o 
ThriftTest_types.o >/dev/null 2>&1
mv -f .deps/ThriftTest_types.Tpo .deps/ThriftTest_types.Plo
/bin/bash ../../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../../.. -I../../../lib/cpp/src -I/usr/include  -Wall -g -O2 -MT 
ThriftTest_extras.lo -MD -MP -MF .deps/ThriftTest_extras.Tpo -c -o 
ThriftTest_extras.lo ThriftTest_extras.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src 
-I/usr/include -Wall -g -O2 -MT ThriftTest_extras.lo -MD -MP -MF 
.deps/ThriftTest_extras.Tpo -c ThriftTest_ext

[jira] [Closed] (THRIFT-1354) Add rake task to build just the gem file

2011-09-22 Thread Jake Farrell (JIRA) 

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

Jake Farrell closed THRIFT-1354.


   Resolution: Fixed
Fix Version/s: 0.8

committed

> Add rake task to build just the gem file
> 
>
> Key: THRIFT-1354
> URL: https://issues.apache.org/jira/browse/THRIFT-1354
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Jake Farrell
>Assignee: Jake Farrell
> Fix For: 0.8
>
> Attachments: thrift-1354.patch
>
>


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

[jira] [Updated] (THRIFT-1354) Add rake task to build just the gem file

2011-09-22 Thread Jake Farrell (JIRA) 

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

Jake Farrell updated THRIFT-1354:
-

Attachment: thrift-1354.patch

Updates ruby build to now build the gem by default and adds a rake task to 
create the gem

make = rake = rake gem

> Add rake task to build just the gem file
> 
>
> Key: THRIFT-1354
> URL: https://issues.apache.org/jira/browse/THRIFT-1354
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Jake Farrell
>Assignee: Jake Farrell
> Attachments: thrift-1354.patch
>
>


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

[jira] [Created] (THRIFT-1354) Add rake task to build just the gem file

2011-09-22 Thread Jake Farrell (JIRA) 
Add rake task to build just the gem file


 Key: THRIFT-1354
 URL: https://issues.apache.org/jira/browse/THRIFT-1354
 Project: Thrift
  Issue Type: New Feature
Reporter: Jake Farrell
Assignee: Jake Farrell




--
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 #267

2011-09-22 Thread Anthony Molinaro 
I think it might be erlang only being version R13B03.  Is R13B04 available
or else R14B03?

I only base this on finding an example of this type of error when searching
google.  It may also be that debian seems to split all the individual
applications that are normally installed out of the erlang core.  So there
may be another missing package.

I installed R13B04 on my Centos 5 box and jsx compiles fine with no
errors, so that's probably first thing to try if it's available.

-Anthony

On Thu, Sep 22, 2011 at 08:50:53AM +0200, ro...@bufferoverflow.ch wrote:
> It's not possible to login to the machine.
> I've created a build job to verify the build environment:
> https://builds.apache.org/view/S-Z/view/Thrift/job/Thrift-env-test/42/console
> 
> any hints?
> 
> -roger
> 
> Quoting Anthony Molinaro :
> 
> >I dunno, which version of erlang is installed, maybe there an issue if
> >its too old.  Is there a way to log into the build machine and try things
> >out?
> >
> >-Anthony
> >
> >On Wed, Sep 21, 2011 at 01:44:37AM +0200, ro...@bufferoverflow.ch wrote:
> >>git is now installed on the build server...but there's a new problem :-(
> >>
> >>---SNIP---
> >>./rebar get-deps
> >>==> erl (get-deps)
> >>Pulling jsx from
> >>{git,"git://github.com/talentdeficit/jsx.git",{tag,"v0.9.0"}}
> >>Initialized empty Git repository in 
> >>/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/lib/erl/deps/jsx/.git/
> >>==> nicefloats (get-deps)
> >>==> jsx (get-deps)
> >>./rebar compile
> >>==> nicefloats (compile)
> >>Compiled src/nicefloats.erl
> >>==> jsx (compile)
> >>./include/jsx_common.hrl:34: type jsx_opt() undefined
> >>./include/jsx_common.hrl:66: type jsx_parser_result() undefined
> >>./include/jsx_common.hrl:82: type eep0018_array() undefined
> >>./include/jsx_common.hrl:82: type eep0018_object() undefined
> >>./include/jsx_common.hrl:84: type eep0018_term() undefined
> >>./include/jsx_common.hrl:85: type eep0018_key() undefined
> >>./include/jsx_common.hrl:85: type eep0018_term() undefined
> >>./include/jsx_common.hrl:91: type eep0018_string() undefined
> >>./include/jsx_common.hrl:92: type eep0018_number() undefined
> >>./include/jsx_common.hrl:100: type encoder_opt() undefined
> >>./include/jsx_common.hrl:109: type decoder_opt() undefined
> >>./include/jsx_common.hrl:117: type verify_opt() undefined
> >>./include/jsx_common.hrl:123: type format_opt() undefined
> >>---SNIP---
> >>
> >>see https://builds.apache.org/view/S-Z/view/Thrift/job/Thrift/271/console
> >>
> >>any ideas? more dependencies for jsx?
> >>
> >>-roger
> >>
> >>
> >>
> >>Quoting ro...@bufferoverflow.ch:
> >>
> >>>I've sent a request to the build server admins.
> >>>Hope they install git very soon...
> >>>
> >>>-Roger
> >>>
> >>>Quoting Anthony Molinaro :
> >>>
> Hmm, is there any way to get a newer version of git on this server?
> 
> -Anthony
> 
> On Sep 17, 2011, at 10:09 PM, Apache Jenkins Server
>  wrote:
> 
> >See 
> >
> >Changes:
> >
> >[molinaro] THRIFT-1227 - erlang implementation of thrift json protocol
> >
> >--
> >[...truncated 784 lines...]
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:197]
> >64-bit constant "9223372036854775807" may not work in all
> >languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:204]
> >64-bit constant "9223372036854775807" may not work in all
> >languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:41]
> >64-bit constant "100" may not work in all languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:169]
> >64-bit constant "1099511627775" may not work in all languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:179]
> >64-bit constant "4294967295" may not work in all languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:179]
> >64-bit constant "1099511627775" may not work in all languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:179]
> >64-bit constant "281474976710655" may not work in all
> >languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:179]
> >64-bit constant "72057594037927935" may not work in all
> >languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:179]
> >64-bit constant "9223372036854775807" may not work in all
> >languages.
> >
> >[WARNING:/x1/jenkins/jenkins-slave/workspace/Thrift/thrift/test/DebugProtoTest.thrift:188]
> >64-bit constant "4294967295" may not work in a

[jira] [Commented] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser

2011-09-22 Thread Roger Meier (JIRA) 

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

Roger Meier commented on THRIFT-1353:
-

Hi Hans!

Thanks for bringing new ideas and bugfixes to Thrift Node.js implementation!

Could you please create a patch and grant License to ASF?
see: http://wiki.apache.org/thrift/HowToContribute

Another important topic are Unit Tests, see my comments on THRIFT-1261
do you have some?

I'm looking forward to commit patches for Node.js!

Thanks
roger


> Switch to performance branch, get rid of BinaryParser
> -
>
> Key: THRIFT-1353
> URL: https://issues.apache.org/jira/browse/THRIFT-1353
> Project: Thrift
>  Issue Type: Improvement
>  Components: Node.js - Library
>Affects Versions: 0.7
>Reporter: Hans Duedal
>  Labels: node, nodejs
> Fix For: 0.8
>
>
> I vote that the thrift library switches to the performance branch at 
> https://github.com/wadey/node-thrift/tree/performance
> I much prefer using the node.js buffers over the BinaryParser class, the 
> performance branch seems focused on this very issue. Also it includes the 
> excellent int64 implementation from broofa. What's not to like?

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

[jira] [Created] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser

2011-09-22 Thread Hans Duedal (JIRA) 
Switch to performance branch, get rid of BinaryParser
-

 Key: THRIFT-1353
 URL: https://issues.apache.org/jira/browse/THRIFT-1353
 Project: Thrift
  Issue Type: Improvement
  Components: Node.js - Library
Affects Versions: 0.7
Reporter: Hans Duedal
 Fix For: 0.8


I vote that the thrift library switches to the performance branch at 
https://github.com/wadey/node-thrift/tree/performance

I much prefer using the node.js buffers over the BinaryParser class, the 
performance branch seems focused on this very issue. Also it includes the 
excellent int64 implementation from broofa. What's not to like?

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

[jira] [Created] (THRIFT-1352) Thrift server

2011-09-22 Thread Hans Duedal (JIRA) 
Thrift server 
--

 Key: THRIFT-1352
 URL: https://issues.apache.org/jira/browse/THRIFT-1352
 Project: Thrift
  Issue Type: Improvement
  Components: Node.js - Library
Affects Versions: 0.7
Reporter: Hans Duedal
 Fix For: 0.8


If a thrift level protocol error occurs. For instance one makes a few changes 
to the thrift IDL file and a client connects using the old API an unhandled 
exception can be thrown from the TBinaryProtocol class. By adding a try-catch 
to the process() call these errors can be caught, the connection closed, and an 
error event emitted.

Likewise if a client closes the socket, ie. due to a timeout condition, another 
unhandled exception is thrown from stream.write().

Patch/Pull-request: https://github.com/wadey/node-thrift/pull/16


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

[jira] [Created] (THRIFT-1351) Compiler does not care about binary strings

2011-09-22 Thread Hans Duedal (JIRA) 
Compiler does not care about binary strings
---

 Key: THRIFT-1351
 URL: https://issues.apache.org/jira/browse/THRIFT-1351
 Project: Thrift
  Issue Type: Bug
  Components: Node.js - Compiler
Affects Versions: 0.7
Reporter: Hans Duedal
 Fix For: 0.8


The node.js lib has support for binary strings, but the compiler does not check 
for it.

It's quite easily fixed:
https://github.com/onlinecity/thrift/commit/1d86faa2f44c7b8db80595375d6bd0b9b678c0ee

With the fix node.js server implementations can operate on binary arguments.

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

[jira] [Commented] (THRIFT-582) C implementation of Thrift

2011-09-22 Thread JIRA 

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

Aurélien Revol commented on THRIFT-582:
---

Thanks for the info. It's good to know there's this option.

> C implementation of Thrift
> --
>
> Key: THRIFT-582
> URL: https://issues.apache.org/jira/browse/THRIFT-582
> Project: Thrift
>  Issue Type: New Feature
>  Components: C glib - Compiler, C glib - Library
>Reporter: David Reiss
>Assignee: Anatol Pomozov
>Priority: Minor
> Fix For: 0.6
>
> Attachments: c_glib_bindings.patch, t_c_generator.cc, 
> thrift_582_c_glib_bindings.patch, thrift_582_c_glib_bindings_20100927.patch, 
> thrift_582_c_glib_bindings_20101012.patch, 
> thrift_582_c_glib_bindings_20101026.patch
>
>
> Create a usable implementation of Thrift that uses only C at runtime, no C++. 
>  The code is at 
> http://svn.apache.org/repos/asf/incubator/thrift/branches/c-bindings/.

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

[jira] [Issue Comment Edited] (THRIFT-976) c_glib tutorial

2011-09-22 Thread JIRA 

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

Aurélien Revol edited comment on THRIFT-976 at 9/22/11 11:34 AM:
-

Hi all,

As I've been playing a bit with the c_glib library, I've managed to port some 
C++ client code to the Glib and get a half-working solution. There must be 
something wrong in my initialization code (directly translated from the C++ 
tutorial, to the Glib), since I can send requests, but not receive them. (It 
only works if I tweak the "len" variable in the "thrift_socket_read" function 
in "thrift_socket.c" while running in the debugger!)

I'm willing to contribute a port of the tutorial to the c_glib, provided 
somebody helps me correct the following initialization and cleanup code:

{code:title=c_glib_client.c|borderStyle=solid}
#include "protocol/thrift_protocol.h"
#include "protocol/thrift_binary_protocol.h"
#include "transport/thrift_buffered_transport.h"
#include "transport/thrift_transport.h"
#include "transport/thrift_socket.h"

#include "../gen-c_glib/calculator.h"

int main(int argc, char** argv) {
 ThriftSocket *tsocket;
 ThriftTransport *transport;
 ThriftProtocol *protocol;
 CalculatorClient *client;
 CalculatorIf *service;
 
 g_type_init();

 tsocket = THRIFT_SOCKET( g_object_new (THRIFT_TYPE_SOCKET,
"hostname", "localhost",
"port", 9090, 0) );
 transport = THRIFT_TRANSPORT( g_object_new (THRIFT_TYPE_BUFFERED_TRANSPORT,
 "transport", tsocket, 0) );
 protocol =  THRIFT_PROTOCOL ( g_object_new (THRIFT_TYPE_BINARY_PROTOCOL,
 "transport", transport, 0) );
 client =CALCULATOR_CLIENT( g_object_new(TYPE_CALCULATOR_CLIENT,
"input_protocol", protocol, /* 
??? */
"output_protocol", protocol,
0) );
 service = CALCULATOR_IF(client);

 thrift_transport_open(transport, 0);

/* Real user code here */

  thrift_transport_close(transport, 0);
  
  g_object_unref (client);
  g_object_unref (protocol);
  g_object_unref (transport);
  g_object_unref (tsocket);

  return 0;
}
{code}

(Sorry for spamming you with many edits: I was a bit too fast with the 
cut-and-paste from my sources.)

Thanks for any help!

  was (Author: arevol):
Hi all,

As I've been playing a bit with the c_glib library, I've managed to port some 
C++ client code to the Glib and get a half-working solution. There must be 
something wrong in my initialization code (directly translated from the C++ 
tutorial to the Glib), since I can send requests, but not receive them. (It 
only works if I tweak the "len" variable in the "thrift_socket_read" function 
in "thrift_socket.c" while running in the debugger!)

I'm willing to contribute a port of the tutorial to the c_glib, provided 
somebody helps me correct the following initialization and cleanup code:

{code:title=c_glib_client.c|borderStyle=solid}
#include "protocol/thrift_protocol.h"
#include "protocol/thrift_binary_protocol.h"
#include "transport/thrift_buffered_transport.h"
#include "transport/thrift_transport.h"
#include "transport/thrift_socket.h"

#include "../gen-c_glib/calculator.h"

int main(int argc, char** argv) {
 ThriftSocket *tsocket;
 ThriftTransport *transport;
 ThriftProtocol *protocol;
 CalculatorClient *client;
 CalculatorIf *service;
 
 g_type_init();

 tsocket = THRIFT_SOCKET( g_object_new (THRIFT_TYPE_SOCKET,
"hostname", "localhost",
"port", 9090, 0) );
 transport = THRIFT_TRANSPORT( g_object_new (THRIFT_TYPE_BUFFERED_TRANSPORT,
 "transport", tsocket, 0) );
 protocol =  THRIFT_PROTOCOL ( g_object_new (THRIFT_TYPE_BINARY_PROTOCOL,
 "transport", transport, 0) );
 client =CALCULATOR_CLIENT( g_object_new(TYPE_CALCULATOR_CLIENT,
"input_protocol", protocol, /* 
??? */
"output_protocol", protocol,
0) );
 service = CALCULATOR_IF(client);

 thrift_transport_open(transport, 0);

/* Real user code here */

  thrift_transport_close(m_transport, 0);
  
  g_object_unref (client);
  g_object_unref (protocol);
  g_object_unref (transport);
  g_object_unref (tsocket);

  return 0;
}
{code}

(Sorry for spamming you with edits: I was a bit too fast with the cut-and-paste 
from my sources.)

Thanks for any help!
  
> c_glib tutorial
> ---
>
> Key: THRIFT-976
> URL: https://issues.ap

[jira] [Issue Comment Edited] (THRIFT-976) c_glib tutorial

2011-09-22 Thread JIRA 

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

Aurélien Revol edited comment on THRIFT-976 at 9/22/11 11:31 AM:
-

Hi all,

As I've been playing a bit with the c_glib library, I've managed to port some 
C++ client code to the Glib and get a half-working solution. There must be 
something wrong in my initialization code (directly translated from the C++ 
tutorial to the Glib), since I can send requests, but not receive them. (It 
only works if I tweak the "len" variable in the "thrift_socket_read" function 
in "thrift_socket.c" while running in the debugger!)

I'm willing to contribute a port of the tutorial to the c_glib, provided 
somebody helps me correct the following initialization and cleanup code:

{code:title=c_glib_client.c|borderStyle=solid}
#include "protocol/thrift_protocol.h"
#include "protocol/thrift_binary_protocol.h"
#include "transport/thrift_buffered_transport.h"
#include "transport/thrift_transport.h"
#include "transport/thrift_socket.h"

#include "../gen-c_glib/calculator.h"

int main(int argc, char** argv) {
 ThriftSocket *tsocket;
 ThriftTransport *transport;
 ThriftProtocol *protocol;
 CalculatorClient *client;
 CalculatorIf *service;
 
 g_type_init();

 tsocket = THRIFT_SOCKET( g_object_new (THRIFT_TYPE_SOCKET,
"hostname", "localhost",
"port", 9090, 0) );
 transport = THRIFT_TRANSPORT( g_object_new (THRIFT_TYPE_BUFFERED_TRANSPORT,
 "transport", tsocket, 0) );
 protocol =  THRIFT_PROTOCOL ( g_object_new (THRIFT_TYPE_BINARY_PROTOCOL,
 "transport", transport, 0) );
 client =CALCULATOR_CLIENT( g_object_new(TYPE_CALCULATOR_CLIENT,
"input_protocol", protocol, /* 
??? */
"output_protocol", protocol,
0) );
 service = CALCULATOR_IF(client);

 thrift_transport_open(transport, 0);

/* Real user code here */

  thrift_transport_close(m_transport, 0);
  
  g_object_unref (client);
  g_object_unref (protocol);
  g_object_unref (transport);
  g_object_unref (tsocket);

  return 0;
}
{code}

(Sorry for spamming you with edits: I was a bit too fast with the cut-and-paste 
from my sources.)

Thanks for any help!

  was (Author: arevol):
Hi all,

As I've been playing a bit with the c_glib library, I've managed to port some 
C++ client code to the Glib and get a half-working solution. There must be 
something wrong in my initialization code (directly translated from the C++ 
tutorial to the Glib), since I can send requests, but not receive them. (It 
only works if I tweak the "len" variable in the "thrift_socket_read" function 
in "thrift_socket.c" while running in the debugger!)

I'm willing to contribute a port of the tutorial to the c_glib, provided 
somebody helps me with the following initialization and cleanup code:

{code:title=c_glib_client.c|borderStyle=solid}
#include "protocol/thrift_protocol.h"
#include "protocol/thrift_binary_protocol.h"
#include "transport/thrift_buffered_transport.h"
#include "transport/thrift_transport.h"
#include "transport/thrift_socket.h"

#include "../gen-c_glib/calculator.h"

int main(int argc, char** argv) {
 ThriftSocket *tsocket = THRIFT_SOCKET( g_object_new (THRIFT_TYPE_SOCKET,
"hostname", "localhost",
"port", 9090, 0) );
  ThriftTransport *transport = THRIFT_TRANSPORT( g_object_new 
(THRIFT_TYPE_BUFFERED_TRANSPORT,
 "transport", tsocket, 0) );
  ThriftProtocol *protocol = THRIFT_PROTOCOL ( g_object_new 
(THRIFT_TYPE_BINARY_PROTOCOL,
 "transport", transport, 0) );
  CalculatorClient *client = CALCULATOR_CLIENT( 
g_object_new(TYPE_CALCULATOR_CLIENT,
"input_protocol", protocol, /* 
??? */
"output_protocol", protocol,
0) );
  CalculatorIf *service = CALCULATOR_IF(client);

  thrift_transport_open(transport, 0);

/* Real user code here */

  thrift_transport_close(m_transport, 0);
  
  g_object_unref (client);
  g_object_unref (protocol);
  g_object_unref (transport);
  g_object_unref (tsocket);

  return 0;
}
{code}

Thanks for any help!
  
> c_glib tutorial
> ---
>
> Key: THRIFT-976
> URL: https://issues.apache.org/jira/browse/THRIFT-976
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Compiler, C glib - Library, Tutorial
>

[jira] [Issue Comment Edited] (THRIFT-976) c_glib tutorial

2011-09-22 Thread JIRA 

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

Aurélien Revol edited comment on THRIFT-976 at 9/22/11 11:08 AM:
-

Hi all,

As I've been playing a bit with the c_glib library, I've managed to port some 
C++ client code to the Glib and get a half-working solution. There must be 
something wrong in my initialization code (directly translated from the C++ 
tutorial to the Glib), since I can send requests, but not receive them. (It 
only works if I tweak the "len" variable in the "thrift_socket_read" function 
in "thrift_socket.c" while running in the debugger!)

I'm willing to contribute a port of the tutorial to the c_glib, provided 
somebody helps me with the following initialization and cleanup code:

{code:title=c_glib_client.c|borderStyle=solid}
#include "protocol/thrift_protocol.h"
#include "protocol/thrift_binary_protocol.h"
#include "transport/thrift_buffered_transport.h"
#include "transport/thrift_transport.h"
#include "transport/thrift_socket.h"

#include "../gen-c_glib/calculator.h"

int main(int argc, char** argv) {
 ThriftSocket *tsocket = THRIFT_SOCKET( g_object_new (THRIFT_TYPE_SOCKET,
"hostname", "localhost",
"port", 9090, 0) );
  ThriftTransport *transport = THRIFT_TRANSPORT( g_object_new 
(THRIFT_TYPE_BUFFERED_TRANSPORT,
 "transport", tsocket, 0) );
  ThriftProtocol *protocol = THRIFT_PROTOCOL ( g_object_new 
(THRIFT_TYPE_BINARY_PROTOCOL,
 "transport", transport, 0) );
  CalculatorClient *client = CALCULATOR_CLIENT( 
g_object_new(TYPE_CALCULATOR_CLIENT,
"input_protocol", protocol, /* 
??? */
"output_protocol", protocol,
0) );
  CalculatorIf *service = CALCULATOR_IF(client);

  thrift_transport_open(transport, 0);

/* Real user code here */

  thrift_transport_close(m_transport, 0);
  
  g_object_unref (client);
  g_object_unref (protocol);
  g_object_unref (transport);
  g_object_unref (tsocket);

  return 0;
}
{code}

Thanks for any help!

  was (Author: arevol):
Hi all,

As I've been playing a bit with the c_glib library, I've managed to port some 
C++ client code to the Glib and get a half-working solution. There must be 
something wrong in my initialization code (directly translated from the C++ 
tutorial to the Glib), since I can send requests, but not receive them. (It 
only works if I tweak the "len" variable in the "thrift_socket_read" function 
in "thrift_socket.c" while running in the debugger!)

I'm willing to contribute a port of the tutorial to the c_glib, provided 
somebody helps me with the following initialization and cleanup code:

{code:title=c_glib_client.c|borderStyle=solid}
#include "protocol/thrift_protocol.h"
#include "protocol/thrift_binary_protocol.h"
#include "transport/thrift_buffered_transport.h"
#include "transport/thrift_transport.h"
#include "transport/thrift_socket.h"

#include "../gen-c_glib/calculator.h"

int main(int argc, char** argv) {
 ThriftSocket *tsocket = THRIFT_SOCKET( g_object_new (THRIFT_TYPE_SOCKET,
"hostname", "localhost",
"port", 9090, 0) );
  ThriftTransport *transport = THRIFT_TRANSPORT( g_object_new 
(THRIFT_TYPE_BUFFERED_TRANSPORT,
 "transport", tsocket, 0) );
  ThriftProtocol *protocol = THRIFT_PROTOCOL ( g_object_new 
(THRIFT_TYPE_BINARY_PROTOCOL,
 "transport", transport, 0) );
  CalculatorClient *client = CALCULATOR_CLIENT( 
g_object_new(TYPE_CALCULATOR_CLIENT,
"input_protocol", protocol, /* 
??? */
"output_protocol", protocol,
0) );
  CalculatorIf *service = CALCULATOR_IF(client);

  thrift_transport_open(transport, 0);

/* Real user code here */

  thrift_transport_close(m_transport, 0);
  
  g_object_unref (client);
  g_object_unref (protocol);
  g_object_unref (transport);
  g_object_unref (tsocket);
}
{code}

Thanks for any help!
  
> c_glib tutorial
> ---
>
> Key: THRIFT-976
> URL: https://issues.apache.org/jira/browse/THRIFT-976
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Compiler, C glib - Library, Tutorial
>Reporter: Roger Meier
>Assignee: Michael Lum
>Priority: Minor
>
> It would be great to have a tutorial for the brand new c_glib library.

--
This message

[jira] [Commented] (THRIFT-976) c_glib tutorial

2011-09-22 Thread JIRA 

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

Aurélien Revol commented on THRIFT-976:
---

Hi all,

As I've been playing a bit with the c_glib library, I've managed to port some 
C++ client code to the Glib and get a half-working solution. There must be 
something wrong in my initialization code (directly translated from the C++ 
tutorial to the Glib), since I can send requests, but not receive them. (It 
only works if I tweak the "len" variable in the "thrift_socket_read" function 
in "thrift_socket.c" while running in the debugger!)

I'm willing to contribute a port of the tutorial to the c_glib, provided 
somebody helps me with the following initialization and cleanup code:

{code:title=c_glib_client.c|borderStyle=solid}
#include "protocol/thrift_protocol.h"
#include "protocol/thrift_binary_protocol.h"
#include "transport/thrift_buffered_transport.h"
#include "transport/thrift_transport.h"
#include "transport/thrift_socket.h"

#include "../gen-c_glib/calculator.h"

int main(int argc, char** argv) {
 ThriftSocket *tsocket = THRIFT_SOCKET( g_object_new (THRIFT_TYPE_SOCKET,
"hostname", "localhost",
"port", 9090, 0) );
  ThriftTransport *transport = THRIFT_TRANSPORT( g_object_new 
(THRIFT_TYPE_BUFFERED_TRANSPORT,
 "transport", tsocket, 0) );
  ThriftProtocol *protocol = THRIFT_PROTOCOL ( g_object_new 
(THRIFT_TYPE_BINARY_PROTOCOL,
 "transport", transport, 0) );
  CalculatorClient *client = CALCULATOR_CLIENT( 
g_object_new(TYPE_CALCULATOR_CLIENT,
"input_protocol", protocol, /* 
??? */
"output_protocol", protocol,
0) );
  CalculatorIf *service = CALCULATOR_IF(client);

  thrift_transport_open(transport, 0);

/* Real user code here */

  thrift_transport_close(m_transport, 0);
  
  g_object_unref (client);
  g_object_unref (protocol);
  g_object_unref (transport);
  g_object_unref (tsocket);
}
{code}

Thanks for any help!

> c_glib tutorial
> ---
>
> Key: THRIFT-976
> URL: https://issues.apache.org/jira/browse/THRIFT-976
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Compiler, C glib - Library, Tutorial
>Reporter: Roger Meier
>Assignee: Michael Lum
>Priority: Minor
>
> It would be great to have a tutorial for the brand new c_glib library.

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