June 2003 - Libraries

Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 08 Jul '04

08 Jul '04

Libraries people, There are currently two ways to create and communicate with external processes: - System.Cmd.system (very basic, doesn't give you access to the process's output but you can use shell primitives to redirect its input/output). - Posix.runProcess (can specify Handles for the process's input/output, but it doesn't create pipes so you can't actually communicate with the subprocess using these Handles.). - POpen.popen (can specify an input String, and gives you lazy output Strings. No interactive communication is possible.) Ok, *three* ways. System.Cmd.system, Posix.runProcess, POpen.popen, and shell-haskell. Er. *Four* ways. David Sankel's shell-haskell creates pipes for stdin/stdout/stderr, and lets you communicate interactively with the sub-process via Handles. It could do with a way to specify the environment and working directory of the sub-process (ala POpen and runProcess), but apart from that it seems to be the most flexible of the four. It could be simplified slightly by using one Handle rather than two for stdin/stdout. We should think about what functionality we want to provide in the core libraries. My preference would be to go for a full version with three pipes (like shell-haskell) and perhaps one or two more specialised versions covering common cases (I don't know what these should be, though). What do people think? Cheers, Simon -----Original Message----- From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of David Sankel Sent: 06 May 2003 03:06 To: haskell(a)haskell.org Subject: [ANNOUNCE] shell-haskell 1.0.0 =================== shell-haskell 1.0.0 =================== shell-haskell provides utilities to communicate with other process's via Haskell code. This library can be used for something as simple as getting the output of another program or as complex as interacting with an interpreter. see http://www.electronconsulting.com/shell-haskell for details. David J. Sankel _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

5 10

New Binary library
by George Russell 27 Jun '03

27 Jun '03

I attach a Binary library, the fruit of my earlier deliberations. Documentation is in the README file within, for now. Comments?

1 0

RE: Implementability and Time.TimeDiff
by Simon Marlow 25 Jun '03

25 Jun '03

> On reflection, I think this is too precise information to be > accessible from a portable library. In particular, I'm not sure it's > possible to correctly implement a TAI-based time system on most Linux > distributions without modification (I was rather shocked to discover > this...), Oh dear. Could you explain why it can't be implemented? What does the existing libtai do - is it incorrect? The glibc docs say: - Data Type: time_t This is the data type used to represent simple time. Sometimes, it also represents an elapsed time. When interpreted as a calendar time value, it represents the number of seconds elapsed since 00:00:00 on January 1, 1970, Coordinated Universal Time. (This calendar time is sometimes referred to as the "epoch".) POSIX requires that this count not include leap seconds, but on some systems this count includes leap seconds if you set `TZ' to certain values (*note TZ Variable::). but it doesn't elaborate on which TZ values cause leap seconds to be included in time_t, so I can imagine that would cause difficulties. Cheers, Simon

2 1

ANNOUNCE: Cryptographic Library for Haskell
by Dominic Steinitz 24 Jun '03

24 Jun '03

I would like to annouce the first release of the Haskell Cryptographic Library (0.2.0). See http://www.haskell.org/crypto/ReadMe.html for more details. This library collects together existing Haskell cryptographic functions and augments them so that they: · Have common type signatures. · Can be used with the standard mode and padding algorithms (in the case of block mode ciphers). This very initial release contains: · DES · Blowfish · Cipher Block Chaining (CBC) mode · PKCS#5 and nulls padding Dominic Steinitz

2 1

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

24 Jun '03

> On Monday 23 June 2003 05:35, Simon Marlow wrote: > > you can't accurately use > > addSeconds or addPicoseconds on a CalendarTime in the future without > > knowing where leap seconds occur. This is an interesting > bug/feature > > that I just realised. > Similarly, converting between ClockTime and CalendarTime in > time zones with > daylight savings is somewhat unpredictable. In my time zone, the > determination of when to set clocks ahead has changed a > couple of times in > the past 20 years. This is true; currently we rely on the C library for a correct implementation of this, and I think we have to continue to do that because it involves consulting the timezone data that usually comes with the OS (we don't want to have to install a load of timezone stuff with GHC, for example). One thing that you can't do with the current proposed interface is ask questions like "are they using daylight savings time in New York right now?". Indeed, the only way I know to do this on Unix is non-standard: > TZ=/usr/share/zoneinfo/America/New_York date Mon Jun 23 12:34:26 EDT 2003 Cheers, Simon

1 0

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

23 Jun '03

Graham Klyne writes: > 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). I'm afraid I don't see why this is necessary. The definition of ClockTime and TimeDiff in terms of TAI *is* independent of leap seconds: it is the conversion to/from CalendarTime that involves leap-second calculations. > 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. This would be provided for in the new library as the function addDays: see the OPTIONAL section at the end. > (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! I think I see what you're trying to do, but I don't think it's necessary. In the TAI proposal, you can do calculations on ClockTimes to your heart's content at arbitrary times in the future, and no accuracy is lost to unknown leap seconds. The only time accuracy would be lost is if you want to convert the ClockTime to a UTC-offset CalendarTime. Alternatively, you can do calculations on CalendarTimes at arbitrary points in the future without losing any accuracy (using the proposed addDays, addMinutes, etc.). HOWEVER, you can't accurately use addSeconds or addPicoseconds on a CalendarTime in the future without knowing where leap seconds occur. This is an interesting bug/feature that I just realised. Cheers, Simon

2 1

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

23 Jun '03

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > > > > [SimpleLineEditor] > > > > 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. > > I'm pretty sure that even termcap/terminfo does not contain the sort > of information we need. There are just too many layers of environment > to worry about. I'm not aware of any reason why termcap/terminfo aren't complete enough - could you give an example? After all, these are the only mechanisms available to readline and terminal apps. If the termcap says that the down arrow key produces a certain string, then that's the string you see in the input, AFAIK. Why not just write a binding to curses? (actually, doesn't one already exist? I seem to recall that there was one in QForeign). > > Isn't this just a pile of bug reports waiting to happen? Or a > > neverending maintenance headache? > > Yes, I expect so. But someone did have a plea that even some small > editing functionality would be better than nothing. So in the spirit > of "worse is better"... Hmm, sometimes worse really is worse :-) Cheers, Simon

1 0

Readline (was Re: state of ghc6 on sparc)
by Malcolm Wallace 23 Jun '03

23 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 does the basic stuff like backspace and left and right arrows. Today's addition was a simple history mechanism using (uggh!) an IORef. Because of the way I chose to implement a separation of keystroke-recognition from interpretation of the associated editing command, it should be reasonably straightforward to extend/change the keystrokes for different terminal types. It should also be fairly easy to add more editing commands (e.g. there are commands for word-movement, and begin/end of line, but no key-binding and no interpretation yet either.) Perhaps we should add something like this to the hierarchical libs, in the readline package? Then we can have some basic line-editing functionality available in a portable fashion, independent of whether any particular machine has the real readline library installed. Regards, Malcolm

2 1

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

21 Jun '03

> > in any case, since a pair of Int64's is not a clear win and > an Integer > > definatly is a clear win in terms of usability then I > believe we should > > go for that. > > It's a radical idea but... Maybe we could avoid all these > issues by using an > abstract type with all sensible instances (including Num > though it is only > semi-sensible for times). > > Internally, we might use Integer or two Int64s or we might > even add Int128 to > our compilers. Externally it looks like an Integral (or > Fractional?) type. Yes, I think that's a reasonable compromise. The accuracy is still specified to be picoseconds, but the representation is hidden. Any objections? Cheers, Simon

2 1

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

21 Jun '03

> On Mon, Jun 16, 2003 at 04:42:53PM +0100, Graham Klyne wrote: > > ... I think it's quite usual for people and applications to deal > > with a day as a consistent time interval without concern for > > possible leap seconds, so dealing with days as intervals of 24*60*60 > > seconds is useful for a majority of applications that deal with such > > intervals. > > What about the fact that days are not actually intervals of 24*60*60 > seconds (as I'm sure you know)? Most applications don't care, but > it's crucial to give correct and unsurprising results. > > I'm worried that the complexity to deal with leap seconds will end up > being just as complicated as the complexity to deal with more general > TimeDiff's as in the current library, in which case it may be > necessary to bite the bullet and specify the behaviour of TimeDiffs > completely and accurately. Agreed, this discussion tends to get rather vague at times, so I'd like to put it on a more concrete footing if I may. I've put together rough suggestion for a starting point for a replacement System.Time, appended below. Please comment! Cheers, Simon ------------------------------------------------------------------------ ---- -- * ClockTime -- | A representation of absolute time data ClockTime = ClockTime { ctSeconds :: Integer, ctPicoseconds :: Integer } deriving (Eq, Ord, Show, Read) -- | returns the current absolute time getClockTime :: IO ClockTime -- | Difference between two 'ClockTime's data TimeDiff = TimeDiff { tdSeconds :: Integer, tdPicoseconds :: Integer } deriving (Eq, Ord, Show, Read) -- | An empty 'TimeDiff' noTimeDiff :: TimeDiff -- | Returns the difference between two 'ClockTime's diffClockTimes :: ClockTime -> ClockTime -> TimeDiff -- | Adds a 'TimeDiff' to a 'ClockTime' addToClockTime :: ClockTime -> TimeDiff -> ClockTime {- Rationale: - TimeDiff is now an absolute measure of time period. Invariants: t1 `addToClockTime` (t2 `diffClockTimes` t1) == t2 t1 `addToClockTime` noTimeDiff == t1 t1 `diffClockTimes` t1 == noTimeDiff TODO: - This representation of TimeDiff is maybe not the best. Two other possibilities: use just picoseconds, or have the type be abstract with a way to extract picoseconds. - If we keep the seconds/picoseconds representation, should we specify that the TimeDiff returned by diffClockTimes is normalised? Should we provide a way to normalise a TimeDiff? -} ------------------------------------------------------------------------ ---- -- * CalendarTime data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer, ctTZ :: Timezone } deriving (Eq, Ord, Read, Show) data Timezone -- abstract -- | Make a 'Timezone' -- TODO: do we need to specify daylight savings time too? timezoneFromOffset :: Int -> Timezone timezoneFromName :: String -> Timezone timezoneOffset :: Timezone -> Int timezoneName :: Timezone -> String -- | Convert a 'ClockTime' to a 'CalendarTime' in the current timezone clockTimeToCalendarTime :: ClockTime -> IO CalendarTime -- | Convert a 'ClockTime' to a 'CalendarTime' in UTC clockTimeToUTCTime :: ClockTime -> CalendarTime -- | Convert a 'CalendarTime' to a 'ClockTime' -- TODO: can this raise an exception if the CalendarTime does not -- represent a valid time? Or should it return Maybe ClockTime? calendarTimeToClockTime :: CalendarTime -> ClockTime -- OPTIONAL: these are hard to implement, and require -- careful specification (see rationale below): addPicoseconds :: CalendarTime -> Integer -> CalendarTime addSeconds :: CalendarTime -> Integer -> CalendarTime addMinutes :: CalendarTime -> Integer -> CalendarTime addDays :: CalendarTime -> Integer -> CalendarTime addWeeks :: CalendarTime -> Integer -> CalendarTime addMonths :: CalendarTime -> Integer -> CalendarTime addYears :: CalendarTime -> Integer -> CalendarTime {- Rationale: - Adding "irregular" time differences should be done on CalendarTimes, because these operations depend on the timezone. - Need to define the meaning when the offset doesn't exist. eg. adding a day at the end of the month clearly rolls over into the next month. But what about adding a month to January 31st? -}

9 28