- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Two listener sockets on same port

by Denis Kudriashov

2017-01-31 11:56 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > IIRC, behaviour is different on all three platforms: > - Linux raises error > I got same behaviour on Debian as on Mac. It assigns different port

Jan. 31, 2017

Re: [Pharo-dev] Two listener sockets on same port

by Sven Van Caekenberghe

> On 31 Jan 2017, at 11:56, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 30 Jan 2017, at 21:13 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> >> 2017-01-30 20:25 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Well, you should do your utmost best to prevent the situation in the first place (use startup/shutdown behaviour correctly). >> >> I remember I had those problems a lot in the beginning of Zn, especially when running tests that sometimes failed. >> >> Have you seen Zn's #isListening ? I think that was written to catch the case you described, but I am not sure it is 100% rock solid. >> >> Yes. This is exactly how I fix my case. >> But this post is about general problem which I think is very critical. >> >> In #isListening code I see extra condition "self serverSocket localPort = self port". Could you explain what case it is covered? >> > > Doesn't work on Windows; > https://pharo.fogbugz.com/f/cases/16939/Intermittent-monkey-failures-due-to… > > IIRC, behaviour is different on all three platforms: > - Linux raises error > - Mac assigns different port than requested > - Win assigns requested port, but receives no traffic. This is the curse of being x-platform, we don't see them often (luckily) but there are important (semantic) differences that sometimes make life (very) difficult. > How to detect the last one from image is a very good question (tm) indeed... > > Cheers, > Henry

Jan. 31, 2017

Re: [Pharo-dev] Two listener sockets on same port

by Henrik Johansen

> On 30 Jan 2017, at 21:13 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-01-30 20:25 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > Well, you should do your utmost best to prevent the situation in the first place (use startup/shutdown behaviour correctly). > > I remember I had those problems a lot in the beginning of Zn, especially when running tests that sometimes failed. > > Have you seen Zn's #isListening ? I think that was written to catch the case you described, but I am not sure it is 100% rock solid. > > Yes. This is exactly how I fix my case. > But this post is about general problem which I think is very critical. > > In #isListening code I see extra condition "self serverSocket localPort = self port". Could you explain what case it is covered? > Doesn't work on Windows; https://pharo.fogbugz.com/f/cases/16939/Intermittent-monkey-failures-due-to… <https://pharo.fogbugz.com/f/cases/16939/Intermittent-monkey-failures-due-to…> IIRC, behaviour is different on all three platforms: - Linux raises error - Mac assigns different port than requested - Win assigns requested port, but receives no traffic. How to detect the last one from image is a very good question (tm) indeed... Cheers, Henry

Jan. 31, 2017

Re: [Pharo-dev] Form/Spec based UI's in GT inspector extensions

by Tudor Girba

Hi, Indeed, this is a nice observation. We currently have basic support for handling forms: - GLMSpecPresentation offers a basic integration of Spec widgets inside Glamour. This ships with the Pharo image. - GLMMagrittePresentation allows us to take a Magritte-described object and render it through a form. But, it would definitely be worthwhile to have more elaborate possibilities. Cheers, Doru > On Jan 31, 2017, at 10:16 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > 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 > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Jan. 31, 2017

Re: [Pharo-dev] Memory leaks

by Pavel Krivanek

Very nice tool. I think it cannot find objects pointed only by a stack of some processes so it may be handy to put them to the global space. Smalltalk globals at: #Stacks put: ((Process allInstances collect: [:p | (p suspendedContext) ifNotNil: #stack ]) reject: #isNil) asOrderedCollection. (Smalltalk globals at: #Stacks) add: thisContext stack. -- Pavel 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

[pharo-project/pharo-core]

by GitHub

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

Jan. 31, 2017

[pharo-project/pharo-core] a1d73b: 60365

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: a1d73b1704d27971ef636f12e05f999c6ef7eb78 https://github.com/pharo-project/pharo-core/commit/a1d73b1704d27971ef636f12… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: M Deprecated60.package/extension/Collection/instance/ifEmpty_ifNotEmptyDo_.st M Kernel-Tests.package/ClassHierarchyTest.class/instance/tests/testSubclasses.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60364.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60365.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60364.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60365.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Catalog.package/CatalogBrowser.class/class/utilities/iconFor_.st Log Message: ----------- 60365 19624 Wrong deprecated message in ifEmpty:ifNotEmptyDo: https://pharo.fogbugz.com/f/cases/19624 19625 Catalog: loaded config should not be displayed with white icon https://pharo.fogbugz.com/f/cases/19625 19129 Deprecation: The method Object>>name called from ClassHierarchyTest>>#testSubclasses has been deprecated. https://pharo.fogbugz.com/f/cases/19129 http://files.pharo.org/image/60/60365.zip

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

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