December 2012 - Haskell-Cafe

Can cabal be turned into a package manager?
by Janek S. 16 Dec '12

16 Dec '12

In the recent months there was a lot of dicussion about cabal, dependency hell and alike. After reading some of these discussions there is a question I just have to ask: Why not create a package manager (like rpm or apt) for Haskell software? I've been using Linux for years. Software for Linux is mostly written in C and C++. There are thousands of libraries with lots of dependencies and yet: a) Linux distributions manage to have package repositories that are kept in a consistent state b) Linux package managers can avoid dependency hell, automatically update to new packages, etc. Linux people did it! Is there any technical issue that prevents Haskell people from doing exactly the same thing? Or are we just having non-technical problems like lack of money or developers? Janek

10 15

Hackage suggestion: Gather the list of the licenses of all dependencies of a package
by Petr P 15 Dec '12

15 Dec '12

Dear Haskellers, following up the recent discussion about copyleft licenses, I'd suggest a (hopefully minor) improvement of Hackage: For each package, gather the list of the licenses of everything it depends on. I think this would help considerably people who don't want or can't use software licensed under a particular license (most often (L)GPL). In particular, we can have a BSD package that depends on a LGPL package, and this is fine for FOSS developers. But for a commercial developer, this can be a serious issue that is not apparent until one examines *every* transitive dependency. This idea is a bit vague, because a dependency is actually a range of packages, which in theory could have different licenses. But I suppose this will rarely happen in practice, so it'd be safe just to take the last package in the range (or maybe take all licences of the packages in the range). Best regards, Petr

9 21

Hackage down, again?
by Magnus Therning 15 Dec '12

15 Dec '12

It looks like hackage is down again. Is it planned or unplanned downtime this time? There doesn't happen to be some mirror of the packages that is a bit more reliable than the original? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

3 2

A new FFMPEG library?
by Kyle Hanson 15 Dec '12

15 Dec '12

The current hs-ffmpeg library is labeled as "old" on github: https://github.com/anders-/hs-ffmpeg is there a newer one or perhaps an alternative to play media files in haskell? -- Kyle Hanson

1 0

Template Haskell Splicing
by satvik chauhan 15 Dec '12

15 Dec '12

Is there any way to splice declarations inside where? If not, then what is the reason for not supporting this? -Satvik

3 3

ANNOUNCE: timeout-with-results
by Petr P 15 Dec '12

15 Dec '12

A small library that extends System.Timeout.timeout. It adds the possibility of saving partial results. Useful for AI-like algorithms that should return the best result found within a time limit. It comes in two variants: (1) Simple, which only allows computations to save partial results, not retrieve what has been written already. If a computation times out, the last saved partial result is returned. It comes in two flavours: One that converts saved values to WHNF, the other to NF. (This is required so that the producing thread performs the computations, not the consuming thread.) (2) Based on MonadWriter. The types of partial results have to be monoids. Saving a partial result combines it with the saved value using `mappend`. It also adds the ability to run a contained computation within another one, without disturbing its output. See https://github.com/ppetr/timeout-with-results#examples for examples. Repo: https://github.com/ppetr/timeout-with-results Hackage: http://hackage.haskell.org/package/timeout-with-results (I apologize for not being able to come up with a better package/module names. Suggestions welcomed.) Petr Pudlak

1 0

Is it possible to have constant-space JSON decoding?
by oleg＠okmij.org 15 Dec '12

15 Dec '12

I am doing, for several months, constant-space processing of large XML files using iteratees. The file contains many XML elements (which are a bit complex than a number). An element can be processed independently. After the parser finished with one element, and dumped the related data, the processing of the next element starts anew, so to speak. No significant state is accumulated for the overall parsing sans the counters of processed and bad elements, for statistics. XML is somewhat like JSON, only more complex: an XML parser has to deal with namespaces, parsed entities, CDATA sections and the other interesting stuff. Therefore, I'm quite sure there should not be fundamental problems in constant-space parsing of JSON. BTW, the parser itself is described there http://okmij.org/ftp/Streams.html#xml

5 5

edge: compile testing
by Christopher Howard 15 Dec '12

15 Dec '12

Hey guys, to teach myself Haskell I wrote a little arcade game called The Edge, built on gloss. It is in hackage under the package name "edge". Are there a few kind souls who would be willing to compile it on their machines and let me know if there are any problems at the compiling level? In the past, I've had issues with Haskell code compiling fine on my development system but not on others (due to dependency-related issues). I want to double check this before I try to make any distro-specific packages. I developed with GHC 7.4 and cabal-install 1.16.0.2 on a Gentoo system. Requires OpenGL and OpenAL (for sound). cabal update && cabal install edge -- frigidcode.com

3 3

LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)
by Petr P 14 Dec '12

14 Dec '12

2012/12/12 David Thomas <davidleothomas(a)gmail.com> > IANAL, but reviewing what others have written, it sounds like it may be > possible to maintain *some* distinction between LGPL and GPL in Haskell, > but it's a different distinction than with an LGPL shared library, so even > if applicable it's certainly worth being aware of. > > It sounds (and I'd very much like clarification) like providing source of > an application to users *without* license to redistribute, which can be > built using an LGPL library, would be compliant - whereas if the library > was GPL this would not be the case? > > As I understand it, this is one of the main differences: Using GPL-ed library forces the entire Combined Work to be GPL-ed (requiring to release the source codes), while using LGPL-ed library forces only the possibility to re-link with another version of it - you can distribute your own sources to users with whatever license you like (unless it's a modification of the library, of course). This could be an interesting question for FSF. Thanks to all for valuable comments. I didn't want to start a discussion about (L)GPL vs others, but since that already happened, let me give my opinion: First, LGPL has been discussed already: http://www.haskell.org/pipermail/haskell-cafe/2007-March/023158.html The problem with LGPL is that it is apparently tailored to languages that strongly rely on dynamic linking. TBH I wasn't aware of this before. One solution (taken by wxWidgets for example) is to modify LGPL so that they explicitly allow distributing the software without the re-linking requirement (which grants a little less rights to end users). I tried asking that on StackExchange: "Is there a modified LGPL license that allows static linking?" <http://programmers.stackexchange.com/q/179084/61231> Anther solution would be to focus on improvements of dynamic linking. Some links I found: http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport Haskell Static vs Dynamic Linking in Deployment < http://stackoverflow.com/q/7854614/1333025> Small Haskell program compiled with GHC into huge binary < http://stackoverflow.com/q/6115459> Yet another solution would be what David Thomas suggest: To provide the source code to your users, but don't allow them to use the code for anything but relinking the program with a different version of the library (no distribution, no modification etc.). <http://www.haskell.org/pipermail/haskell-cafe/2007-March/023158.html> Second, it's my wish to use (L)GPL for FOSS programs I write. My opinion has varied for many years, but in recent years I strongly incline to GPL-like licenses. We all know that GPL-like licenses make life more complicated for us programmers. Programmers want to use libraries with as little restrictions as possible. The main reason for me for choosing (L)GPL despite the complications is the protection and rights it gives to the *users* of a program. Sadly, no users are actually aware of this and what they could gain by choosing GPL-ed programs (let me know if you find a non-programmer who is aware of GPL's benefits). Just imagine if Facebook had to use AGPL, or if your mobile phone software would be all GPL. (Knowing what a program does with your data is becoming more important, like the US intelligence report suggests: http://reut.rs/UxbLtvsection "Technology .."). The other reason for me that GPL-like licenses give an advantage to FOSS developers over private companies. I feel this is fair - anybody who develops something that can be used by everyone deserves an advantage. Another thing to consider is the aspect of adoption/marketing strategy. Using a more permissive license can make adoption of a piece of software much faster. This can be desirable in some cases, like if the OS community wants to prevent the adoption of proprietary standards (like Vorbis VS MP3). Or in the case of Haskell, to motivate private companies to use it. Richard Stallman himself recommends this in some cases http://lwn.net/2001/0301/a/rms-ov-license.php3 But if a project is strong enough, using (L)GPL can actually strengthen it, like in the case of Linux VS NetBSD: http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd To quote: "So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved." Of course I respect other opinions in that matter, every author is free to use whatever licence (s)he likes. After all, FOSS is about freedom. The important thing to know is what advantages and drawbacks each license has and what are the consequences of using them. Best regards, Petr

14 19

Re: [Haskell-cafe] ANNOUNCE: tie-knot library
by Niklas Larsson 14 Dec '12

14 Dec '12

Yes, if you link statically, if you want to distribute without giving away source (or relinkable object files) you can link dynamically or use integer-simple in your GHC. Niklas ----- Ursprungligt meddelande ----- Från: "Herbert Valerio Riedel" <hvr(a)gnu.org> Skickat: ‎2012-‎12-‎14 11:55 Till: "Brandon Allbery" <allbery.b(a)gmail.com> Kopia: "Ramana Kumar" <Ramana.Kumar(a)cl.cam.ac.uk>; "haskell-cafe" <haskell-cafe(a)haskell.org> Ämne: Re: [Haskell-cafe] ANNOUNCE: tie-knot library Brandon Allbery <allbery.b(a)gmail.com> writes: > Haskell libraries are mostly BSD licensed, as is GHC itself. (Oddly > enough, GPL is not the only open source license.) btw, what about GHC's reliance on the LGPLed GMP library? Doesn't that already taint the whole GHC eco-system? Quoting [1]: | GMP is licensed under the GNU Lesser General Public License (LGPL), a | kind of "copyleft" license. According to the terms of the LGPL, | paragraph 5, you may distribute a program that is designed to be | compiled and dynamically linked with the library under the terms of | your choice (i.e., commercially) but if your program incorporates | portions of the library, if it is linked statically, then your program | is a "derivative"--a "work based on the library"--and according to | paragraph 2, section c, you "must cause the whole of the work to be | licensed" under the terms of the LGPL (including for free). | | The LGPL licensing for GMP is a problem for the overall licensing of | binary programs compiled with GHC because most distributions (and | builds) of GHC use static libraries. (Dynamic libraries are currently | distributed only for OS X.) The LGPL licensing situation may be worse: | even though The Glasgow Haskell Compiler License is essentially a | "free software" license (BSD3), according to paragraph 2 of the LGPL, | GHC must be distributed under the terms of the LGPL! [1]: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#ReasonsforReplac… cheers, hvr _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1