June 2003 - Libraries

RE: Concerning Time.TimeDiff
by Graham Klyne 20 Jun '03

20 Jun '03

At 13:37 19/06/03 +0100, Simon Marlow wrote: >UTC is only a kludge for the fact that the Earth wobbles a bit on its >trajectory through space - I think that's a reasonable kludge :-) > >POSIX "seconds since the epoch" is a *real* kludge. Let's not get the >two confused. I think this is an important point, and thanks for pointing it up. Whatever we may decide about TimeDiff values, I think this indicates that a clocktime should *not* be a single integer. The minimal representation that avoids getting dragged into leap-second issues would seem to be, e.g., a pair of Integers (days and picoseconds). This also leaves me thinking that, completely aside from efficiency issues, that a TimeDiff should also be expressed in days and sub-days. I have two related reasons for this: (1) the point that I made previously that adding a TimeDiff of an exact number of days to a Clocktime should always result in a new Clocktime that yields the exact same time-of-day. (2) I assert that ct+dt (ct::ClockTime, dt::DiffTime) should always yield the same answer for any giver ct and dt. If dt is expressed only as a sub-day value (e.g. picoseconds) then the actual value depends on whether there is a leap second in the time interval [dt,dt+ct). But the occurrence of leap seconds is not known very far into the future, so if you try to take account of leap seconds you may end up with different answers depending on the state of knowledge at the time the calculation is performed. Ugh! #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

RE: Readline (was Re: state of ghc6 on sparc)
by Simon Marlow 20 Jun '03

20 Jun '03

> > > [SimpleLineEditor] > > > > It seems to behave strangely here: I can delete the > prompt, and if I > > move the cursor to the left and delete some characters, the > characters > > to the right of the cursor don't move. Also, the backspace > key doesn't > > work, although C-Backspace does work (backspace works fine with > > readline). This is in an xterm; in a cygwin shell window different > > strange things happen. > > There were a couple of bugs (now fixed) in the version I posted which > account for being able to delete the prompt, and for some strange > behaviour when retrieving history whilst in the middle of the line. > > But I'm also perfectly well aware that a different terminal > environment > might completely mess up some assumptions in the keystroke lexer. > For instance, in a gnome-terminal, ^H and backspace register as the > same single character, but in cbreak mode the former is echoed to > screen as two characters, whilst the latter is apparently echoed > as one. Or least, that was the case yesterday - today they seem to > be the same! > > Perhaps the best way to take care of such differences is by turning > off terminal echo, but sadly there is no portable Haskell'98 method > for that. Hmm. I'm highly dubious that this can be done portably enough to be worthwhile. The only way to get information about the terminal is by consulting termcap or terminfo, otherwise you're just guessing. Even Xterm itself differs in what keystrokes it generates between versions of XFree86, and even between vendor releases (RedHat IIRC uses its own key mappings in XTerm and has a special termcap entry). Isn't this just a pile of bug reports waiting to happen? Or a neverending maintenance headache? Cheers, Simon

2 1

RE: Readline (was Re: state of ghc6 on sparc)
by Simon Marlow 20 Jun '03

20 Jun '03

> Alastair Reid <alastair(a)reid-consulting-uk.ltd.uk> writes: > > > It would be nice to have those bindings but just having > backspace and > > left-right cursors work would already be a huge improvement > over nothing. > > OK, here is my contribution. The attached module SimpleLineEditor > is API-compatible with readline, and is a slight elaboration of > the line editor currently distributed as part of hmake interactive. It seems to behave strangely here: I can delete the prompt, and if I move the cursor to the left and delete some characters, the characters to the right of the cursor don't move. Also, the backspace key doesn't work, although C-Backspace does work (backspace works fine with readline). This is in an xterm; in a cygwin shell window different strange things happen. Cheers, Simon

2 1

RE: Concerning Time.TimeDiff
by Simon Marlow 20 Jun '03

20 Jun '03

> Well, my main problem with representing time as a pair, is that a > point in time isn't uniquely defined (e.g. should it be 3s + 5e-11ps, > or 2s + 5e-11ps), and that, in most suggested formats, they overlap > (e.g. 3s or 2s + 1e12 ps). So you need to normalize -- possibly after > each operation. Are you sure this is more efficient than using > bignums? > > Further, I'm not sure Haskell has a standard 64 bit Int. I'm fairly > sure it's in GHC, and probably in the other compilers, but it'd be > nice if it were in the standard. On the other hand, Integer can be > implemented any way that's efficient on each architecture. Haskell does have a standard 64 bit Int, known as Int64. (standard in the sense that the FFI addendum defines it, which is almost but not quite as standard as Haskell 98). If there are performance concerns, then we should measure both the version with an Int64 pair and the version with Integer. My guess is that there won't be enough of a difference for it to matter. > > I find it hard to lose sleep over missing leap-seconds and > dates beyond > > Leap seconds are a completely orthogonal issue. From the discussion > here, it seems plain that UTC is a kluge, and TAI is the way to go. > In any case, we already agree to counting seconds, the question is how > to count them :-) UTC is only a kludge for the fact that the Earth wobbles a bit on its trajectory through space - I think that's a reasonable kludge :-) POSIX "seconds since the epoch" is a *real* kludge. Let's not get the two confused. Cheers, Simon

5 6

RE: Concerning Time.TimeDiff
by Simon Marlow 19 Jun '03

19 Jun '03

> > ...and I don't think it's entirely given that two 64 bit > numbers will > > be faster than one Integer. > > I do. the implementation of Integer requires traversing additional > indirections to an array of bits, reading the size of the operands, > allocating space for the result, etc. It's a lot of work even if the > arguments and result are simple values like 0 or 1. I'm not sure I believe that. Compare: data T = T Int64 Int64 newtype T = T Integer In pure space terms, with GHC, the first rep takes 9 words. The second probably takes 8 words, assuming 3 words for the integer value. The second version is probably faster at most things, too. The fastest representation would be data T = T !Int64 !Int64 and compile with -funbox-strict-fields to remove two indirections and two unnecessary bottoms in the domain. Nevertheless, I still think this is all moot. Cheers, Simon

1 0

Data.Generics, instance Data Int?
by Markus.Schnell＠infineon.com 18 Jun '03

18 Jun '03

Hi, why are Float, Char and Bool instances of Data, but not Int or Integer? Markus -- Markus Schnell

2 1

RE: Concerning Time.TimeDiff
by Simon Marlow 18 Jun '03

18 Jun '03

> Simon Marlow wrote: > > John suggested using (pico)seconds since 1970-01-01 > 00:00:10 TAI. Isn't this equivalent to saying that ClockTime > is the number of > > seconds since 1970-01-01 00:00:00 UTC? > > Yes. > > TAI started ticking on 1 Jan 1958. > > UTC started ticking on 1 Jan 1972, and started 10 seconds > behind of TAI > (to keep it within 0.9 sec of UT1). So before 1 Jan 1972, UTC is defined as being the same as TAI? Or is it just undefined? Cheers, Simon

1 0

Fw: library infrastructure roundup (Alastair Reid)
by Dominic Steinitz 18 Jun '03

18 Jun '03

I meant to copy this to the libraries mailing list. Dominic Steinitz ----- Original Message ----- From: "Dominic Steinitz" <dominic.steinitz(a)blueyonder.co.uk> To: <alastair(a)reid-consulting-uk.ltd.uk> Sent: Tuesday, June 17, 2003 8:31 PM Subject: Re: library infrastructure roundup (Alastair Reid) > Alastair, > > I have put together a crypto library based on other people's contributions > so that you can use standard padding and modes with them. I'm currently > trying to find some web space to put the whole package in. I also haven't > got a CVS repository so that other people can add to it. It isn't finished > but there is nothing else out there (that puts things in one place and has > the modes and padding). I wanted to be able to use all the modules in > Codec/Encryption by saying -package crypto. > > Should I add it to your list in http://haskell.org/hawiki/LibrariesAndTools? > > Here's the instructions for using it: > > tar -xvf crypto.tar > > make depend > make > make install > make doc > > You will need to be root to make install. > > You should then be able to compile and run a test program from anywhere: > > ghc -o Test Test.hs -package crypto > ./Test > Testing DES... > Passed > Testing Blowfish... > Passed > > Dominic Steinitz > > >

3 2

RE: openFile and text mode vs. binary mode
by Simon Marlow 18 Jun '03

18 Jun '03

> On Tue, Jun 10, 2003 at 10:33:53AM +0100, Simon Marlow wrote: > > The question is: is this the interface that we want to expose from > > System.IO? Personally I have two criticisms: openFileEx is not a > > particularly descriptive name, and I don't see a reason for > IOMode to be > > nested inside IOModeEx. So I'd suggest this instead: > > > > openBinaryFile :: FilePath -> IOMode -> IO Handle > > Perhaps openFileAs? openBinaryFile sounds a bit like it would > only open it > as a binary, whereas in fact it actually gives you the option > of opening it > either as binary or as text. Well, my intention was that openBinaryFile would open the file as binary, and the ordinary openFile would open it in text mode. That is, we would get rid of the IOModeEx type. Cheers, Simon

2 1

RE: library infrastructure roundup
by Simon Marlow 18 Jun '03

18 Jun '03

Alastair Reid writes: > I agree that the decision lies with the people who package > libraries and must > conform with guidelines for the individual platform. But I > think that > compiler writers can help implement whatever decision those > people make. > > An easy way of doing this is for compilers to always consult > a configuration > file which says where globally and locally installed > libraries are located. Which is exactly what ghc-pkg does, right? (modulo the fact that per-user packages aren't supported well right now). > A ghc distribution might come with certain default locations > baked into it > but those would be overridden if the configuration file is > found. This is > easy for people packaging ghc to deal with because all they > have to do is > provide a config file which contains the platform preferences. You seem to have made a leap here - I still don't see why *another* configuration file is needed. The package.conf file that ghc-pkg knows about contains all the information the compiler needs to know about what libraries are installed. > Suppose we do this and you go to install a library. Where > should the library > be installed? Obviously, it should go in the place that the platform > maintainers prefer. How can you find where that is? By > consulting the configuration file. Here's where I disagree. Let's take FreeBSD's ports system as an example. When it builds something, it runs the configure script passing an appropriate value for $prefix. This is configurable - I can set PREFIX in /etc/make.conf to change what value is passed to the configure script. Why should I have to put this information in yet another configuration file, risking disaster if the two become out of sync? And why do we need another mechanism on top of what the ports system already provides? Cheers, Simon

1 0