On 7/3/22 22:19, Aksam Lwanga wrote:
Am working on a person project I would like to know how meta trace
limit configured for pypy.any assistance needed is highly appreciated.
On Mon, Mar 7, 2022, 3:43 PM Aksam Lwanga wrote:
Hello , I would like to understand how to set pypy trace limit
Am working on a person project I would like to know how meta trace limit
configured for pypy.any assistance needed is highly appreciated.
On Mon, Mar 7, 2022, 3:43 PM Aksam Lwanga wrote:
> Hello , I would like to understand how to set pypy trace limit . Any link
> available for use will highly
On 20/2/22 16:40, Alex Gaynor wrote:
FYI there seems to be an issue with the formatting of the blog post:
Alex
Thanks Alex, fixed now.
Matti
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
On 20.02.22 06:36, Matti Picus wrote:
I have released PyPy v7.3.8. Thanks to all who contributed and tested
and for moving PyPy forward.
Hi all,
Matti and I have discussed that this is the last 3.7 release. We'll stop
running 3.7 nightly and can merge directly from default to the py3.8
branch.
On 27. 01. 22 0:03, Matti Picus wrote:
This is a release of 4 versions of python: 2.7, 3.7, 3.8 (no longer beta) and
3.9 (beta quality).
Release note: https://doc.pypy.org/en/latest/release-v7.3.8.html
Downloads: https://downloads.python.org/pypy
checksums: https://www.pypy.org/checksums.h
Downloads: https://downloads.python.org/pypy
On 27/1/22 01:03, Matti Picus wrote:
This is a release of 4 versions of python: 2.7, 3.7, 3.8 (no longer
beta) and 3.9 (beta quality).
Release note: https://doc.pypy.org/en/latest/release-v7.3.8.html
Downloads: https://
checksums: https://www.
On Mon, 13 Sep 2021, Carl Friedrich Bolz-Tereick wrote:
The speedup was achieved in relatively boring ways. In summary, nothing
deep, lots of legwork.
Hi Carl,
Thank you very much for the summary, it was very interesting to read!
Congratulations to the PyPy Team even (or even more so) if the
On Mon, 2021-09-13 at 18:21 +0300, Matti Picus wrote:
> The release candidates for pypy v7.3.6rc1 for python2.7, python3.7, and
> python3.8 are up. This is our first release of 3.8. This release also
> includes a backend for HPy0.0.2 (may be upgraded to 0.0.3 by the final
> release). This releas
On 13.09.21 17:29, Yury V. Zaytsev wrote:
On Mon, 13 Sep 2021, Matti Picus wrote:
The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html
As always, edits are welcome.
It would be very interesting to know, how the amazing translation
speedup has been achieved (I hope not by remo
On Mon, 13 Sep 2021, Matti Picus wrote:
The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html
As always, edits are welcome.
It would be very interesting to know, how the amazing translation speedup
has been achieved (I hope not by removing the fractal rendering, right?),
but
On 19/4/21 1:12 pm, Thomas Liske wrote:
Hi,
I'm trying to contribute the packaging of pypy to Alpine Linux. I got
the bootstrapping for x86 x86_64 and s390x working.
On aarch64 two of the pypy tests are failing[1]:
- TestLogParser.test
- TestMicroNumPy.test_reduce_logical_and
[1] https://g
On Mon, 2021-04-19 at 19:12 +0200, Thomas Liske wrote:
> Hi,
>
> I'm trying to contribute the packaging of pypy to Alpine Linux. I got
> the bootstrapping for x86 x86_64 and s390x working.
> On aarch64 two of the pypy tests are failing[1]:
>
> - TestLogParser.test
> - TestMicroNumPy.test_reduce_
Thank a lot Matti and all PyPy developers for the work done on this release,
Two small remarks on the sentence in the release note: "There are also some
significant performance improvements around maps (dictionaries), ints, strings,
btyes and more. These were done as users reported reproducible
Matti,
Although implementation_version looks promising, it is defined as
"sys.implementation.version" which is an alias to the python version.
"implementation" is also not helpful.
does pypy even have a sys.implementation? (My installation doesn't?)
For now, I'm simply breaking the build envi
Hi,
I made everything work, I have extracted bzip and development packages of it to
customized path and then set the LD path and also I have created symbolic link
to libbz2.so.1 to 1.0.6
But, since we setup in customized path, we have to manual set the LD path which
we are not supposed to do i
Hi,
Thank you so much for your response, I tried all methods including patchelf as
well. But it din't help, hence initiated mail thread. However, I will also
find if there is something else missing on my env.
No, worries. Let me send you the complete details in sometime with snapshot but
for
Hi,
On Thu, 8 Oct 2020 at 10:22, Srinivasa Kempapura Padmanabha
wrote:
> I think it's looking for /usr/lib64/libbz2.so.1.0.0 which I am not sure if
> that's compatible
It should be, if it differs only in the last digit.
> I have created the symbolic link and yet idn't work
Sorry, I can't help
I think it's looking for /usr/lib64/libbz2.so.1.0.0 which I am not sure if
that's compatible
I have created the symbolic link and yet idn't work
Srinivasa Kempapura Padmanabha | Staff Engineer
Technology Operations Services Group
Email & SFB & Teams: srike...@arm.com
Mobile: +91 9980633788
Ba
...
ah, also the command given by matti has the arguments in the wrong
order (I think). It should be
sudo ln -s /usr/lib64/libbz2.so.1.0.6 /usr/lib64/libbz2.so.1.0
Armin
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/li
Hi,
On Thu, 8 Oct 2020 at 07:42, Srinivasa Kempapura Padmanabha
wrote:
> I am running on rhe7 aarch64, I tried but it din't work.
You have to run `ldconfig` (without arguments, as root) for the system
to pick up the new symlink.
A bientôt,
Armin
___
p
Hi,
I am running on rhe7 aarch64, I tried but it din't work.
Regards,
On 07/10/20, 10:16 PM, "Matti Picus" wrote:
On 10/7/20 1:35 PM, Srinivasa Kempapura Padmanabha wrote:
>
> Hi,
>
> When I extract the pypy prebuild package as instructions provided in
> the site. I
On 10/7/20 8:30 PM, wlavrij...@lbl.gov
wrote:
Does
anyone know how to add a marker based on the PyPy version in a
pyproject.toml file? Or, how else to enforce build dependencies
for pip in
the same way that can be done with t
On 10/7/20 1:35 PM, Srinivasa Kempapura Padmanabha wrote:
Hi,
When I extract the pypy prebuild package as instructions provided in
the site. I see that the binary fails to run
./bin/pypy3: error while loading shared libraries: libbz2.so.1.0:
cannot open shared object file: No such file or
What OS and version are you running on?
Regards,
Niklas
> On 7 Oct 2020, at 12:35, Srinivasa Kempapura Padmanabha
> wrote:
>
> Hi,
>
> When I extract the pypy prebuild package as instructions provided in the
> site. I see that the binary fails to run
>
> ./bin/pypy3: error while loading s
Hi,
On Fri, 29 May 2020 at 20:10, Joseph Jenne via pypy-dev
wrote:
> I don't have much experience with the windows side of pypy, especially
> on XP, but I would suggest trying to compile for your system, as I do
> not know of any reasons for incompatibility. That said, perhaps using a
> somewhat
I don't have much experience with the windows side of pypy, especially
on XP, but I would suggest trying to compile for your system, as I do
not know of any reasons for incompatibility. That said, perhaps using a
somewhat older version might be preferable, depending on the specifics
of your use
Hi Joseph,
Le 05/28/2020 à 10:56 PM, Joseph Jenne via pypy-dev a écrit :
On 5/28/20 8:58 AM, Denis Cardon wrote:
Hi everyone,
sorry if this is not the best place to ask the question, feel free to
forward me to a better place for this kind of question :-)
I was wondering PyPy 3.6 is supposed t
Hi Denis,
On Thu, 28 May 2020 at 18:05, Denis Cardon wrote:
> WinXP is actually still very common in industrial setups and it would be
> great if it would work with PyPy as CPython has drop WinXP support after
> 3.4.
I see the point. If some parts of the industry want a modern version
of Python
On 5/28/20 8:58 AM, Denis Cardon wrote:
Hi everyone,
sorry if this is not the best place to ask the question, feel free to
forward me to a better place for this kind of question :-)
I was wondering PyPy 3.6 is supposed to run on WinXP SP3 32bit.
Running the pypy3.exe says that it not a valid
On 21/5/20 5:49 am, Valerij “Derad6709” Lebedev wrote:
Hey sorry pls I can’t install builded nightly versions to my ubuntu...
i tried to create symlink but pip (pypy3 -mpip install installing
packages to the Python, not to pypy with symlink) could you help me,
how can I install nigthly version
I am impressed with the very fast list comprehension in PyPy 7.3.1. Thanks
to all the contributors.
In the competitive programming world, list comprehension, recursive functions,
and string concatenation were known as three slow problems of PyPy, but one of
them has been broken.
_
On 3/4/20 10:45 am, Matti Picus wrote:
I have uploaded rc1 of the upcoming pypy v7.3.1 to
https://bitbucket.org/pypy/pypy/downloads/
The sha256 hashes are here https://www.pypy.org/download.html#checksums
The release notice is here
https://doc.pypy.org/en/latest/release-v7.3.1.html
Pleas
Thanks - got it. Many thanks for the clarification.
I reread and missed the part where you mentioned that those two flags are
conflicts in CPython as well. I am sorry for my confusion there. (I'll ask
CPython folks what's up if there is need).
On Mon, Dec 16, 2019 at 6:05 AM Armin Rigo wrote:
Hi Rocky,
On Mon, 16 Dec 2019 at 11:57, Rocky Bernstein wrote:
>
> I did a little test, and for this program:
>
> # from 3.7 test_asyncgen.py
> def test_async_gen_iteration_01(self):
> async def gen():
> await awaitable()
> a = yield 123
>
> the 3.6 ASYNC_GENERATOR flag is ad
I did a little test, and for this program:
# from 3.7 test_asyncgen.py
def test_async_gen_iteration_01(self):
async def gen():
await awaitable()
a = yield 123
the 3.6 ASYNC_GENERATOR flag is added in the code object created for
"gen()" as 3.6 does. So I infer that flag 0x200
Hi,
On Mon, 16 Dec 2019 at 11:24, Rocky Bernstein wrote:
> I have a cross-version Python bytecode disassembler xdis
> (https://pypi.org/project/xdis/) and I notice that flags 0x0100 and 0x0200
> (DONT_IMPLY_DEDENT and SOURCE_IS_UTF8 respectively) conflict in Pypy 3.6 with
> Python 3.6's ITERA
OK. Thanks for the quick reply, Armin.
Mark
On Tue., Mar. 19, 2019, 12:01 p.m. Armin Rigo, wrote:
> Hi Mark,
>
> On Tue, 19 Mar 2019 at 12:46, Mark Melvin wrote:
> > I was wondering if PyPy would be a good candidate to create an embedded
> distribution of Python similar to micropython.
>
> No,
Hi Mark,
On Tue, 19 Mar 2019 at 12:46, Mark Melvin wrote:
> I was wondering if PyPy would be a good candidate to create an embedded
> distribution of Python similar to micropython.
No, PyPy's minimal memory requirements are larger than CPython's.
A bientôt,
Armin.
___
Realised I should ask this on the CFFI list, apologies for the noise.
On Saturday, March 16, 2019, 3:05:03 PM GMT, Stuart Axon
wrote:
PyCairo has a struct like
` typedef struct {
| PyObject_HEAD |
|
| cairo_t *ctx; |
|
| PyObject *base; /* base object used to create co
Re-hi,
On Fri, 8 Feb 2019 at 00:33, Armin Rigo wrote:
> getting "InvalidArgument: Invalid argument deadline" in a call to
> hypothesis.settings() (rpython/conftest.py:14) and upgrading hypothesis
> doesn't seem to help...
My mistake, an old "hypothesis" kept being used. But the logic in
rpython
Hi Anto,
On Thu, 7 Feb 2019 at 11:46, Antonio Cuni wrote:
> I have uploaded all the packages for PyPy 7.0.0; the release is not yet
> official and we still need to write the release announcement, but the
> packages are already available here, for various platforms:
It's unclear to me how you m
On 29/12/2018 00:20, andy l wrote:
Carl Friedrich,
Thanks for the warm words and quick response.
I have booked a bed at Backpackers Dusseldorf from the 3rd to the 9th of
February. Please could you add me to the attendee list?
Andrew Lawrence
Done! see you in Feb.
CF
__
Carl Friedrich,
Thanks for the warm words and quick response.
I have booked a bed at Backpackers Dusseldorf from the 3rd to the 9th of
February. Please could you add me to the attendee list?
Andrew Lawrence
On Fri, Dec 28, 2018 at 8:03 PM Carl Friedrich Bolz-Tereick
wrote:
> Hi Andrew,
>
> Ye
Hi Andrew,
Yes, the sprint is totally suitable for beginners! We usually give
introductions and try to pair newcomers with more experienced developers. You'd
be most welcome to join the sprint!
Cheers,
Carl Friedrich
On December 28, 2018 12:51:03 PM GMT+01:00, andy l
wrote:
>Would the wint
Thank you for the suggestion.
Using the —no-native option, both the test script and my original numerical
integration script run under vmprof on pypy.
Kris
On Mon, Nov 19, 2018 at 1:12 PM Ronan Lamy wrote:
> Le 17/11/18 à 15:39, Kris Kuhlman a écrit :
> > I am using pypy to run numerical integ
Le 17/11/18 à 15:39, Kris Kuhlman a écrit :
I am using pypy to run numerical integration calculations with the
arbitrary precision library mpmath (http://mpmath.org).
I am using pypy2-v6.0.0-osx64 and version 1.0 of mpmath (from github). I
install mpmath with pypy and use the native (python on
> On +2018-10-27 11:55:11 -0700, wlavrij...@lbl.gov wrote:
as I'm struggling with Windows at the moment, I may have an answer ...
I find that for CPython3, sys.maxsize is (2**31)-1 on 32-bits Python and
(2**63)-1 for 64-bits Python builds. With sys.maxint being a Python2 thing,
it may be differen
On +2018-10-27 11:55:11 -0700, wlavrij...@lbl.gov wrote:
> Hi,
>
> On Mon, 22 Oct 2018, Barry wrote:
> > > On 21 Oct 2018, at 19:04, Armin Rigo wrote:
> > > On Sun, 21 Oct 2018 at 16:47, Barry Scott wrote:
> > > > How odd. sys.maxint on macOS and Fedora is (2**63)-1 not (2**31)-1.
> > > That's b
Hi,
On Mon, 22 Oct 2018, Barry wrote:
On 21 Oct 2018, at 19:04, Armin Rigo wrote:
On Sun, 21 Oct 2018 at 16:47, Barry Scott wrote:
How odd. sys.maxint on macOS and Fedora is (2**63)-1 not (2**31)-1.
That's because MacOS and Fedora are not Windows.
Do you why windows is unique in this respec
On 10/22/2018 17:13, Barry wrote:
On 21 Oct 2018, at 19:04, Armin Rigo wrote:
Hi,
On Sun, 21 Oct 2018 at 16:47, Barry Scott wrote:
On 19 Oct 2018, at 11:26, Armin Rigo wrote:
PyPy is not available for 64-bit Windows.
How odd. sys.maxint on macOS and Fedora is (2**63)-1 not (2**31)-1.
On 23/10/18 12:13 am, Barry wrote:
On 21 Oct 2018, at 19:04, Armin Rigo wrote:
Hi,
On Sun, 21 Oct 2018 at 16:47, Barry Scott wrote:
On 19 Oct 2018, at 11:26, Armin Rigo wrote:
PyPy is not available for 64-bit Windows.
How odd. sys.maxint on macOS and Fedora is (2**63)-1 not (2**31)-1.
Probably because 32-bit is still supported by Windows, whereas Fedora
discontinued supporting 32 bit in 2016, and OSX stopped supporting 32 bit
recently as well. Easier to have just one version of Windows rather than
supporting two versions, and 32-bit is compatible with all Windows, whereas
64
> On 21 Oct 2018, at 19:04, Armin Rigo wrote:
>
> Hi,
>
> On Sun, 21 Oct 2018 at 16:47, Barry Scott wrote:
>>> On 19 Oct 2018, at 11:26, Armin Rigo wrote:
>>> PyPy is not available for 64-bit Windows.
>>
>> How odd. sys.maxint on macOS and Fedora is (2**63)-1 not (2**31)-1.
>
> That's bec
Hi,
On Sun, 21 Oct 2018 at 16:47, Barry Scott wrote:
> > On 19 Oct 2018, at 11:26, Armin Rigo wrote:
> > PyPy is not available for 64-bit Windows.
>
> How odd. sys.maxint on macOS and Fedora is (2**63)-1 not (2**31)-1.
That's because MacOS and Fedora are not Windows.
Armin
___
> On 19 Oct 2018, at 11:26, Armin Rigo wrote:
>
> Hi,
>
> On Fri, 19 Oct 2018 at 12:23, wrote:
>> It will not run with PyPy https://pypy.org/download.html on Windows, because
>> there are only 32-bit PyPy installs for Windows available
>
> PyPy is not available for 64-bit Windows. See
> ht
Hi,
On Fri, 19 Oct 2018 at 12:23, wrote:
> It will not run with PyPy https://pypy.org/download.html on Windows, because
> there are only 32-bit PyPy installs for Windows available
PyPy is not available for 64-bit Windows. See
http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-ful
On Wed, Jan 31, 2018 at 12:34 PM, Carl Friedrich Bolz-Tereick wrote:
> Hi Anto,
>
> Yes, I ran your benchmarks and they are improved, particularly the ones
> that pass arguments.
>
cool :)
> I need to rerun them now that I merged default. However, I would prefer it
> if we could find a real
Hi Anto,
Yes, I ran your benchmarks and they are improved, particularly the ones that
pass arguments. I need to rerun them now that I merged default. However, I
would prefer it if we could find a real life cpyext benchmark (maybe using
numpy?).
Cheers,
Carl Friedrich
Carl Friedrich
On Janu
Hi Carl,
wow, this looks awesome. Did you run benchmarks to measure the speedup? If
yes, should we add them to my repo?
https://github.com/antocuni/cpyext-benchmarks
ciao,
Anto
On Tue, Jan 30, 2018 at 1:31 PM, cfbolz wrote:
> Author: Carl Friedrich Bolz-Tereick
> Branch: cpyext-faster-arg-pass
On 13/01/18 00:03, Armin Rigo wrote:
Hi Neal,
On 12 January 2018 at 20:35, Neal Becker wrote:
So Fedora has libbz2.so.1 and libbz2.so.1.0.6, but no libbz2.so.1.0. In
fact, isn't depending on libbz2.so.1.0 an error?
Unless I'm mistaken, it's what we get from ``gcc -lbz2`` on Ubuntu.
If you th
Hi Neal,
On 12 January 2018 at 20:35, Neal Becker wrote:
> So Fedora has libbz2.so.1 and libbz2.so.1.0.6, but no libbz2.so.1.0. In
> fact, isn't depending on libbz2.so.1.0 an error?
Unless I'm mistaken, it's what we get from ``gcc -lbz2`` on Ubuntu.
If you think doing so gives a dependency that
Neal Becker wrote:
> Matti Picus wrote:
>
>>
>>
>> On 12/01/18 14:33, Neal Becker wrote:
>>> Haven't tried pypy for some time, but just tried it on fedora 27.
>>> pypy
>>> pypy: error while loading shared libraries: libbz2.so.1.0: cannot open
>>> shared object file: No such file or directory
>>
Matti Picus wrote:
>
>
> On 12/01/18 14:33, Neal Becker wrote:
>> Haven't tried pypy for some time, but just tried it on fedora 27.
>> pypy
>> pypy: error while loading shared libraries: libbz2.so.1.0: cannot open
>> shared object file: No such file or directory
>>
>> I d/l pypy3-v5.10.1-linux64
On 12/01/18 14:33, Neal Becker wrote:
Haven't tried pypy for some time, but just tried it on fedora 27.
pypy
pypy: error while loading shared libraries: libbz2.so.1.0: cannot open
shared object file: No such file or directory
I d/l pypy3-v5.10.1-linux64.tar.bz2 and installed locally.
_
Matti Picus wrote:
> I have uploaded pypy3.5 v5.10.1 bug-fix release candidates to
> https://bitbucket.org/pypy/pypy/downloads please test them out.
>
> The sha256 hashes are available at the end of the source for the website
>
https://bitbucket.org/pypy/pypy.org/src/extradoc/source/download.txt
I enjoyed the Warsaw sprint a lot, especially the food options, but I
guess that the other options would be nice as well.
Shortly after the Leysin sprint isn't optimal, but okay for me.
However, I don't have time around May 1.
On 2018-01-07 10:26, Maciej Fijalkowski wrote:
Hi Everyone.
It
Hi,
On 7 January 2018 at 10:26, Maciej Fijalkowski wrote:
> * we can have a sprint at my climbing spot - it's quite a problem to
> get to (~2-3h by train from either Prague or Wroclaw), but it's
> incredibly lovely at this time of the year. There is a venue and
> internet that we can use. Limited
Hi,
I'd be happy to come. Since I have already been to Warsaw, I vote for
Krakow or Wroclaw.
The only thing is that April is quite busy for me; ATM, the only reasonable
dates are somewhere between 3rd and 13th. May it's surely easier :)
On Sun, Jan 7, 2018 at 10:26 AM, Maciej Fijalkowski
wrote:
On Wed, Jan 3, 2018 at 8:50 PM, Matti Picus wrote:
> On 1/4/2018 3:15 AM, Nathaniel Smith wrote:
>> None of Linux, Windows, or MacOS provide reasonable pre-existing
>> OpenSSL installs you can use. So it seems to me that if PyPy's going
>> to ship any binaries at all and take that seriously, then
Looks like they ship a shared lib on osx which is different from how they
handle 2.7:
mattb@mattb-mbp2:/Library/Frameworks/Python.framework/Versions $ find . -name
'*ssl*.so' | xargs otool -L
./2.7/lib/python2.7/lib-dynload/_ssl.so:
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8
On 1/4/2018 3:15 AM, Nathaniel Smith wrote:
On Wed, Jan 3, 2018 at 3:51 PM, Alex Gaynor wrote:
If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to be
in the business of issuing new releases whenever upstream has a security
release, we can't be shipping people OpenSSLs with
On Wed, Jan 3, 2018 at 3:51 PM, Alex Gaynor wrote:
> If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to be
> in the business of issuing new releases whenever upstream has a security
> release, we can't be shipping people OpenSSLs with known security issues.
>
> Of LibreSSL an
On Wed, Jan 03, 2018 at 07:06:13PM -0500, Alex Gaynor wrote:
>pyca/cryptography issues a new release on all platforms for any OpenSSL
>security releases.
Yeah, but that's part of the library ecosystem -- not really an end product?
m
--
Matt Billenstein
m...@vazor.com
http://www.vazor.co
pyca/cryptography issues a new release on all platforms for any OpenSSL
security releases.
:-),
Alex
On Wed, Jan 3, 2018 at 7:05 PM, Matt Billenstein wrote:
> On Wed, Jan 03, 2018 at 06:51:21PM -0500, Alex Gaynor wrote:
> >If PyPy releases include a copy of OpenSSL (or LibreSSL) then we nee
On Wed, Jan 03, 2018 at 06:51:21PM -0500, Alex Gaynor wrote:
>If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to
>be in the business of issuing new releases whenever upstream has a
>security release, we can't be shipping people OpenSSLs with known security
>iss
If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to be
in the business of issuing new releases whenever upstream has a security
release, we can't be shipping people OpenSSLs with known security issues.
Of LibreSSL and OpenSSL, I'd choose to ship OpenSSL -- I've found LibreSSL
On Jan 3, 2018 02:17, "Matt Billenstein" wrote:
So, I think updating LibreSSL branches every 6-12 months and using the
latest
point release for a new pypy release is probably a good plan.
BTW you should consult your local cryptographic engineer – I guess that's
probably Alex Gaynor? – before de
On Wed, Jan 03, 2018 at 09:08:22AM +0100, Armin Rigo wrote:
> Given that situation my own vote would be to find the easiest solution
> that seems to work (maybe just link to the outdated openssl) and add a
> warning next to the download link on our web page, with a link to the
> homebrew version.
Hi,
On 3 January 2018 at 06:53, Yury V. Zaytsev wrote:
> Basically only bloat (not an argument) and necessity to track OpenSSL
> security updates & release new versions when they come out...
...which I'm sure will not be done, because there is no-one in the
PyPy core group that is both security-
On Wed, 3 Jan 2018, Matti Picus wrote:
Perhaps we should break with CPython here and statically link on macosx.
Is there a downside to statically linking ssl and libffi?
Basically only bloat (not an argument) and necessity to track OpenSSL
security updates & release new versions when they com
On Wed, Jan 03, 2018 at 07:45:07AM +0200, Matti Picus wrote:
> Perhaps we should break with CPython here and statically link on
> macosx. Is there a downside to statically linking ssl and libffi?
Seems like a great solution given you've already sorted this out on pypy3. No
telling what Apple migh
On 03/01/18 02:04, Matt Billenstein wrote:
On Tue, Jan 02, 2018 at 03:25:17PM -0800, Nathaniel Smith wrote:
I'm pretty sure that the right solution is to ship your own copy of
openssl with the build, so that you're totally independent from Apple's
ssl shenanigans. Maybe look at how C
Which version of CPython are you looking at? Here's the patch that switched
the official MacOS builds to always using a private copy of openssl:
https://hg.python.org/cpython/rev/bfd0a73cf907
(Found here: https://bugs.python.org/issue17128)
On Jan 2, 2018 16:04, "Matt Billenstein" wrote:
> On T
I'm pretty sure the LibreSSL that macOS includes is not intended for public
linkage.
If you want to ship binaries on macOS that use OpenSSL, the thing to do is
to ship your own OpenSSL and update whenever OpenSSL performs a security
release.
Alex
On Tue, Jan 2, 2018 at 7:04 PM, Matt Billenstein
On Tue, Jan 02, 2018 at 03:25:17PM -0800, Nathaniel Smith wrote:
>I'm pretty sure that the right solution is to ship your own copy of
>openssl with the build, so that you're totally independent from Apple's
>ssl shenanigans. Maybe look at how CPython handles this.
That does seem more c
I'm pretty sure that the right solution is to ship your own copy of openssl
with the build, so that you're totally independent from Apple's ssl
shenanigans. Maybe look at how CPython handles this.
On Jan 2, 2018 2:28 PM, "Matt Billenstein" wrote:
> Hi all,
>
> So the general issue seems to be Ap
I think supporting just the more recent OS X releases (Sierra, High Sierra) is
fine. I recently had to upgrade my Mac to Sierra because I was running into
packages that wouldn't work on the older version. (There seems to be a
"get_entropy" function in Sierra, and things were failing because it w
On 31/12/2017 10:59 AM, blanch wrote:
hello, thanks for the 5.10 release!
just a problem on the mac: it seems that the pypy3 binaries are linked against
a libffi provided by a package manager (homebrew?), since dyld is looking for
/usr/local/opt/libffi/lib/libffi.6.dylib (see below the error
hello, thanks for the 5.10 release!
just a problem on the mac: it seems that the pypy3 binaries are linked against
a libffi provided by a package manager (homebrew?), since dyld is looking for
/usr/local/opt/libffi/lib/libffi.6.dylib (see below the error reported and
otool output).
since i do n
Hi Matti
The build on downloads for OS X works only on High Sierra (10.13),
since it expects utimesat in libc, which is only available from High
Sierra. I will build a Sierra version on my computer that (hopefully)
works on older OS X too.
Otherwise looks good to go, I will update the website and
ah indeed, that's a much better fix :-)
The original was done a bit haphazardly :-)
On Sun, Nov 19, 2017 at 11:07 PM, Armin Rigo wrote:
> Hi,
>
> On 9 November 2017 at 10:07, Antonio Cuni wrote:
>> I suppose that the explanation that you put in the commit message should
>> also go in a comment
Hi,
On 9 November 2017 at 10:07, Antonio Cuni wrote:
> I suppose that the explanation that you put in the commit message should
> also go in a comment inside the source code, else when someone sees it it's
> just obscure.
Done in d00a16ef468f. I reverted the addition of ShuffleDict, and
instead
Hi,
I suppose that the explanation that you put in the commit message should
also go in a comment inside the source code, else when someone sees it it's
just obscure.
Also, it'd be nice to have some tests about ShuffleDict :)
On Thu, Nov 9, 2017 at 2:55 AM, fijal wrote:
> Author: fijal
> Branch
Same section
nsure that mappingproxy is recognised as a mapping, not a sequence
Should be Ensure.
Also links to issues aren't clickable.
בתאריך יום ב׳, 25 בספט׳ 2017 ב-14:15 מאת Omer Katz <omer.d...@gmail.com
>:
> Typo in
> http://pypy.readthedocs.io/en/latest/release-v5.9.0.html#highli
Typo in
http://pypy.readthedocs.io/en/latest/release-v5.9.0.html#highlights-of-the-pypy3-5-release-since-5-8-beta-released-june-2017
:
mplement PyType_FromSpec (PEP 384) and fix issues with PEP 489 support
Should be implement
בתאריך יום ב׳, 25 בספט׳ 2017 ב-10:20 מאת Gelin Yan <dynami...@gmai
hi matti
there is a minor typo: cython 2.7 ought to be cython 0.27
regards
gelin yan
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
Hi,
On 5 August 2017 at 00:00, Meide Zhao wrote:
> I'm looking for a recent talk on pypy but can't find one in PYCON 2017. It
> seems pypy is not so hot recently.
That's because we're mostly not travelling to the US any more. You
have to look at other conferences like EuroPython.
A bientôt,
Not so active?
https://morepypy.blogspot.com/2017/06/pypy-v58-released.html
https://morepypy.blogspot.com/2017/07/binary-wheels-for-pypy.html?
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone
elsehttp://refi64.com
On Aug 4, 2017 at 5:02 PM, > wrote:
Hi all,
Congrats on the release and thanks a lot everyone for your hard work!
Just noticed that the link for PyPy 3 on http://pypy.org/download.html
gives a 404, and I don't see pypy3 5.8 here
https://bitbucket.org/pypy/pypy/downloads/ either.
2017-06-09 1:25 GMT+03:00 Matti Picus :
> https://morepypy.bl
2017-04-19 7:32 GMT+02:00 Frank Wang :
> Awesome thanks, Victor! For https://bitbucket.org/pypy/benchmarks, is there
> an explanation on what each of these benchmarks are? There doesn't seem to
> be a README.
performance shares many benchmarks, so you can first look at
performance documentation:
h
1 - 100 of 1000 matches
Mail list logo
