Mailman 3 September 2005 - pypy-dev

Re: [pypy-dev] How agile is PyPy?
by Laura Creighton Sept. 28, 2005

Sept. 28, 2005

In a message of Wed, 28 Sep 2005 18:46:52 +0200, Beatrice During writes: >--8323328-735653061-1127926012=:6433 >Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed >Content-Transfer-Encoding: 8BIT > >Hi there > >On Wed, 28 Sep 2005, Laura Creighton wrote: <snip> >> So if you aren't throwing out a lot of code, then you aren't being >> very agile. I'd say we're excellent on that score. > >So the infrastructure for being able to do that (our … [View More]entire test suite) is >a key component for "throwing away"? How does our automated test suites >fare in comparison with other OSS/agile projects? >(Relax Holger ;-) I think that py.test makes doing test driven development easier and faster. The quality of your test suites depends on the amount of time that developers are willing to put into making tests. I think that the 'NO API' approach makes writing py.tests a lot easier and faster than other testing frameworks that do have an api. Easier and Faster to Write == More Tests == Better Test Suite. And a good test suite is essential .... but I would not think that it is more essential for agile development than for fossilised development. But then I am such a fan of test driven development, that I cannot imagine going any other way, even in a non-agile project. I suspect that TDD is necessary but not sufficient for agile development. It used to be that the state of the test suites in all software projects could be assumed to be abysmal. This is changing. But there is still a lot we do not test. We test the things that interest us, but don't have a way to test the things we never think of. This is a universal failing of all test suites, and I believe that ours is no worse than others, but it still is a flaw. <snip> >I agree - so to summarize - within the community and the boundary of the >PyPy project we are really fullfilling agile thoughts and values - but the >EU boundaries of the projects is "dampening" our "Ability to continuously > >learn" and "Responsibly responding to change" - more? Ah, I think we are continuously learning no matter what. It is more of a problem of not being able to immediately act on what we have learned. And the problem of having to solve the problem in the order we told the EU we would, for the purpose of getting the deliverables done on time, rather than what would be convenient for us. When a new person shows up in the project, they want to immediately work on the thing that gives them the best benefit. The notion of 'well, we could do this now but we aren't supposed to do things like that until next March, according to the schedule' isn't very agile at all. Laura >Thanks for your thoughts on this Laura! My pleasure. > >Cheers > >Bea > > >> Laura >> >> In a message of Tue, 27 Sep 2005 22:20:52 +0200, Beatrice During writes >: >>> --8323328-2105496072-1127852452=:25960 >>> Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed >>> Content-Transfer-Encoding: 8BIT >>> >>> Hi there >>> >>> I am working on documenting PyPy (the project) as a showcase of agile >>> development. In order to be able to do this I would love to get some >>> thoughts and reflections from you who are working on /following PyPy a >nd >>> the question is of course - how agile are we? >>> >>> Here is some short notes on success factors of agile approaches (from >an >>> eworkshop in 2002 - Cockburn, Beck etc, >>> http://fc-md.umd.edu/projects/Agile/Summary/SummaryPF.htm): >>> >>> ---------------------------------------------------------------------- >--- >>> In general, the group agreed that the following are the success factor >s >>> for agile development: >>> >>> § Negotiation: If people are willing to keep talking and learni >ng, >>> you are, almost by definition, agile. >>> >>> § Ability to continuously learn >>> >>> § Responsibly responding to change. >>> >>> § Environment where rapid communication is enabled. >>> >>> § Team reasonably in charge of its own destiny (being allowed t >o >>> succeed). >>> >>> § People are valued over other factors >>> >>> § The team needs to be more than just able, it needs to actuall >y >>> succeed. There needs to be a support network for each >>> individual in the >>> team to make a contribution however small. >>> ---------------------------------------------------------------------- >-- >>> >>> How does these factors apply to PyPy and this community? Are we doing >>> other things that is not mentioned here that is working well for us? T >hin >>> gs we could do better? >>> >>> Your responses will be part of documentation about PyPy/agile dev >>> (sprints) that will be distributed to the EU, Universities, various >>> companies and other Open Source projects who have stated a clear inter >est >>> >>> in the PyPy showcase..... >>> >>> If you feel that answering this email doesnt really fit the purpose of >>> this mailinglist - please answer to me specifically. >>> >>> Thank you for your contribution! >>> >>> Cheers >>> Bea >>> >>> >>> Beatrice Düring Change Maker >>> Tel: 031- 7750940 Järntorget 3 >>> Mobil: 0734- 22 89 06 413 04 Göteborg >>> E-post: bea(a)changemaker.nu www.changemaker.nu >>> >>> "Alla dessa måsten och alldaglighet. >>> Allt detta som binder vår verklighet >>> i bojor av skam och rep utav tvång. >>> Alla dessa kedjor som binder vår sång. >>> Jag skall slita dem alla i små, små stycken >>> och möjligtvis av resterna göra mig smycken." >>> - hemlig >>> >>> --8323328-2105496072-1127852452=:25960 >>> Content-Type: text/plain; charset="us-ascii" >>> MIME-Version: 1.0 >>> Content-Transfer-Encoding: 7bit >>> Content-Disposition: inline >>> >>> _______________________________________________ >>> pypy-dev(a)codespeak.net >>> http://codespeak.net/mailman/listinfo/pypy-dev >>> --8323328-2105496072-1127852452=:25960-- >> > >Beatrice Düring Change Maker >Tel: 031- 7750940 Järntorget 3 >Mobil: 0734- 22 89 06 413 04 Göteborg >E-post: bea(a)changemaker.nu www.changemaker.nu > > "Alla dessa måsten och alldaglighet. > Allt detta som binder vår verklighet > i bojor av skam och rep utav tvång. > Alla dessa kedjor som binder vår sång. > Jag skall slita dem alla i små, små stycken > och möjligtvis av resterna göra mig smycken." > - hemlig > >--8323328-735653061-1127926012=:6433-- [View Less]

1 0

Re: [pypy-dev] How agile is PyPy?
by Laura Creighton Sept. 28, 2005

Sept. 28, 2005

One thing that is rareley mentioned but rather important for agile development is the measurement of how often you _get it wrong_. (Or at least, throw it out.) This is because the results run counter to traditional metrics of software development. Agility means the ability to get it wrong. So -- within limits -- more wrong is better. In traditional, completely non-agile, development, there is only time to build one implementation. You must get it correct the first time. Therefore you … [View More]spend forever sitting down and planning 'the correct way to do something'. And then you do it. Of course, fairly soon it becomes obvious that the very best plan you could come up with overlooked certain very important things. And this is just too bad, because you don't have time to do things except the one way, so you have to make as few changes to the master plan as possible ... and so it goes. Eventually, over time, the software can no longer stand the new demands that are put on it, and it is time to rewrite from scratch. You just cannot patch it up any more. In agile development you rewrite a lot of small things a lot. Instead of discussing what is the best way to implement feature Q, you can just go off and _build_ 3 ways to implement feature Q, and then look at them and measure them, if it is appropriate, and see what is better. But because you have the ability to persue different ways of doing things, you end up throwing out a lot of code. You also need language support for this -- you can talk all you like about agile development, but some languages are so hard to write code in that you really will not have time to try 3 or 5 or 7 implementations of an idea. Plus having sweated bricks to make one, you are in love with your own code, and find it hard to toss it when the opportunity arises. So if you aren't throwing out a lot of code, then you aren't being very agile. I'd say we're excellent on that score. Also -- while traditional agile methodolgies talk about _responding_ to change -- generally from the customer -- we don't have any. So we make change just because we think it would be a good -- or interesting thing to do. We're not responding to outside pressures. Indeed, we would like it if the EU was a bit more flexible, and we could make some changes to our proposal on the basis of what we have learned by doing. But the EU is not very agile, and poor at responding to changes desired by funded project consortia. Laura In a message of Tue, 27 Sep 2005 22:20:52 +0200, Beatrice During writes: >--8323328-2105496072-1127852452=:25960 >Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed >Content-Transfer-Encoding: 8BIT > >Hi there > >I am working on documenting PyPy (the project) as a showcase of agile >development. In order to be able to do this I would love to get some >thoughts and reflections from you who are working on /following PyPy and >the question is of course - how agile are we? > >Here is some short notes on success factors of agile approaches (from an >eworkshop in 2002 - Cockburn, Beck etc, >http://fc-md.umd.edu/projects/Agile/Summary/SummaryPF.htm): > >------------------------------------------------------------------------- >In general, the group agreed that the following are the success factors >for agile development: > >§ Negotiation: If people are willing to keep talking and learning, > you are, almost by definition, agile. > >§ Ability to continuously learn > >§ Responsibly responding to change. > >§ Environment where rapid communication is enabled. > >§ Team reasonably in charge of its own destiny (being allowed to > succeed). > >§ People are valued over other factors > >§ The team needs to be more than just able, it needs to actually > succeed. There needs to be a support network for each > individual in the > team to make a contribution however small. >------------------------------------------------------------------------ > >How does these factors apply to PyPy and this community? Are we doing >other things that is not mentioned here that is working well for us? Thin >gs we could do better? > >Your responses will be part of documentation about PyPy/agile dev >(sprints) that will be distributed to the EU, Universities, various >companies and other Open Source projects who have stated a clear interest > >in the PyPy showcase..... > >If you feel that answering this email doesnt really fit the purpose of >this mailinglist - please answer to me specifically. > >Thank you for your contribution! > >Cheers >Bea > > >Beatrice Düring Change Maker >Tel: 031- 7750940 Järntorget 3 >Mobil: 0734- 22 89 06 413 04 Göteborg >E-post: bea(a)changemaker.nu www.changemaker.nu > > "Alla dessa måsten och alldaglighet. > Allt detta som binder vår verklighet > i bojor av skam och rep utav tvång. > Alla dessa kedjor som binder vår sång. > Jag skall slita dem alla i små, små stycken > och möjligtvis av resterna göra mig smycken." > - hemlig > >--8323328-2105496072-1127852452=:25960 >Content-Type: text/plain; charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >_______________________________________________ >pypy-dev(a)codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev >--8323328-2105496072-1127852452=:25960-- [View Less]

2 1

Next #pypy-sync meeting thursday 13.00 CET
by Anders Lehmann Sept. 28, 2005

Sept. 28, 2005

Til: pypy-dev(a)codespeak.net Hi all, Next #pypy-sync meeting on freenode.net is tomorrow Thursday at 1pm CET as usual. Regular topics -------------- * activity reports (3 prepared lines of info) * resolve conflicts/blockers Here is my draft proposal of Topics of the week ------------------ Pre christmas sprint Do we have a venue ? Compliance Just so we dont forget in our speed effort. There are still several missing pieces (pep 302, ...) Marketing As a … [View More]

1 0

Patch to remove compilation warning with vc++ [repost]
by Baptiste Lepilleur Sept. 28, 2005

Sept. 28, 2005

The attached patch fix a few warning when compiling translated C with VC++: - direct.h not included (required for mkdir...) - mkdir does not takes a mode parameter - redefined macros There is also a warning which I haven't fixed: long LL_os_lseek(long fd, long pos, long how) { #if defined(MS_WIN64) || defined(MS_WINDOWS) PY_LONG_LONG res; // .... return res; } On WIN32, __int64 _lseeki64() returns a 64 bits integer which doesn't fit in a 'long' (which is only 32bits). I'm not sure how this … [View More]

3 3

How agile is PyPy?
by Beatrice During Sept. 27, 2005

Sept. 27, 2005

Hi there I am working on documenting PyPy (the project) as a showcase of agile development. In order to be able to do this I would love to get some thoughts and reflections from you who are working on /following PyPy and the question is of course - how agile are we? Here is some short notes on success factors of agile approaches (from an eworkshop in 2002 - Cockburn, Beck etc, http://fc-md.umd.edu/projects/Agile/Summary/SummaryPF.htm): ----------------------------------------------------… [View More]

1 0

Patch to remove compilation warning with vc++
by Baptiste Lepilleur Sept. 27, 2005

Sept. 27, 2005

The attached patch fix a few warning when compiling translated C with VC++: - direct.h not included (required for mkdir...) - mkdir does not takes a mode parameter - redefined macros There is also a warning which I haven't fixed: long LL_os_lseek(long fd, long pos, long how) { #if defined(MS_WIN64) || defined(MS_WINDOWS) PY_LONG_LONG res; // .... return res; } On WIN32, __int64 _lseeki64() returns a 64 bits integer which doesn't fit in a 'long' (which is only 32bits). I'm not sure how this … [View More]

3 3

profiling translation process?
by hpk＠trillke.net Sept. 24, 2005

Sept. 24, 2005

Hi folks, did anyone try to profile the translation process itself recently? If so what where the results? If not then i think it would be a good idea because it's obviously one of the main activities these days. cheers, holger

4 5

OSCON Europe Oct 17-20 Amsterdam
by Laura Creighton Sept. 23, 2005

Sept. 23, 2005

http://conferences.oreillynet.com/eurooscon/ Anybody going? Laura

4 4

Re: [pypy-svn] r17783 - in pypy/dist/pypy/objspace/flow: . test
by Ben.Young＠risk.sungard.com Sept. 23, 2005

Sept. 23, 2005

Hi Armin, Just a quick question. Is mutating a list while iterating over it rpython? (Also was wondering if you noticed the mail I sent yesterday to pypy-dev?) Cheers, Ben P.S Do you think there is ever going to be a sprint in London sometime as I would love to be able to come to one one day! I guess it's down to someone to organise a room etc. pypy-svn-bounces(a)codespeak.net wrote on 23/09/2005 11:04:05: > Author: arigo > Date: Fri Sep 23 12:04:04 2005 > New Revision: 17783 … [View More]> > Modified: > pypy/dist/pypy/objspace/flow/model.py > pypy/dist/pypy/objspace/flow/test/test_model.py > Log: > Further simplification of traverse(), the full flexibility of which > is never used anywhere and the speed of which is crucial during > translation. > > > Modified: pypy/dist/pypy/objspace/flow/model.py > ============================================================================== > --- pypy/dist/pypy/objspace/flow/model.py (original) > +++ pypy/dist/pypy/objspace/flow/model.py Fri Sep 23 12:04:04 2005 > @@ -344,52 +344,65 @@ > #_________________________________________________________ > # a visitor for easy traversal of the above model > > -import inspect # for getmro > +##import inspect # for getmro > > -class traverse: > +##class traverse: > > - def __init__(self, visitor, functiongraph): > - """ send the visitor over all (reachable) nodes. > - the visitor needs to have either callable attributes > 'visit_typename' > - or otherwise is callable itself. > - """ > - self.visitor = visitor > - self.visitor_cache = {} > - self.seen = {} > - self.visit(functiongraph) > - > - def visit(self, node): > - if id(node) in self.seen: > - return > +## def __init__(self, visitor, functiongraph): > +## """ send the visitor over all (reachable) nodes. > +## the visitor needs to have either callable attributes > 'visit_typename' > +## or otherwise is callable itself. > +## """ > +## self.visitor = visitor > +## self.visitor_cache = {} > +## self.seen = {} > +## self.visit(functiongraph) > + > +## def visit(self, node): > +## if id(node) in self.seen: > +## return > + > +## # do the visit > +## cls = node.__class__ > +## try: > +## consume = self.visitor_cache[cls] > +## except KeyError: > +## for subclass in inspect.getmro(cls): > +## consume = getattr(self.visitor, "visit_" + > subclass.__name__, None) > +## if consume: > +## break > +## else: > +## consume = getattr(self.visitor, 'visit', self.visitor) > + > +## assert callable(consume), "visitor not found for > %r on %r" % (cls, self.visitor) > + > +## self.visitor_cache[cls] = consume > + > +## self.seen[id(node)] = consume(node) > + > +## # recurse > +## if isinstance(node, Block): > +## for obj in node.exits: > +## self.visit(obj) > +## elif isinstance(node, Link): > +## self.visit(node.target) > +## elif isinstance(node, FunctionGraph): > +## self.visit(node.startblock) > +## else: > +## raise ValueError, "could not dispatch %r" % cls > + > +def traverse(visit, functiongraph): > + pending = [functiongraph.startblock] > + seen = {id(functiongraph.startblock): True} > + for block in pending: > + visit(block) > + for link in block.exits: > + visit(link) > + targetid = id(link.target) > + if targetid not in seen: > + pending.append(link.target) > + seen[targetid] = True > > - # do the visit > - cls = node.__class__ > - try: > - consume = self.visitor_cache[cls] > - except KeyError: > - for subclass in inspect.getmro(cls): > - consume = getattr(self.visitor, "visit_" + > subclass.__name__, None) > - if consume: > - break > - else: > - consume = getattr(self.visitor, 'visit', self.visitor) > - > - assert callable(consume), "visitor not found for %r > on %r" % (cls, self.visitor) > - > - self.visitor_cache[cls] = consume > - > - self.seen[id(node)] = consume(node) > - > - # recurse > - if isinstance(node, Block): > - for obj in node.exits: > - self.visit(obj) > - elif isinstance(node, Link): > - self.visit(node.target) > - elif isinstance(node, FunctionGraph): > - self.visit(node.startblock) > - else: > - raise ValueError, "could not dispatch %r" % cls > > def flatten(funcgraph): > l = [] > > Modified: pypy/dist/pypy/objspace/flow/test/test_model.py > ============================================================================== > --- pypy/dist/pypy/objspace/flow/test/test_model.py (original) > +++ pypy/dist/pypy/objspace/flow/test/test_model.py Fri Sep 23 12:04:04 2005 > @@ -28,27 +28,27 @@ > graph = self.getflow(self.simplefunc) > assert all_operations(graph) == {'add': 1} > > - def test_class(self): > - graph = self.getflow(self.simplefunc) > +## def test_class(self): > +## graph = self.getflow(self.simplefunc) > > - class MyVisitor: > - def __init__(self): > - self.blocks = [] > - self.links = [] > - > - def visit_FunctionGraph(self, graph): > - self.graph = graph > - def visit_Block(self, block): > - self.blocks.append(block) > - def visit_Link(self, link): > - self.links.append(link) > - > - v = MyVisitor() > - traverse(v, graph) > - #assert len(v.blocks) == 2 > - #assert len(v.links) == 1 > - assert v.graph == graph > - assert v.links[0] == graph.startblock.exits[0] > +## class MyVisitor: > +## def __init__(self): > +## self.blocks = [] > +## self.links = [] > + > +## def visit_FunctionGraph(self, graph): > +## self.graph = graph > +## def visit_Block(self, block): > +## self.blocks.append(block) > +## def visit_Link(self, link): > +## self.links.append(link) > + > +## v = MyVisitor() > +## traverse(v, graph) > +## #assert len(v.blocks) == 2 > +## #assert len(v.links) == 1 > +## assert v.graph == graph > +## assert v.links[0] == graph.startblock.exits[0] > > ## def test_partial_class(self): > ## graph = self.getflow(self.simplefunc) > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn > [View Less]

3 2

Crash!
by Ben.Young＠risk.sungard.com Sept. 23, 2005

Sept. 23, 2005

Hi Everyone, Current checkout, compiled pypy (windows as usual): $ ./pypy-c.exe debug: entry point starting debug: argv -> c:\Documents and Settings\YoungB\dist\pypy\translator\goal\pypy-c.exe debug: importing code debug: calling code.interact() Python 2.4.1 (pypy 0.7.1 build) on win32 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>>> fe -> Segfault Appears to be a problem throwing exceptions. On another point, I notice … [View More]

2 1