- Libraries - Haskell.org

RE: System.Time.Clock Design Issues
by Simon Marlow 03 Feb '05

03 Feb '05

On 03 February 2005 16:32, Scott Turner wrote: > "Simon Marlow" <simonmar(a)microsoft.com> wrote: >> You can still do accurate calculations on calendar times in the >> future, and that's what matters. > > However, the relationship between seconds and the future calendar is > not known. A specific second such as 2005-12-31T23:59:59 may turn out > not to occur. So even CalendarTime is not safe from leap seconds. Yes, I was aware of that but trying not to confuse the issue too much (I mentioned it in a later message). > On 2005 February 03 Thursday 08:00, Ashley Yakeley wrote: >> During the leap second, the system clock is >> stepped, and getClockTime returns the wrong TAI time converted to the >> wrong (by up to a second) UTC time. After the leap second, >> getClockTime continues to return the wrong TAI time, but it is >> converted to the correct UTC time. > > Until there's a system call that provides up-to-date information > about leap seconds, the above-quoted scenario can occur. Since > future conversions between calendar time and TAI are likely > incorrect, how about raising an exception? Actually I very nearly proposed that in an earlier message. You could also do the slightly less drastic: canConvertAccuratelyToCalendarTime :: TAI -> IO Bool and the reverse. Cheers, Simon

3 3

RE: System.Time.Clock Design Issues
by Simon Marlow 03 Feb '05

03 Feb '05

On 03 February 2005 10:44, Ashley Yakeley wrote: > OK, so we have > > * POSIX time > > Can do accurate calculations on calendar times. > Can store UTC times reliably. > Cannot store TAI times reliably. > Broken for all leap seconds. > > * TAI time with limited leap-second table > > Can do accurate calculations on calendar times. > Cannot store UTC times reliably. > Can store TAI times reliably. > Broken for leap seconds after table runs out. > > Which of these is better? The point is that everything you can do with a POSIX time you can also do with a calendar time, which we need anyway. So why have a POSIX time too? Cheers, Simon

3 3

RE: Text.PrettyPrint.HughesPJ inserting blank lines
by Simon Peyton-Jones 03 Feb '05

03 Feb '05

I recall that making 'empty' a unit for <> and <+> and $$ was one of my main goals in revising John Hughes's library. I recall also that it got more complicated than I expected, and I didn't feel very satisfied with the result, though it has worked pretty well for years. If anyone wants to peer into the implementation and add combinators along the lines of those below, that's fine with me. Vertical operations should be easier to do than horizontal ones, because the question of where to insert line breaks doesn't arise. Whether the code below does the job, I couldn't say without looking in detail -- and I'm hoping someone else will do that. It's crucial to maintain the property that you can print an arbitrary long document in bounded space. It would be a great service to also add Haddock documentation, please! Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Christian | Maeder | Sent: 02 February 2005 12:58 | To: Tomasz Zielonka | Cc: libraries(a)haskell.org | Subject: Re: Text.PrettyPrint.HughesPJ inserting blank lines | | Tomasz Zielonka wrote: | > This is ugly: | > | > x $++$ y = (x <> text "") $+$ text "" $+$ (text "" <> y) | > | > However, I don't know if it's OK that (show (empty $++$ empty) == | > "\n\n"). | | I want "empty" to be a unit of $++$ as well, so that | | -- | list version of '($++$)' | vsep :: [Doc] -> Doc | vsep = foldr ($++$) empty | | works. Therefore I suggest: | | -- | vertical composition with a specified number of blank lines | aboveWithNLs :: Int -> Doc -> Doc -> Doc | aboveWithNLs n d1 d2 = if isEmpty d2 then d1 else | if isEmpty d1 then d2 else | d1 $+$ foldr ($+$) d2 (replicate n $ text "") | | -- | vertical composition with one blank line | ($++$) :: Doc -> Doc -> Doc | ($++$) = aboveWithNLs 1 | | Cheers Christian | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

New HsDNS release
by Peter Simons 02 Feb '05

02 Feb '05

Find it here: http://cryp.to/hsdns/ Changes: * Moved into hierarchical namespace. * Cabalized.

1 0

RE: Time library design proposal
by Bayley, Alistair 02 Feb '05

02 Feb '05

> From: Keean Schupke [mailto:k.schupke@imperial.ac.uk] > > data Gregorian = Gregorian { > second :: Int, > minute :: Int, > hour :: Int, > dayOfMonth :: Int, > dayOfWeek :: Int, > weekOfYear :: Int, > monthOfYear :: Int, > Year :: Int } -- enumerations may make more sense for > dayOfWeek/monthOfYear I don't like the redundancy here. dayOfWeek and weekOfYear can (and should) be derived from the dayOfMonth+monthOfYear+year. Having to specify them in addition to the other fields is a major PITA, and one of the reasons the current CalendarTime library is so unsavoury (why do I need to say what day of the week it is? pah). 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. *****************************************************************

2 1

RE: Time library design proposal
by Bayley, Alistair 02 Feb '05

02 Feb '05

[Oops, replied only to Ashley, not to list.] > From: Ashley Yakeley [mailto:ashley@semantic.org] > > There's something to be said for representing date and time of day > separately in calendar time, something like this: > > data CalendarDate = CalendarDate ... > > data TimeOfDay = TimeOfDay ... > > data CalendarTime = CalendarTime > { > ctDate :: CalendarDate, > ctTime :: TimeOfDay > } > > On the other hand, it adds two levels of construction to CalendarTime. I'm not convinced. I think it would be simpler and just as functional to have just a CalendarTime and a Duration. You would represent a time by a Duration (i.e. time since midnight), and a day with no time component would be represented by that date at midnight. You could add a Duration to a CalendarTime to get a date-with-time. Durations have other uses (differences between two CalendarTimes, summing other Durations, etc), whereas a TimeOfDay is limited to a 24hr period. 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. *****************************************************************

1 0

Text.PrettyPrint.HughesPJ inserting blank lines
by Christian Maeder 02 Feb '05

02 Feb '05

I've found myself using "$+$ space $+$" in order to insert a blank line between two docs. There are probably other ways to do it. "(test "")" (and $$) instead of "space" (or $+$) also work in many cases (but not "empty"). Which way would be the best? Maybe one could add a further function "$++$" to do this and a list version "vsep" of "$++$"? Another idea might be something like a vertical space "vspace" so that several blank lines would be created by: $$ vspace $$ vspace $$ ... Cheers Christian

3 3

RE: Data.Graph patch
by Simon Marlow 02 Feb '05

02 Feb '05

On 31 January 2005 22:20, John Meacham wrote: > Here is a patch for Data.Graph which fixes an oversight in > graphFromEdges. graphFromEdges returns a function which turns vertexes > into nodes, but provides no way to go the other direction and figure > out which vertex goes with a node. I simply return the already created > function of type key -> Maybe Vertex in the tuple. > > I provided it as a new function > graphFromEdges' and left the old functionality under the old name. if > we don't care about backwards compatability, I'd recommend just > replacing the one that is already there since it is a more complete > interface and an easy transition for anyone currently using the > library. Does anyone care if we simply change the interface to graphFromEdges? Cheers, Simon

1 0

RE: Question about packages and GHCi
by Simon Marlow 02 Feb '05

02 Feb '05

On 02 February 2005 11:17, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >>> (1) When I try to add a package to ghc, I receive the >>> error message that a GHCi lib file cannot be found. >>> >>> > ghc-pkg -u -i fgl.pkg >>> Reading package info from "fgl.pkg"done. >>> Expanding embedded variables... done. >>> warning: can't find GHCi lib `HSfgl.o' >>> Saving old package config file... done. >>> Writing new package config file... done. >>> >>> The missing file `HSfgl.o' is located on the >>> current directory as well as in the directory >>> where all other .o and .a files for GHC are >>> kept (/usr/local/lib/ghc-6.2/). >> >> ghc-pkg is looking in the directories specified in the library_dirs >> field in fgl.pkg. HSfgl.o should be in one of those directories. > > This has puzzled me for a long time as well. I /always/ get this > warning message, even when the HSfoo.o file is in the correct place, > as listed in library_dirs. Strange. I just tried a simple example, and didn't get the warning, so at least it's not completely broken. Can someone who is getting this warning send me: the package config being fed into ghc-pkg, and an ls -l of each directory in library_dirs. Cheers, Simon

1 0

RE: Question about packages and GHCi
by Simon Marlow 02 Feb '05

02 Feb '05

On 02 February 2005 01:52, Martin Erwig wrote: > I apologize if this is the wrong mailing list to turn to, > but I would be grateful for any help with two problems > I have when trying to add a package to GHCi. (I wasn't able > to find sufficient information in the documentation for packages > http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html.) > > > (1) When I try to add a package to ghc, I receive the > error message that a GHCi lib fil cannot be found. > > > ghc-pkg -u -i fgl.pkg > Reading package info from "fgl.pkg"done. > Expanding embedded variables... done. > warning: can't find GHCi lib `HSfgl.o' > Saving old package config file... done. > Writing new package config file... done. > > The missing file `HSfgl.o' is located on the > current directory as well as in the directory > where all other .o and .a files for GHC are > kept (/usr/local/lib/ghc-6.2/). ghc-pkg is looking in the directories specified in the library_dirs field in fgl.pkg. HSfgl.o should be in one of those directories. > (2) Maybe related to the previous problem is the > following. When I start "ghci -package fgl", I receive > the following error message: > > Loading package base ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package haskell-src ... linking ... done. > Loading package fgl ... > > GHCi runtime linker: fatal error: I found a duplicate definition > for symbol > __module_registered > whilst processing object file > /usr/local/lib/ghc-6.2/HSfgl.o > This could be caused by: > * Loading two different object files which export the same > symbol > * Specifying the same object file twice on the GHCi command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > GHCi cannot safely continue in this situation. Exiting now. > Sorry. I vaguely remembered seeing this before... googling for 'duplicate __module_registered' turned up this: http://www.haskell.org/pipermail/glasgow-haskell-users/2003-December/006 042.html which indicates that perhaps you should add -x to ld when building HSfgl.o? What version of GHC is this, BTW? Cheers, Simon

3 2