Hi folks, https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick. Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world. Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code. I've kept the change as minimal as possible to ease the (potential) transition and keep the C++ code close to the C code. This led to less idiomatic C++ code, but I value a "correct first" approach. There's an on-going effort by seiko2plus to remove that C layer, I acknowledge this would bring even more C++ code, but that looks orthogonal to me (and a very good second step!) All lights are green for the PR, let's assume it's a solid ground for discussion :-) So, well, what do you think? Should we go forward? Potential follow-ups : - do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep? - what about -fno-exception, -fno-rtti? - coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
I am not a C++ export, and really have to get to used to this code. So I would prefer if some C++ experts can look at it and give feedback. This will be a bit harder to read for me than our `.c.src` code for a while. But on the up-side, I am frustrated by my IDE not being able to deal with the `c.src` templating. One reaction reading the X-macro trick is that I would be more comfortable with a positive list rather than block-listing. It just felt a bit like too much magic and I am not sure how good it is to assume we usually want to export everything (for one, datetimes are pretty special). Even if it is verbose, I would not mind if we just list everything, so long we have short-hands for all-integers, all-float, all-inexact, etc.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
<snip>
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
What does this mean for compatibility? It sounds reasonable to me for now if it increases systems we can run on, but I really don't know.
- what about -fno-exception, -fno-rtti?
How do C++ exceptions work at run-time? What if I store a C++ function pointer that raises an exception and use it from a C program? Does it add run-time overhead, do we need that `no-exception` to define that our functions are actually C "calling convention" in this regard?! Run-time calling convention changes worry me, because I am not sure C++ exception have a place in the current or even future ABI. All our current API use a `-1` return value for exceptions. This is just like Python's type slots, so there must be "off the shelve" approaches for this? Embracing C++ exceptions seems a bit steep to me right now, unless I am missing something awesome? I will note that a lot of the functions that we want to template like this, are – and should be – accessible as public API (i.e. you can ask NumPy to give you the function pointer). Cheers, Sebastian
- coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
On Thu, Aug 26, 2021 at 12:51 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
What does this mean for compatibility? It sounds reasonable to me for now if it increases systems we can run on, but I really don't know.
The only platform where we'd need to bundle in a runtime is Windows I believe. Here's what we do for SciPy: https://github.com/MacPython/scipy-wheels/blob/72cb8ab580ed5ca1b95eb60243fef... . That is indeed a bit of a pain and hard to test, so if we can get away with not doing that by adding `-nostdlib`, that sounds great. Cheers, Ralf
On Wed, Aug 25, 2021 at 05:50:49PM -0500, Sebastian Berg wrote:
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
Hi Sebastian and thanks for the feedback.
I am not a C++ export, and really have to get to used to this code. So I would prefer if some C++ experts can look at it and give feedback.
I don't know if I'm a C++ expert, but I've a decent background with that language. I'll try to give as much clarification as I can.
This will be a bit harder to read for me than our `.c.src` code for a while. But on the up-side, I am frustrated by my IDE not being able to deal with the `c.src` templating.
One reaction reading the X-macro trick is that I would be more comfortable with a positive list rather than block-listing. It just felt a bit like too much magic and I am not sure how good it is to assume we usually want to export everything (for one, datetimes are pretty special).
Even if it is verbose, I would not mind if we just list everything, so long we have short-hands for all-integers, all-float, all-inexact, etc.
There has been similar comments on the PR, I've reverted to an explicit listing.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
<snip>
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
What does this mean for compatibility? It sounds reasonable to me for now if it increases systems we can run on, but I really don't know.
It basically means less packaging issues as one doesn't need to link with the standard C++ library. It doesn't prevent from using some headers, but remove some aspect of the language. If numpy wants to use C++ as a preprocessor on steorids, that's fine. If Numpy wants to embrace more of C++, it's a bad idea (e.g. no new operator)
- what about -fno-exception, -fno-rtti?
How do C++ exceptions work at run-time? What if I store a C++ function pointer that raises an exception and use it from a C program? Does it add run-time overhead, do we need that `no-exception` to define that our functions are actually C "calling convention" in this regard?!
Exception add runtime overhead and imply larger binaries. If an exception is raised at C++ level and not caught at C++ level, there going to unwind the whole C stack and then call a default handler that terminates the program.
Run-time calling convention changes worry me, because I am not sure C++ exception have a place in the current or even future ABI. All our current API use a `-1` return value for exceptions.
This is just like Python's type slots, so there must be "off the shelve" approaches for this?
Embracing C++ exceptions seems a bit steep to me right now, unless I am missing something awesome?
I totally second your opinion. In the spirit of C++ as a preprocessor on steroids, I don't see why exception would be needed.
I will note that a lot of the functions that we want to template like this, are – and should be – accessible as public API (i.e. you can ask NumPy to give you the function pointer).
As of now, I've kept the current C symbol names, which requires a thin foward to the C++ implementation. I would be glad to remove those, but I think it's a nice second step, something that could be done once the custom preprocessor has been removed.
On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote:
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
A brief update on this: The current plan would be to include this in the next release. Largely as a trial balloon, so we see if there are any issues, e.g. with deployment, and can revert the changes if there are. That would mean that some time within the next release cycle using C++ for more things could be on the table and less difficult to discuss. Not knowing the C++ much myself, I assume that the current approach is fine and the only remaining thing is a brief review of the new code to ensure correct translation from C. (Which does not preclude refining the C++ code later.) Cheers, Sebastian
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
I am not a C++ export, and really have to get to used to this code. So I would prefer if some C++ experts can look at it and give feedback.
This will be a bit harder to read for me than our `.c.src` code for a while. But on the up-side, I am frustrated by my IDE not being able to deal with the `c.src` templating.
One reaction reading the X-macro trick is that I would be more comfortable with a positive list rather than block-listing. It just felt a bit like too much magic and I am not sure how good it is to assume we usually want to export everything (for one, datetimes are pretty special).
Even if it is verbose, I would not mind if we just list everything, so long we have short-hands for all-integers, all-float, all-inexact, etc.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
<snip>
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
What does this mean for compatibility? It sounds reasonable to me for now if it increases systems we can run on, but I really don't know.
- what about -fno-exception, -fno-rtti?
How do C++ exceptions work at run-time? What if I store a C++ function pointer that raises an exception and use it from a C program? Does it add run-time overhead, do we need that `no-exception` to define that our functions are actually C "calling convention" in this regard?!
Run-time calling convention changes worry me, because I am not sure C++ exception have a place in the current or even future ABI. All our current API use a `-1` return value for exceptions.
This is just like Python's type slots, so there must be "off the shelve" approaches for this?
Embracing C++ exceptions seems a bit steep to me right now, unless I am missing something awesome?
I will note that a lot of the functions that we want to template like this, are – and should be – accessible as public API (i.e. you can ask NumPy to give you the function pointer).
Cheers,
Sebastian
- coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Will this have any impact on the difficulty of finding "where is np.foo or ndarray.bar implemented"? On Thu, Oct 7, 2021 at 3:02 PM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote:
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
A brief update on this: The current plan would be to include this in the next release. Largely as a trial balloon, so we see if there are any issues, e.g. with deployment, and can revert the changes if there are.
That would mean that some time within the next release cycle using C++ for more things could be on the table and less difficult to discuss.
Not knowing the C++ much myself, I assume that the current approach is fine and the only remaining thing is a brief review of the new code to ensure correct translation from C. (Which does not preclude refining the C++ code later.)
Cheers,
Sebastian
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
I am not a C++ export, and really have to get to used to this code. So I would prefer if some C++ experts can look at it and give feedback.
This will be a bit harder to read for me than our `.c.src` code for a while. But on the up-side, I am frustrated by my IDE not being able to deal with the `c.src` templating.
One reaction reading the X-macro trick is that I would be more comfortable with a positive list rather than block-listing. It just felt a bit like too much magic and I am not sure how good it is to assume we usually want to export everything (for one, datetimes are pretty special).
Even if it is verbose, I would not mind if we just list everything, so long we have short-hands for all-integers, all-float, all-inexact, etc.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
<snip>
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
What does this mean for compatibility? It sounds reasonable to me for now if it increases systems we can run on, but I really don't know.
- what about -fno-exception, -fno-rtti?
How do C++ exceptions work at run-time? What if I store a C++ function pointer that raises an exception and use it from a C program? Does it add run-time overhead, do we need that `no-exception` to define that our functions are actually C "calling convention" in this regard?!
Run-time calling convention changes worry me, because I am not sure C++ exception have a place in the current or even future ABI. All our current API use a `-1` return value for exceptions.
This is just like Python's type slots, so there must be "off the shelve" approaches for this?
Embracing C++ exceptions seems a bit steep to me right now, unless I am missing something awesome?
I will note that a lot of the functions that we want to template like this, are – and should be – accessible as public API (i.e. you can ask NumPy to give you the function pointer).
Cheers,
Sebastian
- coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: jbrockmendel@gmail.com
On Thu, 2021-10-07 at 15:41 -0700, Brock Mendel wrote:
Will this have any impact on the difficulty of finding "where is np.foo or ndarray.bar implemented"?
I don't think so. It is always a bit annoying to step through the python and then C-layer before you reach the computation part (or know from where it is fetched). Just, now you end up in a C++ templated file rather than c.src templated one. Right now, it is probably even slightly better because it is easier to grep for the function names, although I guess that could change. The added complexity is that we have two ways to template C now... I hope that will pay off soon (as in C++ is proofs useful in some way), since it feels like replacing all `c.src` code is a pretty large (although probably doable) endeavor. Cheers, Sebastian
On Thu, Oct 7, 2021 at 3:02 PM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote:
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
A brief update on this: The current plan would be to include this in the next release. Largely as a trial balloon, so we see if there are any issues, e.g. with deployment, and can revert the changes if there are.
That would mean that some time within the next release cycle using C++ for more things could be on the table and less difficult to discuss.
Not knowing the C++ much myself, I assume that the current approach is fine and the only remaining thing is a brief review of the new code to ensure correct translation from C. (Which does not preclude refining the C++ code later.)
Cheers,
Sebastian
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
I am not a C++ export, and really have to get to used to this code. So I would prefer if some C++ experts can look at it and give feedback.
This will be a bit harder to read for me than our `.c.src` code for a while. But on the up-side, I am frustrated by my IDE not being able to deal with the `c.src` templating.
One reaction reading the X-macro trick is that I would be more comfortable with a positive list rather than block-listing. It just felt a bit like too much magic and I am not sure how good it is to assume we usually want to export everything (for one, datetimes are pretty special).
Even if it is verbose, I would not mind if we just list everything, so long we have short-hands for all-integers, all-float, all- inexact, etc.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
<snip>
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
What does this mean for compatibility? It sounds reasonable to me for now if it increases systems we can run on, but I really don't know.
- what about -fno-exception, -fno-rtti?
How do C++ exceptions work at run-time? What if I store a C++ function pointer that raises an exception and use it from a C program? Does it add run-time overhead, do we need that `no-exception` to define that our functions are actually C "calling convention" in this regard?!
Run-time calling convention changes worry me, because I am not sure C++ exception have a place in the current or even future ABI. All our current API use a `-1` return value for exceptions.
This is just like Python's type slots, so there must be "off the shelve" approaches for this?
Embracing C++ exceptions seems a bit steep to me right now, unless I am missing something awesome?
I will note that a lot of the functions that we want to template like this, are – and should be – accessible as public API (i.e. you can ask NumPy to give you the function pointer).
Cheers,
Sebastian
- coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: jbrockmendel@gmail.com
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
It seems time to pick up this discussion again. I think we were cautiously in favor of trying this out in the limited proposed form. Aside from ensuring we do not use C++ exceptions/run-time environment. I.e. compile with `-fno-exception` and `-nostdlib`, the PR is probably largely ready. Are there any other bigger issues that need to be discussed? The goal for now seems to allow this type of function templates (C++ as a glorified templating language). We may be able to enforce this with clang-tidy (not sure if that is necessary right away though). There are parts of NumPy (mainly `fft`) where more C++ features could be helpful but that should probably be discussed separately. The current solution ends up using no X-Macro anymore, which means listing the C symbols like: NPY_NO_EXPORT int radixsort_byte(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_byte>(vec, cnt); } NPY_NO_EXPORT int radixsort_ubyte(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_ubyte>(vec, cnt); } NPY_NO_EXPORT int radixsort_short(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_short>(vec, cnt); } NPY_NO_EXPORT int radixsort_ushort(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_ushort>(vec, cnt); } NPY_NO_EXPORT int radixsort_int(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_int>(vec, cnt); } NPY_NO_EXPORT int radixsort_uint(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_uint>(vec, cnt); } NPY_NO_EXPORT int radixsort_long(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_long>(vec, cnt); } NPY_NO_EXPORT int radixsort_ulong(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_ulong>(vec, cnt); } I guess we could try to write some macro's to make this shorter, although I am fine with delaying this, since the main point is probably getting a brief example and the build changes in. It also defines the following type tags: https://github.com/numpy/numpy/pull/19713/files#diff-4de4beaecd7b0a1f4d88722... Any comments to the approach (especially from anyone more familiar with C++) would be much appreciated! Cheers, Sebastian
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
I've kept the change as minimal as possible to ease the (potential) transition and keep the C++ code close to the C code. This led to less idiomatic C++ code, but I value a "correct first" approach. There's an on-going effort by seiko2plus to remove that C layer, I acknowledge this would bring even more C++ code, but that looks orthogonal to me (and a very good second step!)
All lights are green for the PR, let's assume it's a solid ground for discussion :-) So, well, what do you think? Should we go forward?
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep? - what about -fno-exception, -fno-rtti? - coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
A couple of questions from a quick casual reading 1. radixsort (void *start...) Do we really need void*? We don't know the type of start at compile time? 2. reinterpret_cast<T*> start (related to #1). 3. reinterpret_cast<T*>(malloc(num * sizeof(T))); A C-ism. Would it work to use new T[num]? On Tue, Sep 28, 2021 at 10:03 PM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
Hi folks,
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.
It seems time to pick up this discussion again. I think we were cautiously in favor of trying this out in the limited proposed form.
Aside from ensuring we do not use C++ exceptions/run-time environment. I.e. compile with `-fno-exception` and `-nostdlib`, the PR is probably largely ready.
Are there any other bigger issues that need to be discussed?
The goal for now seems to allow this type of function templates (C++ as a glorified templating language). We may be able to enforce this with clang-tidy (not sure if that is necessary right away though). There are parts of NumPy (mainly `fft`) where more C++ features could be helpful but that should probably be discussed separately.
The current solution ends up using no X-Macro anymore, which means listing the C symbols like:
NPY_NO_EXPORT int radixsort_byte(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_byte>(vec, cnt); } NPY_NO_EXPORT int radixsort_ubyte(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_ubyte>(vec, cnt); } NPY_NO_EXPORT int radixsort_short(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_short>(vec, cnt); } NPY_NO_EXPORT int radixsort_ushort(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_ushort>(vec, cnt); } NPY_NO_EXPORT int radixsort_int(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_int>(vec, cnt); } NPY_NO_EXPORT int radixsort_uint(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_uint>(vec, cnt); } NPY_NO_EXPORT int radixsort_long(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_long>(vec, cnt); } NPY_NO_EXPORT int radixsort_ulong(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort<npy_ulong>(vec, cnt); }
I guess we could try to write some macro's to make this shorter, although I am fine with delaying this, since the main point is probably getting a brief example and the build changes in.
It also defines the following type tags: https://github.com/numpy/numpy/pull/19713/files#diff-4de4beaecd7b0a1f4d88722...
Any comments to the approach (especially from anyone more familiar with C++) would be much appreciated!
Cheers,
Sebastian
Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.
Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.
I've kept the change as minimal as possible to ease the (potential) transition and keep the C++ code close to the C code. This led to less idiomatic C++ code, but I value a "correct first" approach. There's an on-going effort by seiko2plus to remove that C layer, I acknowledge this would bring even more C++ code, but that looks orthogonal to me (and a very good second step!)
All lights are green for the PR, let's assume it's a solid ground for discussion :-) So, well, what do you think? Should we go forward?
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep? - what about -fno-exception, -fno-rtti? - coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ndbecker2@gmail.com
-- Those who don't understand recursion are doomed to repeat it
participants (6)
-
Brock Mendel -
Neal Becker -
Ralf Gommers -
Sebastian Berg -
Serge Guelton -
Zhen Hsiung