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

Re: [Pharo-dev] Two possible Morphic-related issues

by phil＠highoctane.be

Stephan, Is there anything else than a SmalltalkEditor there? Now there is Rubric too, but... Phil On Wed, Apr 6, 2016 at 2:34 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 05-04-16 23:22, Carlos Lombardi wrote: > >> We had another problem to obtain a mix-style PluggableTextMorph. When the >> Text is accepted, the model is given actually a style-less Text, this is >> explicitly established in PluggableTextMorph>>acceptTextInModel. I guess >> that such is convenient when the Text being edited is code, so that the >> styles are automatically set by the editor, and must not be present in the >> code of a method. But in our case, it is the user that establishes the >> styles, so that they must be preserved. >> > > That is a problem that occurs more in the Text subsystem. E.g. > TextMorph>editorClass returns a SmalltalkEditor, which is also just wrong. > > Stephan > > >

April 6, 2016

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

by Sven Van Caekenberghe

Hi Nicolai, > On 06 Apr 2016, at 14:56, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-04-06 14:27 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Fix for review: > > === > Name: STON-Core-SvenVanCaekenberghe.71 > Author: SvenVanCaekenberghe > Time: 6 April 2016, 2:22:24.782251 pm > UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24 > Ancestors: STON-Core-SvenVanCaekenberghe.70 > > Fix a bug where STONReferences occurring as keys in Dictionaries or elements in Sets caused those to be unhealthy after materialization. Thx to Peter UhnÃ¡k for reporting this issue. > > Add 3 new unit tests to STONReaderTests > > #testDictionaryWithReferenceKeys > #testSetWithReferenceElements > #testDeepStructure > > Fix Details > > change the implementation of STONReader>>#processSubObjectsOf: from iterative to recursive (see version 39 of 29 November 2012, this might be a functional regression, see #testDeepStructure; cleanup of stack instance variable for later) so that #stonProcessSubObjects: can be overwritten with code being executed before or after full reference resolution > > imho, recursion stack depth will be equal during both writing and reading, and should be acceptable. > > overwrite #stonProcessSubObjects: in Dictionary and Set to #rehash at the end, but only when needed (minimal optimalization, see Dictionary>>#containsStonReferenceAsKey and Set>>#containsStonReference) > === > Name: STON-Tests-SvenVanCaekenberghe.63 > Author: SvenVanCaekenberghe > Time: 6 April 2016, 2:22:45.01986 pm > UUID: 0beb2322-b81a-46ee-a0e2-6648a808774a > Ancestors: STON-Tests-SvenVanCaekenberghe.62 > > (idem) > === Thanks for looking at the code. > Hi Sven, > instead of rehashing the dictionary for every ston reference, (It rehashes only once after resolving all references) > wouldn't it work to remove and readd the value after processing the subobject: > > Dictionary>>#stonProcessSubObjects: block > self keys do:[:key | > |value| > value := block value:(self removeKey: key ifAbsent:[ nil]). > self at: (block value: key) put: value]. Interesting idea. I have to think about that approach. Now, Object>>#stonProcessSubObjects: is very general and looks at named and indexed instance variables. But this probably could be replaced by something more high level and specific I guess. Adding and removing each key/value has a cost too. I try to make the simplest case very efficient and only pay a price when really needed. Anyway, time for some calculations. Thanks again for the suggestion ! Sven > > On 06 Apr 2016, at 14:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Diction… > > > > fix coming > > > >> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >>> > >>> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >>> > >>> > >>> > >>> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com>: > >>> > >>> > >>> On 05/04/2016 12:09, Sven Van Caekenberghe wrote: > >>> > >>>> Like I said, it is a hashing issue, sometimes it will be correct by accident. > >>>> > >>>> I hope you did not have to much trouble with this bug, I guess it must have been hard to chase. > >>>> > >>>> Is it urgent ? > >>>> > >>>> I probably can give you a quick fix, but I would like to think a bit more about this, since rehashing each materialised dictionary seems expensive. > >>>> > >>>> > >>>> > >>> > >>> Hi Sven, > >>> > >>> I got the same kind of problem in a personal application. > >>> > >>> I use Sets that I serialize and I had a lot of trouble because sometimes > >>> some action had strange behaviours. > >>> > >>> For example in a set with element `aSet remove: aSet anyOne` raised 'XXX > >>> not found in aSet'. > >>> > >>> I am glad to hear that it is a Ston issue and not me that used sets in a > >>> bad way :) > >>> > >>> For me too it is not urgent since I have a not of university work for > >>> the moment. > >>> > >>> > >>> > >>> How are hashed collections created/filled during ston-parsing ? > >>> If the position in a hashed collection is created by a ston-reference, that is later replaced by the "real" object, > >>> the index in the dictionary (or other hashed collections) may be wrong. > >> > >> Yes, that is indeed it, Nicolai. > >> > >> But I would like to try to minimise the rehashing as it seems expensive. But first I need a more reliable failure. > >> > >>> -- > >>> Cyril Ferlicot > >>> > >>> http://www.synectique.eu > >>> > >>> 165 Avenue Bretagne > >>> Lille 59000 France > >

April 6, 2016

Re: [Pharo-dev] [Ann] New version of Mocketry 3.0

by Denis Kudriashov

2016-04-06 14:51 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Just the English does not sound quite well for statements like: > mock should got someMessage > mock should not got anotherMessage. > > I know that there was a long discussion about naming these. I do not > remember the outcome, but still I think other alternatives would be better: > mock should haveReceived someMessage. > mock should not haveReceived anotherMessage. > or even > mock shouldnt haveReceived anotherMessage. > You right. There was discussion and I made decision :) Some of people suggest "should got" which is very short version and I like it. I know it is not completely correct from English perspective but it is readable enough and understandable. #shouldnt can be good. But usually we not use "should not" assertions. Only when we really want to deny certain condition we write it such way. In that cases full form of "should not" feels better for me. But it is always personal choice. So I made decision. (many my tests uses "should not" :)) I think I would favor: > mock stub someMessage toReturn: 1000. > or > mock stub someMessage returns: 1000. > > What do you think? Same here. Mocketry is very old and it was always idea of *will:. *You can also put block for expected action: mock stub someMessage will: [#yourResult]. (mock stub someMessageWith: Any) will: [:arg | arg + 1].

April 6, 2016

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

by Sven Van Caekenberghe

Henrik, > On 06 Apr 2016, at 14:55, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > Hi Sven, > > Instead of: > > stonProcessSubObjects: block > | didContainStonReferenceAsKey | > didContainStonReferenceAsKey := self stonProcessSubObjects: block > > super stonProcessSubObjects: block. > > self isHealthy ifFalse: [ self rehash ].. > super stonProcessSubObjects: block. > didContainStonReferenceAsKey > ifTrue: [ self rehash ] > > > One can do: > > stonProcessSubObjects: block > > super stonProcessSubObjects: block. > > self isHealthy ifFalse: [ self rehash ]. > > > And this could also be moved to HashedCollection as a generic solution for any hash based collection. Moving it there would require implementing #isHealthy as a subclass responsibility. (all current subclasses (Set, Dictionary) implements it). > > What do you think? First, thanks a lot for having a look. Now, I did spend a lot of time thinking about the best approach, and your suggestion was one of the solutions that I considered (and it certainly is the most elegant one). My goal is to make STON both correct and as fast as possible. When materialising, there are 2 phases, the second being the resolution of references. That is a separate phase because doing it directly 'in place' would result in cycles. Consider the first optimisation one level up: STONReader>>next | object | self consumeWhitespace. object := self parseValue. unresolvedReferences > 0 ifTrue: [ self processSubObjectsOf: object ]. ^ object Unless there really are unresolved references, it skips the second phase completely. Next, all Dictionaries and Sets are always freshly created and in principle (99% of the time) correct and #rehash is expensive (it rebuilds them again). We have to try to avoid this. IMO, #isHealthy is more expensive than the manual tests that I added (#containsStonReferenceAsKey and #containsStonReference). Why ? Because #isHealthy always checks all elements, and checks all their hashes, while my tests back out immediately and don't do any hashing. Would you agree ? Still, this is all a balancing act where the pro's and con's have to be carefully considered. Thanks for thinking along. Sven > Best regards, > Henrik > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe > Sent: Wednesday, April 6, 2016 2:27 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references > > Fix for review: > > === > Name: STON-Core-SvenVanCaekenberghe.71 > Author: SvenVanCaekenberghe > Time: 6 April 2016, 2:22:24.782251 pm > UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24 > Ancestors: STON-Core-SvenVanCaekenberghe.70 > > Fix a bug where STONReferences occurring as keys in Dictionaries or elements in Sets caused those to be unhealthy after materialization. Thx to Peter UhnÃ¡k for reporting this issue. > > Add 3 new unit tests to STONReaderTests > > #testDictionaryWithReferenceKeys > #testSetWithReferenceElements > #testDeepStructure > > Fix Details > > change the implementation of STONReader>>#processSubObjectsOf: from iterative to recursive (see version 39 of 29 November 2012, this might be a functional regression, see #testDeepStructure; cleanup of stack instance variable for later) so that #stonProcessSubObjects: can be overwritten with code being executed before or after full reference resolution > > imho, recursion stack depth will be equal during both writing and reading, and should be acceptable. > > overwrite #stonProcessSubObjects: in Dictionary and Set to #rehash at the end, but only when needed (minimal optimalization, see Dictionary>>#containsStonReferenceAsKey and Set>>#containsStonReference) === > Name: STON-Tests-SvenVanCaekenberghe.63 > Author: SvenVanCaekenberghe > Time: 6 April 2016, 2:22:45.01986 pm > UUID: 0beb2322-b81a-46ee-a0e2-6648a808774a > Ancestors: STON-Tests-SvenVanCaekenberghe.62 > > (idem) > === > >> On 06 Apr 2016, at 14:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Di >> ctionaries-and-Sets-when-references-occur-in-its-keys-or-elements >> >> fix coming >> >>> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com>: >>>> >>>> >>>> On 05/04/2016 12:09, Sven Van Caekenberghe wrote: >>>> >>>>> Like I said, it is a hashing issue, sometimes it will be correct by accident. >>>>> >>>>> I hope you did not have to much trouble with this bug, I guess it must have been hard to chase. >>>>> >>>>> Is it urgent ? >>>>> >>>>> I probably can give you a quick fix, but I would like to think a bit more about this, since rehashing each materialised dictionary seems expensive. >>>>> >>>>> >>>>> >>>> >>>> Hi Sven, >>>> >>>> I got the same kind of problem in a personal application. >>>> >>>> I use Sets that I serialize and I had a lot of trouble because >>>> sometimes some action had strange behaviours. >>>> >>>> For example in a set with element `aSet remove: aSet anyOne` raised >>>> 'XXX not found in aSet'. >>>> >>>> I am glad to hear that it is a Ston issue and not me that used sets >>>> in a bad way :) >>>> >>>> For me too it is not urgent since I have a not of university work >>>> for the moment. >>>> >>>> >>>> >>>> How are hashed collections created/filled during ston-parsing ? >>>> If the position in a hashed collection is created by a >>>> ston-reference, that is later replaced by the "real" object, the index in the dictionary (or other hashed collections) may be wrong. >>> >>> Yes, that is indeed it, Nicolai. >>> >>> But I would like to try to minimise the rehashing as it seems expensive. But first I need a more reliable failure. >>> >>>> -- >>>> Cyril Ferlicot >>>> >>>> http://www.synectique.eu >>>> >>>> 165 Avenue Bretagne >>>> Lille 59000 France >> > >

April 6, 2016

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

by Nicolai Hess

2016-04-06 14:27 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Fix for review: > > === > Name: STON-Core-SvenVanCaekenberghe.71 > Author: SvenVanCaekenberghe > Time: 6 April 2016, 2:22:24.782251 pm > UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24 > Ancestors: STON-Core-SvenVanCaekenberghe.70 > > Fix a bug where STONReferences occurring as keys in Dictionaries or > elements in Sets caused those to be unhealthy after materialization. Thx to > Peter UhnÃ¡k for reporting this issue. > > Add 3 new unit tests to STONReaderTests > > #testDictionaryWithReferenceKeys > #testSetWithReferenceElements > #testDeepStructure > > Fix Details > > change the implementation of STONReader>>#processSubObjectsOf: from > iterative to recursive (see version 39 of 29 November 2012, this might be a > functional regression, see #testDeepStructure; cleanup of stack instance > variable for later) so that #stonProcessSubObjects: can be overwritten with > code being executed before or after full reference resolution > > imho, recursion stack depth will be equal during both writing and reading, > and should be acceptable. > > overwrite #stonProcessSubObjects: in Dictionary and Set to #rehash at the > end, but only when needed (minimal optimalization, see > Dictionary>>#containsStonReferenceAsKey and Set>>#containsStonReference) > === > Name: STON-Tests-SvenVanCaekenberghe.63 > Author: SvenVanCaekenberghe > Time: 6 April 2016, 2:22:45.01986 pm > UUID: 0beb2322-b81a-46ee-a0e2-6648a808774a > Ancestors: STON-Tests-SvenVanCaekenberghe.62 > > (idem) > === > Hi Sven, instead of rehashing the dictionary for every ston reference, wouldn't it work to remove and readd the value after processing the subobject: Dictionary>>#stonProcessSubObjects: block self keys do:[:key | |value| value := block value:(self removeKey: key ifAbsent:[ nil]). self at: (block value: key) put: value]. > > > On 06 Apr 2016, at 14:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Diction… > > > > fix coming > > > >> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >>> > >>> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >>> > >>> > >>> > >>> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque < > cyril.ferlicot(a)gmail.com>: > >>> > >>> > >>> On 05/04/2016 12:09, Sven Van Caekenberghe wrote: > >>> > >>>> Like I said, it is a hashing issue, sometimes it will be correct by > accident. > >>>> > >>>> I hope you did not have to much trouble with this bug, I guess it > must have been hard to chase. > >>>> > >>>> Is it urgent ? > >>>> > >>>> I probably can give you a quick fix, but I would like to think a bit > more about this, since rehashing each materialised dictionary seems > expensive. > >>>> > >>>> > >>>> > >>> > >>> Hi Sven, > >>> > >>> I got the same kind of problem in a personal application. > >>> > >>> I use Sets that I serialize and I had a lot of trouble because > sometimes > >>> some action had strange behaviours. > >>> > >>> For example in a set with element `aSet remove: aSet anyOne` raised > 'XXX > >>> not found in aSet'. > >>> > >>> I am glad to hear that it is a Ston issue and not me that used sets in > a > >>> bad way :) > >>> > >>> For me too it is not urgent since I have a not of university work for > >>> the moment. > >>> > >>> > >>> > >>> How are hashed collections created/filled during ston-parsing ? > >>> If the position in a hashed collection is created by a ston-reference, > that is later replaced by the "real" object, > >>> the index in the dictionary (or other hashed collections) may be > wrong. > >> > >> Yes, that is indeed it, Nicolai. > >> > >> But I would like to try to minimise the rehashing as it seems > expensive. But first I need a more reliable failure. > >> > >>> -- > >>> Cyril Ferlicot > >>> > >>> http://www.synectique.eu > >>> > >>> 165 Avenue Bretagne > >>> Lille 59000 France > > > > >

April 6, 2016

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

by Henrik Nergaard

Hi Sven, Instead of: stonProcessSubObjects: block | didContainStonReferenceAsKey | didContainStonReferenceAsKey := self stonProcessSubObjects: block super stonProcessSubObjects: block. self isHealthy ifFalse: [ self rehash ].. super stonProcessSubObjects: block. didContainStonReferenceAsKey ifTrue: [ self rehash ] One can do: stonProcessSubObjects: block super stonProcessSubObjects: block. self isHealthy ifFalse: [ self rehash ]. And this could also be moved to HashedCollection as a generic solution for any hash based collection. Moving it there would require implementing #isHealthy as a subclass responsibility. (all current subclasses (Set, Dictionary) implements it). What do you think? Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: Wednesday, April 6, 2016 2:27 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references Fix for review: === Name: STON-Core-SvenVanCaekenberghe.71 Author: SvenVanCaekenberghe Time: 6 April 2016, 2:22:24.782251 pm UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24 Ancestors: STON-Core-SvenVanCaekenberghe.70 Fix a bug where STONReferences occurring as keys in Dictionaries or elements in Sets caused those to be unhealthy after materialization. Thx to Peter UhnÃ¡k for reporting this issue. Add 3 new unit tests to STONReaderTests #testDictionaryWithReferenceKeys #testSetWithReferenceElements #testDeepStructure Fix Details change the implementation of STONReader>>#processSubObjectsOf: from iterative to recursive (see version 39 of 29 November 2012, this might be a functional regression, see #testDeepStructure; cleanup of stack instance variable for later) so that #stonProcessSubObjects: can be overwritten with code being executed before or after full reference resolution imho, recursion stack depth will be equal during both writing and reading, and should be acceptable. overwrite #stonProcessSubObjects: in Dictionary and Set to #rehash at the end, but only when needed (minimal optimalization, see Dictionary>>#containsStonReferenceAsKey and Set>>#containsStonReference) === Name: STON-Tests-SvenVanCaekenberghe.63 Author: SvenVanCaekenberghe Time: 6 April 2016, 2:22:45.01986 pm UUID: 0beb2322-b81a-46ee-a0e2-6648a808774a Ancestors: STON-Tests-SvenVanCaekenberghe.62 (idem) === > On 06 Apr 2016, at 14:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Di > ctionaries-and-Sets-when-references-occur-in-its-keys-or-elements > > fix coming > >> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com>: >>> >>> >>> On 05/04/2016 12:09, Sven Van Caekenberghe wrote: >>> >>>> Like I said, it is a hashing issue, sometimes it will be correct by accident. >>>> >>>> I hope you did not have to much trouble with this bug, I guess it must have been hard to chase. >>>> >>>> Is it urgent ? >>>> >>>> I probably can give you a quick fix, but I would like to think a bit more about this, since rehashing each materialised dictionary seems expensive. >>>> >>>> >>>> >>> >>> Hi Sven, >>> >>> I got the same kind of problem in a personal application. >>> >>> I use Sets that I serialize and I had a lot of trouble because >>> sometimes some action had strange behaviours. >>> >>> For example in a set with element `aSet remove: aSet anyOne` raised >>> 'XXX not found in aSet'. >>> >>> I am glad to hear that it is a Ston issue and not me that used sets >>> in a bad way :) >>> >>> For me too it is not urgent since I have a not of university work >>> for the moment. >>> >>> >>> >>> How are hashed collections created/filled during ston-parsing ? >>> If the position in a hashed collection is created by a >>> ston-reference, that is later replaced by the "real" object, the index in the dictionary (or other hashed collections) may be wrong. >> >> Yes, that is indeed it, Nicolai. >> >> But I would like to try to minimise the rehashing as it seems expensive. But first I need a more reliable failure. >> >>> -- >>> Cyril Ferlicot >>> >>> http://www.synectique.eu >>> >>> 165 Avenue Bretagne >>> Lille 59000 France >

April 6, 2016

Re: [Pharo-dev] [Ann] New version of Mocketry 3.0

by Tudor Girba

Hi, Nice work! Just the English does not sound quite well for statements like: mock should got someMessage mock should not got anotherMessage. I know that there was a long discussion about naming these. I do not remember the outcome, but still I think other alternatives would be better: mock should haveReceived someMessage. mock should not haveReceived anotherMessage. or even mock shouldnt haveReceived anotherMessage. Also, for this statement: mock stub someMessage willReturn: 1000. I think I would favor: mock stub someMessage toReturn: 1000. or mock stub someMessage returns: 1000. What do you think? Cheers, Doru > On Apr 6, 2016, at 5:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I am glad to present simplest mocks for Pharo. > In this version Mocketry is dramatically improved and changed. I try to provide most simple way to stub any message to any object and to verify any occurred behaviour. > > You can read full details in my blog http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html > > Here is short example: > > mock := Mock new. > mock stub someMessage willReturn: 1000. > > mock someMessage should be: 1000. > mock should got someMessage. > mock should not got anotherMessage. > > rect := 0@0 corner: 2@3. > rect stub width willReturn: 1000. > > rect area should be: 3000 "area = width * height". > rect should got width. -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

April 6, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by stepharo

ok let me know when you have a new "stable" version so that I try my example. Stef Le 4/4/16 23:21, Andrei Chis a Ã©crit : > Hi Stef, > > Currently there was a distinction between Shape and Path which turn > out to be confusing. So Shape will go away and there will be just a > Path (line, circle, rectangle, etc). We started to refactor this > during the PharoDays. And yes, Rectangle will be polymorphic with Path. > > BlElement does support clipping and click detection by paths but right > now they were implicit and you needed to subclass BlElement to > override them independently. We'll change this so one can set them > independently in BlElement. > > Yes, BlElement had a default path for drawing but that will go away. > By default BlElement will have an empty drawOn... method. So to create > a custom widget you can subclass BlElement, override drawOn... and use > the canvas to draw anything you wish. > > There will be a subclass of BlElement that will add more drawing > oriented logic but BlElement will be independent of that. > > Yes, the API of the canvas is not perfect but we're improving. > > Cheers, > Andrei > > On Mon, Apr 4, 2016 at 6:00 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > I saw in bleedingEdge it is different and looks better. > Now I was wondering why shape did not do the rendering and I > thought that this is may be because a shape can be used for doing > something else > than rendering. For example clipping or as igor mentioned defining > the shape of the interaction > > > > drawOnSpartaCanvas: aCanvas > "Actually render receiver on aCanvas in local bounds. > Override to customize. > aCanvas is an instance of AthensCanvas > aCanvas must not be nil" > > self assert: self shape path context isNotNil. > > aCanvas > clipPreserveBy: self shape during: [ > aCanvas paintGroup: [ > aCanvas setPaint: self shape fillPaint. > aCanvas fillPreserve. > aCanvas paintMode source. > aCanvas setStrokePaint: self shape strokePaint. > aCanvas stroke ] ] > > > > unprotectedFullDrawOnSpartaCanvas: aCanvas > "Draw the full structure on the given Canvas withing drawing > bounds > without caring about any errors and visibility. I am > responsible for > clipping and transforming canvas's path to local coordinates > to allow simpler actual drawing in drawOnAthensCanvas: > Additional checks should be implemented in fullDrawOnAthensCanvas: > aCanvas is an instance of AthensCanvas. > aCanvas must not be nil. > @see BlElement>>#fullDrawOnAthensCanvas: > @see BlElement>>#drawOnAthensCanvas:" > self shape adaptTo: self. > self shape path context: aCanvas. > > aCanvas > transform: self transformation > during: [ > self clippingStrategy > clip: self > on: aCanvas > during: [ self drawOnSpartaCanvas: aCanvas ] > childrenDuring: [ self drawChildrenOnSpartaCanvas: > aCanvas ] ] > >

April 6, 2016

Re: [Pharo-dev] [Ann] New version of Mocketry 3.0

by Denis Kudriashov

And I add chapters in PharoInProgress 2016-04-06 14:29 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I am glad to present simplest mocks for Pharo. > In this version Mocketry is dramatically improved and changed. I try to > provide most simple way to stub any message to any object and to verify any > occurred behaviour. > > You can read full details in my blog > http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html > > Here is short example: > > mock := Mock new. > mock *stub* someMessage *willReturn:* 1000. > mock someMessage should be: 1000. > mock *should got* someMessage. > mock *should not* *got* anotherMessage. > rect := 0@0 corner: 2@3. > rect *stub* width willReturn: 1000. > rect area should be: 3000 "area = width * height". > rect *should got* width. >

April 6, 2016

Re: [Pharo-dev] Two possible Morphic-related issues

by Stephan Eggermont

On 05-04-16 23:22, Carlos Lombardi wrote: > We had another problem to obtain a mix-style PluggableTextMorph. When the > Text is accepted, the model is given actually a style-less Text, this is > explicitly established in PluggableTextMorph>>acceptTextInModel. I guess > that such is convenient when the Text being edited is code, so that the > styles are automatically set by the editor, and must not be present in the > code of a method. But in our case, it is the user that establishes the > styles, so that they must be preserved. That is a problem that occurs more in the Text subsystem. E.g. TextMorph>editorClass returns a SmalltalkEditor, which is also just wrong. Stephan

April 6, 2016