Re: [pypy-dev] project infrastructure issues
On Fri, Apr 15, 2011 at 9:42 PM, holger krekel wrote: > On Thu, Apr 14, 2011 at 21:01 -0400, Alex Gaynor wrote: >> On Thu, Apr 14, 2011 at 1:47 PM, holger krekel wrote: >> >> > Hey all, >> > >> > now that pypy's codespeak subversion usage is basically gone i'd like to >> > push for remaining issues related to the pypy infrastructure: >> > >> > - apache/website >> > - buildbot/master >> > - roundup/issue tracker >> > - mailman/mailing lists pypy-dev/commits/z >> > >> > Which of them shall we try to move elsewhere? >> > >> > My preliminary suggestion: >> > >> > - website -> readthedocs? or other site >> > - buildbot -> python.org? or other site >> > - issue tracker -> bitbucket issue tracker >> > - mailing lists -> google groups or python.org or other site >> > >> > The "other site" could be a host that i anyway >> > need to have for remaining codespeak and merlinux stuff >> > and which thus is somewhat guaranteed to work >> > mail- and otherwise. Other people could get admin >> > access as well, of course. >> > >> > any suggestions or comments? >> > >> > best, >> > holger >> > ___ >> > pypy-dev@codespeak.net >> > http://codespeak.net/mailman/listinfo/pypy-dev >> > >> >> readthedocs seems like the right solution for docs, should just be a matter >> of setting up the post-commit hook and adding a cname for docs.pypy.org > > That would still leave open the question of pypy.org itself i guess. > > besides, "make" in pypy/doc spews out a lot of errors and warnings for me. > Do you know if anybody is caring for completing the transition to sphinx? > > holger I think laura does. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] project infrastructure issues
On Thu, Apr 14, 2011 at 21:01 -0400, Alex Gaynor wrote: > On Thu, Apr 14, 2011 at 1:47 PM, holger krekel wrote: > > > Hey all, > > > > now that pypy's codespeak subversion usage is basically gone i'd like to > > push for remaining issues related to the pypy infrastructure: > > > > - apache/website > > - buildbot/master > > - roundup/issue tracker > > - mailman/mailing lists pypy-dev/commits/z > > > > Which of them shall we try to move elsewhere? > > > > My preliminary suggestion: > > > > - website -> readthedocs? or other site > > - buildbot -> python.org? or other site > > - issue tracker -> bitbucket issue tracker > > - mailing lists -> google groups or python.org or other site > > > > The "other site" could be a host that i anyway > > need to have for remaining codespeak and merlinux stuff > > and which thus is somewhat guaranteed to work > > mail- and otherwise. Other people could get admin > > access as well, of course. > > > > any suggestions or comments? > > > > best, > > holger > > ___ > > pypy-dev@codespeak.net > > http://codespeak.net/mailman/listinfo/pypy-dev > > > > readthedocs seems like the right solution for docs, should just be a matter > of setting up the post-commit hook and adding a cname for docs.pypy.org That would still leave open the question of pypy.org itself i guess. besides, "make" in pypy/doc spews out a lot of errors and warnings for me. Do you know if anybody is caring for completing the transition to sphinx? holger ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] pypy default: fixed test_circular
OK, I also added a check on the guard count. On Fri, Apr 15, 2011 at 11:55 AM, Antonio Cuni wrote: > On 15/04/11 10:50, Hakan Ardo wrote: >> Hi, >> the point here is that we want max(a,b) to be turned into a single >> guard while we dont want max(*range(300)) and max(range(300)) to blow >> up into 300 guards, since that might lead to 2**300 different traces. >> I'm not sure how to best test this... > > can't we just check that the loop contains a residual call to min_max_loop? > -- Håkan Ardö ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] pypy default: fixed test_circular
On 15/04/11 10:50, Hakan Ardo wrote: > Hi, > the point here is that we want max(a,b) to be turned into a single > guard while we dont want max(*range(300)) and max(range(300)) to blow > up into 300 guards, since that might lead to 2**300 different traces. > I'm not sure how to best test this... can't we just check that the loop contains a residual call to min_max_loop? ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] pypy default: fixed test_circular
Hi, the point here is that we want max(a,b) to be turned into a single guard while we dont want max(*range(300)) and max(range(300)) to blow up into 300 guards, since that might lead to 2**300 different traces. I'm not sure how to best test this... On Fri, Apr 15, 2011 at 10:38 AM, Antonio Cuni wrote: >> Right. My point was that since we dont care if they are there or not >> the test should not test that they are there and fail if they are not. >> So if there is an easy way to ignore them in this new test_pypy_c >> framework (which is very cool by the way), we should. If it's not easy >> I'm fine with keeping the test as it is. My main motivation here is to >> learn about the new framework :) > > ah, I understand now. > No, ignoring all force_tokens at once is not possible at the moment, > but I agree that it would be a nice feature, I think I'll implement it > later. > > Btw, I fear I need more of your help with test_silly_max and > test_iter_max (see 2e5bd737be0c): what do we want to check there? > ___ > pypy-dev@codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- Håkan Ardö ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] pypy default: fixed test_circular
On Fri, Apr 15, 2011 at 10:38 AM, Antonio Cuni wrote: >> Right. My point was that since we dont care if they are there or not >> the test should not test that they are there and fail if they are not. >> So if there is an easy way to ignore them in this new test_pypy_c >> framework (which is very cool by the way), we should. If it's not easy >> I'm fine with keeping the test as it is. My main motivation here is to >> learn about the new framework :) > > ah, I understand now. > No, ignoring all force_tokens at once is not possible at the moment, > but I agree that it would be a nice feature, I think I'll implement it > later. > > Btw, I fear I need more of your help with test_silly_max and > test_iter_max (see 2e5bd737be0c): what do we want to check there? > ___ > pypy-dev@codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > Note that force_token operation is really cheap in the backend. It also does not use a whole lot of space. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] pypy default: fixed test_circular
> Right. My point was that since we dont care if they are there or not > the test should not test that they are there and fail if they are not. > So if there is an easy way to ignore them in this new test_pypy_c > framework (which is very cool by the way), we should. If it's not easy > I'm fine with keeping the test as it is. My main motivation here is to > learn about the new framework :) ah, I understand now. No, ignoring all force_tokens at once is not possible at the moment, but I agree that it would be a nice feature, I think I'll implement it later. Btw, I fear I need more of your help with test_silly_max and test_iter_max (see 2e5bd737be0c): what do we want to check there? ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] pypy default: fixed test_circular
Hi Hakan, thanks for the commits > +# We want to check that the array bound checks are removed, > +# so it's this part of the trace. However we dont care about > +# the force_token()'s. Can they be ignored? yes, I think they can be just ignored, because AFAIK operations without side effects and whose result is unused, are removed by the backend regalloc. ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
