Squeak-dev February 2006

squeak-dev@lists.squeakfoundation.org

141 participants
278 discussions

Re: Discovering the Local Time Zone--Why It's a Hard Problem
by David T. Lewis 04 Feb '06

04 Feb '06

On Thu, Feb 02, 2006 at 11:10:21PM -0800, Alan Lovejoy wrote: > I have posted an essay on the matter of discovering the host system's time > zone, so that either the VisualWorks or Squeak VM and/or image might be able > synchronize with it. The essay is entitled "Discovering the Local Time > Zone--Why It's a Hard Problem." > > The essay can be viewed at the following link: > <http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It > 's%20a%20Hard%20Problem.html> > http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It' > s%20a%20Hard%20Problem.html. > > I thought this subject might be of some interest to the Squeak community. > > --Alan Thanks Alan, very nice writeup. Here is some additional Squeak-specific info: If you load TimeZoneDatabase from SqueakMap, there is documentation of the oddities of time zones, daylight savings time, and leap seconds as they pertain to Squeak. These are found in class TimeTransformTest, method category "documentation": Squeak Seconds Clock ------------------------- The Squeak seconds clock represents the number of seconds since the Smalltalk epoch. The Smalltalk epoch is defined as 1 January 1901. The current value of this clock is available by evaluating Time class>>totalSeconds, which calls the ioSeconds() function in the Squeak virtual machine to obtain the current local time from the underlying operating system. This is a wall-clock time, in the sense that the Squeak seconds clock corresponds to the setting of a clock on the wall located (geographically) in the current time zone. When a daylight savings time (DST) transition occurs, the hands on the wall clock are moved either forward or backward. Similarly, the Squeak seconds clock will jump forward or backward whenever a DST transition occurs. The current Time in Squeak will also jump forward and backward when DST transitions occur. Of course actual time proceeds forward relentlessly, but the display of time on the wall clock will have changed in order to make timekeeping more meaningful in the local time zone. Likewise, the displayed value of DateAndTime in Squeak will have suddenly adjusted itself to match the wall clock display. In addition to DST transitions, leap seconds are occasionally added to or removed from the world calendar. In principle, the seconds hand on the wall clock is moved forward or back by one second whenever a leap second is defined. Likewise, the Squeak seconds clock is (or should be) adjusted forward or back when leap seconds occur. It is also possible to define a notion of time as a magnitude, independent of all of the adjustments that are made to wall clocks in various locations around the world. Class PointInTime represents this universal clock, and uses the convention of describing a point in time as the total elapsed seconds since 1 January 1, 1970 in the UTC time zone. These are seconds as would be reported by a very accurate Caesium clock located in Greenwich, England. These seconds increase continuously without regard for geographic time zones, daylight savings time changes, or leap second adjustments used for local displays of time on wall clocks. It is always possible to derive the value of the Squeak seconds clock from a PointInTime, given information about the local time zone offset and leap seconds that are in effect as of that PointIntTime. The TimeZoneDatabase provides this information. For any PointInTime and LocalTimeTransform (time zone), the local time zone offset and leap second count are known, and the Squeak seconds clock can be calculated. However, the reverse transformation (Squeak seconds clock to PointInTime) is not possible in the general case. To understand why, consider the case of a Squeak system at 150 minutes (2 1/2 hours) after midnight on Sunday, 31 October, 2004 in an Eastern Standard Time time zone. This is a half hour after the "fall back" time zone change at the end of summer. Assuming that we have kept track of our local time zone and leap seconds, this occurs at the PointInTime 1099204222 seconds after 1 January, 1970. If we check the Squeak seconds clock at this point in time, it reports 3276639000 seconds. This is all well and good, but exactly one hour earlier the DST transition had not yet happened. The PointInTime was 1099200622 seconds, and the Squeak seconds clock was 3276639000, exactly the same value as the Squeak seconds one hour later. Thus the Squeak seconds clock had the same value at two completely different points in time. Therefore there are periods of time during which it is not possible to determine which of two points in time is the correct PointInTime for the Squeak seconds clock. It is of course possible to add a primitive to Squeak that makes the current PointInTime available directly. This, in conjunction with the information in the TimeZoneDatabase, provides enough information to do transformations from PointInTime to Squeak seconds and back without ambiguity. Alternatively, a primitive that reports current time (either UTC or local) along with current time zone offset provides the required information. As a related note, operating systems may not report time zone offset correctly for points in time that occur outside of the current DST setting. But if TimeZoneDatabase is available in the Squeak image and a UTC seconds primitive is added, then Date and Time transformations can be reliably calculated for any PointInTime within the domain of the TimeZoneDatabase transforms. UTC seconds clock -------------------- UTC is a measure of time corresponding to the angular rotation of the earth. As such, it is not a measure of time as measured by an atomic clock. UTC time is kept in synchronization with atomic time by the occasional insertion (or removal) of leap seconds in the UTC clock, although historically other methods of adjusting the clock (e.g. "elastic seconds") have been used, and the term "UTC" has had various definitions over the years. The distinction between rotational time (UTC) and atomic time can often be ignored. However, for purposes of physics and astronomy, they are different concepts and the small numerical differences between the two are significant. Posix seconds are similar to UTC seconds, but are defined in such a way that leap seconds are ignored. The Posix seconds clock is thus effectively a "wall clock" representation of seconds, for which the Posix clock is adjusted forward or back when a leap second occurs. This is similar to the seconds clock in early Unix systems, which were designed prior to the invention of leap seconds. Class PointInTime is intended to represent atomic time, such that time can be treated as a magnitude. Posix time varies from an atomic seconds clock as leap seconds are applied. For this reason, the conversion from PointInTime to and from Posix seconds should show a difference corresponding to the number of leap seconds that have been applied since 1 January, 1970. If leap seconds are ignored, then Posix time and PointInTime seconds produce the same count of seconds. Many time zone tables ignore leap seconds, and many computer operating systems likewise ignore the issue. For example, the LocalTimeTransform for "right/America/Detroit" in a TimeZoneDatabase contains leap second rules, while the "posix/America/Detroit" transform always answers zero leap seconds. Both refer to the same geographical time zone, and for practical purposes the "posix/America/Detroit" transform is an appropriate choice to describe the time zone rules for Detroit, Michigan. The LocalTimeTransforms in the TimeZoneDatabase contain transforms with or without leap second tables. The "posix/America/Detroit" transform ignores leap seconds, and is appropriate for a platform that is configured according to Posix specifications, while the "right/America/Detroit" transform accounts for leap seconds and provided a more realistic count of actual elapsed seconds since the Posix epoch. It should not be assumed that the operatings system on which Squeak is hosted will handle leap seconds consistently. BSD Unix systems (including FreeBSD and Mac OSX) define the time_t system clock to represent atomic clock seconds and providing time2posix() and posix2time() functions for converting to and from Posix seconds. This allows correct counting of actual seconds since the Posix epoch. Other Unix and Linux systems may ignore leap seconds, and other operating systems may also handle leap seconds differently. For purposes of converting Time and Date in Squeak to and from PointInTime seconds, we assume that Squeak will report its second clock as Posix seconds offset by the current time zone offset, regardless of the operating system and virtual machine on which it is running.

1 0

3.9 feature voting round
by Cees De Groot 04 Feb '06

04 Feb '06

I still have that old "voting" software I once wrote as a proof-of-concept of what we could do with SqP's web of trust. I thought it'd be neat to do a round of voting about what should land in v3.9, now that the 3.9a team is considering going to beta. The team also thought it'd be need to get some structured input, so I cleaned up the database and it's now available for voting. The idea is simple: - Go to http://de-1.tric.nl/seaside/sqp/list - Login with your Squeak People account - Create an issue or vote on issues. You will see the number of votes you have constantly updated. Note: I haven't yet added the possibility to delete issues, and if you add an issue, you have to allocate at least one vote to it. So think before creating issues! In fact, you can't even edit an issue - which is logical, otherwise you could rig the voting (editing an issue should logically imply losing all votes that were on it before the issue). The SqP angle is that the higher your ranking, the more votes you get - Observers get none, Apprentice gets 5, Journeyer 10, Master 15. This is an entirely unfounded distribution and I'm not going to debate it here ;-). Note: this voting round serves two purposes: - Advise, I repeat: advise, the 3.9a team. They're entirely free to completely ignore the outcome of this stuff, although if many many many people vote for something and they don't do it, it'd be nice if they'd give a reason; - Check whether this sort of utility is useful. The software can be found in the SqueakPeople repository on SqueakSource. Have fun! Cees

23 45

Re: parallel port access on Linux
by Serge Stinckwich 04 Feb '06

04 Feb '06

Jecel Assumpcao Jr a écrit : > I was easily able to use the parallel port from Squeak in Windows with > the DLL and change set from the IOST package at > http://www.smalltalking.net/Goodies/Squeak/ > > Some people, however, are asking for my help getting this to work on a > Linux machine. There was a thread here in April 15 of last year with > some code posted by Thimon and there have been similar threads in the > past including some advice by Ned Konz. Since there are many > alternatives, all require at least some work and none which is obvious > superior to the others, it would be great if people could share their > experiences and/or insights about this. > Yes, we made some work on parallel port in order to link Squeak to robotic modules. Look at our SqueakBot project here : http://www.iutc3.unicaen.fr/serge/SqueakBot -- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##

3 3

Re: parallel port access on Linux
by Alan Grimes 04 Feb '06

04 Feb '06

Linux is so evil that I can't access my parallel port in any way from any program. -- and it never gives an error message when I try to print a test-page from the KDE utilities... -- Don't let your schoolwork get in the way of your learning. http://users.rcn.com/alangrimes/ (for some reason Charleston SC is back in my signature... I hope you don't learn why...)

1 0

[Off Topic] Google and fair access to information
by Juan Vuletich 04 Feb '06

04 Feb '06

Hi Folks I apologize for being so off topic, but I hope this is important for you. Please check http://images.google.com/images?q=tiananmen+square and compare with http://images.google.cn/images?q=tiananmen+square . I am worried. I thought we could trust google. Regards, Juan Vuletich

5 8

Re: Remove Changes/Sources files in end-user distribution
by Fournier Eric 03 Feb '06

03 Feb '06

>>> The question is: can I get away with not including either of >>> these files in an installation where some classes/methods will be >>> re-compiled via update streams? >>> >> >> Yes. >> >> >>> Is there some hidden necessity to having these two files present >>> in the installation? >>> >> >> No. >> >> You might want to look at the Squeakland distribution, it does not >> include source files either. >> > > Before relying on this, it would be advisable to remove your source > files and *then* recompile the entire system (...recompileAll...). > This should work fine, but I don't know that current maintainers do > this kind of stress test (it is demanding of the decompiler) at > every release. > > - Dan > Hm. I start seeing syntax errors as soon as I get into Tweak classes. Worked when sources/changes were in place (it's the missing changes file). The errors are on Tweak annotations like: CAssignmentTileCostume>>onPropertyChanged <on:in:: #(#propertyChanged #player)> self player property borderStyle: #none. self signal: #updateEverything (second line gets: <on:in> expected ->:: #(#propertyChanged #player)> ) With the Changes file in place, I see: onPropertyChanged <on:in:: #(#propertyChanged #player)> self player property borderStyle: #none. self signal: #updateEverything So, it seems the changes file is providing some annotation syntaxia that goes missing without it, making annotated Tweak classes un- compilable. Seems to be happy without Sources, however. Thanks for the tip: this averted a bad decision. -- Eric

2 1

Re: parallel port access on Linux
by Jecel Assumpcao Jr 03 Feb '06

03 Feb '06

I wrote: > Serge Stinckwich wrote on Fri, 03 Feb 2006 20:54:58 +0100 > > Yes, we made some work on parallel port in order to link Squeak to > > robotic modules. Look at our SqueakBot project here : > > http://www.iutc3.unicaen.fr/serge/SqueakBot > > That looks perfect, thanks! I will forward this to the group at the > University of São Paulo doing this work and since what they are doing is > so similar to this I think they will be doubly pleased to see this. The image/changes pair segfaults for me in 2038523660 ParallelPortUnix>readData 2038523568 Moebus>highSDA 2038523476 I2CHandler>start 2038523384 I2CHandler>readFrom: 2038523292 Smec>statusByte 2038523200 Smec>status 2038523016 SmecMorph>step 2038522188 Morph>stepAt: [....] while trying to start up, which isn't surprising given that I don't have "parallelplugin" which it tried to call. The sources only include .mcz packages, so it isn't very obvious to me how to get that. -- Jecel

1 0

Re: parallel port access on Linux
by Cees De Groot 03 Feb '06

03 Feb '06

I have some C++ code that works under Linux, but I only used that to drive a couple of relays attached to the parallel port. http://www.cdegroot.com/photo-linuxdr/ - maybe not exactly what you're looking for, but it might just contain enough hints :) On 2/3/06, Jecel Assumpcao Jr <jecel(a)merlintec.com> wrote: > I was easily able to use the parallel port from Squeak in Windows with > the DLL and change set from the IOST package at > http://www.smalltalking.net/Goodies/Squeak/ > > Some people, however, are asking for my help getting this to work on a > Linux machine. There was a thread here in April 15 of last year with > some code posted by Thimon and there have been similar threads in the > past including some advice by Ned Konz. Since there are many > alternatives, all require at least some work and none which is obvious > superior to the others, it would be great if people could share their > experiences and/or insights about this. > > -- Jecel > >

2 1

parallel port access on Linux
by Jecel Assumpcao Jr 03 Feb '06

03 Feb '06

I was easily able to use the parallel port from Squeak in Windows with the DLL and change set from the IOST package at http://www.smalltalking.net/Goodies/Squeak/ Some people, however, are asking for my help getting this to work on a Linux machine. There was a thread here in April 15 of last year with some code posted by Thimon and there have been similar threads in the past including some advice by Ned Konz. Since there are many alternatives, all require at least some work and none which is obvious superior to the others, it would be great if people could share their experiences and/or insights about this. -- Jecel

1 0

The Weekly Squeak, Light Edition No. 19: December 25th - December 31th
by Giovanni Corriga 03 Feb '06

03 Feb '06

Dear squeakers, Hello, and welcome back to The Weekly Squeak, a weekly report on what's going on in the world of Squeak. We're back! Due to some personal problems of some member of the News Team (mostly of its team leader, who was and still is swamped in pre-graduation work), we had to suspend the pubblication of The Weekly Squeak. In the coming days, we'll try to recover with the pubblication of Light Editions of TWS. These light editions will contain pointers to interesting and useful messages which have been sent to the various Squeak-related mailing lists. If you'd like to volunteer some time to submit newsbits or article, please feel free to join us on news(a)lists.squeakfoundation.org . In this issue you'll find: 1. The Squeak Foundation and the Squeak License 2. New release of the Chronos Date/Time library, now under MIT license 3. Binary Tree packages compared 4. Squeak video and webcam support 5. A SmallLint extension for expected failures 6. A recap on persistence strategies in Seaside applications 7. GestionImmo: a Pier based application 8. A library for POSIX file handling You'll find the complete report at http://minnow.cc.gatech.edu/squeak/5740 . The past issues archive can be found at http://minnow.cc.gatech.edu/squeak/5751 . The Weekly Squeak has an RSS feed: http://people.squeakfoundation.org/person/gcorriga/rss.xml .

1 0

Jump to page: