Fwd: issue 348
Locked
 
|
From: Pavel Krivanek <[hidden email]> Date: July 6, 2009 2:26:56 PM CEDT To: stephane ducasse <[hidden email]> Subject: issue 348 I updated the issue http://code.google.com/p/pharo/issues/detail?id=348 Cheers, -- Pavel _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> > Date: July 6, 2009 2:26:56 PM CEDT > To: stephane ducasse <[hidden email]> > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/7/7 Stéphane Ducasse <[hidden email]>:
> 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 <[hidden email]> >> Date: July 6, 2009 2:26:56 PM CEDT >> To: stephane ducasse <[hidden email]> >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]> wrote: pavel I was wondering why you want to have interactiveParserFor: in _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email] > > 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 <[hidden email]> > > Date: July 6, 2009 2:26:56 PM CEDT > > To: stephane ducasse <[hidden email]> > > 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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]>: > 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 <[hidden email] >> > 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 <[hidden email]> >> > Date: July 6, 2009 2:26:56 PM CEDT >> > To: stephane ducasse <[hidden email]> >> > 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 >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Your cents are valuable!
2009/7/8 Igor Stasenko <[hidden email]>: > 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 <[hidden email]>: >> 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 <[hidden email] >>> > 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 <[hidden email]> >>> > Date: July 6, 2009 2:26:56 PM CEDT >>> > To: stephane ducasse <[hidden email]> >>> > 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 >>> > [hidden email] >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/7/8 Nicolas Cellier <[hidden email]>:
> 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 <[hidden email]>: >> 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 <[hidden email]>: >>> 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 <[hidden email] >>>> > 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 <[hidden email]> >>>> > Date: July 6, 2009 2:26:56 PM CEDT >>>> > To: stephane ducasse <[hidden email]> >>>> > 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 >>>> > [hidden email] >>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]>: >> 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 <[hidden email]>: >>> 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 <[hidden email]>: >>>> 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 <[hidden email] >>>>>> 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 <[hidden email]> >>>>>> Date: July 6, 2009 2:26:56 PM CEDT >>>>>> To: stephane ducasse <[hidden email]> >>>>>> 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 >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |