Changes by Maciej Fijalkowski <fij...@gmail.com>:
--
nosy: -fijall
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28240>
___
_
Maciej Fijalkowski added the comment:
On windows the profiler runs in a separate thread and pauses/restarts other
threads (hence the requirements are slightly different). HEAD_LOCK etc. are def
not async-signal safe, but it's not an issue on linux
New submission from Maciej Fijalkowski:
Hi
The use case here is for C-based statistical profilers. When running vmprof on
linux/os x, you can get the current thread state from
PyThreadState_GetUnchecked or a similar solution. However, on windows you need
to walk all the interpreter state
Maciej Fijalkowski added the comment:
The easiest way to check is to run the tests attached
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Maciej Fijalkowski added the comment:
Then maybe it's fixed, I have no idea
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Maciej Fijalkowski added the comment:
Apparently you can't have an opinion from ctypes experts. Can you please commit
the upstream fix that has been committed 3 years ago or just stop vendoring
random, old, broken version of ctypes if you can't maintain it enough to pull
fixes from upstream
New submission from Maciej Fijalkowski:
All the internal uses of this API guard everything with HEAD_LOCK/HEAD_UNLOCK
that's not exposed. It's not safe to traverse the whole API without holding
those locks and those locks are static and module local
--
messages: 261030
nosy: fijall
New submission from Maciej Fijalkowski:
I've tried following the dev guide (still not successful) to compile a debug
version of cpython 2.7 and a couple issues that I run into:
* The VS2010 vs VS2008 confustion - the docs say "most versions before 3.3 use
VS2008" - what does it mea
Maciej Fijalkowski added the comment:
Hi
I can answer precise questions, which tests are you asking about?
Note that if the point is to unify the test suite, would be cool to make
changes to both pypy and cpython and not just change cpython one
Maciej Fijalkowski added the comment:
I find numbers really hard to believe. It would mean that over 40% of django
templates is string hashing (assuming 2x speedup) which really sounds
unbelievable.
In fact in PyPy I never found string hashing to be significant while I would
expect PyPy
Maciej Fijalkowski added the comment:
Hi
Looking through your comments, yes, maybe those tests or those things require
fixing. We at pypy don't have enough will to fight python-dev most of the time,
so the usual approach is to do "minimal hack that works" without trying to
dwelv
Changes by Maciej Fijalkowski fij...@gmail.com:
--
nosy: +fijall
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19336
___
___
Python-bugs-list
Hello.
We're pleased to announce an alpha release of PyPy 2.0 for ARM. This is mostly
a technology preview, as we know the JIT is not yet stable enough for the
full release. However please try your stuff on ARM and report back.
This is the first release that supports a range of ARM devices -
Maciej Fijalkowski added the comment:
The issue is reported upstrem and is/will be fixed
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17423
Maciej Fijalkowski added the comment:
It's not a copy for systems that don't provide libffi, since CPython makes
zero effort to try to use system libffi if present.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17423
New submission from Maciej Fijalkowski:
The bug is a little tricky to reproduce. You need a 32bit linux. First compile
x.c with:
gcc -O3 -g -shared -o x.so x.c -std=c99 -msse3 -ftree-vectorize -mfpmath=sse
and run x.py. It segfaults because the alignment of stack is not preserved (and
it's
Changes by Maciej Fijalkowski fij...@gmail.com:
Added file: http://bugs.python.org/file29410/x.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17423
Changes by Maciej Fijalkowski fij...@gmail.com:
Removed file: http://bugs.python.org/file29409/x.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17423
Changes by Maciej Fijalkowski fij...@gmail.com:
Added file: http://bugs.python.org/file29411/x.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17423
Changes by Maciej Fijalkowski fij...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file29412/ffi.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17423
Maciej Fijalkowski added the comment:
This patch is not in the whatever version ubuntu supplies. Btw, this is code
duplication, since there is already darwin alignment, see 17423
--
nosy: +fijall
___
Python tracker rep...@bugs.python.org
http
Maciej Fijalkowski added the comment:
Also IMO -OO should stop talking about optimizations. Maybe Do what -O does
and discard docstrings?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17232
Maciej Fijalkowski added the comment:
There were not for at least 10 years. I would also be the first one to strongly
object adding optimizations only under -O, because that already changes
semantics.
--
___
Python tracker rep...@bugs.python.org
New submission from Maciej Fijalkowski:
Here: http://docs.python.org/2/reference/datamodel.html, as per python-dev
discussion
--
assignee: docs@python
components: Documentation
messages: 182364
nosy: docs@python, fijall
priority: normal
severity: normal
status: open
title: Mark __del__
New submission from Maciej Fijalkowski:
This is what the current documentation says:
-O
Turn on basic optimizations. This changes the filename extension for compiled
(bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE.
-OO
Discard docstrings in addition to the -O optimizations
Maciej Fijalkowski added the comment:
As per discussion on python-dev, this bug should probably be reopened and the
patch maybe reverted as relying on the refcounting hack is both dodgy and hurts
other implementations, like PyPy.
--
nosy: +fijall
, but are being actively worked on, are:
* Faster JIT warmup time.
* Software Transactional Memory.
Cheers,
Maciej Fijalkowski, Armin Rigo and the PyPy team
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http
Maciej Fijalkowski fij...@gmail.com added the comment:
Hi.
This is what we did with Armin: http://bpaste.net/show/32123/
It seems there is still *some* information leaking via side-channels, although
it's a bit unclear what. Feel free to play with it (try swapping, having
different object
Maciej Fijalkowski fij...@gmail.com added the comment:
On Fri, Jun 15, 2012 at 9:41 AM, Nick Coghlan rep...@bugs.python.orgwrote:
Nick Coghlan ncogh...@gmail.com added the comment:
To repeat, the specific feature being proposed for retention is:
* a function called hmac.total_compare
Maciej Fijalkowski fij...@gmail.com added the comment:
On Fri, Jun 15, 2012 at 9:47 AM, Martin v. Löwis rep...@bugs.python.orgwrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
To repeat, the specific feature being proposed for retention is:
To repeat, no use case has been
Maciej Fijalkowski fij...@gmail.com added the comment:
On Fri, Jun 15, 2012 at 9:55 AM, Hynek Schlawack rep...@bugs.python.orgwrote:
Hynek Schlawack h...@ox.cx added the comment:
and any other place that compares passwords, tokens, …
No no no. Any sensible place to compare passwords
Maciej Fijalkowski fij...@gmail.com added the comment:
On Fri, Jun 15, 2012 at 10:09 AM, Martin v. Löwis rep...@bugs.python.orgwrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
Note that this does not relief you from using a time-independent
comparison
function. If you call
Maciej Fijalkowski fij...@gmail.com added the comment:
secure_compare leaks the password always. Note that it takes different time to
create a result of ord() depending whether it's =100 or 100 due to caching
of small numbers. Such functions should be written in C.
--
nosy: +fijall
Maciej Fijalkowski fij...@gmail.com added the comment:
Ah unicodes. is encode('unicode-internal') independent on the string
characters? I heavily doubt so. you leak at least some information through that
function alone.
--
___
Python tracker rep
Maciej Fijalkowski fij...@gmail.com added the comment:
Antoine, seriously? You want to explore a function that's called secure when
the only thing you know about it is probably secure? This is extremely tricky
business and I think it should be called secure only if you can prove it's
secure
Maciej Fijalkowski fij...@gmail.com added the comment:
export not explore. Why can't I edit my own post?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15061
Maciej Fijalkowski fij...@gmail.com added the comment:
For unicode at the very least it's not an improvement at all. With the patch
mentioned that does encode it's also not an improvement at all. Prove as in
reason about the function in C and make sure it does not do any conditionals
Maciej Fijalkowski fij...@gmail.com added the comment:
Hi Christian. It's either secure or it's not. If it's not, there is no point in
introducing it at all as I don't think it's a good idea to have a
kind-of-secure-but-i-dont-know functions in stdlib.
If you restrict input to bytes it looks
PyPy 1.9 - Yard Wolf
We're pleased to announce the 1.9 release of PyPy. This release brings
mostly
bugfixes, performance improvements, other small improvements and overall
progress on the `numpypy`_ effort.
It also brings an improved situation on Windows
New submission from Maciej Fijalkowski fij...@gmail.com:
Example to get a segfault attached. Crashes under python3 as well.
--
files: x.py
messages: 155028
nosy: fijall
priority: normal
severity: normal
status: open
title: Segfault when using re.finditer over mmap
type: crash
versions
PyPy 1.8 - business as usual
We're pleased to announce the 1.8 release of PyPy. As habitual this
release brings a lot of bugfixes, together with performance and memory
improvements over the 1.7 release. The main highlight of the release
is
==
PyPy 1.7 - widening the sweet spot
==
We're pleased to announce the 1.7 release of PyPy. As became a habit, this
release brings a lot of bugfixes and performance improvements over the 1.6
release. However, unlike the previous
`_, not
counting the numerous bugs that were found and reported through other
channels than the bug tracker.
Cheers,
Hakan Ardo, Carl Friedrich Bolz, Laura Creighton, Antonio Cuni,
Maciej Fijalkowski, Amaury Forgeot d'Arc, Alex Gaynor,
Armin Rigo and the PyPy team
.. _`jitviewer`:
http
Maciej Fijalkowski fij...@gmail.com added the comment:
I can hardly think about a specification that would potentially help me
identify actual sizes. Even as a rough estimation. Which experts you had in
mind?
--
___
Python tracker rep
Maciej Fijalkowski fij...@gmail.com added the comment:
Which experts you had in mind?
People who know how the Python implementation works.
I'm serious. What semantics would make sense to anyone? Even if you know
implementation quite well a single number per object does not provide enough
New submission from Maciej Fijalkowski fij...@gmail.com:
sys module documentation (as it is online) has some things that in my opinion
should be marked as implementation details, but are not. Feel free to counter
why not.
Some of them has info it should be used for specialized purposes only
Maciej Fijalkowski fij...@gmail.com added the comment:
I suppose wrt getsizeof it's more of if you provide us with a reasonable
expectations, we can implement this other than anything else.
--
___
Python tracker rep...@bugs.python.org
http
Cheers,
Carl Friedrich Bolz, Antonio Cuni, Maciej Fijalkowski,
Amaury Forgeot d'Arc, Armin Rigo and the PyPy team
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations/
New submission from Maciej Fijalkowski fij...@gmail.com:
PEP100 (http://www.python.org/dev/peps/pep-0100/) links to python starship.
Should it just link to python.org for the newest version of this doc?
--
assignee: d...@python
components: Documentation
messages: 119967
nosy: d
Maciej Fijalkowski fij...@gmail.com added the comment:
Python starship is down, I thought it's permanently down, isn't it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10244
Maciej Fijalkowski fij...@gmail.com added the comment:
That is really weird, it definitely doesn't for me. Anyway, closing the ticket
then.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10244
to the JIT code, as well as a great
speedup of compiling time.
Cheers,
Maciej Fijalkowski, Armin Rigo, Alex Gaynor, Amaury Forgeot d'Arc and
the PyPy team
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http
On Wed, Apr 15, 2009 at 1:10 PM, Georg Brandl ge...@python.org wrote:
Hi,
I managed to screw up the date, so here it goes again:
I'd like to announce that there will be a Python Bug Day on April 25.
As always, this is a perfect opportunity to get involved in Python
development, or bring
53 matches
Mail list logo
