Hi,
Deprecated class TimeStamp has always has second precision.
After the introduction of the ANSI Chronology classes, TimeStamp is implemented as a subclass of DateAndTime - inadvertantly inheriting nano-second precision.
This changest ensure that TimeStamp class>>#now and TimeStamp class>>current clear out the nanosecond field.
Note. This means that (TimeStamp now = TimeStamp now) could be true. Fix TimeStampTest>>#testComparing to accomodate this."!
The three changests posted today:
chronologyClassComments-brp testChronologyHours12-brp chronologyTimeStampNow-brp
ensure that all the SUnit tests for Kernel-Chronology pass in 3.7-5816
Cheers
Brent
Hi,
When you move between projects, Squeak saves the display depth of the project just before in the method Project>>enter:revert:saveForRevert:. However, As "Display depth" returns the absolute value of the instance variable "depth" of Display, you lose the information of endian. Both 3.6 and 3.7a.
I don't know the impact of this, but if Squeak supports both endians for the performance, why don't you fix it?
Cheers, - ICHIKAWA, Yuji
Here is a change set to fix it.
Cheers, - ICHIKAWA, Yuji
----- Original Message ----- From: "ICHIKAWA, Yuji" y.ich@f3.dion.ne.jp To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, March 13, 2004 12:12 AM Subject: [BUG] display depth endian
Hi,
When you move between projects, Squeak saves the display depth of the project just before in the method Project>>enter:revert:saveForRevert:. However, As "Display depth" returns the absolute value of the instance variable "depth" of Display, you lose the information of endian. Both 3.6 and 3.7a.
I don't know the impact of this, but if Squeak supports both endians for
the
performance, why don't you fix it?
Cheers,
ICHIKAWA, Yuji
Ichikawa-san,
I don't know the impact of this, but if Squeak supports both endians for the performance, why don't you fix it?
I looked at your suggested change, but can't quite figure out what problem it is trying to solve. The Display object itself doesn't get stored into the image or project file. The image file or the project file loaded creates, or uses the existing, Display.
the rule of sum is that the depth of the display is determined by the new environment in which the saved thing gets loaded, and the instance variable value of the displayDepth which is local to a Project doesn't used. So I think we can keep the things as it is.
-- Yoshiki
Ohshima-san,
The behavior I encountered on Windows machine is, 1. I set the display depth of "appearance" to 32-bit littlen endian (just because x86 machine may like little endian...) 2. I went to other project and returned to the project. 3. Then I saw that the display depth of "appearance" is set to 32-bit big endian. That is all, no other problems.
I'm sorry that I don't understand the impact of endian setting yet, so just I paid attention to the sign of displayDepth. Appended change set is my latest result.
The endian treatment seems to be added later, several methods in DisplayScreen and Form assumes the depth is positive. So I can't conclude my change better. Keeping the things is good because currently there are no actual problems.
Thank you for your investigation, - ICHIKAWA, Yuji
----- Original Message ----- From: "Yoshiki Ohshima" Yoshiki.Ohshima@acm.org To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Sunday, March 14, 2004 8:49 AM Subject: Re: [BUG] display depth endian
Ichikawa-san,
I don't know the impact of this, but if Squeak supports both endians for
the
performance, why don't you fix it?
I looked at your suggested change, but can't quite figure out what problem it is trying to solve. The Display object itself doesn't get stored into the image or project file. The image file or the project file loaded creates, or uses the existing, Display.
the rule of sum is that the depth of the display is determined by the new environment in which the saved thing gets loaded, and the instance variable value of the displayDepth which is local to a Project doesn't used. So I think we can keep the things as it is.
-- Yoshiki
I'm proposing to fix this in the primitive for the next VMMaker release; does anyone see a problem with this?
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Oxymorons: Plastic glasses
squeak-dev@lists.squeakfoundation.org