[jira] [Commented] (THRIFT-984) ocaml: add version Info to the library
[ https://issues.apache.org/jira/browse/THRIFT-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611966#comment-13611966 ] Jake Farrell commented on THRIFT-984: - I'm not very familiar with ocaml, but looking into this we should be able to add an _oasis file in the lib/ocaml folder and it should work with contents something like the following. If someone can verify that this is good i'll add to the release process Name:libthrift-ocaml Version: 1.0 OASISFormat: 0.3.0 Synopsis:OCaml bindings for the Apache Thrift RPC system Authors: Apache Thrift Developers License: Apache-2.0 Homepage:http://thrift.apache.org Library "libthrift-ocaml" Path: src > ocaml: add version Info to the library > -- > > Key: THRIFT-984 > URL: https://issues.apache.org/jira/browse/THRIFT-984 > Project: Thrift > Issue Type: Sub-task > Components: OCaml - Library >Reporter: Roger Meier > > add version info to the library and update > http://wiki.apache.org/thrift/HowToVersion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1828) moc_TQTcpServer.cpp was removed from source tree but is in thrift-0.9.0.tar.gz
[ https://issues.apache.org/jira/browse/THRIFT-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611949#comment-13611949 ] Jake Farrell commented on THRIFT-1828: -- the cpp libraries Makefile under libthriftqt_la_SOURCES includes libthriftqt_la_MOC which contains the moc_TQTcpServer.cpp file. All sources defined are included in the distribution when making a release which is how the moc file is getting included. initial thought would be to add the moc generation to .PHONY to force run every time > moc_TQTcpServer.cpp was removed from source tree but is in thrift-0.9.0.tar.gz > -- > > Key: THRIFT-1828 > URL: https://issues.apache.org/jira/browse/THRIFT-1828 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: CentOS 6.3 w/Qt 4.6.2 >Reporter: David Rennalls >Priority: Minor > > When attempting to build the the 0.9.0 cpp library I get the following error > ... > src/thrift/qt/moc_TQTcpServer.cpp:14:2: error: #error "This file was > generated using the moc from 4.8.1. It" > src/thrift/qt/moc_TQTcpServer.cpp:15:2: error: #error "cannot be used with > the include files from this version of Qt." > src/thrift/qt/moc_TQTcpServer.cpp:16:2: error: #error "(The moc has changed > too much.)" > ... > As far as I can tell when the C++ QT Bindings were added (see > https://issues.apache.org/jira/browse/THRIFT-1348) that file was removed > since it was an auto-generated file and shouldn't be in source control. > However although it's no longer in the source tree it's being included in the > release .tar.gz > [/tmp]$ wget -q > https://dist.apache.org/repos/dist/release/thrift/0.9.0/thrift-0.9.0.tar.gz > -O - | tar tzvf - | grep moc_ > -rw-r--r-- root/root 3311 2012-10-11 21:00 > thrift-0.9.0/lib/cpp/src/thrift/qt/moc_TQTcpServer.cpp > So if the version of Qt that's installed when building is different than the > one used to generate the file in the release .tar.gz the build will break. > Another user seems to have run into this as well, see > http://mail-archives.apache.org/mod_mbox/thrift-user/201212.mbox/%3C002f01cdd2aa$c7f3a840$57daf8c0$@asiainfo-linkage.com%3E > As a workaround I have to either remove the file before building or specify > --with-qt4=no -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (THRIFT-1828) moc_TQTcpServer.cpp was removed from source tree but is in thrift-0.9.0.tar.gz
[ https://issues.apache.org/jira/browse/THRIFT-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell reassigned THRIFT-1828: Assignee: Jake Farrell > moc_TQTcpServer.cpp was removed from source tree but is in thrift-0.9.0.tar.gz > -- > > Key: THRIFT-1828 > URL: https://issues.apache.org/jira/browse/THRIFT-1828 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: CentOS 6.3 w/Qt 4.6.2 >Reporter: David Rennalls >Assignee: Jake Farrell >Priority: Minor > > When attempting to build the the 0.9.0 cpp library I get the following error > ... > src/thrift/qt/moc_TQTcpServer.cpp:14:2: error: #error "This file was > generated using the moc from 4.8.1. It" > src/thrift/qt/moc_TQTcpServer.cpp:15:2: error: #error "cannot be used with > the include files from this version of Qt." > src/thrift/qt/moc_TQTcpServer.cpp:16:2: error: #error "(The moc has changed > too much.)" > ... > As far as I can tell when the C++ QT Bindings were added (see > https://issues.apache.org/jira/browse/THRIFT-1348) that file was removed > since it was an auto-generated file and shouldn't be in source control. > However although it's no longer in the source tree it's being included in the > release .tar.gz > [/tmp]$ wget -q > https://dist.apache.org/repos/dist/release/thrift/0.9.0/thrift-0.9.0.tar.gz > -O - | tar tzvf - | grep moc_ > -rw-r--r-- root/root 3311 2012-10-11 21:00 > thrift-0.9.0/lib/cpp/src/thrift/qt/moc_TQTcpServer.cpp > So if the version of Qt that's installed when building is different than the > one used to generate the file in the release .tar.gz the build will break. > Another user seems to have run into this as well, see > http://mail-archives.apache.org/mod_mbox/thrift-user/201212.mbox/%3C002f01cdd2aa$c7f3a840$57daf8c0$@asiainfo-linkage.com%3E > As a workaround I have to either remove the file before building or specify > --with-qt4=no -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1882) Use single include
[ https://issues.apache.org/jira/browse/THRIFT-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611939#comment-13611939 ] Jake Farrell commented on THRIFT-1882: -- Hi Evan, thanks for the work on this patch. we currently do not accept patches via github, can you please attach your patch to this ticket using the "More Actions > Attach Files" from the menu above. Please see http://thrift.apache.org/docs/HowToContribute/ and if you have any questions glad to answer. > Use single include > -- > > Key: THRIFT-1882 > URL: https://issues.apache.org/jira/browse/THRIFT-1882 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Reporter: Evan Nemerson >Priority: Minor > > Currently, when using thrift_c_glib you have to include several headers. It > would be nice if you could just include a single header, which would then > include the other headers for you. Most projects I'm aware of, particularly > those based on glib and gobject like thrift_c_glib is, use this method > exclusively. It offers more flexibility by allowing the library to > occasionally reorganize its headers and is much easier for consumers to deal > with. Note this is particularly important for Vala bindings which are not > distributed with the library they bind > (https://live.gnome.org/Vala/UpstreamGuide#C_Headers). > I've created a patch which will have thrift/c_glib/thrift.h include all other > necessary headers, and issue a warning if headers other than > thrift/c_glib/thrift.h are included. This touches the compiler as well, but > I think the library component is a more appropriate place for the bug. > I don't see anywhere to actually attach a patch (maybe it's coming after I > click "Create"), so if nothing else you can find the patch here: > https://github.com/nemequ/thrift/commit/a24b256c62ea65890f19f4a93f582ee6c35da53c -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1823) Missing parenthesis breaks "IS_..." macro in generated code
[ https://issues.apache.org/jira/browse/THRIFT-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-1823. Resolution: Fixed Fix Version/s: 1.0 Assignee: Simon South Thanks for the patch, committed > Missing parenthesis breaks "IS_..." macro in generated code > --- > > Key: THRIFT-1823 > URL: https://issues.apache.org/jira/browse/THRIFT-1823 > Project: Thrift > Issue Type: Bug > Components: C glib - Compiler >Affects Versions: 0.9 > Environment: CentOS 6.3 on x86 (32-bit) >Reporter: Simon South >Assignee: Simon South >Priority: Minor > Fix For: 1.0 > > Attachments: thrift-1823-generate-is-macro-correctly.patch > > > A missing parenthesis in the generated header file for a service interface > breaks the "IS_..." macro, making client code that uses it fail to compile > with messages like > hello_world_processor.c:41:59: error: macro "G_TYPE_CHECK_INSTANCE_TYPE" > requires 2 arguments, but only 1 given > hello_world_processor.c:101:1: error: unterminated argument list invoking > macro "G_LIKELY" > In file included from /usr/include/glib-2.0/glib.h:79, >from /usr/include/glib-2.0/gobject/gtype.h:26, >from /usr/include/glib-2.0/gobject/gboxed.h:26, >from /usr/include/glib-2.0/glib-object.h:25, >from hello_world_processor.h:4, >from hello_world_processor.c:1: > I'll attach a patch with the fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1756) 'make -j 8' fails with "unterminated #ifdef" error
[
https://issues.apache.org/jira/browse/THRIFT-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell closed THRIFT-1756.
Resolution: Cannot Reproduce
Fix Version/s: 1.0
Using the latest version of mountain lion and xcode i am not able to reproduce
the error compiling the cpp lib or test cases. All compile fine with 'make -j 8'
> 'make -j 8' fails with "unterminated #ifdef" error
> --
>
> Key: THRIFT-1756
> URL: https://issues.apache.org/jira/browse/THRIFT-1756
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.9
> Environment: OSX 10.7.4
>Reporter: Vitali Lovich
>Assignee: Jake Farrell
> Fix For: 1.0
>
> Attachments: thrift.log
>
>
> If I run 'make' in 1 thread Thrift builds fine. But if I clean&run it with 16
> threads the build process fails almost constantly with following error
> {noformat}
> g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src -I/usr/include
> -Wall -g -O2 -MT Benchmark.o -MD -MP -MF .deps/Benchmark.Tpo -c -o
> Benchmark.o Benchmark.cpp
> /bin/sh ../../../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
> /bin/sh ../../../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 DebugProtoTest_extras.lo -MD -MP -MF
> .deps/DebugProtoTest_extras.Tpo -c DebugProtoTest_extras.cpp -fPIC -DPIC -o
> .libs/DebugProtoTest_extras.o
> /bin/sh ../../../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 OptionalRequiredTest_types.lo -MD -MP -MF
> .deps/OptionalRequiredTest_types.Tpo -c
> gen-cpp/OptionalRequiredTest_types.cpp -fPIC -DPIC -o
> .libs/OptionalRequiredTest_types.o
> In file included from DebugProtoTest_extras.cpp:22:
> gen-cpp/DebugProtoTest_types.h:6:1: error: unterminated #ifndef
> 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_extras.cpp -fPIC -DPIC -o
> .libs/ThriftTest_extras.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 -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 DebugProtoTest_types.lo -MD -MP -MF
> .deps/DebugProtoTest_types.Tpo -c gen-cpp/DebugProtoTest_types.cpp -fPIC
> -DPIC -o .libs/DebugProtoTest_types.o
> DebugProtoTest_extras.cpp:27: error: definition of 'bool
> thrift::test::debug::Empty::operator<(const thrift::test::debug::Empty&)
> const' is not in namespace enclosing 'thrift::test::debug::Empty'
> DebugProtoTest_extras.cpp:33: error: expected '}' at end of input
> DebugProtoTest_extras.cpp:33: error: expected '}' at end of input
> DebugProtoTest_extras.cpp:33: error: expected '}' at end of input
> make[4]: *** [DebugProtoTest_extras.lo] Error 1
> make[4]: *** Waiting for unfinished jobs
> {noformat}
> The file ./lib/cpp/test/gen-cpp/DebugProtoTest_types.h looks ok. Now if I run
> 'make -j 16' once again - everything builds fine.
> It makes me think that this is a concurrency issue in Makefiles. My only
> guess is this is some undeclared dependency. It looks like
> DebugProtoTest_extras.cpp started building before
> gen-cpp/DebugProtoTest_types.h generation ended.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1804) Binary+compact protocol single byte error in Ruby library (ARM architecture): caused by different char signedness
[
https://issues.apache.org/jira/browse/THRIFT-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell closed THRIFT-1804.
Resolution: Fixed
Fix Version/s: 1.0
Assignee: Elias Karakoulakis
Thanks for the patch, committed
> Binary+compact protocol single byte error in Ruby library (ARM architecture):
> caused by different char signedness
> -
>
> Key: THRIFT-1804
> URL: https://issues.apache.org/jira/browse/THRIFT-1804
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, Ruby - Library
>Affects Versions: 0.9
> Environment: - Debian/ARM Squeeze 6.0.6 native armv5te, compiler: gcc
> (Debian 4.4.5-8) 4.4.5
> QEMU emulated debian hosts:
> - Debian Squeeze 6.0.6 emulated armvtejl, compiler: gcc (Debian 4.4.5-8)
> - Debian Sid 7.0 on QEMU ARM versatilepb, compiler: gcc (Debian 4.6.3-14)
>Reporter: Elias Karakoulakis
>Assignee: Elias Karakoulakis
> Fix For: 1.0
>
> Attachments: THRIFT1804.patch
>
>
> These compilation tests fail when compiling for ARM:
> 1) BinaryProtocolAccelerated it should behave like a binary protocol should
> read a byte
> Failure/Error: @prot.read_byte.should == i
>{*}expected: -128{*}
> {*}got: 128 (using ==){*}
> Shared Example Group: "a binary protocol" called from
> ./spec/binary_protocol_accelerated_spec.rb:28
> # ./spec/binary_protocol_spec_shared.rb:291:in `block (3 levels) in (required)>'
> # ./spec/binary_protocol_spec_shared.rb:289:in `each'
> # ./spec/binary_protocol_spec_shared.rb:289:in `block (2 levels) in (required)>'
> 2) BinaryProtocolAccelerated it should behave like a binary protocol should
> perform a complete rpc with a struct return type
> Failure/Error: result.should == Fixtures::COMPACT_PROTOCOL_TEST_STRUCT
>expected: 127]{*},
> got: 127]{*}, ... (using ==)
> (***) only byte_list gets corrupted
> Shared Example Group: "a binary protocol" called from
> ./spec/binary_protocol_accelerated_spec.rb:28
> # ./spec/binary_protocol_spec_shared.rb:375:in `block (3 levels) in (required)>'
> # ./spec/binary_protocol_spec_shared.rb:406:in `call'
> # ./spec/binary_protocol_spec_shared.rb:406:in `srv_test'
> # ./spec/binary_protocol_spec_shared.rb:370:in `block (2 levels) in (required)>'
> 3) Thrift::CompactProtocol should encode and decode naked primitives
> correctly
> Failure/Error: read_back.should == value
>{*}expected: -127{*}
> {*}got: 129 (using ==){*}
> # ./spec/compact_protocol_spec.rb:45:in `block (4 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:37:in `each'
> # ./spec/compact_protocol_spec.rb:37:in `block (3 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:36:in `each_pair'
> # ./spec/compact_protocol_spec.rb:36:in `block (2 levels) in (required)>'
> 4) Thrift::CompactProtocol should encode and decode primitives in fields
> correctly
> Failure/Error: read_back.should == value
>{*}expected: -127{*}
> {*}got: 129 (using ==){*}
> # ./spec/compact_protocol_spec.rb:68:in `block (4 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:55:in `each'
> # ./spec/compact_protocol_spec.rb:55:in `block (3 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:51:in `each_pair'
> # ./spec/compact_protocol_spec.rb:51:in `block (2 levels) in (required)>'
> Finished in 5.87 seconds
> 364 examples, 4 failures, 1 pending
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1778) Configure requires manual intervention due to tar failure
[ https://issues.apache.org/jira/browse/THRIFT-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-1778. Resolution: Not A Problem Fix Version/s: 1.0 Using bsdtar should resolve this problem for you or switch configure.ac to AM_INIT_AUTOMAKE([1.9 tar-ustar]) to AM_INIT_AUTOMAKE([1.9 tar-pax]) > Configure requires manual intervention due to tar failure > - > > Key: THRIFT-1778 > URL: https://issues.apache.org/jira/browse/THRIFT-1778 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.8, 0.9 > Environment: Fedora 16 >Reporter: Bill Katz >Assignee: Jake Farrell > Fix For: 1.0 > > > On configure, manual intervention is required where pax is unable to identify > the format and user must enter "." to quit pax. Problem is upstream in > configure file. Here is pertinent snippet from config.log: > configure:3482: $? = 0 > configure:3522: tardir=conftest.dir && eval tar --format=ustar -chf - > "$tardir" >conftest.tar > tar: value 9900322 out of uid_t range 0..2097151 > tar: Exiting with failure status due to previous errors > This issue was noted in some other software as well: > http://pl.digipedia.org/usenet/thread/11269/17209/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1715) Allow excluding python parts when building contrib/fb303
[ https://issues.apache.org/jira/browse/THRIFT-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-1715. Resolution: Fixed Fix Version/s: 1.0 Assignee: Jake Farrell Updated patch to include php and java and added following output to configure Building C++ Library . : yes Building Java Library : yes Building Python Library .. : yes Building PHP Library . : yes > Allow excluding python parts when building contrib/fb303 > > > Key: THRIFT-1715 > URL: https://issues.apache.org/jira/browse/THRIFT-1715 > Project: Thrift > Issue Type: Improvement > Components: Build Process >Affects Versions: 0.8 >Reporter: Harsh J >Assignee: Jake Farrell >Priority: Trivial > Labels: fb303 > Fix For: 1.0 > > Attachments: > 0001-THRIFT-1715.-Allow-excluding-python-parts-when-build.patch > > > Right now, the py/ sources are always compiled and installed when building > the contrib/fb303 module. This ought to be optional like the main build is. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-930) Ruby and Haskell bindings don't properly support DESTDIR (makes packaging painful)
[ https://issues.apache.org/jira/browse/THRIFT-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-930. --- Resolution: Fixed Fix Version/s: 1.0 Assignee: Jake Farrell (was: Christian Lavoie) Closing as gem install will place in correct location > Ruby and Haskell bindings don't properly support DESTDIR (makes packaging > painful) > -- > > Key: THRIFT-930 > URL: https://issues.apache.org/jira/browse/THRIFT-930 > Project: Thrift > Issue Type: Bug > Components: Haskell - Library, Ruby - Library >Reporter: Christian Lavoie >Assignee: Jake Farrell > Fix For: 1.0 > > > Anthony Molinar has this to say on a different thread: > """One thing which is likely an issue to be addressed at some point is that I > doubt 'make DESTDIR=/tmp install' will work, so people packaging with rpm/deb > will most likely have to disable haskell until that is fixed, but not a big > enough deal to stop inclusion (besides ruby also has this problem).""" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-986) st: add version Info to the library
[ https://issues.apache.org/jira/browse/THRIFT-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-986. --- Resolution: Fixed Fix Version/s: 1.0 Assignee: Jake Farrell Added a package.xml file containing a version within the header comments. Smalltalk packages have no concept of versions within the package.xml > st: add version Info to the library > --- > > Key: THRIFT-986 > URL: https://issues.apache.org/jira/browse/THRIFT-986 > Project: Thrift > Issue Type: Sub-task > Components: Smalltalk - Library >Reporter: Roger Meier >Assignee: Jake Farrell > Fix For: 1.0 > > > add version info to the library and update > http://wiki.apache.org/thrift/HowToVersion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1859) Generated error c++ code with -out and include_prefix param
[ https://issues.apache.org/jira/browse/THRIFT-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-1859. Resolution: Fixed Fix Version/s: 1.0 Modified patch to fix const error and committed. > Generated error c++ code with -out and include_prefix param > --- > > Key: THRIFT-1859 > URL: https://issues.apache.org/jira/browse/THRIFT-1859 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9 > Environment: Linux, x86-64 >Reporter: CHEN Feng >Priority: Critical > Fix For: 1.0 > > Attachments: > thrift-1859-fix-cpp-include-path-when-include-prefix-is-on-and-out-option-is-specified.patch > > > thrift -gen cpp:include_prefix -out test_thrift test_thrift/tutorial.thrift > the files are generated in test_thrift, without the gen-cpp dir > but the content of generated files are error: > #include "test_thrift/gen-cpp/Calculator.h" > the --help said: > -out dirSet the ouput location for generated files. >(no gen-* folder will be created) > So, the 'gen-cpp' should be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1614) Thrift build from svn repo sources fails with automake-1.12
[ https://issues.apache.org/jira/browse/THRIFT-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-1614. Resolution: Fixed Fix Version/s: 1.0 > Thrift build from svn repo sources fails with automake-1.12 > --- > > Key: THRIFT-1614 > URL: https://issues.apache.org/jira/browse/THRIFT-1614 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.9 > Environment: Reproduced on OS X 10.7 with homebrew automake-1.12 >Reporter: Andrew Cox >Assignee: Jake Farrell > Fix For: 1.0 > > Attachments: thrift-1614-automake-yacc-naming.patch > > > The yacc.am included in automake-1.12 creates the file "thrifty.hh" instead > of "thrifty.h", but the generated file "thriftl.cc" includes "thrifty.h". > Problem goes away when I downgrade automake to 1.11.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-563) Support for Multiplexing Services on any Transport, Protocol and Server
[
https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611910#comment-13611910
]
Randy Abernethy commented on THRIFT-563:
Hi Jens, I agree with the patch. I think the model is good and I will use/test
it if committed.
> Support for Multiplexing Services on any Transport, Protocol and Server
> ---
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Library
>Reporter: Rob Slifka
> Attachments: multiplex_c++.tar, multiplex.py, THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among
> (at least) three languages. To keep maintainability high, we hope to avoid a
> single service defined with a large number of functions. This would require
> monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base
> classes, which provides more flexibility in the object-oriented design of our
> server platform.
> Before our changes, the alternative was to open up additional ports with
> smaller service implementations on each. We'd rather not open additional
> ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}}
> implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator
> around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates
> any {{TProtocol}} by modifying the behaviour of
> {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from
> {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used
> to communicate with a client that was written using {{TMultiplexedProtocol}}.
> It removes {{service_name + separator}} from {{TMessage.name}}, turning it
> back into the standard message format. It then brokers the service request
> to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services:
> {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol,
> "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-563) Support for Multiplexing Services on any Transport, Protocol and Server
[
https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611775#comment-13611775
]
Jens Geyer commented on THRIFT-563:
---
Randy,
does that read "I agree with the patch"?
Patrick,
could you please make a patch out of it?
> Support for Multiplexing Services on any Transport, Protocol and Server
> ---
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Library
>Reporter: Rob Slifka
> Attachments: multiplex_c++.tar, multiplex.py, THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among
> (at least) three languages. To keep maintainability high, we hope to avoid a
> single service defined with a large number of functions. This would require
> monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base
> classes, which provides more flexibility in the object-oriented design of our
> server platform.
> Before our changes, the alternative was to open up additional ports with
> smaller service implementations on each. We'd rather not open additional
> ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}}
> implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator
> around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates
> any {{TProtocol}} by modifying the behaviour of
> {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from
> {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used
> to communicate with a client that was written using {{TMultiplexedProtocol}}.
> It removes {{service_name + separator}} from {{TMessage.name}}, turning it
> back into the standard message format. It then brokers the service request
> to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services:
> {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol,
> "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (THRIFT-1878) Add the possibility to send custom headers
[ https://issues.apache.org/jira/browse/THRIFT-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Meier resolved THRIFT-1878. - Resolution: Fixed Assignee: Roger Meier committed > Add the possibility to send custom headers > -- > > Key: THRIFT-1878 > URL: https://issues.apache.org/jira/browse/THRIFT-1878 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.9 >Reporter: Laurent Sarrazin >Assignee: Roger Meier >Priority: Minor > Labels: patch > Fix For: 1.0 > > Attachments: thrift-0.9.0-add-headers.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Incompatible API changes for c_glib
On 22/03/13 07:04 PM, Evan Nemerson wrote: If anyone is using c_glib, please speak up! I'm here---I'm eyeing Thrift for a project in C and have been slowly working on finishing c_glib's server support ( https://github.com/simonsouth/thrift), learning GLib as I go. I have no issues with the changes Evan is proposing and would be willing to help out; just wanted to identify myself as someone else working with this code. -- *Simon South* sso...@simonsouth.com
