date:20230321

[Numpy-discussion] Linking F2PY to Openblas on Windows

2023-03-21 Thread Ilhan Polat

Dear all,

I'd like to submit to our f2py crew here for a seemingly trivial problem
that has been bugging me for a while. I am trying to compile a Fortran
library (SLICOT [1] ) on windows with MinGW UCRT 64 interface. But let me
simplify the issue.

Let say I have a fortran file, MB01OE.f. It is a standalone code with only
extenal dependency of bunch of LAPACK routines and I'd like to compile this
into a module (if I can pull this off, I can include the rest) Hence I
thought I can just link it with the existing OpenBLAS on my computer.

Hence I use the following command

 f2py -L/opt/64/lib/ -lopenblas -c --verbose
.\SLICOT-Reference\src\MB01OE.f --lower -m slicot

which then gives me the output below. My original plan was to use meson for
this but I can't even make the manual route work so that would wait until I
fix this issue. I'd be grateful if someone can spot the mistake I'm making.


[1] : https://github.com/SLICOT/SLICOT-Reference




running build
running config_cc
INFO: unifing config_cc, config, build_clib, build_ext, build commands
--compiler options
running config_fc
INFO: unifing config_fc, config, build_clib, build_ext, build commands
--fcompiler options
running build_src
INFO: build_src
INFO: building extension "slicot" sources
INFO: f2py options: ['--lower']
INFO: f2py:>
C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10\slicotmodule.c
creating C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10
Reading fortran codes...
Reading file '.\\SLICOT-Reference\\src\\MB01OE.f'
(format:fix,strict)
Line #107 in .\SLICOT-Reference\src\MB01OE.f:"  PARAMETER (
ZERO = 0.0D0, ONE = 1.0D0, TWO = 2.0D0 )"
get_parameters: got "eval() arg 1 must be a string, bytes or code
object" on 4
Line #107 in .\SLICOT-Reference\src\MB01OE.f:"  PARAMETER (
ZERO = 0.0D0, ONE = 1.0D0, TWO = 2.0D0 )"
get_parameters: got "eval() arg 1 must be a string, bytes or code
object" on 4
Line #107 in .\SLICOT-Reference\src\MB01OE.f:"  PARAMETER (
ZERO = 0.0D0, ONE = 1.0D0, TWO = 2.0D0 )"
get_parameters: got "eval() arg 1 must be a string, bytes or code
object" on 4
rmbadname1: Replacing "max" with "max_bn".
Post-processing...
Block: slicot
Block: mb01oe
In: :slicot:.\SLICOT-Reference\src\MB01OE.f:mb01oe
get_parameters: got "eval() arg 1 must be a string, bytes or code object"
on 4
In: :slicot:.\SLICOT-Reference\src\MB01OE.f:mb01oe
get_parameters: got "eval() arg 1 must be a string, bytes or code object"
on 4
In: :slicot:.\SLICOT-Reference\src\MB01OE.f:mb01oe
get_parameters: got "eval() arg 1 must be a string, bytes or code object"
on 4
Applying post-processing hooks...
  character_backward_compatibility_hook
Post-processing (stage 2)...
Building modules...
Building module "slicot"...
Generating possibly empty wrappers"
Maybe empty "slicot-f2pywrappers.f"
Constructing wrapper function "mb01oe"...
getarrdims:warning: assumed shape array, using 0 instead of '*'
getarrdims:warning: assumed shape array, using 0 instead of '*'
getarrdims:warning: assumed shape array, using 0 instead of '*'
  mb01oe(uplo,trans,n,alpha,beta,r,h,e,[ldr,ldh,lde])
Wrote C/API module "slicot" to file
"C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10\slicotmodule.c"
INFO:   adding
'C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10\fortranobject.c'
to sources.
INFO:   adding
'C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10' to
include_dirs.
copying
C:\Users\ilhan\AppData\Local\Programs\Python\Python310\lib\site-packages\numpy\f2py\src\fortranobject.c
-> C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10
copying
C:\Users\ilhan\AppData\Local\Programs\Python\Python310\lib\site-packages\numpy\f2py\src\fortranobject.h
-> C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10
INFO:   adding
'C:\Users\ilhan\AppData\Local\Temp\tmpr1ct3ys_\src.win-amd64-3.10\slicot-f2pywrappers.f'
to sources.
INFO: build_src: building npy-pkg config files
running build_ext
INFO: No module named 'numpy.distutils._msvccompiler' in numpy.distutils;
trying from distutils
DEBUG: new_compiler returns 
INFO: customize MSVCCompiler
INFO: customize MSVCCompiler using build_ext


libraries = []
library_dirs  =
['C:\\Users\\ilhan\\AppData\\Local\\Programs\\Python\\Python310\\libs',
'C:\\Users\\ilhan\\AppData\\Local\\Programs\\Python\\Python310\\PCbuild\\amd64']
include_dirs  =
['C:\\Users\\ilhan\\AppData\\Local\\Programs\\Python\\Python310\\include',
'C:\\Users\\ilhan\\AppData\\Local\\Programs\\Python\\Python310\\Include']

Unable to find productdir in registry
Env var VS140COMNTOOLS is not set or invalid
No productdir found
INFO: get_default_fcompiler: matching types: '['gnu', 'intelv', 'absoft',
'compaqv',

[Numpy-discussion] Re: dropping support for Gitpod and our Docker image builds

2023-03-21 Thread Ralf Gommers

On Tue, Mar 21, 2023 at 12:20 PM Klaus Zimmermann 
wrote:

> Hi,
>
> this sounds all reasonable to me, and as mostly a lurker on this list my
> input shouldn't carry too much weight anyway.
>
> I wanted to point out one thing: Docker does continue to offer free
> access for Open Source projects, it's just that they restructured the
> way of how to do this. So if there is still value in Docker, an
> application to the Docker-Sponsored Open Source tier should certainly
> fit Numpy. A bit more information is at
>
> https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/
>

Thanks for the suggestion Klaus. It doesn't really fit us. I've spoken to
multiple maintainers of other projects who went through this application
process. It's very bureaucratic, may take months, and is only meant for
projects with needs a lot higher than hours (as determined by an actual
interview apparently). On Twitter I've seen similar sentiments from
maintainers. So I'm pretty sure it's not worth applying for that.

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: dropping support for Gitpod and our Docker image builds

2023-03-21 Thread Melissa Mendonça

Hi all,

As a heavy user of Gitpod (mostly for quick fixes) I would also like to
point out that you *can* still use it - it's just that the development
environment won't be set up by default. I agree it has been breaking far
too often and requires a lot of optimization to reach reasonable setup
times, and while I haven't been using the codespaces setup I can see the
gain in maintenance effort there.

Cheers,

Melissa

On Tue, Mar 21, 2023 at 9:21 AM Klaus Zimmermann 
wrote:

> Hi,
>
> this sounds all reasonable to me, and as mostly a lurker on this list my
> input shouldn't carry too much weight anyway.
>
> I wanted to point out one thing: Docker does continue to offer free
> access for Open Source projects, it's just that they restructured the
> way of how to do this. So if there is still value in Docker, an
> application to the Docker-Sponsored Open Source tier should certainly
> fit Numpy. A bit more information is at
>
> https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/
>
> Cheers
> Klaus
>
>
> On 20/03/2023 22:09, Ralf Gommers wrote:
> > Hi all,
> >
> > We received a notification from Docker that there Free Team organization
> > no longer exists, and that we have until April 14 to upgrade to a paid
> > tier. We only use Docker to support Gitpod. Gitpod builds have been
> > broken in main for quite a while (see
> > https://github.com/numpy/numpy/actions/workflows/gitpod.yml
> > ). Since
> > it's a cron job that doesn't show up on PRs, but I get the notifications.
> >
> > Overall, Gitpod has been useful during some sprints, but it has proven
> > to be too much maintenance effort. Maintaining a Docker team, CI jobs
> > for building 2 Docker images, and a nontrivial amount of code and docs
> > is no longer a good tradeoff.
> >
> > Here is what we have related to Gitpod:
> > https://github.com/numpy/numpy/tree/main/tools/gitpod
> > 
> > https://github.com/numpy/numpy/blob/main/.github/workflows/docker.yml
> > 
> > https://github.com/numpy/numpy/blob/main/.github/workflows/gitpod.yml
> > 
> >
> https://github.com/numpy/numpy/blob/main/doc/source/dev/development_gitpod.rst
> <
> https://github.com/numpy/numpy/blob/main/doc/source/dev/development_gitpod.rst
> >
> > https://hub.docker.com/u/numpy 
> >
> > We have a reasonable alternative, which is GitHub Codespaces. All it
> > currently requires is ~lines of simple to understand code
> > (https://github.com/numpy/numpy/tree/main/.devcontainer
> > ) and no CI
> > jobs. We have one tracking issue for feedback in case you try it and
> > find gaps: https://github.com/numpy/numpy/issues/23134
> > . It doesn't pre-build
> > NumPy locally, but that's only 1-2 minutes of wait time and is something
> > a new contributor anyway has to learn about. The dev environment is
> > reproducible, so this isn't much of a hurdle. We need replacement docs
> > for that, but they can be much simpler I'd say. It's basically "go to
> > https://github.com/codespaces/ , hit
> the
> > green button, and select the numpy repo, then it'll drop you into a
> > VSCode IDE with a ready to go dev env".
> >
> > So my proposal is to drop all the Docker Hub and Gitpod related code and
> > docs. I have already discussed this with Tania Allard, who did most of
> > the heavy lifting on the initial creation of the Gitpod machinery (for
> > SciPy, which was then synced to NumPy).
> >
> > Thoughts?
> >
> > 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: klaus.zimmerm...@smhi.se
> ___
> 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: meliss...@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: dropping support for Gitpod and our Docker image builds

2023-03-21 Thread Klaus Zimmermann

Hi,

this sounds all reasonable to me, and as mostly a lurker on this list my
input shouldn't carry too much weight anyway.

I wanted to point out one thing: Docker does continue to offer free
access for Open Source projects, it's just that they restructured the
way of how to do this. So if there is still value in Docker, an
application to the Docker-Sponsored Open Source tier should certainly
fit Numpy. A bit more information is at
https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/

Cheers
Klaus

On 20/03/2023 22:09, Ralf Gommers wrote:

Hi all,

We received a notification from Docker that there Free Team organization
no longer exists, and that we have until April 14 to upgrade to a paid
tier. We only use Docker to support Gitpod. Gitpod builds have been
broken in main for quite a while (see
https://github.com/numpy/numpy/actions/workflows/gitpod.yml
). Since
it's a cron job that doesn't show up on PRs, but I get the notifications.

Overall, Gitpod has been useful during some sprints, but it has proven
to be too much maintenance effort. Maintaining a Docker team, CI jobs
for building 2 Docker images, and a nontrivial amount of code and docs
is no longer a good tradeoff.

Here is what we have related to Gitpod:
https://github.com/numpy/numpy/tree/main/tools/gitpod

https://github.com/numpy/numpy/blob/main/.github/workflows/docker.yml

https://github.com/numpy/numpy/blob/main/.github/workflows/gitpod.yml

https://github.com/numpy/numpy/blob/main/doc/source/dev/development_gitpod.rst

https://hub.docker.com/u/numpy

We have a reasonable alternative, which is GitHub Codespaces. All it
currently requires is ~lines of simple to understand code
(https://github.com/numpy/numpy/tree/main/.devcontainer
) and no CI
jobs. We have one tracking issue for feedback in case you try it and
find gaps: https://github.com/numpy/numpy/issues/23134
. It doesn't pre-build
NumPy locally, but that's only 1-2 minutes of wait time and is something
a new contributor anyway has to learn about. The dev environment is
reproducible, so this isn't much of a hurdle. We need replacement docs
for that, but they can be much simpler I'd say. It's basically "go to
https://github.com/codespaces/ , hit the
green button, and select the numpy repo, then it'll drop you into a
VSCode IDE with a ready to go dev env".

So my proposal is to drop all the Docker Hub and Gitpod related code and
docs. I have already discussed this with Tania Allard, who did most of
the heavy lifting on the initial creation of the Gitpod machinery (for
SciPy, which was then synced to NumPy).

Thoughts?

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: klaus.zimmerm...@smhi.se

[Numpy-discussion] Linking F2PY to Openblas on Windows

[Numpy-discussion] Re: dropping support for Gitpod and our Docker image builds

[Numpy-discussion] Re: dropping support for Gitpod and our Docker image builds

[Numpy-discussion] Re: dropping support for Gitpod and our Docker image builds

4 matches

Site Navigation

Mail list logo

Footer information