April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About testing that ensure works

by StÃ©phane Ducasse

> > testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt > "self debug: #testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt" > > | current empty | > current := RPackageOrganizer default. > empty := RPackageOrganizer basicNew initialize. > > [ > RPackage withOrganizer: empty > do: [ self error ]. > ] on: Error do: [:ex | ]. > > self assert: (SystemAnnouncer announcer hasSubscriber: current). > self deny: (SystemAnnouncer announcer hasSubscriber: empty) Igor but how can I specify that I want an error to occur in the do: and that I do not want to trap it but that the ensure should trap it. Is the ensure execute if I trap the error like that? Stef

April 24, 2011

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by StÃ©phane Ducasse

weak "announcer weak subscribe: foo" ^ WeakSubscriptionBuilder on: self What could be the comment? Stef

April 24, 2011

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by StÃ©phane Ducasse

On Apr 24, 2011, at 11:54 AM, Igor Stasenko wrote: > On 24 April 2011 12:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> of course if the method would have been commented like that I would not have asked. >> So I'm doing a pass on the class now and adding comments :( >> >> unsubscribe: anObject >> "Unsubscribe all occurrences of the subscriber anObject" >> > "Unsubscribe all subscriptions of anObject from receiver" > >> registry removeSubscriber: anObject >> >> >> > Hmm.. isn't that was obvious? No idea. Nothing is obvious!!! Comments are there to remove the obvious assumptions. Stef > > I mean, what behavior you found less surprising? Removing single > subscription per call? Which one? In what order? > > > -- > Best regards, > Igor Stasenko AKA sig. >

April 24, 2011

Re: [Pharo-project] About testing that ensure works

by StÃ©phane Ducasse

>>> > i am puzzled. You wanna to be sure that ensure block are executed? > It is. I want to write a test that shows and tests the withOrganizer:do: semantics. In particular that the ensure is executed and that the context set by the withOrganizer: is only present in the do: block. > However if error was triggered during ensure block evaluation, it may > not complete everything you put there. Sure this is normal. > And for test you can use non-local return to trigger ensure block: > > | current empty | > current := RPackageOrganizer default. > empty := RPackageOrganizer basicNew initialize. > > [ > RPackage withOrganizer: empty > do: [ self error ]. > ] on: Error do: [:ex | ]. > > self assert: (SystemAnnouncer announcer hasSubscriber: current). > self deny: (SystemAnnouncer announcer hasSubscriber: empty) Yes this is what I was thinking to do. because a self error alone was not. Stef

April 24, 2011

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by Igor Stasenko

On 24 April 2011 12:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > of course if the method would have been commented like that I would not have asked. > So I'm doing a pass on the class now and adding comments :( > > unsubscribe: anObject > Â Â Â Â "Unsubscribe all occurrences of the subscriber anObject" > "Unsubscribe all subscriptions of anObject from receiver" > Â Â Â Â registry removeSubscriber: anObject > > > Hmm.. isn't that was obvious? I mean, what behavior you found less surprising? Removing single subscription per call? Which one? In what order? -- Best regards, Igor Stasenko AKA sig.

April 24, 2011

Re: [Pharo-project] About testing that ensure works

by Igor Stasenko

On 24 April 2011 11:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> First question what i wanna ask is: >> - why do you need to play with two different instances of organizer, >> and especially in such manner (temporary swapping forth and back)? >> >> This code doesn't looks to be good. > > Igor can you reply to my question instead of questioning because it just slows me down. > > Now the answer: > Â Â Â Â when we run Â the tests we do not run them in the default organizer because if something wrong happens > Â Â Â Â then this is simply harakiri. > Â Â Â Â So all the tests are performed in a separated created on the fly organizer. > Â Â Â Â And I think that this is good to do it like that else I have to have a global variable and the rest. > Â Â Â Â This design is the result of changes doru pushed me to do and they are good. > Â Â Â Â Now this good is bad and not written my me and I'm trying to clean it and this is why I need to > Â Â Â Â write tests because I want the Package code to be bullet proof. > i am puzzled. You wanna to be sure that ensure block are executed? It is. However if error was triggered during ensure block evaluation, it may not complete everything you put there. And for test you can use non-local return to trigger ensure block: testWithDoIsCorrectlyReinstallingDefault "self debug: #testWithDoIsCorrectlyReinstallingDefault" | current empty | current := RPackageOrganizer default. empty := RPackageOrganizer basicNew initialize. self doWith:current and:empty. self assert: (SystemAnnouncer announcer hasSubscriber: current). self deny: (SystemAnnouncer announcer hasSubscriber: empty) doWith:current and:empty RPackage withOrganizer: empty do: [ ^ self ]. Or with error: testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt "self debug: #testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt" | current empty | current := RPackageOrganizer default. empty := RPackageOrganizer basicNew initialize. [ RPackage withOrganizer: empty do: [ self error ]. ] on: Error do: [:ex | ]. self assert: (SystemAnnouncer announcer hasSubscriber: current). self deny: (SystemAnnouncer announcer hasSubscriber: empty) > Stef >> >> >> On 24 April 2011 00:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> in RPackage there is a method named withOrganizer:do: Â defined as follows and I would like to test it to understand really if it does >>> what it says. >>> >>> withOrganizer: aNewOrganizer do: aBlock >>> Â Â Â Â "Perform an action locally to aNewOrganizer. Does not impact any other organizers." >>> >>> Â Â Â Â | old shouldRegisterAtTheEnd| >>> Â Â Â Â [ >>> Â Â Â Â old := self organizer. >>> Â Â Â Â shouldRegisterAtTheEnd := false. >>> Â Â Â Â old hasRegistered ifTrue: [ >>> Â Â Â Â Â Â Â Â old unregister. >>> Â Â Â Â Â Â Â Â shouldRegisterAtTheEnd := true. >>> Â Â Â Â Â Â Â Â ]. >>> Â Â Â Â self organizer: aNewOrganizer. >>> Â Â Â Â aBlock cull: aNewOrganizer.] ensure: [ >>> Â Â Â Â Â Â Â Â self organizer: old. >>> Â Â Â Â Â Â Â Â shouldRegisterAtTheEnd ifTrue: [ >>> Â Â Â Â Â Â Â Â Â Â Â Â self organizer register. >>> Â Â Â Â Â Â Â Â Â Â Â Â ]. >>> Â Â Â Â Â Â Â Â aNewOrganizer unregister. >>> Â Â Â Â Â Â Â Â ] >>> >>> >>> So I wrote two tests >>> >>> testWithDoIsCorrectlyReinstallingDefault >>> Â Â Â Â "self debug: #testWithDoIsCorrectlyReinstallingDefault" >>> >>> Â Â Â Â | current empty | >>> Â Â Â Â current := RPackageOrganizer default. >>> Â Â Â Â empty := RPackageOrganizer basicNew initialize. >>> Â Â Â Â RPackage withOrganizer: empty >>> Â Â Â Â Â Â Â Â do: [ self assert: (SystemAnnouncer announcer hasSubscriber: empty). >>> Â Â Â Â Â Â Â Â Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: current)]. >>> Â Â Â Â self assert: (SystemAnnouncer announcer hasSubscriber: current). >>> Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: empty) >>> >>> >>> and >>> >>> >>> testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt >>> Â Â Â Â "self debug: #testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt" >>> >>> Â Â Â Â | current empty | >>> Â Â Â Â current := RPackageOrganizer default. >>> Â Â Â Â empty := RPackageOrganizer basicNew initialize. >>> Â Â Â Â RPackage withOrganizer: empty >>> Â Â Â Â Â Â Â Â do: [ self error. >>> Â Â Â Â Â Â Â Â Â Â Â Â self assert: (SystemAnnouncer announcer hasSubscriber: empty). >>> Â Â Â Â Â Â Â Â Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: current)]. >>> Â Â Â Â self assert: (SystemAnnouncer announcer hasSubscriber: current). >>> Â Â Â Â self deny: (SystemAnnouncer announcer hasSubscriber: empty) >>> >>> Now I would like to make sure that I raise an error or whaever to make sure that the ensure: block argument >>> is executed. Does anybody have an idea how I can do that. because self error does not work. >>> >>> Stef >>> >>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

April 24, 2011

Re: [Pharo-project] curl / http request

by Camillo Bruni

Hi Sven, Thanks a lot. Zinc is my friend ;). Nice and understandable. bon weekend, camillo On 2011-04-23, at 21:27, Sven Van Caekenberghe wrote: > Hey Camillo, > > On 23 Apr 2011, at 20:05, Camillo Bruni wrote: > >> I am too dumb and there is too little documentation which is hard to find :). >> So can anyone tell me how I do the following bash thingy in pharo? >> >> curl $URL --data-binary $SOME_FILE -H 'Content-type:application/json' >> >> I don't manage to get this working properly. I guess HTTPSocket is the class to use... >> >> thanks a lot >> camillo > > Well, Zinc HTTP Components [1], of course: > > | json entity | > json := (FileStream fileNamed: '/tmp/foo.json') contentsOfEntireFile. > entity := ZnEntity with: json type: ZnMimeType applicationJson. > ZnClient post: 'http://example.com/foo' data: entity > > This will return a ZnResponse, inspect it for more details. > There are many more options, but this is a simple example to get you started. > > The source code should be your friend. > > Sven > > [1] http://homepage.mac.com/svc/Zinc-HTTP-Components > > >

April 24, 2011

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by StÃ©phane Ducasse

of course if the method would have been commented like that I would not have asked. So I'm doing a pass on the class now and adding comments :( unsubscribe: anObject "Unsubscribe all occurrences of the subscriber anObject" registry removeSubscriber: anObject On Apr 24, 2011, at 11:02 AM, Denis Kudriashov wrote: > Why #unregister: is not enough? > > 2011/4/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Yes > > Now is there a way that we could make sure that an object is really unregistered? > I would write > > [ann hasSubscriber: anObject] whileTrue: [an unregister: anObject] > in the client code > but having > > fullyUnregister: anObject > > is good to have in special case. > > Stef > > > > Okay. But i would discourage from using such methods :) > > > >> Stef > >> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko AKA sig. > >>> > >> > >> > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > >

April 24, 2011

Re: [Pharo-project] is there a way to know whether an object is registered to an announcer?

by StÃ©phane Ducasse

ok I was not aware that the semantics was what I was looking for.... the comment is so good also. removeSubscriber: subscriber ^ self protected: [ subscriptions removeAllSuchThat: [:subscription | subscription subscriber == subscriber ]] On Apr 24, 2011, at 11:02 AM, Denis Kudriashov wrote: > Why #unregister: is not enough? > > 2011/4/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Yes > > Now is there a way that we could make sure that an object is really unregistered? > I would write > > [ann hasSubscriber: anObject] whileTrue: [an unregister: anObject] > in the client code > but having > > fullyUnregister: anObject > > is good to have in special case. > > Stef > > > > Okay. But i would discourage from using such methods :) > > > >> Stef > >> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko AKA sig. > >>> > >> > >> > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > >

April 24, 2011

Re: [Pharo-project] What is a well documented class?

by StÃ©phane Ducasse

for the class comment I would have intention I'm doing that collaborations with the help of this class and that class main api my main public API is ... my subclasses may want to override such specific hooks ... Implementation notes iv and their purposes > Hi! > > I am dreaming about a tool to help me document source code. The question I have is what is a well documented class? > What do you think about the following: > > A well documented class is a class: > - that contains a class comment > - its class comments contains either an example, or an associated unit test > - without 'as yet unclassified' method category > - each public method belongs to a method category named public* > - each private method belongs to a method category named private* > - each method contains a comment, located before the declaration of temporary variables > - other methods are considered as "package visible", meaning that they belong to a category that does not begins with 'private' or 'public' > - without commented code contained in its methods. > > Is there anything else? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 24, 2011