Re: Posix.FileStatus: st_rdev from struct stat is missing
Mon, 12 Jun 2000 11:12:50 -0700, Sigbjorn Finne <[EMAIL PROTECTED]> pisze:
> An implementation of UNIX 9? (aka the single UNIX spec) for Haskell
> would be a Fine Thing (but is there a demand?)
IMHO generic FFI should settle before. Then I would be glad to take
part in making such interface.
I just wanted to make a ls-like directory listing. Posix lacks symlinks,
sticky bits and device id of device files. SUSV2 still seems to lack
any interpretation of device id (major/minor), so device id cannot be
portably printed in a nice way.
It's annoying that to get an unsupported bit of information from Posix
types (like st_rdev or S_ISLNK), the only way that does not depend on
implementation of Haskell's Posix module is to rewrite an interface to
a C function together with marshalling relevant C types from scratch.
--
__("$ P+++ L++>$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
RE: Posix.FileStatus: st_rdev from struct stat is missing
[EMAIL PROTECTED] writes: > > Sorry if I asked this before, but I could not find the answer now: > are POSIX specifications freely available somewhere? > The last time I looked, you had to pay IEEE in order to have them send you a copy. Or get Donald Lewine's O'Reilly book on Posix.1, it's quite useful. An implementation of UNIX 9? (aka the single UNIX spec) for Haskell would be a Fine Thing (but is there a demand?) --sigbjorn
Re: Posix.FileStatus: st_rdev from struct stat is missing
Mon, 12 Jun 2000 09:36:33 -0700, Sigbjorn Finne <[EMAIL PROTECTED]> pisze:
> None of these are POSIX supported (same with st_blksize.)
Ah.
Sorry if I asked this before, but I could not find the answer now:
are POSIX specifications freely available somewhere?
It would be nice to have module(s) Unix, providing parts of the
interface of e.g. The Single UNIX(R) Specification, as an addition to
Posix (i.e. the same FileStatus would have additional fields visible,
and lstat would be there).
--
__("$ P+++ L++>$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
RE: Posix.FileStatus: st_rdev from struct stat is missing
None of these are POSIX supported (same with st_blksize.) --sigbjorn Sven Panne <[EMAIL PROTECTED]> writes: > > Marcin 'Qrczak' Kowalczyk wrote: > > The subject says all. > > st_blocks is missing, too. But I'm unsure about versionitis here, > so could some POSIX guru enlighten us on those fields? Are they > guaranteed to exist on all OS versions or must configure.in come > to the rescue? > > Cheers, >Sven > >
Re: Dynamic and persistent data storage
Mon, 12 Jun 2000 20:42:16 +1000 (EST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> pisze:
> To do this would require several things the current Dynamic library lacks:
[...]
I think it's much harder. How would you store and restore actual data?
It depends on its real type, and for many types it's impossible or
impractical ((->), IO, ForeignObj, Handle, MVar, ThreadId), even if
in some sense every part of the value is already evaluated.
OCaml's values look a bit simpler. There exist functions for dumping
and restoring almost any values, even with cycles, and optionally
with functions, provided that it is restored in a process running the
same binary program - code addresses are stored. No type information
existed before dumping (integer 0 looks exactly as false and [] and
NONE) and thus none is restored. You get fancy coercions or undefined
behavior when restoring to a wrong type.
Do you mean storing the physical structure of values without knowing
their types, similarly as in OCaml? Or overloaded specialized dumpers
and restorers for particular types?
--
__("$ P+++ L++>$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
Dynamic and persistent data storage
The ghc documentation for the Dynamic library says: "Examples where this library may come in handy (dynamic types, really - hopefully the library provided here will suffice) are: persistent programming, ..." ^^ ^^^ I would like to store a data structure in a file (perhaps using mmalloc), and store a TypeRep with it, so that when opening the file later, I can verify that it is what I think it is. I would also like to be able to extract the contents of the file as a Dynamic. To do this would require several things the current Dynamic library lacks: (i) A way to store a TypeRep. TypeRep is an instance of Show. If it were also an instance of Read, such that read . show == id, a TypeRep could be stored as a string. I would write my own instance, but I am a little daunted by the mechanics of the Read class, and worried about ensuring that read . show == id, not being the author or maintainer of the Show instance. (ii) To be able to construct a Dynamic from a TypeRep and a concrete type i.e. some form of access to the Dynamic constructor. The concrete type need not range over typical Haskell instances of Typeable, since they work with toDyn anyway. But something is needed for things like Addr and ForeignObj, which cannot be instances of Typeable. (iii) dynType :: Dynamic -> TypeRep Of course one can repeatedly apply fromDynamic at different types, but there could be a large number of possible types. Even worse, some polymorphic code might wish to know only the top-level type constructor. Obviously (ii) and (iii) are easy enough to hack into the current implementation, but it would be better to add something that most people agree with. As for (i), perhaps it would be relatively easy for one of the Glasgow Hackers to add ? Tim
