(Apologies if - this is not the appropriate venue for this question, but I don't see any other pypy lists, and I'm finding the other docs a bit inscrutable. - I sound too inexperienced or unpythonic: I've spent most of my coding life in java and perl. ) Please advise how to configure pypy to run other python code. Why I ask: I've started running a model implemented in python. Unfortunately a run on "normal" python 2.6.x or 2.7.x requires - 130 min on my ubuntu laptop (on which working would be more convenient) - 55 min on the best build machine to which I currently have access However I have read that this model runs 5x faster under pypy, so I wanna get me that! Unfortunately my current ubuntu me@it:~$ lsb_release -ds
is too down-level to install the available pypy RPM, so I instead did URI="https://bitbucket.org/pypy/pypy/downloads/pypy-1.5-linux64.tar.bz2" TMP_DIR_ROOT="/tmp/pypy" for CMD in \ "rm -fr ${TMP_DIR_ROOT}" \ "mkdir -p ${TMP_DIR_ROOT}" \ "pushd ${TMP_DIR_ROOT}" \ "wget -O - ${URI} | tar xvjf -" \ "ls -alh" \ "popd" \ ; do echo -e "${CMD}" eval "${CMD}" done # check path names, then TMP_DIR_ROOT="/tmp/pypy/pypy-c-jit-43780-b590cf6de419-linux64" TARGET_DIR_ROOT="/opt/pypy-c-jit-1.5.0-alpha0" TARGET_PYPY_EXEC="${TARGET_DIR_ROOT}/bin/pypy" USR_PYPY_EXEC="/usr/local/bin/pypy" for CMD in \ "sudo mkdir -p ${TARGET_DIR_ROOT}" \ "sudo cp -r ${TMP_DIR_ROOT}/* ${TARGET_DIR_ROOT}/" \ "sudo chmod 755 ${TARGET_DIR_ROOT}/" \ "sudo chmod 755 ${TARGET_DIR_ROOT}/bin/" \ "sudo chmod 755 ${TARGET_PYPY_EXEC}" \ "sudo ls -al ${TARGET_PYPY_EXEC}" \ "sudo ln -s ${TARGET_PYPY_EXEC} ${USR_PYPY_EXEC}" \ "sudo ls -al ${USR_PYPY_EXEC}" \ "${USR_PYPY_EXEC} --version" \ "which pypy" \ "pypy --version" \ ; do echo -e "${CMD}" eval "${CMD}" done The good news is, I can now me@it:~$ ls -al $(which pypy)
But when I try to actually *run* the @#$%^&! thing, it spews: me@it:~$ pypy
What do I need to do to fix its library path? Is this where translation is required? (Again, please note that I *have read* http://codespeak.net/pypy/dist/pypy/doc/getting-started-python.html but I'm finding difficulty understanding what one must do to *use* pypy, vs what one must do to *hack* pypy, which is not my usecase.) TIA, Tom Roche <Tom_Roche@pobox.com>
[snip] It's about pypy not finding it's library. I have a bit no idea how those RPMs are built, but usually putting pypy in the same directory tree as it's library (like in checkout) works. I agree we should maybe make some document that makes it more explicit
Tom Roche Sat, 30 Jul 2011 18:17:34 -0400
my current ubuntu
is too down-level to install the available pypy RPM, so I instead [downloaded and installed]
URI="https://bitbucket.org/pypy/pypy/downloads/pypy-1.5-linux64.tar.bz2"
Dan Stromberg Sat, 30 Jul 2011 16:15:08 -0700
Any particular reason not to use the tarball on the pypy website?
That is in fact the "Linux binary (64bit)" from http://pypy.org/download.html#default-with-a-jit-compiler Maciej Fijalkowski Sun, 31 Jul 2011 01:31:47 +0200
I have a bit no idea how those RPMs are built,
Again, please note: I could not use the RPM, so instead used the tarball. Your assistance is appreciated, Tom Roche <Tom_Roche@pobox.com>
Dan Stromberg Sat, 30 Jul 2011 16:15:08 -0700
There might be a silly permission issue
Or more than one. I noticed me@it:~$ pushd ${TARGET_DIR_ROOT} # i.e. where I'm copying pypy to, in /opt me@it:/opt/pypy-c-jit-1.5.0-alpha0$ ls -alh
which seems wrong (even to me :-) So I whacked that install (below) and rebuilt with the following: please note * the chmod's * again, that I'm using the "Linux binary (64bit)" tarball (as previously) URI="https://bitbucket.org/pypy/pypy/downloads/pypy-1.5-linux64.tar.bz2" TMP_DIR_ROOT="/tmp/pypy/pypy-c-jit-43780-b590cf6de419-linux64" TARGET_DIR_ROOT="/opt/pypy-c-jit-1.5.0-alpha0" TARGET_PYPY_EXEC="${TARGET_DIR_ROOT}/bin/pypy" USR_PYPY_EXEC="/usr/local/bin/pypy" for CMD in \ "rm -fr $(dirname ${TMP_DIR_ROOT})" \ "mkdir -p ${TMP_DIR_ROOT}" \ "pushd $(dirname ${TMP_DIR_ROOT})" \ "wget -O - ${URI} | tar xvjf -" \ "ls -alh" \ "popd" \ "sudo rm -fr ${TARGET_DIR_ROOT}" \ "sudo mkdir -p ${TARGET_DIR_ROOT}" \ "sudo cp -r ${TMP_DIR_ROOT}/* ${TARGET_DIR_ROOT}/" \ "sudo chmod a+rx ${TARGET_DIR_ROOT}/" \ "pushd ${TARGET_DIR_ROOT}" \ "find -maxdepth 1 -type f | xargs sudo chmod a+r" \ "find -maxdepth 1 -type d | grep -ve '\.$' | xargs sudo chmod a+rx" \ "sudo chmod a+rx ${TARGET_PYPY_EXEC}" \ "sudo ls -al ${TARGET_PYPY_EXEC}" \ "sudo ln -s ${TARGET_PYPY_EXEC} ${USR_PYPY_EXEC}" \ "which pypy" \ "sudo ls -al ${USR_PYPY_EXEC}" \ "${USR_PYPY_EXEC} --version" \ "sudo ls -al ${TARGET_DIR_ROOT}" \ "pypy --version" \ "pypy" \ "pypy -c 'import sys; print sys.path'" \ "popd" \ ; do echo -e "$ ${CMD}" eval "${CMD}" done The tail of the resulting output is
Those permissions look better than above/before, and
still looks good, but
is still hosed! though at least pypy is now finding its library path:
Which it wasn't before: Tom Roche Sat, 30 Jul 2011 18:17:34 -0400
So I'm wondering, what else needs done in order to make this work? E.g., how to fix the "'import site' failed"? TIA, Tom Roche <Tom_Roche@pobox.com>
I usually: 1) chown it all to root. 2) chmod all the directories and bin/pypy to 755 3) chmod all the regular files except bin/pypy to 644 ...and then I end up with a usable pypy. Or I build it myself - that doesn't give weird permissions problems. After building it, I've been using this script to do the install: #!/bin/bash #where=/usr/local/pypy-trunk-2010-11-20 if [ "$where" = "" ] then echo Need a '$where' to be a prefix path 1>&2 exit 1 fi if [ -d "$where" ] then echo "$where already exists" 1>&2 exit 1 fi # This is for building it: # cd pypy/translator/goal # python translate.py --opt=jit targetpypystandalone.py if [ -f "pypy-c" ] then : else echo "Sorry, I don't see a pypy-c in the CWD" exit 1 fi export where mkdir -p "$where"/bin cp pypy-c "$where"/bin/pypy cd ../../.. mkdir "$where"/include cp include/* "$where"/include/. mkdir "$where"/lib-python (cd lib-python/ && tar cflS - .) | (cd "$where"/lib-python && tar xfp -) mkdir -p "$where"/lib_pypy (cd lib_pypy && tar cflS - .) | (cd "$where"/lib_pypy && tar xfp -) #(cd translator/sandbox && tar cflS - .) | (cd "$where"/lib_pypy && tar xfp -) find "$where" -name .svn -print | xargs rm -rf On Sat, Jul 30, 2011 at 6:58 PM, Tom Roche <Tom_Roche@pobox.com> wrote:
On Sat, Jul 30, 2011 at 7:27 PM, <exarkun@twistedmatrix.com> wrote:
Just unpack the tarball. Don't do all that copying of stuff.
Jean-Paul
I believe it's more than a matter of just unpacking a tar archive. The tar archives have had permissions problems long enough that I suspect there's a bug in the build/release process.
Maciej Fijalkowski Sun, 31 Jul 2011 19:48:26 +0200
Precisely what didn't work?
Ken Watford Sun Jul 31 19:59:55 CEST 2011
The permissions are fine if you're the owner of the files. If another user (say, root) untars them,
e.g., to install FHS-ly
other users may not have appropriate read/execute permissions.
FWIW, Tom Roche <Tom_Roche@pobox.com>
Maciej Fijalkowski Sun, 31 Jul 2011 19:48:26 +0200
Precisely what didn't work?
Ken Watford Sun Jul 31 19:59:55 CEST 2011
The permissions are fine if you're the owner of the files. If another user (say, root) untars them,
Tom Roche Sun, 31 Jul 2011 15:03:34 -0400
e.g., to install FHS-ly
other users may not have appropriate read/execute permissions.
Maciej Fijalkowski Sun, 31 Jul 2011 21:07:17 +0200
as far as I understood, the tarballs are for [extracting] in-place not for installs without serious massaging
Not so much massage is required (e.g., my bash script from http://mail.python.org/pipermail/pypy-dev/2011-July/007893.html does it, as does Dan Stromberg's @ http://mail.python.org/pipermail/pypy-dev/2011-July/007894.html ) but It Would Be Nice for new adopters if the download page documented things like this, esp if intentional. Currently it says only http://pypy.org/download.html#installing
Installing
FWIW, Tom Roche <Tom_Roche@pobox.com>
Maciej Fijalkowski Sun, 31 Jul 2011 21:07:17 +0200
as far as I understood, the tarballs are for [extracting] in-place not for installs without serious massaging
Tom Roche Sun, 31 Jul 2011 15:44:55 -0400
Not so much massage is required (e.g., my bash script from
http://mail.python.org/pipermail/pypy-dev/2011-July/007893.html
does it, as does Dan Stromberg's @
http://mail.python.org/pipermail/pypy-dev/2011-July/007894.html
) but It Would Be Nice for new adopters if the download page documented things like this, esp if intentional.
Maciej Fijalkowski Sun, 31 Jul 2011 21:47:16 +0200
Cool, feel like providing a patch?
To the build or the doc? Regarding the latter, have youse thought about a wiki, or other vehicle for user-contributed doc? Minimally, you could point to http://wiki.python.org/moin/PyPy and have folks work there. Currently it says http://wiki.python.org/moin/PyPy
Please refer to the PyPy home page and development site
(which appear to be the same page)
for more information about this Python implementation.
which (IMHO, YMMV) kinda discourages putting more information on that wiki. FWIW, Tom Roche <Tom_Roche@pobox.com>
Maciej Fijalkowski Sun, 31 Jul 2011 21:07:17 +0200
as far as I understood, the tarballs are for [extracting] in-place not for installs without serious massaging
Tom Roche Sun, 31 Jul 2011 15:44:55 -0400
Not so much massage is required (e.g., my bash script from
http://mail.python.org/pipermail/pypy-dev/2011-July/007893.html
does it, as does Dan Stromberg's @
http://mail.python.org/pipermail/pypy-dev/2011-July/007894.html
) but It Would Be Nice for new adopters if the download page documented things like this, esp if intentional.
Maciej Fijalkowski Sun, 31 Jul 2011 21:47:16 +0200
Cool, feel like providing a patch?
To the build or the doc? Regarding the latter, have youse thought about a wiki, or other vehicle for user-contributed doc? Minimally, you could point to http://wiki.python.org/moin/PyPy and have folks work there. Currently it says http://wiki.python.org/moin/PyPy
Please refer to the PyPy home page and development site
(which appear to be the same page)
for more information about this Python implementation.
which (IMHO, YMMV) kinda discourages putting more information on that wiki. FWIW, Tom Roche <Tom_Roche@pobox.com>
Since I haven't seen it mentioned yet. The issue with permissions is supposed to already be fixed in trunk - https://bugs.pypy.org/issue772 so the next release should resolve that problem for system wide installs. Janzert
Janzert Sun, 31 Jul 2011 16:18:32 -0400
The issue with permissions is supposed to already be fixed in trunk
Great!
so the next release should resolve that problem for system wide installs.
By "next release," do you mean 1.6? (BTW, to show bona fides, and since it needed done, I updated http://wiki.python.org/moin/PyPy to include 1.5, recycling material from the blog.) For when is that planned? Tom Roche Sun, 31 Jul 2011 15:44:55 -0400
It Would Be Nice for new adopters if the download page documented [install details], esp if intentional.
Maciej Fijalkowski Sun, 31 Jul 2011 21:47:16 +0200
Cool, feel like providing a patch?
Tom Roche Sun, 31 Jul 2011 16:03:12 -0400
To the build or the doc?
Maciej Fijalkowski Sun, 31 Jul 2011 22:06:36 +0200
To the doc.
have youse thought about a wiki, or other vehicle for user-contributed doc?
We have a [public] wiki on bitbucket (apparently underused)
not to mention underexposed: I had no idea it was there. (pypy.org links to readthedocs, but that's a private wiki? So you have pypy.org, the blog, readthedocs, the bitbucket wiki, ... lot to manage.) But now I see https://bitbucket.org/pypy/pypy/wiki/Home I could put something in there, and you could point to that?
summary: Maciej: please see link to patch for download.html rework (below). David: please see link to page (below) and critique the (very brief) section on installing from a package manager. details: Maciej Fijalkowski Sun, 31 Jul 2011 23:13:17 +0200
I guess [the PyPy wiki situation] is a bit half-hearted.
Personally, I suspect you'd get more contributions from a wiki: HTML feels kinda heavyweight these days. E.g., I had to `tidy` download.html to work with it, then, after reworking the content, spent an astonishing amount of time twiddling div's in download.html to unbreak the "sidepic" buttons. (This may be mostly due to thickheadedness on my part :-)
Ideally we would like a diff from pypy.org download page to what you want to put info there.
OK, the patch.txt is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKZjBkZDZkNjEtZTJhMi00MzlkLThiMjItMGFmNjY3ZmFkOGI2&hl=en_US&authkey=CNCjt7QK and my version of the HTML is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKMjM0ZDNlNTEtZmYwMi00YmYyLTg5NmItMDc5MDlkOWFmODgw&hl=en_US Of course the HTML won't format correctly standalone (notably without the CSS), but the content is readable (which is still what counts :-) HTH, Tom Roche <Tom_Roche@pobox.com>
Hi Tom, On Wed, Aug 3, 2011 at 3:32 AM, Tom Roche <Tom_Roche@pobox.com> wrote:
Personally, I suspect you'd get more contributions from a wiki: HTML feels kinda heavyweight these days.
Did you actually edit the file download.html? Bah, it looks like some communication problem. If you understood "you have to edit the .html file by hand" then fijal was unclear :-( We don't do that. We edit download.rst, which is a ReST file out of which the .html is generated... Armin
Tom Roche Wed, Aug 3, 2011 at 3:32 AM
I suspect you'd get more contributions from a wiki: HTML feels kinda heavyweight these days.
and there are so many fewer gotchas !-( Armin Rigo Wed, Aug 3, 2011 at 8:21 AM
"Unclear"? How 'bout "unduly terse"? Or, "did not mention *anything* about the following:"
We edit download.rst, which is a ReST file out of which the .html is generated...
Maciej Fijalkowski Wed, 3 Aug 2011 09:24:16 +0200
I think it's download.txt
It's pypy.org/source/download.txt about which there is exactly *nothing* (am I missing something?) in pypy.org/ !!! So here's my suggestion: while I get yatiblog (see below--or has that part of the process changed?) and edit pypy.org/source/download.txt , how 'bout youse do 2 things: 1 edit/commit the attached pypy.org/README
DO NOT EDIT any of
pypy.org/*.html
!!! Those files are all generated from
pypy.org/source/*.txt
so edit those. For more details about the process, see
pypy.org/source/README
for the benefit of the next person who tries to help with the doc. Please add whatever a reasonably-skilled person new to your process would need to know--and then, maintain it when your process changes! </sermonette> 2 (unless I'm missing something) fix pypy.org/source/README
You can get necessary software by doing:
pip install yatiblog
(tested with version 1.0) you can do:
yatiblog -o ..
I say "fix" because, minimally, there is no pypy.org/htdocs/ that I can see @ https://bitbucket.org/pypy/pypy.org/src (The only subdirectories are {css, image, js, source}--am I missing something?) Maximally, I don't know what else has changed since pypy.org/source/README was committed: just make it accurate enough. FWIW, Tom Roche <Tom_Roche@pobox.com>
Armin Rigo Wed, Aug 3, 2011 at 8:21 AM
We edit [pypy.org/source/download.txt]
Done! The new'n'improved download.txt file is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKYzQzNzUwYTktNzBjMS00ZmNmLTk3YzItYThhNTdmY2Q3OWM1&hl=en_US and the patch file is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKZmQzZWZkNDYtODE2YS00MjUwLTgxMDYtZDdiYzVmMmE5ODJh&hl=en_US HTH, Tom Roche <Tom_Roche@pobox.com>
On Sat, Aug 6, 2011 at 2:40 PM, Tom Roche <Tom_Roche@pobox.com> wrote:
Hi This diff does look a bit weird - it contains a lot of stuff and some docutils help among other things. What did you try to diff from? Also I'm not completely sure the idea is to put a copy-pasted script to do something there. Maybe a link would be better? Cheers, fijal
Tom Roche Sat, Aug 6, 2011 at 2:40 PM
The new'n'improved download.txt file is @
and the patch file is @
Maciej Fijalkowski Wed, 10 Aug 2011 17:25:42 +0200
This diff does look a bit weird
Read the download.txt. I reorganized it (e.g., to actually explain things :-), and `diff` doesn't handle that well. If you really believe the previous download.txt only needed marginal tweaking, I can't help you.
I'm not completely sure the idea is to put a copy-pasted script to do something there.
Example scripts in doc are far from unknown. But if it bothers you, take it out.
Hi Tom, On 31/07/11 23:05, Tom Roche wrote:
yes, but it's also possible to download the nightly builds right now: http://buildbot.pypy.org/nightly/trunk/ could you please check that the permission issue is actually fixed in the nightly tarballs? ciao, Anto
Janzert Sun, 31 Jul 2011 16:18:32 -0400
Antonio Cuni Mon, 01 Aug 2011 09:59:00 +0200
could you please check that the permission issue is actually fixed in the nightly tarballs?
It is currently: the tail of the output from BUILD_NAME="pypy-c-jit-latest-linux64" BUILD_TAG="pypy-c-jit-46097-54515dec1d20-linux64" URI="http://buildbot.pypy.org/nightly/trunk/${BUILD_NAME}.tar.bz2" TMP_DIR_ROOT="/tmp/pypy/${BUILD_TAG}" TARGET_DIR_ROOT="/opt/${BUILD_NAME}" TARGET_PYPY_EXEC="${TARGET_DIR_ROOT}/bin/pypy" USR_PYPY_EXEC="/usr/local/bin/pypy" # "sudo chmod -R go+rX ${TARGET_DIR_ROOT}/" \ for CMD in \ "rm -fr $(dirname ${TMP_DIR_ROOT})" \ "mkdir -p ${TMP_DIR_ROOT}" \ "pushd $(dirname ${TMP_DIR_ROOT})" \ "wget -O - ${URI} | tar xvjf -" \ "ls -alh" \ "popd" \ "sudo rm -fr ${TARGET_DIR_ROOT}" \ "sudo mkdir -p ${TARGET_DIR_ROOT}" \ "sudo cp -r ${TMP_DIR_ROOT}/* ${TARGET_DIR_ROOT}/" \ "sudo ln -s ${TARGET_PYPY_EXEC} ${USR_PYPY_EXEC}" \ "which pypy" \ "sudo ls -al ${USR_PYPY_EXEC}" \ "${USR_PYPY_EXEC} --version" \ "sudo ls -al ${TARGET_DIR_ROOT}" \ "pypy --version" \ "pypy" \ "popd" \ ; do echo -e "$ ${CMD}" eval "${CMD}" done is
HTH, Tom Roche <Tom_Roche@pobox.com>
[snip] It's about pypy not finding it's library. I have a bit no idea how those RPMs are built, but usually putting pypy in the same directory tree as it's library (like in checkout) works. I agree we should maybe make some document that makes it more explicit
Tom Roche Sat, 30 Jul 2011 18:17:34 -0400
my current ubuntu
is too down-level to install the available pypy RPM, so I instead [downloaded and installed]
URI="https://bitbucket.org/pypy/pypy/downloads/pypy-1.5-linux64.tar.bz2"
Dan Stromberg Sat, 30 Jul 2011 16:15:08 -0700
Any particular reason not to use the tarball on the pypy website?
That is in fact the "Linux binary (64bit)" from http://pypy.org/download.html#default-with-a-jit-compiler Maciej Fijalkowski Sun, 31 Jul 2011 01:31:47 +0200
I have a bit no idea how those RPMs are built,
Again, please note: I could not use the RPM, so instead used the tarball. Your assistance is appreciated, Tom Roche <Tom_Roche@pobox.com>
Dan Stromberg Sat, 30 Jul 2011 16:15:08 -0700
There might be a silly permission issue
Or more than one. I noticed me@it:~$ pushd ${TARGET_DIR_ROOT} # i.e. where I'm copying pypy to, in /opt me@it:/opt/pypy-c-jit-1.5.0-alpha0$ ls -alh
which seems wrong (even to me :-) So I whacked that install (below) and rebuilt with the following: please note * the chmod's * again, that I'm using the "Linux binary (64bit)" tarball (as previously) URI="https://bitbucket.org/pypy/pypy/downloads/pypy-1.5-linux64.tar.bz2" TMP_DIR_ROOT="/tmp/pypy/pypy-c-jit-43780-b590cf6de419-linux64" TARGET_DIR_ROOT="/opt/pypy-c-jit-1.5.0-alpha0" TARGET_PYPY_EXEC="${TARGET_DIR_ROOT}/bin/pypy" USR_PYPY_EXEC="/usr/local/bin/pypy" for CMD in \ "rm -fr $(dirname ${TMP_DIR_ROOT})" \ "mkdir -p ${TMP_DIR_ROOT}" \ "pushd $(dirname ${TMP_DIR_ROOT})" \ "wget -O - ${URI} | tar xvjf -" \ "ls -alh" \ "popd" \ "sudo rm -fr ${TARGET_DIR_ROOT}" \ "sudo mkdir -p ${TARGET_DIR_ROOT}" \ "sudo cp -r ${TMP_DIR_ROOT}/* ${TARGET_DIR_ROOT}/" \ "sudo chmod a+rx ${TARGET_DIR_ROOT}/" \ "pushd ${TARGET_DIR_ROOT}" \ "find -maxdepth 1 -type f | xargs sudo chmod a+r" \ "find -maxdepth 1 -type d | grep -ve '\.$' | xargs sudo chmod a+rx" \ "sudo chmod a+rx ${TARGET_PYPY_EXEC}" \ "sudo ls -al ${TARGET_PYPY_EXEC}" \ "sudo ln -s ${TARGET_PYPY_EXEC} ${USR_PYPY_EXEC}" \ "which pypy" \ "sudo ls -al ${USR_PYPY_EXEC}" \ "${USR_PYPY_EXEC} --version" \ "sudo ls -al ${TARGET_DIR_ROOT}" \ "pypy --version" \ "pypy" \ "pypy -c 'import sys; print sys.path'" \ "popd" \ ; do echo -e "$ ${CMD}" eval "${CMD}" done The tail of the resulting output is
Those permissions look better than above/before, and
still looks good, but
is still hosed! though at least pypy is now finding its library path:
Which it wasn't before: Tom Roche Sat, 30 Jul 2011 18:17:34 -0400
So I'm wondering, what else needs done in order to make this work? E.g., how to fix the "'import site' failed"? TIA, Tom Roche <Tom_Roche@pobox.com>
I usually: 1) chown it all to root. 2) chmod all the directories and bin/pypy to 755 3) chmod all the regular files except bin/pypy to 644 ...and then I end up with a usable pypy. Or I build it myself - that doesn't give weird permissions problems. After building it, I've been using this script to do the install: #!/bin/bash #where=/usr/local/pypy-trunk-2010-11-20 if [ "$where" = "" ] then echo Need a '$where' to be a prefix path 1>&2 exit 1 fi if [ -d "$where" ] then echo "$where already exists" 1>&2 exit 1 fi # This is for building it: # cd pypy/translator/goal # python translate.py --opt=jit targetpypystandalone.py if [ -f "pypy-c" ] then : else echo "Sorry, I don't see a pypy-c in the CWD" exit 1 fi export where mkdir -p "$where"/bin cp pypy-c "$where"/bin/pypy cd ../../.. mkdir "$where"/include cp include/* "$where"/include/. mkdir "$where"/lib-python (cd lib-python/ && tar cflS - .) | (cd "$where"/lib-python && tar xfp -) mkdir -p "$where"/lib_pypy (cd lib_pypy && tar cflS - .) | (cd "$where"/lib_pypy && tar xfp -) #(cd translator/sandbox && tar cflS - .) | (cd "$where"/lib_pypy && tar xfp -) find "$where" -name .svn -print | xargs rm -rf On Sat, Jul 30, 2011 at 6:58 PM, Tom Roche <Tom_Roche@pobox.com> wrote:
On Sat, Jul 30, 2011 at 7:27 PM, <exarkun@twistedmatrix.com> wrote:
Just unpack the tarball. Don't do all that copying of stuff.
Jean-Paul
I believe it's more than a matter of just unpacking a tar archive. The tar archives have had permissions problems long enough that I suspect there's a bug in the build/release process.
Maciej Fijalkowski Sun, 31 Jul 2011 19:48:26 +0200
Precisely what didn't work?
Ken Watford Sun Jul 31 19:59:55 CEST 2011
The permissions are fine if you're the owner of the files. If another user (say, root) untars them,
e.g., to install FHS-ly
other users may not have appropriate read/execute permissions.
FWIW, Tom Roche <Tom_Roche@pobox.com>
Maciej Fijalkowski Sun, 31 Jul 2011 19:48:26 +0200
Precisely what didn't work?
Ken Watford Sun Jul 31 19:59:55 CEST 2011
The permissions are fine if you're the owner of the files. If another user (say, root) untars them,
Tom Roche Sun, 31 Jul 2011 15:03:34 -0400
e.g., to install FHS-ly
other users may not have appropriate read/execute permissions.
Maciej Fijalkowski Sun, 31 Jul 2011 21:07:17 +0200
as far as I understood, the tarballs are for [extracting] in-place not for installs without serious massaging
Not so much massage is required (e.g., my bash script from http://mail.python.org/pipermail/pypy-dev/2011-July/007893.html does it, as does Dan Stromberg's @ http://mail.python.org/pipermail/pypy-dev/2011-July/007894.html ) but It Would Be Nice for new adopters if the download page documented things like this, esp if intentional. Currently it says only http://pypy.org/download.html#installing
Installing
FWIW, Tom Roche <Tom_Roche@pobox.com>
Maciej Fijalkowski Sun, 31 Jul 2011 21:07:17 +0200
as far as I understood, the tarballs are for [extracting] in-place not for installs without serious massaging
Tom Roche Sun, 31 Jul 2011 15:44:55 -0400
Not so much massage is required (e.g., my bash script from
http://mail.python.org/pipermail/pypy-dev/2011-July/007893.html
does it, as does Dan Stromberg's @
http://mail.python.org/pipermail/pypy-dev/2011-July/007894.html
) but It Would Be Nice for new adopters if the download page documented things like this, esp if intentional.
Maciej Fijalkowski Sun, 31 Jul 2011 21:47:16 +0200
Cool, feel like providing a patch?
To the build or the doc? Regarding the latter, have youse thought about a wiki, or other vehicle for user-contributed doc? Minimally, you could point to http://wiki.python.org/moin/PyPy and have folks work there. Currently it says http://wiki.python.org/moin/PyPy
Please refer to the PyPy home page and development site
(which appear to be the same page)
for more information about this Python implementation.
which (IMHO, YMMV) kinda discourages putting more information on that wiki. FWIW, Tom Roche <Tom_Roche@pobox.com>
Maciej Fijalkowski Sun, 31 Jul 2011 21:07:17 +0200
as far as I understood, the tarballs are for [extracting] in-place not for installs without serious massaging
Tom Roche Sun, 31 Jul 2011 15:44:55 -0400
Not so much massage is required (e.g., my bash script from
http://mail.python.org/pipermail/pypy-dev/2011-July/007893.html
does it, as does Dan Stromberg's @
http://mail.python.org/pipermail/pypy-dev/2011-July/007894.html
) but It Would Be Nice for new adopters if the download page documented things like this, esp if intentional.
Maciej Fijalkowski Sun, 31 Jul 2011 21:47:16 +0200
Cool, feel like providing a patch?
To the build or the doc? Regarding the latter, have youse thought about a wiki, or other vehicle for user-contributed doc? Minimally, you could point to http://wiki.python.org/moin/PyPy and have folks work there. Currently it says http://wiki.python.org/moin/PyPy
Please refer to the PyPy home page and development site
(which appear to be the same page)
for more information about this Python implementation.
which (IMHO, YMMV) kinda discourages putting more information on that wiki. FWIW, Tom Roche <Tom_Roche@pobox.com>
Since I haven't seen it mentioned yet. The issue with permissions is supposed to already be fixed in trunk - https://bugs.pypy.org/issue772 so the next release should resolve that problem for system wide installs. Janzert
Janzert Sun, 31 Jul 2011 16:18:32 -0400
The issue with permissions is supposed to already be fixed in trunk
Great!
so the next release should resolve that problem for system wide installs.
By "next release," do you mean 1.6? (BTW, to show bona fides, and since it needed done, I updated http://wiki.python.org/moin/PyPy to include 1.5, recycling material from the blog.) For when is that planned? Tom Roche Sun, 31 Jul 2011 15:44:55 -0400
It Would Be Nice for new adopters if the download page documented [install details], esp if intentional.
Maciej Fijalkowski Sun, 31 Jul 2011 21:47:16 +0200
Cool, feel like providing a patch?
Tom Roche Sun, 31 Jul 2011 16:03:12 -0400
To the build or the doc?
Maciej Fijalkowski Sun, 31 Jul 2011 22:06:36 +0200
To the doc.
have youse thought about a wiki, or other vehicle for user-contributed doc?
We have a [public] wiki on bitbucket (apparently underused)
not to mention underexposed: I had no idea it was there. (pypy.org links to readthedocs, but that's a private wiki? So you have pypy.org, the blog, readthedocs, the bitbucket wiki, ... lot to manage.) But now I see https://bitbucket.org/pypy/pypy/wiki/Home I could put something in there, and you could point to that?
summary: Maciej: please see link to patch for download.html rework (below). David: please see link to page (below) and critique the (very brief) section on installing from a package manager. details: Maciej Fijalkowski Sun, 31 Jul 2011 23:13:17 +0200
I guess [the PyPy wiki situation] is a bit half-hearted.
Personally, I suspect you'd get more contributions from a wiki: HTML feels kinda heavyweight these days. E.g., I had to `tidy` download.html to work with it, then, after reworking the content, spent an astonishing amount of time twiddling div's in download.html to unbreak the "sidepic" buttons. (This may be mostly due to thickheadedness on my part :-)
Ideally we would like a diff from pypy.org download page to what you want to put info there.
OK, the patch.txt is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKZjBkZDZkNjEtZTJhMi00MzlkLThiMjItMGFmNjY3ZmFkOGI2&hl=en_US&authkey=CNCjt7QK and my version of the HTML is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKMjM0ZDNlNTEtZmYwMi00YmYyLTg5NmItMDc5MDlkOWFmODgw&hl=en_US Of course the HTML won't format correctly standalone (notably without the CSS), but the content is readable (which is still what counts :-) HTH, Tom Roche <Tom_Roche@pobox.com>
Hi Tom, On Wed, Aug 3, 2011 at 3:32 AM, Tom Roche <Tom_Roche@pobox.com> wrote:
Personally, I suspect you'd get more contributions from a wiki: HTML feels kinda heavyweight these days.
Did you actually edit the file download.html? Bah, it looks like some communication problem. If you understood "you have to edit the .html file by hand" then fijal was unclear :-( We don't do that. We edit download.rst, which is a ReST file out of which the .html is generated... Armin
Tom Roche Wed, Aug 3, 2011 at 3:32 AM
I suspect you'd get more contributions from a wiki: HTML feels kinda heavyweight these days.
and there are so many fewer gotchas !-( Armin Rigo Wed, Aug 3, 2011 at 8:21 AM
"Unclear"? How 'bout "unduly terse"? Or, "did not mention *anything* about the following:"
We edit download.rst, which is a ReST file out of which the .html is generated...
Maciej Fijalkowski Wed, 3 Aug 2011 09:24:16 +0200
I think it's download.txt
It's pypy.org/source/download.txt about which there is exactly *nothing* (am I missing something?) in pypy.org/ !!! So here's my suggestion: while I get yatiblog (see below--or has that part of the process changed?) and edit pypy.org/source/download.txt , how 'bout youse do 2 things: 1 edit/commit the attached pypy.org/README
DO NOT EDIT any of
pypy.org/*.html
!!! Those files are all generated from
pypy.org/source/*.txt
so edit those. For more details about the process, see
pypy.org/source/README
for the benefit of the next person who tries to help with the doc. Please add whatever a reasonably-skilled person new to your process would need to know--and then, maintain it when your process changes! </sermonette> 2 (unless I'm missing something) fix pypy.org/source/README
You can get necessary software by doing:
pip install yatiblog
(tested with version 1.0) you can do:
yatiblog -o ..
I say "fix" because, minimally, there is no pypy.org/htdocs/ that I can see @ https://bitbucket.org/pypy/pypy.org/src (The only subdirectories are {css, image, js, source}--am I missing something?) Maximally, I don't know what else has changed since pypy.org/source/README was committed: just make it accurate enough. FWIW, Tom Roche <Tom_Roche@pobox.com>
Armin Rigo Wed, Aug 3, 2011 at 8:21 AM
We edit [pypy.org/source/download.txt]
Done! The new'n'improved download.txt file is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKYzQzNzUwYTktNzBjMS00ZmNmLTk3YzItYThhNTdmY2Q3OWM1&hl=en_US and the patch file is @ https://docs.google.com/leaf?id=0BzDAFHgIxRzKZmQzZWZkNDYtODE2YS00MjUwLTgxMDYtZDdiYzVmMmE5ODJh&hl=en_US HTH, Tom Roche <Tom_Roche@pobox.com>
On Sat, Aug 6, 2011 at 2:40 PM, Tom Roche <Tom_Roche@pobox.com> wrote:
Hi This diff does look a bit weird - it contains a lot of stuff and some docutils help among other things. What did you try to diff from? Also I'm not completely sure the idea is to put a copy-pasted script to do something there. Maybe a link would be better? Cheers, fijal
Tom Roche Sat, Aug 6, 2011 at 2:40 PM
The new'n'improved download.txt file is @
and the patch file is @
Maciej Fijalkowski Wed, 10 Aug 2011 17:25:42 +0200
This diff does look a bit weird
Read the download.txt. I reorganized it (e.g., to actually explain things :-), and `diff` doesn't handle that well. If you really believe the previous download.txt only needed marginal tweaking, I can't help you.
I'm not completely sure the idea is to put a copy-pasted script to do something there.
Example scripts in doc are far from unknown. But if it bothers you, take it out.
Hi Tom, On 31/07/11 23:05, Tom Roche wrote:
yes, but it's also possible to download the nightly builds right now: http://buildbot.pypy.org/nightly/trunk/ could you please check that the permission issue is actually fixed in the nightly tarballs? ciao, Anto
Janzert Sun, 31 Jul 2011 16:18:32 -0400
Antonio Cuni Mon, 01 Aug 2011 09:59:00 +0200
could you please check that the permission issue is actually fixed in the nightly tarballs?
It is currently: the tail of the output from BUILD_NAME="pypy-c-jit-latest-linux64" BUILD_TAG="pypy-c-jit-46097-54515dec1d20-linux64" URI="http://buildbot.pypy.org/nightly/trunk/${BUILD_NAME}.tar.bz2" TMP_DIR_ROOT="/tmp/pypy/${BUILD_TAG}" TARGET_DIR_ROOT="/opt/${BUILD_NAME}" TARGET_PYPY_EXEC="${TARGET_DIR_ROOT}/bin/pypy" USR_PYPY_EXEC="/usr/local/bin/pypy" # "sudo chmod -R go+rX ${TARGET_DIR_ROOT}/" \ for CMD in \ "rm -fr $(dirname ${TMP_DIR_ROOT})" \ "mkdir -p ${TMP_DIR_ROOT}" \ "pushd $(dirname ${TMP_DIR_ROOT})" \ "wget -O - ${URI} | tar xvjf -" \ "ls -alh" \ "popd" \ "sudo rm -fr ${TARGET_DIR_ROOT}" \ "sudo mkdir -p ${TARGET_DIR_ROOT}" \ "sudo cp -r ${TMP_DIR_ROOT}/* ${TARGET_DIR_ROOT}/" \ "sudo ln -s ${TARGET_PYPY_EXEC} ${USR_PYPY_EXEC}" \ "which pypy" \ "sudo ls -al ${USR_PYPY_EXEC}" \ "${USR_PYPY_EXEC} --version" \ "sudo ls -al ${TARGET_DIR_ROOT}" \ "pypy --version" \ "pypy" \ "popd" \ ; do echo -e "$ ${CMD}" eval "${CMD}" done is
HTH, Tom Roche <Tom_Roche@pobox.com>
participants (8)
-
Antonio Cuni -
Armin Rigo -
Dan Stromberg -
exarkun＠twistedmatrix.com -
Janzert -
Ken Watford -
Maciej Fijalkowski -
Tom Roche