October 2013 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Oct. 7, 2013

[pharo-project/pharo-core] 4d1eb6: 30459

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 4d1eb6e81adf0b69c289e1a3e97bc1d11d7fc2cd https://github.com/pharo-project/pharo-core/commit/4d1eb6e81adf0b69c289e1a3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-07 (Mon, 07 Oct 2013) Changed paths: A FuelTools-Debugger.package/FuelOutStackDebugAction.class/README.md A FuelTools-Debugger.package/FuelOutStackDebugAction.class/class/private/encodeDebugInformationOn_.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/class/registration/actionType.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/class/serialization/serializeTestFailureContext_toFileNamed_.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/definition.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/instance/accessing/defaultLabel.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/instance/accessing/defaultOrder.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/instance/accessing/id.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/instance/actions/executeAction.st A FuelTools-Debugger.package/FuelOutStackDebugAction.class/instance/actions/serializeStack.st R FuelTools-Debugger.package/extension/DebugSession/class/encodeDebugInformationOn_.st R FuelTools-Debugger.package/extension/DebugSession/class/serializeTestFailureContext_toFileNamed_.st R FuelTools-Debugger.package/extension/DebugSession/instance/serializeStack.st R FuelTools-Debugger.package/extension/SpecDebugger/class/menuFuelStackAction_.st M HudsonBuildTools20.package/HDTestReport.class/instance/running/serializeError_of_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script114.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30459.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/WorldModel.class/class/specs/defaultSpec.st Log Message: ----------- 30459 11807 openWorldWithSpec does not work https://pharo.fogbugz.com/f/cases/11807 11741 Add Fuel out Stack as an action to the new debugger https://pharo.fogbugz.com/f/cases/11741

Oct. 7, 2013

[update 3.0] #30459

by Marcus Denker

30459 ----- 11807 openWorldWithSpec does not work https://pharo.fogbugz.com/f/cases/11807 11741 Add Fuel out Stack as an action to the new debugger https://pharo.fogbugz.com/f/cases/11741 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FuelTools-Debugger-MarcusDenk…

Oct. 7, 2013

Re: [Pharo-dev] External Semaphores leaking in Socket

by Henrik Johansen

On Oct 6, 2013, at 12:51 , Norbert Hartl <norbert(a)hartl.name> wrote: > I took some time to analyze my current problem with external semaphores. I was just reluctant to raise the limit in my image because I want the problem solved. I logged the management of external semaphores and discovered that the table fills if a connection times out. > > The problem turns out to be in > > Socket>>#connectTo: hostAddress port: port waitForConnectionFor: timeout > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] > > When a socket is created three external semaphores are registered in the ExternalSemaphoreTable. If a connection times out the exception is thrown but the Socket still has his resources attached. > > So e.g. in > > SocketStream class>>#openConnectionToHost: hostIP port: portNumber timeout: timeout > | socket | > socket := Socket new. > socket connectTo: hostIP port: portNumber waitForConnectionFor: timeout. > ^self on: socket > > it holds locally a socket (with semaphores registered) but on exception time the reference to the socket gets lost and the semaphores stay registered. The only way to unregister is on finalization time but I think it should work better. So I would add a destroy before the exception is raised. > > Socket>>#connectTo: hostAddress port: port waitForConnectionFor: timeout > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ > self destroy. > ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] > > I opened a ticket at https://pharo.fogbugz.com/f/cases/11797 but I'm not sure how I am supposed to provide fixes made against a pharo2.0 image. Probably I should fix this againt 3.0 but then I'm still a 2.0 user :) > > Norbert Destroying the socket manually there would only be an optimization, right? It's still cleaned eventually by a finalization action? Finalization all of a sudden stopping to work is an unlikely culprit of running out of external object space, load above what the size can handle, or actual leak(s) are much more probable. Thankfully, there are a limited number of places leaks could occur, for Socket you have improper uses of acceptFrom:/initialize: (multiple sends to the same socket). In a stock image, there's an obscure way that might occur afaict, if class methods acceptFrom:/newXXX are called, and the primitive calls in the new instance's acceptFrom:/initialize: returns a handle with status InvalidSocket instead of nil. Then, the external objects will not be unregistered before repeatWithGCIf: clears them by calling them again. (No idea if this can ever really happen though...) To flush out if such leaks are the cause, it might be useful to adjust initialize:/acceptFrom: with helpful logging/errors, as per https://pharo.fogbugz.com/f/cases/5465/Prevent-accidental-semaphore-leaks-w… There's a few other users of registerExternalObject:, - InputEventFetcher >> #startUp (Used to leak when saving but not quitting due to missing symmetric unregister in #shutDown, should be fixed in 2.0 ) - AsynchFile (none uses this anyways right, so didn't bother checking) - NetNameResolver >> initializeNetwork - (This potentially leaked if network could ever be in an uninitialized state 2x in a session, but should be fixed in 2.0) As long as both the above are fixed in your image, checking if there are non-stock users of registerExternalObject:/initialize:/acceptFrom: is probably the best bet to find trouble spots without waiting for another crash. Cheers, Henry

Oct. 7, 2013

Re: [Pharo-dev] Pharo shower?

by Damien Cassou

On Mon, Oct 7, 2013 at 1:37 PM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > Is there some Pharo smalltalk in this shower head or is it a blatant breach > of the Pharo trademark name? :) they should at least put the logo :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 7, 2013

Pharo shower?

by Geert Claes

Is there some Pharo smalltalk in this shower head or is it a blatant breach of the Pharo trademark name? :) http://www.hansgrohe-int.com/articledetail-null-pharo-shower-panel-lift-2-m… -- View this message in context: http://forum.world.st/Pharo-shower-tp4712968.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 7, 2013

[pharo-project/pharo-core]

by GitHub

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

Oct. 7, 2013

[pharo-project/pharo-core] 7be819: 30458

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 7be8196509a0865dfcbfd7e6ef464fcccbcee2a0 https://github.com/pharo-project/pharo-core/commit/7be8196509a0865dfcbfd7e6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-07 (Mon, 07 Oct 2013) Changed paths: M DebuggerActions.package/DoesNotUnderstandDebugAction.class/instance/actions/executeAction.st A DebuggerActions.package/DoesNotUnderstandDebugAction.class/instance/private/askForCategoryIn_default_.st A DebuggerActions.package/DoesNotUnderstandDebugAction.class/instance/private/askForSuperclassOf_toImplement_ifCancel_.st R DebuggerModel.package/DebugSession.class/instance/debugging actions/createMethodInContext_.st R DebuggerModel.package/DebugSession.class/instance/evaluating/askForCategoryIn_default_.st R DebuggerModel.package/DebugSession.class/instance/evaluating/askForSuperclassOf_toImplement_ifCancel_.st R NautilusCommon.package/extension/SystemNavigation/instance/buildSelfContainedCallsFrom_in_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script113.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30458.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Tools.package/CodeHolderSystemSettings.class/class/settings/codeEditingSettingsOn_.st R System-Support.package/SystemNavigation.class/instance/accessing/allMethodsInCategory_.st R System-Support.package/SystemNavigation.class/instance/author/allContributors.st R System-Support.package/SystemNavigation.class/instance/author/contributionsOf_.st R System-Support.package/SystemNavigation.class/instance/author/contributorsNotSignatories.st R System-Support.package/SystemNavigation.class/instance/author/signatories.st R System-Support.package/SystemNavigation.class/instance/author/signatoriesString.st R System-Support.package/SystemNavigation.class/instance/query/allCallsOn_localTo_.st R System-Support.package/SystemNavigation.class/instance/query/allObjectsSelect_.st R System-Support.package/SystemNavigation.class/instance/utilities/methodsWithInitials_.st R Tests-System.package/SystemNavigationTest.class/instance/testing/testAllMethodsInCategory.st R Tests-System.package/SystemNavigationTest.class/instance/testing/testRetrievingAllMethodsInCategory.st A Text-Edition.package/Editor.class/class/settings/skipOverMultipleSpaces.st A Text-Edition.package/Editor.class/class/settings/skipOverMultipleSpaces_.st M Text-Edition.package/Editor.class/definition.st M Text-Edition.package/Editor.class/instance/nonediting%2Fnontyping keys/cursorLeft_.st M Text-Edition.package/Editor.class/instance/nonediting%2Fnontyping keys/cursorRight_.st A Text-Edition.package/Editor.class/instance/private/nextNonBlank_.st A Text-Edition.package/Editor.class/instance/private/previousNonBlank_.st R Tools-Browser.package/extension/SystemNavigation/instance/browseAllImplementorsOfList_.st R Tools-Browser.package/extension/SystemNavigation/instance/browseAllMethodsInCategory_.st R Tools-Browser.package/extension/SystemNavigation/instance/browseUncommentedMethodsWithInitials_.st R Tools.package/extension/SystemNavigation/instance/browseUnsentMessagesInPackageNamed_.st R Tools.package/extension/SystemNavigation/instance/removeUnsentMessagesWithProgressBarInPackageNamed_.st Log Message: ----------- 30458 11804 Small cleanup in SystemNavigation https://pharo.fogbugz.com/f/cases/11804 (from me) 11806 Refactor the Create action for #doesNotUnderstand https://pharo.fogbugz.com/f/cases/11806 (from Andrei) 11805 [ENH] Editor skip over multiple white space (+ setting option) https://pharo.fogbugz.com/f/cases/11805 (From Igor)

Oct. 7, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Norbert Hartl

Am 07.10.2013 um 11:28 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Oct 7, 2013, at 11:16 , Norbert Hartl <norbert(a)hartl.name> wrote: > >> As I need an image that runs longer than 24 hours I'm looking at some stuff and wonder. Can anybody explain me the rationale for a code like this >> >> maxExternalSemaphores: aSize >> "This method should never be called as result of normal program >> execution. If it is however, handle it differently: >> - In development, signal an error to promt user to set a bigger size >> at startup immediately. >> - In production, accept the cost of potentially unhandled interrupts, >> but log the action for later review. >> >> See comment in maxExternalObjectsSilently: why this behaviour is >> desirable, " >> "Can't find a place where development/production is decided. >> Suggest Smalltalk image inProduction, but use an overridable temp >> meanwhile. " >> | inProduction | >> self maxExternalSemaphores >> ifNil: [^ 0]. >> inProduction := false. >> ^ inProduction >> ifTrue: [self maxExternalSemaphoresSilently: aSize. >> self crTrace: 'WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use'; >> crTrace: 'You should increase this size at startup using #maxExternalObjectsSilently:'; >> crTrace: 'Current table size: ' , self maxExternalSemaphores printString] >> ifFalse: ["Smalltalk image" >> self error: 'Not enough space for external objects, set a larger size at startup!' >> "Smalltalk image"] >> >> I have reported this once but got no feedback so I like to have a few opinions. >> >> The report is here: https://pharo.fogbugz.com/f/cases/10839/ >> >> Norbert > > The rationale is that inProduction would be some global setting, not yet in place when the code was writtenâ¦ > Excessive simultaneous Semaphore usage is something that should be caught during development, in which case it's better to get an active notification, than having it logged somewhere. Agreed. But didn't work in my case because it needed roughly 20 hours and an instable remote backend to trigger the problem. And somehow I forgot to install my logger as Transcript so there is no warning message. I saw only dead images in the morning. This not satisfactory but on the other hand this type of problems are hard to solve anyway. My feeling tells me there is more to discover. Sockets resources get unregistered at finalization time but this didn't work either. I would have said that the unlikely situation that no garbage collection ran could be the case. But it can't because in ExternalSemaphoreTable>>#freedSlotsIn:ratherThanIncreaseSizeTo: there is explicit garbage collection. > If I've understood correctly, it's moot on newer Pharo VM's, where there's no limit on the semtable size, but for legacy code a startup item setting size using maxExternalObjectsSilently: (as suggested in the Warning text), is still a more proper fix than setting inProduction to true and crossing your fingers hoping no signals will be lost during table growth. Ah, I didn't know about the risk of loosing signals while resizing the table. Thanks for that. Don't get me wrong I wasn't proposing to set inProduction in effect. I don't think that automatically growing resource management is a proper way to design a system. There is always a range of resources you need for your use case. Not setting an upper bound for this just covers leaking behavior. Norbert

Oct. 7, 2013

[update 3.0] #30458

by Marcus Denker

Oct. 7, 2013