Re: [Python-Dev] Building Extensions for Python 3.5 on Windows
Hi, that is https://bugs.python.org/msg248716 see also http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest Steve: is there more of that in the new universal runtimes? Carl 2015-09-02 12:16 GMT+02:00 Paul Moore : > On 1 September 2015 at 17:15, Steve Dower wrote: > > On 01Sep2015 0747, Oscar Benjamin wrote: > >> > >> Thanks for the detailed writeup Steve. Do you know how these changes > >> to the python.org Windows binaries would impact on people building > >> extension modules with MinGW? > > > > > > Currently, no version of MinGW AFAIK will link against the UCRT, so > they'll > > suffer from the same mixed-CRT issues as with any other arrangement. > There > > is some work going towards making mingw-w64 work with UCRT, but I am not > > following it closely despite occasional contact with the dev(s) working > on > > it. > > One thing that I hit when trying to build vim with VS2015 is that it > appears that even compiled object code isn't linkable with the ucrt. I > don't know the correct terminology here, so let me explain in a bit > more detail (I'm doing this from memory, so some symbol names might be > wrong, but you'll get the idea, I hope). > > If source code refers to FILE* objects, then previously the compiled > object file (compiled with mingw) would be linkable with any of the > various C runtimes (msvcrt, msvcr10, etc). The object referred to a > symbol __iob_base which is present in all the CRTs. If the actual code > using the library doesn't actually use any of the functions that refer > to stdio, then whether the actual use of that symbol is broken doesn't > (seem to) matter in practice. > > That's likely to be luck, to a certain extent - there's no guarantee > that the internals of the FILE* abstraction are compatible between > CRTs, but it has been true thus far, and so use of object libraries > built with mingw are typically OK, as long as you avoid using things > that need the CRT types like FILE*. > > But with VS 2015 and the ucrt, there is no __iob_base symbol, and so > linking to code that refers to stdio fails. > > The consequence of this (I believe) is that not only does mingw need > to be able to link against the ucrt, but it also needs to *compile* > with ucrt-compatible headers. In particular, when compiling for the > ucrt, mingw needs to use a version of that doesn't reference > __iob_base. As the mingw developers maintain their own headers by some > process of "clean room" reimplementation (to satisfy the needs of the > GPL, as I understand it) updating the headers to cater for the ucrt > could be a non-trivial issue for them. I have no idea what their plans > are in this regard. > > The other side of this is that it means that all object libraries you > use need to be recompiled to target ucrt, you can't simply use > existing compiled libraries and relink. > > I hope this makes sense, and my interpretation is accurate - if I've > misunderstood the implications of the switch to the ucrt, then please > let me know. And if I'm wrong about not being able to use existing > compiled libraries, I would definitely appreciate someone telling me > what I'm doing wrong, because at the moment I'm unable to build my own > copy of vim with VS 2015 because I can't rebuild the xpm library :-( > > Paul > > PS My ultimate goal with building Vim with VS 2015 is to create a > build that uses the new embeddable distribution of Python 3.5 to > create a self-contained copy of Vim with Python 3.5 support enabled. > Something I think would be awesome :-) > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building Extensions for Python 3.5 on Windows
There are more semantic surprises as well. Some Math functions like powf, acosf and so on are available only with the help of the VS 2015 math.h include file (32 bit case). With exporting symbols names from the universal dll's and creating import libraries you are not done yet. Carl 2015-09-02 14:38 GMT+02:00 Paul Moore : > On 2 September 2015 at 13:01, Carl Kleffner wrote: > > that is https://bugs.python.org/msg248716 see also > > http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest > > Interesting. But it does confirm that object files have to be rebuilt, > and there's no way to use existing object files. So if your source > only builds with mingw, it needs mingw's headers updating before you > can do that rebuild. > > FWIW, in the case I hit with xpm, the xpm library only uses FILE* > internally - the external APIs are purely in terms of filenames. And > it only uses FILE* via the standard C APIs for it. So it's not a > simple case of "avoid using CRT types in external APIs". > > So unless I'm misunderstanding, *any* object code used in a project > (whether directly or from a 3rd party library) has to be build using a > compiler that supports the ucrt (which, given that mingw doesn't have > that support yet, means VS 2015 only). > > Note: I understand why the move to the ucrt is good, and I view this > as very much a short term transitional issue, but it is real and I > think it's important people understand the implications. > > Paul > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Embedding Python 3.5
A good overview on this topic is given on https://github.com/numpy/numpy/wiki/windows-dll-notes. As a side note the PATH is usually the latest place in the search order of DLLs. Pre-loading python35.dll into the process space from within vim could be a possible solution. 2015-09-09 16:30 GMT+02:00 Paul Moore : > First of all, an apology. I know this is probably going to be of > limited interest for many on python-dev, but I'm honestly not sure > where there's a better audience for the question. As it's related to > how people should use the new "embeddable" distribution of Python 3.5, > I'm hoping it's sufficiently relevant - but if not, feel free to > direct me to a better forum. > > I've been trying to use the new embeddable distribution to build a > Windows installation of vim that includes a Python interpreter, rather > than relying on the user having a system install of Python on PATH. > This strikes me as precisely the sort of usage that the embeddable > distribution would be great for. And indeed, it works fine for that. > But when it comes to distribution, I have an issue. > > The problem is that for vim to find the Python DLL, it needs to be > alongside vim.exe (there's a small complication here I'll come to > later, but let's ignore that for now). So I unzip the embeddable > distribution into the directory containing vim.exe. > > However, I want that directory on PATH (so I can run vim from the > command line). Now, as the embeddable distribution includes > python.exe, this pollutes my PATH with an extra copy of python, which > may or may not be picked up in preference to my "real" python, > depending on how I install python. That's bad - I can delete > python.exe and pythonw.exe from my vim installation, but I still have > a load of Python DLLs on PATH that could potentially mess up other > Python installations on my machine (I honestly don't know how likely > that is, particularly if I distribute my vim build to other users with > different setups). > > What I'd like to do is to put the Python stuff in a subdirectory of > the Vim installation, so it's safely isolated. In the case of vim, I > can do this, as vim has an option to dynamically load the Python DLL > via LoadLibrary, and I can patch vim to look in \python > before searching PATH. But the LoadLibrary stuff is horribly fragile, > and I doubt anyone else embedding Pthon in their application is likely > to do that - they will probably just link to python35.dll at > load-time. > > I'm not aware of any way to adjust the loader's search path for DLLs > to include a subdirectory that's not on PATH, so it seems to me that > there's no good way to avoid having the embeddable distribution > visible via the user's PATH. > > For vim, I'll probably go for the dynamic loading approach with a > patch to look in a subdirectory. But have I missed any other > approaches that make an embedded Python more isolated from the user's > system? > > Paul > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
Concerning the claims that mingw is difficult: The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, that is in development. It is designed for simple use and for much better compatibility to the standard MSVC python builds. It should work out of the box, as long as the \Scripts folder is in the PATH. It is not 'officially' released and announced, due to the fact that some features are missing, the documentation has to be written and the build scripts for the toolchain are not (yet) published. Install a prerelease of mingwpy with pip: pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy or with conda: (thanks to omnia-md) conda install -c https://conda.anaconda.org/omnia mingwpy and use it at usual with pip install or python setup.py You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy if you have an MSVC compiler installed: [config] compiler=mingw32 [build] compiler=mingw32 [build_ext] compiler=mingw32 Or you install the latest portable winpython distribution https://winpython.github.io that contains the toolchain as well and works out of the box. Future releases of mingwpy will be deployed on Pypi. That has to be said: the main emphasis of the toolchain is building python binary extension (C, C++, GFORTRAN) on windows, not building python itself. Carl 2015-09-30 21:15 GMT+02:00 Paul Moore : > On 30 September 2015 at 16:57, Chris Barker - NOAA Federal > wrote: > >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) > >> 2. Work from an SDK command prompt (with the environment variables > >> set, and the SDK on PATH). > >> 3. Set DISTUTILS_USE_SDK=1 > >> 4. Done. > > > > This, unfortunately is non-trivial, and really a pain if you want to > > automate builds. > > Please clarify. What is non-trivial? Installing the SDK? I know, but > we said that's out of scope. Using an SDK command prompt? It is, sort > of, particularly if (like me) you use powershell. But again, not our > issue. I assume setting the environment variable isn't an issue - you > can do it for the session rather than globally, so even restrictive > permissions aren't a problem. > > I appreciate you mightn't be intending this as criticism of the > instructions, but many people do criticise in exactly this sort of > way. Unix developers, in particular, who have limited Windows > knowledge, find this level of instruction really frustrating to deal > with. That's not a complaint - I have *huge* appreciation for > non-Windows users who bother to make builds for Windows users - but it > is an acknowledgement that often the audience for this sort of > instruction are stumped by Microsoft's less than intuitive install > processes... > > For context, installing mingw is just as messy, complicated and error > prone (I speak from experience :-)) so it's unfair to complain that > the above is a non-trivial pain. I know of no install option that's > *less* straightforward than this (except of course for "install any > version of Visual Studio 2010, even the free ones" - if you have > access to those, use them!) > > For automation, why not use Appveyor? See > https://packaging.python.org/en/latest/appveyor/ Unless you meant > setting up a local build machine. If you want a simple "install a > Python build environment" process, you could look at > https://github.com/pfmoore/pybuild - I haven't used it in a while (as > it's of no relevance to me, because I have VS2010) but it does work. I > never publicised or distributed it, because I got too much pushback in > terms of "but it doesn't work right on my system" (typically because > the system in question usually *wasn't* a clean build of Windows) that > I didn't have time or energy to address. But if it works for you, go > for it. > > I'll push an addition to packaging.python.org, probably tomorrow. > > Paul > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
It should be possible with Wine. Am 30.09.2015 22:50 schrieb "Laurent Gautier" : > Hi Carl, > > Looks promising. > > Any chance the effort would consider cross-compiling (from Linux) as a > possible objective ? > > Best, > > Laurent > > On Wed, Sep 30, 2015, 3:58 PM Carl Kleffner wrote: > >> Concerning the claims that mingw is difficult: >> >> The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, >> that is in development. It is designed for simple use and for much better >> compatibility to the standard MSVC python builds. It should work out of the >> box, as long as the \Scripts folder is in the PATH. >> >> It is not 'officially' released and announced, due to the fact that some >> features are missing, the documentation has to be written and the build >> scripts for the toolchain are not (yet) published. >> >> Install a prerelease of mingwpy with pip: >> >> pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy >> >> or with conda: (thanks to omnia-md) >> >> conda install -c https://conda.anaconda.org/omnia mingwpy >> >> and use it at usual with pip install or python setup.py >> >> You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy >> if you have an MSVC compiler installed: >> >> [config] >> compiler=mingw32 >> [build] >> compiler=mingw32 >> [build_ext] >> compiler=mingw32 >> >> Or you install the latest portable winpython distribution >> https://winpython.github.io that contains the toolchain as well and >> works out of the box. >> >> Future releases of mingwpy will be deployed on Pypi. >> >> That has to be said: the main emphasis of the toolchain is building >> python binary extension (C, C++, GFORTRAN) on windows, not building python >> itself. >> >> Carl >> >> 2015-09-30 21:15 GMT+02:00 Paul Moore : >> >>> On 30 September 2015 at 16:57, Chris Barker - NOAA Federal >>> wrote: >>> >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) >>> >> 2. Work from an SDK command prompt (with the environment variables >>> >> set, and the SDK on PATH). >>> >> 3. Set DISTUTILS_USE_SDK=1 >>> >> 4. Done. >>> > >>> > This, unfortunately is non-trivial, and really a pain if you want to >>> > automate builds. >>> >>> Please clarify. What is non-trivial? Installing the SDK? I know, but >>> we said that's out of scope. Using an SDK command prompt? It is, sort >>> of, particularly if (like me) you use powershell. But again, not our >>> issue. I assume setting the environment variable isn't an issue - you >>> can do it for the session rather than globally, so even restrictive >>> permissions aren't a problem. >>> >>> I appreciate you mightn't be intending this as criticism of the >>> instructions, but many people do criticise in exactly this sort of >>> way. Unix developers, in particular, who have limited Windows >>> knowledge, find this level of instruction really frustrating to deal >>> with. That's not a complaint - I have *huge* appreciation for >>> non-Windows users who bother to make builds for Windows users - but it >>> is an acknowledgement that often the audience for this sort of >>> instruction are stumped by Microsoft's less than intuitive install >>> processes... >>> >>> For context, installing mingw is just as messy, complicated and error >>> prone (I speak from experience :-)) so it's unfair to complain that >>> the above is a non-trivial pain. I know of no install option that's >>> *less* straightforward than this (except of course for "install any >>> version of Visual Studio 2010, even the free ones" - if you have >>> access to those, use them!) >>> >>> For automation, why not use Appveyor? See >>> https://packaging.python.org/en/latest/appveyor/ Unless you meant >>> setting up a local build machine. If you want a simple "install a >>> Python build environment" process, you could look at >>> https://github.com/pfmoore/pybuild - I haven't used it in a while (as >>> it's of no relevance to me, because I have VS2010) but it does work. I >>> never publicised or distributed it, because I got too much pushback in >>> terms of "but it doesn't work right on my system" (typically because >>> the sys
Re: [Python-Dev] modernizing IDLE
there is also http://idlex.sourceforge.net/about.html to mention. 2015-11-06 18:08 GMT+01:00 Mark Roseman : > Just wanted to share some documentation I’ve put together (and a snapshot > of the code) on the effort to improve the appearance and behaviour of IDLE: > > http://www.tkdocs.com/tutorial/idle.html > > (There’s also currently a post on Hacker News about this). > > While Terry can better speak to plans and timelines about getting these > changes integrated in, it seems a good time to get some other people to > have a closer look and share any feedback. > > Mark > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Memory
AFAIK Burkhard A. Meier is the author of the Python GUI Programming Cookbook (Packtpub). I wonder if someone has hacked is gmail account? 2016-05-01 18:51 GMT+02:00 Steven D'Aprano : > On Sun, May 01, 2016 at 08:08:22AM -0500, Ryan Gonzalez wrote: > > Well, I put this in Google Translate...and got this: > > > > The disk clatters > > the Spontie giggles > > ~ > > hopefully > > alliance insures ... > > > > Not sure if this a useless post or Translate just being weird. Leaning > > towards the latter... > > You missed the link to David Bowie's "Heroes" on YouTube. > > I'm pretty sure that this is a useless post. > > Burkhard, please speak English on this list, as best as you are able. > And please avoid rambling cryptic posts and topics which have nothing to > do with the development of CPython. If you want to share random > thoughts, you should get a blog or a Twitter account, don't post them > here. > > > Thank you. > > > > -- > Steve > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
