- Pharo-dev - lists.pharo.org

External Semaphores leaking in Socket

by Norbert Hartl

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

Oct. 6, 2013

Re: [Pharo-dev] What is WeakActionSequence?

by HernÃ¡n Morales Durand

El 04/10/2013 14:27, Camillo Bruni escribiÃ³: > What is that class? No comments, two single methods on Object that refer to it? > A WeakActionSequence is used as container for MessageSend's. It looks like is not even really weak, there is no weakSubclass: definition... You probably don't see users because it was (tipically) only used in OmniBrowser in Pharo <= 1.4. Users of the SASE (a.k.a triggerEvent) mechanism also are (or were) users. The question is, why every object should be able to register events? Think of magnitudes registering events. Object subclasses could include all the observer pattern implementations you like. HernÃ¡n

Oct. 6, 2013

Starting image gives FileWriteError: File stdout is closed - huh?

by phil＠highoctane.be

Now, when starting my image: FileWriteError: File stdout is closed MultiByteFileStream(StandardFileStream)>>primWrite:from:startingAt:count: MultiByteFileStream(StandardFileStream)>>next:putAll:startingAt: MultiByteFileStream>>basicNext:putAll:startingAt: UTF8TextConverter(TextConverter)>>nextPutByteString:toStream: UTF8TextConverter(TextConverter)>>nextPutAll:toStream: MultiByteFileStream>>nextPutAll: I was a link while Googling but not resolution. What to do? -- Phil

Oct. 6, 2013

full version of a Lint Chapter for Entreprise Pharo forthcoming book :)

by StÃ©phane Ducasse

Hi Pharoers since we believe in quality and automation, here is a new chapter on Lint rule support in Pharo :) https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ws/Lint/Li… Stef

Oct. 6, 2013

New Critic Rule: Nobody should directly send #methodDict

by StÃ©phane Ducasse

Hi I'm really happy because "New Critic Rule: Nobody should directly send #methodDict" is the way to go. We should document the system design using automatic rules! Excellent! Stef

Oct. 6, 2013

Re: [Pharo-dev] additional Milestone label for applications

by StÃ©phane Ducasse

thanks! This is a good idea. On Oct 6, 2013, at 1:57 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> I think it should just be fine if we define a different workflow (and thus different labels) for external projects... >>> >>> >> The 'Area' field looks unused, having only a single option 'Misc'. Perhaps that could be 'Image' and 'External Project' or similar. Most of an external project's issues would also have an area of 'External 'Project', but sometimes it might be 'Image' if a change there is required to fix an issue reported on a project. Or maybe for external projects you have only a single option 'External Project' for Area. > > So we need to have 2 things > 1. a separate project for each external project that wants to report > 2. a separate Area for these external projects > > For instance, NativeBoost has both a stable version in the image and a development > version aside. So if a bug appears in the image we can set the Area to "Pharo Image" (the default). > However, if the bug concerns the development version we set the Area to something project > specific. > > I will try to update the tracker and the filters to reflect that...

Oct. 6, 2013

Re: [Pharo-dev] [ANN] Mustache templates

by Alexandre Bergel

Thanks! Nice work! Alexandre > On 4 Oct 2013, at 07:58, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 04.10.2013 um 12:32 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: >> >> What is a mustache template? > http://norbert.hartl.name/blog/2013/10/03/mustache-templates-for-smalltalk/ > > Norbert > >> On 4 Oct 2013, at 03:56, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>>> I like to announce my smalltalk port of mustache templates. >>> >>> Cool! >>> >>>> To load it do >>> >>> Consider making a copy into MetaRepoForPharo20 or MetaReporForPharo30 >>> if it is working in these versions. >>> >>> That way it is easily accessible via Config browser. >>> >>> Thx >>> T. >

Oct. 6, 2013

Re: [Pharo-dev] additional Milestone label for applications

by Camillo Bruni

>> I think it should just be fine if we define a different workflow (and thus different labels) for external projects... >> >> > The 'Area' field looks unused, having only a single option 'Misc'. Perhaps that could be 'Image' and 'External Project' or similar. Most of an external project's issues would also have an area of 'External 'Project', but sometimes it might be 'Image' if a change there is required to fix an issue reported on a project. Or maybe for external projects you have only a single option 'External Project' for Area. So we need to have 2 things 1. a separate project for each external project that wants to report 2. a separate Area for these external projects For instance, NativeBoost has both a stable version in the image and a development version aside. So if a bug appears in the image we can set the Area to "Pharo Image" (the default). However, if the bug concerns the development version we set the Area to something project specific. I will try to update the tracker and the filters to reflect that...

Oct. 5, 2013

Re: [Pharo-dev] [update 3.0] #30455

by Camillo Bruni

On 2013-10-06, at 00:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30455 > ----- > > 11790 add critic rule for keys do: -> keysDo: (and valuesDo:) > https://pharo.fogbugz.com/f/cases/11790 > > 11787 Trivial critic cleanup of CodeImport > https://pharo.fogbugz.com/f/cases/11787 > > 11793 Package Support on RBBrowserEnvironment > https://pharo.fogbugz.com/f/cases/11793 > > 11792 First simplistic file system tree inspector > https://pharo.fogbugz.com/f/cases/11792 > > > actually a FileReference tree inspector... lots of improvments possible > inspect > > FileSystem workingDirectory > > and select the FileReference Tree Inspector ha! nice :) actually we could reuse the file list here, no?

Oct. 5, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 1 regressions found. Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 5, 2013