August 2014 - Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core] 9e4196: 40149

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 9e4196c43074f26c045b8f8051b45269fd819db6 https://github.com/pharo-project/pharo-core/commit/9e4196c43074f26c045b8f80… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-03 (Sun, 03 Aug 2014) Changed paths: M Nautilus.package/AbstractNautilusUI.class/class/menu/classesMenu_.st M Nautilus.package/AbstractNautilusUI.class/class/shortcuts/buildRecategorizeShortcutsOn_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/selectedClass_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/selectedPackageWithoutChangingSelectionInternally_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/selectedPackageWithoutChangingSelection_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/showGroups_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/showInstance_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/showPackages_.st M Nautilus.package/AbstractNautilusUI.class/instance/drag and drop/dropInAPackage_into_.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenRemoved_.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/findClass_.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/findPackage.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/forceGenerateInitialize.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/generateInitialize.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/mergeGroups.st R Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/moveInNewPackage.st A Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/moveInPackage.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/removeEmptyCategories.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/renameGroup.st M Nautilus.package/AbstractNautilusUI.class/instance/plugins announcements/browseClass_.st R Nautilus.package/AbstractNautilusUI.class/instance/private/updateBothView.st A Nautilus.package/AbstractNautilusUI.class/instance/private/updatePackageGroupAndClassList.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/compileAClassFrom_notifying_.st R Nautilus.package/AbstractNautilusUI.class/instance/source code area/okToChangeBoth.st A Nautilus.package/AbstractNautilusUI.class/instance/source code area/okToChangeSourceAndComment.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/classRecategorized_.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/classRemoved_.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/classReorganized_.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/testRunned_.st M Nautilus.package/AbstractNautilusUI.class/instance/test creation/createTestForClass_.st R Nautilus.package/AbstractNautilusUI.class/instance/updating/update.st M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelectionInternally_.st M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/addCategory.st M Nautilus.package/NautilusUI.class/instance/menus behavior/categorizeMethod.st M Nautilus.package/NautilusUI.class/instance/menus behavior/findAllMethod.st M Nautilus.package/NautilusUI.class/instance/menus behavior/findMethod.st M Nautilus.package/NautilusUI.class/instance/menus behavior/findProtocol.st M Nautilus.package/NautilusUI.class/instance/menus behavior/generateTestMethodsAndFocus_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/implementSelector_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/moveMethodToPackage.st M Nautilus.package/NautilusUI.class/instance/menus behavior/removeCategories.st M Nautilus.package/NautilusUI.class/instance/menus behavior/removeMethod_inClass_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/renameCategory.st M Nautilus.package/NautilusUI.class/instance/private/selectedClass_withSelection_.st M Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st M Nautilus.package/NautilusUI.class/instance/source code area/compileAMethodFromCategory_withSource_notifying_.st M Nautilus.package/NautilusUI.class/instance/system announcements/methodAdded_.st M Nautilus.package/NautilusUI.class/instance/system announcements/methodModified_.st M Nautilus.package/NautilusUI.class/instance/system announcements/methodRecategorized_.st M Nautilus.package/NautilusUI.class/instance/system announcements/methodRemoved_.st R Nautilus.package/NautilusUI.class/instance/updating/update.st A Nautilus.package/NautilusUI.class/instance/updating/updateCategoryAndMethodList.st M Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selectedPackageWithoutChangingSelection_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/showPackages_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private/basicShowHierarchy.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/updateBothView.st A Nautilus.package/PackageTreeNautilusUI.class/instance/private/updatePackageGroupAndClassList.st M NautilusCommon.package/NautilusBreadcrumbsPlugin.class/instance/announcement/protocolSelected_.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/protocol/applyTo_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script149.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40149.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Tool-Base.package/AbstractTool.class/instance/class/moveInNewPackage_.st R Tool-Base.package/AbstractTool.class/instance/method/moveMethodsToPackage_in_from_.st Log Message: ----------- 40149 13758 use better package selector for (class/methods) move to https://pharo.fogbugz.com/f/cases/13758 13765 Nautilus Refactoring 6: rename methods and fix hierarchy view https://pharo.fogbugz.com/f/cases/13765 http://files.pharo.org/image/40/40149.zip

Aug. 3, 2014

Re: [Pharo-dev] Pharo image corruption and fatal VM error with Roassal

by volkert＠nivoba.de

... and on Debian 14.04 x64. BW, Volkert Am 02.08.2014 um 02:09 schrieb volkert(a)nivoba.de: > I had the same problem today on W8.1 x64 :-( > > BW, > Volkert > > > Am 31.07.2014 um 10:50 schrieb Blondeau Vincent: >> >> Hi, >> >> Yesterday, I was using GraphET (a part of Roassal) to do some charts >> and, today, when I wanted to reopen the image. >> >> And I got that : >> >> It is **very** unpleasantâ¦ >> >> To reproduce the bug: >> >> 1 - You can do either: >> >> | builder | >> >> builder := GET2Line data: (0 to: 100) . >> >> builder >> >> y: [ :x | x*x ]. >> >> builder open. >> >> Or >> >> WorldMenu -> Roassal examples -> choose an item -> click on a graph . >> A TRMorph should be opened. >> >> 2 - donât close the graph and save the pharo image. >> >> 3 â Close the pharo image >> >> 4 - Reopen it >> >> I am under W7 x64 with the latest moose image and the VM available on >> the pharo.org website >> (http://files.pharo.org/platform/Pharo3.0-win.zip) from the 10 july. >> >> You will find the crash dump attached. >> >> Thankfully, I managed to open the image with a latest VM >> (http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) >> >> >> Thanks a lot Eliot ! :) >> >> And I got this: >> >> Thanks in advance >> >> Cheers, >> >> Vincent BLONDEAU >> >> >> ------------------------------------------------------------------------ >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã >> l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© >> par le secret professionnel. Si vous recevez ce message par erreur, >> merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. >> L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la >> responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au >> contenu de ce message. Bien que les meilleurs efforts soient faits >> pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur >> ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait >> Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive >> this e-mail in error, please notify the sender immediately and >> destroy it. As its integrity cannot be secured on the Internet, the >> Worldline liability cannot be triggered for the message content. >> Although the sender endeavours to maintain a computer virus-free >> network, the sender does not warrant that this transmission is >> virus-free and will not be liable for any damages resulting from any >> virus transmitted. > > -- > www.nivoba.de > > "The more complex an object, the larger the investment in learning to use it, and the greater the resistance to abandon it.", NW -- www.nivoba.de "The more complex an object, the larger the investment in learning to use it, and the greater the resistance to abandon it.", NW

Aug. 3, 2014

Re: [Pharo-dev] where the...

by Tudor Girba

Thanks, Marcus. Doru On Sat, Aug 2, 2014 at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 01 Aug 2014, at 20:50, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > > 2014-08-01 18:23 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> >> On Thu, Jul 31, 2014 at 11:52 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> Eliot Miranda wrote: >>> >>> >>> >>> >>> On Thu, Jul 31, 2014 at 9:48 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> I can tell you that I do not like jenkins but we have it, it works and >>>> it is maintained. So I lobotomize myself when I use it and it looks ok :) >>>> >>> >>> I like it very much. But there's a lot of freedom to design the >>> server and make it easier to find results, etc. For example at Cadence Bob >>> Westergaard has put a lot of effort into our Jenkins server with tabs >>> grouping different build tasks by VM, Newspeak, Spur, etc. So I find it >>> easier to navigate than the Pharo one. In particular it would be great if >>> thee were pointers to the latest build artifacts on >>> https://ci.inria.fr/pharo/job/Pharo-4.0/. Is that possible? >>> >>> >>> I think the philosophy was to avoid the CI server also being a file >>> sever - but perhaps the job result could provide a link to the associated >>> uploaded http://files.pharo.org/image/40/xxxxx.zip >>> >> >> Ok, if one should go to files.pharo.org then there should be as many >> links to files.pharo.org in obvious places as possible. But if I, as an >> outside, think to myself "nbow where would I find the most recent build of >> Pharo 4?", I would go to the CI server. >> >> For me, philosophically, a CI server /is/ a server, of build artifacts, >> test results and benchmarks. >> >> > I keep that link in my bookmarks to download the latest Pharo 4: > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-4-Publish/ > > However, to avoid the server to be overloaded (because there are many > people downloading Pharo every day), it is better to use files.pharo.org . > > > We should add links to the CI server page. I put it on my TODO. (to be > done *after* Holidays and ESUG). > > Marcus > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 3, 2014

Re: [Pharo-dev] Loading Zinc

by Sven Van Caekenberghe

Hi Sebastian, On 02 Aug 2014, at 15:53, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi Sven, > > how are you doing? I am fine, I hope you guys recovered from the football world cup hype ;-) > Firstly let me ask you how should I load Zinc. > > Iâm doing it like this: > > > Gofer it > url: 'http://mc.stfx.eu/ZincHTTPComponents'; > package: 'ConfigurationOfZincHTTPComponents'; > load. > > (Smalltalk at:#ConfigurationOfZincHTTPComponents) project latestVersion load: 'WebSocket'. > (Smalltalk at:#ConfigurationOfZincHTTPComponents) project latestVersion load: 'SSO'. > > Gofer it > url: 'http://mc.stfx.eu/Zodiac'; > package: 'Zodiac-Core'; > package: 'Zodiac-Tests'; > load. > > > Is that the right source/way? It is up to you to decide which version you want to load. Both Zinc & Zodiac are part of the base image, so for most users it is not necessary to load a newer version. But you want more, I guess. I maintain two versions #stable and #bleedingEdge (as you can also see from the CI job: https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/) What I normally do in my images is loading #bleedingEdge over what is already there. So that would be Gofer it url: 'http://mc.stfx.eu/ZincHTTPComponents'; configurationOf: #ZincHTTPComponents; loadVersion: #bleedingEdge. Note that for 4.0 you need to proceed two warning about removed classes. There is no separate configuration for Zodiac, it is part of Zinc's. When doing a #bleedingEdge load, you get those updates automatically (I think because these are present already and because only the baseline is used), else you need to load the 'Zinc' group too. Next you want to load two specific groups #('SSO' 'WebSocket') do: [ :each | #ConfigurationOfZincHTTPComponents asClass project bleedingEdge load: each ]. Now, there was an error in Zinc-WebSocket-Core-SvenVanCaekenberghe.27 with respect to the superclass of ZnWebSocketLogEvent - although it was OK in my image with no dirty package. I committed a new version, Zinc-WebSocket-Core-SvenVanCaekenberghe.28. Please try again. Thanks for the feedback ! HTH, Sven > Secondly, Iâm experiencing this in the latest version: > > > <Screen Shot 2014-08-02 at 10.50.00 AM.png> > > Whatâs the package that has the missin ZnWebSocketControlFrameHandledEvent? > > thanks! > > sebastian > > o/ > > blog: http://sebastianconcept.com > LinkedIn: http://www.linkedin.com/in/sebastiansastre > github: https://github.com/sebastianconcept > > > > >

Aug. 2, 2014