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

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

by Igor Stasenko

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) >> -- >> Best regards, >> Igor Stasenko. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- 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: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 ? > -- > Best regards, > Igor Stasenko. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 14, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

On 14 April 2013 12:50, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 13 Apr 2013, Igor Stasenko wrote: > >> On 13 April 2013 21:36, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Sat, 13 Apr 2013, Igor Stasenko wrote: >>> >>>> >>>> Both #timeToRun and secondsWhenClockTicks (via Delay) using same >>>> primitive >>>> - #millisecondClockValue. >>>> Sure thing, precision of this primitive should be it is 1 millisecond >>>> or smaller.. >>>> But it has nothing to do with precision of primSecondsClock and you >>>> cannot increase precision of >>>> it using #millisecondClockValue. >>> >>> >>> >>> The only thing I wanted to point out is that the value of >>> #primSecondsClock >>> changes when the actual second changes (the difference is less than 1ms). >>> So >>> while its resolution is just 1 second, it's accuracy is better than 1ms. >>> Here's another example using the microsecond clock: >>> >>> >>> (1 to: 10) collect: [ :e | >>> | start | >>> Time secondsWhenClockTicks. >>> start := Time primUTCMicrosecondClock. >>> Time secondsWhenClockTicks. >>> Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 >>> 999961 999926 1000029 999988 999991 999985 998089 1000034)" >>> >> >> My gut feeling that here you are rather measuring accuracy of 1ms >> Delay operation (in secondsWhenClockTicks method). > > > No. I just wanted to show that this method works in practice (yeah, it's > there for years and actually noone had any problems with it). And even > though there's a slight chance for it to drift away by a few milliseconds, > your statement - using a random number for the millisecond part is not worse > than using this method - is not true. > Maybe you are right. But i do not see a compelling reason having DateAndTime soo precise. It makes not sense. And TimeStamp's resetting nanosecs field (in very peculiar way) by rounding it to 1sec heavily backing up my argument. If you need precision/accuracy higher than 1 sec, you should use milli/micro second clock counter. The mess in DateAndTime is imo a big piece of overengineering. > Levente > -- Best regards, Igor Stasenko.

April 14, 2013

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

by Igor Stasenko

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.. -- Best regards, Igor Stasenko.

April 14, 2013

[Pharo-project] On cleaning image startup list

by Igor Stasenko

Hi, i am checking image startup list trying to see if anything uses DateAndTime now (or anything with "now") before DateAndTime does own "startup".. which i suspecting causing this hung process spawning. Due to brittle logic in DateAndTime startup, i think we should promote it closer to Delay startup.. because right now it looks like following: an OrderedCollection(#Delay #OSPlatform #DiskStore #DisplayScreen #Cursor #InputEventFetcher #InputEventSensor #ProcessorScheduler #NaturalLanguageTranslator #ShortIntegerArray #PasteUpMorph #SmalltalkImage #CPUWatcher #Clipboard #InternetConfiguration #Locale #MultiByteFileStream #UUIDGenerator #WeakArray #MacOSClipboard #RecentMessageList #EditorFindReplaceDialogWindow #ZnServer #DateAndTime #FreeTypeSettings #LanguageEnvironment #FileStream #FileLocator #StartupLoader #DefaultCommandLineHandler #FT2Handle) Also, along the way, i found some stuff which to me looks like abuse: NaturalLanguageTranslator, RecentMessageList - already reported on bugs tracker The EditorFindReplaceDialogWindow this one is strange too.. and i'd like to ask about. startUp "This message is sent to registered classes when the system is coming up." Singleton ifNotNil: [Singleton close. Singleton := nil] may i ask why it is sooo important for system to keep some arbitrary morph closed when image goes up? I do not see a valid reason for this, but i might be miss something.. IMO if something can be solved without adding things to startup, it should be solved like that. In general, I think it is logical that everything which can potentially uses dates (like ZnServer, FileSystem & al) should start up after DateAndTime, even if they are not using dates in their own startup method. (but they could spawn threads which do) -- Best regards, Igor Stasenko.

April 14, 2013

Re: [Pharo-project] we spent couple of hours: checking comments and cleaning Athens

by Igor Stasenko

On 14 April 2013 19:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > :) > It was cool to sit and learn stuff by watching igor :). > i will commit the changes soon. > Stef > -- Best regards, Igor Stasenko.

April 14, 2013

[Pharo-project] we spent couple of hours: checking comments and cleaning Athens

by StÃ©phane Ducasse

:) It was cool to sit and learn stuff by watching igor :). Stef

April 14, 2013

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

by Stephan Eggermont

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] Videos: FileSystem-Git

by Max Leske

Cool! Thanks Stephan! 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? Cheers, Max On 14.04.2013, at 14:21, Stephan Eggermont <stephan(a)stack.nl> wrote: > FileSystem-Git > https://www.youtube.com/watch?v=4qld2mDIbg4 > and uploading: Taming MongoDB from Pharo >

April 14, 2013

[Pharo-project] Videos: FileSystem-Git

by Stephan Eggermont

FileSystem-Git https://www.youtube.com/watch?v=4qld2mDIbg4 and uploading: Taming MongoDB from Pharo

April 14, 2013