[Numpy-discussion] Finished maintenance/1.7.x branch
Hey all, We are going to work on a beta release on the 1.7.x branch.The master is open again for changes for 1.8.x. There will be some work on the 1.7.x branch to fix bugs including bugs that are already reported but have not yet been addressed (like the regression against data-type detection for Sage). It would be great if 1.7.x gets as much testing as possible so that we can discover regressions that may have occurred. But, it was important to draw the line for 1.7.0 features. Thanks for all the many hours of reviewing, coding, writing, reviewing and merging pull requests that has gone into this tag.Just perusing the commit history shows there have been dozens of people (including several new contributors) who have contributed to this release. You are a very talented and productive group and it's time to start thinking about 1.8.x. I think the target should be around November or December. Thanks, -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Symbol table not found compiling numpy from git repository on Windows
On Wed, Jul 18, 2012 at 2:20 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Thu, Jan 5, 2012 at 8:22 PM, John Salvatier
jsalv...@u.washington.edu wrote:
Hello,
I'm trying to compile numpy on Windows 7 using the command: python setup.py
config --compiler=mingw32 build but I get an error about a symbol table not
found. Anyone know how to work around this or what to look into?
building library npymath sources
Building msvcr library: C:\Python26\libs\libmsvcr90.a (from
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b\msvcr90.dll)
objdump.exe:
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b\msvcr90.dll:
File format not recognized
Traceback (most recent call last):
File setup.py, line 214, in module
setup_package()
File setup.py, line 207, in setup_package
configuration=configuration )
File C:\Users\jsalvatier\workspace\numpy\numpy\distutils\core.py, line
186, in setup
return old_setup(**new_attr)
File C:\Python26\lib\distutils\core.py, line 152, in setup
dist.run_commands()
File C:\Python26\lib\distutils\dist.py, line 975, in run_commands
self.run_command(cmd)
File C:\Python26\lib\distutils\dist.py, line 995, in run_command
cmd_obj.run()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build.py, line
37, in run
old_build.run(self)
File C:\Python26\lib\distutils\command\build.py, line 134, in run
self.run_command(cmd_name)
File C:\Python26\lib\distutils\cmd.py, line 333, in run_command
self.distribution.run_command(command)
File C:\Python26\lib\distutils\dist.py, line 995, in run_command
cmd_obj.run()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 152, in run
self.build_sources()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 163, in build_sources
self.build_library_sources(*libname_info)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 298, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 385, in generate_sources
source = func(extension, build_dir)
File numpy\core\setup.py, line 646, in get_mathlib_info
st = config_cmd.try_link('int main(void) { return 0;}')
File C:\Python26\lib\distutils\command\config.py, line 257, in try_link
self._check_compiler()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\config.py,
line 45, in _check_compiler
old_config._check_compiler(self)
File C:\Python26\lib\distutils\command\config.py, line 107, in
_check_compiler
dry_run=self.dry_run, force=1)
File C:\Users\jsalvatier\workspace\numpy\numpy\distutils\ccompiler.py,
line 560, in new_compiler
compiler = klass(None, dry_run, force)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 94, in __init__
msvcr_success = build_msvcr_library()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 362, in build_msvcr_library
generate_def(dll_file, def_file)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 282, in generate_def
raise ValueError(Symbol table not found)
ValueError: Symbol table not found
Did you find a workaround? I am having exactly the same problem.
So this happens both in Windows and in Wine and the problem is that
the numpy distutils is trying to read the symbol table using objdump
from msvcr90.dll but it can't recognize the format:
objdump.exe:
C:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef\msvcr90.dll:
File format not recognized
The file exists:
$ file
~/.wine/drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll
/home/ondrej/.wine/drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll:
PE32 executable for MS Windows (DLL) (unknown subsystem) Intel 80386
32-bit
But objdump doesn't work on it.
Ondrej
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Symbol table not found compiling numpy from git repository on Windows
On Wed, Jul 18, 2012 at 12:30 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Wed, Jul 18, 2012 at 2:20 AM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
On Thu, Jan 5, 2012 at 8:22 PM, John Salvatier
jsalv...@u.washington.edu wrote:
Hello,
I'm trying to compile numpy on Windows 7 using the command: python setup.py
config --compiler=mingw32 build but I get an error about a symbol table not
found. Anyone know how to work around this or what to look into?
building library npymath sources
Building msvcr library: C:\Python26\libs\libmsvcr90.a (from
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b\msvcr90.dll)
objdump.exe:
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b\msvcr90.dll:
File format not recognized
Traceback (most recent call last):
File setup.py, line 214, in module
setup_package()
File setup.py, line 207, in setup_package
configuration=configuration )
File C:\Users\jsalvatier\workspace\numpy\numpy\distutils\core.py, line
186, in setup
return old_setup(**new_attr)
File C:\Python26\lib\distutils\core.py, line 152, in setup
dist.run_commands()
File C:\Python26\lib\distutils\dist.py, line 975, in run_commands
self.run_command(cmd)
File C:\Python26\lib\distutils\dist.py, line 995, in run_command
cmd_obj.run()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build.py, line
37, in run
old_build.run(self)
File C:\Python26\lib\distutils\command\build.py, line 134, in run
self.run_command(cmd_name)
File C:\Python26\lib\distutils\cmd.py, line 333, in run_command
self.distribution.run_command(command)
File C:\Python26\lib\distutils\dist.py, line 995, in run_command
cmd_obj.run()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 152, in run
self.build_sources()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 163, in build_sources
self.build_library_sources(*libname_info)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 298, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 385, in generate_sources
source = func(extension, build_dir)
File numpy\core\setup.py, line 646, in get_mathlib_info
st = config_cmd.try_link('int main(void) { return 0;}')
File C:\Python26\lib\distutils\command\config.py, line 257, in try_link
self._check_compiler()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\config.py,
line 45, in _check_compiler
old_config._check_compiler(self)
File C:\Python26\lib\distutils\command\config.py, line 107, in
_check_compiler
dry_run=self.dry_run, force=1)
File C:\Users\jsalvatier\workspace\numpy\numpy\distutils\ccompiler.py,
line 560, in new_compiler
compiler = klass(None, dry_run, force)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 94, in __init__
msvcr_success = build_msvcr_library()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 362, in build_msvcr_library
generate_def(dll_file, def_file)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 282, in generate_def
raise ValueError(Symbol table not found)
ValueError: Symbol table not found
Did you find a workaround? I am having exactly the same problem.
So this happens both in Windows and in Wine and the problem is that
the numpy distutils is trying to read the symbol table using objdump
from msvcr90.dll but it can't recognize the format:
objdump.exe:
C:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef\msvcr90.dll:
File format not recognized
The file exists:
$ file
~/.wine/drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll
/home/ondrej/.wine/drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll:
PE32 executable for MS Windows (DLL) (unknown subsystem) Intel 80386
32-bit
But objdump doesn't work on it.
So the following patch fixes it:
diff --git a/numpy/distutils/mingw32ccompiler.py b/numpy/distutils/mingw32ccompi
index 5b9aa33..72ff5ed 100644
--- a/numpy/distutils/mingw32ccompiler.py
+++ b/numpy/distutils/mingw32ccompiler.py
@@ -91,11 +91,11 @@ class Mingw32CCompiler(distutils.cygwinccompiler.CygwinCComp
build_import_library()
# Check for custom msvc runtime library on Windows. Build if it doesn't
-msvcr_success = build_msvcr_library()
-msvcr_dbg_success = build_msvcr_library(debug=True)
-if msvcr_success or msvcr_dbg_success:
-# add preprocessor statement for using
[Numpy-discussion] Segfault in mingw in test_arrayprint.TestComplexArray
Hi, I managed to compile NumPy in MinGW under Wine in Ubuntu 11.10 and here is a full log of the tests: https://gist.github.com/3135607 It fails at the test test_str (test_arrayprint.TestComplexArray) with a segfault like this: test_str (test_arrayprint.TestComplexArray) ... wine: Unhandled page fault on read access to 0x at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP: ESP:0041c230 EBP: EFLAGS:00010202( R- -- I - - - ) EAX: EBX:1e00807f ECX: EDX:0041c208 ESI:00f46de0 EDI: ... See the gist for the full log. Any ideas? I downloaded Python from python.org, is it supposed to work with numpy compiled using mingw? Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.complex
Hello, In [2]: numpy.real(arange(3)) Out[2]: array([0, 1, 2]) In [3]: numpy.complex(arange(3)) TypeError: only length-1 arrays can be converted to Python scalars Are there any reasons why numpy.complex doesn't work on arrays? Should it be bug reported? Thanks for your help C. Molinaro ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
On Wed, 2012-07-18 at 15:14 +0200, Molinaro Céline wrote: In [2]: numpy.real(arange(3)) Out[2]: array([0, 1, 2]) In [3]: numpy.complex(arange(3)) TypeError: only length-1 arrays can be converted to Python scalars Are there any reasons why numpy.complex doesn't work on arrays? Should it be bug reported? numpy.complex is just a reference to the built in complex, so only works on scalars: In [5]: numpy.complex is complex Out[5]: True Try numpy.complex128 (or another numpy.complexN, with N being the bit length). Henry ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Lazy imports again
A.S.: Some forewords, below the first paragraphs are annotated after I got to the conclusion at the end of the email; read these annotation in square brackets as if it were footnotes. The main point to grasp and keep in mind for me was, when it comes to package hierarchies, that import package.module and all sorts of import statements are completely distinct from variable lookup package.module although the syntactic similarity is very sweet syntactic sugar and makes things look consistent. It did confuse me, so some initial words are without this clarity; it might explain it (I don't want to delete it since it's written and hence provides context, although it leads to the end I cannot just drop it for the sake of the ending; there is no ending in fact :-). So now, have fun! [This email is because it asks if there is interest in an existing working (see below) importing delay mechanism without use of meta levels inside of Python.] Hi, Some Years ago I made a lazy (who's lazy here? We have work with it, the code has, so?), so let's say, a postponed import system when I made Pmw py2exe compatible (it has or had a version choice built-in which was broken when loading from zips, so that files were not readable; this was the issue I wrote it for). It's standard Python 2.6 or so. I would have to lookup myself what the precise mechanism was, but in principle, the postponed-for-load modules of a package are objects with overloaded __getitem__ which does the import. After this, I think [and was wrong, see below], the loaded module is not placed in Python system space sys.modules but lookup always happens through this pseudo module which does the broadcast and yields the same behaviour in terms of attribute access [correct w.r.t. the lookup]. I would not bet my hand on that the module isn't placed in sys.modules [well done, Friedrich; good decision! :-)], but I think it isn't, the usage of that Pmw package was historically to never import submodules but always leave that to the system of the package and act as if it was already imported [what is true, nevertheless, it needs to import the modules somehow, and I didn't like the importing standard module to circumvent ordinary Python syntax, so I used exec instead]. I think this would actually play nice with what numpy was doing in past and would conserve that hence [this seems to be true; a subtlety is pointed out in the postpostscriptum]. Imports from the submodules in the style from package.submodule import Class did work, by design and not by fiddling afair [By Python design, yes; it has nothing to do with the import-delaying objects acting as pseudo modules]. Attributes of a package which are supposed to act as to be modules whose loading is postponed are coded in the __init__.py of the package, for instance, by code like submodule = PostponedLoad(package.submodule), this is the style, don't take it literally. I said it's years ago and I would look it up only if there is interest [probably I meant 'if I develop interest myself'; I didnt know :-)]. I think I even made a standalone module of the functionality already but I'm not sure. There might have been some cleanup which made me never publish it although there was even interest on the Pmw list. Sigh. You can be sure that it was a clean solution with all the constraints by modeling submodules as objects of an instantiated class clearly visible. It was fully compatible with the handling Pmw was doing before, and although I don't have user feedback, I never had to change any code after switching to my own remake. This includes for sure [not for sure; there were no submodules to be specified] syntax like I mentioned above (from p.m import C). I guess I would be very much mistaken in this; so I conclude without further reading that Python first looks up the named object p.m before traversing into sys.modules? This are details. [Yes, I was very much mistaken, it's only from p import C although it goes internally down to p.m; and yes, this are details indeed.] What I am not sure on are local [that is, relative] imports because I guess they might rely on something what causes incompatibility. This is a might, and there is chance that it turns into a not, or not, depending on how local imports (which I never use; bad style :-) are tied to file structure. If they are inherently object and name based ... well I don't know. What speculation. I'm not knowledgabe on this. [The import mechanism isn't touched by this proposal here; the only thing is how e.g. numpy.random.randn is made available to the user without importing numpy.random before: and this is done by making numpy.random (when looked up by name, not in an import statement) an object importing on demand and then pretending it would be the module object itself.] I'm currently not expecting myself to do anything substantial to this. I would just give the code free (public domain) and you can do
Re: [Numpy-discussion] Symbol table not found compiling numpy from git repository on Windows
On Wed, Jul 18, 2012 at 11:38 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote: Now things work and start compiling. Any ideas what is going on here? Why is it trying to build the msvcr library? I believe that it's actually trying to link to the msvcr library (which requires first creating some file that describes its contents). And this is being done because it's trying to workaround mingw's lack of a localtime_s function. AFAICT the solution is to just delete this code and go back to using plain old localtime (see the other thread). -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Finished maintenance/1.7.x branch
On Wed, Jul 18, 2012 at 7:09 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, We are going to work on a beta release on the 1.7.x branch.The master is open again for changes for 1.8.x. There will be some work on the 1.7.x branch to fix bugs including bugs that are already reported but have not yet been addressed (like the regression against data-type detection for Sage). It would be great if 1.7.x gets as much testing as possible so that we can discover regressions that may have occurred. But, it was important to draw the line for 1.7.0 features. There are two strategies for working with maintenance branches: 1) commit bug-fixes to maintenance, merge maintenance back into master as needed 2) commit bug-fixes to master, cherry-pick to maintenance, never merge maintenance back into master Which are we using? (I.e., which branch should bug-fix PRs be submitted against?) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Finished maintenance/1.7.x branch
I don't have a strong preference. Which one do others prefer? Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Jul 18, 2012, at 9:06 AM, Nathaniel Smith n...@pobox.com wrote: On Wed, Jul 18, 2012 at 7:09 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, We are going to work on a beta release on the 1.7.x branch.The master is open again for changes for 1.8.x. There will be some work on the 1.7.x branch to fix bugs including bugs that are already reported but have not yet been addressed (like the regression against data-type detection for Sage). It would be great if 1.7.x gets as much testing as possible so that we can discover regressions that may have occurred. But, it was important to draw the line for 1.7.0 features. There are two strategies for working with maintenance branches: 1) commit bug-fixes to maintenance, merge maintenance back into master as needed 2) commit bug-fixes to master, cherry-pick to maintenance, never merge maintenance back into master Which are we using? (I.e., which branch should bug-fix PRs be submitted against?) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
On 18 July 2012 15:14, Molinaro Céline celine.molin...@telecom-bretagne.eu wrote: Hello, In [2]: numpy.real(arange(3)) Out[2]: array([0, 1, 2]) In [3]: numpy.complex(arange(3)) TypeError: only length-1 arrays can be converted to Python scalars I think you're looking for the dtype keyword to the ndarray constructor: import numpy as np np.arange(3, dtype=np.complex) Out[2]: array([ 0.+0.j, 1.+0.j, 2.+0.j]) or if you have an existing array to cast: np.asarray(np.arange(3), dtype=np.complex) Out[3]: array([ 0.+0.j, 1.+0.j, 2.+0.j]) You can get the real and imaginary components of your complex array like so: a = np.arange(3, dtype=np.complex) a Out[9]: array([ 0.+0.j, 1.+0.j, 2.+0.j]) a.real Out[10]: array([ 0., 1., 2.]) a.imag Out[11]: array([ 0., 0., 0.]) Cheers, Scott ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Symbol table not found compiling numpy from git repository on Windows
On Wed, Jul 18, 2012 at 11:38 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Wed, Jul 18, 2012 at 12:30 PM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
On Wed, Jul 18, 2012 at 2:20 AM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
On Thu, Jan 5, 2012 at 8:22 PM, John Salvatier
jsalv...@u.washington.edu wrote:
Hello,
I'm trying to compile numpy on Windows 7 using the command: python
setup.py
config --compiler=mingw32 build but I get an error about a symbol table
not
found. Anyone know how to work around this or what to look into?
building library npymath sources
Building msvcr library: C:\Python26\libs\libmsvcr90.a (from
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b\msvcr90.dll)
objdump.exe:
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b\msvcr90.dll:
File format not recognized
Traceback (most recent call last):
File setup.py, line 214, in module
setup_package()
File setup.py, line 207, in setup_package
configuration=configuration )
File C:\Users\jsalvatier\workspace\numpy\numpy\distutils\core.py, line
186, in setup
return old_setup(**new_attr)
File C:\Python26\lib\distutils\core.py, line 152, in setup
dist.run_commands()
File C:\Python26\lib\distutils\dist.py, line 975, in run_commands
self.run_command(cmd)
File C:\Python26\lib\distutils\dist.py, line 995, in run_command
cmd_obj.run()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build.py,
line
37, in run
old_build.run(self)
File C:\Python26\lib\distutils\command\build.py, line 134, in run
self.run_command(cmd_name)
File C:\Python26\lib\distutils\cmd.py, line 333, in run_command
self.distribution.run_command(command)
File C:\Python26\lib\distutils\dist.py, line 995, in run_command
cmd_obj.run()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 152, in run
self.build_sources()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 163, in build_sources
self.build_library_sources(*libname_info)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 298, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\build_src.py,
line 385, in generate_sources
source = func(extension, build_dir)
File numpy\core\setup.py, line 646, in get_mathlib_info
st = config_cmd.try_link('int main(void) { return 0;}')
File C:\Python26\lib\distutils\command\config.py, line 257, in try_link
self._check_compiler()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\command\config.py,
line 45, in _check_compiler
old_config._check_compiler(self)
File C:\Python26\lib\distutils\command\config.py, line 107, in
_check_compiler
dry_run=self.dry_run, force=1)
File C:\Users\jsalvatier\workspace\numpy\numpy\distutils\ccompiler.py,
line 560, in new_compiler
compiler = klass(None, dry_run, force)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 94, in __init__
msvcr_success = build_msvcr_library()
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 362, in build_msvcr_library
generate_def(dll_file, def_file)
File
C:\Users\jsalvatier\workspace\numpy\numpy\distutils\mingw32ccompiler.py,
line 282, in generate_def
raise ValueError(Symbol table not found)
ValueError: Symbol table not found
Did you find a workaround? I am having exactly the same problem.
So this happens both in Windows and in Wine and the problem is that
the numpy distutils is trying to read the symbol table using objdump
from msvcr90.dll but it can't recognize the format:
objdump.exe:
C:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef\msvcr90.dll:
File format not recognized
The file exists:
$ file
~/.wine/drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll
/home/ondrej/.wine/drive_c/windows/winsxs/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef/msvcr90.dll:
PE32 executable for MS Windows (DLL) (unknown subsystem) Intel 80386
32-bit
But objdump doesn't work on it.
So the following patch fixes it:
diff --git a/numpy/distutils/mingw32ccompiler.py
b/numpy/distutils/mingw32ccompi
index 5b9aa33..72ff5ed 100644
--- a/numpy/distutils/mingw32ccompiler.py
+++ b/numpy/distutils/mingw32ccompiler.py
@@ -91,11 +91,11 @@ class
Mingw32CCompiler(distutils.cygwinccompiler.CygwinCComp
build_import_library()
# Check for custom msvc runtime library on Windows. Build if it
doesn't
-msvcr_success = build_msvcr_library()
-msvcr_dbg_success = build_msvcr_library(debug=True)
-
Re: [Numpy-discussion] Finished maintenance/1.7.x branch
On Wed, Jul 18, 2012 at 5:29 PM, David Cournapeau courn...@gmail.comwrote: On Wed, Jul 18, 2012 at 3:17 PM, Travis Oliphant tra...@continuum.io wrote: I don't have a strong preference. Which one do others prefer? We've used 2) in the past, and I don't think Ralf changed this when he took over release maintenance. Indeed, everything normally lands in master first. I also have the habit of waiting a few days before backporting when possible, because that way a lot of testing already happens by people tracking master. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segfault in mingw in test_arrayprint.TestComplexArray
On Wed, Jul 18, 2012 at 1:24 PM, Ondřej Čertík ondrej.cer...@gmail.comwrote: Hi, I managed to compile NumPy in MinGW under Wine in Ubuntu 11.10 and here is a full log of the tests: https://gist.github.com/3135607 It fails at the test test_str (test_arrayprint.TestComplexArray) with a segfault like this: test_str (test_arrayprint.TestComplexArray) ... wine: Unhandled page fault on read access to 0x at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP: ESP:0041c230 EBP: EFLAGS:00010202( R- -- I - - - ) EAX: EBX:1e00807f ECX: EDX:0041c208 ESI:00f46de0 EDI: ... See the gist for the full log. Any ideas? I downloaded Python from python.org, is it supposed to work with numpy compiled using mingw? It is. I have Python 2.5 ... 3.2 from Python.org, with MinGW from http://prdownloads.sourceforge.net/mingw/MinGW-5.0.3.exe?download and ATLAS binaries from https://github.com/numpy/vendor. Then I normally build numpy/scipy with paver bdist_wininst_simple or paver bdist_wininst_superpack. This also requires MakeNSIS and the CpuId plugin for it, as documented at https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Finished maintenance/1.7.x branch
On Wed, Jul 18, 2012 at 6:12 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, Jul 18, 2012 at 5:29 PM, David Cournapeau courn...@gmail.com wrote: On Wed, Jul 18, 2012 at 3:17 PM, Travis Oliphant tra...@continuum.io wrote: I don't have a strong preference. Which one do others prefer? We've used 2) in the past, and I don't think Ralf changed this when he took over release maintenance. Indeed, everything normally lands in master first. I also have the habit of waiting a few days before backporting when possible, because that way a lot of testing already happens by people tracking master. Okay then: https://github.com/numpy/numpy/pull/362 -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour
On Jul 17, 2012, at 10:47 AM, Nathaniel Smith wrote: Not that there are likely to be people using skip_header=True as an alias for skip_header=1, but if they were it would currently work. confession I write messy code like that all the time. /confession Best, Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segfault in mingw in test_arrayprint.TestComplexArray
Hi Ralf, On Wed, Jul 18, 2012 at 7:25 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, Jul 18, 2012 at 1:24 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: Hi, I managed to compile NumPy in MinGW under Wine in Ubuntu 11.10 and here is a full log of the tests: https://gist.github.com/3135607 It fails at the test test_str (test_arrayprint.TestComplexArray) with a segfault like this: test_str (test_arrayprint.TestComplexArray) ... wine: Unhandled page fault on read access to 0x at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP: ESP:0041c230 EBP: EFLAGS:00010202( R- -- I - - - ) EAX: EBX:1e00807f ECX: EDX:0041c208 ESI:00f46de0 EDI: ... See the gist for the full log. Any ideas? I downloaded Python from python.org, is it supposed to work with numpy compiled using mingw? It is. I have Python 2.5 ... 3.2 from Python.org, with MinGW from http://prdownloads.sourceforge.net/mingw/MinGW-5.0.3.exe?download and ATLAS binaries from https://github.com/numpy/vendor. Then I normally build numpy/scipy with paver bdist_wininst_simple or paver bdist_wininst_superpack. This also requires MakeNSIS and the CpuId plugin for it, as documented at https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt Thanks for the details. I'll try to reproduce it. I have no idea why my setup doesn't work. I've nailed it to: import numpy as np np.array([complex(0, 1)], np.complex64) wine: Unhandled page fault on read access to 0x at address (nil) (thread 0009), starting debugger... ... So it is something with the complex types. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Pull Requests I'm planning to merge
Hi, On Tue, Jul 17, 2012 at 10:20 PM, Travis Oliphant tra...@continuum.io wrote: On Jul 17, 2012, at 6:48 PM, Nathaniel Smith wrote: On Tue, Jul 17, 2012 at 9:56 PM, Travis Oliphant tra...@continuum.io wrote: I would like to merge the following pull requests sometime today: * 326 -- inplace increment function -1, for the reasons stated in the comment thread -- we shouldn't lock ourselves into an ugly API when there's discussion going on about the right solution, and the submitter has expressed interest in rewriting it in a better way. Also to be clear, I'm not saying I will try to block this functionality forever unless it's perfect or anything -- I could probably be convinced that putting in something sub-optimal here was the best trade-off. Really what I'm -1 on is shoving something in without proper discussion just because the release is happening, on the theory that we can clean up any mess later. Until your comment a few hours ago no-one even looked at this new API except me and the submitter... You are incorrect about that. I've looked at it several times since it was posted. I've looked at and studied all the PRs multiple times in fact over the past several months. I've waited for others to express an opinion. I don't think it's accurate to assume that people have not seen something because they don't comment. I will hold off on this one, but only because you raised your objection to -1 (instead of -0.5).But, I disagree very strongly with you that it is sub-optimal in the context of NumPy. I actually think it is a very reasonable solution. He has re-used the MapIter code correctly (which is the only code that *does* fancy indexing). The author has done a lot of work to support multiple data-types and satisfy an often-requested feature in a very reasonable way. Your objection seems to be that you would prefer that it were a method on ufuncs. I don't think this will work without a *major* refactor. I'm not sure it's even worth it then either. Due to Travis comments, I expect the better solution won't be done in the short time. So blocking a feature requeted frequently because we could do sometimes in an unknow futur something better is not a good idea. (if I get it wrong on the expectation, please, correct me!) Also, if we decide to change the interface, we could do it for NumPy 2, so I don't see a need for an infinit time support of this API. So in conclusion, can we say that when John will have make is PR work with all dtype, we merge it? Also, I understood that it won't be included in NumPy 1.7. Is that right? Fred ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
