November 2015 - Haskell-Cafe

Fwd: Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Paolo Giarrusso 30 Nov '15

30 Nov '15

On 29 November 2015 at 20:12, Michael Orlitzky <michael(a)orlitzky.com> wrote: > On 11/29/2015 01:37 PM, Omari Norman wrote: >> >> Distribution packagers are savvy enough to use stack. > > Ignoring the question of *how* that might work, most distributions > forbid bundled dependencies because it creates a maintenance nightmare > and fills our users' machines with untraceable security vulnerabilities. But doesn't Haskell do static linking (usually) and cross-module inlining? Or are you fine with static linking as long as it's somehow tracked by the package manager, so that upgrading some-vuln-lib from 1.0 to 1.1 forces upgrading all client programs (looks quite doable at least with Debian packages)? -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

4 4

Fwd: Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Sven Panne 30 Nov '15

30 Nov '15

[... and now to the whole list, I hate gmail's defaults... :-] ---------- Forwarded message ---------- From: Sven Panne <svenpanne(a)gmail.com> Date: 2015-11-29 21:12 GMT+01:00 Subject: Re: [Haskell-cafe] Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack` To: Imants Cekusins <imantc(a)gmail.com> 2015-11-29 20:52 GMT+01:00 Imants Cekusins <imantc(a)gmail.com>: > [...] What if the top package (in namespace) contained major version? > > E.g. Cabal_1_22 > > below packages might use minor versions - basically, whenever api changes, > change the version part of the affected package. [...] > As a developer, what should I import if my program/library works with e.g. the version range [1.20 .. 1.23]? It definitely can't be import Cabal_1_23.Foo.Bar because if it later still works with e.g. 1.24, I would have to rename all my imports. And always using the lower bound is probably too restrictive, unless I'm mistaken... In general I think it's a bad idea to spread build dependencies all over the code. Cheers, S.

3 6

make a server & connect to it - strange behavior
by Patrick Redmond 30 Nov '15

30 Nov '15

Hi Haskell Cafe, When I start a web server (http-server:Network.HTTP.Server.serverWith) on a separate thread (async:Control.Concurrent.Async.withAsync) and then try to retrieve a response from the server (HTTP:Network.Browser.*) on a threaded runtime, I see either - connection refusals or - deadlock. Before I sink time into reading the source of the packages in question, does anybody see what's wrong with the code below? Increasing the timeout to wait for the server to initialize doesn't solve the problem. Using a bound thread doesn't solve the problem. I'm compiling with options "-threaded -rtsopts -with-rtsopts=-N". Thank you for taking a look. --Patrick This test project is on github. <https://github.com/plredmond/http-server-test-hs/blob/master/src/Lib.hs> module Lib ( someFunc ) where import Control.Monad.IO.Class (liftIO) import qualified Control.Concurrent as Concurrent import qualified Control.Concurrent.Async as Async import qualified Control.Exception as Exception import qualified Data.Maybe as Maybe import qualified Network.Browser as Browser import qualified Network.HTTP as HTTP import qualified Network.HTTP.Server as Server import qualified Network.HTTP.Server.Logger as ServerL import qualified Network.HTTP.Server.Response as ServerR import qualified Network.URI as URI someFunc :: IO (Either Exception.SomeException (URI.URI, HTTP.Response String)) someFunc = do Async.withAsync (Server.serverWith config handler) $ \_ -> do Concurrent.threadDelay . round $ 2e6 Exception.try . Browser.browse . Browser.request . Browser.defaultGETRequest $ uri where uri = Maybe.fromJust . URI.parseURI $ "http://localhost:8080/" config = Server.Config ServerL.stdLogger "localhost" 8080 handler _ url req = return (ServerR.respond ServerR.OK :: Server.Response String)

1 1

Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Omari Norman 29 Nov '15

29 Nov '15

On Sun, Nov 29, 2015 at 6:54 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com> wrote: > Hi all, > > IIUC, people used to spend nontrivial effort making their Haskell tools > work across a range of dependencies, and be careful about dropping support > for older ones. > Given the tools we had, this was not easy. I was never aware of any tool that substantially helped with making sure that a package remained compatible with the range of packages that was theoretically allowed by the package's .cabal file. > Do cabal sandboxes or Stack reduce that need, at least for applications?* > Or conversely, how bad is it to restrict support to users having them? I > guess I am asking about common policies, but this probably depends on > adoption of those tools. > > IMO there is really no one right answer to this question. It depends on how nice you are, or whether someone is paying you. Obviously if someone is paying you, do as she says or do what she needs. If no one is paying you, then how nice do you want to be by expending the work? Honestly I'm not very nice. I keep stuff working in the current Stackage Nightly but that's it. Maintaining compatibility with huge dependency matrices is just an enormous amount of work. In my view, someone installing an application can just use stack and Stackage.

6 10

Semi-closed handles and I/O errors: misleading documentation?
by Daniel Díaz 29 Nov '15

29 Nov '15

In the documentation for System.IO <http://hackage.haskell.org/package/base-4.8.1.0/docs/System-IO.html>, we find the following assertion: Any I/O errors encountered while a handle is semi-closed are simply discarded. also this other one: Encoding and decoding errors are always detected and reported, except during lazy I/O (hGetContents, getContents, and readFile), where a decoding error merely results in termination of the character stream, as with other I/O errors. Is this really correct, though? This SO question <http://stackoverflow.com/questions/16257037/detecting-i-o-exceptions-in-a-l…> says that exceptions found during lazy I/O are thrown from pure code, and a small experiment <http://stackoverflow.com/a/33985047/1364288> seems to confirm it. I personally prefer that behaviour, by the way. Perhaps the documentation should be updated?

1 0

Re: [Haskell-cafe] Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Paolo Giarrusso 29 Nov '15

29 Nov '15

On Sunday, November 29, 2015 at 1:23:58 PM UTC+1, Michael Snoyman wrote: > > For your particular example, you can use the transformers-compat package. > Thanks, that's useful! But to answer your general question: for applications, I strongly advocate > supporting just a single set of package version combos for dependencies. > Stack does do this by default, but cabal freeze files can get you most of > the way there too (barring some corner cases with different OSes and > OS-specific packages). > > I'm sure others will disagree with this recommendation, but I see no > reason to absorb a large amount of compatibility work just so that two > installations of the same application may end up behaving differently at > runtime because of differences in the behavior of a dependency. > Personally, I switched all the way to stack. I added mention of cabal sandboxes to address anybody who didn't switch yet or who prefers to stick to cabal.

1 0

Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Paolo Giarrusso 29 Nov '15

29 Nov '15

Hi all, IIUC, people used to spend nontrivial effort making their Haskell tools work across a range of dependencies, and be careful about dropping support for older ones. Do cabal sandboxes or Stack reduce that need, at least for applications?* Or conversely, how bad is it to restrict support to users having them? I guess I am asking about common policies, but this probably depends on adoption of those tools. As in: a) without sandboxes or Stack, packages need to build with whatever environment is there. b) with either of sandboxes or Stack, you can just specify the environment and get it. With Stack, you can even specify whichever (supported) GHC you want, without impacting the environment. Concretely, Control.Monad.Trans.Error is deprecated in transformers-0.4.3.0, but the replacement Control.Monad.Trans.Except does not exist in transformers-0.3.x, thus in the one-but-last Haskell Platform (2014.2.0.0). Hence, fixing the deprecation would make this application hard to install** for some users, including past me (around two months ago).*** Would you apply such a patch? Would you keep it out? Or would you even use CPP (something I'd really like to avoid)? Cheers, Paolo * I take for granted libraries are a different matter — composing libraries means intersecting their supported versions. ** I'll omit detailing "hard to install", because that's a matter of opinion; I considered `constraint: transformers installed` necessary in my cabal config (https://www.vex.net/~trebla/haskell/cabal-cabal.xhtml) and I've read that's becoming the default in the HP, so I think users are entitled to this opinion. *** This particular app has a tiny userbase, so my question is a curiosity.

2 1

How to create a Wiki account?
by Jeffrey Brown 29 Nov '15

29 Nov '15

This [1] is as close as I can seem to get. I noticed [2] had obsolete information; it says Either is not by default a Monad. [1] https://wiki.haskell.org/HaskellWiki:New_accounts [2] https://wiki.haskell.org/Failure -- Jeffrey Benjamin Brown

3 2

Why was this function that fast ?
by Romain Gehrig 28 Nov '15

28 Nov '15

Hi, I implemented a function to count how many steps it takes for a number to be reduced to 1 using the Collatz Conjecture (also known as the 3n + 1 problem) and I was very surprised to see it working instantaneously for integers as big as 10^100000. The said function: collatzSteps :: Integer -> Integer collatzSteps n = steps 1 n where steps acc 1 = acc steps acc n' | even n' = steps (acc+1) (n' `div` 2) steps acc n' = steps (acc+1) (n' * 3 + 1) You can try in GHCi (apparently with an upper limit of 10^199669): GHCi> collatzSteps 10^199668 [big num...] GHCi> length $ show $ collatzSteps 10^199668 168740 GHCi> collatzSteps 10^199669 -- Oops [1] 36128 bus error ghci Notice the number 168740: it is the number of *digits* for the number of steps. It implies that the `acc` is ~= *10^168740* when the function ends. Without optimisation at some point, it would mean there were as much (acc+1) calls ! My understanding completely stops there; I can't comprehend why a function that shouldn't return anything even long after the end of the universe just finished before my eyes. Can someone shed some light on how this peculiar function was optimised by GHC? Many thanks, (still dazed) Romain

3 2

Info about List with terminal element
by Silvio Frischknecht 26 Nov '15

26 Nov '15

Hello, I'm interested in learning more about a list-like structure with a terminal element. I.e. data List t e = Cons e (List t e) | Null t or maybe data List t e = Cons e (List t e) | Null | Terminal t An practical application could be lazy reading from a file readFile :: String -> List Error String Obviously there is a Functor instance. There is even a Monad instance. However, it is not defined as obviously because it's not clear what the terminal element should be. There is a straight forward fold like structure. My questions are. Are there more interesting generalizations of List? What rules do they follow? How should the Monad work? Why? I know this is related to the whole Iteratee discussion (I'm not completely familiar with it). Cheers Silvio

5 10