Jonas Hahnfeld <hah...@hahnjo.de> writes:
> Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
>> Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
>> hah...@hahnjo.de
>> >
>> ha scritto:
>> > > > Another shortcoming is that links to other issues are broken
>> > > > (transformed in links to non-existing anchors in current issue).
>> > >
>> > > I think that is because some issues have not (yet) been migrated. I
>> > > hope these links start to work once all is there.
>> >
>> > So I eventually convinced my script to migrate close to all issues
>> > [1],
>> > and all references to other issues that I checked so far are now
>> > working. Could you maybe check again and let me know if something's
>> > still broken? In any case I've already modified my script to first
>> > sort
>> > the issues and not take the (random?) order from SF.
>>
>> I still see the problem.
>>
>> Take issue 34 as example.
>> All the "Issue $NUMBER" have a wrong link:
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
>>
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
>>
>>
>> But I can see an "issue 34" link working fine:
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
>>
>>
>> Perhaps your script is considering only the lower case "issue"?
>
> Well no, I'm relying on GitLab magic here - my script attached for
> reference.
> But I think I see what's going on: When the script migrated issue #34,
> the referenced issues were not there yet and apparently GitLab does
> some evaluation when the text is posted. If I migrate the issue now
> (see https://gitlab.com/lilypond-issues/lilypond/issues/5742), the
> links work - also note how "#25" in the first comment comes live.
> (I manually edited two comments in the original #34, so these do work
> now. The reference to "Issue 1302" is still broken though as I didn't
> touch that comment.)
>
> Unfortunately this means that my strategy to create the issues "in
> order" doesn't work because comments can reference later issues that
> were created in the mean-time. So instead I'll try to first create all
> issues and then migrate all comments. That doesn't work for later edits
> of the issue description, but that should be the minority.
> I'll wait a few days for other problems before starting another
> attempt.
May I point out the tool-to-use for this task?
File: coreutils.info, Node: tsort invocation, Prev: ptx invocation, Up:
Operating on sorted files
7.6 ‘tsort’: Topological sort
=============================
‘tsort’ performs a topological sort on the given FILE, or standard input
if no input file is given or for a FILE of ‘-’. For more details and
some history, see *note tsort background::. Synopsis:
tsort [OPTION] [FILE]
‘tsort’ reads its input as pairs of strings, separated by blanks,
indicating a partial ordering. The output is a total ordering that
corresponds to the given partial ordering.
For example
tsort <<EOF
a b c
d
e f
b c d e
EOF
will produce the output
a
b
c
d
e
f
Consider a more realistic example. You have a large set of functions
all in one file, and they may all be declared static except one.
Currently that one (say ‘main’) is the first function defined in the
file, and the ones it calls directly follow it, followed by those they
call, etc. Let’s say that you are determined to take advantage of
prototypes, so you have to choose between declaring all of those
functions (which means duplicating a lot of information from the
definitions) and rearranging the functions so that as many as possible
are defined before they are used. One way to automate the latter
process is to get a list for each function of the functions it calls
directly. Many programs can generate such lists. They describe a call
graph. Consider the following list, in which a given line indicates
that the function on the left calls the one on the right directly.
main parse_options
main tail_file
main tail_forever
tail_file pretty_name
tail_file write_header
tail_file tail
tail_forever recheck
tail_forever pretty_name
tail_forever write_header
tail_forever dump_remainder
tail tail_lines
tail tail_bytes
tail_lines start_lines
tail_lines dump_remainder
tail_lines file_lines
tail_lines pipe_lines
tail_bytes xlseek
tail_bytes start_bytes
tail_bytes dump_remainder
tail_bytes pipe_bytes
file_lines dump_remainder
recheck pretty_name
then you can use ‘tsort’ to produce an ordering of those functions
that satisfies your requirement.
example$ tsort call-graph | tac
dump_remainder
start_lines
file_lines
pipe_lines
xlseek
start_bytes
pipe_bytes
tail_lines
tail_bytes
pretty_name
write_header
tail
recheck
parse_options
tail_file
tail_forever
main
‘tsort’ detects any cycles in the input and writes the first cycle
encountered to standard error.
Note that for a given partial ordering, generally there is no unique
total ordering. In the context of the call graph above, the function
‘parse_options’ may be placed anywhere in the list as long as it
precedes ‘main’.
The only options are ‘--help’ and ‘--version’. *Note Common
options::.
An exit status of zero indicates success, and a nonzero value
indicates failure.
* Menu:
* tsort background:: Where tsort came from.
Now of course the non-linear manner of being able to update issues and
the desire to have cross-reference means that we _will_ have cycles. So
this is not a cure-all, and cycles may need reediting the issues that
are broken by cycles. But at least for the more linear reference
chains, this should be a good help.
--
David Kastrup
