- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] rethinking compilation notifications

by Guillermo Polito

Just <3 Le 3 aoÃ»t 2014 22:09, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > 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] rethinking compilation notifications

by Yuriy Tymchuk

Yes, we need this really a lot. Thanks Uko On 03 Aug 2014, at 22:09, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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: > > <Screen Shot 2014-08-03 at 9.22.59 AM.png> > > 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. 3, 2014

rethinking compilation notifications

by Tudor Girba

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. 3, 2014

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

by Nicolai Hess

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>: > 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. 3, 2014

About https://pharo.fogbugz.com/f/cases/2489

by stepharo

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. 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40150 Home: https://github.com/pharo-project/pharo-core

Aug. 3, 2014

[pharo-project/pharo-core] 2a7e47: 40150

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 2a7e47f659ae035ca9d52433cab13efe82e9f228 https://github.com/pharo-project/pharo-core/commit/2a7e47f659ae035ca9d52433… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-03 (Sun, 03 Aug 2014) Changed paths: M Graphics-Tests.package/RectangleTest.class/instance/tests/testInsettingByRectangleShouldNotProduceNegativeRectangle.st A Graphics-Tests.package/RectangleTest.class/instance/tests/testPointPointConstructorIsSymmetrical.st M Graphics-Tests.package/RectangleTest.class/instance/tests/testRectangleWithNegativeExtentShouldHaveZeroExtent.st A Graphics-Tests.package/RectangleTest.class/instance/tests/testSettingLeftDoesNotProduceInvalidRectangle.st M Kernel.package/Point.class/instance/converting/rectangle_.st M Kernel.package/Rectangle.class/class/instance creation/left_right_top_bottom_.st M Kernel.package/Rectangle.class/class/instance creation/origin_corner_.st M Kernel.package/Rectangle.class/class/instance creation/origin_extent_.st A Kernel.package/Rectangle.class/class/instance creation/point_point_.st A Kernel.package/Rectangle.class/instance/private/setLeft_right_top_bottom_.st M Kernel.package/Rectangle.class/instance/private/setOrigin_corner_.st A Kernel.package/Rectangle.class/instance/private/setPoint_point_.st M Morphic-Base.package/LayoutFrame.class/instance/transforming/transform_.st M Morphic-Core.package/Morph.class/instance/layout/adjustLayoutBounds.st M Morphic-Widgets-Tree.package/MorphTreeNodeMorph.class/instance/layout/layoutBounds.st A MorphicTests.package/LayoutFrameTest.class/instance/tests/testTransform.st A MorphicTests.package/LayoutFrameTest.class/instance/tests/testTransformReturnASubArea.st A MorphicTests.package/LayoutFrameTest.class/instance/tests/testTransformReturnEmptyRectangleWhenNotPossibleToPlace.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script150.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40150.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40150 2489 Strange behavior of Rectangle https://pharo.fogbugz.com/f/cases/2489 http://files.pharo.org/image/40/40150.zip

Aug. 3, 2014

Re: [Pharo-dev] Strange behavior of blocks

by ClÃ©ment Bera

2014-08-01 16:11 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 01 Aug 2014, at 3:20 , Serge Stinckwich <serge.stinckwich(a)gmail.com> > wrote: > > Dear all, > > using Sci-Smalltalk, we found with Natalia that sometimes blocks have > strange behavior : > https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ > > I was able to create a more simpler example using only Pharo. > If you try, the following expression, there is no problem: > > |state values | > values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 10000) do:[:i | (values at:i) at:2]. > > and you do more iterations, an error appears (Instances of > SmallInteger are not indexable), > because from time to time, an array is replaced by an integer: > > |state values | > values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > and if you move the state variable inside the block, it works again : > > | values | > values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > Same problem in Pharo 3.0 or Pharo 4.0 > > Regards, > > > Speaking of which, when trying to inspect the array, itâs incredibly slowâ¦ > The main reason for this? > BasicIndexedEyeElement >> hash > ^*super* hash bitXor: index hash > > The super implementation? > AbstractEyeElement >> hash > ^host hash > > Guess what the host of an indexedEyeElement is? Thatâs right, the > collectionâ¦ > So every time it tries to find the cached icon of a line (which is, 10-20 > times per refresh cycle depending on the view), it iterates through the > 100000 element array to calculate its hashâ¦ > > Iâd recommend either removing the super call from BasicIndexedEyeElement, > or tell the AbstractEyeElement to use the identityHash of its host instead. > 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 ? > > Bonus: It also invokes a #DNU hander every time, since > DictionaryValueHolder >> at:ifAbsentPut: is implemented > *self* at: key ifAbsent: []. > instead of > *value* at: key ifAbsent: []. > > Your code looks obviously better. I'm making a slice for that. > Code quality progress. Yay. > Thanks for your contribution. Clement. > > Cheers, > Henry >

Aug. 3, 2014

Re: [Pharo-dev] fresh image with dirty packages

by ClÃ©ment Bera

2014-08-02 10:18 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 02 Aug 2014, at 08:54, stepharo <stepharo(a)free.fr> wrote: > > > Yes I saw that too when we worked with Damien yesterday. > > May the last integration of clement was shaking some extensions and we > get from time to time > > dirty packages that are not dirty in fact. It never occurred to me or > marcus fixed them. > > > > I think it is a side effect of the ârecompile classâ fix that now forced > the trains to be re-installed. > This seems to emit notifications that it should not. > I added a OpalCompiler recompileAll as a postLoadDoIt in the last integration. I think this is what makes some packages dirty. This is because we recently patched recompileAll because it was not recompiling some methods in Traits. > > > Stef > > > > > >> Loading and starting a fresh image > >> (Pharo 40148) shows some dirty package in monticello. > >> (KernelTests, CollectionsTests, ...) > >> Comparing those packages with pharo40inbox shows no > >> changes except for > >> NativeBoost-Core > >> Athens-Cairo > >> and AST-Core > >> > >> what happened? > > > > > > >

Aug. 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40149 Home: https://github.com/pharo-project/pharo-core

Aug. 3, 2014