An experimental monadic interface to Tree mutation. The main idea is to
simulate IO-ish manipulation of real filesystem (that's the state part of
the monad), and to keep memory usage down by reasonably often dumping the
intermediate data to disk and forgetting it. The monad interface itself is
generic, and a number of actual implementations can be used. This module
provides just virtualTreeIO
that never writes any changes, but may trigger
filesystem reads as appropriate.
- virtualTreeIO :: TreeIO a -> Tree IO -> IO (a, Tree IO)
- virtualTreeMonad :: Monad m => TreeMonad m a -> Tree m -> m (a, Tree m)
- readFile :: (TreeRO m, MonadError e m) => AnchoredPath -> m ByteString
- writeFile :: (TreeRW m, MonadError e m) => AnchoredPath -> ByteString -> m ()
- createDirectory :: (TreeRW m, MonadError e m) => AnchoredPath -> m ()
- rename :: (TreeRW m, MonadError e m) => AnchoredPath -> AnchoredPath -> m ()
- unlink :: (TreeRW m, MonadError e m) => AnchoredPath -> m ()
- fileExists :: (TreeRO m, MonadError e m) => AnchoredPath -> m Bool
- directoryExists :: (TreeRO m, MonadError e m) => AnchoredPath -> m Bool
- exists :: (TreeRO m, MonadError e m) => AnchoredPath -> m Bool
- withDirectory :: (TreeRO m, MonadError e m) => AnchoredPath -> m a -> m a
- currentDirectory :: TreeRO m => m AnchoredPath
- tree :: TreeState m -> Tree m
- data TreeState m
- type TreeMonad m = RWST AnchoredPath () (TreeState m) m
- type TreeIO = TreeMonad IO
- runTreeMonad :: Monad m => TreeMonad m a -> TreeState m -> m (a, Tree m)
- type PathSet = Set AnchoredPath
- initialState :: Tree m -> (PathSet -> TreeMonad m ()) -> TreeState m
- replaceItem :: (MonadError e m, Functor m, Monad m) => AnchoredPath -> Maybe (TreeItem m) -> TreeMonad m ()
Documentation
virtualTreeMonad :: Monad m => TreeMonad m a -> Tree m -> m (a, Tree m)Source
Run a TreeIO action without storing any changes. This is useful for running monadic tree mutations for obtaining the resulting Tree (as opposed to their effect of writing a modified tree to disk). The actions can do both read and write -- reads are passed through to the actual filesystem, but the writes are held in memory in a form of modified Tree.
readFile :: (TreeRO m, MonadError e m) => AnchoredPath -> m ByteStringSource
Grab content of a file in the current Tree at the given path.
writeFile :: (TreeRW m, MonadError e m) => AnchoredPath -> ByteString -> m ()Source
Change content of a file at a given path. The change will be eventually flushed to disk, but might be buffered for some time.
createDirectory :: (TreeRW m, MonadError e m) => AnchoredPath -> m ()Source
rename :: (TreeRW m, MonadError e m) => AnchoredPath -> AnchoredPath -> m ()Source
unlink :: (TreeRW m, MonadError e m) => AnchoredPath -> m ()Source
fileExists :: (TreeRO m, MonadError e m) => AnchoredPath -> m BoolSource
Check for existence of a file.
directoryExists :: (TreeRO m, MonadError e m) => AnchoredPath -> m BoolSource
Check for existence of a directory.
exists :: (TreeRO m, MonadError e m) => AnchoredPath -> m BoolSource
Check for existence of a node (file or directory, doesn't matter).
withDirectory :: (TreeRO m, MonadError e m) => AnchoredPath -> m a -> m aSource
currentDirectory :: TreeRO m => m AnchoredPathSource
Internal state of the TreeIO
monad. Keeps track of the current Tree
content, unsync'd changes and a current working directory (of the monad).
type TreeMonad m = RWST AnchoredPath () (TreeState m) mSource
A TreeIO
monad. A sort of like IO but it keeps a TreeState
around as well,
which is a sort of virtual filesystem. Depending on how you obtained your
TreeIO
, the actions in your virtual filesystem get somehow reflected in the
actual real filesystem. For virtualTreeIO
, nothing happens in real
filesystem, however with plainTreeIO
, the plain tree will be updated every
now and then, and with hashedTreeIO
a darcs-style hashed tree will get
updated.
type PathSet = Set AnchoredPathSource
replaceItem :: (MonadError e m, Functor m, Monad m) => AnchoredPath -> Maybe (TreeItem m) -> TreeMonad m ()Source
Replace an item with a new version without modifying the content of the
tree. This does not do any change tracking. Ought to be only used from a
sync
implementation for a particular storage format. The presumed use-case
is that an existing in-memory Blob is replaced with a one referring to an
on-disk file.