[Numpy-discussion] Armv8 server donation
Hi, all: I noticed that the shippable CI always skipped after PR submitted , The reason why it's skip seems to be "No active nodes found in shared node pool "shippable_shared_aarch64"" Potential bugs may buried through out numpy without shippable CI. I happened to own an idle armv8 server that can donate to numpy community, please let me know if that can improve numpy's CI/CD environment , also need somebody help me set up the CI/CD environment on that server. Best wishes Fang ChunLin. https://github.com/Qiyu8 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Armv8 server donation
On Thu, Jun 11, 2020, at 13:47, ChunLin Fang wrote: > I noticed that the shippable CI always skipped after PR submitted , The > reason why it's skip seems to be "No active nodes found in shared node pool > "shippable_shared_aarch64"" > Potential bugs may buried through out numpy without shippable CI. > I happened to own an idle armv8 server that can donate to numpy community, > please let me know if that can improve numpy's CI/CD environment , also need > somebody help me set up the CI/CD environment on that server. Thank you for your kind offer! Someone else would be more qualified than I to comment on why the pool is empty, and what resources we have available. I know that AppVeyor allows you to host your own nodes, and it looks like Azure does too: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops https://www.appveyor.com/docs/server/#linux Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Armv8 server donation
Someone could setup https://drone.io/ which has both aarch64 and armv8l servers. I have used this service without issue in randomgen which requires building NumPy (but not testing it). On Thu, Jun 11, 2020 at 2:21 PM Stefan van der Walt wrote: > On Thu, Jun 11, 2020, at 13:47, ChunLin Fang wrote: > > I noticed that the shippable CI always skipped after PR submitted , > The reason why it's skip seems to be "No active nodes found in shared node > pool "shippable_shared_aarch64"" > Potential bugs may buried through out numpy without shippable CI. > I happened to own an idle armv8 server that can donate to numpy > community, please let me know if that can improve numpy's CI/CD environment > , also need somebody help me set up the CI/CD environment on that server. > > > Thank you for your kind offer! > > Someone else would be more qualified than I to comment on why the pool is > empty, and what resources we have available. > > I know that AppVeyor allows you to host your own nodes, and it looks like > Azure does too: > > > https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops > https://www.appveyor.com/docs/server/#linux > > Stéfan > > ___ > 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] Deprecating python type aliases (np.int, np.long, np.str, ...)
Hi all, In the pull request: https://github.com/numpy/numpy/pull/14882 Eric proposes to deprecate the type aliases which NumPy imports into its main namespace (e.g. np.int, np.bool, see table below [1]). Right now there seems to be a consensus to move this forward and I plan on doing that, so this is a heads-up in case anyone has a differing opinion. The deprecation should not be very noisy as such, but I expect it will require many projects to update their code in the long run (although the changes are very simple). One advantage is that some aliases are confusing, e.g. `np.float` is Python float, and thus actually a `float64` and not a C `float`, which is a `float32`. For an example of how this affects a code-base, this is SciPy: https://github.com/scipy/scipy/pull/12344/commits/02def703b8b7b28ed315a658808364fd024bb45c (A chunk of the full PR unrelated style fixes). Cheers, Sebastian [1] Full table of deprecated aliases: == = Deprecated Equivalent to Possibly intended numpy type == = ``numpy.bool`` ``bool`` `numpy.bool_` ``numpy.int`` ``int```numpy.int_` (default int dtype), `numpy.cint` (C ``int``) ``numpy.float`` ``float`` `numpy.float_`, `numpy.double` (equivalent) ``numpy.complex`` ``complex```numpy.complex_`, `numpy.cdouble` (equivalent) ``numpy.object````object`` `numpy.object_` ``numpy.str`` ``str```numpy.str_` ``numpy.long`` ``numpy.compat.long`` `numpy.int_` (C ``long``), `numpy.longlong` (largest integer type) ``numpy.unicode`` ``numpy.compat.str`` `numpy.unicode_` == = == signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating python type aliases (np.int, np.long, np.str, ...)
On Thu, 2020-06-11 at 09:59 -0500, Sebastian Berg wrote: > Hi all, > > In the pull request: https://github.com/numpy/numpy/pull/14882 > Eric proposes to deprecate the type aliases which NumPy imports > into its main namespace (e.g. np.int, np.bool, see table below [1]). > > Right now there seems to be a consensus to move this forward and I > plan > on doing that, so this is a heads-up in case anyone has a differing > opinion. > > > The deprecation should not be very noisy as such, but I expect it > will Sorry, I made a mistake when considering the implementation. It may be fairly noisy, but it is also very easy to avoid for the user. > require many projects to update their code in the long run (although > the changes are very simple). > > One advantage is that some aliases are confusing, e.g. `np.float` is > Python float, and thus actually a `float64` and not a C `float`, > which > is a `float32`. > > For an example of how this affects a code-base, this is SciPy: > https://github.com/scipy/scipy/pull/12344/commits/02def703b8b7b28ed315a658808364fd024bb45c > (A chunk of the full PR unrelated style fixes). > > Cheers, > > Sebastian > > > [1] Full table of deprecated aliases: > > == = == > == > Deprecated Equivalent to Possibly intended numpy > type > == = == > == > ``numpy.bool`` ``bool`` `numpy.bool_` > ``numpy.int`` ``int```numpy.int_` (default int > dtype), `numpy.cint` (C ``int``) > ``numpy.float`` ``float`` `numpy.float_`, > `numpy.double` (equivalent) > ``numpy.complex`` ``complex```numpy.complex_`, > `numpy.cdouble` (equivalent) > ``numpy.object````object`` `numpy.object_` > ``numpy.str`` ``str```numpy.str_` > ``numpy.long`` ``numpy.compat.long`` `numpy.int_` (C ``long``), > `numpy.longlong` (largest integer type) > ``numpy.unicode`` ``numpy.compat.str`` `numpy.unicode_` > == = == > > signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
