January 2016 - Pharo-users - lists.pharo.org

Shutting down persona.org in November 2016

by Damien Cassou

Hi, both pharo.org and pillarhub.pharocloud.com rely on persona.org for authentication. This service will disappear. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Jan. 12, 2016

Re: [Pharo-users] Failling Tests are green if BlockCannotReturn exception

by ClÃ©ment Bera

2016-01-12 0:40 GMT+01:00 Vincent BLONDEAU < vincent.blondeau(a)polytech-lille.net>: > Hi, > > > > It is expected. > > When you evaluate a block with a return, the method containing the block > definition (here testBlock) will return. > > So the test will pass. > > > > BTW, you donât need to put a return in a block. By default, the last > instruction will be returned. > > > [ ^ 1 ] => non local return [ 1 ] => local return The 2 blocks are very different from each other. One returns to the closure activation sender, while the other returns to the closure creating context sender. See the chapter 14.4 Returning from inside a Block from the free book Deep Into Pharo <http://deepintopharo.com/> So I would not say you don't need to put a return in a block. You want to put a return or not depending on the behavior you want. > Cheers, > > Vincent > > > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *abdelghani ALIDRA > *Sent:* mardi 12 janvier 2016 00:26 > *To:* Any Question About Pharo Is Welcome > *Subject:* [Pharo-users] Failling Tests are green if BlockCannotReturn > exception > > > > Hi, > > > > I observed this unexpected behavior in test classes. > > In a test class define a method : > > > > > > > > *testBlock |aBlock| aBlock := [ ^1 ]. aBlock value. self > assert: false.* > > > > Althought the assertion is false at the end of the test, the test is green. > > Actually, It does not matter what you put after *aBlock value*, the test > always succedes (I tried to put a self halt, it does not execute) > > I tried this both in Pharo 4 and 5 under Windows and MacOS. > > > > Any ideas? > > > > Cheers > > Abdelghani > > > > >

Jan. 12, 2016

Re: [Pharo-users] Failling Tests are green if BlockCannotReturn exception

by Sven Van Caekenberghe

> On 12 Jan 2016, at 00:26, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: > > Hi, > > I observed this unexpected behavior in test classes. > In a test class define a method : > > testBlock > |aBlock| > aBlock := [ ^1 ]. > aBlock value. > self assert: false. > > Althought the assertion is false at the end of the test, the test is green. > Actually, It does not matter what you put after aBlock value, the test always succedes (I tried to put a self halt, it does not execute) The test is 'does an explicit return from a block return from the whole method'. Of course it does. But if it would not, you would arrive at the self assert: false and the test would fail. You see ? BTW, this can also be written as self fail - search for the senders of that message for more examples. > I tried this both in Pharo 4 and 5 under Windows and MacOS. > > Any ideas? > > Cheers > Abdelghani > >

Jan. 12, 2016

Re: [Pharo-users] Failling Tests are green if BlockCannotReturn exception

by Vincent BLONDEAU

Hi, It is expected. When you evaluate a block with a return, the method containing the block definition (here testBlock) will return. So the test will pass. BTW, you donât need to put a return in a block. By default, the last instruction will be returned. Cheers, Vincent From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of abdelghani ALIDRA Sent: mardi 12 janvier 2016 00:26 To: Any Question About Pharo Is Welcome Subject: [Pharo-users] Failling Tests are green if BlockCannotReturn exception Hi, I observed this unexpected behavior in test classes. In a test class define a method : testBlock |aBlock| aBlock := [ ^1 ]. aBlock value. self assert: false. Althought the assertion is false at the end of the test, the test is green. Actually, It does not matter what you put after aBlock value, the test always succedes (I tried to put a self halt, it does not execute) I tried this both in Pharo 4 and 5 under Windows and MacOS. Any ideas? Cheers Abdelghani

Jan. 11, 2016

Re: [Pharo-users] Failling Tests are green if BlockCannotReturn exception

by Johan Fabry

Hi Abdelghani, this is actually correct behavior: by putting [ ^1 ] , you are specifying that the method should return 1 when the block is executed. So the result of aBlock value is that the method returns 1. If you want that the result of evaluating the block is 1, you should just put [ 1 ] Hope this helps, > On Jan 11, 2016, at 20:26, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: > > Hi, > > I observed this unexpected behavior in test classes. > In a test class define a method : > > testBlock > |aBlock| > aBlock := [ ^1 ]. > aBlock value. > self assert: false. > > Althought the assertion is false at the end of the test, the test is green. > Actually, It does not matter what you put after aBlock value, the test always succedes (I tried to put a self halt, it does not execute) > I tried this both in Pharo 4 and 5 under Windows and MacOS. > > Any ideas? > > Cheers > Abdelghani > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 11, 2016

Failling Tests are green if BlockCannotReturn exception

by abdelghani ALIDRA

Hi, I observed this unexpected behavior in test classes.In a test class define a method : testBlock Â Â Â |aBlock| Â Â Â aBlock := [ ^1 ]. Â Â Â aBlock value. Â Â Â self assert: false. Althought the assertion is false at the end of the test, the test is green.Actually, It does not matter what you put after aBlock value, the test always succedes (I tried to put a self halt, it does not execute) I tried this both in Pharo 4 and 5 under Windows and MacOS. Any ideas? Cheers Abdelghani

Jan. 11, 2016

Re: [Pharo-users] When Pharo 5 is to be released as stable ?

by Dimitris Chloupis

Ah perfect thanks Esteban On Mon, 11 Jan 2016 at 21:14, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > april > > > On 11 Jan 2016, at 19:55, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > I am curious when is Pharo 5 is to be released as stable and move to > Pharo 6 , any idea ? > > >

Jan. 11, 2016

Re: [Pharo-users] When Pharo 5 is to be released as stable ?

by Esteban Lorenzano

april > On 11 Jan 2016, at 19:55, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I am curious when is Pharo 5 is to be released as stable and move to Pharo 6 , any idea ?

Jan. 11, 2016

When Pharo 5 is to be released as stable ?

by Dimitris Chloupis

I am curious when is Pharo 5 is to be released as stable and move to Pharo 6 , any idea ?

Jan. 11, 2016

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

by Offray Vladimir Luna CÃ¡rdenas

Thanks Johan I will follow from there and report back as soon as I have some results. Cheers, Offray On 10/01/16 13:39, Johan Fabry wrote: > Sorry for the lateness and short reply but Iâm involved in a bunch of > other things that are taking almost all of my time ... > > From what I understand and what I can see in your code, you want to > modify a widget when the UI is open. However you never trigger the > rebuilding of the window. For example, see the Spec docs that I sent, > where in 9.1 there is code that calls buildWithSpecLayout: . > > Actually, I am not sure you need to subclass DynamicComposableModel > since the number of widgets never changes. You can use a normal > ComposableModel subclass and use what is detailed in 9.1 to change the > layout between the two options you want to have (a TextModel or a > GlamourPresentationModel). > >> On Jan 8, 2016, at 23:07, Offray Vladimir Luna CÃ¡rdenas >> <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: >> >> Shouldn't be #right dynamically defined according to the values of >> 'item' and be replaced on the m2 layout? > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile >

Jan. 11, 2016