- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] c79b3f: 60392

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: c79b3f4d5d0e0a00864b8f59cd2860cfb6b3a1f5 https://github.com/pharo-project/pharo-core/commit/c79b3f4d5d0e0a00864b8f59… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-15 (Wed, 15 Feb 2017) Changed paths: M BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/preload_package_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60391.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60392.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60391.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60392.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Clipboard.package/Clipboard.class/instance/accessing/clipboardText_.st M System-Clipboard.package/ExternalClipboard.class/instance/accessing/clipboardText_.st M System-Clipboard.package/UnixClipboard.class/instance/accessing/clipboardText_.st A Text-Core.package/Text.class/instance/converting/copyWithoutExternalReferences.st A Text-Core.package/TextAttribute.class/instance/testing/mayHaveExternalReferences.st A Text-Core.package/TextLink.class/instance/testing/mayHaveExternalReferences.st R Versionner-Tests-Core-Model.package/MBConfigurationInfoTest.class/instance/tests/testInitialization.st Log Message: ----------- 60392 19707 remove Object>>#name hack in the BaselineOfIDE https://pharo.fogbugz.com/f/cases/19707 19706 remove MBConfigurationInfoTest>>#testInitialization https://pharo.fogbugz.com/f/cases/19706 19704 [Memory leak] Clipboard can produce memory leaks https://pharo.fogbugz.com/f/cases/19704 http://files.pharo.org/image/60/60392.zip

Feb. 15, 2017

Re: [Pharo-dev] GLMAction and PharoShortcut

by Stephane Ducasse

It would be better for pharo 7 On Tue, Feb 14, 2017 at 10:13 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Thanks for the update. > Based on previous Steph post, should we move this bug ticket to Pharo7 > or keep it for Pharo6? > > Hilaire > > Le 13/02/2017 Ã 18:46, Andrei Chis a Ã©crit : > > Hi, > > > > Good catch. Indeed GLMAction>>#shortcutAsString should go to the keymap > object. > > > > Apart from the inconsistencies that you mention, there is in my view > > another one. For example, in the debugger in the context menu of the > > stack modifiers are displayed using special characters (at least on > > mac). In tooltips they are display using Shift, Meta, Ctrl, etc. > > Right now the logic for printing shortcuts that way is in > > ToggleMenuItemShortcut>>#owner:keyText: and it's a bit complicated to > > reuse. See GTSpotterCategoryTitleBrick>>#setShortcutBrickTextFor: for > > an example. > > > > Cheers, > > Andrei > > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 15, 2017

Re: [Pharo-dev] Pharo wiki

by Stephane Ducasse

May be dale remember the password because mariano don't and my keychain neither. On Tue, Feb 14, 2017 at 10:09 PM, stepharong <stepharong(a)free.fr> wrote: > Mariano should know the password I asked. > > Stef > > > Hi Stef, >> >> On 13 February 2017 at 01:17, stepharong <stepharong(a)free.fr> wrote: >> >>> remember that we have this >>> >>> http://pharo.gemtalksystems.com >>> >>> stef >>> >> >> But write access requires an account (according to >> http://pharo.gemtalksystems.com/book/Contribute/ContributeToPharoBook) >> I requested an account last year (10 May 2016 to pharo-dev) >> and didn't get a response. >> >> Cheers, >> Alistair >> >> >> >> On Sat, 11 Feb 2017 23:22:11 +0100, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> wrote: >>> >>> I try to use StackOverflow documentation to document some Pharo stuff. >>> Itâs >>> very limited, but it has all the collaborative stuff from StackOverflow, >>> so >>> somehow I believe there is less effort needed to manage permissions. >>> >>> Uko >>> >>> On 10 Feb 2017, at 21:14, philippe.back(a)highoctane.be >>> <philippe.back(a)gmail.com> wrote: >>> >>> I miss the Squeak wiki Pharo style. >>> >>> Phil >>> >>> Le 10 fÃ©vr. 2017 19:06, "Esteban A. Maringolo" <emaringolo(a)gmail.com> a >>> Ã©crit : >>> >>>> >>>> 2017-02-10 14:59 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>> > Mass adoption and hyper reduced friction to get people on board. >>>> > >>>> > For me: I have 10+ slack teams in my slack client and there is really >>>> no >>>> > point in having more clients on the desktop. >>>> >>>> +1 to this. This is key. >>>> >>>> Maybe what we're missing is a simple wiki to collect the shared >>>> knowledge, recipes, and other stuff. >>>> >>>> >>>> Esteban A. Maringolo >>>> >>> >> > > -- > Using Opera's mail client: http://www.opera.com/mail/ > >

Feb. 15, 2017

Re: [Pharo-dev] Pharo wiki

by stepharong

Mariano should know the password I asked. Stef > Hi Stef, > > On 13 February 2017 at 01:17, stepharong <stepharong(a)free.fr> wrote: >> remember that we have this >> >> http://pharo.gemtalksystems.com >> >> stef > > But write access requires an account (according to > http://pharo.gemtalksystems.com/book/Contribute/ContributeToPharoBook) > I requested an account last year (10 May 2016 to pharo-dev) > and didn't get a response. > > Cheers, > Alistair > > > >> On Sat, 11 Feb 2017 23:22:11 +0100, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >> I try to use StackOverflow documentation to document some Pharo stuff. >> Itâs >> very limited, but it has all the collaborative stuff from >> StackOverflow, so >> somehow I believe there is less effort needed to manage permissions. >> >> Uko >> >> On 10 Feb 2017, at 21:14, philippe.back(a)highoctane.be >> <philippe.back(a)gmail.com> wrote: >> >> I miss the Squeak wiki Pharo style. >> >> Phil >> >> Le 10 fÃ©vr. 2017 19:06, "Esteban A. Maringolo" <emaringolo(a)gmail.com> a >> Ã©crit : >>> >>> 2017-02-10 14:59 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>> > Mass adoption and hyper reduced friction to get people on board. >>> > >>> > For me: I have 10+ slack teams in my slack client and there is >>> really no >>> > point in having more clients on the desktop. >>> >>> +1 to this. This is key. >>> >>> Maybe what we're missing is a simple wiki to collect the shared >>> knowledge, recipes, and other stuff. >>> >>> >>> Esteban A. Maringolo > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 14, 2017

Code Completion in Pharo

by komarlu2＠fit.cvut.cz

Hello to all, I am a student at the Faculty of Information Technology of the Czech Technical University in Prague and I decided to make Code Completion in Pharo the topic ofÂ my Bachelor's degree and try to improve it. If you have suggestions on what should change / how to change it so you would be satisfied with it, I will appreciate any input on this topic. It would mean a lot to me if you could find two minutes and take this survey (there are only like 7 questions, so it won't take longer than those 2 minutes): https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwRsnA_AX_e_7sZEz2 XJQ4059nk_-LV6w/viewform Regards Lukas

Feb. 14, 2017

Re: [Pharo-dev] [QA] Scoped

by Hilaire

Thanks Ben. I think Marcus made a slide already. Hilaire Le 14/02/2017 Ã 11:45, Ben Coman a Ã©crit : > Maybe... > Browse selected package in a context that limits the scope of analysis tools > (e.g. 'Senders of...', 'Implementors of...', 'Class refs...') > > cheers -ben -- Dr. Geo http://drgeo.eu

Feb. 14, 2017

Re: [Pharo-dev] Points, Free type fonts cache and memory leaks

by Ben Coman

On Tue, Feb 14, 2017 at 9:54 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > It is very common to see in actively used images that the number of > instances of Point is very high. Sometimes in order of hundreds of > thousands. There is several reasons for that: > > Pharo every few milliseconds checks for the new display size. That check > generates two instances of Point that are not garbage collected in > reasonably short time. So if you periodically check the result of "Point > allInstances size", you will see that it is quickly growing. > On the other hand. That Point instances are not referenced by anyone so as > soon as you do Smalltalk garbageCollect, the amount of Points in reduced. > And they are correctly garbage collected by the VM after some time which is > often longer than one minute. So no action needed. Even though these get cleared out, its still extra work for the GC. Presumably most of the time the display size is identical to the last one, so I wonder if the existing screen size might be passed to the primitive to test and avoid creating a new new point if its the same. Off the top of my head, something like this (untested)... MorphicUIManager >> checkForNewDisplaySize Display hasScreenSizeChanged ifFalse: [^ Display]. DisplayScreen startUp. World restoreMorphicDisplay. DisplayScreen >> hasScreenSizeChanged ^self class isActualScreenSizeX: width Y: height. DisplayScreen class >> isActualScreenSizeX: width Y: height <primitive: 106> InterpreterPrimitives >> primitiveScreenSize "primitive 106" "no arguments(original) ==> DisplayScreen_class>>actualScreenSize ; returning new Point from ioScreenSIze " "two arguments ==> DisplayScreen_class>>isActualyScreenSizeX;Y: ; returning Boolean of whether X,Y match ioScreenSize" | pointWord x y| pointWord := self ioScreenSize. x := pointWord >> 16 bitAnd: 65535. y := pointWord bitAnd: 65535. argumentCount = 2 ifTrue: [ ((x = (self stackValue: 1)) and: [y = (self stackTop)]) ifTrue: [self pop: 3 thenPush: objectMemory trueObject] ifFalse: [self pop: 3 thenPush: objectMemory trueObject]. ]. self pop: 1 thenPush: (self makePointwithxValue: x yValue: y) <snipped other sources of Points> cheers -ben

Feb. 14, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 14, 2017

[pharo-project/pharo-core] 08e7f4: 60391

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 08e7f4885ef882dcf23fd30632eb8c89ffa0c1ca https://github.com/pharo-project/pharo-core/commit/08e7f4885ef882dcf23fd306… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-14 (Tue, 14 Feb 2017) Changed paths: A Deprecated60.package/ShortRunArray.class/README.md A Deprecated60.package/ShortRunArray.class/definition.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60390.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60391.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60390.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60391.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60391 19703 add empty ShortRunArray to Deprecated60 https://pharo.fogbugz.com/f/cases/19703 http://files.pharo.org/image/60/60391.zip

Feb. 14, 2017

Re: [Pharo-dev] Points, Free type fonts cache and memory leaks

by Pavel Krivanek

2017-02-14 15:38 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 14 Feb 2017, at 14:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > Hi, > > > > It is very common to see in actively used images that the number of > instances of Point is very high. Sometimes in order of hundreds of > thousands. There is several reasons for that: > > > > Pharo every few milliseconds checks for the new display size. That check > generates two instances of Point that are not garbage collected in > reasonably short time. So if you periodically check the result of "Point > allInstances size", you will see that it is quickly growing. > > On the other hand. That Point instances are not referenced by anyone so > as soon as you do Smalltalk garbageCollect, the amount of Points in > reduced. And they are correctly garbage collected by the VM after some time > which is often longer than one minute. So no action needed. > > > > Then a lot of Points is stored in FreeTypeCache. That cache is a huge > beast and it tries to store a small form for every new rendered character > glyph. That means for every font, every pixel size etc. It sounds > reasonable but the main reason why the cache can be very huge is in the > fact that it stores a new glyph for every sub-pixel variant too! > > Every FreeTypeChacheEntry also contains several Point instances so it is > a important source of them. Fortunately, this cache has mechanisms to limit > its size. This limit now set to expected size of 5MB, see FreeTypeChache>># > defaultMaximumSize. > > So in the end, probably no immediate fix is needed although this cache > deserves revision. > > IMO, the full FT implementation needs to be revisited, both in image side > and in vm sideâ¦ but this is no easy work, soâ¦ for when âthere is timeââ¦ > likely never ;) > > > > > And then we have a Text related memory leak that I will try to > investigate. This memory leak does not let to garbage collect any tool > window as soon as clipboard or history (undo) was used in it. > > keep pushing! :) > (I remember there was a problem with the find&replace dialog that was a > singleton and it was keeping strong references to the (rubric) editors that > called itâ¦ maybe the leak is someplace around... > https://pharo.fogbugz.com/f/cases/19704/Memory-leak-Clipboard-can-produce-m… And I have seen very similar memory leaks related to GLMHintableActionButtonBrick, undo managers a NECController. Maybe they are related but I need to find a way how to reproduce them. -- Pavel > > Esteban > > > > > Cheers, > > -- Pavel > > > > > > > > > > > > > > > > > > >

Feb. 14, 2017