I had introduced this in f11aef74b as a means of quickly cleaning up
after e.g. an exploratory session where a lot of transient applets were
opened from ndscan, or for a dashboard that has been running for a while
with CCBs enabled but without anybody actually working there.
It turns out that one usually wants the few docked applets to stay open,
as they were necessarily arranged manually at some prior point. And as a
corollary to the latter, if one did want to close them as well, doing so
manually would not be too onerous either.
This only allows for indexing with a constant value (e.g. x[0]).
While slices would be possible to implement, it's not clear how to
preserve type inference here. The current typing rule is:
Γ ⊢ x : τ Γ ⊢ a : Int Γ ⊢ b : Int
------------------------------------
Γ ⊢ x[a:b] : τ
However, tuples would require a different typing rule, and so we'd need
to defer type inference if τ is a tyvar. I'm not confident that this
won't change behaviour, so we leave as-is for now.
Signed-off-by: Jonathan Coates <jonathan.coates@oxionics.com>
This would have caught the reduction in header padding with LLD 14.
In theory, we could just get rid of the hard-coded kernel CPU address
ranges altogether and use ksupport.elf as the one source of truth; the
code already exists in dyld. The actual base address of the file would
still need to be forwarded to the kernel-side libunwind glue, though,
as there doesn't seem to be a clean way to get the equivalent of
KSUPPORT_HEADER_SIZE through the linker script. I have left this as-is
with the hard-coded KERNELCPU_… constants for now.
Previous linker versions had inserted some zero padding bytes
between the ELF headers and the first section, but LLD 14 does
not anymore.
Hard-coding the offset of the first section in ksupport.elf
manually isn't ideal; we should probably parse the ELF program
headers instead when first setting up the kernel CPU.
