<dagreve@...> writes:
> FYI. I understand the SBCL is related to CMUCL.
It is, but...
> Following is some code that illustrates a CMU compiler bug.
> Evaluating the forms at the end of this file will exercise the bug.
... I could not get this code to trigger any bug. Have you actually
verified that it triggers a bug in SBCL, and if so, please could you
tell this list how to reproduce it in SBCL itself?
Cheers,
Christophe

Mario S.Mommer <m_mommer@...> writes:
> Consider the function
>
> (defun lose-important-and-expensive-data-please ()
> (with-open-file (strm "important-data.txt"
> :direction :output
> :if-exists :supersede)
> (format strm "42~%")
> (finish-output strm)
> (break)))
>
> Now, if I return to top level, the file "important-data.txt" gets
> _removed_, together with The Answer.
I agree that this is sub-optimal in principle. When I fixed some of
close :abort t behaviour I looked at dealing with this too, but it
turns out to be (a) painfull (b) bad if your files are BIG, as the
space used up by the old file cannot be reclaimed before writing the
new one is finished.
Luckily, there is a solution that suits your needs:
:if-exists :rename-and-delete
With that SBCL (and other conformant lisps, IMO) should restore the
original in case of an abnormal exist, and delete it otherwise.
The way I see it, there is a usefull distinction between the two:
supeseding will allow the old space to be reclaimed before writing the
new file is finished.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

"Lui Fungsin" <fungsin.lui@...> writes:
> Can anyone explain how I can run a shell subprocess within sbcl repl?
>
> I tried all the combination of :input :output and :pty but it doesn't
> seem to work. I don't know enough of sbcl's internal to figure out
> what's missing.
I'm not sure what exactly is happening. I found one bug in RUN-PROGRAM, but
unfortunately unrelated to your case. Basically it seems shells don't like
being run the way SBCL prefers to run its sub-processes.
A workaround is simple, though:
(define-alien-routine system int (command c-string))
(system "/bin/sh")
Out of curiosity, what do SIGINT and SIGSTOP (C-c and C-z) do with
the Allegro shell-command?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

Mario S.Mommer <m_mommer@...> writes:
> I would sugest that the following is a bug, if not technically, then
> at least, shall we say, morally. Or at least, I think it would be a
> lot better if the behaviour was different.
>
> Consider the function
>
> (defun lose-important-and-expensive-data-please ()
> (with-open-file (strm "important-data.txt"
> :direction :output
> :if-exists :supersede)
> (format strm "42~%")
> (finish-output strm)
> (break)))
>
> Now, if I return to top level, the file "important-data.txt" gets
> _removed_, together with The Answer.
>
> This is particularily insidious if after a very long computation
> something breaks, but you would like to keep the log. Of course, I
> could just have copied the file somewhere else before pressing 'q',
> among a variety of other workarounds. But I think with-open-file
> shouldn't remove data just because. If anything, it makes the scenario
> of inadvertent data loss a lot more likely.
Well, you might have to take this up with the ANSI standardization
committee, because the CLHS page for WITH-OPEN-FILE says
| When control leaves the body, either normally or abnormally (such as
| by use of throw), the file is automatically closed. If a new output
| file is being written, and control leaves abnormally, the file is
| aborted and the file system is left, so far as possible, as if the
| file had never been opened.
So, if you don't want that behaviour from with-open-file, I think
you'd better not use with-open-file in the first place.
(This is not to disagree with your contention that this is a moral
bug, nor to agree with it particularly: just to point out that the
spec not only encourages but mandates the behaviour you've seen)
Cheers,
Christophe

Hi,
I would sugest that the following is a bug, if not technically, then
at least, shall we say, morally. Or at least, I think it would be a
lot better if the behaviour was different.
Consider the function
(defun lose-important-and-expensive-data-please ()
(with-open-file (strm "important-data.txt"
:direction :output
:if-exists :supersede)
(format strm "42~%")
(finish-output strm)
(break)))
Now, if I return to top level, the file "important-data.txt" gets
_removed_, together with The Answer.
This is particularily insidious if after a very long computation
something breaks, but you would like to keep the log. Of course, I
could just have copied the file somewhere else before pressing 'q',
among a variety of other workarounds. But I think with-open-file
shouldn't remove data just because. If anything, it makes the scenario
of inadvertent data loss a lot more likely.
Regards,
Mario.