Quantcast

Branch bug1567-tidy

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Branch bug1567-tidy

Paul Licameli

I intend this branch in my fork to be the one ultimately merged into master, but not yet.

"Fetch" again (don't "pull") in case I update it again.

I squashed all into one commit and added a run time check that the operating system is Sierra or later; else, don't fork and crash.  (But still do the execve in main() that Leland put there for other reasons.)

There is also a one second sleep in Project.cpp when closing a file, but the usefulness of that is not yet proven, and that part may be removed later.

It applies the fix in release builds only.  If you want to do that in a debug build, find this in AudacityApp.h, and remove the #if and #endif lines:

   #if ! defined(__WXDEBUG__)

   #define FIX_BUG1567

   #endif



Please verify that this is still as good a fix as any so far.

PRL


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Gale
Administrator
Hi Paul,

The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.

The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving.  With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).

Recording in another window while closing without saving still prevents
the bug occurring.

The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.

Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines -  but it looks like debug is not
a sufficient or reliable panacea.

Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.

I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.

But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.


Gale


On 22 January 2017 at 02:38, Paul Licameli <[hidden email]> wrote:

> https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>
> I intend this branch in my fork to be the one ultimately merged into master,
> but not yet.
>
> "Fetch" again (don't "pull") in case I update it again.
>
> I squashed all into one commit and added a run time check that the operating
> system is Sierra or later; else, don't fork and crash.  (But still do the
> execve in main() that Leland put there for other reasons.)
>
> There is also a one second sleep in Project.cpp when closing a file, but the
> usefulness of that is not yet proven, and that part may be removed later.
>
> It applies the fix in release builds only.  If you want to do that in a
> debug build, find this in AudacityApp.h, and remove the #if and #endif
> lines:
>
>    #if ! defined(__WXDEBUG__)
>
>    #define FIX_BUG1567
>
>    #endif
>
>
>
> Please verify that this is still as good a fix as any so far.
>
> PRL
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Paul Licameli


On Sun, Jan 22, 2017 at 7:27 PM, Gale Andrews <[hidden email]> wrote:
Hi Paul,

The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.


On my Mac, running El Capitan, I see the icon jump once only at startup, whether running a 2.1.2 download or my release build of bug1567-tidy.
 
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving.  With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).

Recording in another window while closing without saving still prevents
the bug occurring.

Somehow I missed the earlier reports of this observation.  This is a strange datum.  Somehow more traffic in the temp directory stops the bug?
 

The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.

Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines -  but it looks like debug is not
a sufficient or reliable panacea.

Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.

I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.

If I remove audacity.cfg, then the default in directory preferences is: /Users/paullicameli/Library/Application Support/audacity/SessionData

Was that (substituting your user name) not your temporary directory to begin with?  If not then what?

I was speculating that there is something about the ~/Library directory that is special, and that you should try changing your temp directory to something not under it, like simply /tmp
 

But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.

That entry in the bug database is puzzling.  There is no fix of it yet, and no comments on it besides yours.  You say there is a difference of behavior, in removal of temporary sub-folders, depending on operating system, but not on Audacity version?

I observe that the sub-folders are removed on my El Capitan.

PRL 
 


Gale


On 22 January 2017 at 02:38, Paul Licameli <[hidden email]> wrote:
> https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>
> I intend this branch in my fork to be the one ultimately merged into master,
> but not yet.
>
> "Fetch" again (don't "pull") in case I update it again.
>
> I squashed all into one commit and added a run time check that the operating
> system is Sierra or later; else, don't fork and crash.  (But still do the
> execve in main() that Leland put there for other reasons.)
>
> There is also a one second sleep in Project.cpp when closing a file, but the
> usefulness of that is not yet proven, and that part may be removed later.
>
> It applies the fix in release builds only.  If you want to do that in a
> debug build, find this in AudacityApp.h, and remove the #if and #endif
> lines:
>
>    #if ! defined(__WXDEBUG__)
>
>    #define FIX_BUG1567
>
>    #endif
>
>
>
> Please verify that this is still as good a fix as any so far.
>
> PRL
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Paul Licameli


On Sun, Jan 22, 2017 at 8:25 PM, Paul Licameli <[hidden email]> wrote:


On Sun, Jan 22, 2017 at 7:27 PM, Gale Andrews <[hidden email]> wrote:
Hi Paul,

The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.


On my Mac, running El Capitan, I see the icon jump once only at startup, whether running a 2.1.2 download or my release build of bug1567-tidy.
 
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving.  With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).

Recording in another window while closing without saving still prevents
the bug occurring.

Somehow I missed the earlier reports of this observation.  This is a strange datum.  Somehow more traffic in the temp directory stops the bug?
 

The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.

Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines -  but it looks like debug is not
a sufficient or reliable panacea.

Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.

I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.

If I remove audacity.cfg, then the default in directory preferences is: /Users/paullicameli/Library/Application Support/audacity/SessionData

Was that (substituting your user name) not your temporary directory to begin with?  If not then what?

I was speculating that there is something about the ~/Library directory that is special, and that you should try changing your temp directory to something not under it, like simply /tmp
 

But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.

That entry in the bug database is puzzling.  There is no fix of it yet, and no comments on it besides yours.  You say there is a difference of behavior, in removal of temporary sub-folders, depending on operating system, but not on Audacity version?

I observe that the sub-folders are removed on my El Capitan.

PRL 

More about this clue:

I observe that ~DirManager calls DirectoryManager::CleanTempDir which calls RecursivelyRemove() which cleans up by first attempting to delete each file or directory AS A FILE, and then again AS A DIRECTORY, but ignoring error codes.

On my El Capitan, when closing a project without saving, this routinely makes errors in the log file, in either a debug or a release build, that the subdirectories could not be remove (as files), though the eventual attempt to delete them as folders works.

Your computer has some timing-dependent difference of behavior, who knows why.

This suggests to me that a rewrite that carefully removes files as files (only) and directories as directories (only) might fix this problem.

Presumably, this would still be an independent problem; both this fix and the fork and crash fix would be necessary.

PRL

 
 


Gale


On 22 January 2017 at 02:38, Paul Licameli <[hidden email]> wrote:
> https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>
> I intend this branch in my fork to be the one ultimately merged into master,
> but not yet.
>
> "Fetch" again (don't "pull") in case I update it again.
>
> I squashed all into one commit and added a run time check that the operating
> system is Sierra or later; else, don't fork and crash.  (But still do the
> execve in main() that Leland put there for other reasons.)
>
> There is also a one second sleep in Project.cpp when closing a file, but the
> usefulness of that is not yet proven, and that part may be removed later.
>
> It applies the fix in release builds only.  If you want to do that in a
> debug build, find this in AudacityApp.h, and remove the #if and #endif
> lines:
>
>    #if ! defined(__WXDEBUG__)
>
>    #define FIX_BUG1567
>
>    #endif
>
>
>
> Please verify that this is still as good a fix as any so far.
>
> PRL
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Paul Licameli
Gale, try it again with this commit, which may incidentally fix bug 1521, and prevent the spurious messages in the log files:


Do I understand correctly that the problem with closing without save occurs only when closing the last remaining project window?  (But not necessarily quitting the application).  It does not happen when you close one of two projects?  If so, that is consistent with the problem I am fixing.

PRL


On Sun, Jan 22, 2017 at 8:45 PM, Paul Licameli <[hidden email]> wrote:


On Sun, Jan 22, 2017 at 8:25 PM, Paul Licameli <[hidden email]> wrote:


On Sun, Jan 22, 2017 at 7:27 PM, Gale Andrews <[hidden email]> wrote:
Hi Paul,

The bug1567-tidy release configuration starts up well with splash screen
and comes on top - just the weird double bounce in the Dock to be noted
as before.


On my Mac, running El Capitan, I see the icon jump once only at startup, whether running a 2.1.2 download or my release build of bug1567-tidy.
 
The 1000 ms sleep after destroying the block files doesn't seem to do
much for stopping bug 1567 recurring - I got it every three or four closes
without saving.  With 10000 ms sleep it still happens about one time in
10 (which is too long a sleep I figure).

Recording in another window while closing without saving still prevents
the bug occurring.

Somehow I missed the earlier reports of this observation.  This is a strange datum.  Somehow more traffic in the temp directory stops the bug?
 

The bug1567-tidy modified to run as debug triggers 1567 on close without
save about one time in five with 1000 ms sleep. It has not triggered yet in
20 tries with 5000 ms sleep.

Weird2 rebuilt unmodified in debug so with the fork and crash fix turned off
does today sometimes launch with 1567 present, and close without save
does sometimes bring 1567 back. Not sure why I got so much better results
yesterday - I had not messed up the defines -  but it looks like debug is not
a sufficient or reliable panacea.

Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
most of the time.

I tried moving the Audacity temp dir to
/Users/gale/Library/Audacity/SessionData/
(seemed not an unreasonable place) but the bug occurred again after a few
closes without saving. Of course I could not move the entire configuration
directory.

If I remove audacity.cfg, then the default in directory preferences is: /Users/paullicameli/Library/Application Support/audacity/SessionData

Was that (substituting your user name) not your temporary directory to begin with?  If not then what?

I was speculating that there is something about the ~/Library directory that is special, and that you should try changing your temp directory to something not under it, like simply /tmp
 

But this just might be something. Bug 1521
http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
leaves old, emptied project folders behind in the temp folder. If I manually
delete the last project* folder left behind after the File > Close, 1567 doesn't
seem to trigger, even if I remove the sleep after destroying the block files.
I did 18 tries so far without the bug coming back.

That entry in the bug database is puzzling.  There is no fix of it yet, and no comments on it besides yours.  You say there is a difference of behavior, in removal of temporary sub-folders, depending on operating system, but not on Audacity version?

I observe that the sub-folders are removed on my El Capitan.

PRL 

More about this clue:

I observe that ~DirManager calls DirectoryManager::CleanTempDir which calls RecursivelyRemove() which cleans up by first attempting to delete each file or directory AS A FILE, and then again AS A DIRECTORY, but ignoring error codes.

On my El Capitan, when closing a project without saving, this routinely makes errors in the log file, in either a debug or a release build, that the subdirectories could not be remove (as files), though the eventual attempt to delete them as folders works.

Your computer has some timing-dependent difference of behavior, who knows why.

This suggests to me that a rewrite that carefully removes files as files (only) and directories as directories (only) might fix this problem.

Presumably, this would still be an independent problem; both this fix and the fork and crash fix would be necessary.

PRL

 
 


Gale


On 22 January 2017 at 02:38, Paul Licameli <[hidden email]> wrote:
> https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>
> I intend this branch in my fork to be the one ultimately merged into master,
> but not yet.
>
> "Fetch" again (don't "pull") in case I update it again.
>
> I squashed all into one commit and added a run time check that the operating
> system is Sierra or later; else, don't fork and crash.  (But still do the
> execve in main() that Leland put there for other reasons.)
>
> There is also a one second sleep in Project.cpp when closing a file, but the
> usefulness of that is not yet proven, and that part may be removed later.
>
> It applies the fix in release builds only.  If you want to do that in a
> debug build, find this in AudacityApp.h, and remove the #if and #endif
> lines:
>
>    #if ! defined(__WXDEBUG__)
>
>    #define FIX_BUG1567
>
>    #endif
>
>
>
> Please verify that this is still as good a fix as any so far.
>
> PRL
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Gale
Administrator
In reply to this post by Paul Licameli
On 23 January 2017 at 01:25, Paul Licameli <[hidden email]> wrote:

>
>
> On Sun, Jan 22, 2017 at 7:27 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Hi Paul,
>>
>> The bug1567-tidy release configuration starts up well with splash screen
>> and comes on top - just the weird double bounce in the Dock to be noted
>> as before.
>>
>
> On my Mac, running El Capitan, I see the icon jump once only at startup,
> whether running a 2.1.2 download or my release build of bug1567-tidy.

Presumably because it is El Capitan, the crash fix on launch is not being
applied?


>> The 1000 ms sleep after destroying the block files doesn't seem to do
>> much for stopping bug 1567 recurring - I got it every three or four closes
>> without saving.  With 10000 ms sleep it still happens about one time in
>> 10 (which is too long a sleep I figure).
>>
>> Recording in another window while closing without saving still prevents
>> the bug occurring.
>
>
> Somehow I missed the earlier reports of this observation.  This is a strange
> datum.  Somehow more traffic in the temp directory stops the bug?
>
>>
>>
>> The bug1567-tidy modified to run as debug triggers 1567 on close without
>> save about one time in five with 1000 ms sleep. It has not triggered yet
>> in
>> 20 tries with 5000 ms sleep.
>>
>> Weird2 rebuilt unmodified in debug so with the fork and crash fix turned
>> off
>> does today sometimes launch with 1567 present, and close without save
>> does sometimes bring 1567 back. Not sure why I got so much better results
>> yesterday - I had not messed up the defines -  but it looks like debug is
>> not
>> a sufficient or reliable panacea.
>>
>> Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
>> most of the time.
>>
>> I tried moving the Audacity temp dir to
>> /Users/gale/Library/Audacity/SessionData/
>> (seemed not an unreasonable place) but the bug occurred again after a few
>> closes without saving. Of course I could not move the entire configuration
>> directory.
>
>
> If I remove audacity.cfg, then the default in directory preferences is:
> /Users/paullicameli/Library/Application Support/audacity/SessionData
>
> Was that (substituting your user name) not your temporary directory to begin
> with?  If not then what?

 /Users/gale/Library/Application Support/audacity/SessionData is my default
if I delete audacity.cfg, yes. I just did a blind experiment with
/Users/gale/Library/Audacity/SessionData/ .


> I was speculating that there is something about the ~/Library directory that
> is special, and that you should try changing your temp directory to
> something not under it, like simply /tmp

I didn't recall that is what you wrote. And we must be sure the files
survive reboot if Audacity crashes.

Anyway, on a quick try with /tmp/audacity-gale/SessionData, I can
still get 1567 on File > Close with no save.


>> But this just might be something. Bug 1521
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
>> leaves old, emptied project folders behind in the temp folder. If I
>> manually
>> delete the last project* folder left behind after the File > Close, 1567
>> doesn't
>> seem to trigger, even if I remove the sleep after destroying the block
>> files.
>> I did 18 tries so far without the bug coming back.
>
>
> That entry in the bug database is puzzling.  There is no fix of it yet, and
> no comments on it besides yours.  You say there is a difference of behavior,
> in removal of temporary sub-folders, depending on operating system, but not
> on Audacity version?

Yes, on my machine. I am very confident of that.


> I observe that the sub-folders are removed on my El Capitan.

Then I am kind of guessing that will be so with Peter and Cliff on
Sierra, and this is another "machine too slow" issue. This is mine
- 2.3 GHz HDD and 4 GB RAM:
http://www.everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i5-2.3-mid-2011-specs.html
.

It is puzzling why leaving old folders behind is OK when another
project is doing something, but not otherwise.



Gale

>>
>>
>> On 22 January 2017 at 02:38, Paul Licameli <[hidden email]>
>> wrote:
>> >
>> > https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>> >
>> > I intend this branch in my fork to be the one ultimately merged into
>> > master,
>> > but not yet.
>> >
>> > "Fetch" again (don't "pull") in case I update it again.
>> >
>> > I squashed all into one commit and added a run time check that the
>> > operating
>> > system is Sierra or later; else, don't fork and crash.  (But still do
>> > the
>> > execve in main() that Leland put there for other reasons.)
>> >
>> > There is also a one second sleep in Project.cpp when closing a file, but
>> > the
>> > usefulness of that is not yet proven, and that part may be removed
>> > later.
>> >
>> > It applies the fix in release builds only.  If you want to do that in a
>> > debug build, find this in AudacityApp.h, and remove the #if and #endif
>> > lines:
>> >
>> >    #if ! defined(__WXDEBUG__)
>> >
>> >    #define FIX_BUG1567
>> >
>> >    #endif
>> >
>> >
>> >
>> > Please verify that this is still as good a fix as any so far.
>> >
>> > PRL
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Gale
Administrator
In reply to this post by Paul Licameli
On 23 January 2017 at 02:14, Paul Licameli <[hidden email]> wrote:
> Gale, try it again with this commit, which may incidentally fix bug 1521,
> and prevent the spurious messages in the log files:
>
> https://github.com/Paul-Licameli/audacity/commit/d998c959b93738639cecdbe34a7dea9b1d75d332

Thanks a lot, can't do it tonight but for the record my log messages
alternate between these two types:

02:46:28: Error: File
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be removed (error 1: Operation not permitted)
02:46:28: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be deleted (error 66: Directory not empty)

There is a repeat of those two lines then it moves on to another project.

> Do I understand correctly that the problem with closing without save occurs
> only when closing the last remaining project window?  (But not necessarily
> quitting the application).  It does not happen when you close one of two
> projects?  If so, that is consistent with the problem I am fixing.

It can happen even if I am not closing the final window, but not so often
as when closing the final window.


Gale


> PRL
>
>
> On Sun, Jan 22, 2017 at 8:45 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Sun, Jan 22, 2017 at 8:25 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Sun, Jan 22, 2017 at 7:27 PM, Gale Andrews <[hidden email]>
>>> wrote:
>>>>
>>>> Hi Paul,
>>>>
>>>> The bug1567-tidy release configuration starts up well with splash screen
>>>> and comes on top - just the weird double bounce in the Dock to be noted
>>>> as before.
>>>>
>>>
>>> On my Mac, running El Capitan, I see the icon jump once only at startup,
>>> whether running a 2.1.2 download or my release build of bug1567-tidy.
>>>
>>>>
>>>> The 1000 ms sleep after destroying the block files doesn't seem to do
>>>> much for stopping bug 1567 recurring - I got it every three or four
>>>> closes
>>>> without saving.  With 10000 ms sleep it still happens about one time in
>>>> 10 (which is too long a sleep I figure).
>>>>
>>>> Recording in another window while closing without saving still prevents
>>>> the bug occurring.
>>>
>>>
>>> Somehow I missed the earlier reports of this observation.  This is a
>>> strange datum.  Somehow more traffic in the temp directory stops the bug?
>>>
>>>>
>>>>
>>>> The bug1567-tidy modified to run as debug triggers 1567 on close without
>>>> save about one time in five with 1000 ms sleep. It has not triggered yet
>>>> in
>>>> 20 tries with 5000 ms sleep.
>>>>
>>>> Weird2 rebuilt unmodified in debug so with the fork and crash fix turned
>>>> off
>>>> does today sometimes launch with 1567 present, and close without save
>>>> does sometimes bring 1567 back. Not sure why I got so much better
>>>> results
>>>> yesterday - I had not messed up the defines -  but it looks like debug
>>>> is not
>>>> a sufficient or reliable panacea.
>>>>
>>>> Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
>>>> most of the time.
>>>>
>>>> I tried moving the Audacity temp dir to
>>>> /Users/gale/Library/Audacity/SessionData/
>>>> (seemed not an unreasonable place) but the bug occurred again after a
>>>> few
>>>> closes without saving. Of course I could not move the entire
>>>> configuration
>>>> directory.
>>>
>>>
>>> If I remove audacity.cfg, then the default in directory preferences is:
>>> /Users/paullicameli/Library/Application Support/audacity/SessionData
>>>
>>> Was that (substituting your user name) not your temporary directory to
>>> begin with?  If not then what?
>>>
>>> I was speculating that there is something about the ~/Library directory
>>> that is special, and that you should try changing your temp directory to
>>> something not under it, like simply /tmp
>>>
>>>>
>>>>
>>>> But this just might be something. Bug 1521
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
>>>> leaves old, emptied project folders behind in the temp folder. If I
>>>> manually
>>>> delete the last project* folder left behind after the File > Close, 1567
>>>> doesn't
>>>> seem to trigger, even if I remove the sleep after destroying the block
>>>> files.
>>>> I did 18 tries so far without the bug coming back.
>>>
>>>
>>> That entry in the bug database is puzzling.  There is no fix of it yet,
>>> and no comments on it besides yours.  You say there is a difference of
>>> behavior, in removal of temporary sub-folders, depending on operating
>>> system, but not on Audacity version?
>>>
>>> I observe that the sub-folders are removed on my El Capitan.
>>>
>>> PRL
>>
>>
>> More about this clue:
>>
>> I observe that ~DirManager calls DirectoryManager::CleanTempDir which
>> calls RecursivelyRemove() which cleans up by first attempting to delete each
>> file or directory AS A FILE, and then again AS A DIRECTORY, but ignoring
>> error codes.
>>
>> On my El Capitan, when closing a project without saving, this routinely
>> makes errors in the log file, in either a debug or a release build, that the
>> subdirectories could not be remove (as files), though the eventual attempt
>> to delete them as folders works.
>>
>> Your computer has some timing-dependent difference of behavior, who knows
>> why.
>>
>> This suggests to me that a rewrite that carefully removes files as files
>> (only) and directories as directories (only) might fix this problem.
>>
>> Presumably, this would still be an independent problem; both this fix and
>> the fork and crash fix would be necessary.
>>
>> PRL
>>
>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 22 January 2017 at 02:38, Paul Licameli <[hidden email]>
>>>> wrote:
>>>> >
>>>> > https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>>>> >
>>>> > I intend this branch in my fork to be the one ultimately merged into
>>>> > master,
>>>> > but not yet.
>>>> >
>>>> > "Fetch" again (don't "pull") in case I update it again.
>>>> >
>>>> > I squashed all into one commit and added a run time check that the
>>>> > operating
>>>> > system is Sierra or later; else, don't fork and crash.  (But still do
>>>> > the
>>>> > execve in main() that Leland put there for other reasons.)
>>>> >
>>>> > There is also a one second sleep in Project.cpp when closing a file,
>>>> > but the
>>>> > usefulness of that is not yet proven, and that part may be removed
>>>> > later.
>>>> >
>>>> > It applies the fix in release builds only.  If you want to do that in
>>>> > a
>>>> > debug build, find this in AudacityApp.h, and remove the #if and #endif
>>>> > lines:
>>>> >
>>>> >    #if ! defined(__WXDEBUG__)
>>>> >
>>>> >    #define FIX_BUG1567
>>>> >
>>>> >    #endif
>>>> >
>>>> >
>>>> >
>>>> > Please verify that this is still as good a fix as any so far.
>>>> >
>>>> > PRL
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Check out the vibrant tech community on one of the world's most
>>>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> > _______________________________________________
>>>> > audacity-devel mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Paul Licameli
In reply to this post by Gale


On Sun, Jan 22, 2017 at 9:38 PM, Gale Andrews <[hidden email]> wrote:
On 23 January 2017 at 01:25, Paul Licameli <[hidden email]> wrote:
>
>
> On Sun, Jan 22, 2017 at 7:27 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Hi Paul,
>>
>> The bug1567-tidy release configuration starts up well with splash screen
>> and comes on top - just the weird double bounce in the Dock to be noted
>> as before.
>>
>
> On my Mac, running El Capitan, I see the icon jump once only at startup,
> whether running a 2.1.2 download or my release build of bug1567-tidy.

Presumably because it is El Capitan, the crash fix on launch is not being
applied?

I must make a small change in the code so that fork and crash happens on El Capitan, but even so, no I still see nothing unusual about the icon when the program starts.

PRL
 


>> The 1000 ms sleep after destroying the block files doesn't seem to do
>> much for stopping bug 1567 recurring - I got it every three or four closes
>> without saving.  With 10000 ms sleep it still happens about one time in
>> 10 (which is too long a sleep I figure).
>>
>> Recording in another window while closing without saving still prevents
>> the bug occurring.
>
>
> Somehow I missed the earlier reports of this observation.  This is a strange
> datum.  Somehow more traffic in the temp directory stops the bug?
>
>>
>>
>> The bug1567-tidy modified to run as debug triggers 1567 on close without
>> save about one time in five with 1000 ms sleep. It has not triggered yet
>> in
>> 20 tries with 5000 ms sleep.
>>
>> Weird2 rebuilt unmodified in debug so with the fork and crash fix turned
>> off
>> does today sometimes launch with 1567 present, and close without save
>> does sometimes bring 1567 back. Not sure why I got so much better results
>> yesterday - I had not messed up the defines -  but it looks like debug is
>> not
>> a sufficient or reliable panacea.
>>
>> Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
>> most of the time.
>>
>> I tried moving the Audacity temp dir to
>> /Users/gale/Library/Audacity/SessionData/
>> (seemed not an unreasonable place) but the bug occurred again after a few
>> closes without saving. Of course I could not move the entire configuration
>> directory.
>
>
> If I remove audacity.cfg, then the default in directory preferences is:
> /Users/paullicameli/Library/Application Support/audacity/SessionData
>
> Was that (substituting your user name) not your temporary directory to begin
> with?  If not then what?

 /Users/gale/Library/Application Support/audacity/SessionData is my default
if I delete audacity.cfg, yes. I just did a blind experiment with
/Users/gale/Library/Audacity/SessionData/ .


> I was speculating that there is something about the ~/Library directory that
> is special, and that you should try changing your temp directory to
> something not under it, like simply /tmp

I didn't recall that is what you wrote. And we must be sure the files
survive reboot if Audacity crashes.

Anyway, on a quick try with /tmp/audacity-gale/SessionData, I can
still get 1567 on File > Close with no save.


>> But this just might be something. Bug 1521
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
>> leaves old, emptied project folders behind in the temp folder. If I
>> manually
>> delete the last project* folder left behind after the File > Close, 1567
>> doesn't
>> seem to trigger, even if I remove the sleep after destroying the block
>> files.
>> I did 18 tries so far without the bug coming back.
>
>
> That entry in the bug database is puzzling.  There is no fix of it yet, and
> no comments on it besides yours.  You say there is a difference of behavior,
> in removal of temporary sub-folders, depending on operating system, but not
> on Audacity version?

Yes, on my machine. I am very confident of that.


> I observe that the sub-folders are removed on my El Capitan.

Then I am kind of guessing that will be so with Peter and Cliff on
Sierra, and this is another "machine too slow" issue. This is mine
- 2.3 GHz HDD and 4 GB RAM:
http://www.everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i5-2.3-mid-2011-specs.html
.

It is puzzling why leaving old folders behind is OK when another
project is doing something, but not otherwise.



Gale

>>
>>
>> On 22 January 2017 at 02:38, Paul Licameli <[hidden email]>
>> wrote:
>> >
>> > https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>> >
>> > I intend this branch in my fork to be the one ultimately merged into
>> > master,
>> > but not yet.
>> >
>> > "Fetch" again (don't "pull") in case I update it again.
>> >
>> > I squashed all into one commit and added a run time check that the
>> > operating
>> > system is Sierra or later; else, don't fork and crash.  (But still do
>> > the
>> > execve in main() that Leland put there for other reasons.)
>> >
>> > There is also a one second sleep in Project.cpp when closing a file, but
>> > the
>> > usefulness of that is not yet proven, and that part may be removed
>> > later.
>> >
>> > It applies the fix in release builds only.  If you want to do that in a
>> > debug build, find this in AudacityApp.h, and remove the #if and #endif
>> > lines:
>> >
>> >    #if ! defined(__WXDEBUG__)
>> >
>> >    #define FIX_BUG1567
>> >
>> >    #endif
>> >
>> >
>> >
>> > Please verify that this is still as good a fix as any so far.
>> >
>> > PRL
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Branch bug1567-tidy

Paul Licameli
In reply to this post by Gale


On Sun, Jan 22, 2017 at 10:05 PM, Gale Andrews <[hidden email]> wrote:
On 23 January 2017 at 02:14, Paul Licameli <[hidden email]> wrote:
> Gale, try it again with this commit, which may incidentally fix bug 1521,
> and prevent the spurious messages in the log files:
>
> https://github.com/Paul-Licameli/audacity/commit/d998c959b93738639cecdbe34a7dea9b1d75d332

Thanks a lot, can't do it tonight but for the record my log messages
alternate between these two types:

02:46:28: Error: File
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be removed (error 1: Operation not permitted)
02:46:28: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project437381067/e00'
couldn't be deleted (error 66: Directory not empty)

Now that is very interesting!  On my computer I consistently get the first log message but not the second.  The code is supposed to be destroying the temporary file tree bottom-up, the leaf .au files first and then the folders above.  Your log messages suggest to me that the call to ::wxRemoveFile may complete and return to the program, but there is some delayed asynchronous action in the file system that we might need to wait for, before attempting to remove the folder above it.

I am starting to feel hopeful that we have at last pinpointed something that we are doing to the file system that is unusual and may account for the problem on close.

But the commit d998c95 might not be the final fix, if in fact some delay after the deletion of the leaf files is really what we need.

Would this fix, or my next iteration of it, if it completes the fix for 1557, be sufficient by itself to fix 1521 and 1567?  Maybe not, maybe fork and crash is still needed too.  But then, we could test whether that is so.  You can check out master, and cherry-pick d998c95 (or whatever future commit), and see if that is complete for 1567.

PRL

 

There is a repeat of those two lines then it moves on to another project.

> Do I understand correctly that the problem with closing without save occurs
> only when closing the last remaining project window?  (But not necessarily
> quitting the application).  It does not happen when you close one of two
> projects?  If so, that is consistent with the problem I am fixing.

It can happen even if I am not closing the final window, but not so often
as when closing the final window.


Gale


> PRL
>
>
> On Sun, Jan 22, 2017 at 8:45 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Sun, Jan 22, 2017 at 8:25 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Sun, Jan 22, 2017 at 7:27 PM, Gale Andrews <[hidden email]>
>>> wrote:
>>>>
>>>> Hi Paul,
>>>>
>>>> The bug1567-tidy release configuration starts up well with splash screen
>>>> and comes on top - just the weird double bounce in the Dock to be noted
>>>> as before.
>>>>
>>>
>>> On my Mac, running El Capitan, I see the icon jump once only at startup,
>>> whether running a 2.1.2 download or my release build of bug1567-tidy.
>>>
>>>>
>>>> The 1000 ms sleep after destroying the block files doesn't seem to do
>>>> much for stopping bug 1567 recurring - I got it every three or four
>>>> closes
>>>> without saving.  With 10000 ms sleep it still happens about one time in
>>>> 10 (which is too long a sleep I figure).
>>>>
>>>> Recording in another window while closing without saving still prevents
>>>> the bug occurring.
>>>
>>>
>>> Somehow I missed the earlier reports of this observation.  This is a
>>> strange datum.  Somehow more traffic in the temp directory stops the bug?
>>>
>>>>
>>>>
>>>> The bug1567-tidy modified to run as debug triggers 1567 on close without
>>>> save about one time in five with 1000 ms sleep. It has not triggered yet
>>>> in
>>>> 20 tries with 5000 ms sleep.
>>>>
>>>> Weird2 rebuilt unmodified in debug so with the fork and crash fix turned
>>>> off
>>>> does today sometimes launch with 1567 present, and close without save
>>>> does sometimes bring 1567 back. Not sure why I got so much better
>>>> results
>>>> yesterday - I had not messed up the defines -  but it looks like debug
>>>> is not
>>>> a sufficient or reliable panacea.
>>>>
>>>> Leland's Debug HEAD and my Debug HEAD behave similarly - 1567 happens
>>>> most of the time.
>>>>
>>>> I tried moving the Audacity temp dir to
>>>> /Users/gale/Library/Audacity/SessionData/
>>>> (seemed not an unreasonable place) but the bug occurred again after a
>>>> few
>>>> closes without saving. Of course I could not move the entire
>>>> configuration
>>>> directory.
>>>
>>>
>>> If I remove audacity.cfg, then the default in directory preferences is:
>>> /Users/paullicameli/Library/Application Support/audacity/SessionData
>>>
>>> Was that (substituting your user name) not your temporary directory to
>>> begin with?  If not then what?
>>>
>>> I was speculating that there is something about the ~/Library directory
>>> that is special, and that you should try changing your temp directory to
>>> something not under it, like simply /tmp
>>>
>>>>
>>>>
>>>> But this just might be something. Bug 1521
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1521
>>>> leaves old, emptied project folders behind in the temp folder. If I
>>>> manually
>>>> delete the last project* folder left behind after the File > Close, 1567
>>>> doesn't
>>>> seem to trigger, even if I remove the sleep after destroying the block
>>>> files.
>>>> I did 18 tries so far without the bug coming back.
>>>
>>>
>>> That entry in the bug database is puzzling.  There is no fix of it yet,
>>> and no comments on it besides yours.  You say there is a difference of
>>> behavior, in removal of temporary sub-folders, depending on operating
>>> system, but not on Audacity version?
>>>
>>> I observe that the sub-folders are removed on my El Capitan.
>>>
>>> PRL
>>
>>
>> More about this clue:
>>
>> I observe that ~DirManager calls DirectoryManager::CleanTempDir which
>> calls RecursivelyRemove() which cleans up by first attempting to delete each
>> file or directory AS A FILE, and then again AS A DIRECTORY, but ignoring
>> error codes.
>>
>> On my El Capitan, when closing a project without saving, this routinely
>> makes errors in the log file, in either a debug or a release build, that the
>> subdirectories could not be remove (as files), though the eventual attempt
>> to delete them as folders works.
>>
>> Your computer has some timing-dependent difference of behavior, who knows
>> why.
>>
>> This suggests to me that a rewrite that carefully removes files as files
>> (only) and directories as directories (only) might fix this problem.
>>
>> Presumably, this would still be an independent problem; both this fix and
>> the fork and crash fix would be necessary.
>>
>> PRL
>>
>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 22 January 2017 at 02:38, Paul Licameli <[hidden email]>
>>>> wrote:
>>>> >
>>>> > https://github.com/Paul-Licameli/audacity/commit/efc9d349e4a30fec2316fd3e7ca5aec77e0000a9
>>>> >
>>>> > I intend this branch in my fork to be the one ultimately merged into
>>>> > master,
>>>> > but not yet.
>>>> >
>>>> > "Fetch" again (don't "pull") in case I update it again.
>>>> >
>>>> > I squashed all into one commit and added a run time check that the
>>>> > operating
>>>> > system is Sierra or later; else, don't fork and crash.  (But still do
>>>> > the
>>>> > execve in main() that Leland put there for other reasons.)
>>>> >
>>>> > There is also a one second sleep in Project.cpp when closing a file,
>>>> > but the
>>>> > usefulness of that is not yet proven, and that part may be removed
>>>> > later.
>>>> >
>>>> > It applies the fix in release builds only.  If you want to do that in
>>>> > a
>>>> > debug build, find this in AudacityApp.h, and remove the #if and #endif
>>>> > lines:
>>>> >
>>>> >    #if ! defined(__WXDEBUG__)
>>>> >
>>>> >    #define FIX_BUG1567
>>>> >
>>>> >    #endif
>>>> >
>>>> >
>>>> >
>>>> > Please verify that this is still as good a fix as any so far.
>>>> >
>>>> > PRL
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Check out the vibrant tech community on one of the world's most
>>>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> > _______________________________________________
>>>> > audacity-devel mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...