- Libraries - Haskell.org

The numeric c types are (effectively) integral, too.
by Jeff Shaw 29 Mar '13

29 Mar '13

This query is regarding Foreign.C.Types <http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Foreign-C…>. Now that the constructors for CClock, CTime, CUSeconds, and CSUSeconds are exposed, it's become clear that these are Ints or Words. Technically on some architectures they could be floating point, but I would bet that on all architectures that Haskell is ever used on, none of these are floating point types. Adding Bounded, Enum, Integral, and Bits instances to the "numeric" types would break nothing and ease situations such as this: roundTo :: CTime -> CTime -> CTime roundTo a b = (a `div` b) * b This works right now, but requires a trivial Integral class be written for every program that wants to do it. instance Integral CTime where quot (CTime a) (CTime b) = CTime (a `quot` b) rem (CTime a) (CTime b) = CTime (a `rem` b) div (CTime a) (CTime b) = CTime (a `div` b) mod (CTime a) (CTime b) = CTime (a `mod` b) quotRem (CTime n) (CTime d) = (\(d,m) -> (CTime d, CTime m)) (quotRem n d) divMod (CTime n) (CTime d) = (\(d,m) -> (CTime d, CTime m)) (divMod n d) toInteger (CTime t) = toInteger t I think this and the other trivial instances should just go right into Foreign.C.Types for all the "numeric" types in Foreign.C.Types. Any thoughts to the contrary? Jeff

8 22

cabal executable using local hsc modules
by Andreas Voellmy 25 Mar '13

25 Mar '13

Hi, I have a library that has some modules written as .hsc files and I want to include some executables that use those modules. Cabal doesn't seem to find the modules when it is building the executable. It complains that the module used by the executable is in a hidden package (of the same name as the package being built). Adding the package as a dependency in the executable section doesn't work since it references a library defined in the same package. Is this a bug? I've attached three files illustrating the problem. A.hsc is a tiny module in the library, B.hs is the executable that uses A, foo.cabal defines both the library and the executable. I am using $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library and when I run "cabal install -v" I get $ cabal install --disable-library-profiling Resolving dependencies... Configuring foo-1.0... Building foo-1.0... Preprocessing library foo-1.0... [1 of 1] Compiling A ( dist/build/A.hs, dist/build/A.o ) In-place registering foo-1.0... Preprocessing executable 'B' for foo-1.0... B.hs:3:8: Could not find module `A' It is a member of the hidden package `foo-1.0'. Perhaps you need to add `foo' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Failed to install foo-1.0 cabal: Error: some packages failed to install: foo-1.0 failed during the building phase. The exception was: ExitFailure 1

2 10

Advance notice that I'd like to make Cabal depend on parsec
by Duncan Coutts 22 Mar '13

22 Mar '13

Hi folks, I want to give you advance notice that I would like to make Cabal depend on parsec. The implication is that GHC would therefore depend on parsec and thus it would become a core package, rather than just a HP package. So this would affect both GHC and the HP, though I hope not too much. The rationale is that Cabal needs to parse things, like .cabal files and currently we do not have a decent parser in the core libraries. By decent I mean one that can produce error messages with source locations and that doesn't have unpredictable memory use. The only parser in the core libraries at the moment is Text.ParserCombinators.ReadP from the base package and that fails my "decent" criteria on both counts. Its idea of an error message is (), and on some largish .cabal files we take 100s of MB to parse (I realise that the ReadP in the base package is a cutdown version so I don't mean to malign all ReadP-style libs out there). Partly due to the performance problem, the terrible .cabal file error messages, and partly because Doaitse Swierstra keeps asking me if .cabal files have a grammar, I've been writing a new .cabal parser. It uses an alex lexer and a parsec parser. It's fast and the error messages are pretty good. I have reverse engineered a grammar that closely matches the existing parser and .cabal files in the wild, though I'm not sure Doaitse will be satisfied with the approach I've taken to handling layout. Why did I choose parsec? Practicality dictates that I can only use things in the core libraries, and the nearest thing we have to that is the parser lib that is in the HP. I tried to use happy but I could not construct a grammar/lexer combo to handle the layout (also, happy is not exactly known for its great error messages). I've been doing regression testing against hackage and I'm satisfied that the new parser matches close enough. I've uncovered all kinds of horrors with .cabal files in the wild relying on quirks of the old parser. I've made adjustments for most of them but I will be breaking a half dozen old packages (most of those don't actually build correctly because though their syntax errors are not picked up by the parser, they do cause failure eventually). So far I've just done the outline parser, not the individual field parsers. I'll be doing those next and then integrate. So this change is still a bit of a ways off, but I thought it'd be useful to warn people now. Duncan

14 25

Making monads from transformed monads
by Henning Thielemann 22 Mar '13

22 Mar '13

In a library I want to give a base monad and allow the user to choose a monad transformer. However, the Monad.Trans.Class from transformers is not strong enough, because it cannot warrant that a transformed monad is a monads itself. I have appended a module that implements a class with methods 'point' and 'bind' that correspond to 'return' and '>>='. A backward-compatible solution would be to add the class as subclass of current Monad.Trans.Class. This is how I implemented my proof-of-concept. A cleaner solution for the long run would be to add the methods 'point' and 'bind' directly to the current Monad.Trans.Class. Is there any interest in that extension or modification?

1 0

Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Johan Tibell 22 Mar '13

22 Mar '13

Hi all, As requested by Mark, here's a proposal to include unordered-containers and hashable in the platform: http://trac.haskell.org/haskell-platform/wiki/Proposals/unordered-containers The timeline is pretty short, so lets see if we can agree on this before Monday March 25th, 2013. -- Johan

11 20

ANN: text-printer - abstract interface for text builders/printers
by Mikhail Vorozhtsov 22 Mar '13

22 Mar '13

Hello, I was writing a library for working with IP addresses when I found myself puzzled with the number of contexts in which the textual representation of an address could be used: plain strings, bytestring builders (ASCII/UTF8), text builders, pretty printers, etc. I could've just written an `addressToString :: Address -> String` function, but that would be suboptimal: (a) namespace pollution (that's a lot of *ToString's if you count IPv4/6, network addresses, socket addresses, etc) and (b) some contexts can take advantage of the fact that textual representations are ASCII (e.g. UTF8 bytestring builder). And so the text-printer[1] was born. It is mainly two type classes. One for injecting text into a monoid, with special methods for ASCII and UTF-8 characters/strings. The other provides the default injection for values of a type (think of the `Pretty` type class in pretty printing libraries), the textual representation is supposed to be simple (single-line). Plus some convenient combinators and number formatters. [1] http://hackage.haskell.org/package/text-printer

1 0

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Johan Tibell 22 Mar '13

22 Mar '13

On Wed, Mar 20, 2013 at 11:00 AM, Bardur Arantsson <spam(a)scientician.net>wrote: > AFAICT, the hash function needn't be cryptographically secure (though > that obviously avoids the issue altogether) -- if there is some > determined-at-startup "salt" that's added in to all hashed values then > that should provide good enough protection. Obviously this will mean > that the hashes won't be repeatable across runs of the same program, but > that's usually acceptable for a hash function which isn't used for > content identification(*). > > (*) For which you should use a cryptographically secure hash anyway. > This is what Python did and unfortunately it's not enough as the salt can easily be recovered if you use a weak hash function. See the SipHash paper. > > SipHash is one way to address these kinds of attacks. There are other > means > > as well. For example, many general DoS protection mechanisms (timeouts, > IP > > banning, etc) also work on these kind of attacks. > > > > Timeouts aren't necessarily sufficient -- the application can keep > sending data (e.g. form parameter data) and can cause 100% cpu usage for > a loooooonng time. After that it can just start over. > But that limits how long the any given request can occupy the CPU for (as we will sever the connection after X seconds.) > IP banning can only happen after the problem occurs. > Not at all. $BIG_WEB_COMPANIES do it on the fly using $SECRET_SMART_SAUCE. Hash flooding is only one of many ways to DoS a server. You can try other things, like building a bot net and trying to flood the connection. Just as sandboxing is a better way to run untrusted software than trying to plug every whole in your code/RTS, generic anti-DoS techniques are usually better than trying to figure out every possible way someone can DoS you. -- Johan

2 2

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by wren ng thornton 22 Mar '13

22 Mar '13

On 3/20/13 1:02 PM, Thomas Schilling wrote:> To make this more precise the next version of hashable (say, 1.3) > would include this: > > newtype SipHashed a = SipHashed a > > class SipHashable a where > sipHashWithSalt :: Int -> a -> Int > > instance SipHashable a => Hashable (SipHashed a) where > hashWithSalt salt (SipHashed x) = sipHashWithSalt salt x > > Then all Hashable instances are taken from hashable-1.1. All Hashable > instances from hashable-1.2 are renamed to become instances of > SipHashable. That seems like a reasonable solution. I only ever use hashmaps explicitly for speed reasons and in applications that are not susceptible to DoS. The arguments about not wanting to introduce security issues due to some transitive dependency also hold for not wanting to introduce performance issues due to some transitive dependency. I respect all the folks working on web frameworks in Haskell, but there are also those of us who work on programs where compute time really is the number one concern (once an acceptable level of correctness and precision has been obtained); and when experiments are measured in days or weeks of cluster time, those "little" 1.3x and 1.5x slowdowns really hurt, let alone the 2.0x people've mentioned with siphash. One concern with the above approach: is "siphash" a sufficiently generic name, or is it just one hashing method that happens to deflect this DoS issue? I haven't read the paper, so... -- Live well, ~wren

4 3

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by wren ng thornton 22 Mar '13

22 Mar '13

On 3/21/13 4:30 PM, Roman Cheplyaka wrote: > * Thomas Moertel <tom(a)moertel.com> [2013-03-21 15:58:58-0400] >> On Wed, Mar 20, 2013 at 5:05 PM, Johan Tibell <johan.tibell(a)gmail.com>wrote: >>> The problem is that if the secure hashing makes HashMap as slow as Map, >>> there's no point in having the former in the first place, as it only exists >>> to provide speed. >> >> I understand that HashMap exists to provide speed, but are we sure that >> everyone who uses it for speed understands the security implications? >> >> Regardless of whether speed-first or security-first is the default, users >> of HashMap can be partitioned into two groups: those who knowingly choose >> between speed and security, and those who do not. For the first group, >> either default is safe because members of that group will have the >> opportunity to choose the other option. But for the second group, only >> security-first is safe: if its not the default, members of the second >> group wont have the option to choose it. > > Why not simply educate them by placing a prominent notice in the > haddock? +1. Whenever there's this split between knowing-choice and ignorance, my preferred solution is always to educate people. Sometimes there are cases where one side of the choice is obviously superior, or where it's too difficult to explain what is at stake for the choice. In these cases I'm a fan of preferring the "safe" choice, because (a) it's obvious, or (b) education is too costly. But that's not so clear for something like significant speed benefits (which are crucial for some, and nice for all) vs defense against DoS (which are crucial for some, but irrelevant to others). Given that both benefits are crucial for some, either we should have no default ---for fear of offending either side--- or we should ignore both of those parties (since they are of approximately equal prominence), in which case things fall back to nice-for-all vs irrelevant-to-others, which favors speed as the default. Thankfully, in Haskell we have enough polymorphism that it's feasible to eschew a default choice, and it's also feasible to override whatever the default is. That puts us in a much better place than most other languages faced with this choice. -- Live well, ~wren

1 0

ANNOUNCE: monoid-subclasses-0.1.1, incremental-parser-0.2.2, and SCC-0.8
by Mario Blažević 22 Mar '13

22 Mar '13

The new package monoid-subclasses [1] exports a number of classes that sit between monoids and groups: ReductiveMonoid, CancellativeMonoid, GCDMonoid, MonoidNull, and FactorialMonoid among others. The package also comes with class instances for all applicable data types from base, vector, containers, bytestring, and text packages. These classes were initially a part of the incremental-parser package [2] but they've moved, so incremental-parser-0.2.2 now depends on monoid-subclasses which has added more class methods and instances. The parsers constructed using the incremental-parser library generally work on any ReductiveMonoid, FactorialMonoid or TextualMonoid. You can thus construct a generic parser that operates on String, ByteString, or Text input, or even on Product Integer or a Map if you are so inclined. The version 0.8 of Streaming Component Combinators (a.k.a. SCC) has also been re-designed from the ground up. In the earlier versions, as in the pipes and conduit packages, the types of streams and stream-processing components were parametrized by the type of the individual items flowing through. All sources and sinks are now parametrized instead by the type of the monoid they produce or consume. As a consequence, SCC coroutines can now communicate in chunks of ByteString or Text instead of just lists, and these chunks can be of arbitrary size. The boundaries of producer's chunks are invisible to the consumer (excepting some low-level functions), which must specify the amount of data it wants to receive using a ReadRequest. This change at the heart of SCC has had a positive impact on outer layers, and especially on the Splitter component type which has become much simpler. [1] http://hackage.haskell.org/package/monoid-subclasses-0.1.1 [2] http://hackage.haskell.org/package/incremental-parser-0.2.2 [3] http://hackage.haskell.org/package/scc-0.8

1 0