First off, I think we should stick with the current compiler for a while. I think its quicker to package up the compiler for a few platforms, and look at some of the patches that have been made available for building thrift with visual studio.
If some folks want to start a branch and work on a java compiler that's great, go for it, I'd say either a git fork of the thrift git mirror or if you have commit access put it in a branch of svn (or even in compiler/java, just leave it disabled by default). When its as complete as the current compiler a decision can be made which to use. However, something to think about is right now there are 49 open issues for java and 41 for C++, and 252 open issues on the jira. Before we add to those issues with a completely new compiler, maybe we should get the current list down to a manageable level? And I'd like to see more tests tied into make check for more languages. I don't think we even have basic functionality. I figured out last night while working on a minor issue with the erlang framed transport that the test/erl/Makefile doesn't even compile the test files and the test files are never run. I'll be working on getting some eunit tests tied into the make check call. So I guess it summary, while I like the passion this conversation has created in the community (longest thread in the past year as far as I can tell), I think the energy has to be put into getting the current system as solid as possible before working too much on a new system. The project seems to be at a tipping point now, where it is being prodded to work through its issues and hopefully graduate out of incubator status soon. I think that a new compiler would lead to a division of energy and a major setback in this area. After the project has graduated and hit '1.0' then I'd think this could be revisited. Just my 2 cents, -Anthony On Fri, Aug 27, 2010 at 07:40:25AM -0700, Bryan Duxbury wrote: > An alternative would be to have unit tests that cover the basic > functionality of each of the languages' generated code and make sure those > keep passing. (I think we should already have these tests, but I don't > expect anyone to jump up to make them.) > > On Thu, Aug 26, 2010 at 6:41 PM, Todd Lipcon <[email protected]> wrote: > > > On Thu, Aug 26, 2010 at 6:33 PM, Greg Stein <[email protected]> wrote: > > > > > ASN.1, huh? I clicked that link. Couldn't find an overview link. > > > "Papers" and "presentations" and "consortium members" and all that. > > > > > > Wikipedia has a more reasonable introduction. All those consortia > > > members should learn from that, rather than worrying about their > > > "international standard". :-P > > > > > > That said, ASN.1 is about both description and on-wire formats. If > > > Thrift used ASN as the descriptive language, then people might think > > > it also uses the same wire format. And ASN.1 might not have things > > > like field tag numbers, needed by Thrift. > > > > > > I don't think we're talking about a new IDL here. Just the technology > > > to convert those into compilable runtimes. > > > > > > > > Yes, any incompatible change in IDL would be hugely awful. > > > > If we plan to experiment with switching the compiler to a different > > language, the acceptance test should be that it can take any thrift file > > and > > generate hashwise identical code for all of the currently supported > > languages. > > > > -Todd > > > > > > > > > Cheers, > > > -g > > > > > > On Thu, Aug 26, 2010 at 21:22, Roger Meier <[email protected]> > > > wrote: > > > > talking about interface descriptions and languages to build to > > compiler. > > > > > > > > What about ASN.1 (http://www.asn1.org/) as a discription language or > > pre > > > > format? > > > > > > > > Does somebody have a ASN.1 to Thrift compiler ? > > > > > > > > Of course there might be some gaps, but what about that? > > > > > > > > > > > > Am 26.08.2010 22:54, schrieb Bjorn Borud: > > > >> > > > >> on the project I currently work on we have a (ANTLR-based) parser for > > > >> the Thrift IDL language in order to generate code for a proprietary > > > >> serialization library. > > > >> > > > >> it struck me that perhaps we could use this parser the implement the > > > >> Thrift compiler in Java instead. this would mean that the thrift > > > >> compiler itself could be built as a platform independent artifact -- > > > >> which should make it a lot more elegant to write Maven plugins for > > > >> Thrift. it would also eliminate the need (for us) to maintain Thrift > > > >> compiler binaries for all platforms and versions of the compiler. > > > >> > > > >> currently the parser lacks some minor features, but this could easily > > be > > > >> rectified. the real job is to add the code generation for various > > > >> languages. > > > >> > > > >> if anyone is interested in this, I am going to talk to some people > > > >> tomorrow to get formal approval for open sourcing it. > > > >> > > > >> any thoughts? > > > >> > > > >> -Bjørn > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > -- > > Todd Lipcon > > Software Engineer, Cloudera > > -- ------------------------------------------------------------------------ Anthony Molinaro <[email protected]>
