XD blog

blog page

windows


2015-08-23 Building xgboost on Windows for Python

I'm unlucky. The day I decide to deal with xgboost on Windows, a couple of hours later, I see a commit which does that. xgboost is now on pipy even if the version for Python 3 is not ready yet (Missing parentheses in call to 'print').


more...

2014-10-26 Quelques outils pour faire des captures vidéo d'écrans

Logiciels (gratuits) :

Articles :

2014-10-25 agt-get on Windows = chocolatey

Installing a package is quite convenient on Linux : there is only one way. On Windows, you usually go to each software website and download the setup from there. But there exists another option now: chocolatey. Once it is installed, you can install a software just like that:

choco install notepadplusplus

2014-09-17 An issue or something to know with pythonnet

pythonnet is a module which can access .net assemblies (written in C# for example).

from clr import AddReference
AddReference("something.dll or .exe")

It only works if the DLL can be found in one path in sys.path and also if all dependencies are located in the same folder. If it is not the case, dependencies must be loaded first.

from clr import AddReference
import sys
sys.path.append("path to dependencies.dll")
AddReference("dependencies.dll")
sys.path.append("path to something.dll")
AddReference("something.dll or .exe")

2013-10-23 Using pythonnet

I migrated over Windows 8.1 and I realized my version of pythonnet for Python did not work anymore. I got the following error:

ImportError: dynamic module does not define init function (PyInit_clr)
I did not really try to understand but I knew I had to access the sources first because the official website of pythonnet does not provide any version for python 3.x. So I looked for pythonnet on github, I found this. I got the sources which did not compile on the first try unless I apply the three following modifications: After the compilation completed (on Windows 8.1 + Visual Studio 2012, 2013), I could use the two files clr.pyd and Python.Runtime.dll the same way. There were some others modifications I do not remember exactly. Anyway, my version is located here sdpython/pythonnet.

2013-07-07 Build a Python 64 bit extension on Windows 8

I was using MinGW on Windows to build a Python extension including C++ code. The 32bit mode was working fine and I was using the following command line:

python setup.by build --compiler=mingw32
I thought it would be easy to run it with the Python 64 bit version. No change would be required. I was a little bit over confident.
Traceback (most recent call last):
  File "setup.py", line 11, in <module>
    author_email  = '...',
  File "c:\python33_x64\lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "c:\python33_x64\lib\distutils\dist.py", line 929, in run_commands
    self.run_command(cmd)
  File "c:\python33_x64\lib\distutils\dist.py", line 948, in run_command
    cmd_obj.run()
  File "c:\python33_x64\lib\distutils\command\build_ext.py", line 323, in run
    force=self.force)
  File "c:\python33_x64\lib\distutils\ccompiler.py", line 1034, in new_compiler
    return klass(None, dry_run, force)
  File "c:\python33_x64\lib\distutils\cygwinccompiler.py", line 125, in __init__
    if self.ld_version >= "2.10.90":
TypeError: unorderable types: NoneType() >= str()
I decided to switch to Visual Studio Express 2012 to build my extension. but I went through some error related to the file vcvarsall.bat because Python was not able to find the file vsvars64.bat (for one very good reason, it does not exist). I read some blogs where people suggest to reinstall Visual Studio Express but I did not remember the setup asking me anything about options. When I checked the folder of Visual Studio, I found the following file vcvarsx86_amd64.bat. Then, after some research (stubborness is mandatory for those parts) and some tweaks, I discovered two mistakes in the package distutils. They need to be fixed in the file msvc9compiler.py: After the two modifications, it was working fine with the following command line:
python setup.by build --compiler=msvc --plat-name=win-amd64
And I understood why it was failing without any mysterious new installation. I checked about 64 bit version of MinGW but it looked a longer path than the one I chose. Who knows? You will find some others details here. I wrote a function which import a module written in one single C++ file. If the module does not exist, it compiles it inplace.

As a conclusion, I would say it was difficult to find the proper instructions. Maybe the number of documents related to that issue has increased, or the search engines I used were not able to give me the answer. All I know is I do not want to go through that again even if I know there will be a next time when I update Python or when I change my laptop. I hope next time I face that problem, search engines will show me my own page.


Xavier Dupré