Some failing tests in Squeak5.2alpha

On Wed, 13 Jun 2018, Fabio Niephaus wrote:

>
> Hi all,
>
> There might be more, but these tests fail in Squeak5.2alpha:
>
> DateAndTimeLeapTest>>#testAsSeconds

If you can answer the question "When the Squeak epoch is?", then this can
be fixed.

> DoubleWordArrayTest>>#testCannotPutTooLargeValue

Passes here on 64-bit linux. Probably a VM issue.

> UTF16TextConverterTest>>#testByteOrders
> UTF16TextConverterTest>>#testByteOrdersWithNonLatin

These two are related to the changes of UTF16TextConverter from April,
2017. The class side #initializeLatin1MapAndEncodings in TextConveter was
changed to assume that all TextConverter instances respond to #encode:,
but only ByteTextConveters do, and UTF16TextConveter is not a
ByteTextConveter.
The error raised is ignored during the execution of the method, because
errors are only expected to be raised at that point when the character has
no representation in the target encoding, so latin1Encodings will be
filled up with nil values, which means exactly that, the character cannot be
represented in that encoding.

Other converter tests (except for UTF8EdgeCaseTest) are failing, because
the class side tables are not initialized properly, or the encoding was
changed (MacRoman), but the tables were not updated. Those can be fixed
with an appropriate package post script, but UTF16TextConveter should be
fixed first, as that also uses the class side tables, even though it
shouldn't.

Levente

>
> If someone could have a look at them that would be great!
>
> Best,
> Fabio
>
>
>

Hi Levente,
On Wed, 13 Jun 2018 at 14:02, Levente Uzonyi <[hidden email]> wrote:
1 Jan 1901.

(I haven't looked at the test, I'm battling with file timestamps on
Windows in the VM at the moment).

HTH,
Alistair

Hi Alistair,

The everlasting debate is about the time zone. Some say it is UTC, others
say it is whatever time zone you're in. The test is failing, because it
expects the value for UTC, while the method it uses (#asSeconds) was
changed to use your current time zone.

Levente

On Wed, 13 Jun 2018, Alistair Grant wrote:

Hi Levente,

On Wed, 13 Jun 2018 at 14:34, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Alistair,
>
> The everlasting debate is about the time zone. Some say it is UTC, others
> say it is whatever time zone you're in. The test is failing, because it
> expects the value for UTC, while the method it uses (#asSeconds) was
> changed to use your current time zone.

I'm running short of time, apologies for the rushed answer:

The VM returns squeak time using the local timezone, as can be seen in
the conversion from unix time to squeak time on unix platforms:


time_t convertToSqueakTime(time_t unixTime)
{
#ifdef HAVE_TM_GMTOFF
  unixTime+= localtime(&unixTime)->tm_gmtoff;
#else
# ifdef HAVE_TIMEZONE
  unixTime+= ((daylight) * 60*60) - timezone;
# else
#  error: cannot determine timezone correction
# endif
#endif
  /* Squeak epoch is Jan 1, 1901.  Unix epoch is Jan 1, 1970: 17 leap years
     and 52 non-leap years later than Squeak. */
  return unixTime + ((52*365UL + 17*366UL) * 24*60*60UL);
}


Cheers,
Alistair

On Wed, Jun 13, 2018 at 02:34:10PM +0200, Levente Uzonyi wrote:
Putting an end to this kind of endless confusion is the reason that I
implemented UTCDateAndTime for Squeak.

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

  http://www.squeaksource.com/UTCDateAndTime/

Back when I did this in 2014, I considered it experimental. But after four
years of use, I cannot think of any good reason not to adopt it in trunk.
Maybe we can discuss some time after the 5.2 release.

Dave

On Wed, Jun 13, 2018 at 01:12:05PM +0200, Fabio Niephaus wrote:
If I could add one more to the list:

  SemaphoreTest>>testSemaInCriticalWait

This fails now, and was working in Squeak 5.1.

Semaphores and critical sections are important, so it would be good
to know if this test failure is a real problem, and if so is there
something we can do to correct it.

Dave

> > The everlasting debate is about the time zone. Some say it is UTC, others
> > say it is whatever time zone you're in. The test is failing, because it
> > expects the value for UTC, while the method it uses (#asSeconds) was
> > changed to use your current time zone.

Right or wrong, the DateAndTime's #epoch has always been defined in
terms of the local time, not GMT.  Until the "change" you mentioned (I
call it a fix), #asSeconds would report a different value for the same
exact DateAndTime instance depending on the timezone the client image
was running in.  Now, it doesn't.

It seems we all want a time-zone independent epoch, couldn't we define
#utcEpoch to do that.  The distinct name would clarify whatever
expectations people had on this matter.  Probably we could switch
#asSeconds to use it, but we should be careful...

> Putting an end to this kind of endless confusion is the reason that I

It's a complex domain topic, there's no avoiding some confusion at times.

> implemented UTCDateAndTime for Squeak.
>
>   http://wiki.squeak.org/squeak/6197
>
>   http://www.squeaksource.com/UTCDateAndTime/
>
> Back when I did this in 2014, I considered it experimental. But after four
> years of use, I cannot think of any good reason not to adopt it in trunk.
> Maybe we can discuss some time after the 5.2 release.

I also did as well in 2004, called "Ma time objects", with one
LargeInteger representing the number of milliseconds from the epoch to
represent a unique point on a timeline.  It seemed efficient at the
time, but those LargeIntegers sort of bogged down space and
computation relative to Chronology (which has an Array, but no
LargeIntegers), plus compatibility with Squeak objects, so I abandoned
it.

Is yours the same API as Chronology but just the different
implementation?  Are there any backward compatibility issues?

On Tue, Jun 19, 2018 at 06:07:07PM -0500, Chris Muller wrote:
Well, not quite always.

The implementation of the Smalltalk epoch is Squeak is, and always has
been, wrong. As near as I can determine, it resulted from some very early
corner-cutting in VM development that may have seemed reasonable at the
time, but is nevertheless wrong.

Eliot claims to have archival evidence of the definition of the "Smalltalk
epoch" that does not assume local time. This is less well documented than
we might like (after all, you cannot Google it), but at least it is not
completely wrong.

You cannot hack your way around this forever. At some point, you must
at least agree on a definable reference point for the epoch. This is
simply not possible with a Smalltalk epoch defined in local time.

I think it should be less confusing.


As far as I can tell, there is no inefficiency either in memory or
in speed. The UTCDateAndTime variation is overall about twice as
fast as the current implementation in Squeak, both for Spur and for
the old V3 format.

Yes the api is the same.

There are some backward compatibility issues. These are identified in
a small number of unit tests that fail, and that probably should fail
until we figure out what the right semantics should be.

Deserializing from ReferenceStream has been handled, but MA serializer
and Fuel serializer have not been addressed.

Dave