On Thu, Aug 5, 2010 at 9:58 AM, Carl Witty <[email protected]> wrote: > On Thu, Aug 5, 2010 at 12:08 AM, Dag Sverre Seljebotn > <[email protected]> wrote: >> On 08/05/2010 06:01 AM, Carl Witty wrote: >>> I'm starting by essentially duplicating all of the generate_* methods >>> into generate_dotnet_* methods, and modifying the duplicated methods >>> to generate C++/CLI code. My hope is that once I have a working >>> >> Ah, this is very interesting -- when I've spoken with Enthought on the >> matter we've largely ignored C++ for this and were talking about a C# >> backend. > > I convinced the Enthought people that a C++/CLI backend was the best > first step. For a variety of reasons (mostly the fact that Cython's > "extern from" describes the API, not the ABI, but also catching C++ > exceptions and turning them into Python exceptions) a C# backend would > have to generate C or C++ wrappers for every operation on "extern > from" values/types (function call, global variable read, global > variable write, struct member read, struct member write, ...). On the > other hand, a C++/CLI backend can handle "extern from" in exactly the > same way that the current C/C++ backend does. > > Once the C++/CLI backend works, a C# backend is a possible next step. > All of the code generation for C# to interface with IronPython would > be exactly the same as C++/CLI (modulo minor syntactic issues that can > easily be localized). Even if the ultimate goal is a C# backend, I > think that very little of the work on a C++/CLI backend would be > wasted.
The ultimate goal is really just Cython working (well) for IronPython, right? How essential is C# generation (vs. C++/CLI) to that goal? >>> compiler, I can refactor to merge most of the methods back together >>> (eliminating the duplicate code) while still not being very intrusive >>> to the original codebase. >>> >> >> Have you considered writing a transform instead of adding more methods >> to the nodes? E.g. something like Cython/CodeWriter.py for the .NET >> backend? That would be even less intrusive...ideally, one would just >> configure the pipeline differently depending on what the backend is. > > I did consider this briefly. Given the choice between writing a > backend basically from scratch, or being able to copy a working > backend and incrementally modify it, the latter seemed a lot easier. > :) > > Once I have a working compiler, and it's time to clean up the code for > submission, I'll definitely consider this approach. Based on the tiny > amount of work I've done so far, though, I suspect that I may be able > to share a lot of code with the existing backend that would end up > duplicated if I made my backend into a transform. I think for a task like this, once you've gotten something working it'll be a lot clearer what the right form is as well. >> (I once suggested that the CPython generation was also moved into a >> seperate generator class like this as well; of course, that's a lot of >> unnecessary work) > > Sounds like a good idea to me. Also, if the existing backend and the > C++/CLI backend were both transforms, that would make it a lot easier > for them to share code (they could both inherit from a generic "code > generation" transform, for instance). But I doubt if I'll have time > to work on this... > >> I'm just not too sure about having "if dotnet:" all over the place >> (eventually). Of course, you should just do whatever gives results >> quickest at this point (and I very much trust your judgement), I'm just >> making sure the option is mentioned. > > Keeping the number of "if dotnet:" down is definitely an important > long-term goal. (For now, I'm adding lots of them, but I expect to > remove them and handle the cases some other way before I submit the > code.) Excellent. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
