Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation annotation/test translator/test
pedronis@codespeak.net writes:
Author: pedronis Date: Wed Mar 2 19:40:07 2005 New Revision: 9590
Modified: pypy/dist/pypy/annotation/classdef.py pypy/dist/pypy/annotation/model.py pypy/dist/pypy/annotation/test/test_model.py pypy/dist/pypy/annotation/unaryop.py pypy/dist/pypy/translator/test/snippet.py pypy/dist/pypy/translator/test/test_annrpython.py Log: don't bump classdef revision number if only a fresher revision in an attribute is involved, notice that we still reflow even in this case.
contains logic modified to let caller distinguish this situation, RevDiff (a false value) is returned if the only reason for a false contains relationship is rev numbers.
without these changes the new test analysing make_eo would recurse infinititely.
At some point, we're *really* going to want to document some of this stuff! I.e. something approaching a proof of correctness and termination for the annotator. I guess having a correct and/or terminating annotator would be a good start... Cheers, mwh -- <AdamV> SamB: PHP's basic control structure is the "database timeout error". -- from Twisted.Quotes
Michael Hudson wrote:
pedronis@codespeak.net writes:
Author: pedronis Date: Wed Mar 2 19:40:07 2005 New Revision: 9590
Modified: pypy/dist/pypy/annotation/classdef.py pypy/dist/pypy/annotation/model.py pypy/dist/pypy/annotation/test/test_model.py pypy/dist/pypy/annotation/unaryop.py pypy/dist/pypy/translator/test/snippet.py pypy/dist/pypy/translator/test/test_annrpython.py Log: don't bump classdef revision number if only a fresher revision in an attribute is involved, notice that we still reflow even in this case.
contains logic modified to let caller distinguish this situation, RevDiff (a false value) is returned if the only reason for a false contains relationship is rev numbers.
without these changes the new test analysing make_eo would recurse infinititely.
At some point, we're *really* going to want to document some of this stuff! I.e. something approaching a proof of correctness and termination for the annotator. I guess having a correct and/or terminating annotator would be a good start...
yes, but this one change is not only obscure but is also not correct in general (I have an example). The check-in comment indeed gives the wrong impression. The real criteria, I think, is whether the class expanded structurally has changed or not, although this one will help narrowing the cases where we really need to care about that.
Samuele Pedroni <pedronis@strakt.com> writes:
Michael Hudson wrote:
At some point, we're *really* going to want to document some of this stuff! I.e. something approaching a proof of correctness and termination for the annotator. I guess having a correct and/or terminating annotator would be a good start...
yes, but this one change is not only obscure but is also not correct in general (I have an example). The check-in comment indeed gives the wrong impression. The real criteria, I think, is whether the class expanded structurally has changed or not, although this one will help narrowing the cases where we really need to care about that.
Well, OK then, let me put it like: being clearer about our assumptions might help us see when they are silly! Cheers, mwh -- ARTHUR: Yes. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard". -- The Hitch-Hikers Guide to the Galaxy, Episode 1
Hi Samuele, On Thu, Mar 03, 2005 at 02:54:49AM +0100, Samuele Pedroni wrote:
yes, but this one change is not only obscure but is also not correct in general (I have an example).
I think that the whole "class revision number" hack is not needed any more. At some point "factories" used to be some strange and complicated notion, but this has been quite simplified. Nowaways, for example, instance creation points are just recorded somewhere associated with the class, and it's easy enough to reflow from there whenever the classdef changes. We should get rid of rev numbers; it would remove all the problems we keep having with it. Instead we can simply record all the 'getattr' operations, i.e. record where each class attribute is read. That's both easy to do now and considerably more efficient (when a specific attribute is generalized it would only reflow from the places that really use it). Armin
participants (3)
-
Armin Rigo -
Michael Hudson -
Samuele Pedroni