- 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

Pharo 6 update catalog entries

by Torsten Bergmann

Hi, in preparation of upcoming Pharo 6 release we already should do a pass on all our external loadable projects: - load them into Pharo 6 to see if they could be loaded cleanly (due to automatic transformation of deprecated messages your packages get dirty when converted) - check if they are already/still working in Pharo 6 by using them - check that the tests are running in Pharo 6 - check that we have a proper config with catalog methods and that the latest config is in the MetaRepoForPharo60 repository http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60 I did a pass over most projects I implemented or contributed to and we now have much more Pharo 6 based projects in catalog: - Units, Artefact - EventRecorder, Bugzilla, PunQlite, HubCap, VistaCursors, INIFile - Pomodoro, DesktopManager, QuickAccess, WebBrowser, MessageFlowBrowser - ScriptManager (now with icons) - Tealight, Teapot, Nginx, NPMJS, GitHubAPI, FogBugz - OSWindows, OSOSX, OSUnix, OSLinuxCentOS, OSLinuxUbuntu, OSRaspbian - ... You should do the same with your projects! Also if you have a project on SqueakSource, STHub or GitHub that is not yet in the catalog it would be good to provide a ConfigurationOf... with a catalog description. Using Versionner it is easy to create one or generate the required catalog methods. This would give more visibility to your projects! Thanks T.

Jan. 31, 2017

Form/Spec based UI's in GT inspector extensions

by Torsten Bergmann

Hi, there are a lot of examples for GT inspector extensions in the image. I've seen #tree(s), #list(s) or #table like UI's are used. Even a #text or an "image" displaying a morph (using #form keyword sent to the given composite). It is very easy to provide extension methods to adopt the inspector to own needs and I wish people would use this more in our environment and according projects. But what I still miss is an easy way to extend the inspector with REAL FORMS (which are dialog like) to better display and manipulate attributes/ivars of an object. To give a few examples: ======================= When I inspect a color instance I would like to see (and change) the RGB values as well as the HEX representation in a form in an own tab. Similar as if I would be changing a color in a graphics program. I would like to lively manipulate the RGB values easily with sliders instead of sending messages to self in the "first" inspector code pane/tab. Or think of a Person class where you can provide an own custom inspector pane to display/change the name and first name in an edit field or select the date of birth in a datepicker together with a button to apply the new values to the object. Think of a database connection object where I can manipulate the ivar storing the connection string in an edit field but also provide a "Reconnect" in the button after I changed it. Currently we by default we have the "Raw" tab and need to manipulate the object state with expressions in the code pane. For me this is not interactive enough and Pharo has much potential to be a lively objects environment here. Long story short: ================= 1. Is there any support for such kind of dialog based UI's in the inspector tabs/composites. 2. Is there any support to use Spec based UIs to extend the GT inspector? 3. Is there support to build simple UI forms for the inspector with labels and edit fields, combo boxes, radio buttons, date fields, field set, buttons, ... like in [2]. 4. If we dont have such a beast yet I guess we should work into this direction because it would make Pharo not only a lively (for message sending) but very useful environment for direct object interaction/manipulation of states. Are there any plans/work on this already? If not what would be needed to achieve that? Maybe a GSOC project? Thanks T. [1] http://101.wacom.com/UserHelp/en/Images/Dialog_OSDSetColor.png [1] https://i.stack.imgur.com/X91VL.png

Jan. 31, 2017

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