any progress on cython for windows 64 bit ?

[stone...@gmail.com]

Hi,

I don't see any change on https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows

Is it still a lost cause to get cython working on windows 64 with a gcc or llvm compiler ?

[Ian Henriksen]

I think the current status is that it works, but it isn't officially supported. I'd be willing to update the wiki page if the developers are interested in adding support for it. The Anaconda Distribution ships a 64 bit version of MinGW that works for compiling Cython extensions, so I'd assume that using gcc for this is fairly widespread. The MinGW-builds project has good binaries available. I've had success using MinGW 4.7 (from Anaconda), 4.8 (MinGW-builds), and 4.9 (MinGW-builds). Earlier versions probably won't work since there was an ABI update in version 4.7. I could be wrong, but my understanding is that the ABI update was what allowed this sort of thing to work at all.

To configure Python to use distutils, you'll want to make the distutils.cfg file in <python_path>/Lib/distutils that contains

[build]

compiler=mingw32

[build_ext]

compiler = mingw32 

You'll also want to be sure that gcc is on your path and that you have installed the proper dlls for compiling C extensions for 64 bit windows. You can get them here.

I can't speak for clang/llvm. I've fiddled with it a little but haven't had any success in getting the standard library headers from mingw64 included at compilation time for clang. I'm not aware of any good 64 bit binaries for it either. If you wanted to use it for compiling Python extensions on windows, you'd probably want to start by looking at the Python patch that adds support for clang to distutils. If you're really lucky, you may be able to get a 64 bit version of clang compiled and configured to use the standard library from MinGW and then be able to compile extensions using the patch shown in the Python issue. If you decide to try this, be aware that the patch is for Python 3.4. I can't say whether or not that works. I've only used gcc/g++/gfortran for this sort of thing. In theory, it should be possible, but it would still probably be an awful pain.

I hope this helps.

-Ian Henriksen

[Sturla Molden]

<stone...@gmail.com> wrote:

> Is it still a lost cause to get cython working on windows 64 with a gcc or
> llvm compiler ?

https://github.com/numpy/numpy/wiki/Mingw-static-toolchain

[stone...@gmail.com]

hum,

I don't feel it but I didn't succeed to set up a working alternative since last time you sugggested it

Will try today

[stone...@gmail.com]

boum !

I think I remember now I saw something about python 3

D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\lib\site-packages\IPython\core\magic.py in <lambda>(f, *a, **k)
    191     # but it's overkill for just that one bit of state.
    192     def magic_deco(arg):
--> 193         call = lambda f, *a, **k: f(*a, **k)
    194 
    195         if callable(arg):

D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\lib\site-packages\IPython\extensions\cythonmagic.py in cython(self, line, cell)
    269             self._code_cache[key] = module_name
    270 
--> 271         module = imp.load_dynamic(module_name, module_path)
    272         self._import_all(module)
    273 

D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\Scripts\stringsource in init _cython_magic_8ff05497b86c77c64d80657a18455241 (D:\result_tests\WinPython-64bit-3.4.1.2_build07\settings\.ipython\cython\_cython_magic_8ff05497b86c77c64d80657a18455241.c:13258)()

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x83 in position 1: invalid start byte

[Sturla Molden]

This looks like en Ipython unicode error. It might not be Cython or MinGW
related at all. Try to compile and run a Cython module without the Ipython
notebook first.

Sturla

>>> <a
>>> href="https://github.com/numpy/numpy/wiki/Mingw-static-toolchain">https://github.com/numpy/numpy/wiki/Mingw-static-toolchain</a>
>>>
>>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "cython-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cython-users...@googlegroups.com.
> For more options, visit <a
> href="https://groups.google.com/d/optout.">https://groups.google.com/d/optout.</a>
>
> ------=_Part_1655_1626455223.1411894147070
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir="ltr">boum !<br><br>I think I remember now I saw something about
> python 3<br><br><pre><span class="ansicyan"><span
> class="ansigreen">D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\lib\site-packages\IPython\core\magic.py</span>
> in <span class="ansicyan">&amp;lt;lambda&amp;gt;<span class="ansiblue">(f, *a, **k)</span>
> <span class="ansigreen"> 191</span> <span class="ansired"># but
> it's overkill for just that one bit of state.</span><span
> class="ansiyellow"></span><span class="ansiyellow"></span></span>
> <span class="ansigreen"> 192</span> <span
> class="ansigreen">def</span> </span>magic_deco<span
> class="ansiyellow">(</span>arg<span class="ansiyellow">)</span><span
> class="ansiyellow">:</span><span class="ansiyellow"></span>
> <span class="ansigreen">--&amp;gt; 193<span class="ansiyellow">
> </span>call</span> <span class="ansiyellow">=</span> <span
> class="ansigreen">lambda</span> f<span class="ansiyellow">,</span> <span
> class="ansiyellow">*</span>a<span class="ansiyellow">,</span> <span
> class="ansiyellow">**</span>k<span class="ansiyellow">:</span> f<span
> class="ansiyellow">(</span><span class="ansiyellow">*</span>a<span
> class="ansiyellow">,</span> <span class="ansiyellow">**</span>k<span
> class="ansiyellow">)</span><span class="ansiyellow"></span>
> <span class="ansigreen"> 194</span> <span class="ansiyellow"></span>
> <span class="ansigreen"> 195</span> <span
> class="ansigreen">if</span> callable<span
> class="ansiyellow">(</span>arg<span class="ansiyellow">)</span><span
> class="ansiyellow">:</span><span class="ansiyellow"></span>
>
> <span
> class="ansigreen">D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\lib\site-packages\IPython\extensions\cythonmagic.py</span>
> in <span class="ansicyan">cython<span class="ansiblue">(self, line, cell)</span>
> <span class="ansigreen"> 269</span> </span>self<span
> class="ansiyellow">.</span>_code_cache<span
> class="ansiyellow">[</span>key<span class="ansiyellow">]</span> <span
> class="ansiyellow">=</span> module_name<span class="ansiyellow"></span>
> <span class="ansigreen"> 270</span> <span class="ansiyellow"></span>
> <span class="ansigreen">--&amp;gt; 271<span class="ansiyellow">
> </span>module</span> <span class="ansiyellow">=</span> imp<span
> class="ansiyellow">.</span>load_dynamic<span
> class="ansiyellow">(</span>module_name<span class="ansiyellow">,</span>
> module_path<span class="ansiyellow">)</span><span class="ansiyellow"></span>
> <span class="ansigreen"> 272</span> self<span
> class="ansiyellow">.</span>_import_all<span
> class="ansiyellow">(</span>module<span class="ansiyellow">)</span><span
> class="ansiyellow"></span>
> <span class="ansigreen"> 273</span> <span class="ansiyellow"></span>
>
> <span
> class="ansigreen">D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\Scripts\stringsource</span>
> in <span class="ansicyan">init
> _cython_magic_8ff05497b86c77c64d80657a18455
> 41 (D:\result_tests\WinPython-64bit-3.4.1.2_build07\settings\.ipython\cython\_cython_magic_8ff05497b86c77c64d80657a18455241.c:13258)<span
> class="ansiblue">()</span>
>
> <span class="ansired">UnicodeDecodeError</span>: 'utf-8' codec can't
> decode byte 0x83 in position 1: invalid start byte</span></pre><br><br>On

> Sunday, September 28, 2014 10:31:21 AM UTC+2, stone...@gmail.com

> wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left:
> 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div
> dir="ltr">hum,<br><br>I don't feel it but I didn't succeed to set up a
> working alternative since last time you sugggested it<br><br>Will try
> today<br><br>On Sunday, September 28, 2014 3:49:25 AM UTC+2, Sturla Molden
> wrote:<blockquote class="gmail_quote"
> style="margin:0;margin-left:0.8ex;border-left:1px #ccc
> solid;padding-left:1ex">&amp;lt;<a>stone...@gmail.com</a>&amp;gt; wrote:
> <br>
> <br>&amp;gt; Is it still a lost cause to get cython working on windows 64 with a gcc or
> <br>&amp;gt; llvm compiler ?
> <br>
> <br><a href="https://github.com/numpy/numpy/wiki/Mingw-static-toolchain"
> target="_bla
> k" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fwiki%2FMingw-static-toolchain\46sa\75D\46sntz\0751\46usg\75AFQjCNEaQ-HJhKNM_m3joTBy1SChA6w3mQ';return
> true;"
> onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fwiki%2FMingw-static-toolchain\46sa\75D\46sntz\0751\46usg\75AFQjCNEaQ-HJhKNM_m3joTBy1SChA6w3mQ';return
> true;">https://github.com/numpy/<wbr>numpy/wiki/Mingw-static-<wbr>toolchain</a>
> <br>
> <br></blockquote></div></blockquote></div>
>
> <p></p>
>
> -- <br />
> <br />
> --- <br />
> You received this message because you are subscribed to the Google Groups
> &amp;quot;cython-users&amp;quot; group.<br />
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> <a href="mailto:cython-users...@googlegroups.com">cython-users...@googlegroups.com</a>.<br
> />
> For more options, visit <a
> href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br />
>
> ------=_Part_1655_1626455223.1411894147070--

[Stefan Behnel]

Sturla Molden schrieb am 28.09.2014 um 11:40:
> <stone...@gmail.com> wrote:
>> boum !
>>
>> I think I remember now I saw something about python 3
>>
>> D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\lib\site-packages\IPython\core\magic.py
>> in <lambda>(f, *a, **k) 191 # but it's overkill for just that one
>> bit of state. 192 def magic_deco(arg):--> 193 call =
>> lambda f, *a, **k: f(*a, **k) 194 195 if callable(arg):
>> D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\lib\site-packages\IPython\extensions\cythonmagic.py
>> in cython(self, line, cell) 269 self._code_cache[key] =
>> module_name 270 --> 271 module = imp.load_dynamic(module_name,
>> module_path) 272 self._import_all(module) 273
>> D:\result_tests\WinPython-64bit-3.4.1.2_build07\python-3.4.1.amd64\Scripts\stringsource in
>> init _cython_magic_8ff05497b86c77c64d80657a18455241
>> (D:\result_tests\WinPython-64bit-3.4.1.2_build07\settings\.ipython\cython\_cython_magic_8ff05497b86c77c64d80657a18455241.c:13258)()
>> UnicodeDecodeError: 'utf-8' codec can't decode byte 0x83 in position 1: invalid start byte
>>

> This looks like en Ipython unicode error.

Or an actual bug in the user code that the notebook is executing here.
Seeing the code would help.

Stefan

[stone...@gmail.com]

I will,

In mean time, I discovered i was not using cython 0.21.
After fixing that I get  :
* the same error
 D:\result_tests\WinPython-64bit-3.4.1.2_build14\python-3.4.1.amd64\lib\site-packages\IPython\extensions\cythonmagic.py in cython(self, line, cell) 269 self._code_cache[key] = module_name 270 --> 271 module = imp.load_dynamic(module_name, module_path) 272 self._import_all(module) 273 D:\result_tests\WinPython-64bit-3.4.1.2_build14\python-3.4.1.amd64\Scripts\stringsource in init _cython_magic_c45ed9c661cd7ad092c4f148ac9547d7 (D:\result_tests\WinPython-64bit-3.4.1.2_build14\settings\.ipython\cython\_cython_magic_c45ed9c661cd7ad092c4f148ac9547d7.c:13292)() UnicodeDecodeError: 'utf-8' codec can't decode byte 0x83 in position 1: invalid start byte

* a photography of the dos window and task manager says :
- that I blew up in memory,
- something maybe usefull
https://github.com/stonebig/ztest_donotuse/blob/master/cython64_from_numpy_issue1.GIF
https://github.com/stonebig/ztest_donotuse/blob/master/cython64_from_numpy_issue1bis.GIF

> <a href="mailto:cython-users+unsub...@googlegroups.com">cython-users+unsubscribe@googlegroups.com</a>.<br

[stone...@gmail.com]

code is
%%cython
import numpy as np
cimport cython
from libc.math cimport sqrt

@cython.boundscheck(False)
@cython.wraparound(False)
def pairwise_cython(double[:, ::1] X):
    cdef int M = X.shape[0]
    cdef int N = X.shape[1]
    cdef double tmp, d
    cdef double[:, ::1] D = np.empty((M, M), dtype=np.float64)
    for i in range(M):
        for j in range(M):
            d = 0.0
            for k in range(N):
                tmp = X[i, k] - X[j, k]
                d += tmp * tmp
            D[i, j] = sqrt(d)
    return np.asarray(D)

like in http://nbviewer.ipython.org/github/stonebig/winpython_afterdoc/blob/master/examples/using_cython_under_winpython32bit.ipynb

[stone...@gmail.com]

maybe I did somethign wrong there in "pydistutils.cfg" ?


[config]
compiler=mingw32
[build]
compiler=mingw32
[build_ext]
compiler=mingw32

On Sunday, September 28, 2014 11:58:34 AM UTC+2, Stefan Behnel wrote:

[Stefan Behnel]

stone...@gmail.com schrieb am 28.09.2014 um 12:06:
> * a photography of the dos window and task manager says :

Copying text is usually a better idea than sending (links to) images of
text around. Especially on mailing lists.

> - that I blew up in memory,
> - something maybe usefull
> https://github.com/stonebig/ztest_donotuse/blob/master/cython64_from_numpy_issue1.GIF

That looks like a problem in Cython's memory view code. There's a cast from
a pointer to an integer and back, and the integer size (Py_intptr_t) is
different from the pointer size. Could you run this in your notebook and
send us the output please:

"""
%%cython
cdef extern from *:
ctypedef Py_ssize_t Py_intptr_t

print "Py_intptr_t", sizeof(Py_intptr_t)
print "Py_ssize_t", sizeof(Py_ssize_t)
print "void*", sizeof(void*)
"""

Stefan

[stone...@gmail.com]

ok,

In the mean time,  i did compile "helloworld",
- it did compile,
- when i ran it by import helloworld :
  . my pc went berserk, my Taskmanager was running creasy figure from letf to right at 20 times the speed,
  . I saw "HelloWorld" on the python dos window,
  . I had to logoff to get back control.

files included here with a ".zzz" manually added so it passes google controls

[stone...@gmail.com]

trying the HelloWorld on python 2.7.8 64 bit,

I think I copied the right spec.

I get this at compilation time (I would expect to be better than python 3.4)
==> What did I miss ?

Cythonizing helloworld.pyx
running build_ext
building 'helloworld' extension
creating build
creating build\temp.win-amd64-2.7
creating build\temp.win-amd64-2.7\Release
D:\result_tests\WinPython-64bit-2.7.8.2_build11\python-2.7.8.amd64\..\tools\ming
w32\bin\gcc.exe -mdll -O -Wall -ID:\result_tests\WinPython-64bit-2.7.8.2_build11
\python-2.7.8.amd64\include -ID:\result_tests\WinPython-64bit-2.7.8.2_build11\py
thon-2.7.8.amd64\PC -c helloworld.c -o build\temp.win-amd64-2.7\Release\hellowor
ld.o
writing build\temp.win-amd64-2.7\Release\helloworld.def
D:\result_tests\WinPython-64bit-2.7.8.2_build11\python-2.7.8.amd64\..\tools\ming
w32\bin\gcc.exe -shared -s build\temp.win-amd64-2.7\Release\helloworld.o build\t
emp.win-amd64-2.7\Release\helloworld.def -LD:\result_tests\WinPython-64bit-2.7.8
.2_build11\python-2.7.8.amd64\libs -LD:\result_tests\WinPython-64bit-2.7.8.2_bui
ld11\python-2.7.8.amd64\PCbuild\amd64 -lpython27 -lmsvcr90 -o D:\result_tests\Wi
nPython-64bit-2.7.8.2_build11\python-2.7.8.amd64\helloworld.pyd
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x1a4): undefi
ned reference to `__imp_Py_InitModule4'
collect2.exe: error: ld returned 1 exit status
error: command 'D:\\result_tests\\WinPython-64bit-2.7.8.2_build11\\python-2.7.8.
amd64\\..\\tools\\mingw32\\bin\\gcc.exe' failed with exit status 1

D:\result_tests\WinPython-64bit-2.7.8.2_build11\python-2.7.8.amd64>

[Sturla Molden]

Stefan Behnel <stef...@behnel.de> wrote:

> the integer size (Py_intptr_t) is different from the pointer size.

How is that even possible?


Sturla

[Stefan Behnel]

Sturla Molden schrieb am 28.09.2014 um 12:55:

> Stefan Behnel wrote:
>
>> the integer size (Py_intptr_t) is different from the pointer size.
>
> How is that even possible?

I have no idea, but the code that triggers the cast warning is this:

cdef extern from *:
ctypedef Py_ssize_t Py_intptr_t

cdef void *align_pointer(void *memory, size_t alignment) nogil:
cdef Py_intptr_t aligned_p = <Py_intptr_t> memory


Now I'm waiting for the OP to respond to my request about the integer sizes.

Stefan

[Sturla Molden]

Stefan Behnel <stef...@behnel.de> wrote:

> I have no idea, but the code that triggers the cast warning is this:

From his last post you can see that he is trying to build a 32 bit
extension with a 64 bit compiler. Thus Python defines the Py_intptr_t to 4
bytes but the compiler has a 8 byte void*. This is also why the import
fails. It is a trap built into the build system to prevent this error from
passing silently. On Windows, distutils on 64 bit Python will define a
preprocessor symbol to invoke the 64 bit headers. It is missing from his
compile statement. That is a clear sign he is using 32 bit Python.


Sturla

[Sturla Molden]

<stone...@gmail.com> wrote:
> trying the HelloWorld on python 2.7.8 64 bit,
>
> I think I copied the right spec.
>
> I get this at compilation time (I would expect to be better than python 3.4)
> ==> What did I miss ?

-DMS_WIN64

[Sturla Molden]

Sturla Molden <sturla...@gmail.com> wrote:

> From his last post you can see that he is trying to build a 32 bit
> extension with a 64 bit compiler. Thus Python defines the Py_intptr_t to 4
> bytes but the compiler has a 8 byte void*. This is also why the import
> fails. It is a trap built into the build system to prevent this error from
> passing silently. On Windows, distutils on 64 bit Python will define a
> preprocessor symbol to invoke the 64 bit headers. It is missing from his
> compile statement. That is a clear sign he is using 32 bit Python.

Actually, it might be that Enthought is using a patched distutils, and that
a vanilla distutils does not emit the -DMS_WIN64 flag by default. I'm not
sure. After all, Python does not officially support 64 bit extensions with
MinGW64. That is also why libpython27.a is missing from 64-bit Python on
Windows. If this is the case, patch the Mingw32Compiler class in
distutils/cygwincompiler.py to emit this symbol. It is required for both
the compiler and the linker. What you need to do is self evident when you
see the code.

You can also pass this flag to setup.py on the command line or set it as
compile and link flags in setup.py. I am not sure how this works in the
Ipython notebook.

Sturla

[stone...@gmail.com]

Hi again,

Do you mean that the basic example in the official documentation is missleading / limited to python 2.7 32 bit case ?
(http://docs.cython.org/src/tutorial/cython_tutorial.html)

==>


Let me re-state my situation :
- I have a portable (usb-style, movable) python distribution under python 3.4 64 bit
  (for example this WinPython-64bit-3.4.1.2_build14.exe )
- I whish it to include a cython compiler in it, any color, as I succeeded to do for the python3.4 32 bit version  with mingw32

- my distribution includes already cython 0.21, taken from Christoph Gohlke, "Cython-0.21.win-amd64-py3.4.exe"
- to try Sturla suggestion  :
   . I copy the unzipped "mingw64static-2014-07" in its relative directory Tools\mingw32 (for convenient re-use of existing .bat script)
   . then I create a pydistutils.cfg in the "pseudo-HOME" directory of the distribution : \settings
   . QUESTION :
       . did I do ok up to there ?
       . this pydistutils.cfg should contain what exactly ?

   . then let suppose I just want to do HelloWorld, for my python 3.4.1/3.4.2rc1
   . QUESTION :
          . do I need to had some sort of  # cython : Langage_Level3 in the source code ?
          . how  do I get the  -DMS_WIN64   ?

   . I don't mind using mingw32  or llvm/Clang, I just :
          . whish one that works and is portable
          . I accept vs2010 if it's technically and licence-wise possible (and not too heavy) .

[stone...@gmail.com]

Hi Ian,

I tried the other day to do copy/paste from Anaconda64, but I obviously missed something.
Do you think it's a  patch  distutils from "Enthought" or "Anaconda" ?

I would consider all this to be "bugs".
Linus Torvalds  said one time that the code that is shipped is the code that should be supported (was speaking of andr**d).

==> It sounds the same situation here.
==> Couldn't we get the "official" distutils to be fixed as it is fixed by the "main" distributions ? (possibly asap for python3.4.2) ?

[Sturla Molden]

<stone...@gmail.com> wrote:

> - my distribution includes already cython 0.21, taken from Christoph
> Gohlke, "Cython-0.21.win-amd64-py3.4.exe"
> - to try Sturla suggestion :
> . I copy the unzipped "mingw64static-2014-07" in its relative directory
> Tools\mingw32 (for convenient re-use of existing .bat script)

Stop here.

Open a command line. Type

gcc --version

What do you see?

Did you set the PATH to include the bin directory of mingw?

Does the compiler work? Can it compile 'hello word'?

> . then I create a pydistutils.cfg in the "pseudo-HOME" directory of the
> distribution : \settings
> . QUESTION :
> . did I do ok up to there ?
> . this pydistutils.cfg should contain what exactly ?

I never use it. I just pass --compiler=mingw32 to setup.py.

> . how do I get the -DMS_WIN64 ?

Just type it in (unless you get it from distutils).



Sturla

[stone...@gmail.com]

ok,

I found the lines in anaconda 3 that contains DMS_WIN64

This lines are not in my Lib\disutils provided by python.org , but are in  my  numpy\distutils (provided by Christoph Gohlke, or directly by numpy people).



C:\Users\famille\Anaconda3-64\Lib\distutils\cygwinccompiler.py (3 hits)
    Line 140:         self.set_executables(compiler='gcc -DMS_WIN64 -Wall',
    Line 141:                              compiler_so='gcc -DMS_WIN64 -mdll -O -Wall',
    Line 142:                              compiler_cxx='g++ -DMS_WIN64 -O -Wall',
  C:\Users\famille\Anaconda3-64\Lib\site-packages\numpy\distutils\mingw32ccompiler.py (4 hits)
    Line 120:                     compiler='gcc -g -DDEBUG -DMS_WIN64 -mno-cygwin -O0 -Wall',
    Line 121:                     compiler_so='gcc -g -DDEBUG -DMS_WIN64 -mno-cygwin -O0 -Wall -Wstrict-prototypes',
    Line 127:                     compiler='gcc -g -DDEBUG -DMS_WIN64 -O0 -Wall',
    Line 128:                     compiler_so='gcc -g -DDEBUG -DMS_WIN64 -O0 -Wall -Wstrict-prototypes',

[Stefan Behnel]

stone...@gmail.com schrieb am 28.09.2014 um 16:25:
> ==> Couldn't we get the "official" distutils to be fixed as it is fixed by
> the "main" distributions ? (possibly asap for python3.4.2) ?

There's a distutils-sig list where (I guess) this question is being or has
been discussed. There even seem to be plans to backport this to Py2.7.

Stefan

[stone...@gmail.com]

I see that :
D:\result_tests\WinPython-32bit-3.4.2.1_build15>gcc --version
gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[stone...@gmail.com]

I remember I had an issue with anaconda on Windows, and I had to patch their own patched cygwincompiler.py with this, to get cython working on 32 bit.

def is_cygwingcc():
    '''Try to determine if the gcc that would be used is from cygwin.'''
    # http://stackoverflow.com/questions/24291506/building-minimal-cython-file-with-python-3-3-anaconda-under-windows-7
    # out_string = check_output(['gcc', '-dumpmachine'])
    out_string = check_output(['gcc', '-dumpmachine'], shell=True)
    return out_string.strip().endswith(b'cygwin')

==> I'm going to just try this 2 patch, and see if it burns again

[Sturla Molden]

<stone...@gmail.com> wrote:

> I found the lines in anaconda 3 that contains DMS_WIN64
>
> This lines are not in my Lib\disutils provided by python.org , but are in
> my numpy\distutils (provided by Christoph Gohlke, or directly by numpy
> people).

Add -DMS_WIN64 to your Lib/distutils/cygwincompiler.py. You see where to
put it (lines 140-142).

I also have -O2 or -O3 on these lines, if I remember correctly (I'm
currently on ipad).

Sturla

>>>> <a
>>>> href="https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows">https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows</a>

>>>>
>>>> Is it still a lost cause to get cython working on windows 64 with a gcc
>>>> or llvm compiler ?
>>>>
>>>
>>> I think the current status is that it works, but it isn't officially
>>> supported. I'd be willing to update the wiki page if the developers are
>>> interested in adding support for it. The Anaconda Distribution ships a 64
>>> bit version of MinGW that works for compiling Cython extensions, so I'd
>>> assume that using gcc for this is fairly widespread. The MinGW-builds
>>> project has good binaries available. I've had success using MinGW 4.7 (from
>>> Anaconda), 4.8 (MinGW-builds), and 4.9 (MinGW-builds). Earlier versions
>>> probably won't work since there was an ABI update in version 4.7. I could
>>> be wrong, but my understanding is that the ABI update was what allowed this
>>> sort of thing to work at all.
>>>
>>> To configure Python to use distutils, you'll want to make the
>>> distutils.cfg file in <python_path>/Lib/distutils that contains
>>>
>>> [build]
>>> compiler=mingw32
>>>
>>> [build_ext]
>>> compiler = mingw32
>>>
>>> You'll also want to be sure that gcc is on your path and that you have
>>> installed the proper dlls for compiling C extensions for 64 bit windows.
>>> You can get them here.

>>> <<a
>>> href="http://www.lfd.uci.edu/~gohlke/pythonlibs/#libpython">http://www.lfd.uci.edu/~gohlke/pythonlibs/#libpython</a>>

>>>
>>> I can't speak for clang/llvm. I've fiddled with it a little but haven't
>>> had any success in getting the standard library headers from mingw64
>>> included at compilation time for clang. I'm not aware of any good 64 bit
>>> binaries for it either. If you wanted to use it for compiling Python
>>> extensions on windows, you'd probably want to start by looking at the

>>> Python patch <<a
>>> href="http://bugs.python.org/issue18834">http://bugs.python.org/issue18834</a>> that adds

>>> support for
>>> clang to distutils. If you're really lucky, you may be able to get a 64 bit
>>> version of clang compiled and configured to use the standard library from
>>> MinGW and then be able to compile extensions using the patch shown in the
>>> Python issue. If you decide to try this, be aware that the patch is for
>>> Python 3.4. I can't say whether or not that works. I've only used
>>> gcc/g++/gfortran for this sort of thing. In theory, it should be possible,
>>> but it would still probably be an awful pain.
>>> I hope this helps.
>>> -Ian Henriksen
>>>
>>
>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "cython-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cython-users...@googlegroups.com.
> For more options, visit <a
> href="https://groups.google.com/d/optout.">https://groups.google.com/d/optout.</a>
>

> ------=_Part_1716_1227904894.1411915294970

> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>

> <div dir=3D"ltr">ok, <br><br>I found the lines in anaconda 3 that contains =
> DMS_WIN64 <br><br>This lines are not in my Lib\disutils provided by python.=
> org , but are in&amp;nbsp; my&amp;nbsp; numpy\distutils (provided by Christoph Gohl=
> ke, or directly by numpy people).<br><br><br><br>C:\Users\famille\Anaconda3=
> -64\Lib\distutils\cygwinccompiler.py (3 hits)<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; Line 14=
> 0:&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;
> self.set_executables(com=
> piler=3D'gcc -DMS_WIN64 -Wall',<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; Line
> 141:&amp;nbsp;&amp;nbsp;=
> &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nb=
> sp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;=
> &amp;nbsp;&amp;nbsp; compiler_so=3D'gcc -DMS_WIN64 -mdll -O
> -Wall',<br>&amp;nbsp;&amp;nbsp;=
> &amp;nbsp; Line
> 142:&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp=
> ;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;n=
> bsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;
> compiler_cxx=3D'g++ -DMS_WIN64 -O =
> -Wall',<br>&amp;nbsp; C:\Users\famille\Anaconda3-64\Lib\site-packages\numpy\dis=
> tutils\mingw32ccompiler.py (4 hits)<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; Line
> 120:&amp;nbsp;&amp;n=
> bsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp=
> ;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;
> compiler=3D'gcc -g -DDEBUG -DMS_WIN64=
> -mno-cygwin -O0 -Wall',<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; Line
> 121:&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;=
> nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbs=
> p;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; compiler_so=3D'gcc -g -DDEBUG
> -DMS_WIN64 -mno-cy=
> gwin -O0 -Wall -Wstrict-prototypes',<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; Line
> 127:&amp;nbsp;&amp;=
> nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbs=
> p;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;
> compiler=3D'gcc -g -DDEBUG -DMS_WIN6=
> 4 -O0 -Wall',<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; Line
> 128:&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;=
> &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nb=
> sp;&amp;nbsp;&amp;nbsp; compiler_so=3D'gcc -g -DDEBUG -DMS_WIN64 -O0 -Wall -Wstrict=
> -prototypes',<br><br><br>On Sunday, September 28, 2014 4:25:39 PM UTC+2, st=
> one...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
> ;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
> r=3D"ltr">Hi Ian, <br><br>I tried the other day to do copy/paste from Anaco=
> nda64, but I obviously missed something.<br>Do you think it's a&amp;nbsp; patch=
> &amp;nbsp; distutils from "Enthought" or "Anaconda" ?<br><br>I would consider a=
> ll this to be "bugs".<br>Linus Torvalds&amp;nbsp; said one time that the code t=
> hat is shipped is the code that should be supported (was speaking of andr**=
> d).<br><br>=3D=3D&amp;gt; It sounds the same situation here.<br>=3D=3D&amp;gt; Coul=
> dn't we get the "official" distutils to be fixed as it is fixed by the "mai=
> n" distributions ? (possibly asap for python3.4.2) ?<br><br><br><br>On Sund=
> ay, September 28, 2014 12:49:59 AM UTC+2, Ian Henriksen wrote:<blockquote c=
> lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
> cc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Saturday, September 27, =
> 2014 12:05:53 AM UTC-6, <a>stone...@gmail.com</a> wrote:<blockquote class=
> =3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
> olid;padding-left:1ex"><div dir=3D"ltr">Hi,<br><br>I don't see any change o=
> n <a href=3D"https://github.com/cython/cython/wiki/64BitCythonExtensionsOnW=
> indows" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.co=
> m/url?q\75https%3A%2F%2Fgithub.com%2Fcython%2Fcython%2Fwiki%2F64BitCythonEx=
> tensionsOnWindows\46sa\75D\46sntz\0751\46usg\75AFQjCNF8q2LqhQ56FHs_t9dmZ-ou=
> eAZpmg';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\=
> 75https%3A%2F%2Fgithub.com%2Fcython%2Fcython%2Fwiki%2F64BitCythonExtensions=
> OnWindows\46sa\75D\46sntz\0751\46usg\75AFQjCNF8q2LqhQ56FHs_t9dmZ-oueAZpmg';=
> return true;">https://github.com/cython/<wbr>cython/wiki/<wbr>64BitCythonEx=
> tensionsOnWindows</a><br><br>Is it still a lost cause to get cython working=
> on windows 64 with a gcc or llvm compiler ?<br></div></blockquote><div><br=
>> </div><div>I think the current status is that it works, but it isn't offic=
> ially supported. I'd be willing to update the wiki page if the developers a=
> re interested in adding support for it. The Anaconda Distribution ships a 6=
> 4 bit version of MinGW that works for compiling Cython extensions, so I'd a=
> ssume that using gcc for this is fairly widespread. The MinGW-builds projec=
> t has good binaries available. I've had success using MinGW 4.7 (from Anaco=
> nda), 4.8 (MinGW-builds), and 4.9 (MinGW-builds). Earlier versions probably=
> won't work since there was an ABI update in version 4.7. I could be wrong,=
> but my understanding is that the ABI update was what allowed this sort of =
> thing to work at all.</div><div><br></div><div>To configure Python to use d=
> istutils, you'll want to make the distutils.cfg file in &amp;lt;python_path&amp;gt;=
> /Lib/distutils that contains</div><div><br></div><div><div>[build]</div><di=
>> compiler=3Dmingw32</div><div><br></div><div>[build_ext]</div><div>compile=
> r =3D mingw32&amp;nbsp;</div></div><div><br></div><div>You'll also want to be s=
> ure that gcc is on your path and that you have installed the proper dlls fo=
> r compiling C extensions for 64 bit windows. You can get them&amp;nbsp;<a href=
> =3D"http://www.lfd.uci.edu/~gohlke/pythonlibs/#libpython" target=3D"_blank"=
> onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww=
> .lfd.uci.edu%2F~gohlke%2Fpythonlibs%2F%23libpython\46sa\75D\46sntz\0751\46u=
> sg\75AFQjCNF_FGJUuoWg1JsJpCLzMTgRApVJDw';return true;" onclick=3D"this.href=
> =3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.lfd.uci.edu%2F~gohlke%2F=
> pythonlibs%2F%23libpython\46sa\75D\46sntz\0751\46usg\75AFQjCNF_FGJUuoWg1JsJ=
> pCLzMTgRApVJDw';return true;">here.</a></div><div><br></div><div>I can't sp=
> eak for clang/llvm. I've fiddled with it a little but haven't had any succe=
> ss in getting the standard library headers from mingw64 included at compila=
> tion time for clang. I'm not aware of any good 64 bit binaries for it eithe=
> r. If you wanted to use it for compiling Python extensions on windows, you'=
> d probably want to start by looking at&amp;nbsp;<a href=3D"http://bugs.python.o=
> rg/issue18834" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.goo=
> gle.com/url?q\75http%3A%2F%2Fbugs.python.org%2Fissue18834\46sa\75D\46sntz\0=
> 751\46usg\75AFQjCNE1oV8lppjul_GNG2jjj06NQFd88g';return true;" onclick=3D"th=
> is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbugs.python.org%2Fiss=
> ue18834\46sa\75D\46sntz\0751\46usg\75AFQjCNE1oV8lppjul_GNG2jjj06NQFd88g';re=
> turn true;">the Python patch</a>&amp;nbsp;that adds support for clang to distut=
> ils. If you're really lucky, you may be able to get a 64 bit version of cla=
> ng compiled and configured to use the standard library from MinGW and then =
> be able to compile extensions using the patch shown in the Python issue. If=
> you decide to try this, be aware that the patch is for Python 3.4. I can't=
> say whether or not that works. I've only used gcc/g++/gfortran for this so=
> rt of thing. In theory, it should be possible, but it would still probably =
> be an awful pain.</div><div>I hope this helps.</div><div>-Ian Henriksen</di=
>> </div></blockquote></div></blockquote></div>

>
> <p></p>
>
> -- <br />
> <br />
> --- <br />

> You received this message because you are subscribed to the Google Groups &amp;=

> quot;cython-users&amp;quot; group.<br />

> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to <a href=3D"mailto:cython-users...@googlegroups.com">cython=
> -users+un...@googlegroups.com</a>.<br />
> For more options, visit <a href=3D"https://groups.google.com/d/optout">http=

> s://groups.google.com/d/optout</a>.<br />
>

> ------=_Part_1716_1227904894.1411915294970--

[stone...@gmail.com]

This didn't work or I screw up because playing with matches.

I did patch the other set of lines, but I'm clearly out of my comfort zone

  D:\result_tests\WinPython-64bit-3.4.1.2_build14\python-3.4.1.amd64\Lib\distutils\cygwinccompiler.py (6 hits)
    Line 140:         self.set_executables(compiler='gcc -DMS_WIN64 -Wall',  # was 'gcc -mcygwin -O -Wall',
    Line 141:                              compiler_so='gcc -DMS_WIN64 -mdll -O -Wall',  # was 'gcc -mcygwin -mdll -O -Wall',
    Line 142:                              compiler_cxx='g++ -DMS_WIN64 -O -Wall',  # was 'g++ -mcygwin -O -Wall',
    Line 302:         self.set_executables(compiler='gcc -DMS_WIN64  -O -Wall',   # was 'gcc -O -Wall'
    Line 303:                              compiler_so='gcc -DMS_WIN64 -mdll -O -Wall',   # was 'gcc  -mdll -O -Wall',
    Line 304:                              compiler_cxx='g++ -DMS_WIN64  -O -Wall',   # was 'g++   -O -Wall',

and I reverted on line 402

    out_string = check_output(['gcc', '-dumpmachine'])

    #out_string = check_output(['gcc', '-dumpmachine'], shell=True)

==> Now helloworld says hello in 64bit .

> mail to <a href=3D"mailto:cython-users+unsub...@googlegroups.com">cython=

[Sturla Molden]

<stone...@gmail.com> wrote:

> I remember I had an issue with anaconda on Windows, and I had to patch
> their own patched cygwincompiler.py with this, to get cython working on 32
> bit.

Yes, the Mingw32Compiler class used to emit -mno-cygwin, because it was
originally intended to do a mingw cross-compilation from 32-bit Cygwin gcc.
That was common before MSYS provided a proper GNU environment to run
configure scripts. Up to version 3.4 (I think) the native MinGW compiler
just ignored this symbol, but thereafter it started to compilain.

Sturla

>
> def is_cygwingcc():
> '''Try to determine if the gcc that would be used is from cygwin.'''
> #

> <a
> href="http://stackoverflow.com/questions/24291506/building-minimal-cython-file-with-python-3-3-anaconda-under-windows-7">http://stackoverflow.com/questions/24291506/building-minimal-cython-file-with-python-3-3-anaconda-under-windows-7</a>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "cython-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cython-users...@googlegroups.com.
> For more options, visit <a
> href="https://groups.google.com/d/optout.">https://groups.google.com/d/optout.</a>
>

> ------=_Part_1873_346338981.1411915828829

> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>

> <div dir=3D"ltr">I remember I had an issue with anaconda on Windows, and I =
> had to patch their own patched cygwincompiler.py with this, to get cython w=
> orking on 32 bit.<br><br>def is_cygwingcc():<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; '''Try t=
> o determine if the gcc that would be used is from cygwin.'''<br>&amp;nbsp;&amp;nbsp=
> ;&amp;nbsp; # <a
> href="http://stackoverflow.com/questions/24291506/building-minimal-cyth=">http://stackoverflow.com/questions/24291506/building-minimal-cyth=</a>
> on-file-with-python-3-3-anaconda-under-windows-7<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; # ou=
> t_string =3D check_output(['gcc', '-dumpmachine'])<br>&amp;nbsp;&amp;nbsp;&amp;nbsp; ou=
> t_string =3D check_output(['gcc', '-dumpmachine'], shell=3DTrue)<br>&amp;nbsp;&amp;=
> nbsp;&amp;nbsp; return out_string.strip().endswith(b'cygwin')<br><br>=3D=3D&amp;gt;=
> I'm going to just try this 2 patch, and see if it burns again<br><br>On Su=
> nday, September 28, 2014 4:43:56 PM UTC+2, stone...@gmail.com wrote:<blockq=
> uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
> t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I see that :<br>D:\r=
> esult_tests\WinPython-<wbr>32bit-3.4.2.1_build15&amp;gt;gcc --version<br>gcc (G=
> CC) 4.8.1<br>Copyright (C) 2013 Free Software Foundation, Inc.<br>This is f=
> ree software; see the source for copying conditions.&amp;nbsp; There is NO<br>w=
> arranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<=
>> <br><br><br><br><br>On Sunday, September 28, 2014 4:32:30 PM UTC+2, Stur=
> la Molden wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
> left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&amp;lt;<a>stone...@gma=

> il.com</a>&amp;gt; wrote:
> <br>

> <br>&amp;gt; - my distribution includes already cython 0.21, taken from Christo=
> ph
> <br>&amp;gt; Gohlke, "Cython-0.21.win-amd64-py3.4.<wbr>exe"
> <br>&amp;gt; - to try Sturla suggestion &amp;nbsp;:
> <br>&amp;gt; &amp;nbsp; &amp;nbsp;. I copy the unzipped "mingw64static-2014-07" in its =
> relative directory
> <br>&amp;gt; Tools\mingw32 (for convenient re-use of existing .bat script)
> <br>
> <br>Stop here.
> <br>
> <br>Open a command line. Type
> <br>
> <br>&amp;nbsp; &amp;nbsp; gcc --version
> <br>
> <br>What do you see?
> <br>
> <br>Did you set the PATH to include the bin directory of mingw?
> <br>
> <br>Does the compiler work? Can it compile 'hello word'?=20
> <br>
> <br>
> <br>
> <br>&amp;gt; &amp;nbsp; &amp;nbsp;. then I create a pydistutils.cfg in the "pseudo-HOME=
> " directory of the
> <br>&amp;gt; distribution : \settings
> <br>&amp;gt; &amp;nbsp; &amp;nbsp;. QUESTION :
> <br>&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;. did I do ok up to there ?
> <br>&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;. this
> pydistutils.cfg should contain w=
> hat exactly ?
> <br>
> <br>
> <br>I never use it. I just pass --compiler=3Dmingw32 to setup.py.
> <br>
> <br>
> <br>&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; . how
> &amp;nbsp;do I get the &amp;nbsp;=
> -DMS_WIN64 &amp;nbsp; ?
> <br>
> <br>Just type it in (unless you get it from distutils).
> <br>
> <br>
> <br>
> <br>Sturla

> <br>
> <br></blockquote></div></blockquote></div>
>
> <p></p>
>
> -- <br />
> <br />
> --- <br />

> You received this message because you are subscribed to the Google Groups &amp;=

> quot;cython-users&amp;quot; group.<br />

> To unsubscribe from this group and stop receiving emails from it, send an e=

> mail to <a href=3D"mailto:cython-users...@googlegroups.com">cython=

> -users+un...@googlegroups.com</a>.<br />
> For more options, visit <a href=3D"https://groups.google.com/d/optout">http=

> s://groups.google.com/d/optout</a>.<br />
>

> ------=_Part_1873_346338981.1411915828829--

[stone...@gmail.com]

Hi again,

I have :
- HelloWorld basic cython example working,
- %%cython 2*3 working (so via Ipython)
- but when I try an example using numpy, it's blowing up again.

any idea why there would be a problem on this corner case ?

On Saturday, September 27, 2014 8:05:53 AM UTC+2, stone...@gmail.com wrote:

Hi,

I don't see any change on https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows

[Sturla Molden]

<stone...@gmail.com> wrote:
> Hi again,
>
> I have :
> - HelloWorld basic cython example working,
> - %%cython 2*3 working (so via Ipython)
> - but when I try an example using numpy, it's blowing up again.
>
> any idea why there would be a problem on this corner case ?

Guesswork is hard without more detailed information. Show us your code and
the error message.

Sturla

[stone...@gmail.com]

Unfortunately there is none, my pc just becomes totally irresponsive, as when cython heats my memory because not using AMD64.

I suppose the specific numpy "distutils" :
- doesn't guess right that I'm on 64 bit,
- maybe it's due to the portable nature of winpython, but it's only a supposition at the moment.

My anaconda3 64bit on windows doesn't have cython working also.

Is it possible that Anaconda3 - 64 bit on windows doesn't work for cython and that nobody complained ?

[Sturla Molden]

<stone...@gmail.com> wrote:

> Is it possible that Anaconda3 - 64 bit on windows doesn't work for cython
> and that nobody complained ?

No. Without Cython working it would not be possible to build NumPy
(numpy.random), SciPy, scikit-learn, PyZMQ, etc.

There would be no Anaconda3 if Cython did not work. Surely they would
notice.

Sturla

[stone...@gmail.com]

maybe it works well ONLY if you register Anaconda as default python of your pc.

[Sturla Molden]

<stone...@gmail.com> wrote:
> maybe it works well ONLY if you register Anaconda as default python of your
> pc.

If you are running more than one Python distribution on your computer and
they are conflicting with each other then all bets are off.


Sturla

[stone...@gmail.com]

I'm running indeed several distribution.
That is not a problem, until I trying to use cython on numpy 64 bit.

It's hard for me to tell if it's :
- a conflicting issue (with native python 3.4 32 bit, native gcc 4.8.1) ,
- or a mingw64 issue,
- or a detail in my python3.4 64bit + mingw64 setting.

As cython is ok for all but a "with numpy" compilation, it should narrow the problem for experts, but I'm personnally a little lost at the moment

from numpy.distutils.misc_util import msvc_runtime_library, get_build_architecture
get_build_architecture()

==> gives : 'AMD64'
==> sounds ok

import os
import sys
import subprocess

p = subprocess.Popen(['gcc', '-dumpversion'], shell=True,  stdout=subprocess.PIPE)
out_string = p.stdout.read()
p.stdout.close()

>>> out_string
b'4.8.2\r\n'

==> sounds ok.

... any check idea ?

[Ian Henriksen]

Sturla is right, this looks like some sort of conflict between Python installations.

If that's the case, you need to arrange your environment properly. It's no longer a Cython issue.

Here are some things that need to be considered:

What is your path?

How are you compiling and running your test code?

What is your test code?

-Ian

[stone...@gmail.com]

Hi Ian,

I'm not a cython expert, so I use Ipython Notebook :

%load_ext cythonmagic

then

%%cython
print (5*7, 'e')

(which works)

then , hey, thinking about it, this not the execution that blows up my pc, but the compilation process itself.

%%cython
import numpy as np
cimport cython
from libc.math cimport sqrt

@cython.boundscheck(False)
@cython.wraparound(False)
def pairwise_cython(double[:, ::1] X):
    cdef int M = X.shape[0]
    cdef int N = X.shape[1]
    cdef double tmp, d
    cdef double[:, ::1] D = np.empty((M, M), dtype=np.float64)
    for i in range(M):
        for j in range(M):
            d = 0.0
            for k in range(N):
                tmp = X[i, k] - X[j, k]
                d += tmp * tmp
            D[i, j] = sqrt(d)
    return np.asarray(D)

[Ian Henriksen]

Hmm. I'm not seeing anything unusual. What is your system path? How do you launch IPython?

You can see it by running the following line in a notebook cell

%system echo %path%

What is your python path?

You can see that by running (in your IPython notebook)

from sys import path

for line in path:

    print line

That should hopefully help show what your environment looks like.

Also, are you currently trying this in Anaconda or in your vanilla Python installation?

[stone...@gmail.com]

Ok,

Today it works on my pc, AFTER I did slightly modified the source code.

Is this ugly theory possible ?
- an initial compilation was done in 32 bit, (or other "BAD" configuration)
- then :
  . I did switch to 64 bit (or any other "CORRECT" configuration),
  . but the source code WAS NOT modified,
- so cython decided there was no needs to recompile,
- and I would blew up again and again, until :
   . I change the source code a little for whatever reason,
   . cython would detect a full recompiling is necessary.

[Ian Henriksen]

On Tuesday, September 30, 2014 10:31:13 AM UTC-6, stone...@gmail.com wrote:

Ok,

Today it works on my pc, AFTER I did slightly modified the source code.

Is this ugly theory possible ?
- an initial compilation was done in 32 bit, (or other "BAD" configuration)
- then :
  . I did switch to 64 bit (or any other "CORRECT" configuration),
  . but the source code WAS NOT modified,
- so cython decided there was no needs to recompile,
- and I would blew up again and again, until :
   . I change the source code a little for whatever reason,
   . cython would detect a full recompiling is necessary.

Yes, this is probably what happened. I'm not certain if the differing

architecture would trigger a recompile, but it would make sense if it didn't.

I've seen similar things happen before with other changes that aren't reflected

directly in the primary Cython source file. It's good to hear you got it working.

Good luck!

-Ian

[Chris Barker]

On Tue, Sep 30, 2014 at 12:04 PM, Ian Henriksen <insertintere...@gmail.com> wrote:

Is this ugly theory possible ?
- an initial compilation was done in 32 bit, (or other "BAD" configuration)
- then :
  . I did switch to 64 bit (or any other "CORRECT" configuration),
  . but the source code WAS NOT modified,
- so cython decided there was no needs to recompile,
- and I would blew up again and again, until :
   . I change the source code a little for whatever reason,
   . cython would detect a full recompiling is necessary.

Yes, this is probably what happened. I'm not certain if the differing

architecture would trigger a recompile,

Indeed cython / distutils is not very smart about  knowing when to re-run cython / re-compile the code.

whenever anything weird happens, you absolutely want to do a clean run.

If using distuils (and cythonize)  ``python setup.py clean`` should do it, but If odd stuff is going on, I'd make sure the files generated by Cython are deleted.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[stone...@gmail.com]

Hello,

I have a curious issue, when I try to compile a second time a given cython function via Ipython, I get a bad :
"""

DLL load failed: The access to this place of memory is not valid
"""

Is it a know problem/error ? Is there a known workaround ? (using mingw64 static from numpy)

WinPython-64bit-3.4.1.2_build17\python-3.4.1.amd64\lib\site-packages\IPython\extensions\cythonmagic.py in cython(self, line, cell)
    269             self._code_cache[key] = module_name
    270 
--> 271         module = imp.load_dynamic(module_name, module_path)
    272         self._import_all(module)
    273 

ImportError: DLL load failed: L’accès à cet emplacement de la mémoire n’est pas valide.

Procedure/Demo is there :
http://nbviewer.ipython.org/github/stonebig/winpython_afterdoc/blob/WinPython-64bit-3.4.1.2_build17/examples/using_cython_under_winpython64bit.ipynb

[stone...@gmail.com]

Problem solved, after a carefull application of carlkl procedure.

Result looks stable : no advanced user complaint so far.

I really love the "%%cython -a" feature

Thank you for this great tool, I hope I will contribute making it more popular on windows 64bit.

Sheers