Release blockio-0.1.0.0
#765
Conversation
jorisdral
force-pushed
the
jdral/blockio-0.1.0.0
branch
7 times, most recently
from
71c96a5 to
176473a
Compare
jorisdral
requested review from
dcoutts,
mheinzel,
recursion-ninja and
wenkokke
as code owners
jorisdral
force-pushed
the
jdral/blockio-0.1.0.0
branch
from
2657ae6 to
54a958f
Compare
jorisdral
force-pushed
the
jdral/blockio-0.1.0.0
branch
from
54a958f to
55d828a
Compare
| -- even though we'd prefer to keep it truly hidden. There are ways around | ||
| -- this, for example using a new private sub-library that contains the | ||
| -- "System.FS.BlockIO.Serial" module, but it's a lot of boilerplate. | ||
| serialHasBlockIO |
There was a problem hiding this comment.
I'm not sure I totally follow why we don't want to export serialHasBlockIO from the public API. Isn't it ok to always have available, in addition to the platform specific/native one?
There was a problem hiding this comment.
serialHasBlockIO as it stands now has a very unwieldy type:
serialHasBlockIO ::
(MonadThrow m, MonadMVar m, PrimMonad m, Eq h)
=> (Handle h -> Bool -> m ())
-> (Handle h -> API.FileOffset -> API.FileOffset -> API.Advice -> m ())
-> (Handle h -> API.FileOffset -> API.FileOffset -> m ())
-> (FsPath -> LockMode -> m (Maybe (API.LockFileHandle m)))
-> (Handle h -> m ())
-> (FsPath -> m ())
-> (FsPath -> FsPath -> m ())
-> HasFS m h
-> m (API.HasBlockIO m h)
serialHasBlockIO hSetNoCache hAdvise hAllocate tryLockFile hSynchronise synchroniseDirectory createHardLink hfs = doIt's filling in submitIO and close in the resulting HasBlockIO by itself using the input HasFS, but for all the other HasBlockIO functions the user has to provide the implementation. Depending on the platform or simulation, each of these functions is different. I think there would be value in exposing an alternative serialHasBlockIO function with all these HasBlockIO functions filled in, but then those would be exposed from platform-/simulation- specific modules. However, if we move these HasBlockIO functions, that have nothing to do with batched I/O, to fs-api/fs-sim, then our lives become easier because all the unwieldy function arguments disappear and as a result we can just expose serialHasBlockIO from a public module
I say let's keep this function internal for now, and later we can address this (if asked for)
…stead It's specific to the `IO` implementation
We use `serialHasBlockIO` in the `sim` sub-library and so we have to expose it somewhere, but we'd actually prefer it if it was not part of the public API. Exposing it only from an internal module makes it clear that it should ideally not be used by users.
We remove documentation about implementation specifics from the `HasBlockIO` type, but we'll include it in the `IO` module in one of the next commits.
jorisdral
force-pushed
the
jdral/blockio-0.1.0.0
branch
from
55d828a to
eeddbfe
Compare
jorisdral
force-pushed
the
jdral/blockio-0.1.0.0
branch
from
eeddbfe to
254b95a
Compare
jorisdral
force-pushed
the
jdral/blockio-0.1.0.0
branch
from
fd135cf to
359f03c
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
This PR prepares
blockiofor it's first release. Nothing about the implementations changes, but we clean up the public API by refactoring/renaming a little bit, and adding/reworking documentation