[error] DateAndTime changes produce different result on #readFrom:
Locked
[error] DateAndTime changes produce different result on #readFrom:
 
|
In calling this method:
DateAndTime fromString: '2007-03-22T15:58:17+00:00'. The results in 5.3 are different than in 5.2. This is breaking 2 ASN1Tests and 2 X509Tests. I am still in analysis of the decoding differences. The methods between the two versions are completely different. This breaks Cryptography. K, r |
Re: [error] DateAndTime changes produce different result on #readFrom:
|
|
In truth, this is an issue with incomplete DateAndTime testing. As there
are resulting differences, this ought to be tested and modified in the package containing the core DateAndTime definition and NOT an override in the Cryptography package. I do not know who owns DateAndTime. I will continue to slowly dig into the issue.. K, r On 3/2/20 12:23 PM, Robert wrote: > In calling this method: > > DateAndTime fromString: '2007-03-22T15:58:17+00:00'. > > The results in 5.3 are different than in 5.2. This is breaking 2 > ASN1Tests and 2 X509Tests. I am still in analysis of the decoding > differences. The methods between the two versions are completely > different. This breaks Cryptography. > > K, r > |
Re: [error] DateAndTime changes produce different result on #readFrom:
|
|
As the remaining issue is in core DateAndTime, I am publishing
the changes to Cryptography for Squeak v5.3. Cryptography-v5.3-rww.117
|
Re: [error] DateAndTime changes produce different result on #readFrom:
|
In reply to this post by Squeak - Dev mailing list
Hi, there. The internal representation of DateAndTime changed from seconds offset jdn nanos in Squeak 5.2 to this in 5.3: utcMicroseconds localOffsetSeconds --- If tests in "Cryptography" relied on the internal representation of DateAndTime, those tests have to be adapted. Looking at ASN1Test >> #testUTCTime, this is the case: testUTCTime | bytes obj testObj newBytes | bytes := #[23 13 48 55 48 51 50 50 49 53 53 56 49 55 90]. testObj := DateAndTime fromString: '2007-03-22T15:58:17+00:00'. obj := ASN1InputStream decodeBytes: bytes. self assert: (obj = testObj). newBytes := ASN1OutputStream encode: testObj. self assert: (bytes asByteArray = newBytes). newBytes := ASN1OutputStream encode: obj. self assert: (bytes asByteArray = newBytes). The "bytes" are different for (encoded) instances of DateAndTime in Squeak 5.3. Best, Marcel
|
Re: [error] DateAndTime changes produce different result on #readFrom:
|
|
Yes, my former method extension DateAndTime>>#milliSecond
accessed #nanos. I changed this to call #utcMicroseconds and
changed the name o fthe method to #milliseconds. This is in
version 117 of Cryptography that I had released. On 3/2/20 12:48 PM, Marcel Taeumel
wrote:
|
Re: [error] DateAndTime changes produce different result on #readFrom:
|
|
In reply to this post by marcel.taeumel
Hi Robert,
It may also be helpful to look at the 'objects from disk' methods in DateAndTime. These are designed to address the problem of storing instances of the new DateAndTime representation in an external format that is completely compatible with the original implementation. I did something similar for the Fuel serializer, so I am confident that the general approach is valid. The basic idea is to always use the old instance variable format (four instance variables) for externally stored data, and read the old format data into the new format (two instance variables) when loading back into the image. I also did an implementation for the Magma serializer to store DateAndTime for the Magma framework, which proved to be unnecessary for Magma requirements, but which works similarly to the DataStream and Fuel serializers. I have not looked at the Cryptography tests but as Marcel says, if the tests are relying on the internal representation of DateAndTime, then those tests will need to be updated. The 'objects from disk' methods hopefully will provide guidance as to how map the instance variables from one format to the other. Specifically, the two methods to look at are: DateAndTime>>readDataFrom:size: DateAndTime>>storeDataOn: HTH, Dave On Mon, Mar 02, 2020 at 06:48:11PM +0100, Marcel Taeumel wrote: > Hi, there. > > The internal representation of DateAndTime changed from > > seconds > offset > jdn > nanos > > in Squeak 5.2 to this in 5.3: > > utcMicroseconds > localOffsetSeconds > > --- > > If tests in "Cryptography" relied on the internal representation of DateAndTime, those tests have to be adapted. Looking at ASN1Test >> #testUTCTime, this is the case: > > testUTCTime > > | bytes obj testObj newBytes | > bytes := #[23 13 48 55 48 51 50 50 49 53 53 56 49 55 90]. > testObj := DateAndTime fromString: '2007-03-22T15:58:17+00:00'. > obj := ASN1InputStream decodeBytes: bytes. > self assert: (obj = testObj). > newBytes := ASN1OutputStream encode: testObj. > self assert: (bytes asByteArray = newBytes). > newBytes := ASN1OutputStream encode: obj. > self assert: (bytes asByteArray = newBytes). > > The "bytes" are different for (encoded) instances of DateAndTime in Squeak 5.3. > > Best, > Marcel > Am 02.03.2020 18:31:51 schrieb Robert via Squeak-dev <[hidden email]>: > In truth, this is an issue with incomplete DateAndTime testing. As there > are resulting differences, this ought to be tested?? and modified in the > package containing the core DateAndTime definition and NOT an override > in the Cryptography package. I do not know who owns DateAndTime. I will > continue to slowly dig into the issue.. > > K, r > > On 3/2/20 12:23 PM, Robert wrote: > > In calling this method: > > > > DateAndTime fromString: '2007-03-22T15:58:17+00:00'. > > > > The results in 5.3 are different than in 5.2. This is breaking 2 > > ASN1Tests and 2 X509Tests. I am still in analysis of the decoding > > differences. The methods between the two versions are completely > > different. This breaks Cryptography. > > > > K, r > > > > > |
Re: [error] DateAndTime changes produce different result on #readFrom:
|
|
In reply to this post by Squeak - Dev mailing list
Hi Robert,
I know this is no longer an issue for Cryptography, but I am responsible for the new internal representation of DateAndTime, so I want to follow up in case there are any remaining concerns. On Mon, Mar 02, 2020 at 05:55:20PM +0000, Robert via Squeak-dev wrote: > Yes, my former method extension DateAndTime>>#milliSecond accessed > #nanos. > I changed this to call #utcMicroseconds and changed the > name o fthe method to #milliseconds. This is in version 117 of > Cryptography that I had released. The accessor method for this is DateAndTime>>nanosecond. The #nanos instance variable no longer exists, but #nanosecond produces the same results as before and passes all unit tests. If you were to change your method to use self nanosecond rather than direct reference to the instance variable, then it should work as you expect. > > The remaining issue is DateAndtime class>>#readFrom: which completely > changed implementations and also produced different results. This is > a failure of DateAndTime to migrate to a new internal representation, > while preserving identical results to former behavior. There are two > representations of DateAndTime in tthe test method under discussion. > One is the ASN1 representation and the other is an internet task force > accepted textual representation. The new #readFrom: misrepresents the > result from the textual representation. This is a clear error in core > DateAndTime, IMHO. The milliseconds are different, somehow. > Can you say specifically what was different versus the former behavior? There definitely are differences in the new implementation, but my expectation is that any differences should either fix problems or resolve ambiguities. Thanks, Dave |
Re: [error] DateAndTime changes produce different result on #readFrom:
|
|
Hey Dave, The version I ended up publishing was with a call to
#nanoseconds! This was the issue. So we took different paths and arrived together! This fixed all the DateAndTime issues and we got Crypto published in v5.3. I believe the latest is 120. Though the versions are different, for readFrom:, they may well work the same. I would consider it untested, but no cause for alarm. Seems to work for my uses! k, r On 3/6/20 6:30 PM, David T. Lewis wrote: > Hi Robert, > > I know this is no longer an issue for Cryptography, but I am responsible > for the new internal representation of DateAndTime, so I want to follow > up in case there are any remaining concerns. > > On Mon, Mar 02, 2020 at 05:55:20PM +0000, Robert via Squeak-dev wrote: >> Yes, my former method extension DateAndTime>>#milliSecond accessed >> #nanos. > I changed this to call #utcMicroseconds and changed the >> name o fthe method to #milliseconds. This is in version 117 of >> Cryptography that I had released. > The accessor method for this is DateAndTime>>nanosecond. The #nanos > instance variable no longer exists, but #nanosecond produces the same > results as before and passes all unit tests. If you were to change your > method to use self nanosecond rather than direct reference to the > instance variable, then it should work as you expect. > >> The remaining issue is DateAndtime class>>#readFrom: which completely >> changed implementations and also produced different results. This is >> a failure of DateAndTime to migrate to a new internal representation, >> while preserving identical results to former behavior. There are two >> representations of DateAndTime in tthe test method under discussion. >> One is the ASN1 representation and the other is an internet task force >> accepted textual representation. The new #readFrom: misrepresents the >> result from the textual representation. This is a clear error in core >> DateAndTime, IMHO. The milliseconds are different, somehow. >> > Can you say specifically what was different versus the former behavior? > There definitely are differences in the new implementation, but my > expectation is that any differences should either fix problems or > resolve ambiguities. > > Thanks, > Dave > |
Re: [error] DateAndTime changes produce different result on #readFrom:
|
|
Great, thank you :-)
Dave On Fri, Mar 06, 2020 at 11:35:57PM +0000, Robert via Squeak-dev wrote: > Hey Dave, The version I ended up publishing was with a call to > #nanoseconds! This was the issue. So we took different paths and arrived > together! This fixed all the DateAndTime issues and we got Crypto > published in v5.3. I believe the latest is 120. > > Though the versions are different, for readFrom:, they may well work the > same. I would consider it untested, but no cause for alarm. Seems to > work for my uses! > > k, r > > On 3/6/20 6:30 PM, David T. Lewis wrote: > > Hi Robert, > > > > I know this is no longer an issue for Cryptography, but I am responsible > > for the new internal representation of DateAndTime, so I want to follow > > up in case there are any remaining concerns. > > > > On Mon, Mar 02, 2020 at 05:55:20PM +0000, Robert via Squeak-dev wrote: > >> Yes, my former method extension DateAndTime>>#milliSecond accessed > >> #nanos. > I changed this to call #utcMicroseconds and changed the > >> name o fthe method to #milliseconds. This is in version 117 of > >> Cryptography that I had released. > > The accessor method for this is DateAndTime>>nanosecond. The #nanos > > instance variable no longer exists, but #nanosecond produces the same > > results as before and passes all unit tests. If you were to change your > > method to use self nanosecond rather than direct reference to the > > instance variable, then it should work as you expect. > > > >> The remaining issue is DateAndtime class>>#readFrom: which completely > >> changed implementations and also produced different results. This is > >> a failure of DateAndTime to migrate to a new internal representation, > >> while preserving identical results to former behavior. There are two > >> representations of DateAndTime in tthe test method under discussion. > >> One is the ASN1 representation and the other is an internet task force > >> accepted textual representation. The new #readFrom: misrepresents the > >> result from the textual representation. This is a clear error in core > >> DateAndTime, IMHO. The milliseconds are different, somehow. > >> > > Can you say specifically what was different versus the former behavior? > > There definitely are differences in the new implementation, but my > > expectation is that any differences should either fix problems or > > resolve ambiguities. > > > > Thanks, > > Dave > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |