January 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

by philippe.back＠highoctane.be

+100 Priority has nothing to do with the release per se. Phil Le 31 janv. 2017 00:11, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : > > > 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. 30, 2017

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

by Nicolai Hess

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. 30, 2017

Re: [Pharo-dev] Memory leaks

by Sven Van Caekenberghe

> On 30 Jan 2017, at 22:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > It looks like that we are currently suffering memory leaks. That is a bit strong a statement. Maybe some IDE UI stuff might sometimes hold onto something too long. > In march 2015 it was said in the mailing list: > > -=-=-=-=-=-=-=-= > I also tried this: > > 1. Create a dummy class: > Object subclass: #AAA > instanceVariableNames: 'x' > classVariableNames: '' > category: 'AAA'. > > 2. Open a Playground and do it and go on this: > a := #AAA asClass new. And why would you do that ? You assign to a workspace variable, hence your object is held in the scope of the Playground. So whenever the Playground gets retained by some other object, like an announcement, event or whatever, your object get retained too. I am 100% sure that if you do 1e6 timesRepeat: [ #AAA asClass new ]. 3 timesRepeat: [ Smalltalk garbageCollect ]. #AAA asClass allInstances isEmpty. => true > 3. In the second pane go on "self" > > 4. Close the Playground > > 5. Execute: > 3 timesRepeat: [ Smalltalk garbageCollect ]. > > 6. Check: > #AAA asClass allInstances. > > 7. Repeat if necessary, and after a while, the result after step 6 is not empty. > -=-=-=-=-=-=-=-= > > 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? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 30, 2017

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

by Denis Kudriashov

2017-01-30 22:19 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Yes, I check. If port is busy then localPort will be different And I cover it in TCPServer with test

Jan. 30, 2017

Memory leaks

by Alexandre Bergel

Hi! It looks like that we are currently suffering memory leaks. In march 2015 it was said in the mailing list: -=-=-=-=-=-=-=-= I also tried this: 1. Create a dummy class: Object subclass: #AAA instanceVariableNames: 'x' classVariableNames: '' category: 'AAA'. 2. Open a Playground and do it and go on this: a := #AAA asClass new. 3. In the second pane go on "self" 4. Close the Playground 5. Execute: 3 timesRepeat: [ Smalltalk garbageCollect ]. 6. Check: #AAA asClass allInstances. 7. Repeat if necessary, and after a while, the result after step 6 is not empty. -=-=-=-=-=-=-=-= 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? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 30, 2017

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

by Denis Kudriashov

2017-01-30 21:30 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > In #isListening code I see extra condition "self serverSocket localPort > = self port". Could you explain what case it is covered? > > IIRC, the idea was that if you bind/listen unsuccessfully, that condition > is not true, but again, it was a long time ago, and maybe is not bullet > proof. Yes, I check. If port is busy then localPort will be different

Jan. 30, 2017

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

by Sven Van Caekenberghe

> 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? IIRC, the idea was that if you bind/listen unsuccessfully, that condition is not true, but again, it was a long time ago, and maybe is not bullet proof.

Jan. 30, 2017

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

by Denis Kudriashov

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?

Jan. 30, 2017

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

by Sven Van Caekenberghe

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. Have you seen the other methods of queries protocol of Socket ? > On 30 Jan 2017, at 18:23, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi, > > I remember in past there was some reports about it. And now I was a victim of this problem which is very difficult to debug. > > Pharo allows to start two listener sockets on same port. You will not see any error. State of both sockets will be identical. "socket isValid, socket status" will be always correct for both instances. > You can play with sockets with following code: > (socket := Socket newTCP) > setOption: 'TCP_NODELAY' value: 1; > setOption: 'SO_SNDBUF' value: 4096; > setOption: 'SO_RCVBUF' value: 4096. > socket listenOn: 40424 backlogSize: 32. > > When many listener sockets are created. Only first will receive connections. So first server will work. But others will not with no way to know why. > > But more dramatical scenario is when first socket becomes collected as garbage which will destroy it. > In this case You will be completely confusing why your single instance in image is not working. > Such case is of course some bug in how you manage sockets. But that's the problem: > It is now impossible to debug such cases. > > Can we fix it? Is it possible to signal error when socket is not really listen? > > Best regards, > Denis

Jan. 30, 2017

Re: [Pharo-dev] Pharo 6 release status

by Guillermo Polito

On Mon, Jan 30, 2017 at 5:49 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi all, > > as announced, for the Pharo 6 release we set milestone of almost all low > priority issues to "Later". If you feel that some of the postponed issues > you reported are important and needs to be fixed before the release, please > change the milestone back to Pharo 6. > Bah, not only... If there is no code available for the fix, even it it says "Pharo 6" it cannot be integrated... > > All issues where it was possible to decide were tagged as ExistedInPharo5 > or NewInPharo6. The priority of most of the cases tagged as ExistedInPharo5 > were decreased to priority "Fix if time". If you think think that some of > these issues must be fixed for the next release, please increase their > priority. Otherwise such issues will be marked as "Later" before the > release. > > Again, increasing the priority does not magically fix the issues. > If you have a lot of subscribed issues, sorry for the noise in your inbox. > Thanks :P > > We have now 153 open issues for Pharo 6. > 48 issues are now with priority "Must fix" or higher. > We hope in release date on the 1st of April. > > Cheers, > -- Pavel > > >

Jan. 30, 2017