[squeak-dev] [ANN] UtCDateAndTime on SqueakMap for Squeak 5.2

[David T. Lewis]

I added a SqueakMap entry for UTCDateAndTime so that it can be easily loaded
in the new Squeak 5.2 release.

http://wiki.squeak.org/squeak/6197

This project is a few years old now and I use it in my own images. There
is no easy way to uninstall it, so please back up your image before trying
it out.

My primary motivation for this was to make DateAndTime easier to understand
and easier to test. A happy side effect is that it is also substantially
faster on unix VMs, so I would be interested in hearing if it provides
similar improvement on Windows and OS X.

Some Chronology tests will fail. This is intentional, as I did not attempt
to make the tests green in cases where current behavior (or implementation
of the test itself) may be questionable.

After living with this for a couple of years, I think there may be a good
case for moving it to trunk. But there are potential side effects for
things like serializers (Fuel and Ma Serializer, SmartRefStream is already
handled) and databases (Magma, Glorp, others?). So feedback in any of
these areas would be welcome.

If no objections, I will plan to push this to trunk in the not too distant
future. Please yell at me if you think this

[Chris Muller]

Hi Dave,

It sounds like it could be a good improvement, but yes, it is a bad
idea to replace an entire subsystem only "If no objections." This
really does need a thorough peer review, and get the code battle
tested in real-world application code to find all the bugs not exposed
by just the unit tests. (Look how long we went without noticing the
bug in Timespan>>=.

As a safety valve from your eagerness, allow me register my objection
now. This is just temporary to make sure we all can have time to
understand all the tests it breaks and the impacts or trade-offs of
those. Hmm, however, if tests are failing anyway, it's hard to get
motivated to even invest time in it when what we have is already
working...

Best,
Chris

Post by David T. Lewis
I added a SqueakMap entry for UTCDateAndTime so that it can be easily loaded
in the new Squeak 5.2 release.
http://wiki.squeak.org/squeak/6197
This project is a few years old now and I use it in my own images. There
is no easy way to uninstall it, so please back up your image before trying
it out.
My primary motivation for this was to make DateAndTime easier to understand
and easier to test. A happy side effect is that it is also substantially
faster on unix VMs, so I would be interested in hearing if it provides
similar improvement on Windows and OS X.
Some Chronology tests will fail. This is intentional, as I did not attempt
to make the tests green in cases where current behavior (or implementation
of the test itself) may be questionable.
After living with this for a couple of years, I think there may be a good
case for moving it to trunk. But there are potential side effects for
things like serializers (Fuel and Ma Serializer, SmartRefStream is already
handled) and databases (Magma, Glorp, others?). So feedback in any of
these areas would be welcome.
If no objections, I will plan to push this to trunk in the not too distant
future. Please yell at me if you think

[Bert Freudenberg]

All -

what David failed to mention is that in the last Board meeting, we
encouraged him to put this into the trunk now, early in the release cycle.
He asked for feedback multiple times before, and is asking for feedback
again now, out of sheer politeness.

So please, try this. It is a much cleaner and simpler implementation, which
makes it faster, too. We want it. IMHO this should go in unless a *valid*
objection is raised, meaning you should at least try it.

- Bert -

Post by Chris Muller
Hi Dave,
It sounds like it could be a good improvement, but yes, it is a bad
idea to replace an entire subsystem only "If no objections." This
really does need a thorough peer review, and get the code battle
tested in real-world application code to find all the bugs not exposed
by just the unit tests. (Look how long we went without noticing the
bug in Timespan>>=.
As a safety valve from your eagerness, allow me register my objection
now. This is just temporary to make sure we all can have time to
understand all the tests it breaks and the impacts or trade-offs of
those. Hmm, however, if tests are failing anyway, it's hard to get
motivated to even invest time in it when what we have is already
working...
Best,
Chris

Post by David T. Lewis
I added a SqueakMap entry for UTCDateAndTime so that it can be easily

loaded

Post by David T. Lewis
in the new Squeak 5.2 release.
http://wiki.squeak.org/squeak/6197
This project is a few years old now and I use it in my own images. There
is no easy way to uninstall it, so please back up your image before

trying

Post by David T. Lewis
it out.
My primary motivation for this was to make DateAndTime easier to

understand

Post by David T. Lewis
and easier to test. A happy side effect is that it is also substantially
faster on unix VMs, so I would be interested in hearing if it provides
similar improvement on Windows and OS X.
Some Chronology tests will fail. This is intentional, as I did not

attempt

Post by David T. Lewis
to make the tests green in cases where current behavior (or

implementation

Post by David T. Lewis
of the test itself) may be questionable.
After living with this for a couple of years, I think there may be a good
case for moving it to trunk. But there are potential side effects for
things like serializers (Fuel and Ma Serializer, SmartRefStream is

already

Post by David T. Lewis
handled) and databases (Magma, Glorp, others?). So feedback in any of
these areas would be welcome.
If no objections, I will plan to push this to trunk in the not too

distant

Post by David T. Lewis
future. Please yell at me if you think this is a bad idea.
Dave

[Chris Muller]

what David failed to mention is that in the last Board meeting, we encouraged him to put this into the trunk now, early in the release cycle. He asked for feedback multiple times before, and is asking for feedback again now, out of sheer politeness.
So please, try this. It is a much cleaner and simpler implementation, which makes it faster, too. We want it. IMHO this should go in unless a *valid* objection is raised, meaning you should at least try it.

+1

Please appreciate the economy of looking at something that only
provides a nominal improvement. I hope you did not see my temporary
objection as a true objection as much as a request to ensure there is
some community consensus. With what you've just reported, it sounds
like we do, or at least its forming. But we need to give users a bit
more coddling than that meager web page to help them understand what
they would need to do to change to a subsystem that is this critical.
The mention of the serializers is what I'm talking about, but what
data conversions are needed? What algorithm conversions for apps?

One of the worst kinds of bug is one which calculates invalid data for
a particular application (due new assumptions), but doesn't actually
blow up, only to be discovered a long time later after potentially
pervasive damage. Dave, could you see any potential for
different-calculations in yours to allow this sort of bug to creep
into an ex

[David T. Lewis]

Post by Chris Muller

what David failed to mention is that in the last Board meeting, we encouraged him to put this into the trunk now, early in the release cycle. He asked for feedback multiple times before, and is asking for feedback again now, out of sheer politeness.
So please, try this. It is a much cleaner and simpler implementation, which makes it faster, too. We want it. IMHO this should go in unless a *valid* objection is raised, meaning you should at least try it.

+1
Please appreciate the economy of looking at something that only
provides a nominal improvement. I hope you did not see my temporary
objection as a true objection as much as a request to ensure there is
some community consensus. With what you've just reported, it sounds
like we do, or at least its forming. But we need to give users a bit
more coddling than that meager web page to help them understand what
they would need to do to change to a subsystem that is this critical.
The mention of the serializers is what I'm talking about, but what
data conversions are needed? What algorithm conversions for apps?
One of the worst kinds of bug is one which calculates invalid data for
a particular application (due new assumptions), but doesn't actually
blow up, only to be discovered a long time later after potentially
pervasive damage. Dave, could you see any potential for
different-calculations in yours to allow this sort of bug to creep
into an existing application?

Yes there is potential for that kind of error, including the case of
an application that unknowingly relies on bad behavior and later fails
when the bad behavior is removed. This could be a real problem for database
applications, but it is hard for me to assess how big the risk is.

The unit tests will give you a fairly good idea of things that might
be issues. There are 7 failures and one unexpected pass when running
the existing Chronology tests.

With regard to serialization, it is handled as follows:

Name: Chronology-Core-dtl.26
Author: dtl
Time: 8 December 2016, 8:23:28.539757 pm
UUID: 9572cf6e-6c65-4205-9435-f82b6c169a98
Ancestors: Chronology-Core-dtl.25

Fix readDataFrom:size: and implement storeDataOn:

Strategy - Always store instances of DateAndTime as if they were the old
format with seconds, offset, jdn, nanos. This ensures that serialized
instances such as those in the snapshot.bin of a Monticello archive can
be read by any image.

Implementation is in DateAndTime>>readDataFrom:size: and DateAndTime>>storeDataOn:
and I expect that both Fuel and Ma-Serializer wi