[PATCH RFC] RFC: allow optional C++ 11 extensions with pybind11 for performance code

[Laurent Charignon]

Hi,

For the time being and for the tree manifest, I will use C and reuse code from lazy manifest.
If the perf are not acceptable(because no hash table) I will look into hash tables in C that we could add to our project.
Writing the code in C seems like a non controversial way to proceed and have someone review the changes :)

In this discussion we all seem to agree on one thing: **we will have to ditch the Python C layer in the near future**. 
We don't know yet if we should (1) use cffi and ctypes to move toward pypy or (2) use cython.
(1) Implies rewriting of our C layer to decouple it from the Python API.
(2) Implies ditching our C code and adding type hints to our performance sensitive code in python, correct?

I didn't really follow the discussions around pypy, when are we planning to support pypy?

Matt, what do you think about this discussion?

Thanks,

Laurent





> On Feb 10, 2016, at 3:36 PM, Sean Farley <sean at farley.io> wrote:
> 
> 
> Bryan O'Sullivan <bos at serpentine.com> writes:
> 
>> On Mon, Feb 8, 2016 at 1:33 PM, Sean Farley <sean at farley.io> wrote:
>> 
>>> When cloning code on IBM
>>> BlueGene it is annoying as hell to have random dependencies sneak in
>>> like this. For reference, IBM BlueGene has had problem with codes that
>>> use C++.
>>> 
>> 
>> As much as I think Laurent has a burden of proof for how C++ helps with
>> productivity, I submit that you too owe a strong case for why the Mercurial
>> developer community should be hamstrung by support for a tiny
>> sub-population if said sub-population is permanently unable or unwilling to
>> keep up with the times.
>> 
>> This isn't a game of absolutes, and I'd rather have a discussion of the
>> trade-offs.
> 
> That's fair. And I agree.
> 
> I didn't so much mean that we should be held up by this subset, I meant
> more of "here's one example of using C++ that backfired." There are
> other examples, though. There are papercuts from C++'s name mangling.
> Not to mention the hornet's nest with ABI compatibility. That issue is
> still a problem for the Mac (try compiling boost with gcc). Summing all
> of these issues does not instill confidence that we would do any better.
> 
> My main fear is having a negative user experience. DVCS, at its core, is
> a system tool. Impeding a developer from using their familiar tools is a
> serious sin.
> 
> So, what else is there?
> 
> - code generation?
>  - pros: outputs C
>  - cons: I have yet to see a code generator provide a good debugger
> 
> - cython?
>  - pros: has a debugger, somewhat native code
>  - cons: incompatible with pypy
> 
> - cffi?
>  - pros: cleaner C, native code, pypy support
>  - cons: need to include custom data types
> 
> - something else?
> 
> - something crazy?