April 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] leansleft problem

by Ben Coman

Roelof Wobben wrote: > If I understood everything well on page 26 my initialize methods must > look like this: > > Cell >> initialize > super initialize. > self initializeActiveSegments. > self initializeExitSides. > self leanleft. > > BlankCell >> initialize > super initialize. > self initializeExitSides. > > MirrorCell >> initialize > super initialize > self leansLeft: true > > Why then I see a message that #leanleft is not Understood in Blankcell. > or do I misunderstood that page. I find it a very confusing page. > > Roelof > > I've updated your example using the # and >> convention to describe methods and the classes they belong to. So the MNU (Message Not Understood) indicates that BlankCell doesn't know how to #leanLeft Now the first question you should ask yourself is "Does BlankCell or one of its superclasses define #leftLeft ?" Or the same question in another form "Which classes is #leanLeft defined on?" Note that the #leanleft is distinct from #leanLeft. ------------------------complete above before continuing Your next question is "what is causing #leanLeft" to be called on a BlankCell?" Now to simply things I presume evaluating the following in Workspace creates the same error... BlankCell new <doIt> So what you want to do is BlankCell new <debugIt> and trace through until you find where #leanLeft is about to be executed. Pay attention in the call stack to when BlankCell>>initialize transitions to Cell>initialize. ------------------------complete above before continuing Now when debugging "BlankCell new" traces into Cell >> initialize, note that "self leanLeft" refers send the message #leanLeft to the BlankCell object, which then checks to see if BlankCell>>leanLeft is defined, and then looks in the superclass to see if Cell>>leanLeft is defined, and the looks in the next superclass to see if Object>>leanLeft is defined - and if a definition is not found then BlankCell has a MNU. So... I think your Cell>>initialize is incorrect. It would be useful to know in more detail what makes you think it should look like that - to deconstruct your confusion. Cell was only introduced on page 35, and its initialize method looked like this Cell>>initialize super initialize. self initializeActiveSegments. I see nothing else on page 25 or 26 that indicates any further change to Cell>>initialize. The only thing I can guess at it that you've confused the bottom right snapshot as applying to Cell when I guess it applies only to MirrorCell. cheers -ben

April 2, 2014

Re: [Pharo-users] Drag and drop items between list views

by MartinW

Thank you. This is a step forward. The thing is i can't hardcode the collections. In the end product i don't have two but seven lists, so i must be able to detect in the acceptDropBlock which is the receiving collection/list. Goubier Thierry wrote > Ok, look at that code: > > | collection1 collection2 list1 list2 | > collection1 := #(1 2 3 4 5) asOrderedCollection. > collection2 := #($a $b $c $d $e) asOrderedCollection. > list1 := ListModel new. > list1 items: collection1. > list1 dragEnabled: true. > list1 dropEnabled: true. > list1 acceptDropBlock: > [ :transfer :event :source :receiver :index | > transfer passenger do: > [:e | > collection1 insert: e first before: index. > collection2 remove: e first]. > list1 items: collection1. > list2 items: collection2 ]. > list1 openWithSpec. > list2 := ListModel new. > list2 items: collection2. > list2 dragEnabled: true. > list2 dropEnabled: true. > list2 acceptDropBlock: [ :transfer :event :source :receiver :index | > self halt ]. > ^ list2 openWithSpec > > Now you can drag and drop from list2 to list1, and I think the code is > good for drag and drop of multiple items. -- View this message in context: http://forum.world.st/Drag-and-drop-items-between-list-views-tp4752285p4752… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 2, 2014

Re: [Pharo-users] Drag and drop items between list views

by Goubier Thierry

Ok, look at that code: | collection1 collection2 list1 list2 | collection1 := #(1 2 3 4 5) asOrderedCollection. collection2 := #($a $b $c $d $e) asOrderedCollection. list1 := ListModel new. list1 items: collection1. list1 dragEnabled: true. list1 dropEnabled: true. list1 acceptDropBlock: [ :transfer :event :source :receiver :index | transfer passenger do: [:e | collection1 insert: e first before: index. collection2 remove: e first]. list1 items: collection1. list2 items: collection2 ]. list1 openWithSpec. list2 := ListModel new. list2 items: collection2. list2 dragEnabled: true. list2 dropEnabled: true. list2 acceptDropBlock: [ :transfer :event :source :receiver :index | self halt ]. ^ list2 openWithSpec Now you can drag and drop from list2 to list1, and I think the code is good for drag and drop of multiple items. Thierry Le 02/04/2014 17:08, MartinW a Ã©crit : > I tried the following, but i do not know what to do in the acceptDropBlock. > It seems the receiver in the block is only an item in a list, but how do i > get the receiving list/collection? > What i want to achieve is that a user can drag the '1' from list1 to list2 > and the resulting collections will then be collection1: (2 3 4 5) > collection2: ($a $b $c $d $e 1) and the lists will be updated accordingly. > > > | collection1 collection2 list1 list2 | > > collection1 := #(1 2 3 4 5). > collection2 := #($a $b $c $d $e). > > list1 := ListModel new. > list1 items: collection1. > list1 dragEnabled: true. > list1 dropEnabled: true. > list1 acceptDropBlock: [ :transfer :event :source :receiver :index | self > halt ]. > list1 openWithSpec. > > list2 := ListModel new. > list2 items: collection2. > list2 dragEnabled: true. > list2 dropEnabled: true. > list2 acceptDropBlock: [ :transfer :event :source :receiver :index | self > halt ]. > list2 openWithSpec. > > > Goubier Thierry wrote >> yes, most list-like widgets can drag and drop. Feedback when inserting >> items in lists could be improved, however (i.e. you can drop on a list >> item, but I've never seen the feedback for dropping between list items). >> Le 02/04/2014 16:09, MartinW a Ã©crit : >>> i have to make a UI where users can sort items (sentences) into different >>> collections by dragging and dropping them between list views. Is this >>> possible with the widgets currently available in Pharo? > > > > > > -- > View this message in context: http://forum.world.st/Drag-and-drop-items-between-list-views-tp4752285p4752… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 2, 2014

Re: [Pharo-users] leansleft problem

by Roelof Wobben

April 2, 2014

Re: [Pharo-users] Drag and drop items between list views

by MartinW

I tried the following, but i do not know what to do in the acceptDropBlock. It seems the receiver in the block is only an item in a list, but how do i get the receiving list/collection? What i want to achieve is that a user can drag the '1' from list1 to list2 and the resulting collections will then be collection1: (2 3 4 5) collection2: ($a $b $c $d $e 1) and the lists will be updated accordingly. | collection1 collection2 list1 list2 | collection1 := #(1 2 3 4 5). collection2 := #($a $b $c $d $e). list1 := ListModel new. list1 items: collection1. list1 dragEnabled: true. list1 dropEnabled: true. list1 acceptDropBlock: [ :transfer :event :source :receiver :index | self halt ]. list1 openWithSpec. list2 := ListModel new. list2 items: collection2. list2 dragEnabled: true. list2 dropEnabled: true. list2 acceptDropBlock: [ :transfer :event :source :receiver :index | self halt ]. list2 openWithSpec. Goubier Thierry wrote > yes, most list-like widgets can drag and drop. Feedback when inserting > items in lists could be improved, however (i.e. you can drop on a list > item, but I've never seen the feedback for dropping between list items). > Le 02/04/2014 16:09, MartinW a Ã©crit : >> i have to make a UI where users can sort items (sentences) into different >> collections by dragging and dropping them between list views. Is this >> possible with the widgets currently available in Pharo? -- View this message in context: http://forum.world.st/Drag-and-drop-items-between-list-views-tp4752285p4752… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 2, 2014

Re: [Pharo-users] leansleft problem

by Nicolai Hess

2014-04-02 16:40 GMT+02:00 Roelof Wobben <r.wobben(a)home.nl>: > If I understood everything well on page 26 my Cell initialize must look > like this: > > initialize > super initialize. > self initializeActiveSegments. > self initializeExitSides. > self leanleft. > > The Blankcell initialize must look like this : > > initialize > super initialize. > self initializeExitSides. > > And the MirrorCell initialize must look like this : > > initialize > super initialize > self leansLeft: true > > Why then I see a message that leanleft is not Understood in Blankcell. > or do I misunderstood that page. I find it a very confusing page. > > Roelof > > No, Cell initialize is super initialize. self initializeActiveSegments. MirrorCell initialize is super initialize. self initializeExitSides. self leanLeft

April 2, 2014

leansleft problem

by Roelof Wobben

If I understood everything well on page 26 my Cell initialize must look like this: initialize super initialize. self initializeActiveSegments. self initializeExitSides. self leanleft. The Blankcell initialize must look like this : initialize super initialize. self initializeExitSides. And the MirrorCell initialize must look like this : initialize super initialize self leansLeft: true Why then I see a message that leanleft is not Understood in Blankcell. or do I misunderstood that page. I find it a very confusing page. Roelof

April 2, 2014

Re: [Pharo-users] Question on style

by Camille Teruel

Hi Nacho, I wouldn't throw an error because otherwise one must know beforehand that an equation is non-resolvable or must use #on:do: everywhere. Since that when you ask to resolve an equation you get back a collection of solutions, a non-resolvable equation could just return an empty collection, couldn't it?. If you really want to consider that asking to resolve a non-resolvable equation is an error, another solution would be to provide a #rootsIfNone: method. That's a common pattern in Smalltalk. I would also rename 'checkNegative' to 'discriminant', because it's not obvious to see what that variable represents at first glance. On 2 avr. 2014, at 15:14, nacho <0800nacho(a)gmail.com> wrote: > Well here is again, the refactored version. > > "The idea is to have a class to calculate quadratic equations. > This second draft still only calculates real roots (leaving aside imaginary > roots). > But thanks to Damien Cassou I think it has a better style. > > A QuadraticEquation is a class used to solve Quadratic Equations of the > form: ax^2 + bx + c = 0, where a is not 0. > > You can set the coefficients using the following method > setQuadraticCoefficient: linearCoefficient: constant: " > > Object subclass: #QuadraticEquation > instanceVariableNames: 'quadraticCoefficient linearCoefficient constant > roots' > classVariableNames: '' > category: 'IS-Math' > > "I create accessors (only getters for each term) and then the following > method to set the terms" > > QuadraticEquation>>setQuadraticCoefficient: aNumber1 linearCoefficient: > aNumber2 constant: aNumber3 > quadraticCoefficient := aNumber1. > linearCoefficient := aNumber2. > constant := aNumber3 > > > > QuadraticEquation>>calculateRoots > | checkNegative | > checkNegative := linearCoefficient squared - ( 4 * quadraticCoefficient * > constant). > > checkNegative >= 0 > ifFalse: [ Error signal: 'Negative square root'] > ifTrue: [ ^ self solveRoots: checkNegative] > > QuadraticEquation>>solveRoots: aTerm > | rootA rootB | > roots := OrderedCollection new. > rootA := (linearCoefficient negated + aTerm sqrt) / (2 * > quadraticCoefficient). > rootB := (linearCoefficient negated - aTerm sqrt) / (2 * > quadraticCoefficient). > roots add: rootA; add: rootB. > ^ roots > > > " Example: -3x^2+2x+2=0 > an OrderedCollection(-0.5485837703548636 1.2152504370215302) > > print(it) > > | anEquation | > anEquation := QuadraticEquation new. > anEquation setQuadraticCoefficient: -3 linearCoefficient: 2 constant: 2. > anEquation calculateRoots." > > Thanks again > Best, > Nacho > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/Question-on-style-tp4752165p4752262.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

April 2, 2014

Re: [Pharo-users] lasergame problem with Blankcell

by Camille Teruel

On 2 avr. 2014, at 16:27, Mark Rizun <mrizun(a)gmail.com> wrote: > That is really wierd:) > > > 2014-04-02 17:17 GMT+03:00 Roelof Wobben <r.wobben(a)home.nl>: > Mark Rizun schreef op 2-4-2014 15:16: >> The mistake is simple. You have to write as follows (just replace cell for self in two lines before should and shouldnt): >> >> testCellOnState >> | cell | >> cell := BlankCell new. >> self should: [ cell isOff ]. >> self shouldnt: [ cell isOn ]. >> >> > > You are abolute right. > Wierd that earlier test succceed where this error also is made. It's just because before you were subclassing BlankCell from TestCase so BlankCell instances were answering #should: . > > Roelof > >

April 2, 2014

Re: [Pharo-users] lasergame problem with Blankcell

by Mark Rizun

That is really wierd:) 2014-04-02 17:17 GMT+03:00 Roelof Wobben <r.wobben(a)home.nl>: > Mark Rizun schreef op 2-4-2014 15:16: > > The mistake is simple. You have to write as follows (just replace cell for > self in two lines before should and shouldnt): > > testCellOnState > | cell | > cell := BlankCell new. > self should: [ cell isOff ]. > self shouldnt: [ cell isOn ]. > > > > You are abolute right. > Wierd that earlier test succceed where this error also is made. > > Roelof > >

April 2, 2014