[Pharo-project] Fwd: issue 348
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348 Hi Stef, I updated the issue http://code.google.com/p/pharo/issues/detail?id=348 Cheers, -- Pavel
pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler? May be I missed something but I'm ready to learn. Stef On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/7/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
Apparently, UIManager provides a hook to force interactive or non interactive parser to be used while Compiler would only trust the requestor. BTW, I would tend to miss-understand method name: I would expect it to return an interactiveParser. But the meaning is rather shouldParserBeInteractiveFor: requestor Nicolas
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, every UIManager may have its own preference about this behaviour (for example the dummy ui manager has no user input). It is cleaner solution than to set interactivity for every Compiler instance or for the Compiler class. Cheers, -- Pavel On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Pavel
Hi,
every UIManager may have its own preference about this behaviour (for example the dummy ui manager has no user input). It is cleaner solution than to set interactivity for every Compiler instance or for the Compiler class.
In fact I have the impression that this is the same pattern than with preference class. We are now making sure that the Preference layer can be remove by removing references from within the package to the Preference class and we turn into a flow from the preference class to push value to the tools default value. Similarly we prefer that the UIManager pushes information to the compiler and not that the compiler rely on UIManager. I would like to think about a Compiler been able to run standalone without UI. Now we could have UIManager>> setUpForNonInteraction Compiler setInNonInteractiveMode ,... other class and Compiler code referring to itself (its value for non interaction) This way we could even remove completely the UIManager. Else I think that UIManager will become another huge facade that we cannot remove.
Cheers, -- Pavel
On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
My 2 cents: compiler should always work together with requestor: Compiler compile: some thing requestor: aRequestor. Then it could always ask, aRequestor if its interactive, or not, but i think, Compiler could live just well without such knowledge at all - each time it needs some extra data - it can simply ask the requestor to handle such particular situation, in a fashion like following: Compiler>>compileError: error ^ requestor handleError: error ifUnhandled: [ error signal ] all we need is just carefully establish protocol between Compiler and requestor object, so then making interactive/non-interactive/partly interactive will be completely independant from Compiler. 2009/7/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi Pavel
Hi,
every UIManager may have its own preference about this behaviour (for example the dummy ui manager has no user input). It is cleaner solution than to set interactivity for every Compiler instance or for the Compiler class.
In fact I have the impression that this is the same pattern than with preference class. We are now making sure that the Preference layer can be remove by removing references from within the package to the Preference class and we turn into a flow from the preference class to push value to the tools default value.
Similarly we prefer  that the UIManager pushes information to the compiler and not that the compiler rely on UIManager. I would like to think about a Compiler been able to run standalone without UI.
Now we could have
UIManager>> setUpForNonInteraction
        Compiler setInNonInteractiveMode         ,...         other class
and Compiler code referring to itself (its value for non interaction)
This way we could even remove completely the UIManager.
Else I think that UIManager will become another huge facade that we cannot remove.
Cheers, -- Pavel
On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Your cents are valuable! 2009/7/8 Igor Stasenko <siguctua@gmail.com>:
My 2 cents:
compiler should always work together with requestor:
Compiler compile: some thing requestor: aRequestor.
Then it could always ask, aRequestor if its interactive, or not, but i think, Compiler could live just well without such knowledge at all - each time it needs some extra data - it can simply ask the requestor to handle such particular situation, in a fashion like following:
Compiler>>compileError: error  ^ requestor handleError: error ifUnhandled: [ error signal ]
all we need is just carefully establish protocol between Compiler and requestor object, so then making interactive/non-interactive/partly interactive will be completely independant from Compiler.
2009/7/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi Pavel
Hi,
every UIManager may have its own preference about this behaviour (for example the dummy ui manager has no user input). It is cleaner solution than to set interactivity for every Compiler instance or for the Compiler class.
In fact I have the impression that this is the same pattern than with preference class. We are now making sure that the Preference layer can be remove by removing references from within the package to the Preference class and we turn into a flow from the preference class to push value to the tools default value.
Similarly we prefer  that the UIManager pushes information to the compiler and not that the compiler rely on UIManager. I would like to think about a Compiler been able to run standalone without UI.
Now we could have
UIManager>> setUpForNonInteraction
        Compiler setInNonInteractiveMode         ,...         other class
and Compiler code referring to itself (its value for non interaction)
This way we could even remove completely the UIManager.
Else I think that UIManager will become another huge facade that we cannot remove.
Cheers, -- Pavel
On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Your cents are valuable!
Thanks. Then 1 more cent: No doubt , this will require deep refactoring/rethinking the Compiler & requestor roles. But it would help greatly in cleaning the Compiler/Parser code from things which related to handle uncertainties, like non-existing selector(s), undefined identifiers, unused temps and so on..
2009/7/8 Igor Stasenko <siguctua@gmail.com>:
My 2 cents:
compiler should always work together with requestor:
Compiler compile: some thing requestor: aRequestor.
Then it could always ask, aRequestor if its interactive, or not, but i think, Compiler could live just well without such knowledge at all - each time it needs some extra data - it can simply ask the requestor to handle such particular situation, in a fashion like following:
Compiler>>compileError: error  ^ requestor handleError: error ifUnhandled: [ error signal ]
all we need is just carefully establish protocol between Compiler and requestor object, so then making interactive/non-interactive/partly interactive will be completely independant from Compiler.
2009/7/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi Pavel
Hi,
every UIManager may have its own preference about this behaviour (for example the dummy ui manager has no user input). It is cleaner solution than to set interactivity for every Compiler instance or for the Compiler class.
In fact I have the impression that this is the same pattern than with preference class. We are now making sure that the Preference layer can be remove by removing references from within the package to the Preference class and we turn into a flow from the preference class to push value to the tools default value.
Similarly we prefer  that the UIManager pushes information to the compiler and not that the compiler rely on UIManager. I would like to think about a Compiler been able to run standalone without UI.
Now we could have
UIManager>> setUpForNonInteraction
        Compiler setInNonInteractiveMode         ,...         other class
and Compiler code referring to itself (its value for non interaction)
This way we could even remove completely the UIManager.
Else I think that UIManager will become another huge facade that we cannot remove.
Cheers, -- Pavel
On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Yes. I think that it would be great to have a smart student working on a SummerTalk Project on that. Stef On Jul 8, 2009, at 1:22 AM, Igor Stasenko wrote:
2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Your cents are valuable!
Thanks. Then 1 more cent:
No doubt , this will require deep refactoring/rethinking the Compiler & requestor roles. But it would help greatly in cleaning the Compiler/Parser code from things which related to handle uncertainties, like non-existing selector(s), undefined identifiers, unused temps and so on..
2009/7/8 Igor Stasenko <siguctua@gmail.com>:
My 2 cents:
compiler should always work together with requestor:
Compiler compile: some thing requestor: aRequestor.
Then it could always ask, aRequestor if its interactive, or not, but i think, Compiler could live just well without such knowledge at all - each time it needs some extra data - it can simply ask the requestor to handle such particular situation, in a fashion like following:
Compiler>>compileError: error ^ requestor handleError: error ifUnhandled: [ error signal ]
all we need is just carefully establish protocol between Compiler and requestor object, so then making interactive/non-interactive/partly interactive will be completely independant from Compiler.
2009/7/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi Pavel
Hi,
every UIManager may have its own preference about this behaviour (for example the dummy ui manager has no user input). It is cleaner solution than to set interactivity for every Compiler instance or for the Compiler class.
In fact I have the impression that this is the same pattern than with preference class. We are now making sure that the Preference layer can be remove by removing references from within the package to the Preference class and we turn into a flow from the preference class to push value to the tools default value.
Similarly we prefer that the UIManager pushes information to the compiler and not that the compiler rely on UIManager. I would like to think about a Compiler been able to run standalone without UI.
Now we could have
UIManager>> setUpForNonInteraction
Compiler setInNonInteractiveMode ,... other class
and Compiler code referring to itself (its value for non interaction)
This way we could even remove completely the UIManager.
Else I think that UIManager will become another huge facade that we cannot remove.
Cheers, -- Pavel
On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: pavel I was wondering why you want to have interactiveParserFor: in UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
From: Pavel Krivanek <pavel.krivanek@gmail.com> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <stephane.ducasse@free.fr> Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail? id=348
Cheers, -- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Igor Stasenko -
Nicolas Cellier -
Pavel Krivanek -
Stéphane Ducasse