Discussion:
[Audacity-devel] Bug 437, and Strong vs. Weak exception-safety guarantees
Paul Licameli
2016-11-05 18:23:27 UTC
Permalink
Strong and Weak exception safety guarantees. Are we all familiar with such
C++ jargon?

This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.

If you have some object, and do a complicated multi-part operation on it,
which may fail at some point, the "strong" guarantee is that the object is
restored to its state as it was before attempting the operation. The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.

I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier). This
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.

At lower levels than the Project, such as the WaveTrack or WaveClip, I
think it looks like too much effort to make a strong guarantee: try to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results of
the failed operation.

This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.

Recording should still be treated with some extra, special effort to save
as much of the data as possible.

PRL
James Crook
2016-11-05 19:00:24 UTC
Permalink
That sounds right to me Paul.

I think the 'strong' guarantees at the higher levels may not need to be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...

If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.

--James.
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar with such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation on it,
which may fail at some point, the "strong" guarantee is that the object is
restored to its state as it was before attempting the operation. The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier). This
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or WaveClip, I
think it looks like too much effort to make a strong guarantee: try to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.
Recording should still be treated with some extra, special effort to save
as much of the data as possible.
PRL
Paul Licameli
2016-11-05 21:54:24 UTC
Permalink
Post by James Crook
That sounds right to me Paul.
I misspoke one thing. Exhaustion of disk space concerns us. But
exhaustion of memory is a more pervasive possibility in the code that we
will not attempt to recover from gracefully.

PRL
Post by James Crook
I think the 'strong' guarantees at the higher levels may not need to be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
--James.
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar with
such
Post by Paul Licameli
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation on it,
which may fail at some point, the "strong" guarantee is that the object
is
Post by Paul Licameli
restored to its state as it was before attempting the operation. The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier). This
works by restoring the last state saved in Undo history, without
completing
Post by Paul Licameli
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or WaveClip, I
think it looks like too much effort to make a strong guarantee: try to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results
of
Post by Paul Licameli
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.
Recording should still be treated with some extra, special effort to save
as much of the data as possible.
PRL
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2016-11-06 00:50:41 UTC
Permalink
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need to be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?

It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.

When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.

Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar with such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation on it,
which may fail at some point, the "strong" guarantee is that the object is
restored to its state as it was before attempting the operation. The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier). This
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or WaveClip, I
think it looks like too much effort to make a strong guarantee: try to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.
Recording should still be treated with some extra, special effort to save
as much of the data as possible.
PRL
James Crook
2016-11-06 09:42:05 UTC
Permalink
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need to be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
Yes. The lock is something that happens on detection of a failed write.
Restarting could cause the lock again, if enough disk space to recover
the project has not been freed before restarting.
Post by Gale Andrews
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Yes that's a nice embellishment. Could be hard to implement reliably,
and I wouldn't hold 2.1.3 up for it.
Post by Gale Andrews
When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Paul Licameli
2016-11-06 15:35:35 UTC
Permalink
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need to be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Exactly what I wanted to suggest. The means to do that already exists in
the History dialog.

Another place where excess disk usage may lurk is in the clipboard. Less
likely to be a problem, but suppose you do a large cut rather than a
delete. Or suppose you do a large paste, and then apply an effect, so that
the old data pre-effect on the clipboard is not needed. Clearing undo
history does not reclaim that disk space in the clipboard. A special
button to do that may be of help.

If Gale is suggesting, against James, that we should not require the user
to restart, but it would be better to seek ways to let the program continue
after the user intervenes to reclaim disk space -- then I agree.

PRL

When saving a project for the first time, does Audacity delete the AU
Post by Gale Andrews
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar with
such
Post by James Crook
Post by Paul Licameli
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful,
thorough
Post by James Crook
Post by Paul Licameli
ways of fixing it.
If you have some object, and do a complicated multi-part operation on
it,
Post by James Crook
Post by Paul Licameli
which may fail at some point, the "strong" guarantee is that the object
is
Post by James Crook
Post by Paul Licameli
restored to its state as it was before attempting the operation. The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier). This
works by restoring the last state saved in Undo history, without
completing
Post by James Crook
Post by Paul Licameli
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or WaveClip, I
think it looks like too much effort to make a strong guarantee: try to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results
of
Post by James Crook
Post by Paul Licameli
the failed operation.
This assumes most editing operations that could exhaust memory (I
include
Post by James Crook
Post by Paul Licameli
effects and generators) can acceptably just be aborted, and then the
user
Post by James Crook
Post by Paul Licameli
can go free resources and try again.
Recording should still be treated with some extra, special effort to
save
Post by James Crook
Post by Paul Licameli
as much of the data as possible.
PRL
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2016-11-07 02:35:15 UTC
Permalink
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need to be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Exactly what I wanted to suggest. The means to do that already exists in
the History dialog.
Another place where excess disk usage may lurk is in the clipboard. Less
likely to be a problem, but suppose you do a large cut rather than a delete.
Or suppose you do a large paste, and then apply an effect, so that the old
data pre-effect on the clipboard is not needed. Clearing undo history does
not reclaim that disk space in the clipboard. A special button to do that
may be of help.
Perhaps I was mistaken, but I thought the Audacity clipboard was
held in RAM, just as a pointer to the data. Does the Audacity
clipboard take disk space?
Post by Paul Licameli
If Gale is suggesting, against James, that we should not require the user to
restart, but it would be better to seek ways to let the program continue
after the user intervenes to reclaim disk space -- then I agree.
I can see a problem with restart, if the user can't save the project
or can't export because of lack of space. Won't that restart require
a force quit, if the user doesn't want to lose their changes?

Generally restart seems less good to me than letting the user
resume in Audacity once they have enough space. Perhaps
users may be less persuaded to free up space with Audacity
still open, but even with restart they could still run out of space
again so the restart would not seem to achieve anything from
that perspective. .

Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.


Gale
Post by Paul Licameli
Post by Gale Andrews
When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar with such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation on it,
which may fail at some point, the "strong" guarantee is that the object is
restored to its state as it was before attempting the operation. The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many
error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier). This
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or WaveClip, I
think it looks like too much effort to make a strong guarantee: try to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.
Recording should still be treated with some extra, special effort to save
as much of the data as possible.
PRL
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2016-11-07 02:54:47 UTC
Permalink
Post by Paul Licameli
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need to
be
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up
some
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Exactly what I wanted to suggest. The means to do that already exists in
the History dialog.
Another place where excess disk usage may lurk is in the clipboard. Less
likely to be a problem, but suppose you do a large cut rather than a
delete.
Post by Paul Licameli
Or suppose you do a large paste, and then apply an effect, so that the
old
Post by Paul Licameli
data pre-effect on the clipboard is not needed. Clearing undo history
does
Post by Paul Licameli
not reclaim that disk space in the clipboard. A special button to do
that
Post by Paul Licameli
may be of help.
Perhaps I was mistaken, but I thought the Audacity clipboard was
held in RAM, just as a pointer to the data. Does the Audacity
clipboard take disk space?
My understanding is that no sample data are held in RAM but transiently for
purposes of playback or calculating display or computing effects. There is
much disk traffic all the time. There appear to be things in the code for
RAM caching of the block files but they are disabled. I don't know the
history.

(I implemented another level of caching to reduce some disk traffic for
purposes of scrubbing and zooming of spectrogram displays, but still this
cache persists only a short time.)

The block files are maintained by a "reference counting" mechanism -- I
don't know if you know what that means -- but the consequence is that you
might purge some Undo history, and yet, the clipboard could maintain
pointers that keep some of the block files containing samples alive,
delaying their deletion until either you cut or copy something else, or the
program exits.
Post by Paul Licameli
Post by Paul Licameli
If Gale is suggesting, against James, that we should not require the
user to
Post by Paul Licameli
restart, but it would be better to seek ways to let the program continue
after the user intervenes to reclaim disk space -- then I agree.
I can see a problem with restart, if the user can't save the project
or can't export because of lack of space. Won't that restart require
a force quit, if the user doesn't want to lose their changes?
Generally restart seems less good to me than letting the user
resume in Audacity once they have enough space. Perhaps
users may be less persuaded to free up space with Audacity
still open, but even with restart they could still run out of space
again so the restart would not seem to achieve anything from
that perspective. .
Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.
The last ideas are beyond the scope of what I am attempting now. I
understand that such anticipatory warnings might be a complementary effort
from Mark.

PRL
Post by Paul Licameli
Gale
Post by Paul Licameli
Post by Gale Andrews
When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar
with
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation on it,
which may fail at some point, the "strong" guarantee is that the
object
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
is
restored to its state as it was before attempting the operation. The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so
that
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might
fail
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier).
This
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or WaveClip,
I
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
think it looks like too much effort to make a strong guarantee: try
to
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial
results
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.
Recording should still be treated with some extra, special effort to save
as much of the data as possible.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2016-11-07 04:21:40 UTC
Permalink
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need to be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Exactly what I wanted to suggest. The means to do that already exists in
the History dialog.
Another place where excess disk usage may lurk is in the clipboard.
Less
likely to be a problem, but suppose you do a large cut rather than a delete.
Or suppose you do a large paste, and then apply an effect, so that the old
data pre-effect on the clipboard is not needed. Clearing undo history does
not reclaim that disk space in the clipboard. A special button to do that
may be of help.
Perhaps I was mistaken, but I thought the Audacity clipboard was
held in RAM, just as a pointer to the data. Does the Audacity
clipboard take disk space?
My understanding is that no sample data are held in RAM but transiently for
purposes of playback or calculating display or computing effects. There is
much disk traffic all the time. There appear to be things in the code for
RAM caching of the block files but they are disabled. I don't know the
history.
(I implemented another level of caching to reduce some disk traffic for
purposes of scrubbing and zooming of spectrogram displays, but still this
cache persists only a short time.)
The block files are maintained by a "reference counting" mechanism -- I
don't know if you know what that means -- but the consequence is that you
might purge some Undo history, and yet, the clipboard could maintain
pointers that keep some of the block files containing samples alive,
delaying their deletion until either you cut or copy something else, or the
program exits.
OK, thanks for the explanation. So when using the clipboard, the items
remaining in History may add up to less than the actual usage of the
AU files in the _data folder that you can see in the file manager.

If you copy all of the project, select some or all of the project, apply
an effect then discard one level, the disk space actually used does
not go down at all. But if you paste the clipboard, then History and
the file manager agree again about the space used.

So yes this seems a good point.


Gale
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
If Gale is suggesting, against James, that we should not require the user to
restart, but it would be better to seek ways to let the program continue
after the user intervenes to reclaim disk space -- then I agree.
I can see a problem with restart, if the user can't save the project
or can't export because of lack of space. Won't that restart require
a force quit, if the user doesn't want to lose their changes?
Generally restart seems less good to me than letting the user
resume in Audacity once they have enough space. Perhaps
users may be less persuaded to free up space with Audacity
still open, but even with restart they could still run out of space
again so the restart would not seem to achieve anything from
that perspective. .
Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.
The last ideas are beyond the scope of what I am attempting now. I
understand that such anticipatory warnings might be a complementary effort
from Mark.
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
Post by Gale Andrews
When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar with
such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation on
it,
which may fail at some point, the "strong" guarantee is that the object
is
restored to its state as it was before attempting the operation.
The
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier).
This
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or WaveClip, I
think it looks like too much effort to make a strong guarantee: try to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results
of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.
Recording should still be treated with some extra, special effort to save
as much of the data as possible.
PRL
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2016-11-07 15:16:46 UTC
Permalink
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need
to
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
be
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock out
further effects/edits/recording. Post error, the higher levels
only
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the
disk
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
might have enough room for. They should save if they can, free up some
disk space, restart and recover their unsaved project into freed
up
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Exactly what I wanted to suggest. The means to do that already exists in
the History dialog.
Another place where excess disk usage may lurk is in the clipboard.
Less
likely to be a problem, but suppose you do a large cut rather than a delete.
Or suppose you do a large paste, and then apply an effect, so that the old
data pre-effect on the clipboard is not needed. Clearing undo history does
not reclaim that disk space in the clipboard. A special button to do that
may be of help.
Perhaps I was mistaken, but I thought the Audacity clipboard was
held in RAM, just as a pointer to the data. Does the Audacity
clipboard take disk space?
My understanding is that no sample data are held in RAM but transiently
for
Post by Paul Licameli
purposes of playback or calculating display or computing effects. There
is
Post by Paul Licameli
much disk traffic all the time. There appear to be things in the code
for
Post by Paul Licameli
RAM caching of the block files but they are disabled. I don't know the
history.
(I implemented another level of caching to reduce some disk traffic for
purposes of scrubbing and zooming of spectrogram displays, but still this
cache persists only a short time.)
The block files are maintained by a "reference counting" mechanism -- I
don't know if you know what that means -- but the consequence is that you
might purge some Undo history, and yet, the clipboard could maintain
pointers that keep some of the block files containing samples alive,
delaying their deletion until either you cut or copy something else, or
the
Post by Paul Licameli
program exits.
OK, thanks for the explanation. So when using the clipboard, the items
remaining in History may add up to less than the actual usage of the
AU files in the _data folder that you can see in the file manager.
If you copy all of the project, select some or all of the project, apply
an effect then discard one level, the disk space actually used does
not go down at all. But if you paste the clipboard, then History and
the file manager agree again about the space used.
So yes this seems a good point.
Should the History dialog have another button to clear the clipboard? It
would make sense that the controls that can reclaim disk space should be
close together.

PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
If Gale is suggesting, against James, that we should not require the user to
restart, but it would be better to seek ways to let the program
continue
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
after the user intervenes to reclaim disk space -- then I agree.
I can see a problem with restart, if the user can't save the project
or can't export because of lack of space. Won't that restart require
a force quit, if the user doesn't want to lose their changes?
Generally restart seems less good to me than letting the user
resume in Audacity once they have enough space. Perhaps
users may be less persuaded to free up space with Audacity
still open, but even with restart they could still run out of space
again so the restart would not seem to achieve anything from
that perspective. .
Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.
The last ideas are beyond the scope of what I am attempting now. I
understand that such anticipatory warnings might be a complementary
effort
Post by Paul Licameli
from Mark.
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
Post by Gale Andrews
When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data
to
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar with
such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation on
it,
which may fail at some point, the "strong" guarantee is that the object
is
restored to its state as it was before attempting the operation.
The
"weak" guarantee is only that the object is left in some
unspecified
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
but
consistent state, satisfying its "class-invariant" conditions, so that
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might fail
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier).
This
works by restoring the last state saved in Undo history, without
completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or
WaveClip,
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
I
try
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
to
ensure only the weak guarantee. Using RollbackState will destroy the
WaveTrack and WaveClip and Sequence objects holding the partial results
of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then
the
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
user
can go free resources and try again.
Recording should still be treated with some extra, special effort
to
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
save
as much of the data as possible.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
James Crook
2016-11-07 16:00:06 UTC
Permalink
Post by Paul Licameli
Should the History dialog have another button to clear the clipboard? It
would make sense that the controls that can reclaim disk space should be
close together.
PRL
If you want to put it there I'm fine with that. It's non essential to
the 437 fix.

Another approach is that just as 'Cut' adds 'Cut to the clipboard' to
history, 'Copy' could add 'Copy to the clipboard'. We then clear up the
clipboard when we discard the Cut/Copy from History. It saves a
button. After all the clipboard data and the data maintained in history
in the 'Cut' case are the same data, and shared, so deleting one without
the other does not save space.

I do think the clipboard is a bit of a red herring. I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.

--James.
Peter Sampson
2016-11-07 16:16:30 UTC
Permalink
... I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.
I don't think, James, that you should be worried about too many ballooning
GUI changes.

There are a few critical commands that really are deserving of the
high-level
GUI trap of which Recording remains the most egregious and the Save
commands probably run it a close second.

And with recording it is important that we test for remaining disk space
regularly
as, has already been pointed out, other apps and opeartions on the computur
may be simultaneously eating up disk space.

We could also make a good case for covering Import and Export at the
high-level GUI trap - but these would be scondary imo.

But all the numerous Effects, Generators and Analyzers should be capable
of being dealt with by the proposed low-level trap, along with most other
commands.

Peter
Gale Andrews
2016-11-07 21:10:46 UTC
Permalink
IMO, all cases where the project can get damaged by running out
of disk space are important. As things are now, a recording made
with sufficient space available "can" get corrupted by subsequently
importing a file or subsequently generating audio without enough
space available.

Remember too that some users have workflows that delete their files
after importing them.


Gale


On 7 November 2016 at 16:16, Peter Sampson
Post by Peter Sampson
... I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.
I don't think, James, that you should be worried about too many ballooning
GUI changes.
There are a few critical commands that really are deserving of the
high-level
GUI trap of which Recording remains the most egregious and the Save
commands probably run it a close second.
And with recording it is important that we test for remaining disk space
regularly
as, has already been pointed out, other apps and opeartions on the computur
may be simultaneously eating up disk space.
We could also make a good case for covering Import and Export at the
high-level GUI trap - but these would be scondary imo.
But all the numerous Effects, Generators and Analyzers should be capable
of being dealt with by the proposed low-level trap, along with most other
commands.
Peter
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2016-11-07 21:13:12 UTC
Permalink
On Mon, Nov 7, 2016 at 11:16 AM, Peter Sampson <
Post by Peter Sampson
... I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.
I don't think, James, that you should be worried about too many ballooning
GUI changes.
There are a few critical commands that really are deserving of the
high-level
GUI trap of which Recording remains the most egregious and the Save
commands probably run it a close second.
And with recording it is important that we test for remaining disk space
regularly
as, has already been pointed out, other apps and opeartions on the computur
may be simultaneously eating up disk space.
We could also make a good case for covering Import and Export at the
high-level GUI trap - but these would be scondary imo.
But all the numerous Effects, Generators and Analyzers should be capable
of being dealt with by the proposed low-level trap, along with most other
commands.
Peter, I don't know what a "low level trap" is. The problem is detection
of the problem at "low" levels of code, and handling of the problem at
appropriate "high" levels. The "low" level can be reached from many
different "high" starting points, and when you are there, you don't know
which place you came from. If I code the recording case the easy, the
problem is that I must catch the problem at some "high" place on each
possible path -- or else, what was a problem of a corrupted project instead
becomes a crash of the program on those paths.

So, I don't think I can just ignore these other cases. There should not be
many places where I must catch what is thrown, but it takes some effort to
identify what those places are.

PRL
Post by Peter Sampson
Peter
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2016-11-07 23:49:54 UTC
Permalink
Post by Paul Licameli
Peter, I don't know what a "low level trap" is.
what I mean by a "low level trap" is a trap in the code that after a user
has issued a command and Audacity starts working on it, the app detects
that a write is going to fail and then stops that happebning and instead
fails the app gracefully and in a way that is meaningful and informative to
the user.

In contrast a high-level trap will stop the user from effecting the command
in the first place when it believes that there is likely to be insufficient
space
and inform the user in a meaningful and helpful way.

Peter
Post by Paul Licameli
On Mon, Nov 7, 2016 at 11:16 AM, Peter Sampson <
Post by Peter Sampson
... I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.
I don't think, James, that you should be worried about too many ballooning
GUI changes.
There are a few critical commands that really are deserving of the
high-level
GUI trap of which Recording remains the most egregious and the Save
commands probably run it a close second.
And with recording it is important that we test for remaining disk space
regularly
as, has already been pointed out, other apps and opeartions on the computur
may be simultaneously eating up disk space.
We could also make a good case for covering Import and Export at the
high-level GUI trap - but these would be scondary imo.
But all the numerous Effects, Generators and Analyzers should be capable
of being dealt with by the proposed low-level trap, along with most other
commands.
Peter, I don't know what a "low level trap" is. The problem is detection
of the problem at "low" levels of code, and handling of the problem at
appropriate "high" levels. The "low" level can be reached from many
different "high" starting points, and when you are there, you don't know
which place you came from. If I code the recording case the easy, the
problem is that I must catch the problem at some "high" place on each
possible path -- or else, what was a problem of a corrupted project instead
becomes a crash of the program on those paths.
So, I don't think I can just ignore these other cases. There should not
be many places where I must catch what is thrown, but it takes some effort
to identify what those places are.
PRL
Post by Peter Sampson
Peter
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2016-11-07 16:19:23 UTC
Permalink
Post by James Crook
Post by Paul Licameli
Should the History dialog have another button to clear the clipboard? It
would make sense that the controls that can reclaim disk space should be
close together.
PRL
If you want to put it there I'm fine with that. It's non essential to
the 437 fix.
Another approach is that just as 'Cut' adds 'Cut to the clipboard' to
history, 'Copy' could add 'Copy to the clipboard'. We then clear up the
clipboard when we discard the Cut/Copy from History. It saves a
button. After all the clipboard data and the data maintained in history
in the 'Cut' case are the same data, and shared, so deleting one without
the other does not save space.
I do think the clipboard is a bit of a red herring. I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.
That little kipper is just one morning's breakfast for me. I have written
it mostly since the last email.

The difficulties of doing error handling right are inherent. It really is
tough to communicate between a deeply nested error detection and an
appropriate high level catch and have proper recoveries in between.

PRL
Post by James Crook
--James.
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2016-11-07 21:01:40 UTC
Permalink
I think it's OK as Paul has done it with a new button. It saves an
extra item to navigate in the Undo Stack. Also it lets user keep
the copied data even after undoing an effect that may have
included the data.


Gale
Post by James Crook
Post by Paul Licameli
Should the History dialog have another button to clear the clipboard? It
would make sense that the controls that can reclaim disk space should be
close together.
PRL
If you want to put it there I'm fine with that. It's non essential to
the 437 fix.
Another approach is that just as 'Cut' adds 'Cut to the clipboard' to
history, 'Copy' could add 'Copy to the clipboard'. We then clear up the
clipboard when we discard the Cut/Copy from History. It saves a
button. After all the clipboard data and the data maintained in history
in the 'Cut' case are the same data, and shared, so deleting one without
the other does not save space.
I do think the clipboard is a bit of a red herring. I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.
--James.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2016-11-07 21:59:17 UTC
Permalink
Post by Gale Andrews
I think it's OK as Paul has done it with a new button. It saves an
extra item to navigate in the Undo Stack. Also it lets user keep
the copied data even after undoing an effect that may have
included the data.
I don't understand what James was trying to say earlier about copy and
paste, and I do not know what extra navigation Gale means here. But it is
correct that the clipboard and the undo stack vary independently.

I examined the code and decided that the calculation of space usage wasn't
right, so I have changed it at 4ec7044639f7ebceac59d5bdfa75f749c00f59be

If a block file is used in more than one undo history state (as when you
cut or copy and then paste), it will surely be counted once only now, and
in the last state containing it, because you don't reclaim its space until
you delete that state (and necessarily all earlier ones). So the numbers
in the dialog really tell you how much disk you reclaim by deleting that
state.

But that is, assuming that the block files are not also used by the
clipboard. There may still be double-counting between clipboard and undo
history. That must be so if you can reclaim either one independently.

The new, correct counting of history can have an odd effect. Try this,
with the history dialog open: Generate 1 minute of noise. Select all and
cut. -- the last two states show about 10 MB and zero.

Now paste. The 10 MB are now imputed to the new state, but the older state
drops to zero. That is correct as I have explained, though it may look
strange.

Another thing about the new button -- the clipboard is really global, not
peculiar to one project, so if you should have two Audacity projects open,
and open the history for each, then the same clipboard space usage is
reflected in each.

PRL
Post by Gale Andrews
Gale
Post by James Crook
Post by Paul Licameli
Should the History dialog have another button to clear the clipboard?
It
Post by James Crook
Post by Paul Licameli
would make sense that the controls that can reclaim disk space should be
close together.
PRL
If you want to put it there I'm fine with that. It's non essential to
the 437 fix.
Another approach is that just as 'Cut' adds 'Cut to the clipboard' to
history, 'Copy' could add 'Copy to the clipboard'. We then clear up the
clipboard when we discard the Cut/Copy from History. It saves a
button. After all the clipboard data and the data maintained in history
in the 'Cut' case are the same data, and shared, so deleting one without
the other does not save space.
I do think the clipboard is a bit of a red herring. I'm worried about
the 437 project ballooning into lots of nice to haves, more systematic
sweeps, and many GUI changes.
--James.
------------------------------------------------------------
------------------
Post by James Crook
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
James Crook
2016-11-07 23:09:17 UTC
Permalink
Post by Paul Licameli
Post by Gale Andrews
I think it's OK as Paul has done it with a new button. It saves an
extra item to navigate in the Undo Stack. Also it lets user keep
the copied data even after undoing an effect that may have
included the data.
I don't understand what James was trying to say earlier about copy and
paste, and I do not know what extra navigation Gale means here. But it is
correct that the clipboard and the undo stack vary independently.
I examined the code and decided that the calculation of space usage wasn't
right, so I have changed it at 4ec7044639f7ebceac59d5bdfa75f749c00f59be
If a block file is used in more than one undo history state (as when you
cut or copy and then paste), it will surely be counted once only now, and
in the last state containing it, because you don't reclaim its space until
you delete that state (and necessarily all earlier ones). So the numbers
in the dialog really tell you how much disk you reclaim by deleting that
state.
But that is, assuming that the block files are not also used by the
clipboard. There may still be double-counting between clipboard and undo
history. That must be so if you can reclaim either one independently.
That was essentially my point. You don't regain the disk space unless
you free the clipboard AND the history item, because the history item
and clipboard reference the same blockfiles. So separately discarding
does not really gain a lot, and does make the GUI more complex. Sure,
my way would mean that deleting history that included the creation of
clipboard would 'silently' erase the clipboard too when you discard the
cut or copy from history. So some argument can be made that separate
discards have a value and justify the more complex GUI.
Post by Paul Licameli
The new, correct counting of history can have an odd effect. Try this,
with the history dialog open: Generate 1 minute of noise. Select all and
cut. -- the last two states show about 10 MB and zero.
Now paste. The 10 MB are now imputed to the new state, but the older state
drops to zero. That is correct as I have explained, though it may look
strange.
Another thing about the new button -- the clipboard is really global, not
peculiar to one project, so if you should have two Audacity projects open,
and open the history for each, then the same clipboard space usage is
reflected in each.
PRL
Peter Sampson
2016-11-07 13:06:00 UTC
Permalink
Post by Gale Andrews
Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.
I understand that such anticipatory warnings might be a complementary
effort from Mark.

Yes that's my understanding too Paul.

*@Mark:* do you still have that patch around which you had working for the
warning of impending disk over-run while recording? If so it might be
useful
to dig it out again and let folk test it out - it could be a useful initial
fix for
2.1.3 as it is now - leaving us (you probably) to handle the generalization
later.
Just this fix would enable us to reme the Wikipedia black/gray mark against
Audacity.

With the work that Paul is now planning to do with the low-level capture and
safer more graceful degradation the are likely to be far fewer places where
we need to make the effort of an up-front user warning of potential disk
over-run.

As James has pointed out we probaly don't need to do it for the many
effects,
generators and analyzers - but I think we may need it for the Save commands
and for Import and Export.

Peter
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need to
be
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock
out
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up
some
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Exactly what I wanted to suggest. The means to do that already exists
in
Post by Paul Licameli
the History dialog.
Another place where excess disk usage may lurk is in the clipboard.
Less
Post by Paul Licameli
likely to be a problem, but suppose you do a large cut rather than a
delete.
Post by Paul Licameli
Or suppose you do a large paste, and then apply an effect, so that the
old
Post by Paul Licameli
data pre-effect on the clipboard is not needed. Clearing undo history
does
Post by Paul Licameli
not reclaim that disk space in the clipboard. A special button to do
that
Post by Paul Licameli
may be of help.
Perhaps I was mistaken, but I thought the Audacity clipboard was
held in RAM, just as a pointer to the data. Does the Audacity
clipboard take disk space?
My understanding is that no sample data are held in RAM but transiently
for purposes of playback or calculating display or computing effects.
There is much disk traffic all the time. There appear to be things in the
code for RAM caching of the block files but they are disabled. I don't
know the history.
(I implemented another level of caching to reduce some disk traffic for
purposes of scrubbing and zooming of spectrogram displays, but still this
cache persists only a short time.)
The block files are maintained by a "reference counting" mechanism -- I
don't know if you know what that means -- but the consequence is that you
might purge some Undo history, and yet, the clipboard could maintain
pointers that keep some of the block files containing samples alive,
delaying their deletion until either you cut or copy something else, or the
program exits.
Post by Gale Andrews
Post by Paul Licameli
If Gale is suggesting, against James, that we should not require the
user to
Post by Paul Licameli
restart, but it would be better to seek ways to let the program continue
after the user intervenes to reclaim disk space -- then I agree.
I can see a problem with restart, if the user can't save the project
or can't export because of lack of space. Won't that restart require
a force quit, if the user doesn't want to lose their changes?
Generally restart seems less good to me than letting the user
resume in Audacity once they have enough space. Perhaps
users may be less persuaded to free up space with Audacity
still open, but even with restart they could still run out of space
again so the restart would not seem to achieve anything from
that perspective. .
Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.
The last ideas are beyond the scope of what I am attempting now. I
understand that such anticipatory warnings might be a complementary effort
from Mark.
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
Post by Gale Andrews
When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar
with
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation
on
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
it,
which may fail at some point, the "strong" guarantee is that the
object
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
is
restored to its state as it was before attempting the operation.
The
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
"weak" guarantee is only that the object is left in some unspecified but
consistent state, satisfying its "class-invariant" conditions, so
that
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might
fail
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier).
This
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or
WaveClip, I
try to
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
ensure only the weak guarantee. Using RollbackState will destroy
the
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
WaveTrack and WaveClip and Sequence objects holding the partial
results
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then the user
can go free resources and try again.
Recording should still be treated with some extra, special effort to save
as much of the data as possible.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
James Crook
2016-11-07 14:16:09 UTC
Permalink
the warning of impending disk over-run while recording? If so it might
be useful to dig it out again and let folk test it out - it could be a
useful initial fix for 2.1.3 as it is now - leaving us (you probably)
to handle the generalization later.
Just this fix would enable us to reme the Wikipedia black/gray mark against Audacity.
No, it would not allow us to remove the Wikpedia black mark.

Audacity is not the only thing that can use disk space. I could be
recording and downloading the box set of Game of Thrones in the
background, and run out of disk space during recording.

The initial fix is to deal with the write failing. Ideas such as a
monitoring space at regular intervals and displaying a dynamic disk
space monitor are cool and all, but I think it's late in 2.1.3 to be
adding them too. We really need to deal with the must-fix part.

--James.
Mark Young
2016-11-07 14:00:42 UTC
Permalink
Hi, I still have a couple of branches where I was working on fixes here...

I will have a dig out tonight/tomorrow and see what I can offer.

Unfortunately I have not had as much time as I would have liked to spend on
Audacity but hope to change that in the near future.
Post by Peter Sampson
Post by Gale Andrews
Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.
I understand that such anticipatory warnings might be a complementary
effort from Mark.
Yes that's my understanding too Paul.
warning of impending disk over-run while recording? If so it might be
useful
to dig it out again and let folk test it out - it could be a useful
initial fix for
2.1.3 as it is now - leaving us (you probably) to handle the
generalization later.
Just this fix would enable us to reme the Wikipedia black/gray mark against
Audacity.
With the work that Paul is now planning to do with the low-level capture and
safer more graceful degradation the are likely to be far fewer places where
we need to make the effort of an up-front user warning of potential disk
over-run.
As James has pointed out we probaly don't need to do it for the many
effects,
generators and analyzers - but I think we may need it for the Save commands
and for Import and Export.
Peter
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
That sounds right to me Paul.
I think the 'strong' guarantees at the higher levels may not need
to be
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
guaranteeing very much.
It's the project state on disk that we need the guarantee about. In
extremis, we can abort Audacity and rely on Audacity picking up the
pieces when you restart it...
If we hit an out of disk space, my view is that we can/should lock
out
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
further effects/edits/recording. Post error, the higher levels only
need to support that recovery mode. I don't think it is prudent to
encourage the user to continue with ever smaller edits that the disk
might have enough room for. They should save if they can, free up
some
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
disk space, restart and recover their unsaved project into freed up
space, if they could not save at the time of error.
What would free the "lock" on user consuming more disk space -
restarting Audacity?
It could perhaps be legitimate to offer user the chance to remove
undo levels in History to free up space.
Exactly what I wanted to suggest. The means to do that already exists
in
Post by Paul Licameli
the History dialog.
Another place where excess disk usage may lurk is in the clipboard.
Less
Post by Paul Licameli
likely to be a problem, but suppose you do a large cut rather than a
delete.
Post by Paul Licameli
Or suppose you do a large paste, and then apply an effect, so that the
old
Post by Paul Licameli
data pre-effect on the clipboard is not needed. Clearing undo history
does
Post by Paul Licameli
not reclaim that disk space in the clipboard. A special button to do
that
Post by Paul Licameli
may be of help.
Perhaps I was mistaken, but I thought the Audacity clipboard was
held in RAM, just as a pointer to the data. Does the Audacity
clipboard take disk space?
My understanding is that no sample data are held in RAM but transiently
for purposes of playback or calculating display or computing effects.
There is much disk traffic all the time. There appear to be things in the
code for RAM caching of the block files but they are disabled. I don't
know the history.
(I implemented another level of caching to reduce some disk traffic for
purposes of scrubbing and zooming of spectrogram displays, but still this
cache persists only a short time.)
The block files are maintained by a "reference counting" mechanism -- I
don't know if you know what that means -- but the consequence is that you
might purge some Undo history, and yet, the clipboard could maintain
pointers that keep some of the block files containing samples alive,
delaying their deletion until either you cut or copy something else, or the
program exits.
Post by Gale Andrews
Post by Paul Licameli
If Gale is suggesting, against James, that we should not require the
user to
Post by Paul Licameli
restart, but it would be better to seek ways to let the program
continue
Post by Paul Licameli
after the user intervenes to reclaim disk space -- then I agree.
I can see a problem with restart, if the user can't save the project
or can't export because of lack of space. Won't that restart require
a force quit, if the user doesn't want to lose their changes?
Generally restart seems less good to me than letting the user
resume in Audacity once they have enough space. Perhaps
users may be less persuaded to free up space with Audacity
still open, but even with restart they could still run out of space
again so the restart would not seem to achieve anything from
that perspective. .
Is there any value in displaying live disk space remaining when
it gets below a certain threshold? We could do so once a
write error has occurred in the session. Showing the space
remaining could let the user take action before the write error
occurs.
The last ideas are beyond the scope of what I am attempting now. I
understand that such anticipatory warnings might be a complementary effort
from Mark.
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
Post by Gale Andrews
When saving a project for the first time, does Audacity delete the AU
files not required for the state being saved before moving the data to
the _data folder? As I just pointed out elsewhere, Windows can use
some additional disk space while in the process of moving files.
Gale
Post by James Crook
Post by Paul Licameli
Strong and Weak exception safety guarantees. Are we all familiar
with
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
such
C++ jargon?
This is pertinent to the discussion of Bug 437, and the careful, thorough
ways of fixing it.
If you have some object, and do a complicated multi-part operation
on
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
it,
which may fail at some point, the "strong" guarantee is that the
object
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
is
restored to its state as it was before attempting the operation.
The
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
"weak" guarantee is only that the object is left in some
unspecified
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
but
consistent state, satisfying its "class-invariant" conditions, so
that
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
further operations on it do not lead to undefined behavior.
I think that to fix Bug 437, for all editing operations that might
fail
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
because of exhaustion of disk space, and without too many error-handling
catch blocks, we might easily provide a strong guarantee by using
Project::RollbackState (something I had occasion to add earlier).
This
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
works by restoring the last state saved in Undo history, without completing
the (failed) operation and pushing a new state.
At lower levels than the Project, such as the WaveTrack or
WaveClip, I
try to
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
ensure only the weak guarantee. Using RollbackState will destroy
the
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
WaveTrack and WaveClip and Sequence objects holding the partial
results
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
of
the failed operation.
This assumes most editing operations that could exhaust memory (I include
effects and generators) can acceptably just be aborted, and then
the
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
user
can go free resources and try again.
Recording should still be treated with some extra, special effort
to
Post by Paul Licameli
Post by Gale Andrews
Post by James Crook
Post by Paul Licameli
save
as much of the data as possible.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...