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

Re: [Pharo-project] Too many semaphores, image blocked

by Henrik Johansen

On 21. okt. 2011, at 16:56, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > S, Henrik Sperre Johansen piÅ¡e: > >>> There's something wrong with startup/shutdown list, at least with my >>> Pharo 1.4 image... >> Both InputEventFetcher and InputEventPollingFetcher are in the lists, >> going back to at least 1.3 >> Can't have that. Probably got there when switching InputFetcher (IE a >> _long_ time ago) due to being careless with receiver of #install / >> #deinstall... > >> InputEventPollingFetcher should be removed. > > Henrik, can you prepare a patch (or instructions how to remove it) so > that I'll check immediately? > > Best regards > Janko > Execute something like: Smalltalk removeFromStartUpList: InputEventPollingFetcher; removeFromShutDownList: InputEventPollingFetcher. In a workspace, and you should be good to go. Cheers, Henry

Oct. 21, 2011

Re: [Pharo-project] Too many semaphores, image blocked

by Marcus Denker

On Oct 21, 2011, at 4:56 PM, Janko MivÅ¡ek wrote: > S, Henrik Sperre Johansen piÅ¡e: > >>> There's something wrong with startup/shutdown list, at least with my >>> Pharo 1.4 image... >> Both InputEventFetcher and InputEventPollingFetcher are in the lists, >> going back to at least 1.3 >> Can't have that. Probably got there when switching InputFetcher (IE a >> _long_ time ago) due to being careless with receiver of #install / >> #deinstall... > >> InputEventPollingFetcher should be removed. > > Henrik, can you prepare a patch (or instructions how to remove it) so > that I'll check immediately? execute: Smalltalk removeFromStartUpList: InputEventPollingFetcher. Smalltalk removeFromShutDownList: InputEventPollingFetcher. Or update to the latest 1.3 / 1.4... Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 21, 2011

Re: [Pharo-project] Too many semaphores, image blocked

by Janko MivÅ¡ek

S, Henrik Sperre Johansen piÅ¡e: >> There's something wrong with startup/shutdown list, at least with my >> Pharo 1.4 image... > Both InputEventFetcher and InputEventPollingFetcher are in the lists, > going back to at least 1.3 > Can't have that. Probably got there when switching InputFetcher (IE a > _long_ time ago) due to being careless with receiver of #install / > #deinstall... > InputEventPollingFetcher should be removed. Henrik, can you prepare a patch (or instructions how to remove it) so that I'll check immediately? Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Oct. 21, 2011

Re: [Pharo-project] Too many semaphores, image blocked

by Janko MivÅ¡ek

Hi guys, It seems that we found the culpit, according to Igor advice I'm now measuring more and yes, ExternalSemaphoreTable is growing by one every snapshot, as Henrik already found out. Few latest hourly reports: 0 HTTPCommections 5 Sockets 28 Processes 108 Semaphores 1 Socket registry 2 StandardFileStream registry 49 ExternalSemaphoreTable 0 HTTPCommections 5 Sockets 28 Processes 109 Semaphores 1 Socket registry 2 StandardFileStream registry 50 ExternalSemaphoreTable 0 HTTPCommections 5 Sockets 28 Processes 110 Semaphores 1 Socket registry 2 StandardFileStream registry 51 ExternalSemaphoreTable 0 HTTPCommections 5 Sockets 28 Processes 111 Semaphores 1 Socket registry 2 StandardFileStream registry 52 ExternalSemaphoreTable S, Igor Stasenko piÅ¡e: > 2011/10/20 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >> Hi guys, >> >> I'm measuring how my image is breathing through the time and what is >> interesting is how nr. of Semaphore instances is variating through the >> time. Every hour just before snapshot I report nr of instances, see last >> 10 hours: >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 20 Processes >> 300 Semaphores >> >> > Well, the number of semaphores tells nothing because not all of them > serve for sockets. > > There are 3 semaphores per socket. So, if you have 4 sockets, there > should be 12 external objects. > Of course not counting others, which is there for other purposes. > > Could you add following to report: > > Socket registry size > StandardFileStream registry size > (ExternalSemaphoreTable unprotectedExternalObjects reject: #isNil) size >

Oct. 21, 2011

[Pharo-project] [update 1.4] #14206

by Marcus Denker

14206 ----- Issue 4908: LinkedList collect http://code.google.com/p/pharo/issues/detail?id=4908 -- Marcus Denker -- http://marcusdenker.de

Oct. 21, 2011

Re: [Pharo-project] Some bugs

by Andrea BrÃ¼hlmann

> >> This would be too sad... >> >> > No. Too sad is being 1 year and a half to release one single release. Don't > expect perfection in each release, because otherwise there won't be any > release. > If you really need this issue, then apply the patch to your own image. Only > SERIOUS bugs can be integrated in already released versions. That a progress > bar disappears when saving the image doesn't seem to be that serious. > You are completely right :-) We just started to minimize the amount of our personal patches and are getting used to putting them on the issue tracker. But you are right, we will never get rid of personal patches because we need them before they are integrated! And of course progress bars are not so serious :-) Thanks again for all your help. Andrea

Oct. 21, 2011

Re: [Pharo-project] Text for 1.3 announcement?

by Marcus Denker

On Oct 21, 2011, at 3:17 PM, Igor Stasenko wrote: > On 21 October 2011 13:59, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> I am concerned about the error handling failure that I (easily) encountered, at least on Linux. Has anyone tried to reproduce it? >> >> > How does that prevent from releasing 1.3? > > If there are obscure bugs, they will be fixed in 1.4. Or even in 1.3... (just added 3 fixes today). The thing is that there are indefinit unknown problems. If we wait a week, for sure someone finds another. "Release" does not mean "Bug free", because "bug free" does not exist. (and it is even harder in a system with a huge, historical code base and an undefined feature set... I am always amazed to learn new features that people seem to not be able to life without that I did not even know existed. How can we gurantee that these don't break? We just can't). Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 21, 2011

Re: [Pharo-project] Text for 1.3 announcement?

by Igor Stasenko

On 21 October 2011 13:59, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I am concerned about the error handling failure that I (easily) encountered, at least on Linux. Â Has anyone tried to reproduce it? > > How does that prevent from releasing 1.3? If there are obscure bugs, they will be fixed in 1.4. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Marcus Denker [marcus.denker(a)inria.fr] > Sent: Friday, October 21, 2011 2:48 AM > To: An open mailing list to discuss any topics related to an open-source Smalltalk > Subject: [Pharo-project] Text for 1.3 announcement? > > Hi, > > We should officially announce 1.3... > > For that we need a short text to be posted as a news: > > Â Â Â Â http://www.pharo-project.org/news > > Anyone interested in writing it? > > > -- > Marcus Denker -- http://marcusdenker.de > > > > -- Best regards, Igor Stasenko.

Oct. 21, 2011

[Pharo-project] [update 1.4] #14205

by Marcus Denker

14205 ----- Issue 4927: Remove duplicate InputEvent sensor entry in startup/shutdown lists ( running out of semaphores ) http://code.google.com/p/pharo/issues/detail?id=4927 Issue 4683: Code completion breaks search fields http://code.google.com/p/pharo/issues/detail?id=4683 Issue 4921: MIMEDocument class >> guessTypeFromName: should return a String http://code.google.com/p/pharo/issues/detail?id=4921 -- Marcus Denker -- http://marcusdenker.de

Oct. 21, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Philippe Marschall

On 10/16/2011 02:03 PM, StÃ©phane Ducasse wrote: > Mariano I think that the point that Philippe (our national butcher) is trying to make is the following: > If by design a serializer takes the perspective that it will be able to load old formats and ensure > evolution all the time then you have a really cool serializer. > > Now why in fuel it is not possible to have > FuelMaterializer load: aFile > > load using the default = current format > > > FuelMaterializer load: aFile asOfVersion: 1.4 > Of course this can be much slower but when you want to load data of the past you are just happy that this is > working. Not exactly but almost. Put the version in the format and automatically load it using the right class (it has already been written, just don't delete it). This also allows to find out whether the format is too new. Not being able to serialize in an older format would be fine as long as you can still load them. Cheers Philippe

Oct. 21, 2011