bug-idutils
[Top][All Lists]
Advanced

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

[bug-idutils] [patch #5358] scanners for Python and R


From: Ramon Diaz-Uriarte
Subject: [bug-idutils] [patch #5358] scanners for Python and R
Date: Sun, 29 Oct 2006 21:58:42 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060830 Firefox/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-1)

Follow-up Comment #7, patch #5358 (project idutils):

I think I know what is happeing. In both cases, the problem seems to be the
ordering of the output. It is not the individual tokens that differ, but
where they appear in test-file.{R,py}.bad-{xtokid,fid}.

In the file "consistency" (within the /testsuite dir of idutils) I see that
the xtokid output is piped through sort (whereas the fid output seems to be
sorted "internally"). I think this might be the cause of the apparent
problem: the sort is breaking mutliline tokens (and sorting _within_ a
token), whereas fid is doing it "right". 

I think this is happening in test-file.py.bad-{xtokid,fid}. The original
multiline comment

"""A file that does an atomic-rename to move into place.
    This also causes hardlinks to break when it's written out.
    Open this as for a regular file, then use commit() to move into
    place or abort() to cancel.
    An encoding can be specified; otherwise the default is ascii.
    """

is preserved in fid's output. But the sorted xtokid has all these lines
reordered.

So, is it possible that the consitency check, because of the sort of xtokid's
output, is leading us to believe there is a problem (when there is none)?

R.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?5358>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

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