[ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
Locked
[ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
 
|
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 is a bad idea. Dave |
Re: [ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
|
|
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 On Wed, Oct 17, 2018 at 8:18 PM David T. Lewis <[hidden email]> wrote: > > 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 is a bad idea. > > Dave > |
Re: [ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
|
|
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 - On Wed, Oct 17, 2018 at 6:59 PM Chris Muller <[hidden email]> wrote: Hi Dave, |
Re: [ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
|
|
> 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? Best, Chris |
Re: [ANN] UtCDateAndTime on SqueakMap for Squeak 5.2
|
|
On Wed, Oct 17, 2018 at 10:33:50PM -0500, Chris Muller wrote:
> > 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 will need similar handling. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |