[Pharo-project] a way to ignore warnings?
Hi, Is there a way to tell Pharo to ignore warning blocking messages? you those messages where you can press "proceed" and continue, for instance, loading a monticello package. cheers, Esteban
duh... [ ... ] on: Warning do: [ :w | w resume ]. forget my question... :( cheers, Esteban Inicio del mensaje reenviado:
De: Esteban Lorenzano <estebanlm@gmail.com> Fecha: 20 de diciembre de 2010 21:22:49 GMT-03:00 Para: Pharo Development <pharo-project@lists.gforge.inria.fr> Asunto: a way to ignore warnings?
Hi, Is there a way to tell Pharo to ignore warning blocking messages? you those messages where you can press "proceed" and continue, for instance, loading a monticello package.
cheers, Esteban
2010/12/20 Esteban Lorenzano <estebanlm@gmail.com>:
duh... [ ... ] on: Warning do: [ :w | w resume ]. forget my question... :(
That wouldn't make it for Notifications such as: self inform: 'test' so you might want to write: [ self inform: 'test' ] on: Warning, Notification do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText ]. Cheers,
cheers, Esteban
Inicio del mensaje reenviado:
De: Esteban Lorenzano <estebanlm@gmail.com> Fecha: 20 de diciembre de 2010 21:22:49 GMT-03:00 Para: Pharo Development <pharo-project@lists.gforge.inria.fr> Asunto: a way to ignore warnings?
Hi, Is there a way to tell Pharo to ignore warning blocking messages? you those messages where you can press "proceed" and continue, for instance, loading a monticello package.
cheers, Esteban
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
BlockClosure>>#valueSupplyingAnswer: and friends are also useful. Cheers, Adrian On Dec 21, 2010, at 06:27 , Hernán Morales Durand wrote:
2010/12/20 Esteban Lorenzano <estebanlm@gmail.com>:
duh... [ ... ] on: Warning do: [ :w | w resume ]. forget my question... :(
That wouldn't make it for Notifications such as:
self inform: 'test'
so you might want to write:
[ self inform: 'test' ] on: Warning, Notification do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText ].
Cheers,
cheers, Esteban
Inicio del mensaje reenviado:
De: Esteban Lorenzano <estebanlm@gmail.com> Fecha: 20 de diciembre de 2010 21:22:49 GMT-03:00 Para: Pharo Development <pharo-project@lists.gforge.inria.fr> Asunto: a way to ignore warnings?
Hi, Is there a way to tell Pharo to ignore warning blocking messages? you those messages where you can press "proceed" and continue, for instance, loading a monticello package.
cheers, Esteban
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
On 12/20/2010 09:27 PM, Hernán Morales Durand wrote:
2010/12/20 Esteban Lorenzano<estebanlm@gmail.com>:
duh... [ ... ] on: Warning do: [ :w | w resume ]. forget my question... :(
That wouldn't make it for Notifications such as:
self inform: 'test'
so you might want to write:
[ self inform: 'test' ] on: Warning, Notification do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText ].
I would be careful about handling all Notifications. Unlike Error, there is no "correct" pattern for handling Notifications, just take a look at all implementors of #defaultAction for subclasses of Notification and you will see that in most cases, the default action returns an application specific object, so returning a String instead will break them all .. Notifications are meant to be ignored unless you know what you are doing. It turns out that even handling Warning can be dangerous. For Warning it is correct to use #resume to ignore the Warning (which ends up doing a `ex resume: nil`). However, UndeclaredVariableWarning (a subclass of Warning) expects a Boolean result, so if the code you are wrapping does any compiles you'll have to special case UndeclaredVariableWarning to do `ex resume: true`. To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better choice than Notification, but you need to be aware of the implications of ignoring inform: as ProvideAnswerNotification is used for dealing with: inform: - return value is ignored confirm:: - return values is expected to be a Boolean request: - is expected to be a String As Adrian mentions, if you are want to automate the handling of inform:/confirm:/request: you are better off using valueSupplyingAnswers:. Finally, in the above example using 'ex return:'a string` is not the correct way to ignore a Warning or Notification. The #return: messages returns the arg as the result of the block (unwinding the stack). #resume: returns the arg as the result of the #signal: and continues execution from that point. Take a look at the different results for the following two expressions: | w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex return: false ]. {w. x. y. z.}. | w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex resume: false ]. {w. x. y. z.}. Hernán this is common mistake when putting together simple examples and if I hadn't just finished writing a series of automatic Warning handlers, I wouldn't have picked up on it:) Dale
Hi Dale, Thanks for your comments, some notes between lines... 2010/12/21 Dale Henrichs <dhenrich@vmware.com>:
On 12/20/2010 09:27 PM, Hernán Morales Durand wrote:
2010/12/20 Esteban Lorenzano<estebanlm@gmail.com>:
duh... [ ... ] on: Warning do: [ :w | w resume ]. forget my question... :(
That wouldn't make it for Notifications such as:
self inform: 'test'
so you might want to write:
[ self inform: 'test' ] on: Warning, Notification do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText ].
I would be careful about handling all Notifications. Unlike Error, there is no "correct" pattern for handling Notifications, just take a look at all implementors of #defaultAction for subclasses of Notification and you will see that in most cases, the default action returns an application specific object, so returning a String instead will break them all ..
Notifications are meant to be ignored unless you know what you are doing.
Agree. Although I think you're focusing on handling properly the answer but Esteban just wanted to bypass modal dialogs so a time consuming operation could finish without human intervention. In that case we can assume he isn't going to provide a "dangerous" default for a confirm operation and he'd like to log warnings and informations. Esteban may you comment is that your case?
It turns out that even handling Warning can be dangerous. For Warning it is correct to use #resume to ignore the Warning (which ends up doing a `ex resume: nil`). However, UndeclaredVariableWarning (a subclass of Warning) expects a Boolean result, so if the code you are wrapping does any compiles you'll have to special case UndeclaredVariableWarning to do `ex resume: true`.
Yes, I've seen the UndeclaredVariableWarning (from Encoder>>undeclared: ) dialog many times when compiling programatically, and one of things is that I have to handle every compilation to avoid this dialog like this: [ self targetClass compile: aString classified: aCategoryClassification ] on: UndeclaredVariableWarning do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self targetClass asString , '>>' , aString asString ] I didn't found a preference to ignore this dialog, although I've found Parser warningAllowed -> false "That would be the More Warnings preference " I wonder is there a setting I've missed?
To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better choice than Notification, but you need to be aware of the implications of ignoring inform: as ProvideAnswerNotification is used for dealing with:
 inform:      - return value is ignored  confirm::     - return values is expected to be a Boolean  request:      - is expected to be a String
As Adrian mentions, if you are want to automate the handling of inform:/confirm:/request: you are better off using valueSupplyingAnswers:.
Finally, in the above example using 'ex return:'a string` is not the correct way to ignore a Warning or Notification. The #return: messages returns the arg as the result of the block (unwinding the stack). #resume: returns the arg as the result of the #signal: and continues execution from that point. Take a look at the different results for the following two expressions:
| w x y z | w := x:= y:= z:= nil. x:= [ w := #before.     y:= self confirm: 'test'.     z := #after ]         on: ProvideAnswerNotification         do: [:ex | ex return: false ]. {w. x. y. z.}.
| w x y z | w := x:= y:= z:= nil. x:= [ w := #before.     y:= self confirm: 'test'.     z := #after ]         on: ProvideAnswerNotification         do: [:ex | ex resume: false ]. {w. x. y. z.}.
I don't know if assuming always that "correct" means continue execution in that scope. It may depend on the warning or notification and the block task, but of course #resume: is a more common sense choice for most cases.
Hernán this is common mistake when putting together simple examples and if I hadn't just finished writing a series of automatic Warning handlers, I wouldn't have picked up on it:)
I know :) it could be as complex as hell, that's why I say you have to automate exceptions with a specific goal in mind, for example logging or finish an unattended loading. Cheers, -- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
Hernán I agree with you, because practicality outweighs correctness... However I mainly wanted to point out that handling Notifications in the general case is not a good idea ... For development and personal scripts, where you can fix the problems on the fly just about anything goes ... Dale On 12/21/2010 10:41 AM, Hernán Morales Durand wrote:
Hi Dale,
Thanks for your comments, some notes between lines...
2010/12/21 Dale Henrichs<dhenrich@vmware.com>:
On 12/20/2010 09:27 PM, Hernán Morales Durand wrote:
2010/12/20 Esteban Lorenzano<estebanlm@gmail.com>:
duh... [ ... ] on: Warning do: [ :w | w resume ]. forget my question... :(
That wouldn't make it for Notifications such as:
self inform: 'test'
so you might want to write:
[ self inform: 'test' ] on: Warning, Notification do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText ].
I would be careful about handling all Notifications. Unlike Error, there is no "correct" pattern for handling Notifications, just take a look at all implementors of #defaultAction for subclasses of Notification and you will see that in most cases, the default action returns an application specific object, so returning a String instead will break them all ..
Notifications are meant to be ignored unless you know what you are doing.
Agree. Although I think you're focusing on handling properly the answer but Esteban just wanted to bypass modal dialogs so a time consuming operation could finish without human intervention. In that case we can assume he isn't going to provide a "dangerous" default for a confirm operation and he'd like to log warnings and informations. Esteban may you comment is that your case?
It turns out that even handling Warning can be dangerous. For Warning it is correct to use #resume to ignore the Warning (which ends up doing a `ex resume: nil`). However, UndeclaredVariableWarning (a subclass of Warning) expects a Boolean result, so if the code you are wrapping does any compiles you'll have to special case UndeclaredVariableWarning to do `ex resume: true`.
Yes, I've seen the UndeclaredVariableWarning (from Encoder>>undeclared: ) dialog many times when compiling programatically, and one of things is that I have to handle every compilation to avoid this dialog like this:
[ self targetClass compile: aString classified: aCategoryClassification ] on: UndeclaredVariableWarning do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self targetClass asString , '>>' , aString asString ]
I didn't found a preference to ignore this dialog, although I've found
Parser warningAllowed -> false "That would be the More Warnings preference "
I wonder is there a setting I've missed?
To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better choice than Notification, but you need to be aware of the implications of ignoring inform: as ProvideAnswerNotification is used for dealing with:
inform: - return value is ignored confirm:: - return values is expected to be a Boolean request: - is expected to be a String
As Adrian mentions, if you are want to automate the handling of inform:/confirm:/request: you are better off using valueSupplyingAnswers:.
Finally, in the above example using 'ex return:'a string` is not the correct way to ignore a Warning or Notification. The #return: messages returns the arg as the result of the block (unwinding the stack). #resume: returns the arg as the result of the #signal: and continues execution from that point. Take a look at the different results for the following two expressions:
| w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex return: false ]. {w. x. y. z.}.
| w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex resume: false ]. {w. x. y. z.}.
I don't know if assuming always that "correct" means continue execution in that scope. It may depend on the warning or notification and the block task, but of course #resume: is a more common sense choice for most cases.
Hernán this is common mistake when putting together simple examples and if I hadn't just finished writing a series of automatic Warning handlers, I wouldn't have picked up on it:)
I know :) it could be as complex as hell, that's why I say you have to automate exceptions with a specific goal in mind, for example logging or finish an unattended loading. Cheers,
Yes, I've seen the UndeclaredVariableWarning (from Encoder>>undeclared: ) dialog many times when compiling programatically, and one of things is that I have to handle every compilation to avoid this dialog like this:
[ self targetClass compile: aString classified: aCategoryClassification ] on: UndeclaredVariableWarning do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self targetClass asString , '>>' , aString asString ]
I didn't found a preference to ignore this dialog, although I've found
Parser warningAllowed -> false "That would be the More Warnings preference "
I wonder is there a setting I've missed?
it would be nice to have one. Hernan could you open a ticket? and if you provide code it will get in :)
To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better choice than Notification, but you need to be aware of the implications of ignoring inform: as ProvideAnswerNotification is used for dealing with:
inform: - return value is ignored confirm:: - return values is expected to be a Boolean request: - is expected to be a String
As Adrian mentions, if you are want to automate the handling of inform:/confirm:/request: you are better off using valueSupplyingAnswers:.
Finally, in the above example using 'ex return:'a string` is not the correct way to ignore a Warning or Notification. The #return: messages returns the arg as the result of the block (unwinding the stack). #resume: returns the arg as the result of the #signal: and continues execution from that point. Take a look at the different results for the following two expressions:
| w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex return: false ]. {w. x. y. z.}.
| w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex resume: false ]. {w. x. y. z.}.
I don't know if assuming always that "correct" means continue execution in that scope. It may depend on the warning or notification and the block task, but of course #resume: is a more common sense choice for most cases.
Hernán this is common mistake when putting together simple examples and if I hadn't just finished writing a series of automatic Warning handlers, I wouldn't have picked up on it:)
I know :) it could be as complex as hell, that's why I say you have to automate exceptions with a specific goal in mind, for example logging or finish an unattended loading. Cheers,
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
Hi,
Agree. Although I think you're focusing on handling properly the answer but Esteban just wanted to bypass modal dialogs so a time consuming operation could finish without human intervention. In that case we can assume he isn't going to provide a "dangerous" default for a confirm operation and he'd like to log warnings and informations. Esteban may you comment is that your case?
you are right... I'm working on the scripts to automatize vm building (to run on hudson), and I just need a cool way for bypass "this package has changes... blah", because, for instance, if I choose to build a vm with Alien support, the plugin has overrides on VMMaker, then the VMMaker packages becomes dirty, and a new update raises a warning :) And I want to bypass this kind of things... and all the possible things that can happen in the future (I suppose "#valueSupplingAnswers: will be useful in the future) Cheers, Esteban
participants (5)
-
Adrian Lienhard -
Dale Henrichs -
Esteban Lorenzano -
Hernán Morales Durand -
Stéphane Ducasse