Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue22393>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
Mark: Patches to 3.3 are generally not being considered (due to its age) but
patches to 3.5 (possibly 3.4) would be. You suggest the issue can't be
reproduced in 3.4 but have to tried in the current 3.5 release?
--
nosy: +davin
type: ->
Changes by Davin Potts :
--
nosy: +davin
versions: +Python 2.7, Python 3.5
___
Python tracker
<http://bugs.python.org/issue25469>
___
___
Python-bugs-list mailin
Davin Potts added the comment:
Note issue21779 has been around for quite some time with its own patch
specifically for multiprocessing, making its tests more robust.
I am hesitant to embrace the patch suggested here.
--
nosy: +davin
___
Python
Davin Potts added the comment:
I am unable to reproduce the behavior you describe using the code you provided.
I've tried on both the current Linux Mint release (64-bit) and OS X 10.10
using the current Python 2.7 release (2.7.10).
Could you be more specific about what platform you are
Davin Potts added the comment:
I'm going ahead with closing this issue as it originates outside of
multiprocessing and Python itself as well as being highly dependent upon
specific combinations of build options and versions of 3rd party libraries
(such as ATLAS).
--
Davin Potts added the comment:
@tomer70: Thanks for the update and glad to hear that updating to the latest
release fixed the issue.
--
___
Python tracker
<http://bugs.python.org/issue25
Davin Potts added the comment:
Thank you, Winterflower, for the nudge to see this set right.
In truth, invoking multiprocessing.freeze_support() has zero effect on
platforms other than Windows.
This should be reflected in the 2.7 docs as well as the 3.x docs that are still
actively being
Changes by Davin Potts :
Added file:
http://bugs.python.org/file41331/issue_5501_explicit_freeze_support_nonWin_v3x.patch
___
Python tracker
<http://bugs.python.org/issue5
Changes by Davin Potts :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue5501>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue25908>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue12174>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
Given that the issue can not be reproduced except on an older version (3.3)
that is no longer being actively maintained, the proper thing to do is mark
this as "out of date".
If the problem recurs with 3.5 (once cx_Freeze can be tried there) then
Davin Potts added the comment:
Ned's comments summarize this nicely. It's been 7 months without a response
from the OP and given the nature of the OP's environment (use of crouton on a
chromebook) it strongly supports the theory that the OP simply had insufficient
resources
Davin Potts added the comment:
Despite attempts to reproduce the reported behavior, we don't have anything
usable to chase down. It's been 20 months without a response from the OP.
There's not much more we can do.
--
resolution: -> works for me
stage: -> res
Davin Potts added the comment:
Noting the connection to issue22393.
--
dependencies: +multiprocessing.Pool shouldn't hang forever if a worker process
dies unexpectedly
___
Python tracker
<http://bugs.python.org/is
Davin Potts added the comment:
Two core issues are compounding one another here:
1. An un-pythonic, inconsistent behavior currently exists with how managed
lists and dicts return different types of values.
2. Confusion comes from reading what is currently in the docs regarding the
expected
Changes by Davin Potts :
--
assignee: jnoller -> davin
___
Python tracker
<http://bugs.python.org/issue6766>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Davin Potts:
In the docs, references to :class:`Namespace` can not be matched by Sphinx to
any class definition because there isn't one in the doc. It should be placed
in the "Namespace objects" subsection and the initial descriptive para moved
inside
Davin Potts added the comment:
@neologix: I second your proposed patch -- looks like a winner to me.
Apologies for not following up earlier.
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue8690>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue26333>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue25931>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
I can reproduce the problem under Windows 7. Thank you for your example and
description -- they were very helpful.
Detection that the original parent was PythonService.exe is necessary to avoid
undoing the paths set appropriately for running under a service
Davin Potts added the comment:
Using tools like pyinstaller (and other competing frozen-exe-creating tools)
unfortunately complicates things for multiprocessing to understand the
environment it's now in. It is unclear from this description whether this
should be regarded as an issue
Davin Potts added the comment:
Attached is a patch for the 2.7 branch which adds the check described in the
previous message.
I don't see a reasonable way to provide an accompanying test because it
requires registering a win32 service (requiring administrative privileges)
temporari
Davin Potts added the comment:
Closing as the original reporter has not responded to requests for additional
information after 4.5 months.
--
resolution: -> out of date
stage: -> resolved
status: pending -> closed
___
Python track
Davin Potts added the comment:
As described in issue23403, it is possible for independent processes to
communicate to one another through multiprocessing. Thus changing the default
triggers complications and is arguably much less interesting than having
control over what protocol (or
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue26633>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue26732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue18382>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue22872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
Tested Steve's code snippet on Windows 7 64-bit without the patch on default
(3.5) and got result: True
Not knowing the full history here, I blindly tried on the same Win7 system with
2.7.8 and got a False. Looks like Richard's patches made in #12328
Davin Potts added the comment:
For my part, I'm now good with all aspects of the patch supplied by Alon.
I have a working set of tests that will be attached in the next day or two
after seeing them behave on more than one platform.
--
stage: -> tes
Davin Potts added the comment:
Successfully reproduced on OS X 10.10 with 2.7.9.
Changing the issue type to "behavior" because "crash" is reserved for "Hard
crashes of the Python interpreter – possibly with a core dump or a Windows
error box." In this issue, we
Davin Potts added the comment:
A much simpler example of code triggering the described issue:
import multiprocessing.managers
with multiprocessing.managers.SyncManager() as s:
print "here"
Running the above code in 2.7.9 results in an exception with the
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue23513>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
I have a working patch that addresses this behavior and tests to go along with
it but am still working on updating the docs. Updating the docs in 2.7 in a
way to as closely match the docs in 3.4/3.5 as possible seems reasonable. It
remains unclear why
Davin Potts added the comment:
Detecting the number of processors available to a process is a distinct concept
from reporting the number of processors present on a system. cpu_count is
currently focused on the latter.
Functionality to report the number of effectively-available processors is
Davin Potts added the comment:
Steve: FWIW, it looks like a good solution to me.
--
___
Python tracker
<http://bugs.python.org/issue18382>
___
___
Python-bug
Davin Potts added the comment:
Adding an option does sound like a better possibility. Still, when I start
looking through the examples that psutil provides, it reminds me how this is
but one small piece of a much larger picture which psutil has done a nice,
focused job of working to address
Davin Potts added the comment:
Confirmed that the issue can be reproduced under 2.7.9 on OS X 10.10.
It is not possible to reproduce the issue with default (3.5) -- taking a look
at what's different there, notably the import of is_exiting has moved to the
top of the queues module and
Davin Potts added the comment:
Attaching a patch for 2.7 that applies Florian's fix and provides a test for it
as well.
Although the issue is not triggered on 3.4 or default (3.5), there is the
potential for regression there -- attaching a single patch that works for both
3.4 and 3
Changes by Davin Potts :
Added file:
http://bugs.python.org/file38273/issue_22853_only_test_import_lock_in_queue_py34_and_py35.patch
___
Python tracker
<http://bugs.python.org/issue22
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue17140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
In the docs for 2.7, multiprocessing.Lock refers to threading.Lock in which the
signature for acquire looks like:
threading.Lock.acquire([blocking])
However, in the current code in 2.7, Modules/_multiprocessing/semaphore.c
implements
Davin Potts added the comment:
To be fair, the docs in 2.7 do actually mention the use of 'block' instead of
'blocking' in acquire though it does so inside a "Note" block a bit later in
the docs after first claiming that multiprocessing.Lock is a "clone&q
Davin Potts added the comment:
The runnable example in the attached file, issue_23513_play.py, suggests a way
to preserve the inheritance of the Result class in any subclasses of Thing yet
leaves the definition of Thing.worker as the OP first had it (in the most
straightforward way).
In
Davin Potts added the comment:
Attaching a further revised patch for 3.4 and 3.5/default, now with cleaned-up
code style per the discussion in the review.
No changes are prompted for the patch to 2.7 as it only contained changes to
the docs and nothing code-related.
Thanks again goes to
Davin Potts added the comment:
The discussion in issue23484 is leading to a recommendation that the docs be
changed to reflect the actual behavior of multiprocessing's Lock and its close
relatives.
As far back as 2.6.9, calling release() on an unlocked threading.Lock triggered
a thread.
Davin Potts added the comment:
Updates to both cx-freeze and multiprocessing in the meantime may likely have
addressed this since this issue was first reported. Granted, diagnosing issues
with cx-freeze are best directed to the cx-freeze project -- that is perhaps
where this issue should be
Davin Potts added the comment:
This same issue came up recently in issue23582. Really, it should have been
addressed in this issue here first and issue23582 marked as a duplicate of this
one but these things don't always happen in a synchronous or apparently-linear
fashion.
Adding to
Changes by Davin Potts :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20147>
___
___
Python-bugs-list mailing list
Unsubscrib
Davin Potts added the comment:
The original issue now appears addressed in the docs (thanks goes to Stuart and
Jesse) though it was not explicitly tracked here as a patch file.
The follow-on secondary issue from spongebob (if that is your real name) could
not be reproduced by Richard.
This
Davin Potts added the comment:
Doing cleanup: This was marked as out of date in 2010 but somehow escaped
being marked closed. Closing now.
--
nosy: +davin
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.p
Davin Potts added the comment:
Please keep in mind that this issue should only be encountered by people using
Python 3.x on a platform like Hurd (an unsupported platform) that has no
working sem_open implementation. If we try to imagine what Python 3.x users
should expect, it's that
Davin Potts added the comment:
Corrected patch for 3.4 and default/3.5 -- newly introduced test is now turned
on this time and the dangling weak references are properly addressed as well as
the reference to Empty. Nastiness.
Good save, Serhiy.
--
Added file:
http://bugs.python.org
Davin Potts added the comment:
Updated (1) the patch for default/3.5 and 3.4 and (2) the patch for 2.7 to
reflect recommendations from the review.
Thanks goes to Serhiy for the helpful review and especially the suggestion on
better future-proofing in the tests.
--
Added file:
http
Changes by Davin Potts :
Added file:
http://bugs.python.org/file38363/issue_23051_revised_fix_and_tests_v27.patch
___
Python tracker
<http://bugs.python.org/issue23
Davin Potts added the comment:
> No, I suggested to replace only the line that produces AttributeError now.
Ah! Sorry, I misunderstood and incorrectly assumed you were imagining the
import to happen at the top of the module.
I must confess I am hesitant about the idea of putting an imp
Davin Potts added the comment:
Attaching updated single patch for both default/3.5 and 3.4 to use Serhiy's
insightful simplification.
This updated patch has been tested on current Debian Hurd (see earlier comments
about full battery of tests there) and OS X 10.10 (full, verbose tests).
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue21779>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
I am unable to reproduce the described behavior using the script provided in
that gist using Python 2.7.9 on OS X 10.10 with scikit-learn 0.15.2, scipy
0.14.0, numpy 1.9.0.
For me, the sample code runs happily through to completion.
Can the OP still reproduce
Davin Potts added the comment:
While the mockup of the code that you provided is of some help, it is still
unclear whether the problem could originate from your hand-rolled
serialization/de-serialization implementation or somewhere else. The traceback
you shared could even suggest an
Davin Potts added the comment:
Unable to reproduce on Ubuntu 12.04.5 with Python 2.7.8 and current libtk8.5
and libtcl8.5 releases using the attached hanger.py example.
Key findings to-date:
1. Posts to this issue have concluded that there exists a problem with thread-
and process-safety in
Davin Potts added the comment:
Can the OP provide a runnable example to help us understand what they are
actually trying to do?
There is simply not enough information for us to go on here -- Torsten's
suggestion is a good one but we need more information to help any further.
--
Davin Potts added the comment:
Attaching patch for both 3.4 and default/3.5 (single file works for both) which
fixes the test to properly adjust for running under -Werror.
Whether -Werror is set or otherwise the equivalent of
'warnings.simplefilter("error", Warning)
Changes by Davin Potts :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue21779>
___
___
Python-bugs-list mailing list
Unsubscrib
Davin Potts added the comment:
Yes, setting -Werror::ResourceWarning would indeed cause the test to fail again.
A couple of options we could potentially adopt:
1. Decide to ignore anything extra in the file anytime any kind of "error"
filterwarning is present.
2. Decide to ignor
Davin Potts added the comment:
Per Richard's post from 1 year ago where he offers both explanation and an
example, ultimately concluding that things are working as intended, and because
there have been no objections or requests for clarification in the past year,
closing this and marki
Davin Potts added the comment:
After pondering it for two days and coming back to it with hopefully "fresh
eyes", I believe that changing the for-loop to a while-loop is not overall
easier to understand -- I would lean towards keeping the for-loop.
I do think the change to the while
Davin Potts added the comment:
Are you looking at the current code in the 2.7 branch or just at the code
committed in https://hg.python.org/cpython/rev/da5b370f41a1 (done as part of
issue13854)?
The code in 2.7 has since been updated and appears to use an exitcode of 1
whenever a str is
Davin Potts added the comment:
This is closely related to issue23510. The two issues are reacting to the same
underlying inconsistency though in this issue the problem is more generally
(and clearly) stated whereas issue23510 is more concerned with the consequences
to using these as Context
Davin Potts added the comment:
To provide supporting information, using the i386 release of FreeBSD 10.1:
* ctypes fails to build with the latest from Python 2.7 branch with the message:
build/temp.freebsd-10.1-RELEASE-i386-2.7-pydebug/usr/home/davin/pycoredev/cpython/Modules/_ctypes
Davin Potts added the comment:
Reading issue22634 suggests that perhaps this issue is not limited to FreeBSD
-- issue22634 appears to suffer the same behavior on RHEL 6.4 and 5.5 when
compiling to 32-bit (the -m32 compiler flag is being used there
Davin Potts added the comment:
Comparing this to issue23042, this same behavior appears on i386 releases of
FreeBSD 8.3 and 10.1 (the i386-RELEASE means it's 32-bit as opposed to 64-bit
build). Given that this issue is being triggered here with -m32 (triggers
building of 32-bit binaries
Davin Potts added the comment:
Attaching a patch which enabled successful compilation of ctypes on FreeBSD
10.1 i386-RELEASE in each of default/3.5, 3.4, and 2.7 branches.
This patch attempts to fix the incomplete logic regarding Windows target
platforms in the ifdef's inside Modules/_c
Changes by Davin Potts :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue23042>
___
___
Python-bugs-list mailing list
Unsubscrib
Davin Potts added the comment:
There is now a proposed patch on issue23042 which, having gone through those
changes, may well address this issue too.
Testing that patch on multiple platforms (including the RHEL variants relevant
here) would be much appreciated.
Thanks goes to @lemburg for
Davin Potts added the comment:
No, it's premature to share the start of my patch.
Very much agreed on getting that input/insight -- sbt (multiprocessing module
maintainer and original author) was added to the nosy list yesterday too.
--
___
P
Davin Potts added the comment:
@siyuan: Duping it -- thanks for trying that patch out so quickly!
--
superseder: -> ctypes module doesn't build on FreeBSD x86
___
Python tracker
<http://bugs.python.org
New submission from Davin Potts:
test_imap_unordered_handle_iterable_exception fails intermittently on some
platforms due to the test being too rigid (fragile) about the order of the
items being iterated over which, as the name would imply, is not guaranteed.
Of the multiprocessing module&#
Davin Potts added the comment:
Attaching patch for this fragile test for default/3.5 and 3.4 branches.
Blame for implementing the fragile test falls to @davin. In my own defense,
@davin also discovered it in testing on FreeBSD 10.1 i386-RELEASE.
--
keywords: +patch
Added file:
http
Davin Potts added the comment:
Attaching patch for this fragile test for 2.7 branch.
Patches have been put through test.regrtest on OS X 10.10 (64-bit), FreeBSD
10.1 i386 (32-bit), and Raspbian Debian (ARMv6) thus far.
--
stage: -> patch review
Added file:
http://bugs.python.
Davin Potts added the comment:
Inheriting the priority from issue22634 which has been marked closed->duplicate
(duplicate of this issue).
Previously issue22634 was given a priority of "release blocker" by @pitrou.
Issue22634 described how this issue also afflicts 32-bit build
Davin Potts added the comment:
Since the time of its introduction in 2.6, a call to
multiprocessing.Lock.release on an already unlocked lock resulted in behavior
that did not match that of threading.Lock.release (which raised a thread.error
as far back as 2.4 and probably longer than that
Changes by Davin Potts :
--
versions: +Python 2.7, Python 3.4
___
Python tracker
<http://bugs.python.org/issue21342>
___
___
Python-bugs-list mailing list
Unsub
Changes by Davin Potts :
Added file: http://bugs.python.org/file38703/issue_23484_doc_locks_py27.patch
___
Python tracker
<http://bugs.python.org/issue23484>
___
___
Pytho
Davin Potts added the comment:
Attaching patches for 3.5/default, 3.4, and 2.7 which update the documentation
on multiprocessing.Lock, RLock, Semaphore, and BoundedSemaphore to describe
their actual implemented behavior, replacing the existing, misleading claim
that they are clones of
Changes by Davin Potts :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue23484>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue18620>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
@haypo: Could you please take a look at applying my patches from issue23713 to
address an intermittent multiprocessing test failure? I don't know that it is
the sole cause, but it is indeed one potential source of the misbehavior.
--
nosy: +
Davin Potts added the comment:
@haypo: I didn't think that one through -- the consequences of that fragile
test are not a hang. It's unrelated.
--
___
Python tracker
<http://bugs.python.o
Davin Potts added the comment:
@berker: I would have said this should not be marked an enhancement as the
proposed solution (in the patch) is to correct the errors in the documentation
to accurately describe the current implemented behavior. Does that make sense?
Whatever label we give it
Davin Potts added the comment:
@berker: Sadly, I've read those descriptions in triaging.html more than once
and that part apparently did not stick in my head. Hopefully it will now --
thanks.
@r.david: Ok, cool -- I had been mentally associating more significance to one
versus the
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue23852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
Updating patch for default/3.5 and 3.4 branches to remove versionchanged
message on {Lock,RLock}.acquire per feedback from @berker.
--
Added file:
http://bugs.python.org/file38867/issue_23484_doc_locks_py35_and_py34_noverchange.patch
Davin Potts added the comment:
Same for 2.7 branch.
--
Added file:
http://bugs.python.org/file38868/issue_23484_doc_locks_py27_noverchange.patch
___
Python tracker
<http://bugs.python.org/issue23
Davin Potts added the comment:
Serhiy: If I understand correctly what you suggest, calling sorted(it) or
list(it) would run the iterator all the way until it raises the SayWhenError
exception, triggering the self.assertRaises before it ever actually gets to
call the self.assertEqual or
Davin Potts added the comment:
Closing this very stale issue as out of date with no response from OP since
request months ago for enough info to be able to proceed.
--
resolution: -> out of date
status: pending -> closed
___
Python tracker
201 - 300 of 351 matches
Mail list logo
