July 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Question about dynamic spec

by Benjamin

Committed :) Ben On Jul 12, 2013, at 8:26 PM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > > > > On Fri, Jul 12, 2013 at 2:14 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Smalltalk hub is not trig erring notifications (yet) :) > > Now you should be added as a contributor, so you can commit :) > > Andrei > > > > Ben > > On Jul 12, 2013, at 2:09 PM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > >> >> On Fri, Jul 12, 2013 at 1:59 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> I reviewed your code. There was some misunderstanding I think about how to rebuild widgets :) >> >> I patch your version so the toolbar is only responsible of its own layout, and the ChangingButton too. >> >> Super. Thanks a lot :) >> >> I can not commit in your repo since I do not have proper rights :) >> >> I tried to add you as a contributor but nothing happened. >> Did you receive perhaps some notification? >> >> >> Andrei >> >> > >

July 12, 2013

Re: [Pharo-users] Question about dynamic spec

by Andrei Vasile Chis

On Fri, Jul 12, 2013 at 2:14 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Smalltalk hub is not trig erring notifications (yet) :) > Now you should be added as a contributor, so you can commit :) Andrei > > Ben > > On Jul 12, 2013, at 2:09 PM, Andrei Vasile Chis < > chisvasileandrei(a)gmail.com> wrote: > > > On Fri, Jul 12, 2013 at 1:59 PM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> I reviewed your code. There was some misunderstanding I think about how >> to rebuild widgets :) >> >> > I patch your version so the toolbar is only responsible of its own layout, >> and the ChangingButton too. >> > > Super. Thanks a lot :) > > >> I can not commit in your repo since I do not have proper rights :) >> > > I tried to add you as a contributor but nothing happened. > Did you receive perhaps some notification? > > > Andrei > > > > >

July 12, 2013

Re: [Pharo-users] Question about dynamic spec

by Benjamin

Smalltalk hub is not trig erring notifications (yet) :) Ben On Jul 12, 2013, at 2:09 PM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > > On Fri, Jul 12, 2013 at 1:59 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > I reviewed your code. There was some misunderstanding I think about how to rebuild widgets :) > > I patch your version so the toolbar is only responsible of its own layout, and the ChangingButton too. > > Super. Thanks a lot :) > > I can not commit in your repo since I do not have proper rights :) > > I tried to add you as a contributor but nothing happened. > Did you receive perhaps some notification? > > > Andrei > >

July 12, 2013

Re: [Pharo-users] Question about dynamic spec

by Andrei Vasile Chis

On Fri, Jul 12, 2013 at 1:59 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > I reviewed your code. There was some misunderstanding I think about how to > rebuild widgets :) > > I patch your version so the toolbar is only responsible of its own layout, > and the ChangingButton too. > Super. Thanks a lot :) > I can not commit in your repo since I do not have proper rights :) > I tried to add you as a contributor but nothing happened. Did you receive perhaps some notification? Andrei

July 12, 2013

Re: [Pharo-users] Question about dynamic spec

by Benjamin

I reviewed your code. There was some misunderstanding I think about how to rebuild widgets :) I patch your version so the toolbar is only responsible of its own layout, and the ChangingButton too. I can not commit in your repo since I do not have proper rights :) Ben On Jul 9, 2013, at 9:18 AM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > If you decide to use this example for the Spec chapter I could do another pass on the code and make it nicer. > > Andrei > > > On Tue, Jul 9, 2013 at 9:11 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ben > > I'm still fuzzy after a flood in the flat we rent at 2 in the morning :) > but I was thinking that may be we can use this example to explain the dynamic part of spec. > So can you take this view also when you look at the code? > If this sounds good to you, I will put on the stack that I should look and see how to put it in the Spec chapter. > > Stef > > On Jul 8, 2013, at 11:05 PM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > >> Hi, >> >> I've implemented a small UI using the dynamic features of spec and I'd like to know if there isn't a better way to do it. My use case is simple: I have a normal ComposableModel that has two models - a list and a DynamicComposableModel. The DynamicComposableModel should contain a list of buttons that should change every time the user selects an element in the list. I've implemented a demo that can be seen if you download the package DynamicSpec-Examples from http://www.smalltalkhub.com/mc/AndreiChis/Playground/main and execute the code from the class comment of DSChangingButtons. >> >> My problem is that the widget containing the buttons has to define a spec layout on the class side. I haven't found a way to tell the spec layout to add a widget and use a method on the object for constructing the layout. I've manage to get away by dynamically reconstructing the layout when the selection changes, however it's not that nice because I had to duplicate the layout of the main widget both on the class side and the object side. It would be nice to add a widget to the layout like this: 'aSpec dynamicAdd: modelGetter withSpec: aSymbol ' that would call aSymbol on the object and not on the class. This may or may not make sense :) >> >> To be concrete, the method DSToolbarModel>>updateButtons will call the method dynamicLayout on it's parent which in turn will call dynamicLayoutWithSpec: on the toolbar. I'd like to avoid this, and when specifying the layout of the parent widget to call a method on the instance side of it subwidgets to get their layout. >> >> Now I'll end here this rather long email :) >> >> Cheers, >> Andrei > >

July 12, 2013

Re: [Pharo-users] Procedure for reporting bugs in external libraries

by raphonic

Ok, thanks for the reply. I had a test fail in one external package I'm using, I'll contact the author directly. -- View this message in context: http://forum.world.st/Procedure-for-reporting-bugs-in-external-libraries-tp… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 12, 2013

Re: [Pharo-users] Phexample state keeping

by Norbert Hartl

Am 12.07.2013 um 00:17 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > > On 2013-07-11, at 11:50, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I'm playing with Phexampe because I think that in my current project the setup of test scenarios will be a huge part of the testing. So do it in a structured way reducing doubled initialization procedures should be something good. >> I'm just wondering how the state is kept between dependent test cases. A Phexample test case returns a value so that >> >> value := self given: #shouldHaveCollectedSomeState >> >> transfers the state from the dependent test case into the current. What do you do if the state produced is more complex than a single value? > > I don't remember, but calling multiple times #given:, for each part, doesn't solve this problem? No, in my case a test needs two participants that communicate with each other. The first test case checks the validity of the request. The second test case checks the validity of the reply. So I need to transfer both communication ends to the next test case. For now I've created a TestScenario class that keeps both parts just so I can return it as a single value. That is not optimal because the number of combinations of objects I need to return together will be quite big and creating a class for each of them is not good. Using TestResources is not optimal either because I need to manually reset them which defeats their purpose. Or I need to have an external class that records the side effects. > >> To be honest I don't understand why in a test case that calls #given: a tearDown/setUp cycle is executed between the first and the second test case. I think while using #given: I make the second test case explicitly dependent on the first. Why should I reset state collected by the first before executing the second? > > I think that is one of the possible approximations. Since in general you cannot say that a testcase is side-effect free (needs teardown) or has some requirements (setup). > I think side-effect freeness is not the point here. SetUp and tearDown are useful to isolate a single test case. When using #given: you include one test case into another. Meaning the setUp and tearDown needs to surround the combination of both and not each individual. Removing side-effects between the tests is like calling cleanUpInstanceVariables in the middle of a test case. > On the other hand I would rather expect it not to call the setup, especially in the case where the #given is done on the same class/test suite. > > I only had a look at phexample a while ago, so I don't remember all the details. I think I will do a try this weekend. Thanks Cami! Norbert

July 12, 2013

Re: [Pharo-users] Procedure for reporting bugs in external libraries

by ClÃ©ment Bera

Hello, Usually, projects that are in integrated in Pharo or are going to be integrated in it are on the main Pharo issue tracker. For other projects, you can directly contact the author's email or you report about it on this mailing list. Depending on the project there could be an issue tracker or not. 2013/7/12 raphonic <raphonic(a)outlook.com> > Hi, > > What is the procedure for reporting bugs in libraries that I download from > Smalltalkhub and Squeaksource? Should I contact the author's email directly > or is there an issue tracker for external projects? > > Thanks. > > > > -- > View this message in context: > http://forum.world.st/Procedure-for-reporting-bugs-in-external-libraries-tp… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 12, 2013

Procedure for reporting bugs in external libraries

by raphonic

Hi, What is the procedure for reporting bugs in libraries that I download from Smalltalkhub and Squeaksource? Should I contact the author's email directly or is there an issue tracker for external projects? Thanks. -- View this message in context: http://forum.world.st/Procedure-for-reporting-bugs-in-external-libraries-tp… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 12, 2013

Re: [Pharo-users] Phexample state keeping

by Camillo Bruni

On 2013-07-11, at 11:50, Norbert Hartl <norbert(a)hartl.name> wrote: > I'm playing with Phexampe because I think that in my current project the setup of test scenarios will be a huge part of the testing. So do it in a structured way reducing doubled initialization procedures should be something good. > I'm just wondering how the state is kept between dependent test cases. A Phexample test case returns a value so that > > value := self given: #shouldHaveCollectedSomeState > > transfers the state from the dependent test case into the current. What do you do if the state produced is more complex than a single value? I don't remember, but calling multiple times #given:, for each part, doesn't solve this problem? > To be honest I don't understand why in a test case that calls #given: a tearDown/setUp cycle is executed between the first and the second test case. I think while using #given: I make the second test case explicitly dependent on the first. Why should I reset state collected by the first before executing the second? I think that is one of the possible approximations. Since in general you cannot say that a testcase is side-effect free (needs teardown) or has some requirements (setup). On the other hand I would rather expect it not to call the setup, especially in the case where the #given is done on the same class/test suite. I only had a look at phexample a while ago, so I don't remember all the details. I think I will do a try this weekend.

July 11, 2013