-
I rebuilt the patch after minor rejections in 0.8.18. No functional change.
#pycheck_no suppressions worked for me over the years.
In my experience its almost impossible in larger projects to reach and maintain a clean checker status with suppressions only in .pycheckrc.
2009-05-10 11:22:39 UTC in PyChecker
-
Speed / default-disabling is a absolute non-issue regarding my experience. It uses the linecache. Only files with errors have to be opened (post processing). And reading the source file lines is much much faster than the checker job.
style nits of course :-)
Somewhat questionable is the re-matching (only) on human readable warning messages (which are possibly changing during evolution of...
2007-04-23 09:32:29 UTC in PyChecker
-
The Pychecker Plug-In for PythonWin, which supports the #$pycheck_no, is at:
#1623093
http://sourceforge.net/tracker/index.php?func=detail&aid=1623093&group_id=78018&atid=551956.
2006-12-27 18:59:01 UTC in PyChecker
-
This Pychecker plug-in module for PythonWin enables to use Pychecker easily in PythonWin (usage similar to the existing Grep-Tool (Ctrl-N,P) - but it can run in background due to the time consuming Pychecker task).
It also supports easily the #$pycheck_no option of #1623076
http://sourceforge.net/tracker/index.php?func=detail&aid=1623076&group_id=24686&atid=382219
One can jump to...
2006-12-27 18:53:15 UTC in Python for Windows extensions
-
This patch enables to make pychecker quiet on source code line basis by adding a "#$pycheck_no" comment (=quiet on all errors concerning this line) or a "#$pycheck_no=re-pattern" comment (quiets the message if the re-pattern is found inside the message).
Example: "def __init__(self): #$pycheck_no='Base class .* not called'"
A re-pattern can of course use OR (|) syntax to stop more warnings...
2006-12-27 18:07:20 UTC in PyChecker
-
Logged In: YES
user_id=972995
Meanwhile there is significant feedback that
c_GIL_bugs.patch in fact solved all the crash problems with
threaded apps on all (dual core) machines.
2006-11-08 09:12:58 UTC in Python for Windows extensions
-
Logged In: YES
user_id=972995
In attachment a patch candidate I've so far in action for
all these things.
(That issue around "pExistingAppObject" was nonsense.
pExistingAppObject seems to be not set to anything at all)
Notes:
The speed DECREF's in ~CVirtualHelper are switched all off
by this patch - as it seems to not be valid so outside of
the GIL. Would require a __asm LOCK...
2006-11-05 20:00:52 UTC in Python for Windows extensions
-
Logged In: YES
user_id=972995
Think I found other serious potential refcount/GIL problems
which cause crashes here in apps with threads - mainly on
dual core - and set priority to 9:
I looked over GUI_BGN_SAVE's
=> Py_XINC/DECREF's outside of the GIL. this causes probably
the special problems only on dual cores when multiple threads:
win32cmdui/Line120:
GUI_BGN_SAVE;...
2006-11-04 15:49:52 UTC in Python for Windows extensions
-
Logged In: YES
user_id=972995
(repeated)
--- win32assoc.cpp.orig 2005-04-12 17:01:00.000000000 +0200
+++ win32assoc.cpp 2006-11-04 10:59:46.326646400 +0100
@@ -252,9 +252,10 @@
{
if (this==NULL) return NULL;
if (virtualInst) {
+ PyObject *vi = virtualInst;
+ DOINCREF(vi);
DODECREF(this);
- DOINCREF(virtualInst);
- return virtualInst;
+ return vi;
} else
return...
2006-11-04 10:22:25 UTC in Python for Windows extensions
-
I wonder if the below patch possibly addresses a
refcount/memory problem. Think its possible, that
DODECREF(this) frees from memory, another
released threads malloc uses the memory and
this->virtualInst is bogus?
( In preceding function ui_assoc_object::DoKillAssoc
there is a simlar technique to do "PyObject *vi =
virtualInst;" - but for reverse reason )
( I'm still in...
2006-11-04 10:12:36 UTC in Python for Windows extensions
