- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec Examples

by Erwan Douaille

Since UIPainter, example aren't needed :p Another way, than i like, is create a method for a model. Class>>listModel listModel ifNil: [ listModel := self instantiate: ListModel. and options ]. ^ listModel And do nothing in initializeWidgets 2013/9/21 Camillo Bruni <camillobruni(a)gmail.com> > Can I rewrite all spec examples from > > self instantiateModels: #( > listModel ListComposableModel > methodModel MethodBrowser ). > > to the more explicit form: > > listModel := self instantiate: ListComposableModel. > methodModel := self instantiate: MethodBrowser. > > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Sept. 21, 2013

Spec Examples

by Camillo Bruni

Can I rewrite all spec examples from self instantiateModels: #( listModel ListComposableModel methodModel MethodBrowser ). to the more explicit form: listModel := self instantiate: ListComposableModel. methodModel := self instantiate: MethodBrowser.

Sept. 21, 2013

Re: [Pharo-dev] TextMorph with Athens

by Igor Stasenko

text morph dont works. and this is what i working on currently. i working on making new text model, new layout and new rendering for it.. and that will be completely different than existing text morph. On 21 September 2013 11:11, Hilaire Fernandes <hilaire.fernandes(a)gmail.com>wrote: > Is there anythink I should know regarding rendering TextMorph on Athens > Canvas? > I see there is a #drawOnAthensCanvas: method for this class but when I > use it on a DrGeo canvas, no thing is rendered. > > Hilaire > > -- > Dr. Geo http://drgeo.eu > > > -- Best regards, Igor Stasenko.

Sept. 21, 2013

Re: [Pharo-dev] Spec Question: DropListModel

by Camillo Bruni

thanks for the details, here are my requests, which as usual I expected to be implemented by yesterday :P. Well mostly for synchronizing and to see if my idea fits with what you thought about it. - First of all we should get the API straight, it is not clear what returns the internal model (DropListItem) and what returns the externally injected model. - I am missing icons :P - a lazy labelBlock and a lazy iconBlock - convenience label and icon block creators which internally set the labelBlock and iconBlock: iconProperty: #icon, labelProperty: #packageName So what I expected somehow (coming from Flex / Flash, yes you read correctly flash!): - items: { myObject1. myObject2...} - labelBlock: [ :item :dropListItem "optional" | item asString ] - iconBlock: [ :item :dropListItem "optional" | item isClosed ifTrue: [ Smalltalk ui icons closedIcon ] ifFalse: [ Smalltalk ui icons openedIcon ]] => by default you get the icon/label from the internal DropListItem => if the icon / label is not set, use the #labelBlock or #iconBLock on the DropList => if there is no #labelBlock use `asStringLimitedTo: 100` => if there is no #iconBlock do not use an icon By default in Flex you cannot access the internal wrapper (DropListItem in our case) hence you have to defined the accessors for the label and icon directly on your own model (here myObject). This prevents you from the non-uniform lists you described below and only marginally simplifies the design (and dare you having a look at their implementation :P). On 2013-09-21, at 10:10, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> What is the idea behind the #displayBlock: in DropListModel? > > The original drop list required manual building of DropListItems, which chop > the original domain objects down to maps of label strings, to action blocks. > > There seem to be two general use cases for drop down lists: > 1. Heterogeneous items like { { 'Open a workspace' -> [ Workspace open ] }. > { 'Save the image' -> [ ... ] }. Here the original implementation "works", > but at the cost of forcing the user to know about and build DropListItems > 2. Related items like displaying class names and returning the actual class > that's selected. I never liked the way this was handled by the original > implementation, but it became more jarring under Spec because other list > model classes (like ListComposableModel) use #displayBlock: to adapt domain > objects to list labels > > So the intention was two-fold: > 1. to provide an API through DropListModel that hides the Items > 2. to make Spec's list handling more uniform > > So the situation is improved for both use cases: > items := { > DropListItem named: aString do: aBlock. > DropListItem named: aString do: aBlock. > DropListItem named: aString do: aBlock }. > listModel items: items. > > For 1 becomes: > listModel > addItemLabeled: aString do: aBlock; > addItemLabeled: aString do: aBlock; > addItemLabeled: aString do: aBlock. > For 2 becomes: > listModel > items: aCollectionOfDomainObjects; > displayBlock: [ :domainObject | ... ]. > > Where #2 uses the same API as ListComposableModel. > > But something doesn't feel quite right about the current implementation, so > let's def do another pass. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spec-Question-DropListModel-tp4709441p4709503.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 21, 2013

Re: [Pharo-dev] About Morphic Documentation

by Sean P. DeNigris

ClÃ©ment Bera-4 wrote > the documentation would be on the web, available to anyone, > and each class / each package inside Pharo has a link towards its online > documentation. > This way the image size does not grow because of massive documentation. I agree that it would be nice for the docs to be on the web. But for me I would want that to be a mirror of what's available in the image. In general, I'd rather not context switch between the live, dynamic world of my image and a browser. Also, I don't think saving image size is enough of a benefit. Pharo is already tiny compared to other technologies, and the documentation would presumably be removed for production anyway. My 2c... ----- Cheers, Sean -- View this message in context: http://forum.world.st/if-Pharo-is-key-for-you-tp4708875p4709505.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 21, 2013

Re: [Pharo-dev] Spec Question: DropListModel

by Sean P. DeNigris

Camillo Bruni-3 wrote > What is the idea behind the #displayBlock: in DropListModel? The original drop list required manual building of DropListItems, which chop the original domain objects down to maps of label strings, to action blocks. There seem to be two general use cases for drop down lists: 1. Heterogeneous items like { { 'Open a workspace' -> [ Workspace open ] }. { 'Save the image' -> [ ... ] }. Here the original implementation "works", but at the cost of forcing the user to know about and build DropListItems 2. Related items like displaying class names and returning the actual class that's selected. I never liked the way this was handled by the original implementation, but it became more jarring under Spec because other list model classes (like ListComposableModel) use #displayBlock: to adapt domain objects to list labels So the intention was two-fold: 1. to provide an API through DropListModel that hides the Items 2. to make Spec's list handling more uniform So the situation is improved for both use cases: items := { DropListItem named: aString do: aBlock. DropListItem named: aString do: aBlock. DropListItem named: aString do: aBlock }. listModel items: items. For 1 becomes: listModel addItemLabeled: aString do: aBlock; addItemLabeled: aString do: aBlock; addItemLabeled: aString do: aBlock. For 2 becomes: listModel items: aCollectionOfDomainObjects; displayBlock: [ :domainObject | ... ]. Where #2 uses the same API as ListComposableModel. But something doesn't feel quite right about the current implementation, so let's def do another pass. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-Question-DropListModel-tp4709441p4709503.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 21, 2013

Re: [Pharo-dev] Pharo Sprint pre-planning until end of year

by Sean P. DeNigris

Marcus Denker-4 wrote > The dates: > > 18/10 > 29/11 > 20/12 All work for me ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Sprint-pre-planning-until-end-of-year-tp4709137… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 21, 2013

Re: [Pharo-dev] How to test the same behavior with different data

by Jan Vrany

Hi, I actually already thought on this as I have similar problems. So far I just create a bunch of tests, passing the actual set of parameters to a common test method as message arguments. For different framework (not SUnit, but similar spirit), I introduced a notion of "parameter", each having a domain. When running test, the runner computes all possible combinations of parameter values and run the test on each such combination. I would like to have something similar in SUnit, but there are some issues. This is the feature I would like to see in SUnit 6.x, but I/we have to finish 5.0 first - I wonder if I ever find a time to do push it :-( On 21/09/13 11:06, Noury Bouraqadi wrote: > Hi, > > Last ESUG I attended the cool katas session organized by Stephan Eggermont and Laurent Laffont. > That was a good opportunity to step back and think about my TDD practices . > > To experiment with the style proposed by Laurent, I started writing tests for a pong. > I ended up having groups of nearly identical tests: > -they use exactly the same objects, send the same messages, > -but they differ only by values. > > An example, is testing the motion of the ball towards different directions or collisions with obstacles at different locations or speeds. > > Now, I wonder what is the best way to express those similar tests? > > In a short discussion before I leave, Stephane told me about tables of values. It seem that there is such a support in the ruby world in the cucumber framework. Do we have anything similar in Smalltalk world? > > BTW, the full ESUG conference was great. Thanx to local organizers, and all people that contributed to make it a success. > > Thanx, > Noury > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > > > >

Sept. 21, 2013

Re: [Pharo-dev] How to test the same behavior with different data

by kilon

why not pass your data to arrays and iterate through them ? -- View this message in context: http://forum.world.st/How-to-test-the-same-behavior-with-different-data-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 21, 2013

Re: [Pharo-dev] How to test the same behavior with different data

by StÃ©phane Ducasse

I would really like to organiser a kata afternoon :) Stef On Sep 21, 2013, at 12:06 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Hi, > > Last ESUG I attended the cool katas session organized by Stephan Eggermont and Laurent Laffont. > That was a good opportunity to step back and think about my TDD practices . > > To experiment with the style proposed by Laurent, I started writing tests for a pong. > I ended up having groups of nearly identical tests: > -they use exactly the same objects, send the same messages, > -but they differ only by values. > > An example, is testing the motion of the ball towards different directions or collisions with obstacles at different locations or speeds. > > Now, I wonder what is the best way to express those similar tests? > > In a short discussion before I leave, Stephane told me about tables of values. It seem that there is such a support in the ruby world in the cucumber framework. Do we have anything similar in Smalltalk world? > > BTW, the full ESUG conference was great. Thanx to local organizers, and all people that contributed to make it a success. > > Thanx, > Noury > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > > >

Sept. 21, 2013