Mailman 3 February 2011 - pypy-dev

Building pypy on freebsd 64bit
by Shadrin Eugene 18 Nov '11

18 Nov '11

Hi! I tryed to build pypy on the freebsd, 64bit platform, but failed. First of all I downloaded a 32bit-Python to run pypy. And then: [user@server_name ~/pypy-trunk/pypy/translator/goal]$ ~/py32/bin/python translate.py -Ojit [translation:info] Translating target as defined by targetpypystandalone [platform:execute] gcc -m32 -c -O3 -pthread -fomit-frame-pointer /var/tmp/usession-trunk-22/gcctest.c -o /var/tmp/usession-trunk-22/gcctest.o [platform:WARNING] /var/tmp/usession-trunk-22/gcctest.c:28:2: warning: no newline at end of file [platform:execute] gcc -m32 /var/tmp/usession-trunk-22/gcctest.o -L/lib32 -L/usr/lib32 -L`pwd`/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 -pthread -o /var/tmp/usession-trunk-22/gcctest printf("sizeof short=%ld\n", (long)sizeof(short)); printf("sizeof unsigned short=%ld\n", (long)sizeof(unsigned short)); printf("sizeof int=%ld\n", (long)sizeof(int)); printf("sizeof unsigned int=%ld\n", (long)sizeof(unsigned int)); printf("sizeof long=%ld\n", (long)sizeof(long)); printf("sizeof unsigned long=%ld\n", (long)sizeof(unsigned long)); printf("sizeof signed char=%ld\n", (long)sizeof(signed char)); printf("sizeof unsigned char=%ld\n", (long)sizeof(unsigned char)); printf("sizeof long long=%ld\n", (long)sizeof(long long)); printf("sizeof unsigned long long=%ld\n", (long)sizeof(unsigned long long)); printf("sizeof size_t=%ld\n", (long)sizeof(size_t)); printf("sizeof time_t=%ld\n", (long)sizeof(time_t)); printf("sizeof wchar_t=%ld\n", (long)sizeof(wchar_t)); printf("sizeof mode_t=%ld\n", (long)sizeof(mode_t)); printf("sizeof pid_t=%ld\n", (long)sizeof(pid_t)); sizeof short=2 sizeof unsigned short=2 sizeof int=4 sizeof unsigned int=4 sizeof long=8 sizeof unsigned long=8 sizeof signed char=1 sizeof unsigned char=1 sizeof long long=8 sizeof unsigned long long=8 sizeof size_t=8 sizeof time_t=8 sizeof wchar_t=4 sizeof mode_t=2 sizeof pid_t=4 Traceback (most recent call last): File "translate.py", line 300, in <module> main() File "translate.py", line 205, in main targetspec_dic, translateconfig, config, args = parse_options_and_load_target() File "translate.py", line 153, in parse_options_and_load_target targetspec_dic = load_target(targetspec) File "translate.py", line 105, in load_target mod = __import__(specname) File "targetpypystandalone.py", line 5, in <module> from pypy.objspace.std.objspace import StdObjSpace File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/__init__.py", line 1, in <module> from pypy.objspace.std.objspace import StdObjSpace File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/objspace.py", line 3, in <module> from pypy.interpreter import pyframe, function, special File "/place/home/hitrobot/pypy-trunk/pypy/interpreter/pyframe.py", line 13, in <module> from pypy.rlib import jit, rstack File "/place/home/hitrobot/pypy-trunk/pypy/rlib/rstack.py", line 10, in <module> from pypy.rpython.lltypesystem import rffi, lltype File "/place/home/hitrobot/pypy-trunk/pypy/rpython/lltypesystem/rffi.py", line 824, in <module> sys.maxint, sizeof(lltype.Signed))) AssertionError: Mixed configuration of the word size of the machine: the underlying Python was compiled with maxint=2147483647, but the C compiler says that 'long' is 8 bytes I got this error, then I added "-m32" flag to gcc argument list (in the posix.py source file) , but error occured again :( Does anybody tryed to build pypy-c on the 64bit FreeBsd? Thank you for your answer! -- Shadrin Eugene

5 7

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 04 Mar '11

04 Mar '11

Also, can you change every usage of the word 'less' on the axis of the graphs to 'smaller'. As far as I can tell, every time it is an incorrect and ungramatically usage of English. Sometimes the legend is 'seconds - less is better'. But seconds are inherantly countable, so it is incorrect English to say 'there are less seconds' -- rather that there are *fewer* seconds. Or you could change that legend to read 'time in seconds' -- because time is considered uncountable, so you have more or less time, not more or fewer time. Smaller would also work here. Ratios, however, such as on http://speed.pypy.org/comparison/ cannot be 'more or less' or 'more or fewer'. They have to be greater (or larger) or smaller. Thus we need 'smaller' here. Laura

2 1

_scproxy module and tweaks for osx
by Dan Colish 28 Feb '11

28 Feb '11

I've been playing with a few ideas on OSX to get the build to be more stable. Attached is a patch that does this, but it is far from complete. There are still bugs in the way that frameworks are used when the final Makefile is created. In addition, there are problems with libintl that I'd like to be a little more pragmatic about. The _scproxy module itself works with the framework hardcoded fixes. Anyway, I'd appreciate some feedback and also so thoughts on how best to deal with various build environments on OSX. -- Dan

1 0

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 28 Feb '11

28 Feb '11

In a message of Sun, 27 Feb 2011 21:57:33 +0200, Maciej Fijalkowski writes: >Hey. > >Just my 5 cents. > >It would be cool if default view has a down-scaled version of >comparison against CPython. I can look anywhere for recent changes. >Also the recent changes as they're now are not very informative and I >don't use them at all. They stick around, so I don't know if they're >new or old. I'm also as interested in good as in bad changes. Simply >this: http://speed.pypy.org/changes/ is way more informative. > >Can we either just remove the red recent changes for now or simply put >a vs cpython, scaled down graph there? > >At least for pycon this seems like a better way to go. > >Cheers, >fijal > >PS. Miquel, don't get me wrong, I think you're doing an awesome job, >the speed website itself was a huge step forward for us. This sounds good to me as well, and I too don't want Miquel to think that I am ungrateful for all his hard work. The site is really good for us, and thank you. Laura

3 3

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 27 Feb '11

27 Feb '11

In a message of Sun, 27 Feb 2011 19:36:52 +0100, Miquel Torres writes: >Hi Laura, > >you bring up good points, however, it is not as straight forward as it se >em= >Well, it really is a list of the latest results. The problem is that >speed.pypy.org is foremost a tool to help in development. As such, the >logic behind the "latest results" list is regression oriented, or let >us say pessimistic. > >For example, this revision: >http://speed.pypy.org/changes/?rev=3D42312:392bbf936179 > >The average change is actually -0.91%, which is actually an >improvement, though not an statistical significant one. However, There >was a sizeable regression in spitfire_cstringio, +5.21. The "summary" >for that revision is then "regression for an individual benchmark". >Which is actually what developers need to know: they should check >whether that revision really introduced a real regression in >performance. I understand this. I just don't think that this should be on our front page. Developers can get used to looking anywhere, and indeed I never use the front page for looking at anything important -- I am always looking at the complete stats for any runs. I think that speed.pypy.org -- the front page -- should primarily be of use to people who want to find out if pypy is good for them, people who want to convince their bosses that they should switch, and people who just want to cheer us on and add to the general warm feeling about pypy. I see it as the prime tool in the world domination project. >That said, I do understand where you are coming from. I would point >outsiders though directly to http://speed.pypy.org/comparison/ This is the wrong way to do things from a usability point of view. What the casual person wants is not a way to dig down and get information, but something already packaged for them which already tells them the main story. Then they can dig down if they actually care. This is what Steve Krug calls the 'Don't Make Me Think' principle. >So what can some body think about what could be changed or added so >that the main page doesn't give a negative impression to the >non-developer? > >Something I could think of is to add, above the results list, a plot >showing the overall trend over the last 2 or 3 months. What do you >think? I think this would be a very nice thing to have as the home page for speed.pypy.org Then the page that we have now could be called something like http://speed.pypy.org/regressions or something. >> The other thing I want is for the graphs you get, for instance with >> http://speed.pypy.org/changes/?rev=3D42312:392bbf936179&exe=3D%203&env= >3D= >tannit >> to have, in addition to the selection button beside: 'result for revisi >on= >' >> an actual label that says 'build 42312:392b' or something that you >> can select with your mouse and use to paste into things like this mail >> article. > >I think to the right of the changes table there is a box with info for >the revision, with a text field you can select and copy. Isn't that >what you want? Looking at http://speed.pypy.org/changes/?rev=42312:392bbf936179&exe=%203&env=tannit There is nothing to the right of the table. To the right of the label that says: Results for revision is a box that you can use to select different builds to look at. The text in this box is not selectable; you cannot paste it anywhere. To the right of that is a link that says 'Permalink'. As far as I can tell clicking it causes the page to refresh and nothing more. This is with iceweasel 3.5.16 (which is debian's repackage of firefox 3.5.16) Laura

4 3

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 27 Feb '11

27 Feb '11

In a message of Sun, 27 Feb 2011 20:22:57 +0100, Miquel Torres writes: >Ok, I'll try that then. > >> There is nothing to the right of the table. >What is your screen width? >The Revision info box should be below the table if your width is small. xpdyinfo says dimensions: 1024x768 pixels (270x203 millimeters) Laura

1 0

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 27 Feb '11

27 Feb '11

<Resend. I seem to have typed python-dev(a)codespeak.net last time. sorry Miguel.> I'd like to change what is displayed on the speed.python.org frontpage. Right now, as I look at http://speed.pypy.org/ I see, under a section called 'latest results' a list of all the recent times when we became slower. It's thus a 'recent problems' page -- we have actually improved in recent times in many areas, and nowhere is that shown. As we go off to PyCON, which is March 9-17, I intend to mention how great PyPy is, and that you can see it for yourself at speed.pypy.org. Thus, without lying, I would like it if the first impression of PyPy's speed that people got when looking at the site was 'we're getting faster'. Do you think you could change the front page so that what was displayed was more balanced with respect to good news and bad news? I realise that there is nothing you can do if we make a recent build that slows everything down, but for instance in build 42312:392b (Feb 26) we have improvments which are not shown on the main page. I actually think that the _trend_ is a more useful thing to display on the front page, though that might be because it is so green right now. :-) The other thing I want is for the graphs you get, for instance with http://speed.pypy.org/changes/?rev=42312:392bbf936179&exe=%203&env=tannit to have, in addition to the selection button beside: 'result for revision' an actual label that says 'build 42312:392b' or something that you can select with your mouse and use to paste into things like this mail article. It would also be useful to label the run with something more meaningful than 'tannit' for outsiders -- 64 bit ubuntu linux for instance. Thanks very much, Laura Creighton

2 1

Re: [pypy-dev] implementing the additional repo migrations
by Laura Creighton 27 Feb '11

27 Feb '11

In a message of Sat, 26 Feb 2011 11:54:39 +0200, Maciej Fijalkowski writes: >Isn't the debate mostly about older revisions of binary files, since >the rest is fine? Or you want to keep those as well? (say .doc) I don't care about the old versions of binary files. Laura

4 3

implementing the additional repo migrations
by Ronny Pfannschmidt 26 Feb '11

26 Feb '11

hi, this night i started taking a look at the extra repos that need to be migrated. many of them contain reconstructible, but large pdf files, that i'd like to kill off for saving space. this shouldn't be a problem as long as the svn that many people link to stays available read-only, but it would need a bit of a plan if that goes as well. im currently investigating what parts of extradoc are reconstructible it seems the most costly things are * the split + full variants of the eu report (no tex aviliable) * papers (also no tex available) * api_html.tar.gz * the talks directory the talks directory is the largest size offender as well as the tree that’s the hardest to figure out (in terms of what’s reconstructible and what not). (more details later) The language repo's seem to be mostly fine, except for the prolog one, which contains a few reconstructible pdf's regards Ronny

2 1

Re: [pypy-dev] implementing the additional repo migrations
by Laura Creighton 26 Feb '11

26 Feb '11

In a message of Sat, 26 Feb 2011 09:09:50 +0100, holger krekel writes: >Hi Laura, > >> Why should we ever care about space? > >Small repositories are faster to clone and work with. >I am fine to copy everything related to extradoc, though. I thought we had unlimited repos in bitbucket. If so, then this is an argument for putting the extra documentation in a different repo than the pypy one, not for getting rid of things in extradoc. >> I don't think that much (or maybe any) reconstruction is necessary. >> The things in extradoc really are the tex files, pdfs and what-have-you >> that you would expect from their filename extensions. The problem >> is that codespeak improperly serves them up as binary files. So no >> reconstruction needed. Just serve them properly. > >this has nothing to do with codespeak but which svn:mime-type >files have in the svn repository. If you find a file in the repo >that should have a certain mime-type you can e. g. > > svn ps svn:mime-type application/pdf path/to/file.pdf > >it. > >I am actually not sure how mercurial or bitbucket handles serving such fi >les. Sorry, I knew that, I didn't mean to imply that it was some flaw in codespeak. Though it is very far from clear to me how svn got in the business of giving our files mimetypes, which I think happened secretly, under-the-hood. I don't think any of us explicitly went around typing svn commands to set a mime-type of binary to those files, it just happened silently. And, for me, at any rate, svn was an unexpected culprit -- by this I mean that when I went investigating the problem of 'why is this talk being served up as a binary file' svn was not one of the places I thought to look. The mercurial authors (like me) don't like the concept of binrary files, see http://mercurial.selenic.com/wiki/BinaryFiles , so I guess all we need to find out is does bitbucket itself make assumptions. I wouldn't think so, but then I thought that about svn as well. >But I think we should anyway go for serving talks via http://pypy.org/tal >ks/ >just through apache and avoid giving out links to version control >repositories. We might eventually migrate away from bitbucket >and we would then again have the problem of stale links. I'm not fond of a solution which leaves the extradoc files in two versions, the one in the repo and the one on http://pypy.org/talks , and where you have to keep remembering to change the pypy.org one because you have made a change to the one in the repo. >cheers, >holger I think we may have a more general problem, in that the flexibility of pypy should lead to massive experimentation, not only by ourselves but by third parties. What then should we do with the experiments? I'd like to find a way to keep the interesting ones around without making branching horribly slow. I thought that having many separate repositories would go a long way to getting this, was this also a mistaken assumption? Laura

2 1