[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] working directory
From: |
Taylor R Campbell |
Subject: |
Re: [MIT-Scheme-devel] working directory |
Date: |
Tue, 15 Feb 2011 16:19:08 +0000 |
User-agent: |
IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.0.1 |
Date: Tue, 15 Feb 2011 06:46:42 -0700
From: address@hidden (Matt Birkholz)
How about renaming with-working-directory-pathname
"with-DEFAULT-directory-pathname", and set-working-directory-pathname!
"set-PROCESS-current-working-directory!"? Then the two procedures
will not appear to be related, and we might avoid these frustrated
expectations.
I think it would be better to make WITH-WORKING-DIRECTORY-PATHNAME and
SET-WORKING-DIRECTORY-PATHNAME! match semantics and both interact with
the operating system. You can always hack *DEFAULT-PATHNAME-DEFAULTS*
if you don't want to interact with the operating system, and just want
to influence MERGE-PATHNAMES.
I just wish to emphasize that the runtime makes frequent use of
merge-pathnames, such that the OS never sees a relative pathname.
The frobbing of the cwd is, I think, appropriately confined to ux-
procedures like ux-make-subprocess.
The runtime doesn't guarantee that the OS never sees a relative
pathname. If you want, you can set *DEFAULT-PATHNAME-DEFAULTS* so
that it does. You can also set *DEFAULT-PATHNAME-DEFAULTS* so that it
doesn't.
I AM trying to put the brakes on loading up threads with tons of bells
and whistles. I want to spawn threads with wild abandon, e.g. in
Edwin every time it needs to load an image, fontify a buffer, or
animate anything.
I want to spawn threads with wild abandon, too. That's why I want to
make sure they don't interfere. I don't care how fast they run if
they render Scheme unusably unreliable.