[Python-Dev] SVN backup?
While cleaning up some old CDs, I discovered that I had received some backups of the CVS repository. Should we repeat the exercise for SVN? -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck." --USENET schmuck (aka Robert Kern) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN backup?
Aahz wrote: > While cleaning up some old CDs, I discovered that I had received some > backups of the CVS repository. Should we repeat the exercise for SVN? No *exactly* sure what you are asking: if you mean that you had been producing regular backups of the CVS tarball, and ask whether you should do that for subversion also... Certainly, if you can contribute the resources for that! The daily snapshot of the repository is at http://svn.python.org/snapshots/projects-svn-tarball.tar.bz2 Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed additional keyword argument in lo gging calls
Skip, Thanks for the detailed post indicating what stuff you find useful, and what stuff you don't need. It seems that your use case is fairly unusual, so I completely understand that you have optimized how you use logging. I will consider how to try to incorporate your feedback without breaking backwards compatibility, but it will probably not be via the 'extra' mechanism I proposed. For example, to avoid thread and process computation, I could introduce module-level variables eg. log_threads and log_processes, both set to true to maintain backwards compatibility, but settable to false to avoid expensive thread and process computations where not needed. The 'extra' mechanism will remain to provide additional diagnostic information where e.g. the same code is executed by multiple threads and there is a need to distinguish the different threads in the logging output. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast-objects branch created
On 12/1/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Jeremy Hylton wrote: > > I'm not sure what your intent for this work is, but I'd like to create > > a parallel arena branch and compare the results. I'll start work on > > that tomorrow. > > I certainly want the PyObject* branch to become "life" at some time; > I think this is the way to go, and that an arena approach is > fundamentally flawed. I have implemented a version of the arena API that handles freeing memory in ast.c. It worked out rather like I expected, although I still haven't thought much about how it would extend to the rest of the compiler. It seems like the same approach should apply, although I think the primary concern was the complexity of memory management in ast.c. The way the arena approach works is to free all the AST nodes at the end of compilation. This approach isn't all that different than the one it replaced. In the trunk, there is a single call to free_mod() at the end of compilation and it recursively frees all the sub-objects. One way to think about the arena changes is to replace a set of recursive function calls based on the tree structure with a flat list of all AST nodes created during object creation. The real advantage is in the error cases, where all the memory gets freed even though all the nodes aren't attached to a single tree. Can you expand on why you think this approach is fundamentally flawed? > That said: go ahead and create a branch. This is one of the things > that subversion makes convenient, and it allows people to actually > judge the results when we are done. I'm personally not worried about > the duplicated work: if we actually carry out the experiment of > multiple alternative (or perhaps supplementing) implementations, > we have much better grounds to pick the approach for the mainline. Sure does. It seems like the code generation from the AST description also makes this kind of experimentation easier. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast-objects branch created
Jeremy Hylton wrote: > Can you expand on why you think this approach is fundamentally flawed? I would expect that you allocate in the process memory that needs to outlive the arena, e.g. python strings. The fundamental problem is that the arena deallocation cannot know whether such memory exists, and what to do with it. So two things may happen: - you mistakenly allocate long-lived memory from the arena, and then discard it when you discard the arena. This gives you dangling pointer. The problem here is that at the allocation point, you may not know (yet) either whether this is going to survive the arena or not. - you allocate memory outside of the arena to survive it, and then something goes wrong, and you deallocate the arena. Yet, the outside memory remains garbage. IOW, there would be no problem if you were *completely* done when you throw away the arena. This is not the case, though: eventually you end up with byte code that need to persist. > Sure does. It seems like the code generation from the AST description > also makes this kind of experimentation easier. Indeed. I wish there was a way to generate ast.c from a transformation description as well. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
