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

Re: [Pharo-project] On cleaning image startup list

by Norbert Hartl

Am 14.04.2013 um 21:27 schrieb Igor Stasenko <siguctua(a)gmail.com>: > pfff... > > DateAndTime class>>initialize > > super initialize. > > NEVER EVER call super initialize for class initializers! > > I think we should add a lint rule for that. > Can you explain why? Norbert

April 14, 2013

[Pharo-project] Videos: MongoDB

by Stephan Eggermont

Taming MongoDB from Pharo https://www.youtube.com/watch?v=LOFygLIRLY8 now uploading: Pharo from the CommandLine

April 14, 2013

Re: [Pharo-project] Videos: FileSystem-Git

by Max Leske

Not a problem. Thanks! On 14.04.2013, at 16:11, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote: >> I noticed that there's a transition in the middle of the video (rotating cube) and then >> the entire video is shown again. So the video contains the same sequence twice. >> What's the idea behind that? > > I'm sorry about that. No CI and lack of tests I'm afraid. > It looked to me like all rendering was done before the machine ran out of disk space > so I thought it safe to start uploading everything asap. I'll put out a fixed version. > > Stephan > > >

April 14, 2013

Re: [Pharo-project] On cleaning image startup list

by phil＠highoctane.be

I was wondering about that method the other day... Now, you made it clear: crap! 2013/4/14 Igor Stasenko <siguctua(a)gmail.com> > the more i learn about DateAndTime the more i lean towards completely > rewriting this ... err.. > crap. (yes. sorry for harsh word). > > DateAndTime class>>now > is not thread-safe.. > > now > | nanoTicks msm | > > nanoTicks := (msm := self milliSecondsSinceMidnight) * 1000000. > > (LastTick < nanoTicks) ifTrue: [ > LastTick := nanoTicks. > ^ self todayAtMilliSeconds: msm]. > > LastTickSemaphore critical: [ > LastTick := LastTick + 1. > ^ self todayAtNanoSeconds: LastTick] > > Wrapping only single assignment to variable with critical section > while leaving another without it > is same as if not using critical section at all. > > > -- > Best regards, > Igor Stasenko. > >

April 14, 2013

Re: [Pharo-project] On cleaning image startup list

by Igor Stasenko

the more i learn about DateAndTime the more i lean towards completely rewriting this ... err.. crap. (yes. sorry for harsh word). DateAndTime class>>now is not thread-safe.. now | nanoTicks msm | nanoTicks := (msm := self milliSecondsSinceMidnight) * 1000000. (LastTick < nanoTicks) ifTrue: [ LastTick := nanoTicks. ^ self todayAtMilliSeconds: msm]. LastTickSemaphore critical: [ LastTick := LastTick + 1. ^ self todayAtNanoSeconds: LastTick] Wrapping only single assignment to variable with critical section while leaving another without it is same as if not using critical section at all. -- Best regards, Igor Stasenko.

April 14, 2013

Re: [Pharo-project] On cleaning image startup list

by Igor Stasenko

On 14 April 2013 21:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > pfff... > > DateAndTime class>>initialize > > super initialize. > > NEVER EVER call super initialize for class initializers! > > I think we should add a lint rule for that. > (https://pharo.fogbugz.com/default.asp?10288) > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

April 14, 2013

Re: [Pharo-project] On cleaning image startup list

by Igor Stasenko

pfff... DateAndTime class>>initialize super initialize. NEVER EVER call super initialize for class initializers! I think we should add a lint rule for that. -- Best regards, Igor Stasenko.

April 14, 2013

Re: [Pharo-project] On cleaning image startup list

by Igor Stasenko

On topic: i did not succeeded in finding who is the first guy calling 'DateAndTime now' and so i going to patch the code to detect it. -- Best regards, Igor Stasenko.

April 14, 2013

Re: [Pharo-project] On cleaning image startup list

by Igor Stasenko

On 14 April 2013 20:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 14 Apr 2013, at 20:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 14 April 2013 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> On 14 Apr 2013, at 20:24, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> Another strange thing, which i discovered is deferredStartupActions, >>>> is not empty in my image.. >>>> >>>> (you can check it by inspecting Smalltalk variable) >>>> >>>> an OrderedCollection([self managedServers >>>> do: [:each | each start]]) >>>> >>>> Sven, please check this. Maybe it is my image.. >>> >>> Euh, yes, that is what ZnServer class>>#startUp: does. >>> There is even a comment. >>> I don't remember why it is done this way, I guess someone suggested it to me. >>> Is there anything wrong with that ? >>> >> yes. the code by itself looks quite harmless. >> but i don't understand why deferredStartupActions list is not empty >> (it should be empty, and stay empty once image finished startup) > > OK, you mean that once a deferred action is executed, it should be removed from the list. > If the list is not empty, that seems like an internal problem. > it seems so.. because nothing cleaning it after.. in #executeDeferredStartupActions: (https://pharo.fogbugz.com/default.asp?10287) -- Best regards, Igor Stasenko.

April 14, 2013

Re: [Pharo-project] On cleaning image startup list

by Sven Van Caekenberghe

On 14 Apr 2013, at 20:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 April 2013 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> On 14 Apr 2013, at 20:24, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Another strange thing, which i discovered is deferredStartupActions, >>> is not empty in my image.. >>> >>> (you can check it by inspecting Smalltalk variable) >>> >>> an OrderedCollection([self managedServers >>> do: [:each | each start]]) >>> >>> Sven, please check this. Maybe it is my image.. >> >> Euh, yes, that is what ZnServer class>>#startUp: does. >> There is even a comment. >> I don't remember why it is done this way, I guess someone suggested it to me. >> Is there anything wrong with that ? >> > yes. the code by itself looks quite harmless. > but i don't understand why deferredStartupActions list is not empty > (it should be empty, and stay empty once image finished startup) OK, you mean that once a deferred action is executed, it should be removed from the list. If the list is not empty, that seems like an internal problem. >>> -- >>> Best regards, >>> Igor Stasenko. >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 14, 2013