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

Re: [Pharo-project] System time

by Andres Valloud

Ok, so each time you add the offset things become more and more imprecise... http://msdn.microsoft.com/en-us/library/dd757629%28v=vs.85%29.aspx "The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod." Note you cannot even assume what the precision is because the function timeBeginPeriod() changes the precision for EVERY program (plus it has other side effects). Of course, then the docs state "Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution" even though the relevant specs mention all sorts of problems when one uses QueryPerformanceCounter(). This is typical MSDN, unfortunately. On 5/2/11 3:56 , Henrik Sperre Johansen wrote: > On 02.05.2011 00:56, Andres Valloud wrote: >> Does the Windows VM depend on QueryPerformanceCounter()? > The Cog VM (which it seemed Jimmie was using) uses a clock > (sqWin32Heartbeat.c) initialized with > GetSystemTimeAsFileTime and timeGetTime > then adds an offset based on current timeGetTime (reinitialization > happens at rollovers) > > I can't see any mention of drift in the Microsoft documentation of > timeGetTime, but I guess there must be some? > > Cheers, > Henry > >

May 2, 2011

Re: [Pharo-project] System time

by Henrik Sperre Johansen

On 02.05.2011 00:56, Andres Valloud wrote: > Does the Windows VM depend on QueryPerformanceCounter()? The Cog VM (which it seemed Jimmie was using) uses a clock (sqWin32Heartbeat.c) initialized with GetSystemTimeAsFileTime and timeGetTime then adds an offset based on current timeGetTime (reinitialization happens at rollovers) I can't see any mention of drift in the Microsoft documentation of timeGetTime, but I guess there must be some? Cheers, Henry

May 2, 2011

Re: [Pharo-project] System time

by Andres Valloud

I'd look into how the VM knows what time it is. Sooner or later there will be a primitive or some FFI call that asks the OS to tell you the time. You should follow the VM Code Lawyer's Standard Procedure(TM): 1. What is the VM doing, exactly? 2. What are the relevant *official* specifications governing what the VM is doing? Be thorough in your search. 3. Does the VM implementation comply 100% with the specifications' requirements? If you cannot answer "yes" at step 3, then you don't know what's going on. Chances are the VM merely *appears* to work, but you can't quite explain why. This is bad and should be rectified. If you are forced to answer "no" at step 3, then you know the VM is Broken(TM). A lot of bugs are caused by specification violations. I know working with C specifications is not cool because it's not Smalltalk and all of that stuff, but I think it's even less cool to have a Broken(TM) VM so something has to be done. I did some investigation about similar problems for Windows not long ago. Basically, relying on the function QueryPerformanceCounter() is just bad. Moreover, if the x86 VMs depend on the CPU's timestamp counter, then you are going to get problems like those you get with QueryPerformanceCounter(). Trace through the documentation on the function QueryPerformanceCounter(), the boot switch /usepmtimer, and something called HPET. On 5/2/11 0:49 , Mariano Martinez Peck wrote: > > > On Mon, May 2, 2011 at 12:56 AM, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net > <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: > > Does the Windows VM depend on QueryPerformanceCounter()? > > > I have no idea what that is, but a quick > > grep -n "QueryPerformanceCounte" -r > ~/Pharo/vm/git/cogVMMaster/blessed/platforms > > tell me that not. > > > > On 5/1/11 16:53 , Alexandre Bergel wrote: > > Strange. I cannot produce this problem on OSX. > > Alexandre > > > On 30 Apr 2011, at 22:15, Jimmie Houchin wrote: > > Hello, > > My OS for this application is Windows. On a freshly opened > image, the image and OS time are in sync. Over a period of > time the image drifted 34 seconds away from OS time. I do > not know how long I had this image open, but it has been a > number of days, possibly a week plus. > > I saved the image and quit. I reopened the image and did > DateAndTime now and it was in sync with the OS once again. > Same image, vm and OS that was out of sync by 34 seconds > only one minute before. > > I have opened an image on my server which is also running > the latest cog vm, the current Pharo 1.3 and Windows Vista. > I am going to periodically do a DateAndTime now to log the > drift if any. Prior to opening this image I updated the OS > system clock with time.nist.gov <http://time.nist.gov> which > is about 1000 miles away. > > I know that within a second or so it can be subject to my > coordination of doing DateAndTime now while watching my OS > system clocks seconds. But 34 seconds is beyond any > subjective standards. > > The only reason I discovered this was while exploring how I > want to retrieve my data, act upon my data and then pause > (Delay wait) until time to repeat. > dtnow := DateAndTime now. > dtnext := DateAndTime year: 2011 month: 4 day: 30 hour: > 11 minute: i second: 5. "The next minute in the future" > (Delay forDuration: (dtnext - dtnow)) wait. > > I got an error, that Duration cannot be a negative number. > As I processed the debugger, I saw that dtnow was greater > than dtnext. I watched the OS clock and manually selected > the next minute before I executed. However, I was within > that 34 second window. > > So now I am exploring the problem. > > Thanks. > > Jimmie > > On 4/30/2011 5:06 PM, Alexandre Bergel wrote: > > 'Time now' gives me the same result than OSX > > Alexandre > > > On 30 Apr 2011, at 16:15, Jimmie Houchin wrote: > > On 4/30/2011 11:50 AM, StÃ©phane Ducasse wrote: > > I am developing a time sensitive > application. I poll a server every minute > for new data. The data is time sensitive and > the sooner I can get the data to the release > of the data the better. > > I have noticed that Pharo's system time > drifts away from the OS system time. I would > really like the Pharo system time to be the > correct time. > > do you have a repeatable scenario? > VM > Image information. > > Pharo 1.3 and the latest Cog. > > I have not been able to find where in Pharo > I can call to update the System clock to the > correct time. > > you can use OSProcess (only mac and linux) > > No, that's not the problem. The OS clock is right. > It's Pharo that has drifted away from correct time. > Regardless it would be nice if I have to correct the > OS clock, it would still be nice to resync Pharo > with the OS, keep both in sync and correct. What I > am wanting is simply to resync the Pharo clock with > the OS clock. > > It seems that when the Pharo image is started that > it gets the OS System time, but keeps its own time > after that. Now I do not know the consequences of > Pharo adjusting its time backward. If this isn't > possible, then I might have to do some workarounds > to insure that I get my data in a timely manner. > > The image I have been developing in is currently > about 30 seconds ahead of the OS clock. It is on my > laptop. It might be due to the laptops sleep and > hibernation. I have not tested this on my server. > > That is the situation as best I know it. > > Thanks. > > Jimmie > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 2, 2011

[Pharo-project] stable RPackage version

by Tudor Girba

Hi, ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For example, download the following Moose image: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… and try RPackage organizer packageNamed: 'Famix-Core' If you load RPackage 3.0 it works. So, can we mark 3.0 as stable? Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice."

May 2, 2011

Re: [Pharo-project] digitAt: issue

by Bernat Romagosa

Ouch, understood! Then what would be the proper way to address a decimal digit in a number? I can only think of (bigNumber asString at: index) asNumber, which is... awful. 2011/5/2 Sven Van Caekenberghe <sven(a)beta9.be> > Bernat, > > On 02 May 2011, at 11:13, Bernat Romagosa wrote: > > > Hi, try to run the following: > > > > (2 raisedTo: 100000) digitAt: 1 > > > > The expected result (if I understood what digitAt: should return) is 9, > but the message returns 0 instead. In fact, it returns 0 for any index. > > > > Is this a bug or am I missunderstanding how digitAt: should work? > > > > Cheers, > > > > Bernat Romagosa. > > > > p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter > VMMaker-oscog.51]' on Debian Lenny. > > Consider, > > 2 raisedTo: 32 > > #digitAt: for digits 1 to 4 returns 0, 5 return 1. > From the comments you can see that the number is looked at in base 256. > The above number thus has 5 digits in this base, four are zero and the > highest one is one. > Furthermore, the first digit is the lowest one. > If you inspect the number it might become clearer. > > Any #digitAt: has to depend on the base you use to represent the number, > this one doesn't, so it seems to be useful only to return internal parts of > a number. > > HTH, > > Sven > > >

May 2, 2011

Re: [Pharo-project] digitAt: issue

by Nicolas Cellier

Hello, digitAt: 1 returns the least significant byte, thus it is expectedto be 0. The most significant would be | n | (n := 2 raisedTo: 100000) digitAt: n digitLength Nicolas 2011/5/2 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > Hi, try to run the following: > > (2 raisedTo: 100000) digitAt: 1 > > The expected result (if I understood what digitAt: should return) is 9, but > the message returns 0 instead. In fact, it returns 0 for any index. > Is this a bug or am I missunderstanding how digitAt: should work? > Cheers, > Bernat Romagosa. > p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter > VMMaker-oscog.51]' on Debian Lenny.

May 2, 2011

Re: [Pharo-project] digitAt: issue

by Sven Van Caekenberghe

Bernat, On 02 May 2011, at 11:13, Bernat Romagosa wrote: > Hi, try to run the following: > > (2 raisedTo: 100000) digitAt: 1 > > The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index. > > Is this a bug or am I missunderstanding how digitAt: should work? > > Cheers, > > Bernat Romagosa. > > p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny. Consider, 2 raisedTo: 32 #digitAt: for digits 1 to 4 returns 0, 5 return 1. >From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer. Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number. HTH, Sven

May 2, 2011

Re: [Pharo-project] Think about migration upfront! (was Re: squeaksource is down - a different perspective)

by Tobias Pape

Am 2011-05-02 um 10:00 schrieb Janko MivÅ¡ek: > I think we should learn very carefully from Gemstone migration > experiences to develop our Smalltalk systems *upfront* with migration in > mind. > > Just see all recent (or less recent) examples: MC2 seems too radical to > be easily migrated from MC1 and obviously designed without migration in > mind, SqueakSource as well, SS3 too? Just by chance. I really have migratioin in my mind, it was painfully enough to migrate from SqueakSource to SqueakSource2 so I pay attention to it but had not enough time to come up with something really useful :/ So Long -Tobias

May 2, 2011

[Pharo-project] digitAt: issue

by Bernat Romagosa

Hi, try to run the following: (2 raisedTo: 100000) digitAt: 1 The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index. Is this a bug or am I missunderstanding how digitAt: should work? Cheers, Bernat Romagosa. p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.

May 2, 2011

Re: [Pharo-project] Don't you think "Windows" menu item should be with the rest?

by Fabrizio Perin

2011/4/30 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Sat, Apr 30, 2011 at 9:08 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Mariano >> let it like it is. >> we did it because windows is not the same as the other one and got in our >> way.... >> so either we remove windows or we let it like that. the three others are >> nicely grouped. >> > > Ok...that's why I asked instead of directly open an issue. I wanted to know > if it was intentional or not. > I am not sure if I would like to remove them. Maybe we can remove some > options. > There are 2 that I use quite frequently: "Close all debuggers" and "Delete > unchanged windows" (which in fact the name is bad for me) > I also use "Close all debuggers" and "Delete unchanged windows" quite frequently so it would be nice for me to keep them somewhere in the world menu i don't care if in "Windows" or "System". Thanks, Fabrizio > > > > >> Stef >> On Apr 30, 2011, at 12:40 AM, Mariano Martinez Peck wrote: >> >> > Right now, there is a special section for "Windows", but I think it is >> easier if it is together with Help, System, Tools, etc. >> > I attach a screenshot. >> > >> > In addition, it changed the order in compare with Pharo 1.2 where it >> was: >> > >> > Tools >> > Windows >> > System >> > Help >> > >> > What do you tink ? >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > <Pharo 1.2.png><Pharo 1.3.png> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 2, 2011