- Libraries - Haskell.org

Proposal unix. Change to `IO (Maybe String)`: getLoginName, getUserEntry* and getGroupEntry*
by Thomas Miedema 01 Dec '14

01 Dec '14

In the unix package, in System.Posix.User, we have the following functions [1]: * getLoginName (getlogin) * getUserEntryForID (getpwuid_r) * getGroupEntryForID (getgrgid_r) * getUserEntryForName (getpwnam_r) * getGroupEntryForName (getgrnam_r) They have signature `IO String`, and use `throwErrnoIfNull` to call the c functions listed in parenthesis. ## Proposal Change the signature of the functions listed above to `IO (Maybe String)`. The new semantics would be: * If the c function returns a NULL pointer with errno set to ENOENT, meaning the given user or group could not be found, the result is Nothing. * If another error occured, an error is thrown (no change). * Otherwise the result is Just "result". ## Motivation At least `getlogin` and `getgrgid` are unreliable on Linux. It is possible for them to return NULL pointers [2] even when the user is logged in and has an associated user entry in /etc/passwd and group entry in /etc/group. Examples: * when `getLoginName` is called using a terminal emulator that doesn't write login records to /var/run/utmp, or inside screen/tmux, `getlogin` tends to return NULL pointers [3]. * `getGroupEntryForID` can throw a NULL pointer exception inside chroots or other environments where the information in /etc/groups is not to be considered reliable [4]. Since we can, let's give the above Haskell functions a type safe(r) api. If the proposal gets rejected, I will just add a warning message to the docstrings of the functions in question and permanently disable their tests from the unix testsuite, since this is currently causing problems [5,6]. Discussion period: 2 weeks. ## Links [1] https://github.com/haskell/unix/blob/master/System/Posix/User.hsc [2] http://linux.die.net/man/3/getlogin [3] https://github.com/haskell/unix/blob/cad1ef27bb0a51bc68ebadb1297de1ae05bee9… [4] https://ghc.haskell.org/trac/ghc/ticket/8293 [5] http://www.haskell.org/pipermail/ghc-devs/2014-September/006420.html [6] https://ghc.haskell.org/trac/ghc/ticket/1487#comment:23 ## Details * Another function in the same module that needs to change is `getEffectiveUserName`, because it calls the function `getUserEntryForID` mentioned before. * The following functions don't need to change, since they return the empty list if no entries are found: - getGroups (getgroups) - getAllGroupEntries (getgrent) - getAllUserEntries (getpwent) * The rest of the functions in the module don't need to change either, since they are not expected to return NULL pointers, according to their respective man pages: - getRealUserID (getuid) - getRealGroupID (getgid) - getEffectiveUserID (geteuid) - getEffectiveGroupID (getegid)

5 4

process: Confusion about UseHandle handles being closed.
by Michael Snoyman 29 Nov '14

29 Nov '14

I originally opened this as a Github issue[1] about this, but due to lack of attention, Herbert recommended that I send it to the libraries list as well. Here's the issue description copied verbatim from Github: When working on a library, I was surprised to find that the `Handle`s that I passed in for `std_in`, `std_out` and `std_err` via `UseHandle` were automatically closed. This is not clear from the documentation, and- at least for the use case I was interested in- the opposite of what I needed. There are valid cases where we'd want the `Handle` to remain open after the process runs to completion. The function `createProcess_` in the `.Internals` module has the behavior I was looking for, and for my purpose, I can simply import from there. I'd like to propose two changes: 1. Add clear documentation to `createProcess` indicating that it will close the `Handle` automatically. 2. Add a new function to be exported from `System.Process` with the semantics of `createProcess_`. I'm open to bikeshedding on the name, but perhaps sticking with `createProcess_` makes the most sense. Note that I do *not* think we should change the existing semantics of `createProcess`: I think it's a large breaking change, and should be avoided. I'm happy to provide pull requests for both of these, I just wanted to check if there was objection before going ahead with it. Michael [1] https://github.com/haskell/process/issues/2

7 15

Why is there no Monoid instance for Either?
by Francesco Mazzoli 27 Nov '14

27 Nov '14

Hi, Lately, I found myself wanting to use the following Monoid instance: ```` instance (Monoid b) => Monoid (Either a b) where mempty = Right mempty Left e `mappend` _ = Left e _ `mappend` Left e = Left e Right x `mappend` Right y = Right (x `mappend` y) ```` It would seem quite justified to me, given the left-bias of Either elsewhere in base. Is there any particular reason why it shouldn't be defined? It would break the instance for Either in `semigroups`, which is ```` instance Semigroup (Either a b) where Left _ <> b = b a <> _ = a ```` But I think mine is more useful, and has the additional advantage of having `mappend` to behave very similar to the `mappend` for `Maybe`. Francesco

2 2

PROPOSAL: toBoundedIntegral: an adaptation of fromIntegral that respects bounds
by Sean Leather 25 Nov '14

25 Nov '14

Inspired by conversations recent [1] and not-so-recent [2] and by my own past wish for this, I propose adding the following function to base: toBoundedIntegral :: (Integral a, Integral b, Bounded b) => a -> Maybe b toBoundedIntegral x | y > toInteger (maxBound `asTypeOf` z) = Nothing | y < toInteger (minBound `asTypeOf` z) = Nothing | otherwise = Just $! z where y = toInteger x z = fromInteger y This includes rules to optimize for many cases where we know the bounds at compile time. See the gist for the full implementation: https://gist.github.com/spl/1986c9ff0b2416948957 I'm not particularly concerned with the precise location of this function. It could start out in GHC.Int if there's controversy. Otherwise, Data.Int would be an option to avoid polluting the Prelude. I chose the name to be descriptive of the result type, which is the more constrained type. The function that I started from [2] was called fromIntegralSafe, but I think “safe” is too ambiguous here. I did not find “toBoundedIntegral” in any package on Hackage. I welcome review of the implementation and rules. Discussion period: ~10 days if there is a strong desire to get it in GHC 7.10. (I would certainly like to see it get in.) Otherwise, I can make a package, and we can revisit the issue at another time. Regards, Sean [1] Evan Laforge: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/113600/focus=113648 [2] Stephen Paul Weber: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/102613/focus=64686

4 16

Final bikeshedding call: Fixing Control.Exception.bracket
by Merijn Verstraaten 23 Nov '14

23 Nov '14

Ola! In September Eyal Lotem raised the issue of bracket's cleanup handler not being uninterruptible [1]. This is a final bikeshedding email before I submit a patch. The problem, summarised: Blocking cleanup actions can be interrupted, causing cleanup not to happen and potentially leaking resources. Main objection to making the cleanup handler uninterruptible: Could cause deadlock if the code relies on async exceptions to interrupt a blocked thread. I count only two objections in the previous thread, 1 on the grounds that "deadlocks are NOT unlikely" and 1 that is conditioned on "I don't believe this is a problem". The rest seems either +1, or at least agrees that the status quo is *worse* than the proposed solution. My counter to these objections is: 1) No one has yet shown me any code that relies on the cleanup handler being interruptible 2) There are plenty of examples of current code being broken, for example every single 'bracket' using file handles is broken due to handle operations using a potentially blocking MVar operation internally, potentially leaking file descriptors/handles. 3) Even GHC-HQ can't use bracket correctly (see Simon's emails) Potential solution #1: Leave bracket as-is, add bracketUninterruptible with an uninterruptible cleanup handler. Potential solution #2: Change bracket to use uninterruptible cleanup handler, add bracketInterruptible for interruptible cleanups. Trade-offs: Solution 1 won't change the semantics of any existing code, however this also means that any currently broken uses of bracket will remain broken, possibly indefinitely. Solution 2 will change the semantics of bracket, which means any currently broken uses of bracket will be fixed, at the cost of creating potential deadlocks in code that relies on the interruptibility of cleanup. I will argue that solution #2 is preferable, since I have yet to see any code that uses the interruptibility of the cleanup handler. Whereas there's many broken assumption assuming the cleanup handler is not interruptible. Secondly, it is easier to detect deadlocks caused by this problem than it is to detect resource leaks which only happen in unlucky timings of async exceptions. Especially since any deadlock caused by the change can be fixed by replacing bracket with bracketInterruptible. [1] - https://www.haskell.org/pipermail/libraries/2014-September/023675.html Cheers, Merijn

17 88

Proposal: Add 'fillBytes' to Foreign.Marshal.Utils
by Alex Petrov 23 Nov '14

23 Nov '14

Hi everyone, Currently the memory allocated with (Foreign.Marshal.Alloc) malloc may potentially be dirty. In C this problem is usually solved by using memset. This would be extremely useful for FFI / C interop, when a data structure is allocated within Haskell code. With memset, you can do something like customMem <- malloc _ <- memset (castPtr customMem) 0 #{size custom_t} This will fill a block of allocated memory with zeroes. For example, I've been working on FFI bindings for collectd, and when I was allocating memory, previously used within the process, it was dirty, so my CString contained a value of "custom name7e0700490, test_plugin_LTX_module_register): symbol nd" Instead of just "custom name" After using memset and filling everything with zeroes, problem never appeared again. This can be implemented in user applications, too, although it would be really nice to have it by default. This is a common practice in C world, and this function is not only useful for cases when the memory was just allocated from Haskell process, but also when one receives a dirty memory buffer from C code. The patch for proposal was implemented and is available on Phabricator: https://phabricator.haskell.org/D465 Please share your thoughts. Alex https://twitter.com/ifesdjeen http://clojurewerkz.org/

5 5

PROPOSAL: Add displayException to Exception typeclass
by Michael Snoyman 21 Nov '14

21 Nov '14

I started a discussion a few weeks back on some theoretical changes to how exceptions are displayed. That discussion covered a lot of different ground. I'd now like to formally propose the original change I mentioned in that thread: 1. Add a new method to the Exception typeclass: -- | Render this exception value in a human-friendly manner. Default implementation: @show@. displayException :: e -> String displayException = show 2. Modify GHC's default exception handler to use `displayException` instead of `show`. This change will, on its own, cause no breakage[1] and, without further action, will have no change in program behavior. It does, however, allow users to begin distinguishing between how their exceptions should be `show`n versus how they should be displayed to an end user. Note that I am *not* proposing at this time any other changes discussed in the previous thread. If someone wants to propose removing Show superclasses, adding a Read superclass, providing a typeRepStack method[2], or something else, please propose it separately. Discussion period: two weeks. Michael [1] Besides introducing a new, possibly clashing identifier name. [2] That one actually seems like a very good idea to me.

12 34

PROPOSAL: Add 'Natural' type to base:Data.Word
by Herbert Valerio Riedel 18 Nov '14

18 Nov '14

Hello CLC et al., I hereby suggest to add a type for encoding term-level naturals data Natural = <opaque/hidden> deriving (...the usual standard classes...) to `base:Data.Word` module Motivation ========== - GHC 7.10 is planned to ship with integer-gmp2[2] as its default `Integer` lib, whose low-level primitives are based on *unsigned* BigNums. And 'Natural' type for integer-gmp2 can be implemented directly w/o the overhead of wrapping an `Integer` via data Natural = NatS# Word# | NatJ# !PrimBigNat# as well as having a twice as large domain handled via the small-word constructor and thus avoiding FFI calls into GMP. - GHC/`base` already provides type-level naturals, but no term-level naturals - Remove the asymmetry of having an unbounded signed `Integer` but no unbounded /unsigned/ integral type. Also, `Data.Word` has been carrying the following note[1] for some time now: > It would be very natural to add a type Natural providing an > unbounded size unsigned integer, just as Integer provides unbounded > size signed integers. We do not do that yet since there is no > demand for it. Discussion period: ~10 days (GHC 7.10 RC freeze is scheduled for Nov 21st) Cheers, hvr [1]: http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Word.html#g:3 [2]: https://phabricator.haskell.org/D82 https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2

24 38

Why the presence/absence of the HsColour binary forces to recompile the QuickCheck library?
by Andrés Sicard-Ramírez 18 Nov '14

18 Nov '14

Hi, (The Cabal home page https://www.haskell.org/cabal/ says I can send questions about Cabal to this mailing list). My question is http://stackoverflow.com/questions/26785036/why-the-presence-absence-of-the… . Thanks, -- Andrés

1 0

Proposal: Make amap an IArray method
by David Feuer 14 Nov '14

14 Nov '14

I realized what I wrote about amap earlier was utterly boneheaded, because it has the wrong type for fmap. The only way to accomplish my goal is to make Data.Array.IArray.amap a method of the IArray class. This will allow IArray instances to offer optimized versions and things like amap/coerce rules. The current implementation of amap can become the default one.

2 4