From matti.picus at gmail.com Mon Jun 1 01:49:29 2020 From: matti.picus at gmail.com (Matti Picus) Date: Mon, 1 Jun 2020 08:49:29 +0300 Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> <20200531211431.GB240@Zed.localdomain> Message-ID: <1cb9a50e-f0be-a346-c748-a3205ff709fb@gmail.com> On 6/1/20 12:39 AM, Yury V. Zaytsev wrote: > On Sun, 31 May 2020, Matt Billenstein via pypy-dev wrote: > >> I think if you want to ship portable binary packages, they should be >> self-contained - you can't really know what Apple is going to include >> or remove from release to release. >> >> I think this principle holds on the various Linux distros as well - >> you can't know what version of the various dependencies is going to >> be installed. > > Well, the principled approach would be to do something like > > ? https://github.com/squeaky-pl/portable-pypy > > ... only it's a hell a lot of work, and the current package is > "portable enough", so not sure this effort even makes a lot of sense. | | |I think porting the current make_portable to macOS would not be so terrible. Since most of the work has been done for linux64/linux32, it is "just" a matter of adjusting the workflow. I opened https://foss.heptapod.net/pypy/pypy/issues/3240 which only requires devop-level python skills to fix. Help is welcome.| | | |Matti | || From matt at vazor.com Mon Jun 1 18:46:49 2020 From: matt at vazor.com (Matt Billenstein) Date: Mon, 1 Jun 2020 15:46:49 -0700 Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: <1cb9a50e-f0be-a346-c748-a3205ff709fb@gmail.com> References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> <20200531211431.GB240@Zed.localdomain> <1cb9a50e-f0be-a346-c748-a3205ff709fb@gmail.com> Message-ID: <20200601224649.GJ48@Zed.localdomain> On Mon, Jun 01, 2020 at 08:49:29AM +0300, Matti Picus wrote: > I think porting the current make_portable to macOS would not be so > terrible. Since most of the work has been done for linux64/linux32, it is > "just" a matter of adjusting the workflow. I opened > https://foss.heptapod.net/pypy/pypy/issues/3240 which only requires > devop-level python skills to fix. Help is welcome. I've made some progress on this $ otool -L bin/libpypy3-c.dylib bin/libpypy3-c.dylib: @rpath/libpypy3-c.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) @rpath/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0) @rpath/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) @rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) @rpath/libffi.dylib (compatibility version 1.0.0, current version 26.0.0) @rpath/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) $ DYLD_PRINT_LIBRARIES=1 bin/pypy3 -c '1' 2>&1 | egrep 'expat|ffi' dyld: loaded: <1ED53818-578C-3D17-8761-68792CCAD685> /private/tmp/usession-unknown-35/build/mattb/bin/../lib/libexpat.1.dylib dyld: loaded: <2AACAE86-FCF4-3613-89A4-5F822BD92AA9> /private/tmp/usession-unknown-35/build/mattb/bin/../lib/libffi.dylib Trying to commit changes to make_portable.py -- I cloned the pypy repo, but getting stuck at 'hg topic issue3240' -- do I need a newer version of mercurial or something? thx m -- Matt Billenstein matt at vazor.com http://www.vazor.com/ From matti.picus at gmail.com Mon Jun 1 23:46:46 2020 From: matti.picus at gmail.com (Matti Picus) Date: Tue, 2 Jun 2020 06:46:46 +0300 Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: <20200601224649.GJ48@Zed.localdomain> References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> <20200531211431.GB240@Zed.localdomain> <1cb9a50e-f0be-a346-c748-a3205ff709fb@gmail.com> <20200601224649.GJ48@Zed.localdomain> Message-ID: On 6/2/20 1:46 AM, Matt Billenstein wrote: > Trying to commit changes to make_portable.py -- I cloned the pypy repo, but > getting stuck at 'hg topic issue3240' -- do I need a newer version of mercurial > or something? > > thx > > m > You need to install the "topic" extension: https://heptapod.net/pages/quick-start-guide.html If you are still stuck, try posting the result of `hg version -v` Thanks Matti From matti.picus at gmail.com Tue Jun 2 15:48:07 2020 From: matti.picus at gmail.com (Matti Picus) Date: Tue, 2 Jun 2020 22:48:07 +0300 Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: <20200601224649.GJ48@Zed.localdomain> References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> <20200531211431.GB240@Zed.localdomain> <1cb9a50e-f0be-a346-c748-a3205ff709fb@gmail.com> <20200601224649.GJ48@Zed.localdomain> Message-ID: <5b34cf71-7ae9-59bf-06c5-4feb494a55ff@gmail.com> On 6/2/20 1:46 AM, Matt Billenstein wrote: > I've made some progress on this > ... > > thx > > m Just to follow up here: thanks to Matt we have a "portable build" candidate available here http://buildbot.pypy.org/nightly/issue3240 It would be nice if someone who could not use the 7.3.1 release tarball would give this a try and let us know if it works. Still to do: I think we need to include the tc/tkl runtime, maybe in a different PR. Matti From shao.lo at gmail.com Tue Jun 9 15:13:19 2020 From: shao.lo at gmail.com (shao lo) Date: Tue, 9 Jun 2020 14:13:19 -0500 Subject: [pypy-dev] Trouble with first commit Message-ID: i'm having trouble following the steps for my first simple commit (looking at contributing.html). I applied for and was granted access yesterday. I've connected my github account. When i try to do the push i get 'remote: user "heptapod-write" is not authorised to publish changesets' Any help would be much appreciated! ...the steps I followed mkdir local_src cd local_src hg clone https://foss.heptapod.net/pypy/pypy cd pypy # edit pypy/.hg/hgrc # add # username = shaolo1 hg pull && hg up hg branch build_link_fix # ...edit file build.rst hg commit -m "Replaced bad link to getting-started-dev.html with contributing.html." hg push pushing to https://foss.heptapod.net/pypy/pypy searching for changes abort: push creates new remote branches: build_link_fix! (use 'hg push --new-branch' to create new remote branches) hg push --new-branch pushing to https://foss.heptapod.net/pypy/pypy searching for changes http authorization required for https://foss.heptapod.net/pypy/pypy realm: GitLab user: shaolo1 password: remote: adding changesets remote: adding manifests remote: adding file changes remote: user "heptapod-write" is not authorised to publish changesets: a2ceee6a2d79 abort: push failed on remote -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at manueljacob.de Wed Jun 10 05:29:07 2020 From: me at manueljacob.de (Manuel Jacob) Date: Wed, 10 Jun 2020 11:29:07 +0200 Subject: [pypy-dev] Trouble with first commit In-Reply-To: References: Message-ID: <71bb29ba9f4cc9dd006cbf14f5ff5e40@manueljacob.de> Our documentation is not as clear on this aspect as it could be. After having been granted access, by default you can only make "short-lived" branches (with `hg topic foo`) but not "long-lived" branches (`hg branch foo`). It seems like in your case, it?s just a matter of replacing `hg branch build_link_fix` with `hg topic build_link_fix`. You can also change it after the fact: * (Your changeset has hash a2ceee6a2d79.) * First, you can reset the branch: `hg branch default -r a2ceee6a2d79`. Now, your changeset has a new hash. * Then, you can set the topic `hg topic build_link_fix -r `. If you already have multiple changesets, you can pass `-r` multiple times or pass a revset. On 2020-06-09 21:13, shao lo wrote: > i'm having trouble following the steps for my first simple commit > (looking > at contributing.html). I applied for and was granted access yesterday. > I've connected my github account. When i try to do the push i get > 'remote: > user "heptapod-write" is not authorised to publish changesets' > > Any help would be much appreciated! > > ...the steps I followed > > mkdir local_src > cd local_src > hg clone https://foss.heptapod.net/pypy/pypy > cd pypy > # edit pypy/.hg/hgrc > # add > # username = shaolo1 > hg pull && hg up > hg branch build_link_fix > # ...edit file build.rst > hg commit -m "Replaced bad link to getting-started-dev.html with > contributing.html." > hg push > pushing to https://foss.heptapod.net/pypy/pypy > searching for changes > abort: push creates new remote branches: build_link_fix! > (use 'hg push --new-branch' to create new remote branches) > hg push --new-branch > pushing to https://foss.heptapod.net/pypy/pypy > searching for changes > http authorization required for https://foss.heptapod.net/pypy/pypy > realm: GitLab > user: shaolo1 > password: > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: user "heptapod-write" is not authorised to publish changesets: > a2ceee6a2d79 > abort: push failed on remote > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From joao.guazzelli at simbioseventures.com Wed Jun 10 13:29:54 2020 From: joao.guazzelli at simbioseventures.com (=?UTF-8?Q?Jo=C3=A3o_Victor_Guazzelli?=) Date: Wed, 10 Jun 2020 14:29:54 -0300 Subject: [pypy-dev] Dough about prevision on updating pypy to python 3.8 Message-ID: Hello there I'm a brazilian developer in hope to use pypy, or should I say, in need to use pypy. I'm thinking about upgrading my code to python 3.8 but pypy is mandatory. That being said my dough is if pypy is compatible with 3.8 and if it is not if there is a prevision on that. Thank you so much for your attention. -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Sun Jun 14 09:23:58 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Sun, 14 Jun 2020 15:23:58 +0200 Subject: [pypy-dev] Dough about prevision on updating pypy to python 3.8 In-Reply-To: References: Message-ID: Hi, On Wed, 10 Jun 2020 at 19:30, Jo?o Victor Guazzelli via pypy-dev wrote: > I'm a brazilian developer in hope to use pypy, or should I say, in need to use pypy. I'm thinking about upgrading my code to python 3.8 but pypy is mandatory. That being said my dough is if pypy is compatible with 3.8 and if it is not if there is a prevision on that. PyPy supports Python 2.7 or 3.6 at the moment, with 3.7 being in progress. We can't give any time estimate for when 3.8 support might be available. A bient?t, Armin. From armin.rigo at gmail.com Mon Jun 15 12:22:46 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Mon, 15 Jun 2020 18:22:46 +0200 Subject: [pypy-dev] Fwd: pypy | Proposed changes to make pypy3 work when embedded within a virtualenv (!728) In-Reply-To: References: Message-ID: Hi, I'm very reluctant to make changes relating to virtualenv and installation in general, because I have very limited experience with that topic (particularly on Python 3). Ronan or someone else, could you please double check it? Thanks! Armin ---------- Forwarded message --------- From: Armin Rigo Date: Sun, 14 Jun 2020, 10:20 PM Subject: pypy | Proposed changes to make pypy3 work when embedded within a virtualenv (!728) To: Armin Rigo created a merge request: Branches: topic/py3.6/embedded-in-virtualenv to branch/py3.6 Author: Armin Rigo Assignees: This fixes cffi#460 . Unsure it is the correct fix, though, so I'll seek review by making a merge request. ? Reply to this email directly or view it on GitLab . You're receiving this email because of your activity on foss.heptapod.net. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ram at rachum.com Sun Jun 28 15:34:39 2020 From: ram at rachum.com (Ram Rachum) Date: Sun, 28 Jun 2020 22:34:39 +0300 Subject: [pypy-dev] Changing the PyPy download page Message-ID: Hi everyone! The last week, I've been talking with Matti about ways in which PyPy could be friendlier to new users, and what to do about that. One of the examples I raised in which PyPy is, in my opinion, giving newbies a hard time, is the download page. In my opinion it's way too complicated and not geared for people who want to use PyPy but are less knowledgeable, or less interested in putting in time to understand the subtleties of JIT vs no-JIT vs STM, etc. We discussed that maybe I should make that change and open a PR for it. I said I'm willing to do that, (and learn some Mercurial and Nikita on the way) if I know there's general support in this list to that direction of change; I expect a code review, but I want to know before I start that this change is wanted. Here are a few of the changes I'd like to make: 1. Push the list of binaries to the top. 2. Put Python 3 above Python 2. 3. Move the instructions for building to a separate page. The intersection of the set "people who are interested in build instructions" with the set "people who have a hard time pressing an additional link to get to the build instruction" is very small indeed. 4. I might also put icons of Windows, Mac and Linux near their respective binaries. 5. Ideally I would have auto-detection that gives you the binary to your OS, but I'm not sure I want to work that hard. You get the general idea: Treating PyPy more like a finished product and less like a C library. What do you think? Thanks, Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Mon Jun 29 01:45:52 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Mon, 29 Jun 2020 07:45:52 +0200 Subject: [pypy-dev] Changing the PyPy download page In-Reply-To: References: Message-ID: Hi Ram, On Sun, 28 Jun 2020 at 21:35, Ram Rachum wrote: > We discussed that maybe I should make that change and open a PR for it. I'm +1 on the idea. Armin From cfbolz at gmx.de Mon Jun 29 04:27:45 2020 From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick) Date: Mon, 29 Jun 2020 10:27:45 +0200 Subject: [pypy-dev] Changing the PyPy download page In-Reply-To: References: Message-ID: On 29.06.20 07:45, Armin Rigo wrote: > Hi Ram, > > On Sun, 28 Jun 2020 at 21:35, Ram Rachum wrote: >> We discussed that maybe I should make that change and open a PR for it. > > I'm +1 on the idea. Sounds good to me as well! Thanks for putting though into this! CF From dje.gcc at gmail.com Mon Jun 29 09:00:27 2020 From: dje.gcc at gmail.com (David Edelsohn) Date: Mon, 29 Jun 2020 09:00:27 -0400 Subject: [pypy-dev] Changing the PyPy download page In-Reply-To: References: Message-ID: On Sun, Jun 28, 2020 at 3:36 PM Ram Rachum wrote: > > Hi everyone! > > The last week, I've been talking with Matti about ways in which PyPy could be friendlier to new users, and what to do about that. One of the examples I raised in which PyPy is, in my opinion, giving newbies a hard time, is the download page. > > In my opinion it's way too complicated and not geared for people who want to use PyPy but are less knowledgeable, or less interested in putting in time to understand the subtleties of JIT vs no-JIT vs STM, etc. > > We discussed that maybe I should make that change and open a PR for it. I said I'm willing to do that, (and learn some Mercurial and Nikita on the way) if I know there's general support in this list to that direction of change; I expect a code review, but I want to know before I start that this change is wanted. > > Here are a few of the changes I'd like to make: > > Push the list of binaries to the top. > Put Python 3 above Python 2. > Move the instructions for building to a separate page. The intersection of the set "people who are interested in build instructions" with the set "people who have a hard time pressing an additional link to get to the build instruction" is very small indeed. > I might also put icons of Windows, Mac and Linux near their respective binaries. > Ideally I would have auto-detection that gives you the binary to your OS, but I'm not sure I want to work that hard. > > You get the general idea: Treating PyPy more like a finished product and less like a C library. > > What do you think? +1 - David From ram at rachum.com Mon Jun 29 09:01:36 2020 From: ram at rachum.com (Ram Rachum) Date: Mon, 29 Jun 2020 16:01:36 +0300 Subject: [pypy-dev] Changing the PyPy download page In-Reply-To: References: Message-ID: Awesome. Thanks for the support guys. I've put this on my todo list. On Mon, Jun 29, 2020 at 4:00 PM David Edelsohn wrote: > On Sun, Jun 28, 2020 at 3:36 PM Ram Rachum wrote: > > > > Hi everyone! > > > > The last week, I've been talking with Matti about ways in which PyPy > could be friendlier to new users, and what to do about that. One of the > examples I raised in which PyPy is, in my opinion, giving newbies a hard > time, is the download page. > > > > In my opinion it's way too complicated and not geared for people who > want to use PyPy but are less knowledgeable, or less interested in putting > in time to understand the subtleties of JIT vs no-JIT vs STM, etc. > > > > We discussed that maybe I should make that change and open a PR for it. > I said I'm willing to do that, (and learn some Mercurial and Nikita on the > way) if I know there's general support in this list to that direction of > change; I expect a code review, but I want to know before I start that this > change is wanted. > > > > Here are a few of the changes I'd like to make: > > > > Push the list of binaries to the top. > > Put Python 3 above Python 2. > > Move the instructions for building to a separate page. The intersection > of the set "people who are interested in build instructions" with the set > "people who have a hard time pressing an additional link to get to the > build instruction" is very small indeed. > > I might also put icons of Windows, Mac and Linux near their respective > binaries. > > Ideally I would have auto-detection that gives you the binary to your > OS, but I'm not sure I want to work that hard. > > > > You get the general idea: Treating PyPy more like a finished product and > less like a C library. > > > > What do you think? > > +1 > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Mon Jun 29 10:04:52 2020 From: matti.picus at gmail.com (Matti Picus) Date: Mon, 29 Jun 2020 17:04:52 +0300 Subject: [pypy-dev] the end of bitbucket, heptapod, and permissions Message-ID: <677406f1-3f76-9722-4a0c-7258e3fbe6e9@gmail.com> An HTML attachment was scrubbed... URL: From georges.racinet at octobus.net Mon Jun 29 11:24:06 2020 From: georges.racinet at octobus.net (Georges Racinet) Date: Mon, 29 Jun 2020 17:24:06 +0200 Subject: [pypy-dev] the end of bitbucket, heptapod, and permissions In-Reply-To: <677406f1-3f76-9722-4a0c-7258e3fbe6e9@gmail.com> References: <677406f1-3f76-9722-4a0c-7258e3fbe6e9@gmail.com> Message-ID: Hi, On 6/29/20 4:04 PM, Matti Picus wrote: > > The foss.heptapod.net team is working hard to convert bitbucket > mercurial repos. This is good time to remind everyone to check that > you have not left code on bitbucket: the deadline for removal of > mercurial support there is the end of June. > > > The pypy/pypy and pypy/pypy.org repos will now allow anyone with > "developer" status and above (so basically anyone who asks) to commit > long-lived branches. Previously "developers" were restricted to only > use topic branches, which are a new experimental mercurial feature. > The ability to push long-lived branches is? similar to the way > bitbucket worked. > For completeness I should add that Heptapod is publishing out of topics, meaning that changesets that don't have topics are automatically published once pushed to the server. The most traditional Mercurial setting is to automatically publish all drafts upon pushes. I know that Bitbucket could be set to be fully non-publishing on a per-repository basis. I don't what the setting was for PyPy on Bitbucket, so that may actually be a difference. Best, -- Georges Racinet https://octobus.net, https://about.heptapod.host, https://heptapod.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: