[Numpy-discussion] Help Regarding Debugging Cython Code

[Amardeep Singh]

Hi Team

If some one has setup to debug cython code can  you please share
the details.
I am using ubuntu 20.4 .
Not sure why gdb not picking up breakpoints.

I am able to debug c extensions but not cython code.

Thx
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Help Regarding Debugging Cython Code

[Matti Picus]

On 5/9/21 12:55 pm, Amardeep Singh wrote:

Hi Team

If some one has setup to debug cython code can  you please share 
the details.

I am using ubuntu 20.4 .
Not sure why gdb not picking up breakpoints.

I am able to debug c extensions but not cython code.

Thx



There are a number of ways to set up for debugging. The one that works 
for me is to do



git clean -xfdd

CFLAGS='-O0 -g3' python runtests.py -b

gdb --args python runtests.py -t file/I/with/the/test/I/want.py


The "git clean" should make sure you are not using pre-compiled 
c-extensions.


There are variants of this if you are using an IDE or like to use 
setup.py directly



Matti

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] np.trunc is inconsistent with array-api

[Ralf Gommers]

On Sat, Sep 4, 2021 at 10:02 AM Kshitij Kalambarkar <
kshitijkalambar...@gmail.com> wrote:

> Hi,
>
> np.trunc returns floating dtype output even for integral dtype input. As
> per array-api, it should preserve the input dtype.
>

Just a note that it's not compatibility with the array API standard that's
the main driver for the change here (that would be handled in
`numpy.array_api.trunc`, not `numpy.trunc`). But it's just unwanted
behavior, so an improvement to `numpy.trunc` is also desirable.


> Note: This is also true for np.rint, np.fix, np.ceil, np.floor
>
> Reference: https://github.com/numpy/numpy/issues/19464
>
> Possible Fix:
> 1. We update the behaviour directly with an update to release note.
> 2. We add a FutureWarning and update the behaviour in a future release.
>

I'm fine with (1), because (a) it can be considered a bug fix, (b) it's
unlikely to break anything, and (c) a FutureWarning is not too helpful
because there's no way to update existing code to be forward-proof and
remove the warning.

Cheers,
Ralf


> This email is to gauge the preference for the fix.
>
> Thank You!
>
> Regards,
> Kshiteej K
>
>
>
> ___
> 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