[squeak-dev] [ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
bert at freudenbergs.de
Thu Oct 18 02:13:54 UTC 2018
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 -
On Wed, Oct 17, 2018 at 6:59 PM Chris Muller <asqueaker at gmail.com> wrote:
> 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
> On Wed, Oct 17, 2018 at 8:18 PM David T. Lewis <lewis at mail.msen.com>
> > I added a SqueakMap entry for UTCDateAndTime so that it can be easily
> > 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
> > it out.
> > My primary motivation for this was to make DateAndTime easier to
> > 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
> > to make the tests green in cases where current behavior (or
> > 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
> > 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
> > future. Please yell at me if you think this is a bad idea.
> > Dave
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev