AW: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6
Holger Krekel wrote:
All i all, i think that we probably want to checkout joeq some more. In particular, we might want to think about trying to generate a QUAD representation of PyPy and reuse some of the joeq infrastructure. We can expect to have less integration issues than with the Low-Level-Virtual-Machine (LLVM) project which is written in C++ (ever worked with C++-libraries and dependencies? funfunfun).
C++ is an Industry standard based on C. C++ Libraries can be wrapped by C-Libraries (extern 'C') if you have the source-code at hand. C++ Libraries that are not wrapped can contain native C++ (for example class definitions). Then they can be called by C++ code only. It is not
Anthony Baxter wrote: Jantzen, Günter wrote: possible to call
C++ Libraries which are compiled with a different Compiler, because all C++ Implementations have different naming conventions for methods and parameters(name mangling).
I don't say LLVM is better for PyPy than joeq. But I think it should be first considered what is right and second what is easy to implement.
Huh? This is completely ass-backwards. Trying to implement it in C++, merely because it's "an industry standard", is about the worst reason in the world. And in your reply you point out that the "industry standard" is a shambles when it comes to dependencies and libraries.
Consider what works, then worry about what's got some supposed "industry standard" elephant stamp on it. If we worried about "industry standards" we'd be all implementing in ECMAScript, Java, and C#, _not_ Python.
I did not suggest to implement something in C++ I only suggested to search for better reasons to make a decision. When choosing a library for a backend you will always have integration issues. It is never a fun to cross language borders. But as long as you wourk with 'industry standards' like Java, C or C++ you have a good chance to solve this problem one time and to encapsulate this stuff with a thin wrapper. For this reason it is more important to look from a design perspective. When choosing a backend, ask yourself if it will support the features which are your needs. I am not a native speaker, so I don't understand the expression 'ass-backwards'. Seems not very polite to me. regards Guenter
["Jantzen, G?nter" Tue, Jun 22, 2004 at 01:36:15PM +0200]
Anthony Baxter wrote: Consider what works, then worry about what's got some supposed "industry standard" elephant stamp on it. If we worried about "industry standards" we'd be all implementing in ECMAScript, Java, and C#, _not_ Python.
I did not suggest to implement something in C++ I only suggested to search for better reasons to make a decision.
When choosing a library for a backend you will always have integration issues.
Indeed.
It is never a fun to cross language borders. But as long as you wourk with 'industry standards' like Java, C or C++ you have a good chance to solve this problem one time and to encapsulate this stuff with a thin wrapper.
Well, to my ears an "industry standard" is usually the label vendors put on their product. Moreover, with PyPy we cross language borders all the time. It is inherent to the kind of project we are doing. For practical matters, integration issues and the "consider that works" principle are very important to our kind of evolutionary development. Anyway, i imagine that if we use joeq or LLVM as a backend we might very well rewrite the most interesting parts in Python at some point, depending on our experiences and the actual development. But for now, it's "does it do the job" and "does it integrate well enough".
For this reason it is more important to look from a design perspective.
I think we do but use a different definition of "design" then what is considered "design" in large companies which usually develop in terms of UML diagrams, workflow specifications/engines and model-driven code-generators using "standard" components etc.pp. No offense meant :-)
When choosing a backend, ask yourself if it will support the features which are your needs.
OK, i guess we all agree here.
I am not a native speaker, so I don't understand the expression 'ass-backwards'. Seems not very polite to me.
I am not a native speaker myself but i would think this is a just a somewhat stronger word for "backwards". just my 2ec. cheers, holger
Jantzen, Günter wrote:
I am not a native speaker, so I don't understand the expression 'ass-backwards'. Seems not very polite to me.
It's just a slightly stronger way of saying "the wrong way". I'm Australian, and tend to use language like a blunt instrument. <wink> Apologies for any offense.
participants (3)
-
"Jantzen, Günter" -
Anthony Baxter -
holger krekel