- Pharo-dev - lists.pharo.org

pb with primitive #primitiveScreenDepth on Linux ?

by Christophe Demarey

Hello, With Pavel, we discovered a strange behavior of the primitive #primitiveScreenDepth on Linux. It returns a value of 24 bits per pixel (True colors) that looks valid but not supported (at least by Pharo). DisplayScreen actualScreenDepth "(calling the primitive screenDepth)" => 32 on OS X [OK] => 24 on Linux [KO] Also, it is not consistent with the primitive 91 DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth => true on OS X => false on Linux There are some safeguard image-side but it would be great if someone could check that vm side. Christophe.

Jan. 31, 2017

Re: [Pharo-dev] Memory leaks

by Thierry Goubier

Hi John, thanks for that tool. Have found a leak that I have been chasing like forever... I would vote to integrate that into the base image. Regards, Thierry 2017-01-31 5:00 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > On Jan 30, 2017, at 3:57 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > > > > The problem is still present. > > Looking at the pointers > > > > There was an object reference crawler no? I remember someone worked on > this? I tried sending #pointersTo but I without much success on identifying > the cause of this leak. > > > > Any idea? > > > > I donât know if there is an existing object reference crawler, but I > ported mine from VW. It finds the shortest paths so it is good for finding > the reference that is causing the memory leak. > > MCHttpRepository > location: 'http://www.smalltalkhub.com/ > mc/JohnBrant/ReferenceFinder/main' > user: '' > password: ââ > > Once loaded, you can evaluate something like "ReferenceFinder > findPathToInstanceOf: MyClassâ. That will return a reference path or nil > if no path exists from the Smalltalk global to an instance of MyClass. If > you want to find a path to a particular instance, you can use > âReferenceFinder findPathTo: myInstâ. > > In the past, Iâve found that NECController and some compiler > infrastructure (I forget the class) have been culprits for memory leaks > with their caches. > > > John Brant >

Jan. 31, 2017

Re: [Pharo-dev] Working with critiques in Calypso

by Denis Kudriashov

And here screenshots of Calypso with critiques: â â 2017-01-31 9:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-01-30 15:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> You will see new Calypso-Plugins-Critic-Browser package. I add decorators >> support to TextEditorTool. And critic plugin just adds CriticDecorator into >> required tools. >> Sadly it is not working. Critiques are not shown somehow. >> I leave it for you to fix it. Probably reason is that full tool morph is >> prepared in background. So critiques are added when morph is not in World. >> I hope you can find solution. >> > > And to get working critiques disable background tabs: > > ClyBrowserTabTool>>addInto: aBrowser > containerTab := TabMorph > label: self defaultTitle > icon: self defaultIcon > morph: self. > self build. > containerTab when: #tabDeleted send: #tabDeleted to: self. > containerTab model: self. > aBrowser addTab: containerTab > > So question why it is not working when morph is built from background > process? >

Jan. 31, 2017

Re: [Pharo-dev] Working with critiques in Calypso

by Denis Kudriashov

2017-01-30 15:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > You will see new Calypso-Plugins-Critic-Browser package. I add decorators > support to TextEditorTool. And critic plugin just adds CriticDecorator into > required tools. > Sadly it is not working. Critiques are not shown somehow. > I leave it for you to fix it. Probably reason is that full tool morph is > prepared in background. So critiques are added when morph is not in World. > I hope you can find solution. > And to get working critiques disable background tabs: ClyBrowserTabTool>>addInto: aBrowser containerTab := TabMorph label: self defaultTitle icon: self defaultIcon morph: self. self build. containerTab when: #tabDeleted send: #tabDeleted to: self. containerTab model: self. aBrowser addTab: containerTab So question why it is not working when morph is built from background process?

Jan. 31, 2017

Re: [Pharo-dev] Memory leaks

by John Brant

> On Jan 30, 2017, at 3:57 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > The problem is still present. > Looking at the pointers > > There was an object reference crawler no? I remember someone worked on this? I tried sending #pointersTo but I without much success on identifying the cause of this leak. > > Any idea? > I donât know if there is an existing object reference crawler, but I ported mine from VW. It finds the shortest paths so it is good for finding the reference that is causing the memory leak. MCHttpRepository location: 'http://www.smalltalkhub.com/mc/JohnBrant/ReferenceFinder/main' user: '' password: ââ Once loaded, you can evaluate something like "ReferenceFinder findPathToInstanceOf: MyClassâ. That will return a reference path or nil if no path exists from the Smalltalk global to an instance of MyClass. If you want to find a path to a particular instance, you can use âReferenceFinder findPathTo: myInstâ. In the past, Iâve found that NECController and some compiler infrastructure (I forget the class) have been culprits for memory leaks with their caches. John Brant

Jan. 31, 2017

Re: [Pharo-dev] cally changed from 3 to 5 ?

by Pepe Pepino

Ã GP HP en full full full y Ruff Ãºltima RIP de de clash Royale El ene. 30, 2017 8:11 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> escribiÃ³: > > > 2017-01-30 15:23 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Hi Nicolai, >> >> I'm checking all current issues marked for Pharo 6 and testing if they >> are new or the problem already existed in Pharo 5. According to it I'm >> marking it and for most cases (but not all) I'm decreasing the priority to >> "Fix if Time". >> I understand you but look at the priorities as priorities for the >> releasing process. Of course a lot such issues should be fixed and if you >> think they must be fixed for the upcoming release, increase the priority. >> Currently the assignment of priorities is on issue reporters and they use >> different personal scales. This way we can unify that a little bit. >> >> After finishing of the marking I wanted to ask people to think again >> about priorities of the reported issues. But If we already made a release >> with some issue, it probably means it is not extremely important. >> > > I am not talking about "extremely important" issues. If it is an issue > that "must be fixed for this release", I would use the "show stopper" > priority. > Now if some uses used his time to report an issue, say one as priority > "fix if time" and another one "must fix", now we put all this issues to > "fix if time", don't you think we loose some valuable information ? > If this issues won't be fixed in this release (because we don't have > enough man power) we can always put them on "Later" instead of "Pharo 6.0" > For me, it makes a difference if some issues occure in some situations, > where we can maybe work around, and can be fixed "if time" or if an issues > is a bug > that must be fixed just because the functionality is just not working > anymore. > > >> >> This step needs to be done anyway or we will never finish the release. To >> do it now gives us more time to focus on really important things. We want >> every new release to be better that release before so it makes sense to >> firstly look at new problems we created. >> > > I don't get this point. Some issues were just introduced in the pharo 5.0. > So instead of seeing this issues as "must fix", we decrease the priority as > "fix if time", so we can focus on the issues we introduced in Pharo 6.0? > > > >> Cheers, >> -- Pavel >> >> >> 2017-01-30 14:07 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> For example: >>> 19457 >>> <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-…> >>> Scrolling Versionner configuration list is very slow >>> 18778 >>> <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> >>> FileList "View as" does not work >>> 19221 >>> <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search…> >>> Rub Find And Replace can not search for "?" >>> >>> For me, these are issues that "must fix" and not "Fix If Time". Most >>> issues are only >>> fixed "if someone has the time to do it" regardless how serious they are. >>> Fixed if time looks like , we can live without this as we did since the >>> last >>> release, but actually we are just used to accept some bugs and >>> regressions because >>> we know we are to small or to few develoeper to actually fix this issues. >>> I don't see any value in downgrading the priority - else we could just >>> discard any priority. >>> >>> >>> nicolai >>> >> >> >

Jan. 31, 2017

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

by Martin McClure

At Stef's request, I've opened case 19629 on this issue. On 01/27/2017 11:14 PM, Andres Valloud wrote: >> The 2007 update of 10967 is somewhat more helpful. It replaces the >> "sign" operation with one called "signum" which returns 1, -1, or NaN. >> It returns 1 for positive zero and positive infinity, and -1 for >> negative zero and negative infinity. If given a qNaN, it returns a qNaN. >> If given a signaling NaN, it returns a qNaN but notifies the application >> of an "invalid" situation. > > That's ISO 10967. However, IEEE-758-2008 specifies implementations > shall provide isSignMinus(x). This operation is true if and only if x > has negative sign, and applies to zeros and NaNs. > > IMO, values that operate according to IEEE-758-2008 should behave as > specified by IEEE-758-2008 by default. The ISO 10967 standard seems > more of a layer on top of things like IEEE-758-2008, because it's a > standard for language agnostic arithmetic. > > So, shouldn't #sign behave as in IEEE-758-2008? > > ^self isSignMinus ifTrue: [-1] ifFalse: [1] I think that defining #sign this way would add to the confusion. IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC 10967 do, so it makes sense to provide a #sign that conforms to those standards -- answering -1, 0, or 1. IEEE-754 does define an isSignMinus operation, answering true or false, so it makes sense to provide that operation in addition to the ones specified by the other standards. > > It looks like the real question is whether Float's methods are merely > renaming IEEE-758-2008 functionality (if yes, why rename at all and add > to the confusion?), ISO 10967 functionality, or are something else > entirely (e.g. Smalltalk provided behavior in the context of the > Smalltalk experience). First and foremost, Smalltalk. The ANSI Smalltalk numeric spec is based on 10967, but that standard lacks some operations found in IEEE-754. But those have different names anyway, so it's easy in this case to comply with *both* standards. Regards, -Martin

Jan. 31, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Stephan Eggermont

On 12/01/17 12:07, Denis Kudriashov wrote: > I glad release new version of Calypso: Nice! > * white toolbar (according to theme background color) That doesn't work well. Don't mix styles like this, that is confusing. Stephan

Jan. 31, 2017

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

by philippe.back＠highoctane.be

+100 Priority has nothing to do with the release per se. Phil Le 31 janv. 2017 00:11, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : > > > 2017-01-30 15:23 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Hi Nicolai, >> >> I'm checking all current issues marked for Pharo 6 and testing if they >> are new or the problem already existed in Pharo 5. According to it I'm >> marking it and for most cases (but not all) I'm decreasing the priority to >> "Fix if Time". >> I understand you but look at the priorities as priorities for the >> releasing process. Of course a lot such issues should be fixed and if you >> think they must be fixed for the upcoming release, increase the priority. >> Currently the assignment of priorities is on issue reporters and they use >> different personal scales. This way we can unify that a little bit. >> >> After finishing of the marking I wanted to ask people to think again >> about priorities of the reported issues. But If we already made a release >> with some issue, it probably means it is not extremely important. >> > > I am not talking about "extremely important" issues. If it is an issue > that "must be fixed for this release", I would use the "show stopper" > priority. > Now if some uses used his time to report an issue, say one as priority > "fix if time" and another one "must fix", now we put all this issues to > "fix if time", don't you think we loose some valuable information ? > If this issues won't be fixed in this release (because we don't have > enough man power) we can always put them on "Later" instead of "Pharo 6.0" > For me, it makes a difference if some issues occure in some situations, > where we can maybe work around, and can be fixed "if time" or if an issues > is a bug > that must be fixed just because the functionality is just not working > anymore. > > >> >> This step needs to be done anyway or we will never finish the release. To >> do it now gives us more time to focus on really important things. We want >> every new release to be better that release before so it makes sense to >> firstly look at new problems we created. >> > > I don't get this point. Some issues were just introduced in the pharo 5.0. > So instead of seeing this issues as "must fix", we decrease the priority as > "fix if time", so we can focus on the issues we introduced in Pharo 6.0? > > > >> Cheers, >> -- Pavel >> >> >> 2017-01-30 14:07 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> For example: >>> 19457 >>> <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-…> >>> Scrolling Versionner configuration list is very slow >>> 18778 >>> <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> >>> FileList "View as" does not work >>> 19221 >>> <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search…> >>> Rub Find And Replace can not search for "?" >>> >>> For me, these are issues that "must fix" and not "Fix If Time". Most >>> issues are only >>> fixed "if someone has the time to do it" regardless how serious they are. >>> Fixed if time looks like , we can live without this as we did since the >>> last >>> release, but actually we are just used to accept some bugs and >>> regressions because >>> we know we are to small or to few develoeper to actually fix this issues. >>> I don't see any value in downgrading the priority - else we could just >>> discard any priority. >>> >>> >>> nicolai >>> >> >> >

Jan. 30, 2017

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

by Nicolai Hess

2017-01-30 15:23 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi Nicolai, > > I'm checking all current issues marked for Pharo 6 and testing if they are > new or the problem already existed in Pharo 5. According to it I'm marking > it and for most cases (but not all) I'm decreasing the priority to "Fix if > Time". > I understand you but look at the priorities as priorities for the > releasing process. Of course a lot such issues should be fixed and if you > think they must be fixed for the upcoming release, increase the priority. > Currently the assignment of priorities is on issue reporters and they use > different personal scales. This way we can unify that a little bit. > > After finishing of the marking I wanted to ask people to think again about > priorities of the reported issues. But If we already made a release with > some issue, it probably means it is not extremely important. > I am not talking about "extremely important" issues. If it is an issue that "must be fixed for this release", I would use the "show stopper" priority. Now if some uses used his time to report an issue, say one as priority "fix if time" and another one "must fix", now we put all this issues to "fix if time", don't you think we loose some valuable information ? If this issues won't be fixed in this release (because we don't have enough man power) we can always put them on "Later" instead of "Pharo 6.0" For me, it makes a difference if some issues occure in some situations, where we can maybe work around, and can be fixed "if time" or if an issues is a bug that must be fixed just because the functionality is just not working anymore. > > This step needs to be done anyway or we will never finish the release. To > do it now gives us more time to focus on really important things. We want > every new release to be better that release before so it makes sense to > firstly look at new problems we created. > I don't get this point. Some issues were just introduced in the pharo 5.0. So instead of seeing this issues as "must fix", we decrease the priority as "fix if time", so we can focus on the issues we introduced in Pharo 6.0? > Cheers, > -- Pavel > > > 2017-01-30 14:07 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> For example: >> 19457 >> <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-…> >> Scrolling Versionner configuration list is very slow >> 18778 >> <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> >> FileList "View as" does not work >> 19221 >> <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search…> >> Rub Find And Replace can not search for "?" >> >> For me, these are issues that "must fix" and not "Fix If Time". Most >> issues are only >> fixed "if someone has the time to do it" regardless how serious they are. >> Fixed if time looks like , we can live without this as we did since the >> last >> release, but actually we are just used to accept some bugs and >> regressions because >> we know we are to small or to few develoeper to actually fix this issues. >> I don't see any value in downgrading the priority - else we could just >> discard any priority. >> >> >> nicolai >> > >

Jan. 30, 2017