Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [9 earlier articles] |
| Re: binary search debugging of compilers gah4@u.washington.edu (gah4) (2023-05-16) |
| Re: binary search debugging of compilers rsc@swtch.com (Russ Cox) (2023-05-17) |
| Re: binary search debugging of compilers cameron.mcinally@nyu.edu (Cameron McInally) (2023-05-17) |
| Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-17) |
| Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-17) |
| Re: binary search debugging of compilers gah4@u.washington.edu (gah4) (2023-05-17) |
| Re: binary search debugging of compilers spibou@gmail.com (Spiros Bousbouras) (2023-05-18) |
| Re: binary search debugging of compilers rsc@swtch.com (Russ Cox) (2023-05-18) |
| Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-19) |
| Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-19) |
| binary search debugging of compilers cclick0@gmail.com (Cliff Click) (2023-05-19) |
| binary search debugging of compilers tekk.nolagi@gmail.com (Max B) (2023-05-19) |
| Re: binary search debugging of compilers tkoenig@netcologne.de (Thomas Koenig) (2023-05-19) |
| [2 later articles] |
| From: | Spiros Bousbouras <spibou@gmail.com> |
| Newsgroups: | comp.compilers |
| Date: | Thu, 18 May 2023 10:50:24 -0000 (UTC) |
| Organization: | A noiseless patient Spider |
| References: | <CADSkJJVN7RGqhgVDZaz_K5be6uEDaMofMu5OF3RR4Y5-fDu00Q@mail.gmail.com> 23-05-013 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="15025"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | debug, tools |
| Posted-Date: | 18 May 2023 13:00:32 EDT |
| In-Reply-To: | 23-05-013 |
On Wed, 17 May 2023 10:55:27 -0400
Russ Cox <rsc@swtch.com> wrote:
> When BitKeeper came along, we added this:
>
> --longest Restrict the deltas to those on the longest line
> between the two range endpoints. Unlike a range, the
> lower bound is included in the output.
>
> because BitKeeper history is a lattice, not a straight line. So your
> test points became
>
> bk changes -nd:REV: > REVS
>
> and binary search over those. That gets you the longest "straight" line
> in the graph.
Any partial ordering can be extended to a total ordering. Why can't you
just do that instead of using 'the longest "straight" line' ?
Return to the
comp.compilers page.
Search the
comp.compilers archives again.