So it turns out there are two branches for multi dimensional arrays. I just
committed get/set for ndim slices on the branch numpy NDimArray , and it
turns out I am duplicating work done by someone else on the numpy-multidim
branch :( . Could that developer please contact me directly so we can
Trying to install in pypy I get
error C2065: '_Py_PackageContext' : undeclared identifier
Matti
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
I created a fork of Pillow at git://github.com/mattip/Pillow.git for
win32 Using a pypy nightly and the github code should allow you to
setup.py install Pillow for win32. Note you may need some external
libraries like libjpeg and zlib to get full functionality.
I also fixed a bug in pypy so
On 22/03/2012 1:00 PM, pypy-dev-requ...@python.org wrote:
Date: Thu, 22 Mar 2012 11:08:18 +0100
From: Armin Rigo ar...@tunes.org
To: Jacob Finkelman eh2...@wayne.edu
Cc: pypy-dev@python.org
Subject: Re: [pypy-dev] How to get PIL to install?
Message-ID:
I have done some cleaning house (it's that time of year) with
win32, on the win32-cleanup2 branch. Here are the issues I
"handled" by brutally skipping or rewriting tests:
- test_recv_send_timeout in test_sock_app was raising the proper
exception, but for some
Two copies of Python.h exist:
pypy\include\Python.h
pypy\module\cpyext\include\Python.h
When translating targetpypystandalone on win32, the created Makefile
prefers the cpyext\include.
It appears that the CConfig class used to create the Makefile is the one
in module/cpyext/api.py (since I
I have modified files in lib-python/modified-2.7 to close all open files
so that more of the lib-python tests pass in windows.
The modifications live on the win32-stdlib branch, a recent diff to
default shows:
hg diff -r default --stat
lib-python/modified-2.7/mailbox.py |
On 5/05/2012 7:53 PM, Amaury Forgeot d'Arc wrote:
2012/5/4 Matti Picus matti.pi...@gmail.com
mailto:matti.pi...@gmail.com
I have modified files in lib-python/modified-2.7 to close all open
files so that more of the lib-python tests pass in windows.
CPython 3 emits a warning when
On 25/05/2012 3:35 AM, bookaa wrote:
yes, it should be like this.
thank you
Bookaa
*From:* Amaury Forgeot d'Arc mailto:amaur...@gmail.com
*Sent:* Wednesday, May 23, 2012 9:26 PM
*To:* bookaa mailto:rors...@gmail.com
*Cc:* pypy-dev@python.org mailto:pypy-dev@python.org
*Subject:* Re: [pypy-dev]
On 26/05/2012 4:55 AM, bookaa wrote:
according to http://web.archiveorange.com/archive/v/cZ0K2Jye2cyGARzh9OlA
after patch pypy/conftest.py, pytest.py now support --cc
option:
pytest.py --cc=mingw32-gcc
On 28/05/2012 6:04 PM, bookaa wrote:
with
set cc=mingw32-gcc
this test fail:
pytest.py pypy/rlib/test/test_rpoll.py::test_translate
this is how to patch:
diff -crN pypy-pypy-4a38b43757e3/pypy/rlib/_rsocket_rffi.py
I have started a branch to support app level finding functions by
ordinals: win-ordinal
I would be happy for any comments as it progresses. Currently, I have
added tests and ordinal handling to rlib/libffi.py and module/_ffi
if I run tests one at a time, they all pass, but running in one
I think the branch is ready to be merged. It exposes finding a
function in a dll via ordinals as well as names, and brings
windows platform ctypes module one step closer to cpython
compatability.
___
pypy-dev
On 6/07/2012 8:07 AM, Robert Grosse wrote:
Hello, I am having difficulties translating Pypy, but googling
searching did not reveal any mentions of similar problems, so I am not
sure what to do.
I am not able to successfully translate Pypy, using any combination of
options I have tried. Here
at the earliest.
I am still working out the tax and other implications of issuing an
invoice for the work
to an American tax entity. This too should be clear within a month
or so.
Matti Picus
On 29/06/2012 9:08 AM, Antonio Cuni wrote:
Hi all,
as you probably know, the Py3k [1] proposal is getting
Searching for pypy windows compile on google gave me this link as the
top result, which is indeed the latest and greatest instructions for
compiling on Windows:
http://pypy.readthedocs.org/en/latest/windows.html
Please let us know if the instructions are unclear, suggested
modifications would
IMHO, *.pyc files should not be distributed with a binary pypy. This is
probably an issue for the team who supply the pypy for travis-ci.org
(since the __pycache__ files do not appear in the nightly or release
builds on pypy.org) - I think they live at https://launchpad.net/~pypy
Welcome, your help is needed and appreciated.
One thing you might want to try is adding the functionality as a pure
python. You should be
able to add a load function somewhere in the the
lib_pypy/numpypy/core/directory, and
add tests to the lib_pypy/numpypy/tests directory.
Then just run (from
Numpy's tests are a good starting point, but they tend to ignore corner
cases such as:
improper arguments,
strange mixtures of options,
passing in virtual ndarrays (lazy evaluation and slices),
empty arrays or scalars,
so we generally start with theirs and add more, trying to retain
I am trying to complete complex numbers in numpypy.
Progress is good, I picked up from previous work on the numpypy-complex2
branch.
Complex numbers come with extensive tests, it seems all the corner cases
are covered.
In porting the tests to numpypy, I came across a problem: numpy returns
Hmm, that's actually two bugs:
- the link on the web site has the wrong label but the correct link
- the buildbot picked up the wrong compiler, it should not be using the
visual stidio 10 compiler.
Thanks for pointing this out.
Matti
On 5/12/2012 9:21 PM, Gerrat Rickert wrote:
Sorry, I
Thanks for trying pypy.
Some of the nightly builds need the runtime you saw, which can be found here
http://www.microsoft.com/en-us/download/details.aspx?id=
The official version here http://pypy.org/download.html
depends on a different runtime, and a link is provided on that page to download
running 'vcredist_x86.exe' on Win32?
Signed,
Thomas
On 12/19/2012 8:43 PM, Matti Picus wrote:
Thanks for trying pypy.
Some of the nightly builds need the runtime you saw, which can be
found here
http://www.microsoft.com/en-us/download/details.aspx?id=
The official version here http://pypy.org
was not removed. Then sphinx
picks up all the rst files and boom.
Anyone want to suggest a fix?
Anyone know why we do txt - rst in the first place?
Matti
On Sun, Jan 6, 2013 at 12:04 AM, Matti Picus matti.pi...@gmail.com wrote:
Looking at https://readthedocs.org/builds/pypy shows that builds of pypy
many of the jit.backend.x86.test are failing, I am willing to put time
into solving this but have a bit of no idea where to start.
Can someone give me the end of a string to pull?
here are the last few lines of test_float, index so apparently
deadframe.jf_values is empty
Matti
fwiw, this happened on the remove-globals-in-jit branch and began
occurring soon after the first commits on the branch, after
changeset 8c87151e76f0 on that branch the test passed on 64 bit
linux.
Matti
On 5/02/2013 11:34 PM, Matti Picus
wrote:
many
warning: the stdio output of a translate is a very large webpage.
I wondered why the jit-benchmark-linux-x86-64 tests were failing to
translate, where the pypy-c-jit-linux-x86-64 passed
for instance the failed build on tannit64
test/test_ztranslation still passes even if I put an xxx in
Bool.reciprocal (line 397) in micronumpy/types.py. What am I doing
wrong?
Matti
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
Digging around, it seems that close_fds non-support on windows was in
the original subprocess module,
which was imcluded in stdlib in 2005 (renamed as such from the popen5
module), and even then
some questioned it's practicality because of race condition problems*
Py3k adds an option to list
I just noticed this on the schedule, anyone want to join me there?
https://us.pycon.org/2013/community/openspaces/numpyscipybof
Matti
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
I know this is not all that important, but...
It annoyed me that there is so much stuff on this page
http://buildbot.pypy.org/nightly
so I changed our buildbot code to sort by filesystem mtime, and put
trunk on top.
I tried it out by writing tests, and even installing a debug buildbot,
and
fijal did restart the buildbot, it didn't help.
Matti
On 21/03/2013 1:20 PM, Antonio Cuni wrote:
On 03/21/2013 05:01 PM, matti picus wrote:
I know this is not all that important, but...
It annoyed me that there is so much stuff on this page
http://buildbot.pypy.org/nightly
so I changed our
I tried kicking the new windows buildbot on py3k branch, and got a
linking error about missing
zlib in openssl
http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/897/steps/translate/logs/stdio
but I couldn't find any relevant diff between the two branches that
would cause that. Before
I was under the impression that that link flag can cause problems for 32
bit systems, but maybe we don't care? For instance see this
http://stackoverflow.com/questions/5185406/how-does-the-large-address-aware-flag-work-for-32-bit-applications-on-64-bit-com.
Why is it a problem for you to run
I would vote -1 for adding the largeaddressaware
flag to our translation proccess for nightlies. Better to run out of memory
than to use cffi to call some random dll andhave it explode. Those who are
in the know will have a compiler or can down load a free version and DIY.
Matti
On Apr 6, 2013
We started a 64 bit windows port once, but it died from lack of
interest. The port is complicated since on windows 64 bit,/longs/are
only 32 bit. This is a problem for/PyPy/right now, since it assumes that
a c/long/can hold a pointer
Can you ship a largeaddressaware exe with your code, or even
Note that patch is incomplete, it is missing an import os (thanks bdk)
that was added in a later changeset.
Matti
On 9/04/2013 10:03 PM, Peter Cock wrote:
On Tue, Apr 9, 2013 at 7:35 PM, Philip Jenvey pjen...@underboss.org wrote:
This was fixed yesterday, see: https://bugs.pypy.org/issue1440
On 11/04/2013 7:58 PM, Maciej Fijalkowski wrote:
On Thu, Apr 11, 2013 at 6:49 PM, Roger Flores aide...@yahoo.com wrote:
OK, I reworked (and attached) the patch for the suggestions to
nt_threads.[ch]. You had no comments for dtoa.c.
This is great. From
We finally have a buidlbot up and running own-windows-x86-32 tests.
The page at http://buildbot.pypy.org/summary?builder=own-win-x86-32 is
clogged with old results, could someone with superpowers please erase all
build runs before 16.4.2013 ?
Thanks,
Matti
cpyext is currently disabled on default. Is there a branch to revive it?
Or are we expecting cffi to replace all interaction with external c code?
I'm not sure what will be more painful, getting the world to rewrite all
modules or supporting cpyext, both seem non-trivial.
(I'm opening the
On 18/05/2013 10:45 PM, Maciej
Fijalkowski wrote:
On Sat, May 18, 2013 at 8:51 PM, Matti Picus matti.pi...@gmail.com wrote:
cpyext is currently disabled on default. Is there a branch to revive it?
Or are we expecting cffi to replace all
I have been trying to whip win32 own tests into passing, or at least
to an understanding of why they fail.
I am seeing the interpreter crash on the
jit.backend.x86.test.test_fficall.py, here is a traceback
http://bpaste.net/show/cM9YptahKH0PkZjp5gtN/
and the original
Running own tests on win32 gives many errors in the _sre module:
rlib/rsre/rsre_core.py:111: AssertionError
which is checking that all values of the pattern are =0
Here is one of many such failures:
Making it a r_uint did not work for me, apparently the pattern
bytecode should be signed.
It would seem to me we would want to be cpython compatible, that is
it should be of size SRE_CODE from the _sre cpython module which has
changed to 4.
Maybe someone else wants
Using Ronan's git repository and a few modifications we pass about
30% of the numpy test suite.
It seems like now is the time to add a build target to our nightly
builds that would install numpy and test a build:
1) download a pre-built version of pypy from nightlies
On 06/28/2013 12:07 PM, Maciej Fijalkowski wrote:
- buildbot has no support for git, I wrote a git_update function but it
needs test
i don't believe youhttp://docs.buildbot.net/0.8.1/Git.html
cool, thanks! I guess we have our own update_hg for historical reasons?
Matti
I got motivated and implemented parts of subtypes on ndarray in the
ndarray-subtype branch.
This page
http://docs.scipy.org/doc/numpy/user/basics.subclassing.html
describes the numpy way, so I did
ndarray.view(subtype)
as well, but I did not yet do the slice (they call it template) nor did
I do
, the
memap code I've already written may just work. Will try that next.
Mike
On Wed, Jul 3, 2013 at 3:29 PM, Matti Picus matti.pi...@gmail.com
mailto:matti.pi...@gmail.com wrote:
I got motivated and implemented parts of subtypes on ndarray in
the ndarray-subtype branch.
This page
() won't work on a memmap object.
2013/7/4 Matti Picus matti.pi...@gmail.com
mailto:matti.pi...@gmail.com
You correctly point out, in other words, that it was an ugly hack.
It is on the way to being removed by adding a space argument to
calls to from_space...().
Let us know how
The ndarray-branch passes tests both translated and untranslated. I ran
it through the numpy test suite as well, specifically the matrix class
tests, and it seems to pass them.
Would anyone like to review, or should I just go ahead and merge?
Specifically, I may have missed some w_ prefixes on
On 07/17/2013 06:36 PM, Amaury Forgeot d'Arc wrote:
2013/7/17 Maciej Fijalkowski fij...@gmail.com mailto:fij...@gmail.com
you go to your checkout (default), you do hg merge branch name and
then hg diff. if you don't like it, you do hg up -C to clean stuff up.
Easy to do in a
TL;DR : Do you have any hints/instructions as to how to test a new
buildbot task?
Thanks for the update, it seems to have cleaned up much of the code base.
I would like to add a task that installs the python part of a numpy
installation to pypy and runs numpy's tests. I have started the work
I reverted the changes I made to the pypy-pyarray branch that changed
c-api functions like PyArray_NDIM(arr).
The original code had no real answer to what happens if these are called
when arr is not an ndarray.
While the reviewers of the branch suggested that these should raise an
exception
I am getting close to being ready to merge the pypy-pyarray branch. I
related to all the review items from
https://bitbucket.org/pypy/pypy/src/1a379a6f127bd6df8a4b628575c7124e83007e60/TODO.txt
https://bitbucket.org/pypy/pypy/src/1a379a6f127bd6df8a4b628575c7124e83007e60/TODO.txt?at=pypy-pyarray
On 09/23/2013 04:01 PM, Romain Guillebert wrote:
Hi Matti
+1 for me.
On Mon, Sep 23, 2013 at 11:16 AM, Maciej Fijalkowski fij...@gmail.com wrote:
On Sun, Sep 22, 2013 at 5:26 PM, Matti Picus matti.pi...@gmail.com wrote:
I am getting close to being ready to merge the pypy-pyarray branch. I
I have been working to get numfocus benchmarks written for numpy to run
on numpypy and pypy https://github.com/numfocus/python-benchmarks
The biggest obstacle is actually the need for matplotlib, which is used
internally to produce pretty comparisons between different benchmarks.
Luckily,
and what about cloning the numpy repo into bitbucket/pypy to make it more
of a pypy owned thing?
Matti
On Tue, Oct 15, 2013 at 1:18 PM, Romain Guillebert romain...@gmail.comwrote:
Hi Matti
I think we should remove numpy.py and package the pypy-hack branch
(even if it's not stable yet) so
This zip has been downloaded more than 15000 times and you are the first to
report this problem. Please try again, and if it fails tell us exactly how
you are downloading and opening it, what is your operating system and
anything else that many help us to reproduce your specific problem
Thanks to Brian Kearns, the pypy-compat branch of the numpy repo at
https://bitbucket.org/pypy/numpy https://bitbucket.org/pypy/numpy/
is starting to become the prefrered method of using numpy on pypy. Note
this is a git repo.
All commiters to pypy should have a commit bit here, let me know if
Someone recently tried to use this repository
https://bitbucket.org/pypy/tkinter
and failed, it would seem we would be better off without it.
May I delete it?
Matti
___
pypy-dev mailing list
pypy-dev@python.org
has a cffi implementation, in lib_pypy since 2.1.
then yes please :)
OK, consider it done.
Matti
On Mon, Nov 4, 2013 at 1:16 PM, Matti Picus matti.pi...@gmail.com wrote:
Someone recently tried
There are only a handful (ok - 10, two others are from the nightly
default) of failures on the stdlib-2.7.5 branch:
http://buildbot.pypy.org/summary?branch=stdlib-2.7.5
It seems the major one is handling eintr signal on file reading, which
AFAICT would fix more or less 3 of the failures. The
I have been commenting in the bug reports. The general strategy we
recommend on the windows build page
http://doc.pypy.org/en/latest/windows.html#abridged-method-for-ojit-builds-using-visual-studio-2008
is to download a zip file with all the recommended dependencies, and
build after adding the
The sqlite3 issue was easy, we can simply replace the one on the
buildbot with the 3.6.21 version.
I have asked the buildbot manager to do the replacement.
I have opened a branch for the tkinter changes, since they require a bit
more work. Those scripts are definitely helpful, thanks.
It seems
or so) . I would suggest that we ship pypy2.2 without a functioning Tkinter
module, to be consistent with all previous pypy versions :)
Matti
On Thu, Nov 14, 2013 at 9:58 AM, Armin Rigo ar...@tunes.org wrote:
Hi Matti,
On Wed, Nov 13, 2013 at 1:01 AM, Matti Picus matti.pi...@gmail.com
wrote
Can we just say don't do that?
I guess the answer is no...
Going down the initialization route seems to be the way numpy does it, I see
import_array();
used extensively in numpy c code.
Although making sure it is only called once seems to really complicate
the header files, with API defines and
I would seriously consider Feb in Tallinn.
Matti
On 29/11/2013 7:17 PM, Romain Guillebert wrote:
Hi Ahti
I'm interested in going if this sprint happens, I'd be able to go after
February 2nd (as long as it's not during PyCon).
Cheers
Romain
On 11/26, Ahti Heinla wrote:
Hi,
I am new
It would be nice to get a modern gui widget set working with pypy.
Personally, I prefer a more liberal license, which leads to wx rather
than qt, but I imagine, given the name of your company, that you do not
share my preference :).
In any case, you might want to take a look at the
I need to turn my arm cubieboard into a DVR for the next couple of
weeks, so it will not be available as a build bot.
This will affect the builders:
pypy-c-jit-linux-armhf-v7
pypy-c-app-level-linux-armhf-v7
jitbackendonly-own-linux-armhf-v7
It should be
On Sun, Jan 26, 2014 at 2:44 PM, Johan Råde johan.r...@gmail.com wrote:
On 2014-01-26 13:34, Maciej Fijalkowski wrote:
Hi Johan
Should this mail come with some attachments?
Cheers,
fijal
___
pypy-dev mailing list
pypy-dev@python.org
On 2014-01-26 15:15, matti picus wrote:
If you wish, post the hacked Makefile to a pastebin and we can
work
backwards from there.
I would be willing to help move this forward.
Matti
I would like to ask for help with this branch, as I have not been able to
move it forward fast enough.
micronumpy tests crash on ARM, due to issues accessing raw memory in struct
arrays. It turn out that casting unaligned memory to a float or double
causes a segfault on ARM, I started to fix this
/2014 10:30 AM, Armin Rigo wrote:
Hi Matti,
On 18 February 2014 14:05, matti picus matti.pi...@gmail.com wrote:
I would like to ask for help with this branch, as I have not been able to
move it forward fast enough.
I moved it forward a little bit, but now I'm wondering if it actually
makes sense
Thanks to Arimin and Brian Kearns.
They fixed unaligned memory access, now ARM micronumpy no longer crashes
during testing.
Matti
On 02/23/2014 11:43 AM, Armin Rigo wrote:
I've checked in some new code in rawstorage.py on default:
raw_storage_{get,set}item_unaligned(). It's regular RPython
I have begun running own tests on win32.
http://buildbot.pypy.org/summary?builder=own-win-x86-32
Almost all of the module._cffi_backend.test.test_c failures are
caused by id(x) returning a long where an int is expected in
rlib\objectmodel.py compute_unique_id. Note that
win32 is failing this test
http://buildbot.pypy.org/summary/longrepr?testname=TestLLTypeLLGraph.%28%29.test_call_to_winapi_functionbuilder=own-win-x86-32build=62mod=jit.backend.llgraph.test.test_llgraph
which is testing the ability to use stdcall in llgraph.
It is failing AFAIKT
looking at this test failure
http://buildbot.pypy.org/summary/longrepr?testname=test_mathbuilder=own-win-x86-32build=86mod=jit.backend.x86.test.test_zmath
which tests that atan2(0.23/1.23) == 1.3 via OP_FLOAT_EQ(double value,
double value)
OP_FLOAT_EQ is a compiler define to (a == b), which is
The consensus on IRC is that we are ready to release PyPy 2.3 Please
help triage the bugs on bugs.pypy.org, and mark your favorite
release-critical one with the 2.3 Release tag. We could also use a name
for the release, suggestions are welcome. For an idea as to what
changed, see
the release
If you have a branch you would like included in pypy-2.3.0, please be
sure to merge it by April 28. At that point I will merge, for the last
time, default into the release branch.
Matti
___
pypy-dev mailing list
pypy-dev@python.org
The macos buildbot, names xerses, has a consistent test failure. It
appears to be a configuration error of the buildbot. The owner of the
buldbot has not responded on IRC.
Could someone else build a macos version off the release branch
release-2.3.x that does not exhibit this failure and ships
You have been chosen by an advanced algorithm to participate in the alpha
release of PyPy 2.3.
Well, not so advanced, but please try it out, I want to release over the
next few days.
The remaining issues are:
- rumors of the python 3.4 ensurepip module appearing in pypy
- the macos build has a
luckily, it is only patented, not trademarked AFAIK
http://www.google.com/patents/US20110289822
Matti
On 05/05/2014 10:48 AM, Armin Rigo wrote:
Hi Matti,
On 4 May 2014 13:42, matti picus matti.pi...@gmail.com wrote:
I would also appreciate help with the release notice, the name Easier Than
I will try to upload the builds later today and complete the release,
unless someone asks me to delay now.
We still need a volunteer to build for macos since the buildbot has some
problem with the openssl versioning. If anyone can help, please translate
and make sure you can run the
https://bitbucket.org/pypy/pypy/downloads
Please try them out, let me know if anything seems wrong.
Matti
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
When should we release 2.3.1?
Matti
On 11/05/2014 8:07 PM, Armin Rigo wrote:
Hi Yaacov,
On 11 May 2014 17:04, Yaacov Finkelman yeomanyaa...@gmail.com wrote:
C:\pypy\pypy.exe -i C:\pypy\lib-python\2.7\idlelib\idle.py
** IDLE can't import Tkinter. Your Python may not be configured for Tk. **
Hi. I am looking at adding the ability to monitor a bitbucket-hosted git
repo to the bbhook module in pypy's buildbot. The current design
requires a repo copy to monitor. Couldn't we just use the payload from
bitbucket instead of requiring a repo copy?
Matti
Please download and try out the release candidate 71938-32f35069a16d from
http://buildbot.pypy.org/nightly/release-2.3.x
Comments on the release notice
http://doc.pypy.org/en/latest/release-2.3.1.html
are welcome as well. Barring last minute failures, I intend to release
over the weekend.
Matti
Thanks, fixed. It may take a few minutes to percolate out, and then you
need to refresh the cached page.
Matti
On 06/08/2014 04:22 PM, David Naylor wrote:
Hi,
The links to the source tarballs are broken (on the download page).
Regards
On Sunday, 8 June 2014 09:08:41 Armin Rigo wrote:
Hi
See issue 1630, we should be 1.5 times slower on the latest version
(2.3.1)
https://bitbucket.org/pypy/pypy/issue/1630
We do have plans for being faster, but it will take a while to get
there.
Note that your pre-allocation of c is not used by a.dot(b),
We are down to the last 50 own tests on win32.
Here is one I need help with:
http://buildbot.pypy.org/summary/longrepr?testname=TestLowLevelType.%28%29.test_round_up_for_allocationbuilder=own-win-x86-32build=162mod=translator.c.test.test_lltyped
The failure is that, like ARM, ssize ==
if PYPYLOG is a filename, we log to it (except debug_print)
if PYPYLOG is :filename, we log debug_print as well
if PYPYLOG is section:filename, we log only that section
But : is a valid char for filename on windows, so something like
PYPYLOG=C:\TEMP\log.log
does the wrong thing, and even worse,
on windows own build, tests that call ctypes2lltype with an Unsigned
failed last night's build, for instance
http://buildbot.pypy.org/summary/longrepr?testname=test_connect_exbuilder=own-win-x86-32build=164mod=rlib.test.test_rsocket
Running this test alone passes.
Two questions
1. Should there
in looking at the own test_rzipfile failures on windows[0], the
annotator is failing in rtyper.rpbc.redispatch_call since the method
being called is a MultipleFrozenPBCRepr .
The method is flush_buffers from (it seems) streamio.Stream [1]
Any hints how this can happen?
Matti
[0]
Cpython has a feature that allows you to call c-api functions from
python via ctypes.pythonapi
It doesn't currently work on pypy, I started to document why not on
the disable_pythonapi branch:
``ctypes.pythonapi`` lets you access the CPython C API
emulation
Sorry, it's my fault, I didn't download/repackage/upload the source
files as in previous builds, it seemed redundant.
I see it was not, so I will try to fix.
Matti
On 22/06/2014 1:12 PM, Laurence Tratt
wrote:
I feel I might be going mad but I
:34 AM, Armin Rigo wrote:
Hi Matti,
First question, what is the relationship of this mail and PyPy on Windows?
On 21 June 2014 22:24, Matti Picus matti.pi...@gmail.com wrote:
``ctypes.pythonapi`` lets you access the CPython C API
emulation layer. It does not work on PyPy at the moment
(..., sys.dllhandle) and served
up as ctypes.pythonapi.
Working backwards from no pythonapi - no PyDLL - no sys.dllhandle.
Matti
On 25/06/2014 5:04 PM, Armin Rigo wrote:
Hi Matti,
On 25 June 2014 14:47, Matti Picus matti.pi...@gmail.com wrote:
removes sys.dllhandle on windows,
Can you explain
Googling sys.dllhandle gave me no other uses, the only use case I can of
think would
involve casting to some kind of ctypes dll and accessing capi (cpyext)
capabilites.
The original failing test that led me down the path to discover all this
was
module.cpyext.test.test_cpyext's
I have created a meta-issue
https://bitbucket.org/pypy/pypy/issue/1855
and a release notice
http://pypy.readthedocs.org/en/latest/release-2.4.html
Help resolving open issues, adding more existing issues that are
critical, and/or edits to the release notice would be
Get it while it's hot, let me know if something is wrong.
https://bitbucket.org/pypy/pypy/downloads
Comments and corrections on the release notice would be appreciated
http://pypy.readthedocs.org/en/latest/release-2.4.0.html
Please test the MacOS version since we have had reports in the past
1 - 100 of 472 matches
Mail list logo
