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

Re: [Pharo-project] Clock/Delay problems

by stephane ducasse

On Feb 13, 2013, at 6:39 PM, phil(a)highoctane.be wrote: > Don't know if this is related but the 2.0 image seems to runs slower > on my box (20543 now). this is strange because people told me exactly the inverse yesterday (comparing to 1.4). So this is difficult to assess. Stef > > Also a question: why is there a ZnServer in the StartUpList ? I saw > discussions on the loading of .changes if there is none in the image > folder. > > Phil > > 2013/2/13 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> On 13 Feb 2013, at 18:17, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Is this related to that large list of [delaySemaphore wait] in >>> Delay>>wait that I do see in the Process Browser? This thing wasn't so >>> large in the past. >> >> Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image. >> >>> Phil >>> >>> 2013/2/13 Igor Stasenko <siguctua(a)gmail.com>: >>>> My personal take about this issue: >>>> >>>> - when image starting up, all Delays should be reset by unblocking all >>>> waiting processes (regardless how much extra time there left to be >>>> waiting). >>>> >>>> Because, to my opinion, a code which uses delays to cross session >>>> boundaries will fail badly anyways, >>>> so imo it is better to have delays unblocked the process prematurely, >>>> rather than blocking it for next 2^30 milliseconds (or any random big >>>> number around that). >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> >> >

Feb. 13, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by Sean P. DeNigris

Frank Shearar-3 wrote > As a general rule this is a very bad idea +1. It's a bad habit to get into and subverts part of MetaC's usefulness, as Frank described. In fact, I find 4.5.1 very exciting, because it uses semantic versioning to communicate a whole world to the user without a long comment. Given x.y.z, z is a bug-fix release with no additional functionality -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669711.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by stephane ducasse

On Feb 13, 2013, at 6:28 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 13 February 2013 16:03, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >> On Feb 13, 2013, at 4:06 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >>> stephane ducasse wrote >>>> @sean what was the problem because I tested it several time on 1.4 and 2.0 >>> >>> The tests were failing due to FS differences between 1.4 and 2.0. I uploaded >>> fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged >>> release so we shouldn't change it). Also, I moved the dependency on the >>> CommandShell version from the baseline (where I originally put it in error), >>> to the versions. >> >> Nobody use this 4.5 so we could just modify it. Because 4.5.1 looks boring to me. > > As a general rule this is a very bad idea. The version number should > allow you to say with certainty what's in an artifact. Just modifying > it means that "4.5" tells you just about nothing about someone's setup > when they say "4.5 is broken". frank I do not really need a lesson. ***I*** created the wrong 4.5 version so probably nobody could reliably use it. So what is the point to get a major version broken. I do not want to always have to remember that I should use 4.5.1.1 better 4.5 Stef > > frank > >>> For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC >>> into a #'squeak' one. >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by Sven Van Caekenberghe

Hi Phil, On 13 Feb 2013, at 18:39, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Don't know if this is related but the 2.0 image seems to runs slower > on my box (20543 now). That is hard to quantify, but any regressions should be investigated. > Also a question: why is there a ZnServer in the StartUpList ? I saw > discussions on the loading of .changes if there is none in the image > folder. No, the automatic loading of .sources has become an option that is off by default. ZnServer is in the startup list, because it manages a list of registered server instances. If you create a ZnServer and it is registered, it will shutdown/restart on image shutdown/restart. This is something that is traditionally expected from servers running in a Smalltalk image. It can be handy during development, but I do not like it or use it for production systems. Sven > Phil > > 2013/2/13 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> On 13 Feb 2013, at 18:17, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Is this related to that large list of [delaySemaphore wait] in >>> Delay>>wait that I do see in the Process Browser? This thing wasn't so >>> large in the past. >> >> Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image. >> >>> Phil >>> >>> 2013/2/13 Igor Stasenko <siguctua(a)gmail.com>: >>>> My personal take about this issue: >>>> >>>> - when image starting up, all Delays should be reset by unblocking all >>>> waiting processes (regardless how much extra time there left to be >>>> waiting). >>>> >>>> Because, to my opinion, a code which uses delays to cross session >>>> boundaries will fail badly anyways, >>>> so imo it is better to have delays unblocked the process prematurely, >>>> rather than blocking it for next 2^30 milliseconds (or any random big >>>> number around that). >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> >> >

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by phil＠highoctane.be

Don't know if this is related but the 2.0 image seems to runs slower on my box (20543 now). Also a question: why is there a ZnServer in the StartUpList ? I saw discussions on the loading of .changes if there is none in the image folder. Phil 2013/2/13 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 13 Feb 2013, at 18:17, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Is this related to that large list of [delaySemaphore wait] in >> Delay>>wait that I do see in the Process Browser? This thing wasn't so >> large in the past. > > Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image. > >> Phil >> >> 2013/2/13 Igor Stasenko <siguctua(a)gmail.com>: >>> My personal take about this issue: >>> >>> - when image starting up, all Delays should be reset by unblocking all >>> waiting processes (regardless how much extra time there left to be >>> waiting). >>> >>> Because, to my opinion, a code which uses delays to cross session >>> boundaries will fail badly anyways, >>> so imo it is better to have delays unblocked the process prematurely, >>> rather than blocking it for next 2^30 milliseconds (or any random big >>> number around that). >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > >

Feb. 13, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by Frank Shearar

On 13 February 2013 16:03, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Feb 13, 2013, at 4:06 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> stephane ducasse wrote >>> @sean what was the problem because I tested it several time on 1.4 and 2.0 >> >> The tests were failing due to FS differences between 1.4 and 2.0. I uploaded >> fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged >> release so we shouldn't change it). Also, I moved the dependency on the >> CommandShell version from the baseline (where I originally put it in error), >> to the versions. > > Nobody use this 4.5 so we could just modify it. Because 4.5.1 looks boring to me. As a general rule this is a very bad idea. The version number should allow you to say with certainty what's in an artifact. Just modifying it means that "4.5" tells you just about nothing about someone's setup when they say "4.5 is broken". frank >> For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC >> into a #'squeak' one. >> >> >> >> -- >> View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by Sven Van Caekenberghe

On 13 Feb 2013, at 18:17, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Is this related to that large list of [delaySemaphore wait] in > Delay>>wait that I do see in the Process Browser? This thing wasn't so > large in the past. Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image. > Phil > > 2013/2/13 Igor Stasenko <siguctua(a)gmail.com>: >> My personal take about this issue: >> >> - when image starting up, all Delays should be reset by unblocking all >> waiting processes (regardless how much extra time there left to be >> waiting). >> >> Because, to my opinion, a code which uses delays to cross session >> boundaries will fail badly anyways, >> so imo it is better to have delays unblocked the process prematurely, >> rather than blocking it for next 2^30 milliseconds (or any random big >> number around that). >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by phil＠highoctane.be

Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past. Phil 2013/2/13 Igor Stasenko <siguctua(a)gmail.com>: > My personal take about this issue: > > - when image starting up, all Delays should be reset by unblocking all > waiting processes (regardless how much extra time there left to be > waiting). > > Because, to my opinion, a code which uses delays to cross session > boundaries will fail badly anyways, > so imo it is better to have delays unblocked the process prematurely, > rather than blocking it for next 2^30 milliseconds (or any random big > number around that). > > > -- > Best regards, > Igor Stasenko. >

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by Igor Stasenko

My personal take about this issue: - when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting). Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that). -- Best regards, Igor Stasenko.

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by Igor Stasenko

On 13 February 2013 18:01, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Sven > > can you add a bug entry because igor and camillo were discussing about the > strange logic of DateAndTime? > yeah.. i was looking at it recently (remember my post about DateAndTime nanosecond precision handling).. still did not found anything which causing the problems. there is too much stuff involved during startup... and since you cannot debug that code, you cannot see what happens :( > Stef > > On Feb 11, 2013, at 2:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I have seen this before, and it is probably related to other problems that > we have been seeing lately: > > <PharoScreenshot.png> > > Basically the whole initialization of DateAndTime (class side) goes wrong. > > Could this have something to do with Delay problems ? > > Some time ago, there were some Delay changes, right ? > > I have not yet made an issue, as I think we should discuss a bit first. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- Best regards, Igor Stasenko.

Feb. 13, 2013