Could be implemented as a command line command using revsets?.
Propose a new revset to mercurial devels?
It *is* implemented as a command line command using revsets.
The revset is
max(ancestors(branch(%s)))-outgoing(%s))
where the first parameter is the branch that contains your changes,
and
Given GCC's announcement that Intel's STM will be an extension for C
and C++ in GCC 4.7, what does this mean for Python, and the GIL?
I've seen efforts made to make STM available as a context, and for use
in user code. I've also read about the old attempts way back that
attempted to use finer
2011/11/30 Matt Joiner anacro...@gmail.com:
Given GCC's announcement that Intel's STM will be an extension for C
and C++ in GCC 4.7, what does this mean for Python, and the GIL?
I've seen efforts made to make STM available as a context, and for use
in user code. I've also read about the old
On Sat, Nov 26, 2011 at 11:53 AM, Éric Araujo mer...@netwok.org wrote:
Le 11/08/2011 20:30, P.J. Eby a écrit :
At 04:39 PM 8/11/2011 +0200, Éric Araujo wrote:
I’ll just regret that it's not possible to provide a module docstring
to inform that this is a namespace package used for X and
However given advances in locking and garbage collection in the last
decade, what attempts have been made recently to try these new ideas
out? In particular, how unlikely is it that all the thread safe
primitives, global contexts, and reference counting functions be made
__transaction_atomic,
Hi,
Thanks for the replies.
At this point, though, before doing any more work on the PEP I'd
like to have some idea of whether there's any chance of it being accepted.
At this point, there seems to be a lot of passive, Usenet nod syndrome
type support for it, but little active support.
If
If this helps, I am +1, and I’m sure other devs will chime in. I think
the feature is useful, and I prefer 402’s way to 382’s pyp directories.
If that's the obstacle to adopting PEP 382, it would be easy to revert
the PEP back to having file markers to indicate package-ness. I insist
on having
On Thu, Dec 1, 2011 at 1:28 AM, PJ Eby p...@telecommunity.com wrote:
It doesn't help at all that I'm not really in a position to provide an
implementation, and the persons most likely to implement have been leaning
somewhat towards 382, or wanting to modify 402 such that it uses .pyp
directory
I did see this, I'm not convinced it's only relevant to PyPy.
On Thu, Dec 1, 2011 at 2:25 AM, Benjamin Peterson benja...@python.org wrote:
2011/11/30 Matt Joiner anacro...@gmail.com:
Given GCC's announcement that Intel's STM will be an extension for C
and C++ in GCC 4.7, what does this mean
On Thu, 1 Dec 2011 01:31:14 +1100
Matt Joiner anacro...@gmail.com wrote:
However given advances in locking and garbage collection in the last
decade, what attempts have been made recently to try these new ideas
out? In particular, how unlikely is it that all the thread safe
primitives,
Azul has been using hardware transactional memory on their custom CPUs (and
likely STM in their current x86 virtual machine based products) to great
effect for their massively parallel Java VM (700+ cpu cores and gobs of
ram) for over 4 years. I'll leave it to the reader to do the relevant
On Thu, Dec 1, 2011 at 10:58 AM, Gregory P. Smith g...@krypto.org wrote:
Azul has been using hardware transactional memory on their custom CPUs (and
likely STM in their current x86 virtual machine based products) to great
effect for their massively parallel Java VM (700+ cpu cores and gobs of
I saw this, I believe it just exposes an STM primitive to user code.
It doesn't make use of STM for Python internals.
Explicit STM doesn't seem particularly useful for a language that
doesn't expose raw memory in its normal usage.
On Thu, Dec 1, 2011 at 4:41 PM, Nick Coghlan ncogh...@gmail.com
When updating the documentation, please don't go overboard with warnings.
The docs need to be worded affirmatively -- say what a tool does and show how
to use it correctly.
See http://docs.python.org/documenting/style.html#affirmative-tone
The docs for the subprocess module currently have SEVEN
On Nov 30, 2011, at 6:39 PM, Nick Coghlan wrote:
On Thu, Dec 1, 2011 at 1:28 AM, PJ Eby p...@telecommunity.com wrote:
It doesn't help at all that I'm not really in a position to provide an
implementation, and the persons most likely to implement have been leaning
somewhat towards 382, or
On Dec 1, 2011, at 1:10 AM, Raymond Hettinger wrote:
When updating the documentation, please don't go overboard with warnings.
The docs need to be worded affirmatively -- say what a tool does and show how
to use it correctly.
See
On Thu, Dec 1, 2011 at 4:10 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
When updating the documentation, please don't go overboard with warnings.
The docs need to be worded affirmatively -- say what a tool does and show
how to use it correctly.
See
On Thu, Dec 1, 2011 at 5:15 PM, Glyph gl...@twistedmatrix.com wrote:
I think both of these documents point to a need for a recommended idiom for
discussing security, or at least common antipatterns, within the Python
documentation. I like the IETF's security considerations section, because
it
On Thu, Dec 1, 2011 at 5:36 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Dec 1, 2011 at 5:15 PM, Glyph gl...@twistedmatrix.com wrote:
I think both of these documents point to a need for a recommended idiom for
discussing security, or at least common antipatterns, within the Python
19 matches
Mail list logo
