Hi!

Bert Freudenberg bert@freudenbergs.de wrote:

goran@krampe.se schrieb:

...

Hi!

Just posted this ENH on Mantis making "DateAndTime now" 6 times faster (and lots, lots more):

http://bugs.impara.de/view.php?id=4669

...enjoy. And please review.

Great that someone is looking into this!

There are other gross inefficiencies in there, like that every Date instance stores a duration with nano-second precision. See

http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/100427

• Bert -

Right. I haven't looked into all this enough to give any judgement on the design - I just did "behaviour preserving refactorings" to get speed. It would be nice if someone could summarize all Time related classes and when to use which one. There is plenty of them these days. :)

For example, Date as you mention seems IMHO also like it still could be stored as a julian day number. A "Date beast" with duration etc seems like it probably could be called a Day instead. A Date does not in my mind represent a "specific historic period", but I am no expert of course.

regards, Göran

PS. We also use the Timezone stuff from David Lewis and that also ties into this using class PointInTime etc. Phew. One thing we found is that David added a small "daemon" process that keeps track of "now" and that can very quickly give back an instance. But it wasn't hooked into the general machinery so it was just sitting there. :) We hooked it in and it seems to work - though I am unsure if it turned out faster than the ENH I posted - I don't think so.

hi guys

What I think that we should do is the following: You decide, collect, run the tests and once this is done you ping, publish the new package to be integrated in the inbox of the squeakfoundation and I integrated as the first new package of 3.10.

Now recently I was thinking that retrospectively it would have been better to keep a really small and limited core class (that the system only requires) and have separate and loadable time packages. I have the impression that aconcagua for example is circuventing some limits of Brent packages... So having packages that are not tied to the kernel would make their evolution/tests/maintenance easier. What do you think about that?

Stef

On 31 août 06, at 14:22, Brent Pinkney wrote:

Hi,

From the Mantis issue: I am nominally responsible for the Chronology package since I wrote it :)

I have tested and reviewed this change. All tests pass in 3.8.1 (6744).

I would also encourage this enhancement to include Dan Ingall's modificaton which significantly speeds up printing a DateAndTime instance.

All tests work with both enhancements. I have attached my cleanup of Dan's code to this issue.

 suite := TestSuite new name: 'Chronology Tests'.
 (SystemOrganization superclassOrder: #'Kernel-Chronology-Tests')
     do: [ :tc | tc addToSuiteFromSelectors: suite ].
 suite run.

RESULT: 420 run, 420 passes, 0 expected failures, 0 failures, 0 errors...

I strongly encourage both changesets to be approved.

---

---

...

It would be nice if someone could summarize all Time related classes and when to use which one. There is plenty of them these days.

I developed the Chronology class to precisely solve the problem of many Time classes. If you read the original wiki page (http://minnow.cc.gatech.edu/ squeak/1871) I refer to my experience with Java/J++ where there were 6 different class libraries to choose from.

I added the support for nano second precision precisely to future- proof the design.

...

For example, Date as you mention seems IMHO also like it still could be stored as a julian day number. A "Date beast" with duration etc seems like it probably could be called a Day instead.

Perhaps, but a Date definately starts at midnight and ends 86400 later. So it has a duration. I chose Date as Day implies the sun is shining :)

...

A Date does not in my mind represent a "specific historic period", but I am no expert of course.

If you are interested, the design came from my experience of off-by- one errors when manipluating the jail sentences (and other such) things in VisualAge for a certain South Pacific nation.

Hence, a given Date occupies all 86400 seconds it legally spans and can be used with the other Timespan classes to correctly calculate intersections, etc.

...

PS. We also use the Timezone stuff from David Lewis and that also ties into this using class PointInTime etc. Phew.

David developed his class in isolation - I only learnt of it when he announced it.

Much of the features he offers are related to time zones. The existing chronology package does support the basics of time zones with an eye to adding daylight saving later.

I did not add that as I live in a country with only one time zone and no daylight saving. There is no reason Dave's functionality could not be included.

Brent

On 31 août 06, at 14:42, Brent Pinkney wrote:

...

I have the impression that aconcagua for example is circuventing some limits of Brent packages...

May be you should read the paper of hernan that was published last year at ESUG.

Perhaps - no one informs me though.

...

So having packages that are not tied to the kernel would make their evolution/tests/maintenance easier. What do you think about that?

Nice in theory - hard in practice. The Date and Time classes are heavily used by the IDE to update the version history and changes files.

So it is hard to simply file-in a replacement package. My original chanset used all sorts of #become to file in the new classes and then swap over.

Brent in that scenario clients of a package just use BPDate or HernanDate but not the core ones. I was just thinking about that so this is not serious :). But this was going with some thoughts of what is a core? where do we stop?

Stef

Cheers

Hi!

Brent Pinkney brent.pinkney@aircom.co.za wrote:

Hi,

From the Mantis issue: I am nominally responsible for the Chronology package since I wrote it :)

Yup :)

I have tested and reviewed this change. All tests pass in 3.8.1 (6744).

I would also encourage this enhancement to include Dan Ingall's modificaton which significantly speeds up printing a DateAndTime instance.

All tests work with both enhancements. I have attached my cleanup of Dan's code to this issue.

 suite := TestSuite new name: 'Chronology Tests'.
 (SystemOrganization superclassOrder: #'Kernel-Chronology-Tests') 
     do: [ :tc | tc addToSuiteFromSelectors: suite ].
 suite run.

RESULT: 420 run, 420 passes, 0 expected failures, 0 failures, 0 errors...

I strongly encourage both changesets to be approved.

Cool! :) Even though the tests passes I might (not sure) have introduced some subtle problems when creating Durations using non integer arguments. I think my latest sweep of the code managed to get it right, but I am just hoisting a small warning flag.

---

...

It would be nice if someone could summarize all Time related classes and when to use which one. There is plenty of them these days.

I developed the Chronology class to precisely solve the problem of many Time classes. If you read the original wiki page (http://minnow.cc.gatech.edu/squeak/1871) I refer to my experience with Java/J++ where there were 6 different class libraries to choose from.

Ok, I read it and it explains quite a bit. We also have TimeStamp in the 3.8 image. It seems to me that TimeStamp (which has a Date and a Time) is a "duplication" of DateAndTime.

I added the support for nano second precision precisely to future-proof the design.

...

For example, Date as you mention seems IMHO also like it still could be stored as a julian day number. A "Date beast" with duration etc seems like it probably could be called a Day instead.

Perhaps, but a Date definately starts at midnight and ends 86400 later. So it has a duration. I chose Date as Day implies the sun is shining :)

Probably. It just seems odd to me (and to Bert) that it needs to contain all that it contains today. I mean, in *essence* it should be enough with the julian day number, right? Or what does the duration etc buy us in this case?

regards, Göran