[issue12265] revamp argument errors
Roger Binns added the comment: Is there any reason it doesn't show the function 'prototype' which is by far the most the useful piece of information and is also a form of documentation (plus fairly hard to work out). Convoluted technospeak is far harder to understand. Compare: TypeError: f() takes from 1 to 2 positional arguments but 0 were given versus: TypeError: f(a, b=2) takes from 1 to 2 positional arguments but 0 were given -- nosy: +rogerbinns ___ Python tracker <http://bugs.python.org/issue12265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12265] revamp argument errors
Roger Binns added the comment: Obviously the prototype can't be provided when it isn't known. But the pseudo-English text is trying to describe the prototype and is far less clear than the actual prototype. ie the developer communicated the prototype to Python in Python syntax, why not have Python do the same rather than use a different and very unfamiliar language. (Try using the Python documentation to work out what the word 'positional' means.) As for looking it up in the source code, that is one of the harder things for newbies to do, and certainly very difficult for a lot of people. How would they know where the standard library source is on their system? Heck I don't even know where the source is for third party packages on my Ubuntu system as the last I looked they used convoluted sequences of version numbers, symbolic links and who knows what else. The popularity of eggs makes it even harder to look up. -- ___ Python tracker <http://bugs.python.org/issue12265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11851] Flushing the standard input causes an error
Roger Binns added the comment: I'm the APSW author. The reason why this apparent nonsense is done is due to using readline and completion. That requires being able to write to standard input when it is a terminal - something that Windows and Linux are happy to do. In any event I'll put a try/catch around this and ignore. -- nosy: +rogerbinns ___ Python tracker <http://bugs.python.org/issue11851> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
New submission from Roger Binns <[EMAIL PROTECTED]>: My extension (apsw) builds and runs just fine on Linux, Mac and Windows for Python 2.3, 2.4 and 2.5. For Linux and Mac Python 2.6 beta 1 and Python 3.0 beta 1 also work just fine. However on Windows using MinGW and Python 2.6 beta 1 and Python 3.0 beta 1 the pyd fails to load claiming the "specified procedure cannot be found". The compile/link is just fine and pexports shows the procedure is present. # Compile lines c:/python26/python setup.py build --compile=mingw32 install c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DSQLITE_THREADSAFE=1 -DNDEBUG=1 -DEXPERIMENTAL=1 -DAPSW_USE_SQLITE_AMALGAMATION=\"C:\apsw\sqlite3.c\" -Ic:\python26\include -Ic:\python26\PC -c apsw.c -o build\temp.win32-2.6\Release\apsw.o writing build\temp.win32-2.6\Release\apsw.def c:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6\Release\apsw.o build\temp.win32-2.6\Release\apsw.def -Lc:\python26\libs -Lc:\python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\apsw.pyd # Running ImportError: DLL load failed: The specified procedure could not be found. # Pexports C:\apsw>pexports build\lib.win32-2.6\apsw.pyd LIBRARY apsw.pyd EXPORTS initapsw When using Python 3.0 things are substantially the same except the init function is PyInit_apsw. MinGW was installed using the default configuration with the automated installer http://sourceforge.net/forum/forum.php?forum_id=817299 The libmsvcr90.a is part of MinGW found in c:\MinGW\lib -- components: Distutils messages: 69361 nosy: rogerbinns severity: normal status: open title: MinGW built extensions do not load (specified procedure cannot be found) versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
Roger Binns <[EMAIL PROTECTED]> added the comment: I figured maybe it was something to do with MSVC 90 dlls. C:\apsw>dir \*msvc*90* /s Volume in drive C has no label. Volume Serial Number is F4A5-1661 Directory of C:\MinGW\lib 12/27/2007 08:23 AM 554,136 libmsvcr90.a 12/27/2007 08:23 AM 555,910 libmsvcr90d.a 2 File(s) 1,110,046 bytes Directory of C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375 11/06/2007 08:23 PM 224,768 msvcm90.dll 11/07/2007 01:19 AM 568,832 msvcp90.dll 11/07/2007 01:19 AM 655,872 msvcr90.dll 3 File(s) 1,449,472 bytes Directory of C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30411.0_x-ww_71382c73 04/10/2008 10:52 PM 225,280 msvcm90.dll 04/11/2008 04:32 AM 572,928 msvcp90.dll 04/11/2008 04:32 AM 655,872 msvcr90.dll 3 File(s) 1,454,080 bytes Total Files Listed: 8 File(s) 4,013,598 bytes 0 Dir(s) 22,924,242,944 bytes free Process Explorer shows Python 2.6 exe using MSVCR90.dll from the 71382c73 WinSxS directory. Using Process Monitor for the 'import apsw' invocation shows the cp437 encoding being looked for and found, then the apsw.pyd being looked for, found, opened, LoadImage, ReadFile and CloseFile. Then a file named angle bracket stdin angle bracket it looked for and not found (presumably to show the error message). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
Roger Binns <[EMAIL PROTECTED]> added the comment: I can't prove it since Python gives no further information than a procedure cannot be found, but using a bunch of other tools I think this may be due at least to the use of localtime() and it not being present in the msvcr90.dll but is in the vc version 7 dlls which is why earlier versions of Python have no issue. If the above is the case then I have no idea where the actual underlying cause lies. Is MinGW missing header information that should mangle localtime() to one of the other variants used by msvc (_s suffix, _ prefix, 32/64 in there somewhere)? Is the Python header causing issues? Attached is a trivial extension providing the issue with localtime. Added file: http://bugs.python.org/file10839/localtime.zip ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
Roger Binns <[EMAIL PROTECTED]> added the comment: I cleared all event categories, and then ran Python followed by the import (which fails). No events in any category appeared. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
Roger Binns <[EMAIL PROTECTED]> added the comment: I didn't have a copy of depends.exe since it doesn't appear to come with MinGW. System is basically VirtualBox VM with fresh install of XP Pro SP2, upgraded to SP3 and TortoiseSVN, Firefox, Xemacs, MinGW and Python versions installed. I found a GUI program named depends which is what I used to figure out that the issue appeared to be localtime() missing in msvcr90.dll. BTW did you notice msg69367 and the attached file that shows the problem in a trivial test case? The gui depends program found the following issues: - No localtime in msvcr90.dll - DWMAPI.DLL not found (not mentioned on link line so no idea why depends wants it) - MPR.DLL & SHLWAPI.DLL are red but I don't know why (again not mentioned on link line) I think that the localtime() symbol is the underlying cause. However this isn't exactly Python's fault (Python's headers don't do anything to the localtime symbol but there may be defines that cause "secure crt" to be used which wants localtime_s to be used instead). Maybe MinGW is supposed to be redefining localtime to one of the _/32/64/s variants but isn't. In any event the net result is that if a Python extension uses current MinGW and localtime() then it will compile and link correctly on Python 2.3, 2.4, 2.5, 2.6b1 & 3.0b1. However it won't run on 2.6b1 or 3.0b1 due to some sort of mismatch between those versions of Python using new MSVC runtime and/or MinGW. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
Roger Binns <[EMAIL PROTECTED]> added the comment: In MinGW's defense the MSVC 7 dll does include localtime. Since Python/distutils only says that MSVC 9 dll is being used at link time, how exactly is MinGW (or any other code) supposed to know that localtime should be provided some other way? Maybe distutils should be defining __MSVCRT_VERSION__ to 0x0900 for the compile phase as well for Python 2.6/3.0. If that was the case then at least I could work around the issue (the localtime call isn't actually in my code but a library I statically link in) and still work correctly on earlier Pythons which don't need any workarounds. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
Roger Binns <[EMAIL PROTECTED]> added the comment: I will ask on the MinGW lists. I am still curious as to how MinGW is supposed to know which MSVC library will be used at compile time since distutils doesn't tell it until link time. As a seperate issue Python isn't too helpful when an extension doesn't load :-) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3308] MinGW built extensions do not load (specified procedure cannot be found)
Roger Binns <[EMAIL PROTECTED]> added the comment: I guess you can close this now. Unfortunately SourceForge goes out of its way to not make an easy link for the MinGW mailing list but you can see the messages on 8th July 2008: http://sourceforge.net/mailarchive/forum.php?forum_name=mingw-users&viewmonth=200807&viewday=8 Basically MinGW erroneously ships a .lib saying localtime is in MSVCR90.DLL when it isn't. That means there is no link failure but the pyd will fail to load without information as to why. Fixing the .lib means that localtime is picked up from MSVCRT.DLL (ie no version in name) and everything appears to work well. The MinGW project also claims they only support MSVCRT.DLL and not any of the numbered ones, so basically it is luck they work. Noone pointed out any compile time directives to direct versioning of MSVCRT. I guess this is more fuel for the semi-regular flame war about free software and free compilers on Windows, but not in this ticket! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16035] Segmentation fault in test suite of apsw
Roger Binns added the comment: Thanks for finding this problem. I can repeat it with the patch and am in the process of fixing it. -- ___ Python tracker <http://bugs.python.org/issue16035> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16145] Abort in _csv module
Roger Binns added the comment: I'm the APSW author. You do not need SQLite installed - APSW's setup can fetch the current SQLite and use it privately not affecting the rest of the system. An easier way of testing is: python3 setup.py fetch --sqlite --version 3.7.14 build_ext --inplace --force Create test.sql with these contents .output output_file .mode csv select 3, '4'; Then run: env PYTHONPATH=. python3 tools/shell.py .read test.sql The actual code where the problem happens does the following: - Create a StringIO - Initialize csv.writer using the StringIO - Write one row with two values (this is when the crash happens in Python 3.3 on the first write) - Copy the current contents of the StringIO to the actual output file changing encoding as needed - Truncate StringIO and seek back to offset zero ready for the next line The relevant code is in tools/shell.py in the output_csv function. Writing just that sequence of code above doesn't result in the assertion. valgrind doesn't show any problems either (using pydebug, without pymalloc and all the freelists set to zero). A stack trace is here: https://code.google.com/p/apsw/issues/detail?id=132#c4 If not using a debug/nopymalloc build then you get a crash happening later. -- ___ Python tracker <http://bugs.python.org/issue16145> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16145] Abort in _csv module
Roger Binns added the comment: (APSW author here). I haven't ported to the new Python 3.3 Unicode handling yet but it is on my todo list. The PEPs and doc said the C API would remain backwards compatible. The APSW code supports Python 2.3 onwards. SQLite APIs support both UTF-8 and UTF-16. Py_UNICODE_SIZE is used to select between two code paths - if 2 then the UTF-16 APIs are used and if 4 then a UTF-8 conversion is made and those APIs used. Python 3.3 makes Py_UNICODE_SIZE meaningless and will be quite a bit of work to integrate as a third branch. It should be noted that at no point is there any dependence of the underlying bytes/pointer living a long time. They are only used at the point which data needs to be transferred between Python types and SQLite APIs (both ways) and not held outside of that period. -- ___ Python tracker <http://bugs.python.org/issue16145> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16145] Abort in _csv module
Roger Binns added the comment: Roughly how long will it be before Python 3.3.1 comes out? This issue means my users will get garbage or crashes, so I'll need to work around it if it will be quite a while till 3.3.1. -- ___ Python tracker <http://bugs.python.org/issue16145> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6040] bdist_msi does not deal with pre-release version
Roger Binns added the comment: This issue is highly annoying. The ultimate cause is the msi code using the StrictVersion class to get the version number. StrictVersion is documented to be constrained to numerical dot separated versions, and there doesn't appear to be a way of providing that. My extension has a human readable version and I'm happy to also provide a different mangled version to keep this command working. I suspect the strictversion doesn't actually matter than much and is only used to identify an identical version of the installer so there is no reason why it can't be automatically derived from the human readable version. -- nosy: +rogerbinns ___ Python tracker <http://bugs.python.org/issue6040> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16145] Abort in _csv module
Roger Binns added the comment: So is 3.3.1 with the fix ever going to be released? Georg did predict mid-November and we are 4 months after that. -- ___ Python tracker <http://bugs.python.org/issue16145> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
