As you might remember, I worked on adding D support to Apache Thrift [1] during Google Summer of Code 2011. A few months (and DMD releases) down the road, the patch was finally submitted to Thrift upstream [2], with the test suite passing on all of Windows, Linux and OS X.

The problem now is that while there is definitely interest in using D with Thrift, the upstream team is (unsurprisingly, perhaps) lacking people who know D well enough to review the almost 24k LOC patch. Thus, the patch has been sitting in the Apache JIRA for almost two months now.

So, if you are interested in Thrift or already have some experience with it, it'd be great if you could have a look at the code and let me (and the Thrift issue tracker, of course), know what you think. You should be able to find anything needed from the ticket [2], let me know if something is missing.

———
What the library doesn't have (yet):
 - @safe-ty annotations (pure doesn't apply to most of the code): I tried to add them a while back, but hit some unpleasant compiler bugs.

 - Compile-time Thrift IDL parsing: While most of the codegen is done at D compile time anyway, having the interface file parser in CTFE as well wasn't really feasible when GSoC started (before Don's rewrite), and integration with the main Thrift compiler would have been required in any case. Now, a CTFE implementation might be a nice use case of one of the CTFE parsing libraries, though (the current code generator is only 700 lines of C++, plus parser), if you want to tackle this, let me know.

 - A HashSet implementation in Phobos it could generate code against; currently, a void[0]-AA-based hack is used. I've been meaning to look into adding something to std.container for ages now, but with me being swamped in work and the container design being »in flux« (e.g. allocators)…

 - While I implemented a feature to generate Thrift IDL from existing D structs and interfaces at compile time (now that is cool), which can do a round-trip for all Thrift-generated code, it probably breaks in the face of real-world D code – please use it, break it, and ideally fix it. ;)

 – There are lots of cool ideas for D-specific features which could be added, for example a Thrift server which maps RPC requests to std.concurrency messages, etc. So far, I mostly concentrated on providing the parts which Thrift users expect to be there, i.e. which the C++ and Java implementations also offer. This also involves a slightly non-idiomatic design in some places, which is unfortunate, but Thrift generally strives to find a good balance between offering a »native« feel in each target language and cross-language consistency.
———

Thanks,
David


[1] http://thrift.apache.org/
[2] https://issues.apache.org/jira/browse/THRIFT-1500

David Nadlinger:

> What the library doesn't have (yet):
>   - @safe-ty annotations (pure doesn't apply to most of the code):
> I tried to add them a while back, but hit some unpleasant
> compiler bugs.

Are they in Bugzilla already?

Bye,
bearophile

On Sunday, 11 March 2012 at 21:55:54 UTC, bearophile wrote:
> David Nadlinger:
>> What the library doesn't have (yet):
>>   - @safe-ty annotations (pure doesn't apply to most of the code): I tried to add them a while back, but hit some unpleasant compiler bugs.
> Are they in Bugzilla already?

Some findings include issue 7049–7052, but what led me to stop work on it was an instance related to interfaces where I couldn't figure out what was going on. Trying to add it should be easy for anyone who is interested, though, just put a »@safe:« at the top of each file and look where the test suite build breaks.

David

> So, if you are interested in Thrift or already have some experience with it, it'd be great if you could have a look at the code and let me (and the Thrift issue tracker, of course), know what you think. You should be able to find anything needed from the ticket [2], let me know if something is missing.
I did recently tried it out because I wanted to test some async Fiber kqueue stuff.
It did fail to compile though because of conflicting selective imports.
You probably want to avoid those until the remaining issues are sorted out.

>   - Compile-time Thrift IDL parsing:
I probably forgot to lex floating point literals.
https://gist.github.com/2019921#gistcomment-90654


>   - A HashSet implementation in Phobos it could generate code against; currently, a void[0]-AA-based hack is used. I've been meaning to look into adding something to std.container for ages now, but with me being swamped in work and the container design being »in flux« (e.g. allocators)…
Yup, at some point we should stick a not yet ready allocator design
into std.experimental before it inhibits even more development.

The void[0][Key] is a good trick, I always used empty structs.

On Monday, 12 March 2012 at 05:44:10 UTC, Martin Nowak wrote:
> I did recently tried it out because I wanted to test some async Fiber kqueue stuff.
> It did fail to compile though because of conflicting selective imports.
> You probably want to avoid those until the remaining issues are sorted out.

Ouch, no idea how that happened – before the 2.058 release, I tested it regularly against the old import implementation, my own fix for bug 314, the then-trunk including Christian's 314 fixes, and I even tested most revisions during the »let's back this out shortly before the release« fiasko, but I must have somehow missed the actual release when doing so.

In any case, I pushed a fix to the Thrift JIRA and the GitHub repo [1], but was only able to test on OS X, so let me know if it still breaks for you.


>>  - Compile-time Thrift IDL parsing:
> I probably forgot to lex floating point literals.
> https://gist.github.com/2019921#gistcomment-90654

Nice! I hope I'll miraculously find myself with a free afternoon during the next week or so, can't wait to play around with it. Also, I'm thinking about rewriting the codegen completely in CTFE (i.e. producing a big string to be mixed in instead of using templates with string mixins only where required), because this would allow running the generator separately (and caching the output in a regular .d file) for faster build times…


>>  - A HashSet implementation in Phobos it could generate code against; currently, a void[0]-AA-based hack is used. I've been meaning to look into adding something to std.container for ages now, but with me being swamped in work and the container design being »in flux« (e.g. allocators)…
> Yup, at some point we should stick a not yet ready allocator design
> into std.experimental before it inhibits even more development.

Andrei? ;)


> The void[0][Key] is a good trick, I always used empty structs.
I expose a (minimalistic) thrift.util.HashSet wrapper, though, to avoid too much confusion on the user side (and besides, an empty struct is probably cleaner anyway).


David


[1] https://github.com/klickverbot/thrift