> I myself *very* need SymPy to be faster. For example it takes me a lot > of time to just wait for tests passing.
The tests are annoying. What I am definitely going to do is to fix bugs in SymPy so that py.test -d works again (your py.test patch will have to be improved though). Then it is possible to run all tests in about 30s on Intel Core Quad -- I can provide you an account. Then I tried 4 computers (one amd64, one core Quad, two core Duos) an it runs for about 20s. By improving the testsuite and py.test, we could maybe even speed it up (I don't see a reason why it couldn't scale up linearly). However, this is a "hammer method". If we could speedup sympy, it will be fine, but I suspect it's simply because of so many tests. The next step is rewriting parts in C++, but I would wait a little bit with this one, until the internals of SymPy are not changing that often as now. The huge disadvantage of C++ rewriting is that we will need to have two equivalent implementations - C++ and Python and keep both updated, because I certainly want SymPy to run on pure Python only, the C++ should be only an optional addon. But I believe it will be possible - that's my secret plan from the beginning - to write it in Python first, to have something now (and slow) and then when we know how to do it and it works, to rewrite parts to C++ or even C. > > It > > would be awesome, if we could cleanly separate it (even to a separate > > project, and just copy it to sympy, like we do with pyglet, so that > > endusers are not affected at all), > > I do not think separating sympy.core into its own project is a good idea. > > The reason is that not only core affects everything else, but everything > else also affects core and it's design. So having both core and > 'high-level' stuff in one place will help to improve *both*. > > I agree that structuring things is good, but we are already on that > road, right? I think so I think we are doing good. > I think what we really need to be able to experiment easily is a more > distributed development model. This could be slightly ooftopic, but an > interested reader could go to: > > http://svk.bestpractical.com/view/HomePage > > and also: > > http://darcs.net/ > http://www.selenic.com/mercurial/wiki/ > http://git.or.cz/ And you forgot bazaar and arch. Well, I am not against, but then we could use the google code hosting for everything, except the source repository and use some other hosting for it, for example: http://repo.or.cz/ Nevertheless before deciding not to use svn, what are the problems with that? For example how could it help us with this Apply things transition to use let's say git, that is distributed? I myself only used svn and cvs so far, but let's switch to something else if it is so much better. Ondrej --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
