gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] PyArch patches


From: Aaron Bentley
Subject: Re: [Gnu-arch-users] PyArch patches
Date: Sun, 20 Jun 2004 18:42:48 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

David Allouche wrote:

Since tla is about to be
localized, parsing the error logs is no longer really an option, so tla
should maybe be modified to have particular exit status for those cases.

I wouldn't be surprised if it was trivial to force tla into default English mode. Probably it would just require changing a locale variable. But in that case, a pyArch program that was localized would have to interpret every possible error.

(Which might not be so hard actually, given that the tla program texts would be in a standardized format)

What I have to do is iterate through the logs in order to find out whether the specified log exists, and return it if so. That's exactly what get_log did.


How hackish... on the other hand tla does not really provide existence
predicates for anything.

It's not just tla. libarch doesn't provide existence predicates for anything, either. (Except revisions, and I added that.)

Testing for the existence of namespace objects
is currently done, very unefficiently, more or less along those lines in
the arch.py "exists" methods and _tla.py "*_exists" functions.

Which is more or less how they're done in tla also.  (I just rewrote the
input validation stuff.  Sorry.)

I think the correct way would be:

  * Implementing a "patchlog_exists(tree, version, patchlevel)" function
    in _tla.py, which currently just checks the output of "tla logs"
    using the "in" keyword.
That way we can easily drop in something faster leveraging a new
    feature of tla or looking directly in the {arch} directory.

Should be trivial, if the need arises.

  * Defining "arch.ArchSourceTree.has_patchlog(revision)" as a
    high-level interface. The "archive/version" and patchlevel parts are
    already handy in Revision instances.

  * Documenting that "arch.Patchlog" expects the patchlog to exist in
    the archive/library/tree or unpleasant things may happen at
    unexpected times, unless the patchlog if "forced" so unpleasant
    things happen right now.

You can kinda see why I skipped all that, eh? I've done it in my cat-log function, so I don't have an immediate need anymore. Still, I can imagine putting it in sometime when I'm bored.

Aaron




reply via email to

[Prev in Thread] Current Thread [Next in Thread]