Partial fix of 1567 in master?

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

Partial fix of 1567 in master?

Paul Licameli
For James to decide:

If you want to put the fork-and-crash fix into master now, then fetch my fork and cherry-pick this:

0988c427b9efd31f26491712f01cc15b46dac085

I have other things in my bug1567-tidy branch which are so far unsuccessful attempts to fix what may be an independent problem with closing projects without saving.  I had hoped that if these other things succeeded, then fork and crash might not be needed, but that no longer seems likely.

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: Partial fix of 1567 in master?

James Crook
I am 90% likely to cherry pick this. Before I do though....

1) is there any known downside to it?  (other perhaps than changed icon
bouncing behaviour)
2) Has dragging of a file into Audacity been tested on a machine with
fork-and-crash?
3) What sign/symptom led to the idea of this fix, rather than waits?

Thanks.

--James.

On 1/25/2017 5:09 PM, Paul Licameli wrote:

> For James to decide:
>
> If you want to put the fork-and-crash fix into master now, then fetch my
> fork and cherry-pick this:
>
> 0988c427b9efd31f26491712f01cc15b46dac085
>
> I have other things in my bug1567-tidy branch which are so far unsuccessful
> attempts to fix what may be an independent problem with closing projects
> without saving.  I had hoped that if these other things succeeded, then
> fork and crash might not be needed, but that no longer seems likely.
>
> 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: Partial fix of 1567 in master?

Paul Licameli


On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]> wrote:
I am 90% likely to cherry pick this. Before I do though....

1) is there any known downside to it?  (other perhaps than changed icon
bouncing behaviour)
2) Has dragging of a file into Audacity been tested on a machine with
fork-and-crash?
3) What sign/symptom led to the idea of this fix, rather than waits?

Thanks.

  1. None I know.  I don't see any change in the bounce on El Capitan.  (I saw that my earlier attempts momentarily made two Audacity icons, but that no longer happens, because now I do the fork and crash in main() itself, before any wxWidgets initializations.)
  2. I just tried it in a release build of master plus the cherry-pick and all is well.  As before, you must release the mouse over the track panel area, and it works to import files but not to open .aup projects.
  3. Gale's observation that force-quitting (it had to be a force-quit) by means of the toolbar icon, done soon enough after it appears, clears the problem if it had happened in the previous run, and reboot of the operating system was then not needed.  I figured out how to do something like that automatically.  I determined in the debugger that when you force-quit, the program receives SIGTERM.  So I crash the program by raising that signal.
PRL
 

--James.

On 1/25/2017 5:09 PM, Paul Licameli wrote:
> For James to decide:
>
> If you want to put the fork-and-crash fix into master now, then fetch my
> fork and cherry-pick this:
>
> 0988c427b9efd31f26491712f01cc15b46dac085
>
> I have other things in my bug1567-tidy branch which are so far unsuccessful
> attempts to fix what may be an independent problem with closing projects
> without saving.  I had hoped that if these other things succeeded, then
> fork and crash might not be needed, but that no longer seems likely.
>
> 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: Partial fix of 1567 in master?

James Crook
OK.  Committed to HEAD
https://github.com/audacity/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085



On 1/25/2017 5:56 PM, Paul Licameli wrote:

> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]> wrote:
>
>> I am 90% likely to cherry pick this. Before I do though....
>>
>> 1) is there any known downside to it?  (other perhaps than changed icon
>> bouncing behaviour)
>> 2) Has dragging of a file into Audacity been tested on a machine with
>> fork-and-crash?
>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>
>> Thanks.
>>
>
>     1. None I know.  I don't see any change in the bounce on El Capitan.  (I
>     saw that my earlier attempts momentarily made two Audacity icons, but that
>     no longer happens, because now I do the fork and crash in main() itself,
>     before any wxWidgets initializations.)
Excellent.


>     2. I just tried it in a release build of master plus the cherry-pick and
>     all is well.  As before, you must release the mouse over the track panel
>     area, and it works to import files but not to open .aup projects.
Right, but doCrash is false on your machine, so the fork and crash does
not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
staying on El Capitan.


>     3. Gale's observation that force-quitting (it had to be a force-quit) by
>     means of the toolbar icon, done soon enough after it appears, clears the
>     problem if it had happened in the previous run, and reboot of the operating
>     system was then not needed.  I figured out how to do something like that
>     automatically.  I determined in the debugger that when you force-quit, the
>     program receives SIGTERM.  So I crash the program by raising that signal.
Ah.  OK.  So the SIGTERM is hypothesised to clear the state.


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Paul Licameli


On Wed, Jan 25, 2017 at 1:50 PM, James Crook <[hidden email]> wrote:
OK.  Committed to HEAD
https://github.com/audacity/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085



On 1/25/2017 5:56 PM, Paul Licameli wrote:
> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]> wrote:
>
>> I am 90% likely to cherry pick this. Before I do though....
>>
>> 1) is there any known downside to it?  (other perhaps than changed icon
>> bouncing behaviour)
>> 2) Has dragging of a file into Audacity been tested on a machine with
>> fork-and-crash?
>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>
>> Thanks.
>>
>
>     1. None I know.  I don't see any change in the bounce on El Capitan.  (I
>     saw that my earlier attempts momentarily made two Audacity icons, but that
>     no longer happens, because now I do the fork and crash in main() itself,
>     before any wxWidgets initializations.)
Excellent.


>     2. I just tried it in a release build of master plus the cherry-pick and
>     all is well.  As before, you must release the mouse over the track panel
>     area, and it works to import files but not to open .aup projects.
Right, but doCrash is false on your machine, so the fork and crash does
not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
staying on El Capitan.

I neglected to say, I modify AudacityApp::IsSierraOrLater to return true always in my build.

I suppose I should upgrade to Sierra soon for the good of the team.  I am always hesistant to move operating systems, precisely because surprises like this happen with programs.
 


>     3. Gale's observation that force-quitting (it had to be a force-quit) by
>     means of the toolbar icon, done soon enough after it appears, clears the
>     problem if it had happened in the previous run, and reboot of the operating
>     system was then not needed.  I figured out how to do something like that
>     automatically.  I determined in the debugger that when you force-quit, the
>     program receives SIGTERM.  So I crash the program by raising that signal.
Ah.  OK.  So the SIGTERM is hypothesised to clear the state.


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Peter Sampson-2
Paul wrote:
>I suppose I should upgrade to Sierra soon for the good of the team.

Yepper, as they say "take one for the team" :-))

Peter,

------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Gale
Administrator
In reply to this post by James Crook
On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
> OK.  Committed to HEAD
> https://github.com/audacity/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085

Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
extending cleanup time by an unwarranted amount on my machine
that increases not only with the number of folders but also with the
number of AU files they contain. If I have four projects in SessionData,
three old, each with half an hour of audio, it now takes 20 minutes to
attempt (and fail) at clean up.

Obviously it's 1567 or some friend of it doing this, but I suggest we
don't want that commit in.


Gale


> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]> wrote:
>>
>>> I am 90% likely to cherry pick this. Before I do though....
>>>
>>> 1) is there any known downside to it?  (other perhaps than changed icon
>>> bouncing behaviour)
>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>> fork-and-crash?
>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>
>>> Thanks.
>>>
>>
>>     1. None I know.  I don't see any change in the bounce on El Capitan.  (I
>>     saw that my earlier attempts momentarily made two Audacity icons, but that
>>     no longer happens, because now I do the fork and crash in main() itself,
>>     before any wxWidgets initializations.)
> Excellent.
>
>
>>     2. I just tried it in a release build of master plus the cherry-pick and
>>     all is well.  As before, you must release the mouse over the track panel
>>     area, and it works to import files but not to open .aup projects.
> Right, but doCrash is false on your machine, so the fork and crash does
> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
> staying on El Capitan.
>
>
>>     3. Gale's observation that force-quitting (it had to be a force-quit) by
>>     means of the toolbar icon, done soon enough after it appears, clears the
>>     problem if it had happened in the previous run, and reboot of the operating
>>     system was then not needed.  I figured out how to do something like that
>>     automatically.  I determined in the debugger that when you force-quit, the
>>     program receives SIGTERM.  So I crash the program by raising that signal.
> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>
>
> ------------------------------------------------------------------------------
> 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: Partial fix of 1567 in master?

James Crook
https://github.com/audacity/audacity/commit/bb0fb7f6c240a733c7a247f88ff393422c0cd8a3

should fix the slow clean, if it was 0061cd0 at fault.

--James.

On 1/25/2017 7:59 PM, Gale Andrews wrote:

> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>> OK.  Committed to HEAD
>> https://github.com/audacity/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085
> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
> extending cleanup time by an unwarranted amount on my machine
> that increases not only with the number of folders but also with the
> number of AU files they contain. If I have four projects in SessionData,
> three old, each with half an hour of audio, it now takes 20 minutes to
> attempt (and fail) at clean up.
>
> Obviously it's 1567 or some friend of it doing this, but I suggest we
> don't want that commit in.
>
>
> Gale
>
>
>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]> wrote:
>>>
>>>> I am 90% likely to cherry pick this. Before I do though....
>>>>
>>>> 1) is there any known downside to it?  (other perhaps than changed icon
>>>> bouncing behaviour)
>>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>>> fork-and-crash?
>>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>>
>>>> Thanks.
>>>>
>>>      1. None I know.  I don't see any change in the bounce on El Capitan.  (I
>>>      saw that my earlier attempts momentarily made two Audacity icons, but that
>>>      no longer happens, because now I do the fork and crash in main() itself,
>>>      before any wxWidgets initializations.)
>> Excellent.
>>
>>
>>>      2. I just tried it in a release build of master plus the cherry-pick and
>>>      all is well.  As before, you must release the mouse over the track panel
>>>      area, and it works to import files but not to open .aup projects.
>> Right, but doCrash is false on your machine, so the fork and crash does
>> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
>> staying on El Capitan.
>>
>>
>>>      3. Gale's observation that force-quitting (it had to be a force-quit) by
>>>      means of the toolbar icon, done soon enough after it appears, clears the
>>>      problem if it had happened in the previous run, and reboot of the operating
>>>      system was then not needed.  I figured out how to do something like that
>>>      automatically.  I determined in the debugger that when you force-quit, the
>>>      program receives SIGTERM.  So I crash the program by raising that signal.
>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>>


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Paul Licameli
James, I wanted you to cherry-pick commit 0061cd0 -- not merge it.  You took other changes with it, that came before it in my branch that are not yet intended for master.

Could you make a hard reset of audacity/master to 97bf72ddb4136cc15a7d1aa03085989c128e881b and then cherry-pick 0061cd0?

I am sorry I wasn't clear enough.

PRL


On Wed, Jan 25, 2017 at 4:05 PM, James Crook <[hidden email]> wrote:
https://github.com/audacity/audacity/commit/bb0fb7f6c240a733c7a247f88ff393422c0cd8a3

should fix the slow clean, if it was 0061cd0 at fault.

--James.

On 1/25/2017 7:59 PM, Gale Andrews wrote:
> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>> OK.  Committed to HEAD
>> https://github.com/audacity/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085
> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
> extending cleanup time by an unwarranted amount on my machine
> that increases not only with the number of folders but also with the
> number of AU files they contain. If I have four projects in SessionData,
> three old, each with half an hour of audio, it now takes 20 minutes to
> attempt (and fail) at clean up.
>
> Obviously it's 1567 or some friend of it doing this, but I suggest we
> don't want that commit in.
>
>
> Gale
>
>
>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]> wrote:
>>>
>>>> I am 90% likely to cherry pick this. Before I do though....
>>>>
>>>> 1) is there any known downside to it?  (other perhaps than changed icon
>>>> bouncing behaviour)
>>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>>> fork-and-crash?
>>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>>
>>>> Thanks.
>>>>
>>>      1. None I know.  I don't see any change in the bounce on El Capitan.  (I
>>>      saw that my earlier attempts momentarily made two Audacity icons, but that
>>>      no longer happens, because now I do the fork and crash in main() itself,
>>>      before any wxWidgets initializations.)
>> Excellent.
>>
>>
>>>      2. I just tried it in a release build of master plus the cherry-pick and
>>>      all is well.  As before, you must release the mouse over the track panel
>>>      area, and it works to import files but not to open .aup projects.
>> Right, but doCrash is false on your machine, so the fork and crash does
>> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
>> staying on El Capitan.
>>
>>
>>>      3. Gale's observation that force-quitting (it had to be a force-quit) by
>>>      means of the toolbar icon, done soon enough after it appears, clears the
>>>      problem if it had happened in the previous run, and reboot of the operating
>>>      system was then not needed.  I figured out how to do something like that
>>>      automatically.  I determined in the debugger that when you force-quit, the
>>>      program receives SIGTERM.  So I crash the program by raising that signal.
>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>>


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Paul Licameli
Or shall I push the revert commits myself?

PRL


On Wed, Jan 25, 2017 at 4:20 PM, Paul Licameli <[hidden email]> wrote:
James, I wanted you to cherry-pick commit 0061cd0 -- not merge it.  You took other changes with it, that came before it in my branch that are not yet intended for master.

Could you make a hard reset of audacity/master to 97bf72ddb4136cc15a7d1aa03085989c128e881b and then cherry-pick 0061cd0?

I am sorry I wasn't clear enough.

PRL


On Wed, Jan 25, 2017 at 4:05 PM, James Crook <[hidden email]> wrote:
https://github.com/audacity/audacity/commit/bb0fb7f6c240a733c7a247f88ff393422c0cd8a3

should fix the slow clean, if it was 0061cd0 at fault.

--James.

On 1/25/2017 7:59 PM, Gale Andrews wrote:
> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>> OK.  Committed to HEAD
>> https://github.com/audacity/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085
> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
> extending cleanup time by an unwarranted amount on my machine
> that increases not only with the number of folders but also with the
> number of AU files they contain. If I have four projects in SessionData,
> three old, each with half an hour of audio, it now takes 20 minutes to
> attempt (and fail) at clean up.
>
> Obviously it's 1567 or some friend of it doing this, but I suggest we
> don't want that commit in.
>
>
> Gale
>
>
>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]> wrote:
>>>
>>>> I am 90% likely to cherry pick this. Before I do though....
>>>>
>>>> 1) is there any known downside to it?  (other perhaps than changed icon
>>>> bouncing behaviour)
>>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>>> fork-and-crash?
>>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>>
>>>> Thanks.
>>>>
>>>      1. None I know.  I don't see any change in the bounce on El Capitan.  (I
>>>      saw that my earlier attempts momentarily made two Audacity icons, but that
>>>      no longer happens, because now I do the fork and crash in main() itself,
>>>      before any wxWidgets initializations.)
>> Excellent.
>>
>>
>>>      2. I just tried it in a release build of master plus the cherry-pick and
>>>      all is well.  As before, you must release the mouse over the track panel
>>>      area, and it works to import files but not to open .aup projects.
>> Right, but doCrash is false on your machine, so the fork and crash does
>> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
>> staying on El Capitan.
>>
>>
>>>      3. Gale's observation that force-quitting (it had to be a force-quit) by
>>>      means of the toolbar icon, done soon enough after it appears, clears the
>>>      problem if it had happened in the previous run, and reboot of the operating
>>>      system was then not needed.  I figured out how to do something like that
>>>      automatically.  I determined in the debugger that when you force-quit, the
>>>      program receives SIGTERM.  So I crash the program by raising that signal.
>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>>


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

James Crook
Done.

Or rather after reverting to:
97bf72 Bug 1304 - Starting Save or Export directory is not set, so is
unwritable or requires authentication for most users
I cherry picked:
0988c4 Bug1567: intermittent failure to load libraries, plugins on Sierra...


It's rare I'll do a push -f to master, as once other people pull from it
there is a risk of lots of confusion.  But I did this time.  It was as
much my mistake as yours.


--James.


On 1/25/2017 9:23 PM, Paul Licameli wrote:

> Or shall I push the revert commits myself?
>
> PRL
>
>
> On Wed, Jan 25, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
> wrote:
>
>> James, I wanted you to cherry-pick commit 0061cd0 -- not merge it.  You
>> took other changes with it, that came before it in my branch that are not
>> yet intended for master.
>>
>> Could you make a hard reset of audacity/master to
>> 97bf72ddb4136cc15a7d1aa03085989c128e881b and then cherry-pick 0061cd0?
>>
>> I am sorry I wasn't clear enough.
>>
>> PRL
>>
>>
>> On Wed, Jan 25, 2017 at 4:05 PM, James Crook <[hidden email]> wrote:
>>
>>> https://github.com/audacity/audacity/commit/bb0fb7f6c240a733
>>> c7a247f88ff393422c0cd8a3
>>>
>>> should fix the slow clean, if it was 0061cd0 at fault.
>>>
>>> --James.
>>>
>>> On 1/25/2017 7:59 PM, Gale Andrews wrote:
>>>> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>>>>> OK.  Committed to HEAD
>>>>> https://github.com/audacity/audacity/commit/0988c427b9efd31f
>>> 26491712f01cc15b46dac085
>>>> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
>>>> extending cleanup time by an unwarranted amount on my machine
>>>> that increases not only with the number of folders but also with the
>>>> number of AU files they contain. If I have four projects in SessionData,
>>>> three old, each with half an hour of audio, it now takes 20 minutes to
>>>> attempt (and fail) at clean up.
>>>>
>>>> Obviously it's 1567 or some friend of it doing this, but I suggest we
>>>> don't want that commit in.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>>>>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]>
>>> wrote:
>>>>>>> I am 90% likely to cherry pick this. Before I do though....
>>>>>>>
>>>>>>> 1) is there any known downside to it?  (other perhaps than changed
>>> icon
>>>>>>> bouncing behaviour)
>>>>>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>>>>>> fork-and-crash?
>>>>>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>       1. None I know.  I don't see any change in the bounce on El
>>> Capitan.  (I
>>>>>>       saw that my earlier attempts momentarily made two Audacity
>>> icons, but that
>>>>>>       no longer happens, because now I do the fork and crash in main()
>>> itself,
>>>>>>       before any wxWidgets initializations.)
>>>>> Excellent.
>>>>>
>>>>>
>>>>>>       2. I just tried it in a release build of master plus the
>>> cherry-pick and
>>>>>>       all is well.  As before, you must release the mouse over the
>>> track panel
>>>>>>       area, and it works to import files but not to open .aup projects.
>>>>> Right, but doCrash is false on your machine, so the fork and crash does
>>>>> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
>>>>> staying on El Capitan.
>>>>>
>>>>>
>>>>>>       3. Gale's observation that force-quitting (it had to be a
>>> force-quit) by
>>>>>>       means of the toolbar icon, done soon enough after it appears,
>>> clears the
>>>>>>       problem if it had happened in the previous run, and reboot of
>>> the operating
>>>>>>       system was then not needed.  I figured out how to do something
>>> like that
>>>>>>       automatically.  I determined in the debugger that when you
>>> force-quit, the
>>>>>>       program receives SIGTERM.  So I crash the program by raising
>>> that signal.
>>>>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>>>>>
>>>


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Paul Licameli
If any others of you have fetched the unintended commits to a local repository, then likewise do this to correct it:

git checkout master
git reset --hard 97bf72
git pull audacity master

PRL


On Wed, Jan 25, 2017 at 5:35 PM, James Crook <[hidden email]> wrote:
Done.

Or rather after reverting to:
97bf72 Bug 1304 - Starting Save or Export directory is not set, so is
unwritable or requires authentication for most users
I cherry picked:
0988c4 Bug1567: intermittent failure to load libraries, plugins on Sierra...


It's rare I'll do a push -f to master, as once other people pull from it
there is a risk of lots of confusion.  But I did this time.  It was as
much my mistake as yours.


--James.


On 1/25/2017 9:23 PM, Paul Licameli wrote:
> Or shall I push the revert commits myself?
>
> PRL
>
>
> On Wed, Jan 25, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
> wrote:
>
>> James, I wanted you to cherry-pick commit 0061cd0 -- not merge it.  You
>> took other changes with it, that came before it in my branch that are not
>> yet intended for master.
>>
>> Could you make a hard reset of audacity/master to
>> 97bf72ddb4136cc15a7d1aa03085989c128e881b and then cherry-pick 0061cd0?
>>
>> I am sorry I wasn't clear enough.
>>
>> PRL
>>
>>
>> On Wed, Jan 25, 2017 at 4:05 PM, James Crook <[hidden email]> wrote:
>>
>>> https://github.com/audacity/audacity/commit/bb0fb7f6c240a733
>>> c7a247f88ff393422c0cd8a3
>>>
>>> should fix the slow clean, if it was 0061cd0 at fault.
>>>
>>> --James.
>>>
>>> On 1/25/2017 7:59 PM, Gale Andrews wrote:
>>>> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>>>>> OK.  Committed to HEAD
>>>>> https://github.com/audacity/audacity/commit/0988c427b9efd31f
>>> 26491712f01cc15b46dac085
>>>> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
>>>> extending cleanup time by an unwarranted amount on my machine
>>>> that increases not only with the number of folders but also with the
>>>> number of AU files they contain. If I have four projects in SessionData,
>>>> three old, each with half an hour of audio, it now takes 20 minutes to
>>>> attempt (and fail) at clean up.
>>>>
>>>> Obviously it's 1567 or some friend of it doing this, but I suggest we
>>>> don't want that commit in.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>>>>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]>
>>> wrote:
>>>>>>> I am 90% likely to cherry pick this. Before I do though....
>>>>>>>
>>>>>>> 1) is there any known downside to it?  (other perhaps than changed
>>> icon
>>>>>>> bouncing behaviour)
>>>>>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>>>>>> fork-and-crash?
>>>>>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>       1. None I know.  I don't see any change in the bounce on El
>>> Capitan.  (I
>>>>>>       saw that my earlier attempts momentarily made two Audacity
>>> icons, but that
>>>>>>       no longer happens, because now I do the fork and crash in main()
>>> itself,
>>>>>>       before any wxWidgets initializations.)
>>>>> Excellent.
>>>>>
>>>>>
>>>>>>       2. I just tried it in a release build of master plus the
>>> cherry-pick and
>>>>>>       all is well.  As before, you must release the mouse over the
>>> track panel
>>>>>>       area, and it works to import files but not to open .aup projects.
>>>>> Right, but doCrash is false on your machine, so the fork and crash does
>>>>> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
>>>>> staying on El Capitan.
>>>>>
>>>>>
>>>>>>       3. Gale's observation that force-quitting (it had to be a
>>> force-quit) by
>>>>>>       means of the toolbar icon, done soon enough after it appears,
>>> clears the
>>>>>>       problem if it had happened in the previous run, and reboot of
>>> the operating
>>>>>>       system was then not needed.  I figured out how to do something
>>> like that
>>>>>>       automatically.  I determined in the debugger that when you
>>> force-quit, the
>>>>>>       program receives SIGTERM.  So I crash the program by raising
>>> that signal.
>>>>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>>>>>
>>>


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Gale
Administrator
In reply to this post by James Crook
On 25 January 2017 at 22:35, James Crook <[hidden email]> wrote:
> Done.
>
> Or rather after reverting to:
> 97bf72 Bug 1304 - Starting Save or Export directory is not set, so is
> unwritable or requires authentication for most users
> I cherry picked:
> 0988c4 Bug1567: intermittent failure to load libraries, plugins on Sierra...

Having experimented some more I would now like James/Paul to
consider adding to master:

* https://github.com/Paul-Licameli/audacity/commit/79730a1
   This removes the spurious log messages which show a problem
   even if there isn't one, and which add confusion on machines where
   1521 and/or 1567 present themselves

* https://github.com/Paul-Licameli/audacity/commit/a1b6aad
   This shows if a folder that could not be deleted still contains a file.
   This may be useful if (realistically) 1521 and 1567 are still present
   in 2.1.3.


Gale



> It's rare I'll do a push -f to master, as once other people pull from it
> there is a risk of lots of confusion.  But I did this time.  It was as
> much my mistake as yours.
>
>
> --James.
>
>
> On 1/25/2017 9:23 PM, Paul Licameli wrote:
>> Or shall I push the revert commits myself?
>>
>> PRL
>>
>>
>> On Wed, Jan 25, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
>> wrote:
>>
>>> James, I wanted you to cherry-pick commit 0061cd0 -- not merge it.  You
>>> took other changes with it, that came before it in my branch that are not
>>> yet intended for master.
>>>
>>> Could you make a hard reset of audacity/master to
>>> 97bf72ddb4136cc15a7d1aa03085989c128e881b and then cherry-pick 0061cd0?
>>>
>>> I am sorry I wasn't clear enough.
>>>
>>> PRL
>>>
>>>
>>> On Wed, Jan 25, 2017 at 4:05 PM, James Crook <[hidden email]> wrote:
>>>
>>>> https://github.com/audacity/audacity/commit/bb0fb7f6c240a733
>>>> c7a247f88ff393422c0cd8a3
>>>>
>>>> should fix the slow clean, if it was 0061cd0 at fault.
>>>>
>>>> --James.
>>>>
>>>> On 1/25/2017 7:59 PM, Gale Andrews wrote:
>>>>> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>>>>>> OK.  Committed to HEAD
>>>>>> https://github.com/audacity/audacity/commit/0988c427b9efd31f
>>>> 26491712f01cc15b46dac085
>>>>> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
>>>>> extending cleanup time by an unwarranted amount on my machine
>>>>> that increases not only with the number of folders but also with the
>>>>> number of AU files they contain. If I have four projects in SessionData,
>>>>> three old, each with half an hour of audio, it now takes 20 minutes to
>>>>> attempt (and fail) at clean up.
>>>>>
>>>>> Obviously it's 1567 or some friend of it doing this, but I suggest we
>>>>> don't want that commit in.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>>>>>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]>
>>>> wrote:
>>>>>>>> I am 90% likely to cherry pick this. Before I do though....
>>>>>>>>
>>>>>>>> 1) is there any known downside to it?  (other perhaps than changed
>>>> icon
>>>>>>>> bouncing behaviour)
>>>>>>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>>>>>>> fork-and-crash?
>>>>>>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>       1. None I know.  I don't see any change in the bounce on El
>>>> Capitan.  (I
>>>>>>>       saw that my earlier attempts momentarily made two Audacity
>>>> icons, but that
>>>>>>>       no longer happens, because now I do the fork and crash in main()
>>>> itself,
>>>>>>>       before any wxWidgets initializations.)
>>>>>> Excellent.
>>>>>>
>>>>>>
>>>>>>>       2. I just tried it in a release build of master plus the
>>>> cherry-pick and
>>>>>>>       all is well.  As before, you must release the mouse over the
>>>> track panel
>>>>>>>       area, and it works to import files but not to open .aup projects.
>>>>>> Right, but doCrash is false on your machine, so the fork and crash does
>>>>>> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
>>>>>> staying on El Capitan.
>>>>>>
>>>>>>
>>>>>>>       3. Gale's observation that force-quitting (it had to be a
>>>> force-quit) by
>>>>>>>       means of the toolbar icon, done soon enough after it appears,
>>>> clears the
>>>>>>>       problem if it had happened in the previous run, and reboot of
>>>> the operating
>>>>>>>       system was then not needed.  I figured out how to do something
>>>> like that
>>>>>>>       automatically.  I determined in the debugger that when you
>>>> force-quit, the
>>>>>>>       program receives SIGTERM.  So I crash the program by raising
>>>> that signal.
>>>>>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>>>>>>
>>>>
>
>
> ------------------------------------------------------------------------------
> 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: Partial fix of 1567 in master?

Paul Licameli


On Fri, Jan 27, 2017 at 1:18 PM, Gale Andrews <[hidden email]> wrote:
On 25 January 2017 at 22:35, James Crook <[hidden email]> wrote:
> Done.
>
> Or rather after reverting to:
> 97bf72 Bug 1304 - Starting Save or Export directory is not set, so is
> unwritable or requires authentication for most users
> I cherry picked:
> 0988c4 Bug1567: intermittent failure to load libraries, plugins on Sierra...

Having experimented some more I would now like James/Paul to
consider adding to master:

* https://github.com/Paul-Licameli/audacity/commit/79730a1
   This removes the spurious log messages which show a problem
   even if there isn't one, and which add confusion on machines where
   1521 and/or 1567 present themselves

* https://github.com/Paul-Licameli/audacity/commit/a1b6aad
   This shows if a folder that could not be deleted still contains a file.
   This may be useful if (realistically) 1521 and 1567 are still present
   in 2.1.3.


Gale


The first, at best, removes extraneous messages from the log, when Audacity attempts to delete folders as if they were ordinary files, but it does not really help fix the bug.

The second, I hoped, would enable Gale to give me more diagnostic data about the seeming discrepancy between what Finder tells us and what Audacity's log tells us, whether the /dnn folders are really empty when Audacity tries to delete them.

At this stage, conservatism might argue against taking these commits, as they don't fix any real problems for certain.

PRL

 



> It's rare I'll do a push -f to master, as once other people pull from it
> there is a risk of lots of confusion.  But I did this time.  It was as
> much my mistake as yours.
>
>
> --James.
>
>
> On 1/25/2017 9:23 PM, Paul Licameli wrote:
>> Or shall I push the revert commits myself?
>>
>> PRL
>>
>>
>> On Wed, Jan 25, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
>> wrote:
>>
>>> James, I wanted you to cherry-pick commit 0061cd0 -- not merge it.  You
>>> took other changes with it, that came before it in my branch that are not
>>> yet intended for master.
>>>
>>> Could you make a hard reset of audacity/master to
>>> 97bf72ddb4136cc15a7d1aa03085989c128e881b and then cherry-pick 0061cd0?
>>>
>>> I am sorry I wasn't clear enough.
>>>
>>> PRL
>>>
>>>
>>> On Wed, Jan 25, 2017 at 4:05 PM, James Crook <[hidden email]> wrote:
>>>
>>>> https://github.com/audacity/audacity/commit/bb0fb7f6c240a733
>>>> c7a247f88ff393422c0cd8a3
>>>>
>>>> should fix the slow clean, if it was 0061cd0 at fault.
>>>>
>>>> --James.
>>>>
>>>> On 1/25/2017 7:59 PM, Gale Andrews wrote:
>>>>> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>>>>>> OK.  Committed to HEAD
>>>>>> https://github.com/audacity/audacity/commit/0988c427b9efd31f
>>>> 26491712f01cc15b46dac085
>>>>> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
>>>>> extending cleanup time by an unwarranted amount on my machine
>>>>> that increases not only with the number of folders but also with the
>>>>> number of AU files they contain. If I have four projects in SessionData,
>>>>> three old, each with half an hour of audio, it now takes 20 minutes to
>>>>> attempt (and fail) at clean up.
>>>>>
>>>>> Obviously it's 1567 or some friend of it doing this, but I suggest we
>>>>> don't want that commit in.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>>>>>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]>
>>>> wrote:
>>>>>>>> I am 90% likely to cherry pick this. Before I do though....
>>>>>>>>
>>>>>>>> 1) is there any known downside to it?  (other perhaps than changed
>>>> icon
>>>>>>>> bouncing behaviour)
>>>>>>>> 2) Has dragging of a file into Audacity been tested on a machine with
>>>>>>>> fork-and-crash?
>>>>>>>> 3) What sign/symptom led to the idea of this fix, rather than waits?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>       1. None I know.  I don't see any change in the bounce on El
>>>> Capitan.  (I
>>>>>>>       saw that my earlier attempts momentarily made two Audacity
>>>> icons, but that
>>>>>>>       no longer happens, because now I do the fork and crash in main()
>>>> itself,
>>>>>>>       before any wxWidgets initializations.)
>>>>>> Excellent.
>>>>>>
>>>>>>
>>>>>>>       2. I just tried it in a release build of master plus the
>>>> cherry-pick and
>>>>>>>       all is well.  As before, you must release the mouse over the
>>>> track panel
>>>>>>>       area, and it works to import files but not to open .aup projects.
>>>>>> Right, but doCrash is false on your machine, so the fork and crash does
>>>>>> not happen?  Or have you upgraded to Sierra?  I'm (for various reasons)
>>>>>> staying on El Capitan.
>>>>>>
>>>>>>
>>>>>>>       3. Gale's observation that force-quitting (it had to be a
>>>> force-quit) by
>>>>>>>       means of the toolbar icon, done soon enough after it appears,
>>>> clears the
>>>>>>>       problem if it had happened in the previous run, and reboot of
>>>> the operating
>>>>>>>       system was then not needed.  I figured out how to do something
>>>> like that
>>>>>>>       automatically.  I determined in the debugger that when you
>>>> force-quit, the
>>>>>>>       program receives SIGTERM.  So I crash the program by raising
>>>> that signal.
>>>>>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>>>>>>
>>>>
>
>
> ------------------------------------------------------------------------------
> 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: Partial fix of 1567 in master?

James Crook
In reply to this post by Gale
Done.

a1b6aad may say '<path> still contains:'. and then not say anything.  
This could happen if the directory being deleted is empty but read only
(so empty dir exists after unsuccessful RmDir).  Not really a problem,
provided you are aware of that.

--James.



On 1/27/2017 6:18 PM, Gale Andrews wrote:

> On 25 January 2017 at 22:35, James Crook <[hidden email]> wrote:
>> Done.
>>
>> Or rather after reverting to:
>> 97bf72 Bug 1304 - Starting Save or Export directory is not set, so is
>> unwritable or requires authentication for most users
>> I cherry picked:
>> 0988c4 Bug1567: intermittent failure to load libraries, plugins on Sierra...
> Having experimented some more I would now like James/Paul to
> consider adding to master:
>
> * https://github.com/Paul-Licameli/audacity/commit/79730a1
>     This removes the spurious log messages which show a problem
>     even if there isn't one, and which add confusion on machines where
>     1521 and/or 1567 present themselves
>
> * https://github.com/Paul-Licameli/audacity/commit/a1b6aad
>     This shows if a folder that could not be deleted still contains a file.
>     This may be useful if (realistically) 1521 and 1567 are still present
>     in 2.1.3.
>
>
> Gale


------------------------------------------------------------------------------
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: Partial fix of 1567 in master?

Gale
Administrator
In reply to this post by Paul Licameli
I've just posted more about the diagnostics in the other thread, and
added file monitoring output to that post.



Gale


On 27 January 2017 at 19:33, Paul Licameli <[hidden email]> wrote:

>
>
> On Fri, Jan 27, 2017 at 1:18 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 25 January 2017 at 22:35, James Crook <[hidden email]> wrote:
>> > Done.
>> >
>> > Or rather after reverting to:
>> > 97bf72 Bug 1304 - Starting Save or Export directory is not set, so is
>> > unwritable or requires authentication for most users
>> > I cherry picked:
>> > 0988c4 Bug1567: intermittent failure to load libraries, plugins on
>> > Sierra...
>>
>> Having experimented some more I would now like James/Paul to
>> consider adding to master:
>>
>> * https://github.com/Paul-Licameli/audacity/commit/79730a1
>>    This removes the spurious log messages which show a problem
>>    even if there isn't one, and which add confusion on machines where
>>    1521 and/or 1567 present themselves
>>
>> * https://github.com/Paul-Licameli/audacity/commit/a1b6aad
>>    This shows if a folder that could not be deleted still contains a file.
>>    This may be useful if (realistically) 1521 and 1567 are still present
>>    in 2.1.3.
>>
>>
>> Gale
>
>
>
> The first, at best, removes extraneous messages from the log, when Audacity
> attempts to delete folders as if they were ordinary files, but it does not
> really help fix the bug.
>
> The second, I hoped, would enable Gale to give me more diagnostic data about
> the seeming discrepancy between what Finder tells us and what Audacity's log
> tells us, whether the /dnn folders are really empty when Audacity tries to
> delete them.
>
> At this stage, conservatism might argue against taking these commits, as
> they don't fix any real problems for certain.
>
> PRL
>
>
>>
>>
>>
>>
>> > It's rare I'll do a push -f to master, as once other people pull from it
>> > there is a risk of lots of confusion.  But I did this time.  It was as
>> > much my mistake as yours.
>> >
>> >
>> > --James.
>> >
>> >
>> > On 1/25/2017 9:23 PM, Paul Licameli wrote:
>> >> Or shall I push the revert commits myself?
>> >>
>> >> PRL
>> >>
>> >>
>> >> On Wed, Jan 25, 2017 at 4:20 PM, Paul Licameli
>> >> <[hidden email]>
>> >> wrote:
>> >>
>> >>> James, I wanted you to cherry-pick commit 0061cd0 -- not merge it.
>> >>> You
>> >>> took other changes with it, that came before it in my branch that are
>> >>> not
>> >>> yet intended for master.
>> >>>
>> >>> Could you make a hard reset of audacity/master to
>> >>> 97bf72ddb4136cc15a7d1aa03085989c128e881b and then cherry-pick 0061cd0?
>> >>>
>> >>> I am sorry I wasn't clear enough.
>> >>>
>> >>> PRL
>> >>>
>> >>>
>> >>> On Wed, Jan 25, 2017 at 4:05 PM, James Crook <[hidden email]> wrote:
>> >>>
>> >>>> https://github.com/audacity/audacity/commit/bb0fb7f6c240a733
>> >>>> c7a247f88ff393422c0cd8a3
>> >>>>
>> >>>> should fix the slow clean, if it was 0061cd0 at fault.
>> >>>>
>> >>>> --James.
>> >>>>
>> >>>> On 1/25/2017 7:59 PM, Gale Andrews wrote:
>> >>>>> On 25 January 2017 at 18:50, James Crook <[hidden email]> wrote:
>> >>>>>> OK.  Committed to HEAD
>> >>>>>> https://github.com/audacity/audacity/commit/0988c427b9efd31f
>> >>>> 26491712f01cc15b46dac085
>> >>>>> Thanks. As I said though elsewhere, "0061cd0" definitely seems to be
>> >>>>> extending cleanup time by an unwarranted amount on my machine
>> >>>>> that increases not only with the number of folders but also with the
>> >>>>> number of AU files they contain. If I have four projects in
>> >>>>> SessionData,
>> >>>>> three old, each with half an hour of audio, it now takes 20 minutes
>> >>>>> to
>> >>>>> attempt (and fail) at clean up.
>> >>>>>
>> >>>>> Obviously it's 1567 or some friend of it doing this, but I suggest
>> >>>>> we
>> >>>>> don't want that commit in.
>> >>>>>
>> >>>>>
>> >>>>> Gale
>> >>>>>
>> >>>>>
>> >>>>>> On 1/25/2017 5:56 PM, Paul Licameli wrote:
>> >>>>>>> On Wed, Jan 25, 2017 at 12:21 PM, James Crook <[hidden email]>
>> >>>> wrote:
>> >>>>>>>> I am 90% likely to cherry pick this. Before I do though....
>> >>>>>>>>
>> >>>>>>>> 1) is there any known downside to it?  (other perhaps than
>> >>>>>>>> changed
>> >>>> icon
>> >>>>>>>> bouncing behaviour)
>> >>>>>>>> 2) Has dragging of a file into Audacity been tested on a machine
>> >>>>>>>> with
>> >>>>>>>> fork-and-crash?
>> >>>>>>>> 3) What sign/symptom led to the idea of this fix, rather than
>> >>>>>>>> waits?
>> >>>>>>>>
>> >>>>>>>> Thanks.
>> >>>>>>>>
>> >>>>>>>       1. None I know.  I don't see any change in the bounce on El
>> >>>> Capitan.  (I
>> >>>>>>>       saw that my earlier attempts momentarily made two Audacity
>> >>>> icons, but that
>> >>>>>>>       no longer happens, because now I do the fork and crash in
>> >>>>>>> main()
>> >>>> itself,
>> >>>>>>>       before any wxWidgets initializations.)
>> >>>>>> Excellent.
>> >>>>>>
>> >>>>>>
>> >>>>>>>       2. I just tried it in a release build of master plus the
>> >>>> cherry-pick and
>> >>>>>>>       all is well.  As before, you must release the mouse over the
>> >>>> track panel
>> >>>>>>>       area, and it works to import files but not to open .aup
>> >>>>>>> projects.
>> >>>>>> Right, but doCrash is false on your machine, so the fork and crash
>> >>>>>> does
>> >>>>>> not happen?  Or have you upgraded to Sierra?  I'm (for various
>> >>>>>> reasons)
>> >>>>>> staying on El Capitan.
>> >>>>>>
>> >>>>>>
>> >>>>>>>       3. Gale's observation that force-quitting (it had to be a
>> >>>> force-quit) by
>> >>>>>>>       means of the toolbar icon, done soon enough after it
>> >>>>>>> appears,
>> >>>> clears the
>> >>>>>>>       problem if it had happened in the previous run, and reboot
>> >>>>>>> of
>> >>>> the operating
>> >>>>>>>       system was then not needed.  I figured out how to do
>> >>>>>>> something
>> >>>> like that
>> >>>>>>>       automatically.  I determined in the debugger that when you
>> >>>> force-quit, the
>> >>>>>>>       program receives SIGTERM.  So I crash the program by raising
>> >>>> that signal.
>> >>>>>> Ah.  OK.  So the SIGTERM is hypothesised to clear the state.
>> >>>>>>
>> >>>>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > 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...