Hi all,
I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
_________________________________________________________________ Download Messenger. Join the im Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07
Chronos: http://www.chronos-st.org/
Hernan Wilkinson escribió:
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, *J J* <azreal1977@hotmail.com mailto:azreal1977@hotmail.com> wrote:
Hi all, I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier. So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis? Thanks, Jason _________________________________________________________________ Download Messenger. Join the i'm Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07
Chronos is way ahead of Chalten in terms of functionality.
Philippe
2007/4/16, Hernan Wilkinson hernan.wilkinson@gmail.com:
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere?
Do
I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07
_________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
They are not maintained anymore, patches don't get integrated.
Philippe
2007/4/16, J J azreal1977@hotmail.com:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07
Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
Chronos also has a very interesting blog with lots of stuff, that you never wanted to know, but still have to know.
examples: http://chronos-st.blogspot.com/2006/12/chronos-101-points-in-time.html http://chronos-st.blogspot.com/2007/01/chronos-101-durational-values.html http://chronos-st.blogspot.com/2007/01/chronos-101-intervals-of-time.html
Philippe
2007/4/16, J J azreal1977@hotmail.com:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07
Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
J J wrote:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
Absolutely nothing, the squeak classes recently had a fairly comprehensive rewrite, and are still essentially a 1.0 release, it should be expected that some updates and improvements are desired. There is plenty of room for these base classes to evolve. For example I would also propose a split in the packaging of these classes so there can be an absolute minimum Kernel version for KernelImages as well as a fully featured version.
Goran also submitted a number of speed improvements to mantis, http://bugs.squeak.org/view.php?id=4669
cheers
Keith
Keith Hodges wrote:
J J wrote:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
Absolutely nothing, the squeak classes recently had a fairly comprehensive rewrite, and are still essentially a 1.0 release, it should be expected that some updates and improvements are desired. There is plenty of room for these base classes to evolve. For example I would also propose a split in the packaging of these classes so there can be an absolute minimum Kernel version for KernelImages as well as a fully featured version.
I have been experimenting with this idea recently and the bottom line is that all you *really* need is access to the millisecond clock primitive (for Delay and friends). Pretty much everything else can be built on top of that without access to more elaborate Date and Time classes. Moving #millisecondClockValue into, say, Delay would make a great starting point to rip out all of the Chronology classes for a minimal image.
Cheers, - Andreas
On 17 avr. 07, at 01:42, Andreas Raab wrote:
Keith Hodges wrote:
J J wrote:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
Absolutely nothing, the squeak classes recently had a fairly comprehensive rewrite, and are still essentially a 1.0 release, it should be expected that some updates and improvements are desired. There is plenty of room for these base classes to evolve. For example I would also propose a split in the packaging of these classes so there can be an absolute minimum Kernel version for KernelImages as well as a fully featured version.
I have been experimenting with this idea recently and the bottom line is that all you *really* need is access to the millisecond clock primitive (for Delay and friends). Pretty much everything else can be built on top of that without access to more elaborate Date and Time classes. Moving #millisecondClockValue into, say, Delay would make a great starting point to rip out all of the Chronology classes for a minimal image.
andreas don't you think that for the kernel having the old pre- chronology kernel is not sufficient (was it that big)? because there are a lot of things that could be removed from pavel images (at least this was my impression).
Cheers,
- Andreas
On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote:
Keith Hodges wrote:
J J wrote:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
Absolutely nothing, the squeak classes recently had a fairly comprehensive rewrite, and are still essentially a 1.0 release, it should be expected that some updates and improvements are desired. There is plenty of room for these base classes to evolve. For example I would also propose a split in the packaging of these classes so there can be an absolute minimum Kernel version for KernelImages as well as a fully featured version.
I have been experimenting with this idea recently and the bottom line is that all you *really* need is access to the millisecond clock primitive (for Delay and friends). Pretty much everything else can be built on top of that without access to more elaborate Date and Time classes. Moving #millisecondClockValue into, say, Delay would make a great starting point to rip out all of the Chronology classes for a minimal image.
This is true if and only if the millisecond clock is a monotonically increasing function. That is not the case for the Squeak VM, which presents a "local time" version of the clock. Thus for example durations that cross daylight savings time transitions are problematic. If we change to a millisecond clock that represents UTC time rather than local time, then you are absolutely right.
Dave
David T. Lewis wrote:
On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote:
I have been experimenting with this idea recently and the bottom line is that all you *really* need is access to the millisecond clock primitive (for Delay and friends). Pretty much everything else can be built on top of that without access to more elaborate Date and Time classes. Moving #millisecondClockValue into, say, Delay would make a great starting point to rip out all of the Chronology classes for a minimal image.
This is true if and only if the millisecond clock is a monotonically increasing function. That is not the case for the Squeak VM, which presents a "local time" version of the clock. Thus for example durations that cross daylight savings time transitions are problematic. If we change to a millisecond clock that represents UTC time rather than local time, then you are absolutely right.
I'm not getting your point. Why is having a monotonically increasing msecs clock a requirement? What I meant to say is that the only dependency I can't think to get rid of is the millisecond clock and only because it's tied so intrinsically to Delay which itself is tied intrinsically to Semaphore and Process. Which, even for a minimal image, you probably can't get rid of ;-) But it seems to me that whether the msecs clock is monotonically increasing or not is independent of that.
Cheers, - Andreas
On Tue, May 01, 2007 at 08:57:19PM -0700, Andreas Raab wrote:
David T. Lewis wrote:
On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote:
I have been experimenting with this idea recently and the bottom line is that all you *really* need is access to the millisecond clock primitive (for Delay and friends). Pretty much everything else can be built on top of that without access to more elaborate Date and Time classes. Moving #millisecondClockValue into, say, Delay would make a great starting point to rip out all of the Chronology classes for a minimal image.
This is true if and only if the millisecond clock is a monotonically increasing function. That is not the case for the Squeak VM, which presents a "local time" version of the clock. Thus for example durations that cross daylight savings time transitions are problematic. If we change to a millisecond clock that represents UTC time rather than local time, then you are absolutely right.
I'm not getting your point. Why is having a monotonically increasing msecs clock a requirement? What I meant to say is that the only dependency I can't think to get rid of is the millisecond clock and only because it's tied so intrinsically to Delay which itself is tied intrinsically to Semaphore and Process. Which, even for a minimal image, you probably can't get rid of ;-) But it seems to me that whether the msecs clock is monotonically increasing or not is independent of that.
You are absolutely right with regard to the dependencies. My only point is to clarify that the existing Squeak millisecond clock is not sufficient for getting the rest of it right. But as you say this is independent of your argument.
Alan Lovejoy gives a better explanation of the issue in his reply. It's important because, without a correct implementation, things like time durations can look like they are correct but in fact will not be right under certain circumstances. For example, if you schedule a ten minute delay beginning at 1:55am, and a Daylight Savings Time transition happens to occur five minutes later, the delay may not do what you intended.
FWIW, I had to deal with this when implementing TimeZoneDatabase. It is not trivial to figure out "DateAndTime now" based only on the information from the millisecond clock if the time happens to be two and a half hours after midnight on the day of a fall Daylight Savings Time transition. It can be solved, but you have to keep track of whether or not a DST transition has already occurred. The unit tests illustrate the problem and the (rather awkward) solution.
Dave
The real problem is that the millisecond clock overturns back to 0 isn't it? That and the fact there's no way to detect when it does. I didn't test it, but I'd be surprised if changing the computer clock has any effect on Time millisecondClockValue..
<Chris Muller> The real problem is that the millisecond clock overturns back to 0 isn't it? That and the fact there's no way to detect when it does. </Chris Muller>
The problem is the lack of an epoch to use as a well-known, absolute origin point on the time line. Clock rollover ("non-monotonicity") is inimical to having an absolute epoch. Best practice is to use some well-known moment in Universal Time--although using Universal Time for the system clock also requires the ability to convert between Universal Time and local time. Chronos, Windows, Symbian, REXX, and Rata Die all use midnight of 0001-01-01 (1 January 0001,) which is the natural epoch of the Gregorian calendar.
Given a system clock primitive that reports ticks since a well-known epoch, all else can be added as needed from dynamically loadable packages. The resolution of the system clock (the duration of one tick, which is also the minimum representable difference between two timepoints as reported by the clock**) can either be a well-known value, such as one microsecond, or else there can be yet another primitive that provides that information.
--Alan
** The precision of a clock is the minimum amount of difference between two timepoints that the clock is competent to measure (a functional characteristic of the clock hardware.) The resolution of a clock is the minimum representable difference between two timepoints that might be reported by the clock, which is determined by the semantics of the notation used to represent timepoints. The former is determined by physics, the latter by math/syntax.
After thinking a lot of the improving of squeak I have the impression that this would have been much better to have external packages that people use and enhance instead of having Chronology inside. Chronology could have also been such external package. This way the kernel of squeak could have been just what is needed to manage the internal of the system. This way we get something small and specific and clients can use packages that fits their specific needs. Now that Chronology is in squeak it is important to fix it if there are problems and inconsistencies. The best is to submit fixes with tests.
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
Absolutely nothing, the squeak classes recently had a fairly comprehensive rewrite, and are still essentially a 1.0 release, it should be expected that some updates and improvements are desired. There is plenty of room for these base classes to evolve. For example I would also propose a split in the packaging of these classes so there can be an absolute minimum Kernel version for KernelImages as well as a fully featured version.
Goran also submitted a number of speed improvements to mantis, http://bugs.squeak.org/view.php?id=4669
If this is good the harvesting team should harvest them.
Stef
cheers
Keith
Just to give you a fast review of what I remember (I developed the model that Maxi Taborda converted into Chalten): 1) Chronos supports many calendars, Chalten only the Gregorian Calendar 2) Chronos supports time zones, Chalten does not 3) Choros is huge (as you mentions), Chalten is more manageable (because it just model the Gregorian Calendar) 4) Chronos lacks some abstractions that Chalten has, like Day of Month and others (I don't remember now...there are a couple of mails that I and the guy that created Chronos wrote about these issues, like one year ago) 5) Chalten is based on a arithmetic model that allows you to represent time measurements easily (like 3 days, 5 months, etc). These objects are polymorphic with numbers respect to the arithmetic messages such as +, -, *, etc., that means that you can use them in arithmetic formulas 5) And of course, I like Chalten's model more that Chronos :-). For me it is easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that the Smalltalk date classes have and the advantages of having a better model. If you are interested on having better date and time classes, I recommend you to read the paper... you may not like it, but at least you will see other people ideas... We use that model (Chalten) in a production system and we believe it allowed us to avoid many common mistakes related to financial systems.... but hey, that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye, Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that
come
with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the
core
system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference
today.
Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
2007/4/17, Hernan Wilkinson hernan.wilkinson@gmail.com:
Just to give you a fast review of what I remember (I developed the model that Maxi Taborda converted into Chalten):
- Chronos supports many calendars, Chalten only the Gregorian Calendar
- Chronos supports time zones, Chalten does not
Additionally Chronos also supports nominal time and leap seconds.
- Choros is huge (as you mentions), Chalten is more manageable (because it
just model the Gregorian Calendar) 4) Chronos lacks some abstractions that Chalten has, like Day of Month and others (I don't remember now...there are a couple of mails that I and the guy that created Chronos wrote about these issues, like one year ago) 5) Chalten is based on a arithmetic model that allows you to represent time measurements easily (like 3 days, 5 months, etc).
That won't work in Squeak because these methods are already by the Squeak Chronology (unless you have classboxes). It might work in VW though.
These objects are polymorphic with numbers respect to the arithmetic messages such as +, -, *, etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
- And of course, I like Chalten's model more that Chronos :-). For me it is
easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that the Smalltalk date classes have and the advantages of having a better model. If you are interested on having better date and time classes, I recommend you to read the paper... you may not like it, but at least you will see other people ideas... We use that model (Chalten) in a production system and we believe it allowed us to avoid many common mistakes related to financial systems.... but hey, that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess with shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten,
but
what is wrong with a few upgrades to the classes that come with Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers list< squeak-dev@lists.squeakfoundation.org> To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that
come
with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the
core
system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference
today.
Get a FREE Web site, company branded e-mail and more from Microsoft Office Live!
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
Additionally Chronos also supports nominal time and leap seconds.
Maxi Taborda is enhancing Chalten adding that functionality... but is going to take some time :-) ...
- Chalten is based on a arithmetic model that allows you to represent
time
measurements easily (like 3 days, 5 months, etc).
That won't work in Squeak because these methods are already by the Squeak Chronology (unless you have classboxes). It might work in VW though.
It works on Squeak, VW, VisualAge, Dolphin and GemStone that are the Smalltalk were Chalten has been migrated to. Look at Aconcagua, the model that takes care of this.
These objects are
polymorphic with numbers respect to the arithmetic messages such as +,
-, *,
etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important for us... for us it is also important the way you "write" these things... for example, with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if you create meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the time domain but used in other domains... that is way for us it is important to support this type of behavior and in a DSL way...
Bye, Hernan.
- And of course, I like Chalten's model more that Chronos :-). For me it
is
easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that the
Smalltalk
date classes have and the advantages of having a better model. If you
are
interested on having better date and time classes, I recommend you to
read
the paper... you may not like it, but at least you will see other people ideas... We use that model (Chalten) in a production system and we believe it
allowed
us to avoid many common mistakes related to financial systems.... but
hey,
that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess with shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
I have looked at Cronos but it is really huge, and the classes that
come
with the image are already very close. I will have to look at
Chalten,
but
what is wrong with a few upgrades to the classes that come with
Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers list< squeak-dev@lists.squeakfoundation.org> To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos
too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that
come
with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here
and
there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the
core
system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference
today.
Get a FREE Web site, company branded e-mail and more from Microsoft
Office
Live!
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
2007/4/17, Hernan Wilkinson hernan.wilkinson@gmail.com:
Additionally Chronos also supports nominal time and leap seconds.
Maxi Taborda is enhancing Chalten adding that functionality... but is going to take some time :-) ...
- Chalten is based on a arithmetic model that allows you to represent
time
measurements easily (like 3 days, 5 months, etc).
That won't work in Squeak because these methods are already by the Squeak Chronology (unless you have classboxes). It might work in VW though.
It works on Squeak, VW, VisualAge, Dolphin and GemStone that are the Smalltalk were Chalten has been migrated to. Look at Aconcagua, the model that takes care of this.
I loaded Aconcagua-mx.1.6 and Chalten-mx.1.3 in Squeak 3.9. The following all give errors:
GregorianDay today + 1 day GregorianDateTime now + 1 day GregorianDay today next: 5 GregorianYear current + 1 year 5 months
I guess I have to thank you. After hearing what a piece of shit Seaside is because of its lack of documentation it's relieving to see a framework with no class comments at all. A quick browsing through same classes showed also no method comments.
Cheers Philippe
These objects are polymorphic with numbers respect to the arithmetic messages such as +,
-, *,
etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important for us... for us it is also important the way you "write" these things... for example, with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if you create meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the time domain but used in other domains... that is way for us it is important to support this type of behavior and in a DSL way...
Bye, Hernan.
- And of course, I like Chalten's model more that Chronos :-). For me
it is
easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that the
Smalltalk
date classes have and the advantages of having a better model. If you
are
interested on having better date and time classes, I recommend you to
read
the paper... you may not like it, but at least you will see other people ideas... We use that model (Chalten) in a production system and we believe it
allowed
us to avoid many common mistakes related to financial systems.... but
hey,
that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess with shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
I have looked at Cronos but it is really huge, and the classes that
come
with the image are already very close. I will have to look at
Chalten,
but
what is wrong with a few upgrades to the classes that come with
Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers list< squeak-dev@lists.squeakfoundation.org> To: "The general-purpose Squeak developers list"< squeak-dev@lists.squeakfoundation.org> Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos
too.
Hernan.
On 4/16/07, J J < azreal1977@hotmail.com> wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that
come
with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here
and
there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the
core
system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference
today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
Get a FREE Web site, company branded e-mail and more from Microsoft
Office
Live!
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
I loaded Aconcagua-mx.1.6 and Chalten-mx.1.3 in Squeak 3.9. The following all give errors:
GregorianDay today + 1 day GregorianDateTime now + 1 day GregorianDay today next: 5 GregorianYear current + 1 year 5 months
I guess I have to thank you. After hearing what a piece of shit
Seaside is because of its lack of documentation it's relieving to see a framework with no class comments at all. A quick browsing through same classes showed also no method comments.
jaja, it seems to me that you did not look good enough.... just look at the Test!!! They are all the documentation you need! and more!! real examples, live code! not just documentation.... We defenetly use different development techniques... Also, remember the paper! Links: http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A%20New%20... http://prog2.vub.ac.be/~cderoove/esugtalks/Wilkinson.pdf (ESUG Presentation)
About the code you tried: 1) GregorianDay today + 1 day -> It will not work becuase a date is not polymorphic with numbers. You have to do: "GregorianDate today next" or "GregorianDate today next: 1 * day" Remember the *, that allows you to create measures easily
2) GregorianDateTime now + 1 day ---> Same as 1)
3) GregorianDay today next: 5 --> It will not work because 5 is not a measure of time, it is just a number. Try "GregorianDay today next: 5 * day" 5 * day is a measure of time
4) GregorianYear current + 1 year --> Same as 1) but using a measure expressed in year, for example "2 * year" 5) 5 months --> Measure are created in many ways. We decided not to clutter the number protocol with each unit you could have... because measures are arithmetic representations of a number times its unit, the right way to create them is using the arithmetic operator * (See our paper about Aconcagua. Link: http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CF...)
Hope this help. Hernan.
Cheers
Philippe
These objects are polymorphic with numbers respect to the arithmetic messages such as
+,
-, *,
etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important for us...
for
us it is also important the way you "write" these things... for example, with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if you
create
meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the time
domain
but used in other domains... that is way for us it is important to
support
this type of behavior and in a DSL way...
Bye, Hernan.
- And of course, I like Chalten's model more that Chronos :-). For
me
it is
easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that the
Smalltalk
date classes have and the advantages of having a better model. If
you
are
interested on having better date and time classes, I recommend you
to
read
the paper... you may not like it, but at least you will see other
people
ideas... We use that model (Chalten) in a production system and we believe it
allowed
us to avoid many common mistakes related to financial systems....
but
hey,
that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess with shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
I have looked at Cronos but it is really huge, and the classes
that
come
with the image are already very close. I will have to look at
Chalten,
but
what is wrong with a few upgrades to the classes that come with
Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers list< squeak-dev@lists.squeakfoundation.org> To: "The general-purpose Squeak developers list"< squeak-dev@lists.squeakfoundation.org> Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look
at
"Chalten" or "Cronos". Chalten is in SqueakSource.... I think
Cronos
too.
Hernan.
On 4/16/07, J J < azreal1977@hotmail.com> wrote: > >Hi all, > >I am doing some stuff with dates and I noticed the date classes
that
come
>with the default Squeak image are very nice and very close to
having
>everything I would want. But there are a few inconsistencies
here
and
>there, and things missing that would make things easier. > >So what is the procedure to updating this? I think it's part of
the
core
>system so I probably can't just do a monicello package update >somewhere? Do >I have to do it through mantis? > >Thanks, >Jason >
>Download Messenger. Join the i'm Initiative. Help make a
difference
today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
> > >
Get a FREE Web site, company branded e-mail and more from
Microsoft
Office
Live!
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
2007/4/17, Hernan Wilkinson hernan.wilkinson@gmail.com:
I loaded Aconcagua-mx.1.6 and Chalten-mx.1.3 in Squeak 3.9. The following all give errors:
GregorianDay today + 1 day GregorianDateTime now + 1 day GregorianDay today next: 5 GregorianYear current + 1 year 5 months
I guess I have to thank you. After hearing what a piece of shit Seaside is because of its lack of documentation it's relieving to see a framework with no class comments at all. A quick browsing through same classes showed also no method comments.
jaja, it seems to me that you did not look good enough.... just look at the Test!!! They are all the documentation you need! and more!! real examples, live code! not just documentation.... We defenetly use different development techniques... Also, remember the paper! Links: http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A%20New%20... http://prog2.vub.ac.be/~cderoove/esugtalks/Wilkinson.pdf (ESUG Presentation)
That exists for Seaside too (plus blogs, screen casts, real applications using it, ...), didn't count for nothing.
About the code you tried:
- GregorianDay today + 1 day -> It will not work becuase a date is not
polymorphic with numbers.
Why? This works fine with Chronos. I find it quite handy to compute the difference between two points in time by sending #-. Or being able to add a duration to a timepoint by sending #+. Yeah the type signatures are different than for standard arithmetic but still.
You have to do: "GregorianDate today next" or "GregorianDate today next: 1 * day" Remember the *, that allows you to create measures easily
GregorianDateTime now + 1 day ---> Same as 1)
GregorianDay today next: 5 --> It will not work because 5 is not a
measure of time, it is just a number. Try "GregorianDay today next: 5 * day" 5 * day is a measure of time
Maybe then the suggested type should be aMeasure and not aNumberOfDays
- GregorianYear current + 1 year --> Same as 1) but using a measure
expressed in year, for example "2 * year" 5) 5 months --> Measure are created in many ways. We decided not to clutter the number protocol with each unit you could have... because measures are arithmetic representations of a number times its unit, the right way to create them is using the arithmetic operator * (See our paper about Aconcagua. Link:
All good and fine, however the code you posted in this thread suggests differently. And there is still the question where year comes from (please no shared pool).
Cheers Philippe
http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CF... )
Hope this help. Hernan.
Cheers Philippe
These objects are polymorphic with numbers respect to the arithmetic messages such as
+,
-, *,
etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important for us...
for
us it is also important the way you "write" these things... for example, with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if you
create
meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the time
domain
but used in other domains... that is way for us it is important to
support
this type of behavior and in a DSL way...
Bye, Hernan.
- And of course, I like Chalten's model more that Chronos :-). For
me
it is
easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that the
Smalltalk
date classes have and the advantages of having a better model. If
you
are
interested on having better date and time classes, I recommend you
to
read
the paper... you may not like it, but at least you will see other
people
ideas... We use that model (Chalten) in a production system and we believe it
allowed
us to avoid many common mistakes related to financial systems....
but
hey,
that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess with shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
Hernan.
On 4/16/07, J J <azreal1977@hotmail.com > wrote:
I have looked at Cronos but it is really huge, and the classes
that
come
with the image are already very close. I will have to look at
Chalten,
but
what is wrong with a few upgrades to the classes that come with
Squeak?
>From: "Hernan Wilkinson" < hernan.wilkinson@gmail.com> >Reply-To: The general-purpose Squeak developers >list< squeak-dev@lists.squeakfoundation.org > >To: "The general-purpose Squeak developers >list"< squeak-dev@lists.squeakfoundation.org > >Subject: Re: Date classes >Date: Mon, 16 Apr 2007 14:28:09 -0300 > >Before doing something with Date, I recommend you to take a look
at
>"Chalten" or "Cronos". Chalten is in SqueakSource.... I think
Cronos
too.
> >Hernan. > >On 4/16/07, J J < azreal1977@hotmail.com> wrote: >> >>Hi all, >> >>I am doing some stuff with dates and I noticed the date classes
that
come
>>with the default Squeak image are very nice and very close to
having
>>everything I would want. But there are a few inconsistencies
here
and
>>there, and things missing that would make things easier. >> >>So what is the procedure to updating this? I think it's part of
the
core
>>system so I probably can't just do a monicello package update >>somewhere? Do >>I have to do it through mantis? >> >>Thanks, >>Jason >>
>>Download Messenger. Join the i'm Initiative. Help make a
difference
today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
>> >> >>
>
Get a FREE Web site, company branded e-mail and more from
Microsoft
Office
Live!
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
About the code you tried:
- GregorianDay today + 1 day -> It will not work becuase a date is not
polymorphic with numbers.
Why? This works fine with Chronos. I find it quite handy to compute the difference between two points in time by sending #-. Or being able to add a duration to a timepoint by sending #+. Yeah the type signatures are different than for standard arithmetic but still.
I may sound repetitive, but everything is explained in the paper. Because of the metaphor we used to create de model (points in a line, the time-line) the messages #next:, #distanceTo:, etc. are better.
You have to do: "GregorianDate today next" or
"GregorianDate today next: 1 * day" Remember the *, that allows you to create measures easily
GregorianDateTime now + 1 day ---> Same as 1)
GregorianDay today next: 5 --> It will not work because 5 is not a
measure of time, it is just a number. Try "GregorianDay today next: 5 * day" 5 * day is a measure of time
Maybe then the suggested type should be aMeasure and not aNumberOfDays
Maybe... or maybe it should be aMeasureOfTime... I think that sounds better.
- GregorianYear current + 1 year --> Same as 1) but using a measure
expressed in year, for example "2 * year" 5) 5 months --> Measure are created in many ways. We decided not to
clutter
the number protocol with each unit you could have... because measures
are
arithmetic representations of a number times its unit, the right way to create them is using the arithmetic operator * (See our paper about Aconcagua. Link:
All good and fine, however the code you posted in this thread suggests differently.
I don't understand what you mean...
And there is still the question where year comes from
(please no shared pool).
I did not see that question, but the answer is No. The variable "year" is global. The same as month, day, January, February, Monday, etc. Maybe you will not like it, but I think that the time domain is so important in writing software as the arithmetic domain, so if numbers are global (1, 2, 3, etc) why not the time objects? They are well know entities of the real life....
Bye, Hernan.
Cheers
Philippe
http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CF...
)
Hope this help. Hernan.
Cheers Philippe
These objects are polymorphic with numbers respect to the arithmetic messages such
as
+,
-, *,
etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important for
us...
for
us it is also important the way you "write" these things... for
example,
with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if you
create
meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the time
domain
but used in other domains... that is way for us it is important to
support
this type of behavior and in a DSL way...
Bye, Hernan.
- And of course, I like Chalten's model more that Chronos :-).
For
me
it is
easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that
the
Smalltalk
date classes have and the advantages of having a better model.
If
you
are
interested on having better date and time classes, I recommend
you
to
read
the paper... you may not like it, but at least you will see
other
people
ideas... We use that model (Chalten) in a production system and we
believe it
allowed
us to avoid many common mistakes related to financial
systems....
but
hey,
that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess
with
shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
Hernan.
On 4/16/07, J J <azreal1977@hotmail.com > wrote: > I have looked at Cronos but it is really huge, and the classes
that
come
> with the image are already very close. I will have to look at
Chalten,
but > what is wrong with a few upgrades to the classes that come
with
Squeak?
> > >From: "Hernan Wilkinson" < hernan.wilkinson@gmail.com> > >Reply-To: The general-purpose Squeak developers > >list< squeak-dev@lists.squeakfoundation.org > > >To: "The general-purpose Squeak developers > >list"< squeak-dev@lists.squeakfoundation.org > > >Subject: Re: Date classes > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > >Before doing something with Date, I recommend you to take a
look
at
> >"Chalten" or "Cronos". Chalten is in SqueakSource.... I think
Cronos
too.
> > > >Hernan. > > > >On 4/16/07, J J < azreal1977@hotmail.com> wrote: > >> > >>Hi all, > >> > >>I am doing some stuff with dates and I noticed the date
classes
that
come > >>with the default Squeak image are very nice and very close
to
having
> >>everything I would want. But there are a few
inconsistencies
here
and
> >>there, and things missing that would make things easier. > >> > >>So what is the procedure to updating this? I think it's
part of
the
core > >>system so I probably can't just do a monicello package
update
> >>somewhere? Do > >>I have to do it through mantis? > >> > >>Thanks, > >>Jason > >> >
> >>Download Messenger. Join the i'm Initiative. Help make a
difference
today. >
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
> >> > >> > >> > > > > > >
> Get a FREE Web site, company branded e-mail and more from
Microsoft
Office
> Live!
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> > >
2007/4/17, Hernan Wilkinson hernan.wilkinson@gmail.com:
About the code you tried:
- GregorianDay today + 1 day -> It will not work becuase a date is not
polymorphic with numbers.
Why? This works fine with Chronos. I find it quite handy to compute the difference between two points in time by sending #-. Or being able to add a duration to a timepoint by sending #+. Yeah the type signatures are different than for standard arithmetic but still.
I may sound repetitive, but everything is explained in the paper. Because of the metaphor we used to create de model (points in a line, the time-line) the messages #next:, #distanceTo:, etc. are better.
You have to do: "GregorianDate today next" or "GregorianDate today next: 1 * day" Remember the *, that allows you to create measures easily
GregorianDateTime now + 1 day ---> Same as 1)
GregorianDay today next: 5 --> It will not work because 5 is not a
measure of time, it is just a number. Try "GregorianDay today next: 5 * day" 5 * day is a measure of time
Maybe then the suggested type should be aMeasure and not aNumberOfDays
Maybe... or maybe it should be aMeasureOfTime... I think that sounds better.
- GregorianYear current + 1 year --> Same as 1) but using a measure
expressed in year, for example "2 * year" 5) 5 months --> Measure are created in many ways. We decided not to
clutter
the number protocol with each unit you could have... because measures
are
arithmetic representations of a number times its unit, the right way to create them is using the arithmetic operator * (See our paper about Aconcagua. Link:
All good and fine, however the code you posted in this thread suggests differently.
I don't understand what you mean...
You said:
- Chalten is based on a arithmetic model that allows you to represent time measurements easily (like 3 days, 5 months, etc)
So I assumed you meant we could write 5 months just the same way we could write 100 dollars like the examples in the paper show.
And there is still the question where year comes from (please no shared pool).
I did not see that question, but the answer is No. The variable "year" is global. The same as month, day, January, February, Monday, etc. Maybe you will not like it,
Global state sucks, no matter how well intended. I haven't tested it but I wouldn't be surprised if it causes problems with Monticello.
but I think that the time domain is so important in writing software as the arithmetic domain,
I think time sucks as a domain. Days that don't have 24 hours, minutes that don't have 60 seconds, years that don't have 365 days, different calendars, timezones, points in time with timezones and without timezones, timezones with more than two DST changes, different week start days, .... For every rule there's an exception and these can change at basically any time. Seriously, how much worse can it get?
so if numbers are global (1, 2, 3, etc) why not the time objects? They are well know entities of the real life....
Numbers are literals not global variables.
Cheers Philippe
Bye, Hernan.
Cheers Philippe
http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CF...
)
Hope this help. Hernan.
Cheers Philippe
> These objects are > polymorphic with numbers respect to the arithmetic messages such
as
+,
-, *,
> etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important for
us...
for
us it is also important the way you "write" these things... for
example,
with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if you
create
meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the time
domain
but used in other domains... that is way for us it is important to
support
this type of behavior and in a DSL way...
Bye, Hernan.
> 5) And of course, I like Chalten's model more that Chronos :-).
For
me
it is
> easier to use, but this is just a matter of taste... > > There is a paper we wrote 2 years ago about the problems that
the
Smalltalk
> date classes have and the advantages of having a better model.
If
you
are
> interested on having better date and time classes, I recommend
you
to
read
> the paper... you may not like it, but at least you will see
other
people
> ideas... > We use that model (Chalten) in a production system and we
believe it
allowed
> us to avoid many common mistakes related to financial
systems....
but
hey,
> that's just a feeling, nothing I can prove formally. > > I hope you can do something useful. > Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess
with
shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
> Hernan. > > > On 4/16/07, J J <azreal1977@hotmail.com > wrote: > > I have looked at Cronos but it is really huge, and the classes
that
come
> > with the image are already very close. I will have to look at
Chalten,
> but > > what is wrong with a few upgrades to the classes that come
with
Squeak?
> > > > >From: "Hernan Wilkinson" < hernan.wilkinson@gmail.com> > > >Reply-To: The general-purpose Squeak developers > > >list< squeak-dev@lists.squeakfoundation.org
> > >To: "The general-purpose Squeak developers > > >list"< squeak-dev@lists.squeakfoundation.org
> > >Subject: Re: Date classes > > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > > > >Before doing something with Date, I recommend you to take a
look
at
> > >"Chalten" or "Cronos". Chalten is in SqueakSource.... I think
Cronos
too.
> > > > > >Hernan. > > > > > >On 4/16/07, J J < azreal1977@hotmail.com> wrote: > > >> > > >>Hi all, > > >> > > >>I am doing some stuff with dates and I noticed the date
classes
that
> come > > >>with the default Squeak image are very nice and very close
to
having
> > >>everything I would want. But there are a few
inconsistencies
here
and
> > >>there, and things missing that would make things easier. > > >> > > >>So what is the procedure to updating this? I think it's
part of
the
> core > > >>system so I probably can't just do a monicello package
update
> > >>somewhere? Do > > >>I have to do it through mantis? > > >> > > >>Thanks, > > >>Jason > > >> > > >
> > >>Download Messenger. Join the i'm Initiative. Help make a
difference
> today. > > >
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
> > >> > > >> > > >> > > > > > > > > > > > >
> > Get a FREE Web site, company branded e-mail and more from
Microsoft
Office
> > Live! >
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> > > > > > > > > > >
On 4/17/07, Philippe Marschall philippe.marschall@gmail.com wrote:
You said:
- Chalten is based on a arithmetic model that allows you to represent
time measurements easily (like 3 days, 5 months, etc)
So I assumed you meant we could write 5 months just the same way we could write 100 dollars like the examples in the paper show.
No "5 months" but "5 * months" or "moth with: 5". Same for "dollars", "euros", "meters", "liters", "A", "B", etc. That is why I think that measure was not a good word to define this objects... 5*A is not a measure.. what we implemented is really an algebra, maybe a limited one, but an algebra at the end.
And there is still the question where year comes from
(please no shared pool).
I did not see that question, but the answer is No. The variable "year"
is
global. The same as month, day, January, February, Monday, etc. Maybe
you
will not like it,
Global state sucks, no matter how well intended. I haven't tested it but I wouldn't be surprised if it causes problems with Monticello.
Well, I do not agree... I used to think like that but I've changed my mind... Object should be global if the entity they represent in real life is global... but I understand that you don't like them.
From an Software Engineering point of view, global variables are not good...
but if you think software development as a learning process and you see the Smalltalk image as the "state" of your knowledge about a specific domain(s), having global objects (well know objects) is not bad....
but I think that the time domain is so important in
writing software as the arithmetic domain,
I think time sucks as a domain. Days that don't have 24 hours, minutes that don't have 60 seconds, years that don't have 365 days, different calendars, timezones, points in time with timezones and without timezones, timezones with more than two DST changes, different week start days, .... For every rule there's an exception and these can change at basically any time. Seriously, how much worse can it get?
I believe it is a really interesting domain!! because of the things you mention! because the exceptions it has makes it a very interesting and challenging problem to design.
so if numbers are global (1, 2, 3, etc) why not the time objects? They are well know entities of the
real
life....
Numbers are literals not global variables.
Well... that's an implementation detail... at the end they are global. They are not "global variables" but "global objects" because the parser knows about them.... so, at the end, they are global. And I think it is ok for them to be global because it is almost impossible to think about a programming language without numbers.... when we get a programming language we are expecting to have at least the math to be model with it... (a programming language without numbers as primitives is a very challenging idea... I don't know if it is feasible...)
Anyhow, I think that when your knowledge about a problem domain (Smalltalk image) is mature, you will end up with some global objects... We develop financial software and I have to tell you that having "dollar", "euro", etc. as global objects would help us a lot... for example no need to declare them on each unit test (of course we use test resources, but still), no need for the final user to define them (they expect dollar, euro, peso, etc. as part of the "kit")...
Bye, Hernan.
Cheers
Philippe
Bye, Hernan.
Cheers Philippe
http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CF...
)
Hope this help. Hernan.
Cheers Philippe
> > These objects are > > polymorphic with numbers respect to the arithmetic messages
such
as
+,
-, *, > > etc., that means that you can use them in arithmetic
formulas
> > That's true to a certain extent in Chronos for example you
can:
> Timepoint now - (CalendarDuration months: 1) > (CalendarDuration months: 1) * 5 > but you can't: > 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important
for
us...
for
us it is also important the way you "write" these things... for
example,
with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if
you
create
meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the
time
domain
but used in other domains... that is way for us it is important
to
support
this type of behavior and in a DSL way...
Bye, Hernan.
> > 5) And of course, I like Chalten's model more that Chronos
:-).
For
me
it is > > easier to use, but this is just a matter of taste... > > > > There is a paper we wrote 2 years ago about the problems
that
the
Smalltalk > > date classes have and the advantages of having a better
model.
If
you
are > > interested on having better date and time classes, I
recommend
you
to
read > > the paper... you may not like it, but at least you will see
other
people
> > ideas... > > We use that model (Chalten) in a production system and we
believe it
allowed > > us to avoid many common mistakes related to financial
systems....
but
hey, > > that's just a feeling, nothing I can prove formally. > > > > I hope you can do something useful. > > Bye, > > Chronos is a bit ugly in Squeak because Squeak does not
support
> namespaces which means that classes that model the same
concept as
> Squeak Chronology classes have different names (unless you
mess
with
> shared pools). Also loading it is a bit of a pain with
Monticello
> (this is the fault of Monticello and not Chronos). > > Cheers > Philippe > > > Hernan. > > > > > > On 4/16/07, J J <azreal1977@hotmail.com > wrote: > > > I have looked at Cronos but it is really huge, and the
classes
that
come > > > with the image are already very close. I will have to
look at
Chalten, > > but > > > what is wrong with a few upgrades to the classes that come
with
Squeak? > > > > > > >From: "Hernan Wilkinson" < hernan.wilkinson@gmail.com> > > > >Reply-To: The general-purpose Squeak developers > > > >list< squeak-dev@lists.squeakfoundation.org
> > > >To: "The general-purpose Squeak developers > > > >list"< squeak-dev@lists.squeakfoundation.org
> > > >Subject: Re: Date classes > > > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > > > > > >Before doing something with Date, I recommend you to take
a
look
at
> > > >"Chalten" or "Cronos". Chalten is in SqueakSource.... I
think
Cronos
too. > > > > > > > >Hernan. > > > > > > > >On 4/16/07, J J < azreal1977@hotmail.com> wrote: > > > >> > > > >>Hi all, > > > >> > > > >>I am doing some stuff with dates and I noticed the date
classes
that
> > come > > > >>with the default Squeak image are very nice and very
close
to
having
> > > >>everything I would want. But there are a few
inconsistencies
here
and > > > >>there, and things missing that would make things easier. > > > >> > > > >>So what is the procedure to updating this? I think it's
part of
the
> > core > > > >>system so I probably can't just do a monicello package
update
> > > >>somewhere? Do > > > >>I have to do it through mantis? > > > >> > > > >>Thanks, > > > >>Jason > > > >> > > > > >
> > > >>Download Messenger. Join the i'm Initiative. Help make a
difference
> > today. > > > > >
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
> > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > >
> > > Get a FREE Web site, company branded e-mail and more from
Microsoft
Office > > > Live! > >
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> > > > > > > > > > > > > > > > > > > > >
2007/4/17, Hernan Wilkinson hernan.wilkinson@gmail.com:
On 4/17/07, Philippe Marschall philippe.marschall@gmail.com wrote:
You said:
- Chalten is based on a arithmetic model that allows you to represent
time measurements easily (like 3 days, 5 months, etc)
So I assumed you meant we could write 5 months just the same way we could write 100 dollars like the examples in the paper show.
No "5 months" but "5 * months" or "moth with: 5". Same for "dollars", "euros", "meters", "liters", "A", "B", etc. That is why I think that measure was not a good word to define this objects... 5*A is not a measure.. what we implemented is really an algebra, maybe a limited one, but an algebra at the end.
Maybe I'm just seeing things: http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A%20New%20... page 7, figure 11: 14 days + 1 week = 1814400000 milliseconds. "Adding measurements of the same base unit" ((14 days + 1 week) convertTo: days) = 21 days. "Converting the result of an operation" (1 year + 10 days) = (1 year + 10 days) "Adding measurements of different base unit" 10 years * 10 = 100 years "Multiplying a measurement by a number" 10 years * 12 months = 10 year*year "Multiplying measurements" 10 years * 12 months / 24 months = 5 years "The model automatically simplifies units" 100 kilometers / 1 hour "Represents a speed of 100 km per hour" 0.01 / 1 month "Represent an interest rate of 10 % by month"
page 8, figure 12: (GregorianYear number: 2005) next: 1 year "Returns GregorianYear number: 2006" (GregorianYear number: 2005) next: 12 months "Returns GregorianYear number: 2006" (GregorianYear number: 2005) next: 10 years "Returns GregorianYear number: 2015" (GregorianYear number: 2005) previous: 5 years "Returns GregorianYear number: 2000"
page 8, figure 13: (GregorianYear number: 2005) next: 120 days "Signals an exception because 120 days can not be converted to years" '01/2005' asGregorianMonthOfYear next: 120 days "Signals an exception because 120 days can not be converted to months"
page 8, figure 14: GregorianDay monday next: 4 days "Returns Friday" GregorianMonth january next: 2 months "Returns March" (GregorianMonth january dayNumber: 1) next: 2 days "Returns January 3rd "
page 8, figure 17: "Returns an Interval with six elements, the years 2005,2007,2009,2011,2013 and 2015 inclusive". (GregorianYear number: 2005) to: (GregorianYear number: 2015) by: 2 years "Returns an Interval with six elements, the years 2005,2004,2003,2002,2001 and 2000 inclusive". (GregorianYear number: 2005) to: (GregorianYear number: 2000) by: -1 year
page 10, figure 22: "06/01/2005 is a Thursday" aTimespan := Timespan from: '06/01/2005' asGregorianDate duration: 48 hours.
And there is still the question where year comes from (please no shared pool).
I did not see that question, but the answer is No. The variable "year"
is
global. The same as month, day, January, February, Monday, etc. Maybe
you
will not like it,
Global state sucks, no matter how well intended. I haven't tested it but I wouldn't be surprised if it causes problems with Monticello.
Well, I do not agree... I used to think like that but I've changed my mind... Object should be global if the entity they represent in real life is global... but I understand that you don't like them. From an Software Engineering point of view, global variables are not good... but if you think software development as a learning process and you see the Smalltalk image as the "state" of your knowledge about a specific domain(s), having global objects (well know objects) is not bad....
but I think that the time domain is so important in writing software as the arithmetic domain,
I think time sucks as a domain. Days that don't have 24 hours, minutes that don't have 60 seconds, years that don't have 365 days, different calendars, timezones, points in time with timezones and without timezones, timezones with more than two DST changes, different week start days, .... For every rule there's an exception and these can change at basically any time. Seriously, how much worse can it get?
I believe it is a really interesting domain!! because of the things you mention! because the exceptions it has makes it a very interesting and challenging problem to design.
Well, yeah. I just don't see how Chalten addresses many of these. Eg. it assumes days have 24 hours and minutes have 60 seconds.
so if numbers are global (1, 2, 3, etc) why not the time objects? They are well know entities of the
real
life....
Numbers are literals not global variables.
Well... that's an implementation detail... at the end they are global. They are not "global variables" but "global objects" because the parser knows about them.... so, at the end, they are global. And I think it is ok for them to be global because it is almost impossible to think about a programming language without numbers.... when we get a programming language we are expecting to have at least the math to be model with it... (a programming language without numbers as primitives is a very challenging idea... I don't know if it is feasible...)
I don't agree because they don't have the semantics of globals like identify (for everything but SmallIntegers). The compiler/parser knows about them, that's all. But that certainly depends of POV.
Anyhow, I think that when your knowledge about a problem domain (Smalltalk image) is mature, you will end up with some global objects... We develop financial software and I have to tell you that having "dollar", "euro", etc. as global objects would help us a lot... for example no need to declare them on each unit test (of course we use test resources, but still), no need for the final user to define them (they expect dollar, euro, peso, etc. as part of the "kit")...
Why don't you have them as global objects then?
Cheers Philippe
Bye, Hernan.
Cheers Philippe
Bye, Hernan.
Cheers Philippe
http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CF...
)
Hope this help. Hernan.
Cheers Philippe
> > > These objects are > > > polymorphic with numbers respect to the arithmetic messages
such
as
+,
> -, *, > > > etc., that means that you can use them in arithmetic
formulas
> > > > That's true to a certain extent in Chronos for example you
can:
> > Timepoint now - (CalendarDuration months: 1) > > (CalendarDuration months: 1) * 5 > > but you can't: > > 5 * (CalendarDuration months: 1) > > Ok, but it is not only the functionality what it is important
for
us...
for
> us it is also important the way you "write" these things... for
example,
> with Chalten/Aconcagua you can write: > > 5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) > 5 * meter / (second * second) --> A measure of acceleration if
you
create
> meter as a unit using Aconcagua > 1/10 * year --> Represents an interest rate of 10% yearly. > > As you can see, time measure are not only related only to the
time
domain
> but used in other domains... that is way for us it is important
to
support
> this type of behavior and in a DSL way... > > Bye, > Hernan. > > > > 5) And of course, I like Chalten's model more that Chronos
:-).
For
me
> it is > > > easier to use, but this is just a matter of taste... > > > > > > There is a paper we wrote 2 years ago about the problems
that
the
> Smalltalk > > > date classes have and the advantages of having a better
model.
If
you
> are > > > interested on having better date and time classes, I
recommend
you
to
> read > > > the paper... you may not like it, but at least you will see
other
people
> > > ideas... > > > We use that model (Chalten) in a production system and we
believe it
> allowed > > > us to avoid many common mistakes related to financial
systems....
but
> hey, > > > that's just a feeling, nothing I can prove formally. > > > > > > I hope you can do something useful. > > > Bye, > > > > Chronos is a bit ugly in Squeak because Squeak does not
support
> > namespaces which means that classes that model the same
concept as
> > Squeak Chronology classes have different names (unless you
mess
with
> > shared pools). Also loading it is a bit of a pain with
Monticello
> > (this is the fault of Monticello and not Chronos). > > > > Cheers > > Philippe > > > > > Hernan. > > > > > > > > > On 4/16/07, J J <azreal1977@hotmail.com > wrote: > > > > I have looked at Cronos but it is really huge, and the
classes
that
> come > > > > with the image are already very close. I will have to
look at
> Chalten, > > > but > > > > what is wrong with a few upgrades to the classes that come
with
> Squeak? > > > > > > > > >From: "Hernan Wilkinson" < hernan.wilkinson@gmail.com> > > > > >Reply-To: The general-purpose Squeak developers > > > > >list<
squeak-dev@lists.squeakfoundation.org
> > > > >To: "The general-purpose Squeak developers > > > > >list"<
squeak-dev@lists.squeakfoundation.org
> > > > >Subject: Re: Date classes > > > > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > > > > > > > >Before doing something with Date, I recommend you to take
a
look
at
> > > > >"Chalten" or "Cronos". Chalten is in SqueakSource.... I
think
Cronos
> too. > > > > > > > > > >Hernan. > > > > > > > > > >On 4/16/07, J J < azreal1977@hotmail.com> wrote: > > > > >> > > > > >>Hi all, > > > > >> > > > > >>I am doing some stuff with dates and I noticed the date
classes
that
> > > come > > > > >>with the default Squeak image are very nice and very
close
to
having
> > > > >>everything I would want. But there are a few
inconsistencies
here
> and > > > > >>there, and things missing that would make things easier. > > > > >> > > > > >>So what is the procedure to updating this? I think it's
part of
the
> > > core > > > > >>system so I probably can't just do a monicello package
update
> > > > >>somewhere? Do > > > > >>I have to do it through mantis? > > > > >> > > > > >>Thanks, > > > > >>Jason > > > > >> > > > > > > > >
> > > > >>Download Messenger. Join the i'm Initiative. Help make a
difference
> > > today. > > > > > > > >
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
> > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > Get a FREE Web site, company branded e-mail and more from
Microsoft
> Office > > > > Live! > > > >
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
On 4/18/07, Philippe Marschall philippe.marschall@gmail.com wrote:
2007/4/17, Hernan Wilkinson hernan.wilkinson@gmail.com:
On 4/17/07, Philippe Marschall philippe.marschall@gmail.com wrote:
You said:
- Chalten is based on a arithmetic model that allows you to
represent
time measurements easily (like 3 days, 5 months, etc)
So I assumed you meant we could write 5 months just the same way we could write 100 dollars like the examples in the paper show.
No "5 months" but "5 * months" or "moth with: 5". Same for "dollars", "euros", "meters", "liters", "A", "B", etc. That is why I think that measure was not a good word to define this objects... 5*A is not a measure.. what we implemented is really an
algebra,
maybe a limited one, but an algebra at the end.
Maybe I'm just seeing things:
http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A%20New%20... page 7, figure 11: 14 days + 1 week = 1814400000 milliseconds. "Adding measurements of the same base unit" ((14 days + 1 week) convertTo: days) = 21 days. "Converting the result of an operation" (1 year + 10 days) = (1 year + 10 days) "Adding measurements of different base unit" 10 years * 10 = 100 years "Multiplying a measurement by a number" 10 years * 12 months = 10 year*year "Multiplying measurements" 10 years * 12 months / 24 months = 5 years "The model automatically simplifies units" 100 kilometers / 1 hour "Represents a speed of 100 km per hour" 0.01 / 1 month "Represent an interest rate of 10 % by month"
page 8, figure 12: (GregorianYear number: 2005) next: 1 year "Returns GregorianYear number: 2006" (GregorianYear number: 2005) next: 12 months "Returns GregorianYear number: 2006" (GregorianYear number: 2005) next: 10 years "Returns GregorianYear number: 2015" (GregorianYear number: 2005) previous: 5 years "Returns GregorianYear number: 2000"
page 8, figure 13: (GregorianYear number: 2005) next: 120 days "Signals an exception because 120 days can not be converted to years" '01/2005' asGregorianMonthOfYear next: 120 days "Signals an exception because 120 days can not be converted to months"
page 8, figure 14: GregorianDay monday next: 4 days "Returns Friday" GregorianMonth january next: 2 months "Returns March" (GregorianMonth january dayNumber: 1) next: 2 days "Returns January 3rd "
page 8, figure 17: "Returns an Interval with six elements, the years 2005,2007,2009,2011,2013 and 2015 inclusive". (GregorianYear number: 2005) to: (GregorianYear number: 2015) by: 2 years "Returns an Interval with six elements, the years 2005,2004,2003,2002,2001 and 2000 inclusive". (GregorianYear number: 2005) to: (GregorianYear number: 2000) by: -1 year
page 10, figure 22: "06/01/2005 is a Thursday" aTimespan := Timespan from: '06/01/2005' asGregorianDate duration: 48 hours.
ups... you are right, the papers were written before we implemented the #* message to create measures... that's why documentation is not good! :-) (Hey, just kidding, I don't want to get into that discussion again...)
And there is still the question where year comes from
(please no shared pool).
I did not see that question, but the answer is No. The variable
"year"
is
global. The same as month, day, January, February, Monday, etc.
Maybe
you
will not like it,
Global state sucks, no matter how well intended. I haven't tested it but I wouldn't be surprised if it causes problems with Monticello.
Well, I do not agree... I used to think like that but I've changed my mind... Object should be global if the entity they represent in real
life is
global... but I understand that you don't like them. From an Software Engineering point of view, global variables are not
good...
but if you think software development as a learning process and you see
the
Smalltalk image as the "state" of your knowledge about a specific
domain(s),
having global objects (well know objects) is not bad....
but I think that the time domain is so important in writing software as the arithmetic domain,
I think time sucks as a domain. Days that don't have 24 hours, minutes that don't have 60 seconds, years that don't have 365 days, different calendars, timezones, points in time with timezones and without timezones, timezones with more than two DST changes, different week start days, .... For every rule there's an exception and these can change at basically any time. Seriously, how much worse can it get?
I believe it is a really interesting domain!! because of the things you mention! because the exceptions it has makes it a very interesting and challenging problem to design.
Well, yeah. I just don't see how Chalten addresses many of these. Eg. it assumes days have 24 hours and minutes have 60 seconds.
Yes, as I said, it is a model of the GREGORIAN CALENDAR, and in that calendar, days have 24 hours and minutes 60 seconds...
so if numbers are global (1, 2,
3, etc) why not the time objects? They are well know entities of the
real
life....
Numbers are literals not global variables.
Well... that's an implementation detail... at the end they are global.
They
are not "global variables" but "global objects" because the parser knows about them.... so, at the end, they are global. And I think it is ok for them to be global because it is almost impossible to think about a programming language without numbers.... when we get a programming
language
we are expecting to have at least the math to be model with it... (a programming language without numbers as primitives is a very challenging idea... I don't know if it is feasible...)
I don't agree because they don't have the semantics of globals like identify (for everything but SmallIntegers).
I don't understand this... anyhow, at the end, from a conceptual point of view, they are global objects (no global variables... I see variables just as names we give to objects...)
The compiler/parser knows
about them, that's all. But that certainly depends of POV.
Anyhow, I think that when your knowledge about a problem domain (Smalltalk
image) is mature, you will end up with some global objects... We develop financial software and I have to tell you that having "dollar", "euro",
etc.
as global objects would help us a lot... for example no need to
declare them
on each unit test (of course we use test resources, but still), no need
for
the final user to define them (they expect dollar, euro, peso, etc. as
part
of the "kit")...
Why don't you have them as global objects then?
Because software evolution is not simple you know... and because not everybody in the team agrees with me!!! :-).
Well, it was nice to talk about this issues with you.
Bye, Hernan.
Cheers
Philippe
Bye, Hernan.
Cheers Philippe
Bye, Hernan.
Cheers Philippe
http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CF...
)
Hope this help. Hernan.
> Cheers > Philippe > > > > > These objects are > > > > polymorphic with numbers respect to the arithmetic
messages
such
as
+, > > -, *, > > > > etc., that means that you can use them in arithmetic
formulas
> > > > > > That's true to a certain extent in Chronos for example you
can:
> > > Timepoint now - (CalendarDuration months: 1) > > > (CalendarDuration months: 1) * 5 > > > but you can't: > > > 5 * (CalendarDuration months: 1) > > > > Ok, but it is not only the functionality what it is
important
for
us...
for > > us it is also important the way you "write" these things...
for
example,
> > with Chalten/Aconcagua you can write: > > > > 5 * month ---> Equivalent to 5 * (CalendarDuration months:
> > 5 * meter / (second * second) --> A measure of acceleration
if
you
create > > meter as a unit using Aconcagua > > 1/10 * year --> Represents an interest rate of 10% yearly. > > > > As you can see, time measure are not only related only to
the
time
domain > > but used in other domains... that is way for us it is
important
to
support > > this type of behavior and in a DSL way... > > > > Bye, > > Hernan. > > > > > > 5) And of course, I like Chalten's model more that
Chronos
:-).
For
me > > it is > > > > easier to use, but this is just a matter of taste... > > > > > > > > There is a paper we wrote 2 years ago about the problems
that
the
> > Smalltalk > > > > date classes have and the advantages of having a better
model.
If
you > > are > > > > interested on having better date and time classes, I
recommend
you
to > > read > > > > the paper... you may not like it, but at least you will
see
other
people > > > > ideas... > > > > We use that model (Chalten) in a production system and
we
believe it
> > allowed > > > > us to avoid many common mistakes related to financial
systems....
but > > hey, > > > > that's just a feeling, nothing I can prove formally. > > > > > > > > I hope you can do something useful. > > > > Bye, > > > > > > Chronos is a bit ugly in Squeak because Squeak does not
support
> > > namespaces which means that classes that model the same
concept as
> > > Squeak Chronology classes have different names (unless you
mess
with
> > > shared pools). Also loading it is a bit of a pain with
Monticello
> > > (this is the fault of Monticello and not Chronos). > > > > > > Cheers > > > Philippe > > > > > > > Hernan. > > > > > > > > > > > > On 4/16/07, J J <azreal1977@hotmail.com > wrote: > > > > > I have looked at Cronos but it is really huge, and the
classes
that > > come > > > > > with the image are already very close. I will have to
look at
> > Chalten, > > > > but > > > > > what is wrong with a few upgrades to the classes that
come
with
> > Squeak? > > > > > > > > > > >From: "Hernan Wilkinson" < hernan.wilkinson@gmail.com
> > > > > >Reply-To: The general-purpose Squeak developers > > > > > >list<
squeak-dev@lists.squeakfoundation.org
> > > > > >To: "The general-purpose Squeak developers > > > > > >list"<
squeak-dev@lists.squeakfoundation.org
> > > > > >Subject: Re: Date classes > > > > > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > > > > > > > > > >Before doing something with Date, I recommend you to
take
a
look
at > > > > > >"Chalten" or "Cronos". Chalten is in SqueakSource....
I
think
Cronos > > too. > > > > > > > > > > > >Hernan. > > > > > > > > > > > >On 4/16/07, J J < azreal1977@hotmail.com> wrote: > > > > > >> > > > > > >>Hi all, > > > > > >> > > > > > >>I am doing some stuff with dates and I noticed the
date
classes
that > > > > come > > > > > >>with the default Squeak image are very nice and very
close
to
having > > > > > >>everything I would want. But there are a few
inconsistencies
here > > and > > > > > >>there, and things missing that would make things
easier.
> > > > > >> > > > > > >>So what is the procedure to updating this? I think
it's
part of
the > > > > core > > > > > >>system so I probably can't just do a monicello
package
update
> > > > > >>somewhere? Do > > > > > >>I have to do it through mantis? > > > > > >> > > > > > >>Thanks, > > > > > >>Jason > > > > > >> > > > > > > > > > > >
> > > > > >>Download Messenger. Join the i'm Initiative. Help
make a
difference > > > > today. > > > > > > > > > > >
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
> > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > Get a FREE Web site, company branded e-mail and more
from
Microsoft > > Office > > > > > Live! > > > > > >
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
But hernan class comments and method comments are good too.
Stef
On 17 avr. 07, at 18:00, Hernan Wilkinson wrote:
I loaded Aconcagua-mx.1.6 and Chalten-mx.1.3 in Squeak 3.9. The following all give errors:
GregorianDay today + 1 day GregorianDateTime now + 1 day GregorianDay today next: 5 GregorianYear current + 1 year 5 months
I guess I have to thank you. After hearing what a piece of shit Seaside is because of its lack of documentation it's relieving to see a framework with no class comments at all. A quick browsing through same classes showed also no method comments.
jaja, it seems to me that you did not look good enough.... just look at the Test!!! They are all the documentation you need! and more!! real examples, live code! not just documentation.... We defenetly use different development techniques... Also, remember the paper! Links: http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A% 20New%20Object-Oriented%20Model%20of%20the%20Gregorian%20Calendar.pdf http://prog2.vub.ac.be/~cderoove/esugtalks/Wilkinson.pdf (ESUG Presentation)
About the code you tried:
- GregorianDay today + 1 day -> It will not work becuase a date
is not polymorphic with numbers. You have to do: "GregorianDate today next" or "GregorianDate today next: 1 * day" Remember the *, that allows you to create measures easily
GregorianDateTime now + 1 day ---> Same as 1)
GregorianDay today next: 5 --> It will not work because 5 is not
a measure of time, it is just a number. Try "GregorianDay today next: 5 * day" 5 * day is a measure of time
- GregorianYear current + 1 year --> Same as 1) but using a
measure expressed in year, for example "2 * year" 5) 5 months --> Measure are created in many ways. We decided not to clutter the number protocol with each unit you could have... because measures are arithmetic representations of a number times its unit, the right way to create them is using the arithmetic operator * (See our paper about Aconcagua. Link: http://portal.acm.org/citation.cfm? id=1094964&coll=ACM&dl=ACM&CFID=20205775&CFTOKEN=19800555 )
Hope this help. Hernan.
Cheers Philippe
These objects are polymorphic with numbers respect to the arithmetic messages
such as +,
-, *,
etc., that means that you can use them in arithmetic formulas
That's true to a certain extent in Chronos for example you can: Timepoint now - (CalendarDuration months: 1) (CalendarDuration months: 1) * 5 but you can't: 5 * (CalendarDuration months: 1)
Ok, but it is not only the functionality what it is important for
us... for
us it is also important the way you "write" these things... for
example,
with Chalten/Aconcagua you can write:
5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) 5 * meter / (second * second) --> A measure of acceleration if
you create
meter as a unit using Aconcagua 1/10 * year --> Represents an interest rate of 10% yearly.
As you can see, time measure are not only related only to the
time domain
but used in other domains... that is way for us it is important
to support
this type of behavior and in a DSL way...
Bye, Hernan.
- And of course, I like Chalten's model more that
Chronos :-). For me
it is
easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that
the
Smalltalk
date classes have and the advantages of having a better
model. If you
are
interested on having better date and time classes, I
recommend you to
read
the paper... you may not like it, but at least you will see
other people
ideas... We use that model (Chalten) in a production system and we
believe it
allowed
us to avoid many common mistakes related to financial
systems.... but
hey,
that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye,
Chronos is a bit ugly in Squeak because Squeak does not support namespaces which means that classes that model the same concept as Squeak Chronology classes have different names (unless you mess
with
shared pools). Also loading it is a bit of a pain with Monticello (this is the fault of Monticello and not Chronos).
Cheers Philippe
Hernan.
On 4/16/07, J J <azreal1977@hotmail.com > wrote:
I have looked at Cronos but it is really huge, and the
classes that
come
with the image are already very close. I will have to look at
Chalten,
but
what is wrong with a few upgrades to the classes that come
with
Squeak?
From: "Hernan Wilkinson" < hernan.wilkinson@gmail.com> Reply-To: The general-purpose Squeak developers list< squeak-dev@lists.squeakfoundation.org > To: "The general-purpose Squeak developers list"< squeak-dev@lists.squeakfoundation.org > Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take
a look at
"Chalten" or "Cronos". Chalten is in SqueakSource.... I
think Cronos
too.
Hernan.
On 4/16/07, J J < azreal1977@hotmail.com> wrote: > >Hi all, > >I am doing some stuff with dates and I noticed the date
classes that
come
>with the default Squeak image are very nice and very
close to having
>everything I would want. But there are a few
inconsistencies here
and
>there, and things missing that would make things easier. > >So what is the procedure to updating this? I think it's
part of the
core
>system so I probably can't just do a monicello package
update
>somewhere? Do >I have to do it through mantis? > >Thanks, >Jason >
>Download Messenger. Join the i'm Initiative. Help make a
difference
today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
> > >
Get a FREE Web site, company branded e-mail and more from
Microsoft
Office
Live!
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
I guess I have to thank you. After hearing what a piece of shit Seaside is because of its lack of documentation it's relieving to see a framework with no class comments at all. A quick browsing through same classes showed also no method comments.
Cheers Philippe
Hey, Seaside rocks, hard! Don't let anyone tell you otherwise or make you feel bad because of a lack of comments. Comments are nice, but features are nicer. You guys do outstanding work, even if it's not said enough, we're all thinking it.
Ramon Leon http://onsmalltalk.com
Hey, Seaside rocks, hard! Don't let anyone tell you otherwise or make you feel bad because of a lack of comments. Comments are nice, but features are nicer. You guys do outstanding work, even if it's not said enough, we're all thinking it.
Ramon Leon http://onsmalltalk.com
"But if it is not documented it may as well not exist" - so the features you mention that are so great actually for real purposes (apart from personal hacking) do not exist!
When you are working in a professional coding environment, anything without documentation falls below the radar. Management cant keep looking at source code to see if a needed feature has arrived.
best regards
Keith
"But if it is not documented it may as well not exist" - so the features you mention that are so great actually for real purposes (apart from personal hacking) do not exist!
Not true. They've been doing lots of stuff lately to improve performance. We all benefit from that whether they document it or not.
When you are working in a professional coding environment, anything without documentation falls below the radar. Management cant keep looking at source code to see if a needed feature has arrived.
best regards
Keith
I don't see a professional coding environment, I see 3 or 4 guys contributing their spare time writing one of the most kick ass web frameworks ever made. I see check in comments on every commit saying what they did. If there's a lack of comments in the code and on the classes, I don't blame them, I blame us, for not jumping in and helping them out. Would more comments be nice, sure, but lets not make the only guys doing the work feel bad about it.
Ramon Leon http://onsmalltalk.com
I don't see a professional coding environment, I see 3 or 4 guys contributing their spare time writing one of the most kick ass web frameworks ever made. I see check in comments on every commit saying what they did. If there's a lack of comments in the code and on the classes, I don't blame them, I blame us, for not jumping in and helping them out. Would more comments be nice, sure, but lets not make the only guys doing the work feel bad about it.
Kick ass web frameworks for whom, the elite? the premadonnas? What happened to smalltalk being an environment that is so easy a child could do it, making things accessible as part of the culture?
I am not trying to make anyone feel bad, it is a cultural thing I was trying to highlight. We have no problem promoting a Testing/Test First culture, why not promote the documentation aspect?
If you look in the seaside archives I said it back towards Seaside version 1.0 and 1.1 back in the days before seaside had any credibility. If seaside had had some documentation back then perhaps there would not even be a rails today. Regrettably nothing much has changed, until recently. (i.e. Lukas knows better :-) )
Zope had a book, and as a result zope runs the intranet at my previous company. The actual under the hood code in zope was horrendous, but it has/had a book.
PHP has a book, and what a book it is, I saw a printout of the manual once, the sheer size of it scared me. But it has a book, and the market share speaks for itself. Sure documentation is not the only factor but it is a factor.
Keith
Kick ass web frameworks for whom, the elite? the premadonnas?
Sadly, right now, those who are willing to put forth the effort to learn it. I'm not saying that's not a problem, only that it's a community problem, not necessarily the core developers problem.
What happened to smalltalk being an environment that is so easy a child could do it, making things accessible as part of the culture?
I don't think it ever was that, despite its attempts to be.
I am not trying to make anyone feel bad, it is a cultural thing I was trying to highlight. We have no problem promoting a Testing/Test First culture, why not promote the documentation aspect?
If you look in the seaside archives I said it back towards Seaside version 1.0 and 1.1 back in the days before seaside had any credibility. If seaside had had some documentation back then perhaps there would not even be a rails today. Regrettably nothing much has changed, until recently. (i.e. Lukas knows better :-) )
Zope had a book, and as a result zope runs the intranet at my previous company. The actual under the hood code in zope was horrendous, but it has/had a book.
PHP has a book, and what a book it is, I saw a printout of the manual once, the sheer size of it scared me. But it has a book, and the market share speaks for itself. Sure documentation is not the only factor but it is a factor.
Keith
I don't disagree, a book would be great. More than anything, Seaside needs documentation, marketing, and a larger community to enable those things, but we don't need to piss of the only people actually doing any work. Philippe's comments seemed to indicate he was rather annoyed. I was just reminding him that we appreciate the effort they put forth, despite any bitching they may feel coming their way.
Ramon Leon http://onsmalltalk.com
Keith Hodges a écrit :
I don't see a professional coding environment, I see 3 or 4 guys contributing their spare time writing one of the most kick ass web frameworks ever made. I see check in comments on every commit saying what they did. If there's a lack of comments in the code and on the classes, I don't blame them, I blame us, for not jumping in and helping them out. Would more comments be nice, sure, but lets not make the only guys doing the work feel bad about it.
Kick ass web frameworks for whom, the elite? the premadonnas? What happened to smalltalk being an environment that is so easy a child could do it, making things accessible as part of the culture?
Hi Keith,
I agree, a nice goal.
But you must take into account that external world do impose constraints.
I'am not sure Seaside team is responsible for WEB complexity. They just try to manage it.
And to come back to Date subject our days are still more or less 86400 seconds, night included. So I would not rant Seaside people for not working hard enough.
Nicolas
And to come back to Date subject our days are still more or less 86400 seconds, night included. So I would not rant Seaside people for not working hard enough.
Nicolas
It's not a rant about people not working hard enough.
Many people perceive that Test first development must require 'more work'. Those that swear by test first development might disagree. The same goes for most other practices which have a counter intuitive payoff (e.g. pair programming etc)
I do not think that it has anything to do with working hard enough, it has to do with attitude, and culture. In smalltalk we have a culture that accepts this, because we can I guess.
cheers
Keith
I think the problem we are seeing is that we don't really have a distinction between "stable" and "live branch" in Seaside right now. I think what happens in most OS projects is when a branch moves to "stable" (i.e. no new features added to the branch, just bug fixes) then the documentation team can come in and make sure the documentation is 100% because the target isn't moving so much anymore.
The main Seaside branch is moving so fast documenting it would be a situation where; before you can publish the change set with the documentation, much of it is already invalid.
I think we need to have a separate group doing the documentation if possible, these guys are on a role, we should let them keep at it.
From: "Ramon Leon" ramon.leon@allresnet.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'The general-purpose Squeak developers list'"squeak-dev@lists.squeakfoundation.org Subject: RE: Date classes Date: Tue, 17 Apr 2007 10:37:35 -0700
"But if it is not documented it may as well not exist" - so the features you mention that are so great actually for real purposes (apart from personal hacking) do not exist!
Not true. They've been doing lots of stuff lately to improve performance. We all benefit from that whether they document it or not.
When you are working in a professional coding environment, anything without documentation falls below the radar. Management cant keep looking at source code to see if a needed feature has arrived.
best regards
Keith
I don't see a professional coding environment, I see 3 or 4 guys contributing their spare time writing one of the most kick ass web frameworks ever made. I see check in comments on every commit saying what they did. If there's a lack of comments in the code and on the classes, I don't blame them, I blame us, for not jumping in and helping them out. Would more comments be nice, sure, but lets not make the only guys doing the work feel bad about it.
Ramon Leon http://onsmalltalk.com
_________________________________________________________________ Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapr...
2007/4/20, J J azreal1977@hotmail.com:
I think the problem we are seeing is that we don't really have a distinction between "stable" and "live branch" in Seaside right now. I think what happens in most OS projects is when a branch moves to "stable" (i.e. no new features added to the branch, just bug fixes) then the documentation team can come in and make sure the documentation is 100% because the target isn't moving so much anymore.
stable: Seaside 2.7 live: Seaside 2.8
The main Seaside branch is moving so fast documenting it would be a situation where; before you can publish the change set with the documentation, much of it is already invalid.
No
I think we need to have a separate group doing the documentation if possible, these guys are on a role, we should let them keep at it.
We are happy for any help.
Cheers Philippe
From: "Ramon Leon" ramon.leon@allresnet.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'The general-purpose Squeak developers list'"squeak-dev@lists.squeakfoundation.org Subject: RE: Date classes Date: Tue, 17 Apr 2007 10:37:35 -0700
"But if it is not documented it may as well not exist" - so the features you mention that are so great actually for real purposes (apart from personal hacking) do not exist!
Not true. They've been doing lots of stuff lately to improve performance. We all benefit from that whether they document it or not.
When you are working in a professional coding environment, anything without documentation falls below the radar. Management cant keep looking at source code to see if a needed feature has arrived.
best regards
Keith
I don't see a professional coding environment, I see 3 or 4 guys contributing their spare time writing one of the most kick ass web frameworks ever made. I see check in comments on every commit saying what they did. If there's a lack of comments in the code and on the classes, I don't blame them, I blame us, for not jumping in and helping them out. Would more comments be nice, sure, but lets not make the only guys doing the work feel bad about it.
Ramon Leon http://onsmalltalk.com
Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapr...
Ramon
Philippe is not feeling bad because of that. I hope :) Lukas wrote the first class comment of seaside in my car on the highway to Nice. They know that I'm right on that point. Comments are important. They also know that I respect them and that I pushed a lot seaside. Now liking seaside does not mean that difficult feedback should not be made :)
Stef
On 17 avr. 07, at 18:34, Ramon Leon wrote:
I guess I have to thank you. After hearing what a piece of shit Seaside is because of its lack of documentation it's relieving to see a framework with no class comments at all. A quick browsing through same classes showed also no method comments.
Cheers Philippe
Hey, Seaside rocks, hard! Don't let anyone tell you otherwise or make you feel bad because of a lack of comments. Comments are nice, but features are nicer. You guys do outstanding work, even if it's not said enough, we're all thinking it.
Ramon Leon http://onsmalltalk.com
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Tue, 17 Apr 2007 10:10:49 -0300
There is a paper we wrote 2 years ago about the problems that the Smalltalk date classes have and the advantages of having a better model. If you are interested on having better date and time classes, I recommend you to read the paper... you may not like it, but at least you will see other people ideas...
Hi. Any link to the paper?
And my choice is not about what I like or what I don't like, it's about external dependencies. I am creating Recurrence rules in Squeak (very hairy specification) and I want to minimize external dependencies. I didn't want to say someone has to use some special time package (no matter how good it is) just to use my stuff. Especially since I don't see Recurrence rules needing that extra functionality (e.g. timezones).
_________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
Oh, and thanks for the information.
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Tue, 17 Apr 2007 10:10:49 -0300
Just to give you a fast review of what I remember (I developed the model that Maxi Taborda converted into Chalten):
- Chronos supports many calendars, Chalten only the Gregorian Calendar
- Chronos supports time zones, Chalten does not
- Choros is huge (as you mentions), Chalten is more manageable (because it
just model the Gregorian Calendar) 4) Chronos lacks some abstractions that Chalten has, like Day of Month and others (I don't remember now...there are a couple of mails that I and the guy that created Chronos wrote about these issues, like one year ago) 5) Chalten is based on a arithmetic model that allows you to represent time measurements easily (like 3 days, 5 months, etc). These objects are polymorphic with numbers respect to the arithmetic messages such as +, -, *, etc., that means that you can use them in arithmetic formulas 5) And of course, I like Chalten's model more that Chronos :-). For me it is easier to use, but this is just a matter of taste...
There is a paper we wrote 2 years ago about the problems that the Smalltalk date classes have and the advantages of having a better model. If you are interested on having better date and time classes, I recommend you to read the paper... you may not like it, but at least you will see other people ideas... We use that model (Chalten) in a production system and we believe it allowed us to avoid many common mistakes related to financial systems.... but hey, that's just a feeling, nothing I can prove formally.
I hope you can do something useful. Bye, Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
I have looked at Cronos but it is really huge, and the classes that come with the image are already very close. I will have to look at Chalten, but what is wrong with a few upgrades to the classes that come with Squeak?
From: "Hernan Wilkinson" hernan.wilkinson@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Date classes Date: Mon, 16 Apr 2007 14:28:09 -0300
Before doing something with Date, I recommend you to take a look at "Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos
too.
Hernan.
On 4/16/07, J J azreal1977@hotmail.com wrote:
Hi all,
I am doing some stuff with dates and I noticed the date classes that
come
with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the
core
system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
Download Messenger. Join the i'm Initiative. Help make a difference
today.
Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
_________________________________________________________________ MSN is giving away a trip to Vegas to see Elton John. Enter to win today. http://msnconcertcontest.com?icid-nceltontagline
Do check the latest iterations of some fixes for DateAndTime here ( http://bugs.squeak.org/view.php?id=474) , in particular this includes a fully tested implementation of the millisecond clock.
For testing you will need SUnit and SUnitGUI from http://www.squeaksource.com/Testing Because it uses ClassClonerTestResource to clone the DataAndTime class for testing without messing with the main system clock.
from my last note:
I am pleased to announce a testable/tested incarnation of the millisecond clock implementation. It is much faster too. This handles the clock rollover, and midnight rollovers.
If the clock is not used for a number of days and may have lost synchronisation then a sanity check is performed that will recalculate the offsets.
The updates can be quite tricky to load, but I hope to see them in 3.10 (Edgar?) It would be great if you could try them out and offer feedback first.
best regards
Keith
Hi all,
I am doing some stuff with dates and I noticed the date classes that come with the default Squeak image are very nice and very close to having everything I would want. But there are a few inconsistencies here and there, and things missing that would make things easier.
So what is the procedure to updating this? I think it's part of the core system so I probably can't just do a monicello package update somewhere? Do I have to do it through mantis?
Thanks, Jason
squeak-dev@lists.squeakfoundation.org
-
Alan Lovejoy -
Andreas Raab -
Chris Muller -
David T. Lewis -
Giuseppe Luigi Punzi -
Hernan Wilkinson -
J J -
Keith Hodges -
nicolas cellier -
Philippe Marschall -
Ramon Leon -
stephane ducasse