- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

> Ok, let's summarize: If an error occurs, the handler block is not > evaluated, but attached to a new exception, that exception is raised. > Then, the caller catches that exception, retrieves the handler block, > does some more ballyhoo, and then runs the handler block. Yes, the block mostly contains some code to that allows the user to fix the problem (like to show all references of a class to be removed, etc.). > And you get invited to this construction by these methods in > RBAbstractCondition: > > errorBlock > Â Â Â Â ^self errorBlockFor: false > > errorBlockFor: aBoolean > Â Â Â Â ^nil These methods (and subclass implementations) are used to retrieve the right block that caused the composite condition to fail. > We can clean it up on the next sprint, if you want :) The implementation in RBCondition is fine, the problem is more the way how exceptions are used to pass the values. This mainly stems from the fact that exceptions evolved over the past 15 years and are no longer the same as the signals that were used when the refactoring code was originally written. Now of course it is difficult to change this code because there are various users out there that depend on it, e.g. OB, RefactoringBrowser, SmaCC, ... Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Niko Schwarz

Ok, let's summarize: If an error occurs, the handler block is not evaluated, but attached to a new exception, that exception is raised. Then, the caller catches that exception, retrieves the handler block, does some more ballyhoo, and then runs the handler block. And you get invited to this construction by these methods in RBAbstractCondition: errorBlock ^self errorBlockFor: false errorBlockFor: aBoolean ^nil We can clean it up on the next sprint, if you want :) Niko On Mon, Oct 4, 2010 at 4:14 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > The tool that triggers the refactoring, e.g. ORCommand>>#handleError: > > Ok, the code is quite ugly, but this is how the original refactoring > browser implemented it. > > On 4 October 2010 16:06, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> Ok, help me out, how is that block ever invoked? The above code >> snippet just appends the block as a parameter to an exception, which >> looks just funny. >> >> Niko >> >> On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> See for senders of #errorBlock:, e.g. >>> PushDownInstanceVariableRefactoring, RemoveClassRefactoring or >>> RemoveInstanceRefactoring. >>> >>> On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> This is used to validate the preconditions of refactorings and inform >>>> the user about any mismatches. >>>> >>>> It should better not be removed. >>>> >>>> Lukas >>>> >>>> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>>>> Hi, >>>>> >>>>> The RB refactorings do some obscure dance around an errorBlock, which >>>>> is always nil, as far as I can see. As I was trying to supply a >>>>> non-nil error block, I was astonished to find out that even if it >>>>> isn't nil, it won't be executed. Here's the relevant snippets: >>>>> >>>>> checkPreconditions >>>>> Â Â Â Â | conditions block | >>>>> Â Â Â Â conditions := self preconditions. >>>>> Â Â Â Â conditions check >>>>> Â Â Â Â Â Â Â Â ifFalse: >>>>> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >>>>> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >>>>> >>>>> refactoringError: aString with: aBlock >>>>> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >>>>> >>>>> I can't imagine how that could help anyone. I suggest either removing >>>>> the errorBlock, or turning it into a good old instance variable, and >>>>> running it in case of an error. >>>>> >>>>> Cheers, >>>>> >>>>> Niko >>>>> >>>>> -- >>>>> http://scg.unibe.ch/staff/Schwarz >>>>> twitter.com/nes1983 >>>>> Tel: +41 076 235 8683 >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Oct. 4, 2010

Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))

by Schwab,Wilhelm K

Noury, I am very interested in seeing this done well. At a minimum, I'll give the result some serious abuse. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraqadi(a)gmail.com] Sent: Monday, October 04, 2010 4:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)) On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote: > For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening. > You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-) BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations. Noury _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

[Pharo-project] Soap Webservices for pharo

by Guillermo Polito

http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html So, we have some tasks now: - put it in squeaksource - test it in pharo - build a metacello config - document it? Any help is really appreciated, since I don't have too much time. Cheers, Guille ---------- Forwarded message ---------- From: Masashi Umezawa <umejava(a)mars.dti.ne.jp> Date: Mon, Oct 4, 2010 at 8:46 AM Subject: Re: About SoapOpera and SoapCore To: Guillermo Polito <guillermopolito(a)gmail.com> Hi Guillermo, I am happy to hear that SoapOpera and SoapCore would be useful for your projects. Please feel free to reuse my Soap stuff. Recently I do not have enough time to upgrade those packages. So I really appreciate your offer. I hope SoapOpera and SoapCore will start growing again! Best regards, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > My name's Guillermo and I'm from Argentina. I'm participating in the pharo > project (www.pharo-project.org) and I would love to integrate your soap > package into our available packages :). > I was wandering if you let us put it into squeaksource ( www.squeaksource.com) > and mantain it for our use, because pharo is growing very quickly and it > needs this kind of really cool stuff :). Of course we will keep the MIT > license. > > Thank you for your time and sorry for bothering :P! > Guille --- [:masashi | ^umezawa]

Oct. 4, 2010

Re: [Pharo-project] do we need handleDisabledKey:

by Gary Chambers

Similar, but reworked to fit in with TextEditor>>disptachOn: style of handling. Regards, Gary ----- Original Message ----- From: Guillermo Polito To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, October 04, 2010 1:26 PM Subject: Re: [Pharo-project] do we need handleDisabledKey: So as a first approach, we should use the ParagraphEditor #handleDisabledKey: behavior. Should we? Cheers, Guille On Mon, Oct 4, 2010 at 7:29 AM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: Well, the short answer is "yes" if we want the (previously requested long ago) features of being able to copy text, browse classes etc. from selections in disabled text. Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, October 04, 2010 11:17 AM Subject: Re: [Pharo-project] do we need handleDisabledKey: Catching up on emails after being away... will check once software update completes... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 24, 2010 7:01 PM Subject: [Pharo-project] do we need handleDisabledKey: hi gary do we need handleDisabledKey: because this is not defined on the new editorHierarchy? http://code.google.com/p/pharo/issues/detail?id=3003 Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

The tool that triggers the refactoring, e.g. ORCommand>>#handleError: Ok, the code is quite ugly, but this is how the original refactoring browser implemented it. On 4 October 2010 16:06, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > Ok, help me out, how is that block ever invoked? The above code > snippet just appends the block as a parameter to an exception, which > looks just funny. > > Niko > > On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> See for senders of #errorBlock:, e.g. >> PushDownInstanceVariableRefactoring, RemoveClassRefactoring or >> RemoveInstanceRefactoring. >> >> On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: >>> This is used to validate the preconditions of refactorings and inform >>> the user about any mismatches. >>> >>> It should better not be removed. >>> >>> Lukas >>> >>> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>>> Hi, >>>> >>>> The RB refactorings do some obscure dance around an errorBlock, which >>>> is always nil, as far as I can see. As I was trying to supply a >>>> non-nil error block, I was astonished to find out that even if it >>>> isn't nil, it won't be executed. Here's the relevant snippets: >>>> >>>> checkPreconditions >>>> Â Â Â Â | conditions block | >>>> Â Â Â Â conditions := self preconditions. >>>> Â Â Â Â conditions check >>>> Â Â Â Â Â Â Â Â ifFalse: >>>> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >>>> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >>>> >>>> refactoringError: aString with: aBlock >>>> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >>>> >>>> I can't imagine how that could help anyone. I suggest either removing >>>> the errorBlock, or turning it into a good old instance variable, and >>>> running it in case of an error. >>>> >>>> Cheers, >>>> >>>> Niko >>>> >>>> -- >>>> http://scg.unibe.ch/staff/Schwarz >>>> twitter.com/nes1983 >>>> Tel: +41 076 235 8683 >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Niko Schwarz

Ok, help me out, how is that block ever invoked? The above code snippet just appends the block as a parameter to an exception, which looks just funny. Niko On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > See for senders of #errorBlock:, e.g. > PushDownInstanceVariableRefactoring, RemoveClassRefactoring or > RemoveInstanceRefactoring. > > On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: >> This is used to validate the preconditions of refactorings and inform >> the user about any mismatches. >> >> It should better not be removed. >> >> Lukas >> >> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>> Hi, >>> >>> The RB refactorings do some obscure dance around an errorBlock, which >>> is always nil, as far as I can see. As I was trying to supply a >>> non-nil error block, I was astonished to find out that even if it >>> isn't nil, it won't be executed. Here's the relevant snippets: >>> >>> checkPreconditions >>> Â Â Â Â | conditions block | >>> Â Â Â Â conditions := self preconditions. >>> Â Â Â Â conditions check >>> Â Â Â Â Â Â Â Â ifFalse: >>> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >>> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >>> >>> refactoringError: aString with: aBlock >>> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >>> >>> I can't imagine how that could help anyone. I suggest either removing >>> the errorBlock, or turning it into a good old instance variable, and >>> running it in case of an error. >>> >>> Cheers, >>> >>> Niko >>> >>> -- >>> http://scg.unibe.ch/staff/Schwarz >>> twitter.com/nes1983 >>> Tel: +41 076 235 8683 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

See for senders of #errorBlock:, e.g. PushDownInstanceVariableRefactoring, RemoveClassRefactoring or RemoveInstanceRefactoring. On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: > This is used to validate the preconditions of refactorings and inform > the user about any mismatches. > > It should better not be removed. > > Lukas > > On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> Hi, >> >> The RB refactorings do some obscure dance around an errorBlock, which >> is always nil, as far as I can see. As I was trying to supply a >> non-nil error block, I was astonished to find out that even if it >> isn't nil, it won't be executed. Here's the relevant snippets: >> >> checkPreconditions >> Â Â Â Â | conditions block | >> Â Â Â Â conditions := self preconditions. >> Â Â Â Â conditions check >> Â Â Â Â Â Â Â Â ifFalse: >> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >> >> refactoringError: aString with: aBlock >> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >> >> I can't imagine how that could help anyone. I suggest either removing >> the errorBlock, or turning it into a good old instance variable, and >> running it in case of an error. >> >> Cheers, >> >> Niko >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

This is used to validate the preconditions of refactorings and inform the user about any mismatches. It should better not be removed. Lukas On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > Hi, > > The RB refactorings do some obscure dance around an errorBlock, which > is always nil, as far as I can see. As I was trying to supply a > non-nil error block, I was astonished to find out that even if it > isn't nil, it won't be executed. Here's the relevant snippets: > > checkPreconditions > Â Â Â Â | conditions block | > Â Â Â Â conditions := self preconditions. > Â Â Â Â conditions check > Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. > Â Â Â Â Â Â Â Â Â Â Â Â block notNil > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] > > refactoringError: aString with: aBlock > Â Â Â Â ^ RefactoringError signal: aString with: aBlock > > I can't imagine how that could help anyone. I suggest either removing > the errorBlock, or turning it into a good old instance variable, and > running it in case of an error. > > Cheers, > > Niko > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 4, 2010

[Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Niko Schwarz

Hi, The RB refactorings do some obscure dance around an errorBlock, which is always nil, as far as I can see. As I was trying to supply a non-nil error block, I was astonished to find out that even if it isn't nil, it won't be executed. Here's the relevant snippets: checkPreconditions | conditions block | conditions := self preconditions. conditions check ifFalse: [block := conditions errorBlock. block notNil ifTrue: [self refactoringError: conditions errorString with: block] ifFalse: [self refactoringError: conditions errorString]] refactoringError: aString with: aBlock ^ RefactoringError signal: aString with: aBlock I can't imagine how that could help anyone. I suggest either removing the errorBlock, or turning it into a good old instance variable, and running it in case of an error. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Oct. 4, 2010