- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 59f46a: 40151

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 59f46ae2e98655799a7c05db47e39ac8f911a55c https://github.com/pharo-project/pharo-core/commit/59f46ae2e98655799a7c05db… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-04 (Mon, 04 Aug 2014) Changed paths: A Kernel.package/DegeneratedRectangle.class/README.md A Kernel.package/DegeneratedRectangle.class/definition.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script151.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40151.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40151 2489 Strange behavior of Rectangle https://pharo.fogbugz.com/f/cases/2489 Little fix to continue moving. http://files.pharo.org/image/40/40151.zip

Aug. 4, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Nicolai Hess

2014-08-04 9:57 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 04 Aug 2014, at 9:31 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-08-04 8:50 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> >> On 03 Aug 2014, at 5:55 , ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> > >> > >> > Right, current hash is bad and long to compute. >> > >> > I think we should use instead >> > BasicIndexedEyeElement >> hash >> > ^ index hashMultiply >> > >> > host identityHash and index hash may lead to many collisions... >> > What do you think ? >> > >> >> I agree thereâs not much value in including host in the hash for the use >> case of the icon lookup cache, since those were per host anyways (iirc). >> Index hash will be a sequential number, I havenât checked the usage >> closely to see if itâll be a problem wrt. collisions, but removal at least >> might be slow (if thatâs ever done) due to lots of scanning needed to find >> the nil slot. Using hashMultiply seems a good precaution. >> >> Cheers, >> Henry >> > > > And as far as I know, the icon lookup isn't needed for the inspector, as > it does not show any icons at all! > > > Well, it still needs to figure out there is no icon to be displayed for > the entryâ¦ > In that process, it caches the result (nil), and that cache is too > expensive to query later on, due to the expensive hash calculation needed > to find an entry. > > Cheers, > Henry > Thats the reason I created the issue 13315 NewList without icons (13315 <https://pharo.fogbugz.com/default.asp?13315>) We need a way to tell NewList to not use and therefore don't try to lookup icons, if the client (the inspector) don't provide any icons at all. Maybe NewList should not hold an icon cache at all, but rely on the icon provider for proper caching. Nicolai

Aug. 4, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Henrik Johansen

On 04 Aug 2014, at 9:31 , Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-04 8:50 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 03 Aug 2014, at 5:55 , ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > > > > Right, current hash is bad and long to compute. > > > > I think we should use instead > > BasicIndexedEyeElement >> hash > > ^ index hashMultiply > > > > host identityHash and index hash may lead to many collisions... > > What do you think ? > > > > I agree thereâs not much value in including host in the hash for the use case of the icon lookup cache, since those were per host anyways (iirc). > Index hash will be a sequential number, I havenât checked the usage closely to see if itâll be a problem wrt. collisions, but removal at least might be slow (if thatâs ever done) due to lots of scanning needed to find the nil slot. Using hashMultiply seems a good precaution. > > Cheers, > Henry > > > And as far as I know, the icon lookup isn't needed for the inspector, as it does not show any icons at all! Well, it still needs to figure out there is no icon to be displayed for the entryâ¦ In that process, it caches the result (nil), and that cache is too expensive to query later on, due to the expensive hash calculation needed to find an entry. Cheers, Henry

Aug. 4, 2014

Re: [Pharo-dev] About https://pharo.fogbugz.com/f/cases/2489

by stepharo

So apparently if I introduce the missing exception (that we should have removed) the system works. I will try to do a new integration and after we will fix the problem with igor. If I cannot integrate them I will see tomorrow with esteban. Stef

Aug. 4, 2014

Re: [Pharo-dev] rethinking compilation notifications

by Baptiste Quide

It seems to be very great! Hope to see this feature soon in the image ----- Mail original ----- > De: "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> > Ã: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: "moose-dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is > welcome" <pharo-users(a)lists.pharo.org> > EnvoyÃ©: Lundi 4 AoÃ»t 2014 09:26:29 > Objet: Re: [Pharo-dev] rethinking compilation notifications > So beautiful :) > 2014-08-03 22:09 GMT+02:00 Tudor Girba < tudor(a)tudorgirba.com > : > > Hi, > > > The next stop in our little tour around code actions was the compilation > > notifications. Again, we used a popper interface to show the error without > > affecting the underlying text editor: > > > You can find more details here: > > > http://www.humane-assessment.com/blog/rethinking-compilation-notifications-… > > > Please let us know what you think. > > > Cheers, > > > Doru > > > -- > > > www.tudorgirba.com > > > "Every thing has its own flow" >

Aug. 4, 2014

Re: [Pharo-dev] About https://pharo.fogbugz.com/f/cases/2489

by stepharo

Thanks this is strange because we used the modified system. I see some problems with MC and changes tracking recently and this is annoying. Because this reference should not be there. Now I do not know how to rollback a change so the system will stay broken until I find and I do not have the time today. Stef > Pharo 40150 after typing two characters in a Workspace: > setOrigin:corner: referese to the undefined Object: > "DegeneratedRectangle" > > UndefinedObject(Object)>>doesNotUnderstand: #signal > CharacterBlock(Rectangle)>>setOrigin:corner: > CharacterBlock>>stringIndex:text:topLeft:extent: > CharacterBlockScanner>>characterBlockAtPoint:index:in: > Paragraph>>characterBlockAtPoint: > Paragraph>>buildSelectionBlocksFrom:to: > Paragraph>>displayExtraSelectionOn: > TextMorphForEditView>>drawOn: > FormCanvas(Canvas)>>draw: > FormCanvas(Canvas)>>drawMorph: > [ > (aCanvas isVisible: self bounds) > ifTrue: [ aCanvas drawMorph: self ]. > self drawSubmorphsOn: aCanvas. > self drawDropHighlightOn: aCanvas. > self drawMouseDownHighlightOn: aCanvas ] in [ > "Note: At some point we should generalize this into some sort of > multi-canvas so that we can cross-optimize some drawing > operations." > "Pass 1: Draw eventual drop-shadow" > self hasDropShadow > ifTrue: [ self drawDropShadowOn: aCanvas ]. "Pass 2: Draw > receiver itself" > aCanvas > roundCornersOf: self > during: [ > (aCanvas isVisible: self bounds) > ifTrue: [ aCanvas drawMorph: self ]. > self drawSubmorphsOn: aCanvas. > self drawDropHighlightOn: aCanvas. > self drawMouseDownHighlightOn: aCanvas ] ] in > TextMorphForEditView(Morph)>>fullDrawOn: in Block: [ ... > FormCanvas>>roundCornersOf:in:during: > FormCanvas(Canvas)>>roundCornersOf:during: > [ > "Note: At some point we should generalize this into some sort of > multi-canvas so that we can cross-optimize some drawing > operations." > "Pass 1: Draw eventual drop-shadow" > self hasDropShadow > ifTrue: [ self drawDropShadowOn: aCanvas ]. "Pass 2: Draw > receiver itself" > aCanvas > roundCornersOf: self > during: [ > (aCanvas isVisible: self bounds) > ifTrue: [ aCanvas drawMorph: self ]. > self drawSubmorphsOn: aCanvas. > self drawDropHighlightOn: aCanvas. > self drawMouseDownHighlightOn: aCanvas ] ] in > TextMorphForEditView(Morph)>>fullDrawOn: in Block: [ ... > BlockClosure>>on:do: > TextMorphForEditView(Morph)>>fullDrawOn: > FormCanvas(Canvas)>>fullDraw: > FormCanvas(Canvas)>>fullDrawMorph: > [ :m | myCanvas fullDrawMorph: m ] in [ :myCanvas | > (self angle ~= 0.0 or: [ self scale ~= 1.0 ]) > ifTrue: [ FreeTypeSettings current forceNonSubPixelDuring: [ > submorphs reverseDo: [ :m | myCanvas fullDrawMorph: m ] ] ] > ifFalse: [ submorphs reverseDo: [ :m | myCanvas fullDrawMorph: m ] > ] ] in TransformMorph>>drawSubmorphsOn: in Block: [ :m | myCanvas > fullDrawMorph: m ] > Array(SequenceableCollection)>>reverseDo: > [ :myCanvas | > (self angle ~= 0.0 or: [ self scale ~= 1.0 ]) > ifTrue: [ FreeTypeSettings current forceNonSubPixelDuring: [ > submorphs reverseDo: [ :m | myCanvas fullDrawMorph: m ] ] ] > ifFalse: [ submorphs reverseDo: [ :m | myCanvas fullDrawMorph: m ] > ] ] in TransformMorph>>drawSubmorphsOn: in Block: [ :myCanvas | ... > FormCanvas>>transformBy:clippingTo:during:smoothing: > TransformMorph>>drawSubmorphsOn: > [ > (aCanvas isVisible: self bounds) > ifTrue: [ aCanvas drawMorph: self ]. > self drawSubmorphsOn: aCanvas. > self drawDropHighlightOn: aCanvas. > self drawMouseDownHighlightOn: aCanvas ] in [ > "Note: At some point we should generalize this into some sort of > multi-canvas so that we can cross-optimize some drawing > operations." > "Pass 1: Draw eventual drop-shadow" > self hasDropShadow > ifTrue: [ self drawDropShadowOn: aCanvas ]. "Pass 2: Draw > receiver itself" > aCanvas > roundCornersOf: self > during: [ > (aCanvas isVisible: self bounds) > ifTrue: [ aCanvas drawMorph: self ]. > self drawSubmorphsOn: aCanvas. > self drawDropHighlightOn: aCanvas. > self drawMouseDownHighlightOn: aCanvas ] ] in > TransformMorph(Morph)>>fullDrawOn: in Block: [ ... > FormCanvas>>roundCornersOf:in:during: > FormCanvas(Canvas)>>roundCornersOf:during: > [ > "Note: At some point we should generalize this into some sort of > multi-canvas so that we can cross-optimize some drawing > operations." > "Pass 1: Draw eventual drop-shadow" > self hasDropShadow > ifTrue: [ self drawDropShadowOn: aCanvas ]. "Pass 2: Draw > receiver itself" > aCanvas > roundCornersOf: self > during: [ > (aCanvas isVisible: self bounds) > ifTrue: [ aCanvas drawMorph: self ]. > self drawSubmorphsOn: aCanvas. > self drawDropHighlightOn: aCanvas. > self drawMouseDownHighlightOn: aCanvas ] ] in > TransformMorph(Morph)>>fullDrawOn: in Block: [ ... > BlockClosure>>on:do: > TransformMorph(Morph)>>fullDrawOn: > FormCanvas(Canvas)>>fullDraw: > > > > 2014-08-03 18:12 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > We finished (we hope) a really long effort to be such that we > cannot have "negative" rectangles. > It implied fixing around 250 users of layoutFrame and a lot more. > > We introduced point:point: to create rectangles. > We improved many little points. > > We deeply tested the image but we never know it may happen that a > layout policy produce strange rectangles again. > If you find some glitches we will fix them. > > Stef and Igor > >

Aug. 4, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Nicolai Hess

2014-08-04 8:50 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 03 Aug 2014, at 5:55 , ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > > > > Right, current hash is bad and long to compute. > > > > I think we should use instead > > BasicIndexedEyeElement >> hash > > ^ index hashMultiply > > > > host identityHash and index hash may lead to many collisions... > > What do you think ? > > > > I agree thereâs not much value in including host in the hash for the use > case of the icon lookup cache, since those were per host anyways (iirc). > Index hash will be a sequential number, I havenât checked the usage > closely to see if itâll be a problem wrt. collisions, but removal at least > might be slow (if thatâs ever done) due to lots of scanning needed to find > the nil slot. Using hashMultiply seems a good precaution. > > Cheers, > Henry > And as far as I know, the icon lookup isn't needed for the inspector, as it does not show any icons at all!

Aug. 4, 2014

Re: [Pharo-dev] rethinking compilation notifications

by Santiago Bragagnolo

So beautiful :) 2014-08-03 22:09 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > The next stop in our little tour around code actions was the compilation > notifications. Again, we used a popper interface to show the error without > affecting the underlying text editor: > > [image: Inline image 2] > > You can find more details here: > > http://www.humane-assessment.com/blog/rethinking-compilation-notifications-… > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 4, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Henrik Johansen

On 03 Aug 2014, at 5:55 , ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Right, current hash is bad and long to compute. > > I think we should use instead > BasicIndexedEyeElement >> hash > ^ index hashMultiply > > host identityHash and index hash may lead to many collisions... > What do you think ? > I agree thereâs not much value in including host in the hash for the use case of the icon lookup cache, since those were per host anyways (iirc). Index hash will be a sequential number, I havenât checked the usage closely to see if itâll be a problem wrt. collisions, but removal at least might be slow (if thatâs ever done) due to lots of scanning needed to find the nil slot. Using hashMultiply seems a good precaution. Cheers, Henry

Aug. 4, 2014

WhatsUp from: 2014-08-04 until: 2014-08-17

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-08-17 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Aug. 4, 2014