[Numpy-discussion] How does Numpy build system detect the change of .c source file?
Hi everyone! I 'm here again.
Recently I 'm trying to understand the C code with output-debug method,
inserting many print statements. I was doing well with it until one day: I
changed a file called loops_utils.h.src located in numpy/core/src/umath by
inserting some "printf", but after I re-built the Numpy from source, the
changes didn't apply.
Specifically, I added:
printf(" ??? ");
in line 80, but after re-building it didn't output "??".
I found that when I ran "python setup.py build_ext --inplace", the output
info seemed to tell me that nothing has been compiled, because normally
when something changed, it will output:
> x86-64-conda-linux-gnu-cc: xx.dispatch.c
What's more interesting is that: after I changed the file
loops_arithm_fp.dispatch.c.src, and then rebuilt, the change to
loops_utils.h.src applied, with the screen full of "??".
I tested it for many times that each time I modify loops_utils.h.src, and
the change doesn't apply after re-building; while after I
modify loops_arithm_fp.dispatch.c.src, the change to loops_utils.h.src
starts to apply.
It seems to be related to how build system detects the change, I guuess.
Can someone explain why this will happen or point out what I 've missed?
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
[Numpy-discussion] Re: How does Numpy build system detect the change of .c source file?
On Wed, Nov 2, 2022 at 9:30 AM 腾刘 <27rabbi...@gmail.com> wrote:
> Hi everyone! I 'm here again.
>
> Recently I 'm trying to understand the C code with output-debug method,
> inserting many print statements. I was doing well with it until one day: I
> changed a file called loops_utils.h.src located in numpy/core/src/umath by
> inserting some "printf", but after I re-built the Numpy from source, the
> changes didn't apply.
>
> Specifically, I added:
>
> printf(" ??? ");
>
> in line 80, but after re-building it didn't output "??".
>
> I found that when I ran "python setup.py build_ext --inplace", the output
> info seemed to tell me that nothing has been compiled, because normally
> when something changed, it will output:
> > x86-64-conda-linux-gnu-cc: xx.dispatch.c
>
> What's more interesting is that: after I changed the file
> loops_arithm_fp.dispatch.c.src, and then rebuilt, the change to
> loops_utils.h.src applied, with the screen full of "??".
>
> I tested it for many times that each time I modify loops_utils.h.src, and
> the change doesn't apply after re-building; while after I
> modify loops_arithm_fp.dispatch.c.src, the change to loops_utils.h.src
> starts to apply.
>
> It seems to be related to how build system detects the change, I guuess.
> Can someone explain why this will happen or point out what I 've missed?
>
I don't think you've missed anything, that's a bug in one of the setup.py
files. The build system (distutils + numpy.distutils) is bad at
automatically figuring out what is used, so sometimes it needs an explicit
hint with `depends=['some_header.h.src']` - it looks like that is missing
here.
Cheers,
Ralf
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
[Numpy-discussion] Re: How does Numpy build system detect the change of .c source file?
So much thanks! I will have a look at how distutils work and try to figure
out whether I can fix this dependency problem.
Ralf Gommers 于2022年11月2日周三 17:13写道：
>
>
> On Wed, Nov 2, 2022 at 9:30 AM 腾刘 <27rabbi...@gmail.com> wrote:
>
>> Hi everyone! I 'm here again.
>>
>> Recently I 'm trying to understand the C code with output-debug method,
>> inserting many print statements. I was doing well with it until one day: I
>> changed a file called loops_utils.h.src located in numpy/core/src/umath by
>> inserting some "printf", but after I re-built the Numpy from source, the
>> changes didn't apply.
>>
>> Specifically, I added:
>>
>> printf(" ??? ");
>>
>> in line 80, but after re-building it didn't output "??".
>>
>> I found that when I ran "python setup.py build_ext --inplace", the output
>> info seemed to tell me that nothing has been compiled, because normally
>> when something changed, it will output:
>> > x86-64-conda-linux-gnu-cc: xx.dispatch.c
>>
>> What's more interesting is that: after I changed the file
>> loops_arithm_fp.dispatch.c.src, and then rebuilt, the change to
>> loops_utils.h.src applied, with the screen full of "??".
>>
>> I tested it for many times that each time I modify loops_utils.h.src, and
>> the change doesn't apply after re-building; while after I
>> modify loops_arithm_fp.dispatch.c.src, the change to loops_utils.h.src
>> starts to apply.
>>
>> It seems to be related to how build system detects the change, I guuess.
>> Can someone explain why this will happen or point out what I 've missed?
>>
>
> I don't think you've missed anything, that's a bug in one of the setup.py
> files. The build system (distutils + numpy.distutils) is bad at
> automatically figuring out what is used, so sometimes it needs an explicit
> hint with `depends=['some_header.h.src']` - it looks like that is missing
> here.
>
> Cheers,
> Ralf
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: 27rabbi...@gmail.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
[Numpy-discussion] Re: NEP 51: Changing the Representation of NumPy Scalars
On Mon, 2022-10-31 at 13:49 -0600, Aaron Meurer wrote:
> I like this. NumPy scalar printing is confusing to new users, who
> might think they are Python scalars. And even if you understand them,
> it's always been annoying that you have to do further introspection
> to
> see the dtype. I also like the longdouble change (the name float128
> has misled me in the past), and the decision to make everything
> copy-paste round-trippable.
>
> Are there also plans to add "np." to array() and the string forms of
> other objects?
Didn't include changing arrays here, since I thought I would focus on
scalars only.
Clearly it is a plausible change though, and we could add it in this
NEP. Although, I suspect it is just as well to do it separately.
Including the `np.` for scalars seemed more clear, but since it is
pretty common to exclude modules in repr, I would also be happy to not
do it.
It would make a bit of a presumption that NumPy is the obvious provider
of `int32` (and if others do, they are likely compatible).
- Sebastian
>
> Aaron Meurer
>
> On Fri, Oct 28, 2022 at 2:55 AM Sebastian Berg
> wrote:
> >
> > Hi all,
> >
> > As mentioned earlier, I would like to propose changing the
> > representation of scalars in NumPy. Discussion and ideas on
> > changes
> > are much appreciated!
> >
> > The main change is to show scalars as:
> >
> > * `np.float64(3.0)` instead of just `3.0`
> > * `np.True_` instead of `True`
> > * `np.void((3, 5), dtype=[('a', ' > `(3, 5)`
> > * Use `np.` rather than `numpy.` for datetime/timedelta.
> >
> > This way it is clear for users that they are dealing with NumPy
> > scalars
> > which behave different from Python scalars.
> > The `str()` that is given when using `print()` and the way arrays
> > are
> > shown will be unchanged.
> >
> > The NEP draft can be found here:
> >
> > https://numpy.org/neps/nep-0051-scalar-representation.html
> >
> > and it includes more details and related changes.
> >
> > The implementation is largely finished and can be found here:
> >
> > https://github.com/numpy/numpy/pull/22449
> >
> > W are fairly late in the release cycle and the change should not
> > block
> > other things. So, the aim is to merge it early in the next release
> > cycle. That way downstream has time to fix documentation is
> > wanted.
> >
> > Depending on how discussion goes, I hope to formally propose the
> > NEP
> > fairly soon, so that the merging the implementation doesn't need to
> > wait on NEP approval.
> >
> > Cheers,
> >
> > Sebastian
> >
> >
> >
> >
> > On Thu, 2022-09-08 at 11:38 +0200, Sebastian Berg wrote:
> > >
> > > TL;DR: NumPy scalars representation is e.g. `34.3` instead of
> > > `float32(34.3)`. So the representation is missing the type
> > > information. What are your thoughts on changing that?
> > >
> > >
> > > Hi all,
> > >
> > > I am thinking about the next steps for NEP 50 (The NEP wants to
> > > fix
> > > the
> > > NumPy promotion rules, especially with respect to scalars):
> > >
> > > https://numpy.org/neps/nep-0050-scalar-promotion.html
> > >
> > > In relation to that, there was one point that Stéfan brought up
> > > previously.
> > >
> > > The NumPy scalars (representation) currently print as numbers:
> > >
> > > >>> np.float32(34.3)
> > > 34.3
> > > >>> np.uint8(5)
> > > 5
> > >
> > > That can already be confusing now. However, it gets more
> > > problematic
> > > if NEP 50 is introduced since the behavior between a Python
> > > `34.3`
> > > and
> > > `np.float32(34.3)` would differ more than it does now (please
> > > refer
> > > to
> > > the NEP).
> > >
> > > The change would be that we should print as:
> > >
> > > float64(34.3) (or similar?)
> > >
> > > This Email is mainly to ask for any feedback or concern on such a
> > > change. I suspect we may have to write a very brief NEP about
> > > it.
> > >
> > > If there is little concern, maybe we could move forward such a
> > > change
> > > promptly. Otherwise it could be moved forward together with NEP
> > > 50
> > > and
> > > take effect in a "major" release [1].
> > >
> > > Cheers,
> > >
> > > Sebastian
> > >
> > >
> > >
> > > [1] Note that for me, even a major release would hopefully not
> > > affect
> > > the majority of users or be very disruptive.
> > >
> > > ___
> > > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > > To unsubscribe send an email to numpy-discussion-le...@python.org
> > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > > Member address: sebast...@sipsolutions.net
> >
> >
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: asmeu...@gmail.com
> ___
>
