[vwnc] Build Script

> Hi,
>
> a few week ago I tried James Robertsons build script. Unfortunately the
> error logging does not work. I thought the following lines should set up
> the system to behave in the case of an exception like beeing build with
> Runtimepackager:
>
> "go to deployment"
> DeploymentOptionsSystem current startInRuntime: true.
>
> Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
> RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
> RuntimePackager.RuntimeFullDumper.
> Notifier
> uheFilename: 'error.log';
> logToFile: true.
>
> Instead I get an error notification as attached. The directory is  
> writable
> and It doesn't make a difference whether error.log has to be created or  
> is
> already existing. How do I produce the correct behaviour?
>
> Steffen

> I've posted this previously and brought it up in irc - unfortunately  
> without getting a solution:
>
> I attempt to set up the Notifier of a runtime image to behave like  
> configured with the Runtimepackager (see below), but no error.log is  
> written.
> At the following URLs you can find what is needed for a minimal example:
> http://dl.getdropbox.com/u/106181/errorTest.command
> http://dl.getdropbox.com/u/106181/errorTest.st
>
> I'd be glad about any hint.
>
> Steffen
>
>
>
> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker <[hidden email]>:
>
>  
>> Hi,
>>
>> a few week ago I tried James Robertsons build script. Unfortunately the
>> error logging does not work. I thought the following lines should set up
>> the system to behave in the case of an exception like beeing build with
>> Runtimepackager:
>>
>> "go to deployment"
>> DeploymentOptionsSystem current startInRuntime: true.
>>
>> Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>> RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>> RuntimePackager.RuntimeFullDumper.
>> Notifier
>> uheFilename: 'error.log';
>> logToFile: true.
>>
>> Instead I get an error notification as attached. The directory is  
>> writable
>> and It doesn't make a difference whether error.log has to be created or  
>> is
>> already existing. How do I produce the correct behaviour?
>>
>> Steffen
>>    
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
>
>  

> There is a bug  fix on the Cincom Website at:
>
> http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutionsPortal 
> and look for the resolution #95912
>
> It may help...
>
> Steffen Märcker wrote:
>> I've posted this previously and brought it up in irc - unfortunately  
>> without getting a solution:
>>
>> I attempt to set up the Notifier of a runtime image to behave like  
>> configured with the Runtimepackager (see below), but no error.log is  
>> written.
>> At the following URLs you can find what is needed for a minimal example:
>> http://dl.getdropbox.com/u/106181/errorTest.command
>> http://dl.getdropbox.com/u/106181/errorTest.st
>>
>> I'd be glad about any hint.
>>
>> Steffen
>>
>>
>>
>> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker <[hidden email]>:
>>
>>
>>> Hi,
>>>
>>> a few week ago I tried James Robertsons build script. Unfortunately the
>>> error logging does not work. I thought the following lines should set  
>>> up
>>> the system to behave in the case of an exception like beeing build with
>>> Runtimepackager:
>>>
>>> "go to deployment"
>>> DeploymentOptionsSystem current startInRuntime: true.
>>>
>>> Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>> RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>>> RuntimePackager.RuntimeFullDumper.
>>> Notifier
>>> uheFilename: 'error.log';
>>> logToFile: true.
>>>
>>> Instead I get an error notification as attached. The directory is  
>>> writable
>>> and It doesn't make a difference whether error.log has to be created  
>>> or  is
>>> already existing. How do I produce the correct behaviour?
>>>
>>> Steffen
>>>
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>>
>>
>>
>
>

>Thank you very much, but the fix didn't help - I guess I've misconfigure  
>the Notifer mechanism. But how should it be done?
>
>Greetings, Steffen
>
>
>Am 04.04.2009, 05:56 Uhr, schrieb Mark Pirogovsky  
><[hidden email]>:
>
>> There is a bug  fix on the Cincom Website at:
>>
>> http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutionsPortal 
>> and look for the resolution #95912
>>
>> It may help...
>>
>> Steffen Märcker wrote:
>>> I've posted this previously and brought it up in irc - unfortunately  
>>> without getting a solution:
>>>
>>> I attempt to set up the Notifier of a runtime image to behave like  
>>> configured with the Runtimepackager (see below), but no error.log is  
>>> written.
>>> At the following URLs you can find what is needed for a minimal example:
>>> http://dl.getdropbox.com/u/106181/errorTest.command
>>> http://dl.getdropbox.com/u/106181/errorTest.st
>>>
>>> I'd be glad about any hint.
>>>
>>> Steffen
>>>
>>>
>>>
>>> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker <[hidden email]>:
>>>
>>>
>>>> Hi,
>>>>
>>>> a few week ago I tried James Robertsons build script. Unfortunately the
>>>> error logging does not work. I thought the following lines should set  
>>>> up
>>>> the system to behave in the case of an exception like beeing build with
>>>> Runtimepackager:
>>>>
>>>>     "go to deployment"
>>>>     DeploymentOptionsSystem current startInRuntime: true.
>>>>
>>>>     Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>>>     RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>>>>                     RuntimePackager.RuntimeFullDumper.
>>>>     Notifier
>>>>             uheFilename: 'error.log';
>>>>             logToFile: true.
>>>>
>>>> Instead I get an error notification as attached. The directory is  
>>>> writable
>>>> and It doesn't make a difference whether error.log has to be created  
>>>> or  is
>>>> already existing. How do I produce the correct behaviour?
>>>>
>>>> Steffen
>>>>
>>>
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>
>>>
>>>
>>>
>>
>>
>
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> Different subclasses of ErrorNotifier do different things, and may take  
> their parameters from different palces, mostly for  
> backward-compatibility reasons. That and leftover cruft. It looks like  
> you're setting the error log file in a way that is ignored by the  
> RuntimeEmergencyNotifier. That class is there for backward-compatibility  
> with Runtime Packager, and there are stack dumping facilities available  
> in the base system. But if you want the Runtime Packager exact  
> behaviour, then you need to tell Runtime Packager's facilities what the  
> filename is. So,
>
>         Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>         RuntimeEmergencyNotifier imageDumperClass: RuntimeFullDumper.
>         RuntimeManager errorLogPath: 'foo.log'.
>
> And no, I didn't remember that off the top of my head.  A useful  
> debugging technique in this sort of scenario is something like
>        [3 seconds wait. Notifier current: DebuggerService] fork.
>         3 zork.
>
> Then, if you're getting one of those "the application will now quit"  
> dialogs, wait 3 seconds and hit control-y.
>
> At 05:58 AM 4/4/2009, Steffen Märcker wrote:
>> Thank you very much, but the fix didn't help - I guess I've misconfigure
>> the Notifer mechanism. But how should it be done?
>>
>> Greetings, Steffen
>>
>>
>> Am 04.04.2009, 05:56 Uhr, schrieb Mark Pirogovsky
>> <[hidden email]>:
>>
>>> There is a bug  fix on the Cincom Website at:
>>>
>>> http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutionsPortal
>>> and look for the resolution #95912
>>>
>>> It may help...
>>>
>>> Steffen Märcker wrote:
>>>> I've posted this previously and brought it up in irc - unfortunately
>>>> without getting a solution:
>>>>
>>>> I attempt to set up the Notifier of a runtime image to behave like
>>>> configured with the Runtimepackager (see below), but no error.log is
>>>> written.
>>>> At the following URLs you can find what is needed for a minimal  
>>>> example:
>>>> http://dl.getdropbox.com/u/106181/errorTest.command
>>>> http://dl.getdropbox.com/u/106181/errorTest.st
>>>>
>>>> I'd be glad about any hint.
>>>>
>>>> Steffen
>>>>
>>>>
>>>>
>>>> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker <[hidden email]>:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> a few week ago I tried James Robertsons build script. Unfortunately  
>>>>> the
>>>>> error logging does not work. I thought the following lines should set
>>>>> up
>>>>> the system to behave in the case of an exception like beeing build  
>>>>> with
>>>>> Runtimepackager:
>>>>>
>>>>>     "go to deployment"
>>>>>     DeploymentOptionsSystem current startInRuntime: true.
>>>>>
>>>>>     Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>>>>     RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>>>>>                     RuntimePackager.RuntimeFullDumper.
>>>>>     Notifier
>>>>>             uheFilename: 'error.log';
>>>>>             logToFile: true.
>>>>>
>>>>> Instead I get an error notification as attached. The directory is
>>>>> writable
>>>>> and It doesn't make a difference whether error.log has to be created
>>>>> or  is
>>>>> already existing. How do I produce the correct behaviour?
>>>>>
>>>>> Steffen
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> vwnc mailing list
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> --
> Alan Knight [|], Engineering Manager, Cincom Smalltalk
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>

>Thank you very much, I'll try it this afternoon! If the  
>RuntimeEmergencyNotifier is for backward-compatibility, which are the  
>stack dumping facilities available alternatively?
>
>Steffen
>
>Am 07.04.2009, 00:54 Uhr, schrieb Alan Knight <[hidden email]>:
>
>>Different subclasses of ErrorNotifier do different things, and may take  
>>their parameters from different palces, mostly for  
>>backward-compatibility reasons. That and leftover cruft. It looks like  
>>you're setting the error log file in a way that is ignored by the  
>>RuntimeEmergencyNotifier. That class is there for backward-compatibility  
>>with Runtime Packager, and there are stack dumping facilities available  
>>in the base system. But if you want the Runtime Packager exact  
>>behaviour, then you need to tell Runtime Packager's facilities what the  
>>filename is. So,
>>
>>        Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>        RuntimeEmergencyNotifier imageDumperClass: RuntimeFullDumper.
>>        RuntimeManager errorLogPath: 'foo.log'.
>>
>>And no, I didn't remember that off the top of my head.  A useful  
>>debugging technique in this sort of scenario is something like
>>       [3 seconds wait. Notifier current: DebuggerService] fork.
>>        3 zork.
>>
>>Then, if you're getting one of those "the application will now quit"  
>>dialogs, wait 3 seconds and hit control-y.
>>
>>At 05:58 AM 4/4/2009, Steffen Märcker wrote:
>>>Thank you very much, but the fix didn't help - I guess I've misconfigure
>>>the Notifer mechanism. But how should it be done?
>>>
>>>Greetings, Steffen
>>>
>>>
>>>Am 04.04.2009, 05:56 Uhr, schrieb Mark Pirogovsky
>>><[hidden email]>:
>>>
>>>>There is a bug  fix on the Cincom Website at:
>>>>
>>>>http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutionsPortal
>>>>and look for the resolution #95912
>>>>
>>>>It may help...
>>>>
>>>>Steffen Märcker wrote:
>>>>>I've posted this previously and brought it up in irc - unfortunately
>>>>>without getting a solution:
>>>>>
>>>>>I attempt to set up the Notifier of a runtime image to behave like
>>>>>configured with the Runtimepackager (see below), but no error.log is
>>>>>written.
>>>>>At the following URLs you can find what is needed for a minimal  
>>>>>example:
>>>>>http://dl.getdropbox.com/u/106181/errorTest.command
>>>>>http://dl.getdropbox.com/u/106181/errorTest.st
>>>>>
>>>>>I'd be glad about any hint.
>>>>>
>>>>>Steffen
>>>>>
>>>>>
>>>>>
>>>>>Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker <[hidden email]>:
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>a few week ago I tried James Robertsons build script. Unfortunately  
>>>>>>the
>>>>>>error logging does not work. I thought the following lines should set
>>>>>>up
>>>>>>the system to behave in the case of an exception like beeing build  
>>>>>>with
>>>>>>Runtimepackager:
>>>>>>
>>>>>>    "go to deployment"
>>>>>>    DeploymentOptionsSystem current startInRuntime: true.
>>>>>>
>>>>>>    Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>>>>>    RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>>>>>>                    RuntimePackager.RuntimeFullDumper.
>>>>>>    Notifier
>>>>>>            uheFilename: 'error.log';
>>>>>>            logToFile: true.
>>>>>>
>>>>>>Instead I get an error notification as attached. The directory is
>>>>>>writable
>>>>>>and It doesn't make a difference whether error.log has to be created
>>>>>>or  is
>>>>>>already existing. How do I produce the correct behaviour?
>>>>>>
>>>>>>Steffen
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>vwnc mailing list
>>>>>[hidden email]
>>>>>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>_______________________________________________
>>>vwnc mailing list
>>>[hidden email]
>>>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>>--
>>Alan Knight [|], Engineering Manager, Cincom Smalltalk
>>[hidden email]
>>[hidden email]
>>http://www.cincom.com/smalltalk
>

> The simplest is just to use
>    Notifier current: ErrorNotifier.
>
> At 02:01 AM 4/7/2009, Steffen Märcker wrote:
>> Thank you very much, I'll try it this afternoon! If the
>> RuntimeEmergencyNotifier is for backward-compatibility, which are the
>> stack dumping facilities available alternatively?
>>
>> Steffen
>>
>> Am 07.04.2009, 00:54 Uhr, schrieb Alan Knight <[hidden email]>:
>>
>>> Different subclasses of ErrorNotifier do different things, and may take
>>> their parameters from different palces, mostly for
>>> backward-compatibility reasons. That and leftover cruft. It looks like
>>> you're setting the error log file in a way that is ignored by the
>>> RuntimeEmergencyNotifier. That class is there for  
>>> backward-compatibility
>>> with Runtime Packager, and there are stack dumping facilities available
>>> in the base system. But if you want the Runtime Packager exact
>>> behaviour, then you need to tell Runtime Packager's facilities what the
>>> filename is. So,
>>>
>>>        Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>>        RuntimeEmergencyNotifier imageDumperClass: RuntimeFullDumper.
>>>        RuntimeManager errorLogPath: 'foo.log'.
>>>
>>> And no, I didn't remember that off the top of my head.  A useful
>>> debugging technique in this sort of scenario is something like
>>>       [3 seconds wait. Notifier current: DebuggerService] fork.
>>>        3 zork.
>>>
>>> Then, if you're getting one of those "the application will now quit"
>>> dialogs, wait 3 seconds and hit control-y.
>>>
>>> At 05:58 AM 4/4/2009, Steffen Märcker wrote:
>>>> Thank you very much, but the fix didn't help - I guess I've  
>>>> misconfigure
>>>> the Notifer mechanism. But how should it be done?
>>>>
>>>> Greetings, Steffen
>>>>
>>>>
>>>> Am 04.04.2009, 05:56 Uhr, schrieb Mark Pirogovsky
>>>> <[hidden email]>:
>>>>
>>>>> There is a bug  fix on the Cincom Website at:
>>>>>
>>>>> http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutionsPortal
>>>>> and look for the resolution #95912
>>>>>
>>>>> It may help...
>>>>>
>>>>> Steffen Märcker wrote:
>>>>>> I've posted this previously and brought it up in irc - unfortunately
>>>>>> without getting a solution:
>>>>>>
>>>>>> I attempt to set up the Notifier of a runtime image to behave like
>>>>>> configured with the Runtimepackager (see below), but no error.log is
>>>>>> written.
>>>>>> At the following URLs you can find what is needed for a minimal
>>>>>> example:
>>>>>> http://dl.getdropbox.com/u/106181/errorTest.command
>>>>>> http://dl.getdropbox.com/u/106181/errorTest.st
>>>>>>
>>>>>> I'd be glad about any hint.
>>>>>>
>>>>>> Steffen
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker <[hidden email]>:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> a few week ago I tried James Robertsons build script. Unfortunately
>>>>>>> the
>>>>>>> error logging does not work. I thought the following lines should  
>>>>>>> set
>>>>>>> up
>>>>>>> the system to behave in the case of an exception like beeing build
>>>>>>> with
>>>>>>> Runtimepackager:
>>>>>>>
>>>>>>>    "go to deployment"
>>>>>>>    DeploymentOptionsSystem current startInRuntime: true.
>>>>>>>
>>>>>>>    Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>>>>>>    RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>>>>>>>                    RuntimePackager.RuntimeFullDumper.
>>>>>>>    Notifier
>>>>>>>            uheFilename: 'error.log';
>>>>>>>            logToFile: true.
>>>>>>>
>>>>>>> Instead I get an error notification as attached. The directory is
>>>>>>> writable
>>>>>>> and It doesn't make a difference whether error.log has to be  
>>>>>>> created
>>>>>>> or  is
>>>>>>> already existing. How do I produce the correct behaviour?
>>>>>>>
>>>>>>> Steffen
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> vwnc mailing list
>>>>>> [hidden email]
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> vwnc mailing list
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>
>>> --
>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>>> [hidden email]
>>> [hidden email]
>>> http://www.cincom.com/smalltalk
>>
>
> --
> Alan Knight [|], Engineering Manager, Cincom Smalltalk
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>

> This sounds like the old VW bug, where #canBeWritten is simply wrong for Windows. In Windows a read-only attribute on a directory means that the directory itself cannot be modified, not that files cannot be written into it. I've attached the fix - I've no idea why this isn't in the base yet.
>
> Steve
>
>  
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Steffen Märcker
>> Sent: 08 April 2009 15:41
>> To: Alan Knight; vwnc
>> Subject: Re: [vwnc] How to configure Runtime Notifier?
>>
>> Dear Alan Knight,
>>
>> I've just looked into the problem, that an error.log is not written, if
>> it
>> has to be created on Vistas Desktop. This is caused by the fact that
>> '<path to your profile>\Desktop' canBeWritten
>> evaluates to false. This happens on All Vista Systems (no
>> administrative
>> rights) I've looked at today. But in fact you can write to that
>> directory,
>> e.g.
>> '<path to your profile>\Desktop\test.log' writeStream nextPutAll:
>> 'foo';
>> close.
>> Is this a bug (Vista, VW) or does it happen only on the systems here?
>>
>> Greetings,
>> Steffen
>>
>>
>> Am 07.04.2009, 19:03 Uhr, schrieb Alan Knight <[hidden email]>:
>>
>>    
>>> The simplest is just to use
>>>    Notifier current: ErrorNotifier.
>>>
>>> At 02:01 AM 4/7/2009, Steffen Märcker wrote:
>>>      
>>>> Thank you very much, I'll try it this afternoon! If the
>>>> RuntimeEmergencyNotifier is for backward-compatibility, which are
>>>>        
>> the
>>    
>>>> stack dumping facilities available alternatively?
>>>>
>>>> Steffen
>>>>
>>>> Am 07.04.2009, 00:54 Uhr, schrieb Alan Knight <[hidden email]>:
>>>>
>>>>        
>>>>> Different subclasses of ErrorNotifier do different things, and may
>>>>>          
>> take
>>    
>>>>> their parameters from different palces, mostly for
>>>>> backward-compatibility reasons. That and leftover cruft. It looks
>>>>>          
>> like
>>    
>>>>> you're setting the error log file in a way that is ignored by the
>>>>> RuntimeEmergencyNotifier. That class is there for
>>>>> backward-compatibility
>>>>> with Runtime Packager, and there are stack dumping facilities
>>>>>          
>> available
>>    
>>>>> in the base system. But if you want the Runtime Packager exact
>>>>> behaviour, then you need to tell Runtime Packager's facilities what
>>>>>          
>> the
>>    
>>>>> filename is. So,
>>>>>
>>>>>        Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>>>>        RuntimeEmergencyNotifier imageDumperClass: RuntimeFullDumper.
>>>>>        RuntimeManager errorLogPath: 'foo.log'.
>>>>>
>>>>> And no, I didn't remember that off the top of my head.  A useful
>>>>> debugging technique in this sort of scenario is something like
>>>>>       [3 seconds wait. Notifier current: DebuggerService] fork.
>>>>>        3 zork.
>>>>>
>>>>> Then, if you're getting one of those "the application will now
>>>>>          
>> quit"
>>    
>>>>> dialogs, wait 3 seconds and hit control-y.
>>>>>
>>>>> At 05:58 AM 4/4/2009, Steffen Märcker wrote:
>>>>>          
>>>>>> Thank you very much, but the fix didn't help - I guess I've
>>>>>> misconfigure
>>>>>> the Notifer mechanism. But how should it be done?
>>>>>>
>>>>>> Greetings, Steffen
>>>>>>
>>>>>>
>>>>>> Am 04.04.2009, 05:56 Uhr, schrieb Mark Pirogovsky
>>>>>> <[hidden email]>:
>>>>>>
>>>>>>            
>>>>>>> There is a bug  fix on the Cincom Website at:
>>>>>>>
>>>>>>>
>>>>>>>              
>> http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutions
>> Portal
>>    
>>>>>>> and look for the resolution #95912
>>>>>>>
>>>>>>> It may help...
>>>>>>>
>>>>>>> Steffen Märcker wrote:
>>>>>>>              
>>>>>>>> I've posted this previously and brought it up in irc -
>>>>>>>>                
>> unfortunately
>>    
>>>>>>>> without getting a solution:
>>>>>>>>
>>>>>>>> I attempt to set up the Notifier of a runtime image to behave
>>>>>>>>                
>> like
>>    
>>>>>>>> configured with the Runtimepackager (see below), but no
>>>>>>>>                
>> error.log is
>>    
>>>>>>>> written.
>>>>>>>> At the following URLs you can find what is needed for a minimal
>>>>>>>> example:
>>>>>>>> http://dl.getdropbox.com/u/106181/errorTest.command
>>>>>>>> http://dl.getdropbox.com/u/106181/errorTest.st
>>>>>>>>
>>>>>>>> I'd be glad about any hint.
>>>>>>>>
>>>>>>>> Steffen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker
>>>>>>>>                
>> <[hidden email]>:
>>    
>>>>>>>>                
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> a few week ago I tried James Robertsons build script.
>>>>>>>>>                  
>> Unfortunately
>>    
>>>>>>>>> the
>>>>>>>>> error logging does not work. I thought the following lines
>>>>>>>>>                  
>> should
>>    
>>>>>>>>> set
>>>>>>>>> up
>>>>>>>>> the system to behave in the case of an exception like beeing
>>>>>>>>>                  
>> build
>>    
>>>>>>>>> with
>>>>>>>>> Runtimepackager:
>>>>>>>>>
>>>>>>>>>    "go to deployment"
>>>>>>>>>    DeploymentOptionsSystem current startInRuntime: true.
>>>>>>>>>
>>>>>>>>>    Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>>>>>>>>    RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>>>>>>>>>                    RuntimePackager.RuntimeFullDumper.
>>>>>>>>>    Notifier
>>>>>>>>>            uheFilename: 'error.log';
>>>>>>>>>            logToFile: true.
>>>>>>>>>
>>>>>>>>> Instead I get an error notification as attached. The directory
>>>>>>>>>                  
>> is
>>    
>>>>>>>>> writable
>>>>>>>>> and It doesn't make a difference whether error.log has to be
>>>>>>>>> created
>>>>>>>>> or  is
>>>>>>>>> already existing. How do I produce the correct behaviour?
>>>>>>>>>
>>>>>>>>> Steffen
>>>>>>>>>                  
>>>>>>>> _______________________________________________
>>>>>>>> vwnc mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>> _______________________________________________
>>>>>> vwnc mailing list
>>>>>> [hidden email]
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>>>            
>>>>> --
>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>>>>> [hidden email]
>>>>> [hidden email]
>>>>> http://www.cincom.com/smalltalk
>>>>>          
>>> --
>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>>> [hidden email]
>>> [hidden email]
>>> http://www.cincom.com/smalltalk
>>>
>>>      
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>    
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>    

> This sounds like the old VW bug, where #canBeWritten is simply wrong for  
> Windows. In Windows a read-only attribute on a directory means that the  
> directory itself cannot be modified, not that files cannot be written  
> into it. I've attached the fix - I've no idea why this isn't in the base  
> yet.
>
> Steve
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Steffen Märcker
>> Sent: 08 April 2009 15:41
>> To: Alan Knight; vwnc
>> Subject: Re: [vwnc] How to configure Runtime Notifier?
>>
>> Dear Alan Knight,
>>
>> I've just looked into the problem, that an error.log is not written, if
>> it
>> has to be created on Vistas Desktop. This is caused by the fact that
>> '<path to your profile>\Desktop' canBeWritten
>> evaluates to false. This happens on All Vista Systems (no
>> administrative
>> rights) I've looked at today. But in fact you can write to that
>> directory,
>> e.g.
>> '<path to your profile>\Desktop\test.log' writeStream nextPutAll:
>> 'foo';
>> close.
>> Is this a bug (Vista, VW) or does it happen only on the systems here?
>>
>> Greetings,
>> Steffen
>>
>>
>> Am 07.04.2009, 19:03 Uhr, schrieb Alan Knight <[hidden email]>:
>>
>> > The simplest is just to use
>> >    Notifier current: ErrorNotifier.
>> >
>> > At 02:01 AM 4/7/2009, Steffen Märcker wrote:
>> >> Thank you very much, I'll try it this afternoon! If the
>> >> RuntimeEmergencyNotifier is for backward-compatibility, which are
>> the
>> >> stack dumping facilities available alternatively?
>> >>
>> >> Steffen
>> >>
>> >> Am 07.04.2009, 00:54 Uhr, schrieb Alan Knight <[hidden email]>:
>> >>
>> >>> Different subclasses of ErrorNotifier do different things, and may
>> take
>> >>> their parameters from different palces, mostly for
>> >>> backward-compatibility reasons. That and leftover cruft. It looks
>> like
>> >>> you're setting the error log file in a way that is ignored by the
>> >>> RuntimeEmergencyNotifier. That class is there for
>> >>> backward-compatibility
>> >>> with Runtime Packager, and there are stack dumping facilities
>> available
>> >>> in the base system. But if you want the Runtime Packager exact
>> >>> behaviour, then you need to tell Runtime Packager's facilities what
>> the
>> >>> filename is. So,
>> >>>
>> >>>        Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>> >>>        RuntimeEmergencyNotifier imageDumperClass: RuntimeFullDumper.
>> >>>        RuntimeManager errorLogPath: 'foo.log'.
>> >>>
>> >>> And no, I didn't remember that off the top of my head.  A useful
>> >>> debugging technique in this sort of scenario is something like
>> >>>       [3 seconds wait. Notifier current: DebuggerService] fork.
>> >>>        3 zork.
>> >>>
>> >>> Then, if you're getting one of those "the application will now
>> quit"
>> >>> dialogs, wait 3 seconds and hit control-y.
>> >>>
>> >>> At 05:58 AM 4/4/2009, Steffen Märcker wrote:
>> >>>> Thank you very much, but the fix didn't help - I guess I've
>> >>>> misconfigure
>> >>>> the Notifer mechanism. But how should it be done?
>> >>>>
>> >>>> Greetings, Steffen
>> >>>>
>> >>>>
>> >>>> Am 04.04.2009, 05:56 Uhr, schrieb Mark Pirogovsky
>> >>>> <[hidden email]>:
>> >>>>
>> >>>>> There is a bug  fix on the Cincom Website at:
>> >>>>>
>> >>>>>
>> http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutions
>> Portal
>> >>>>> and look for the resolution #95912
>> >>>>>
>> >>>>> It may help...
>> >>>>>
>> >>>>> Steffen Märcker wrote:
>> >>>>>> I've posted this previously and brought it up in irc -
>> unfortunately
>> >>>>>> without getting a solution:
>> >>>>>>
>> >>>>>> I attempt to set up the Notifier of a runtime image to behave
>> like
>> >>>>>> configured with the Runtimepackager (see below), but no
>> error.log is
>> >>>>>> written.
>> >>>>>> At the following URLs you can find what is needed for a minimal
>> >>>>>> example:
>> >>>>>> http://dl.getdropbox.com/u/106181/errorTest.command
>> >>>>>> http://dl.getdropbox.com/u/106181/errorTest.st
>> >>>>>>
>> >>>>>> I'd be glad about any hint.
>> >>>>>>
>> >>>>>> Steffen
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker
>> <[hidden email]>:
>> >>>>>>
>> >>>>>>
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>> a few week ago I tried James Robertsons build script.
>> Unfortunately
>> >>>>>>> the
>> >>>>>>> error logging does not work. I thought the following lines
>> should
>> >>>>>>> set
>> >>>>>>> up
>> >>>>>>> the system to behave in the case of an exception like beeing
>> build
>> >>>>>>> with
>> >>>>>>> Runtimepackager:
>> >>>>>>>
>> >>>>>>>    "go to deployment"
>> >>>>>>>    DeploymentOptionsSystem current startInRuntime: true.
>> >>>>>>>
>> >>>>>>>    Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>> >>>>>>>    RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>> >>>>>>>                    RuntimePackager.RuntimeFullDumper.
>> >>>>>>>    Notifier
>> >>>>>>>            uheFilename: 'error.log';
>> >>>>>>>            logToFile: true.
>> >>>>>>>
>> >>>>>>> Instead I get an error notification as attached. The directory
>> is
>> >>>>>>> writable
>> >>>>>>> and It doesn't make a difference whether error.log has to be
>> >>>>>>> created
>> >>>>>>> or  is
>> >>>>>>> already existing. How do I produce the correct behaviour?
>> >>>>>>>
>> >>>>>>> Steffen
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> vwnc mailing list
>> >>>>>> [hidden email]
>> >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> vwnc mailing list
>> >>>> [hidden email]
>> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>> >>>
>> >>> --
>> >>> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>> >>> [hidden email]
>> >>> [hidden email]
>> >>> http://www.cincom.com/smalltalk
>> >>
>> >
>> > --
>> > Alan Knight [|], Engineering Manager, Cincom Smalltalk
>> > [hidden email]
>> > [hidden email]
>> > http://www.cincom.com/smalltalk
>> >
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> I'll test your fix tomorrow. Thank you very much for sharing it!
>
> Good Night!
> Steffen Märcker
>
> Am 08.04.2009, 18:36 Uhr, schrieb Steven Kelly <[hidden email]>:
>
>> This sounds like the old VW bug, where #canBeWritten is simply wrong for
>> Windows. In Windows a read-only attribute on a directory means that the
>> directory itself cannot be modified, not that files cannot be written
>> into it. I've attached the fix - I've no idea why this isn't in the base
>> yet.
>>
>> Steve
>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]] On
>>> Behalf Of Steffen Märcker
>>> Sent: 08 April 2009 15:41
>>> To: Alan Knight; vwnc
>>> Subject: Re: [vwnc] How to configure Runtime Notifier?
>>>
>>> Dear Alan Knight,
>>>
>>> I've just looked into the problem, that an error.log is not written, if
>>> it
>>> has to be created on Vistas Desktop. This is caused by the fact that
>>> '<path to your profile>\Desktop' canBeWritten
>>> evaluates to false. This happens on All Vista Systems (no
>>> administrative
>>> rights) I've looked at today. But in fact you can write to that
>>> directory,
>>> e.g.
>>> '<path to your profile>\Desktop\test.log' writeStream nextPutAll:
>>> 'foo';
>>> close.
>>> Is this a bug (Vista, VW) or does it happen only on the systems here?
>>>
>>> Greetings,
>>> Steffen
>>>
>>>
>>> Am 07.04.2009, 19:03 Uhr, schrieb Alan Knight <[hidden email]>:
>>>
>>> > The simplest is just to use
>>> >    Notifier current: ErrorNotifier.
>>> >
>>> > At 02:01 AM 4/7/2009, Steffen Märcker wrote:
>>> >> Thank you very much, I'll try it this afternoon! If the
>>> >> RuntimeEmergencyNotifier is for backward-compatibility, which are
>>> the
>>> >> stack dumping facilities available alternatively?
>>> >>
>>> >> Steffen
>>> >>
>>> >> Am 07.04.2009, 00:54 Uhr, schrieb Alan Knight <[hidden email]>:
>>> >>
>>> >>> Different subclasses of ErrorNotifier do different things, and may
>>> take
>>> >>> their parameters from different palces, mostly for
>>> >>> backward-compatibility reasons. That and leftover cruft. It looks
>>> like
>>> >>> you're setting the error log file in a way that is ignored by the
>>> >>> RuntimeEmergencyNotifier. That class is there for
>>> >>> backward-compatibility
>>> >>> with Runtime Packager, and there are stack dumping facilities
>>> available
>>> >>> in the base system. But if you want the Runtime Packager exact
>>> >>> behaviour, then you need to tell Runtime Packager's facilities what
>>> the
>>> >>> filename is. So,
>>> >>>
>>> >>>        Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>> >>>        RuntimeEmergencyNotifier imageDumperClass:  
>>> RuntimeFullDumper.
>>> >>>        RuntimeManager errorLogPath: 'foo.log'.
>>> >>>
>>> >>> And no, I didn't remember that off the top of my head.  A useful
>>> >>> debugging technique in this sort of scenario is something like
>>> >>>       [3 seconds wait. Notifier current: DebuggerService] fork.
>>> >>>        3 zork.
>>> >>>
>>> >>> Then, if you're getting one of those "the application will now
>>> quit"
>>> >>> dialogs, wait 3 seconds and hit control-y.
>>> >>>
>>> >>> At 05:58 AM 4/4/2009, Steffen Märcker wrote:
>>> >>>> Thank you very much, but the fix didn't help - I guess I've
>>> >>>> misconfigure
>>> >>>> the Notifer mechanism. But how should it be done?
>>> >>>>
>>> >>>> Greetings, Steffen
>>> >>>>
>>> >>>>
>>> >>>> Am 04.04.2009, 05:56 Uhr, schrieb Mark Pirogovsky
>>> >>>> <[hidden email]>:
>>> >>>>
>>> >>>>> There is a bug  fix on the Cincom Website at:
>>> >>>>>
>>> >>>>>
>>> http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutions
>>> Portal
>>> >>>>> and look for the resolution #95912
>>> >>>>>
>>> >>>>> It may help...
>>> >>>>>
>>> >>>>> Steffen Märcker wrote:
>>> >>>>>> I've posted this previously and brought it up in irc -
>>> unfortunately
>>> >>>>>> without getting a solution:
>>> >>>>>>
>>> >>>>>> I attempt to set up the Notifier of a runtime image to behave
>>> like
>>> >>>>>> configured with the Runtimepackager (see below), but no
>>> error.log is
>>> >>>>>> written.
>>> >>>>>> At the following URLs you can find what is needed for a minimal
>>> >>>>>> example:
>>> >>>>>> http://dl.getdropbox.com/u/106181/errorTest.command
>>> >>>>>> http://dl.getdropbox.com/u/106181/errorTest.st
>>> >>>>>>
>>> >>>>>> I'd be glad about any hint.
>>> >>>>>>
>>> >>>>>> Steffen
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Am 26.03.2009, 15:13 Uhr, schrieb Steffen Märcker
>>> <[hidden email]>:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>> Hi,
>>> >>>>>>>
>>> >>>>>>> a few week ago I tried James Robertsons build script.
>>> Unfortunately
>>> >>>>>>> the
>>> >>>>>>> error logging does not work. I thought the following lines
>>> should
>>> >>>>>>> set
>>> >>>>>>> up
>>> >>>>>>> the system to behave in the case of an exception like beeing
>>> build
>>> >>>>>>> with
>>> >>>>>>> Runtimepackager:
>>> >>>>>>>
>>> >>>>>>>    "go to deployment"
>>> >>>>>>>    DeploymentOptionsSystem current startInRuntime: true.
>>> >>>>>>>
>>> >>>>>>>    Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
>>> >>>>>>>    RuntimePackager.RuntimeEmergencyNotifier imageDumperClass:
>>> >>>>>>>                    RuntimePackager.RuntimeFullDumper.
>>> >>>>>>>    Notifier
>>> >>>>>>>            uheFilename: 'error.log';
>>> >>>>>>>            logToFile: true.
>>> >>>>>>>
>>> >>>>>>> Instead I get an error notification as attached. The directory
>>> is
>>> >>>>>>> writable
>>> >>>>>>> and It doesn't make a difference whether error.log has to be
>>> >>>>>>> created
>>> >>>>>>> or  is
>>> >>>>>>> already existing. How do I produce the correct behaviour?
>>> >>>>>>>
>>> >>>>>>> Steffen
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> vwnc mailing list
>>> >>>>>> [hidden email]
>>> >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> vwnc mailing list
>>> >>>> [hidden email]
>>> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>> >>>
>>> >>> --
>>> >>> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>>> >>> [hidden email]
>>> >>> [hidden email]
>>> >>> http://www.cincom.com/smalltalk
>>> >>
>>> >
>>> > --
>>> > Alan Knight [|], Engineering Manager, Cincom Smalltalk
>>> > [hidden email]
>>> > [hidden email]
>>> > http://www.cincom.com/smalltalk
>>> >
>>>
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc