From 59aebe93a588105544dd6c51525fc30399432d58 Mon Sep 17 00:00:00 2001 From: Chris Penner Date: Wed, 26 Jun 2024 11:22:32 -0700 Subject: [PATCH] remove ls-pretty-print-scope-bug.md, we don't really support subnamespaces for this any more --- .../transcripts/ls-pretty-print-scope-bug.md | 44 ------- .../ls-pretty-print-scope-bug.output.md | 115 ------------------ 2 files changed, 159 deletions(-) delete mode 100644 unison-src/transcripts/ls-pretty-print-scope-bug.md delete mode 100644 unison-src/transcripts/ls-pretty-print-scope-bug.output.md diff --git a/unison-src/transcripts/ls-pretty-print-scope-bug.md b/unison-src/transcripts/ls-pretty-print-scope-bug.md deleted file mode 100644 index 36ff97107..000000000 --- a/unison-src/transcripts/ls-pretty-print-scope-bug.md +++ /dev/null @@ -1,44 +0,0 @@ -```unison -unique type Foo = Foo -``` - -```ucm -scratch/main a.b> add -scratch/main> fork .a.b .c.d.f -.c.g.f> -``` - -```unison -unique type Foo = Foo -``` - -```ucm -scratch/main c.g.f> add -.c> -``` - -```unison -foo = .d.f.Foo.Foo -``` - -```ucm -scratch/main c> add -``` - -At this point we have: -`.a.b.Foo` -`.c.d.f.Foo` which is equal to `.a.b.Foo` -`.c.g.f.Foo` which is distinct from the other `Foo` types - -```ucm -scratch/main> delete .c.d.f.Foo -``` -Once `.c.d.f.Foo` is deleted `.c.foo` should have the type `.a.b.Foo` -when viewed from `scratch/main>`, but an unnamed type when viewed from `.c>`, -since referencing `.a.b.Foo` would reference names outside of the -namespace rooted at `.c`. - -```ucm -scratch/main> ls c -scratch/main c> ls -``` diff --git a/unison-src/transcripts/ls-pretty-print-scope-bug.output.md b/unison-src/transcripts/ls-pretty-print-scope-bug.output.md deleted file mode 100644 index 5c0eab0b7..000000000 --- a/unison-src/transcripts/ls-pretty-print-scope-bug.output.md +++ /dev/null @@ -1,115 +0,0 @@ -```unison -unique type Foo = Foo -``` - -```ucm - - Loading changes detected in scratch.u. - - I found and typechecked these definitions in scratch.u. If you - do an `add` or `update`, here's how your codebase would - change: - - ⍟ These new definitions are ok to `add`: - - type Foo - -``` -```ucm - ☝️ The namespace .a.b is empty. - -.a.b> add - - ⍟ I've added these definitions: - - type Foo - -scratch/main> fork .a.b .c.d.f - - Done. - - ☝️ The namespace .c.g.f is empty. - -``` -```unison -unique type Foo = Foo -``` - -```ucm - - Loading changes detected in scratch.u. - - I found and typechecked these definitions in scratch.u. If you - do an `add` or `update`, here's how your codebase would - change: - - ⍟ These new definitions are ok to `add`: - - type Foo - -``` -```ucm -.c.g.f> add - - ⍟ I've added these definitions: - - type Foo - -``` -```unison -foo = .d.f.Foo.Foo -``` - -```ucm - - Loading changes detected in scratch.u. - - I found and typechecked these definitions in scratch.u. If you - do an `add` or `update`, here's how your codebase would - change: - - ⍟ These new definitions are ok to `add`: - - foo : d.f.Foo - -``` -```ucm -.c> add - - ⍟ I've added these definitions: - - foo : d.f.Foo - -``` -At this point we have: -`.a.b.Foo` -`.c.d.f.Foo` which is equal to `.a.b.Foo` -`.c.g.f.Foo` which is distinct from the other `Foo` types - -```ucm -scratch/main> delete .c.d.f.Foo - - Done. - -``` -Once `.c.d.f.Foo` is deleted `.c.foo` should have the type `.a.b.Foo` -when viewed from `scratch/main>`, but an unnamed type when viewed from `.c>`, -since referencing `.a.b.Foo` would reference names outside of the -namespace rooted at `.c`. - -```ucm -scratch/main> ls c - - nothing to show - -``` - - - -🛑 - -The transcript failed due to an error in the stanza above. The error is: - - - nothing to show -