<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
The use case is the TimeZone's in DatePosix.m3.<BR>
It's not a big deal.<BR>
There are just two constant timezones, "local", and "utc", identified by references to integers: NIL, ^ = 1 and ^ = 0. Where NIL is interpreted as 0 or 1. It could just be an enum, but the public type is REFANY and it is revealed in the Win32 flavor to actually be a reference to something else. I could maybe change that. But what is the effect on pickles either way?<BR>
The Win32 one isn't picklable in either case?? I'm not sure. So Timezone isn't portably pickable? And therefore pickles of Posix timezones can be broken? If they were to be pickled, I think the representation is dubious -- probably should pickle the "offset" from GMT/UTC, not 0 or 1.<BR>
<BR>
<BR>
The Win32 code is also dubious given evolution of the Win32 API over the years. It is more flexible now and I wonder if that implies the old API was insufficient.<BR>
<BR>
<BR>
(Though "local" can change in time, not really "constant", as the daylight savings cutoff is crossed, or indeed when I travel with a computer and stuff says running but "asleep" and then "resumed". I'm quite suspicious that lots of code doesn't account for timezone changes. I'm also quite suspicious of any code that does anything timezone sensitive or uses "local" time for anything. Using GMT/UTC for everything, except display, is the way to go. It makes things vastly simpler and better defined. Could be that Unix/Posixy stuff is generally ok. Could be just an historical bogus favoring of localtime on PCs (and Macs?).)<BR>
<BR>
<BR>
I actually strongly suspect as well that we can get by with just the one Posix implementation of this stuff, no BSD, no Win32.<BR>
In particular, msvcr*.dll does expose tzname, timezone, daylight. Besides of course "small" localtime/gmtime.<BR>
Have to think though "Time" vs. "Date".<BR>
Win32 epoch is earlier, which is useful for representating dates in the past.<BR>
Basically "this stuff" is more about "Date" and less about "Time", though they interact.<BR>
<BR>
I'm pretty sure we have bugs as well where we assume the current "daylight" status applies to all times/dates.<BR>
<BR>
Switching to "time64" is part of the equation.<BR>
Maybe I should attack more from that angle. Make things work for Date{year := 2040} and see what all that implies.<BR>
<BR>
- Jay<BR><BR> <BR>
<HR id=stopSpelling>
From: hosking@cs.purdue.edu<BR>Date: Fri, 16 Apr 2010 10:30:48 -0400<BR>To: jay.krell@cornell.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] Modula-3/C interop in Date/Time?<BR><BR><BASE>
<DIV>What is the use-case here?</DIV>
<DIV><BR></DIV>
<DIV>Merely having UNTRACED references doesn't make your code unsafe. Using ADR does.</DIV>
<DIV><BR></DIV>
<DIV>But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C.</DIV>
<DIV><BR></DIV>
<DIV>e.g., C function</DIV>
<DIV><BR></DIV>
<DIV>f(int *ref p)</DIV>
<DIV><BR></DIV>
<DIV>can be declared as</DIV>
<DIV><BR></DIV>
<DIV><*EXTERNAL*> f(VAR i: INTEGER)</DIV>
<DIV><BR></DIV>
<DIV>and this is still safe.</DIV><BR><BR>
<DIV>
<DIV>On 16 Apr 2010, at 04:18, Jay K wrote:</DIV><BR class=ecxApple-interchange-newline>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxhmmessage>Isn't making them unsafe? ADR? I'll try..<BR><BR>- Jay<BR><BR>> To:<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>> Date: Fri, 16 Apr 2010 00:00:34 -0700<BR>> From:<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:mika@async.async.caltech.edu">mika@async.async.caltech.edu</A><BR>> CC:<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?<BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> I don't think there's anything unsafe about UNTRACED.<BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> It's DISPOSE that's unsafe...<BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> Mika<BR>><SPAN class=ecxApple-converted-space> </SPAN><BR>> Jay
K writes:<BR>> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_<BR>> >Content-Type: text/plain; charset="iso-2022-jp"<BR>> >Content-Transfer-Encoding: 7bit<BR>> ><BR>> >But then unsafe, right?<BR>> ><BR>> > - Jay<BR>> ><BR>> >> From:<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>> >> Date: Thu, 15 Apr 2010 22:06:14 -0400<BR>> >> To:<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</A><BR>> >> CC: m3dev<SPAN class=ecxApple-converted-space> </SPAN><A href="mailto:el@elegosoft.com">el@elegosoft.com</A><BR>> >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?<BR>> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> Indeed! UNTRACED.<BR>> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >><SPAN clas
s=ecxApple-converted-space> </SPAN><BR>> >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:<BR>> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> > Since these pointer variables are initialized by<BR>> >> > C code and their referents are also provided by C code<BR>> >> > as global variables, shouldn't the type be untraced?<BR>> >> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> > I suppose that, since they don't point into the traced<BR>> >> > heap, the collector implementation we have would quietly<BR>> >> > ignore them as roots. But that's relying on implementation-<BR>> >> > dependent information.<BR>> >> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> > Also, if someone created a field of type Date.TimeZone,<BR>> >> > (or an array of them) in a traced-heap-allocated object,<BR>>
> > which is a perfectly legitimate thing to do, what would<BR>> >> > our collector do then?<BR>> >> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> > Jay K wrote:<BR>> >> >> Is this legal/correct?<BR>> >> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> >> Date.i3:<BR>> >> >> TYPE TimeZone <: REFANY;<BR>> >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)<BR>> >> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> >> Date.m3: <BR>> >> >> REVEAL TimeZone
= BRANDED "Date.TimeZone" REF INTEGER;<BR>> >> >> <BR>> >> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> >> DatePosixC.c:<BR>> >> >> static const int Local = 0& #59;<BR>> >> >> static const int UTC = 1;<BR>> >> >> extern const int const * const Date__Local = &Local;<BR>> >> >> extern const int const * const Date__UTC = &UTC;<BR>> >> >> <BR>> >> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> >> >> - Jay<BR>> >><SPAN class=ecxApple-converted-space> </SPAN><BR>> ><SPAN class=ecxApple-converted-space> </SPAN><BR>> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_<BR>> >Content-Type: text/html; charset="iso-2022-jp"<BR>> >Content-Transfer-Encoding: 7bit<BR>> ><BR>> ><html><BR>> ><head><BR>> ><style><
!--<BR>> >.hmmessage P<BR>> >{<BR>> >margin:0px;<BR>> >padding:0px<BR>> >}<BR>> >body.hmmessage<BR>> >{<BR>> >font-size: 10pt;<BR>> >font-family:Verdana<BR>> >}<BR>> >--></style><BR>> ></head 2;<BR>> ><body class='hmmessage'>But then unsafe, right?<br><br> - Jay<br><br>> From: hosking@cs.purdue.edu<br>> Date: Thu, 15 Apr 2010 22:06:14 -0400<br>> To: rodney_bates&<BR>> >#64;lcwb.coop<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?<br>> <br>> Indeed! UNTRACED.<br>> <br>> <<BR>> >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:<br>> <br>> > Since
these pointer variables are initialized by<br>> & #38;#62; C code and their referents are also provided by C<BR>> > code<br>> > as global variables, shouldn't the type be untraced?<br>> > <br>> > I suppose that, since they don't point into the traced<br>> > heap, the collect<BR>> >or implementation we have would quietly<br>> > ignore them as roots. But that's relying on implementation-<br>> > dependent information.<br>> > <br>> > Also, if someon<BR>> >e created a field of type Date.TimeZone,<br>> ><BR>> > ; (or an array of them) in a traced-heap-allocated object,<br>> > which is a perfectly legitimate thing to do, what would<br >> > our collector do then?<br>> > <br><BR>> &g
t;> > <br>> > <br>> > Jay K wrote:<br>> >> Is this legal/correct?<br>> >> <br>> >> <br>> >> Date.i3:<br>> >> TYPE TimeZone<BR>> > <: REFANY;<br>> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)<br>> >> <br>> >&# 38;#62; <br>> >><BR>> > Date.m3:　<br>> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;<br>> >> 　<br>> >> <br>> >> DatePosixC.c:<br><BR>> >> >> static cons
t int Local = 0;<br>> >> static const int UTC = 1;<br>> >> extern const int const * const Date__Local = &Local;<br>><BR>> > >> extern const int con st * const Dat<BR>> > e__UTC = &UTC;<br>> >> 　<br>> >> <br>> >> - Jay<br>> <br> </body><BR>> ></html><BR>> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_--<BR></DIV></SPAN></BLOCKQUOTE></DIV><BR> </body>
</html>