headers
Michael Hudson | 2 Mar 2005 21:31
Favicon

Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation annotation/test translator/test

pedronis <at> 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...
(Continue reading)

Permalink | Reply | 3 comments |
headers
Samuele Pedroni | 3 Mar 2005 02:54
Favicon

Re: Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation annotation/test translator/test

Michael Hudson wrote:
> pedronis <at> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Hudson | 3 Mar 2005 17:09
Favicon

Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation annotation/test translator/test

Samuele Pedroni <pedronis <at> 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
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armin Rigo | 4 Mar 2005 13:38
Favicon

Re: Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation annotation/test translator/test

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
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Samuele Pedroni | 10 Mar 2005 00:57
Favicon

summaries on builtin types/modules

Hi.

I have played a bit with generating static html pages summarizing where 
we stand wrt the implementations of builtins.

A first cut can be seen starting here:

http://codespeak.net/~pedronis/deltareports/modules-index.html

the numbers refer to totals, numbers/percent of missing for 
functions/attributes of modules and/or classes/types.

Red/maroon means missing, incomplete.

Faked stuff is considered missing.

There are buttons to switch locally to different sort orders.
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 2 comments |
headers
holger krekel | 11 Mar 2005 09:20
Favicon

Re: summaries on builtin types/modules

Hi Samuele, 

On Thu, Mar 10, 2005 at 00:57 +0100, Samuele Pedroni wrote:
> I have played a bit with generating static html pages summarizing where 
> we stand wrt the implementations of builtins.
> 
> A first cut can be seen starting here:
> 
> http://codespeak.net/~pedronis/deltareports/modules-index.html

nice although i do not fully understand all results yet. 

> the numbers refer to totals, numbers/percent of missing for 
> functions/attributes of modules and/or classes/types.
> 
> Red/maroon means missing, incomplete.
> 
> Faked stuff is considered missing.
> 
> There are buttons to switch locally to different sort orders.

It would be nice to have a small legend on the top of the
pages or so.  

Moreover you should now be able to use the delta-report tool
"pypy/tool/delta.py" directly on codespeak and if you look
into /home/hpk/.svntrigger you'll see how you can automate the
generation of the web pages upon svn-commits by putting an 
".svntrigger" file in your home directory.  I also added a
getpypyrevision() helper to the deltareport tool (which is not
(Continue reading)

Permalink | Reply | 1 comment |
headers
Samuele Pedroni | 11 Mar 2005 19:51
Favicon

Re: summaries on builtin types/modules

holger krekel wrote:

>Hi Samuele, 
>
>On Thu, Mar 10, 2005 at 00:57 +0100, Samuele Pedroni wrote:
>  
>
>>I have played a bit with generating static html pages summarizing where 
>>we stand wrt the implementations of builtins.
>>
>>A first cut can be seen starting here:
>>
>>http://codespeak.net/~pedronis/deltareports/modules-index.html
>>    
>>
>
>nice although i do not fully understand all results yet. 
>
>  
>
>>the numbers refer to totals, numbers/percent of missing for 
>>functions/attributes of modules and/or classes/types.
>>
>>Red/maroon means missing, incomplete.
>>
>>Faked stuff is considered missing.
>>
>>There are buttons to switch locally to different sort orders.
>>    
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
bernstorff_lehmann | 11 Mar 2005 21:07
Picon

Re: summaries on builtin types/modules

just a heads up : For some reason the summaries doesn't work in either Internet Explorer or Opera (windows
2k). In these browsers you only get a blank window when you try :

http://codespeak.net/~pedronis/deltareports/modules-index.html

FireFox is ok though.

I havent tried to understand why yet

Anders Lehmann
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 502 comments |
headers
Samuele Pedroni | 11 Mar 2005 23:24
Favicon

Re: Re: summaries on builtin types/modules

bernstorff_lehmann <at> mail.tele.dk wrote:
> just a heads up : For some reason the summaries doesn't work in either Internet Explorer or Opera (windows
2k). In these browsers you only get a blank window when you try :

having just tried Firefox and Safari, I should have expected some IE 
problems, OTOH I did not expect something this radical.

> 
> http://codespeak.net/~pedronis/deltareports/modules-index.html
> 
> FireFox is ok though.
> 
> I havent tried to understand why yet

at least IE on the Mac was unhappy about <script ... /> vs <script ...> 
</script>. I think it swallowed all the rest of the file as part of the 
script.

I have uploaded a new version, which seem to work with Firexfox, Safari,
and also Mac IE5 (which I admit I did not try the first time around),
js driven local sorting seems also to work with all three after some 
changes.

Samuele
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 502 comments |
headers
Grant Olson | 12 Mar 2005 23:01
Picon

Dynamic compilation via pyrex?

I'm working on a dynamic x86 assembler for python.  Someone on
comp.lang.python mentioned that you guys were dynamically compiling python
code via pyrex.  I was under the impression that this was static
compilation.  Which one of us is right?

I tried digging around your website some, but couldn't find any info.  BTW,
the interpreter is in much better shape than when I last checked it out
(probably 18 months ago ;-) )

-Grant

_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 1 comment |

Gmane