February 2005 - Libraries

RE: Time Libraries Rough Draft
by Simon Marlow 14 Feb '05

14 Feb '05

On 10 February 2005 12:12, Marcin 'Qrczak' Kowalczyk wrote: > Seth Kurtzberg <seth(a)cql.com> writes: > >> The simple fact that UTC time is not monotonically increasing causes >> a whole host of difficulties. > > And the simple fact that obtaining TAI from systems in use requires > periodic updates of the leap second table causes other difficulties. This is a vitally important bit of rationale which has emerged from the current discussion. I certainly didn't fully appreciate the difficulties with basing the library on TAI before, and I imagine others won't too. I think it's important that we clearly state this rationale in the docs for the new library. Cheers, Simon

13 23

RE: registration tricks (cabal)
by Simon Marlow 14 Feb '05

14 Feb '05

On 14 February 2005 03:02, Isaac Jones wrote: > So I'm thinking of adding a flag to register and unregister, maybe > --dry-run or something which does _not_ register right away, but > rather emits such a script. This is actually a pretty small change, > but I wanted to check with you folks before adding it, since we're so > close to a release. > > Does anyone see any problems with this? Seems reasonable to me. You might want to make the script self-contained, though, i.e. have it actually include the contents of .installed-pkg-conf to avoid the complication of having a separate file which you have to locate. Cheers, Simon

1 0

Re: Time Libraries Rough Draft
by Udo Stenzel 14 Feb '05

14 Feb '05

Ashley Yakeley <ashley(a)semantic.org> schrieb am 11.02.05 21:39:42: > > The most obvious functions in Calendar are going to be these: > > utcToCalendar :: TimeZone -> UTCTime -> CalendarTime > calendarToUTC :: TimeZone -> CalendarTime -> UTCTime And what would you do with the "UTCTime", whatever that is? You can't do arithmetic on it, because that is full of surprises, not only around leap seconds, but also around leap hours and days. You can only store it and read it back, but that can already be done with the CalendarTime itself. I think, the most useful operations are those that "roll" the calendar fields, say to advance by a day (which is not always 24 hours long). Converting a CalendarTime to a number of seconds is just useless, the apparent simplification only introduces complications. Udo. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

3 2

registration tricks (cabal)
by Isaac Jones 13 Feb '05

13 Feb '05

Mighty Haskellers, I'm afraid we've never had a very good story about how to run "register" and "unregister" on a target machine which is different from the machine that a cabal package was built on. This comes up when building Debian or RPM packages which get copied into a temporary location, packaged up, and shipped off to an end user's machine. The closest I've come is to say that after installing into a temporary directory, you should bring the Setup script (and the .cabal file, and the .installed-pkg-info file) along and rerun it on the target machine, which probably has cabal anyway. This should work fine, but it's a little heavy handed for a one-line call to ghc-pkg. Yesterday someone suggested that instead of doing this, we could emit a little shell script / batch file (which might even contain the .installed-pkg-info file) and just run that on the target machine. So I'm thinking of adding a flag to register and unregister, maybe --dry-run or something which does _not_ register right away, but rather emits such a script. This is actually a pretty small change, but I wanted to check with you folks before adding it, since we're so close to a release. Does anyone see any problems with this? peace, isaac

1 0

Calendar Types
by Ashley Yakeley 12 Feb '05

12 Feb '05

OK, so here are the basic functions of System.Time.Calendar: utcToCalendar :: TimeZone -> UTCTime -> CalendarTime calendarToUTC :: TimeZone -> CalendarTime -> UTCTime CalendarTime should be a "struct", i.e. a datatype with its constructor and access functions exported. Here's a "flat" definition: data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Int, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer } deriving ... This has a certain simplicity to it. Alternatively, there's this: data TimeOfDay = TimeOfDay { todHour :: Int, todMin :: Int, todSec :: Int, todPicosec :: Integer } deriving ... data CalendarDay = CalendarDay { cdYear :: Int, cdMonth :: Int, cdDay :: Int } deriving ... data CalendarTime = CalendarTime { ctDay :: CalendarDay, ctTime :: TimeOfDay } deriving ... This has an extra level of complexity, but also some advantages: * It's more internationalisation-friendly, as TimeOfDay can be reused in other kinds of calendar. In fact, CalendarTime could be parameterised with a typevar replacing "CalendarDay". * CalendarDay and possibly TimeOfDay are useful types by themselves, for instance dayToCalendar :: JulianDay -> CalendarDay Other questions: * Should we include a timezone field in CalendarTime? * Should the "year" field be an Integer instead of an Int? Assuming Int=Int32, it gives us 2*10^9 BCE to 2*10^9 CE. The age of the universe is about 13.7*10^9 years. The age of the earth is about 4.6*10^9 years. * TimeZone represents a fixed offset to UTC. What should it look like internally, and what functions on it should we provide? -- Ashley Yakeley, Seattle WA

2 1

RE: Time Libraries Rough Draft
by Bayley, Alistair 12 Feb '05

12 Feb '05

> From: Seth Kurtzberg [mailto:seth@cql.com] > > The problem is that it has been stated several times on this > thread that there will be no leap second table, nor a way to > use one. That's not my understanding (but then I do fid it hard to follow _everything_). Ashley's proposed API has the following: module System.Time.LeapSeconds ( ... ) where ... utcDayLength :: LeapSecondTable -> JulianDay -> DiffTime utcToTAITime :: LeapSecondTable -> UTCTime -> TAITime taiToUTCTime :: LeapSecondTable -> TAITime -> UTCTime Of course, where the LeapSecondTable comes from is another problem... Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

5 7

Text.Regex.Posix exposes too little
by Peter Simons 11 Feb '05

11 Feb '05

Hi, I was wondering why Text.Regex.Posix does not expose the Ptr interface to the regular expression library? Is there a deeper reason for that? I am also worried about the fact that the module uses finalizers to free-up unused expressions -- rather than providing a bracket-style withRegex :: String -> Int -> (Regex -> IO a) -> IO a function. Last but not least I see that the regex flags are represented as an 'Int'. I don't feel strongly about this, but IMHO a data RegexFlag = IgnoreCase | Newline | ... data type with an appropriate declaration for Enum would be nicer for this purpose. Unless there is violent opposition, I'd volunteer to make those changes, because as it happens I need them anyway. ;-) Peter

1 0

RE: Cabal package descriptions
by Simon Marlow 11 Feb '05

11 Feb '05

On 10 February 2005 18:39, Isaac Jones wrote: > I'm still a bit worried; I suspect the Distribution.Make stuff is out > of date, and if we're under a freeze already then that should probably > go away. setup sdist has bitrotted too, and I don't have a hugs test > suite yet. > > The change I made to add preprocessors to UserHooks is pretty > important, IMO. > > I can definitely release cabal separately; I have maintained an > independent tree, as you know, but there are obviously problems with > this. Are we under a code freeze right now? Can we get another > weekend to hack on it? The GHC 6.4 release is way overdue. We originally planned to push it out in Aug last year, and it's now been over a year since the last major release of GHC! I suppose given that, another couple of weeks won't hurt :-) What is important, as I see it, is that the version of Cabal we ship with GHC - can support building & registering 3rd party packages for some time to come - will be compatible with future enhancements to Cabal. That is, packages which work with this version of Cabal will also work with future versions (maybe until the next *major* release of Cabal, at least). So the second point means that the syntax we use for .cabal files, and the Distribution.* API, have to be supported for some time to come. We should be clear about which parts of the Distribution.* API are actually supposed to be stable, BTW. Cheers, Simon

2 1

RE: Time Libraries Rough Draft
by Simon Marlow 11 Feb '05

11 Feb '05

On 11 February 2005 10:11, Seth Kurtzberg wrote: > The problem is that it has been stated several times on this thread > that there will be no leap second table, nor a way to use one. If > that's not correct, then there is no problem. I think you've misunderstood. The plan was never to get rid of TAI altogether; the discussion has been about whether getCurrentTime should return TAI or something UTC-based. In case you missed it, here's Ashley's latest proposal, which includes full support for TAI and leap second tables: http://www.haskell.org//pipermail/libraries/2005-February/003158.html Cheers, Simon

2 1

RE: Time Libraries Rough Draft
by Simon Marlow 11 Feb '05

11 Feb '05

On 11 February 2005 01:54, Seth Kurtzberg wrote: > We are getting bogged down in the terminology here. My problem is > that, as proposed, the library will give wrong answers. Having a > nanosecond granularity library that can't even manage one second > accuracy doesn't seem useful to me. Apparently, though, I'm in the > minority here, so I'll let it go. > > The comment about scheduling is not correct, because the leap year > correction is always available. To me, it is more important to get > the correct answer when, say, finding the amount of time that has > passed from one timestamp to another. I can't see the logic in a > library that returns incorrect answers, because to return correct > answers is more difficult. > > I guess those people who intend to use it don't care if the interval > results are correct. I do care, but I'll have to implement it myself > since I appear to be a minority of one. I don't see why you claim the library will produce incorrect answers. It will produce answers exactly as correct as the OS interfaces on which it is based. If you want to do accurate interval calculations then you have to use TAI, and if you need to convert between TAI and UTC then you also need appropriate leap second tables to hand. The library allows you to do this, and the documentation for the library will explain exactly why you have to use TAI if you need to do this. So what's the problem? Cheers, Simon

2 1