Re: [Haskell-cafe] Can cabal be turned into a package manager?
On 12 December 2012 18:16, Bardur Arantsson s...@scientician.net wrote: On 12/12/2012 06:01 PM, Janek S. wrote: Well, one big issue is that Linux distribution packagers have control of the entire stack. A (hypothetical) Haskell package manager wouldn't. In Gentoo, there are many package overlays apart from the main repository. You can add as many as you want (local or remote). Typical package managers also restrict you to exactly one version of any given package. This can be a severe limitation for developers. Gentoo's emerge doesn't. It adds a concept called slots, which are different versions of the same package that can be installed in the same system without conflict. While this property is true for most versions of most packages in hackage, it is not necessarily true if those packages contain executables. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can cabal be turned into a package manager?
Well, one advantage of cabal over nix is that cabal works on windows. I haven't tried to install nix on windows, but: Portability. Nix should run on most Unix systems, including Linux, FreeBSD and Mac OS X. Has anyone tried it? Cheers, Ivan On 12 December 2012 18:55, Ertugrul Söylemez e...@ertes.de wrote: Janek S. fremenz...@poczta.onet.pl wrote: 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? There is no need to reinvent that. See below. 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? Actually Linux distributions do all the hard work for you. Package maintainers know what I'm talking about. It's a difficult task to specify correct dependencies, tedious to negotiate with all the other developers and all in all provide a consistent system. But that's only half of the story. The problem starts with the File Hierarchy Standard (FHS), which essentially doesn't allow you to employ a more useful concept. That's why an experimental (yet quite usable) Linux distribution called NixOS [1] has established. It recognizes the problems of the FHS. The solution is simple and radical: the FHS sucks, so ignore it. NixOS uses the Nix package manager, which you can also use for your Haskell packages to escape from the dependency hell. With Nix you can even allow all users to install arbitrary packages without interfering with other users, even the same packages with different versions. Two programs can depend on different versions of the same library, etc. It's the package manager of the future. Unfortunately the concept is new and different enough that it will be difficult to convince a large portion of the Linux community to employ it. It's the same issue Haskell has in the programming language world. There is no need to switch to NixOS to use Nix. You can even install it in your home directory. [1]: http://nixos.org/ Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can cabal be turned into a package manager?
Btw, one more great pearl of Gentoo's package manager: predependencies and postdependencies. These are packages (and/or programs) that must be installed in the system prior to the package being installed, and after the package is installed, respectively. Most packages have almost the same predeps, deps and postdeps. A Haskell compiler might be a (pre-)dependency for most packages, but not necessarily a post-dependency. Gtk should have gtk2hs-buildtools in its predependencies, but not in its postdependencies (once the package is installed, gtk2hs-buildtools is not needed anymore). The same is true for many packages that depend on happy, alex, etc. If your program needs an auxiliary program to run, but needs not be compiled against it, that's also the place for predeps/postdeps. I used it for a long time (not anymore), and it works wonders. It would be great to have something like this in cabal. On 16 December 2012 12:10, Ivan Perez ivanperezdoming...@gmail.com wrote: On 12 December 2012 18:16, Bardur Arantsson s...@scientician.net wrote: On 12/12/2012 06:01 PM, Janek S. wrote: Well, one big issue is that Linux distribution packagers have control of the entire stack. A (hypothetical) Haskell package manager wouldn't. In Gentoo, there are many package overlays apart from the main repository. You can add as many as you want (local or remote). Typical package managers also restrict you to exactly one version of any given package. This can be a severe limitation for developers. Gentoo's emerge doesn't. It adds a concept called slots, which are different versions of the same package that can be installed in the same system without conflict. While this property is true for most versions of most packages in hackage, it is not necessarily true if those packages contain executables. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Haskell bindings for the igraph C library
Hi Haskellers, dear igraph community, I am pleased to announce the release of our (inofficial) Haskell bindings to the igraph C library. igraph is a powerfull library for creating and manipulating directed, undirected and weighted graphs. Our package offers a complete coverage of all functions on structural properties of graphs. Compared to the official packages for R and Python it is the first library that offers type level distinction between directed/undirected and weighted graphs. Haskells type system allows to keep track of the types of your nodes and whether or not your graph and its edges are directed or undirected, weighted or unweighted. Haskell graphs may contain any Haskell value as node values, kind of similar to Pythons attributes. igraph on hackage, the official package database for Haskell: http://hackage.haskell.org/package/igraph (requires the current igraph-0.6 C library) The official igraph website: http://igraph.sourceforge.net/index.html Until hackage generates the haddock documentation, the documentation is also available at: http://hs.nils.cc/igraph-0.1/html/index.html Any feedback is appreciated, - Nils Schweinsberg - George Giorgidze ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANN: Haskell bindings for the igraph C library
On Sun, Dec 16, 2012 at 9:53 AM, Nils Schweinsberg m...@nils.cc wrote: Hi Haskellers, dear igraph community, I am pleased to announce the release of our (inofficial) Haskell bindings to the igraph C library. igraph is a powerfull library for creating and manipulating directed, undirected and weighted graphs. Our package offers a complete coverage of all functions on structural properties of graphs. How does this compare with fgl? http://hackage.haskell.org/package/fgl Thanks! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] edge: compile testing
From: Christopher Howard christopher.how...@frigidcode.com On 12/14/2012 07:05 PM, Clark Gaebel wrote: Unacceptable argument type in foreign declaration Thanks for giving it a try. Could you send off a bug report to the OpenAL Haskell module maintainer? sven.pa...@aedion.de (I might offer to do it, but I tried to e-mail him once about a different issue and never heard back. Probably didn't make it through his spam filter.) I think Sven's been incommunicado for a few years now. Most likely somebody else will need to step forward as the OpenAL maintainer, if there's interest in keeping that package current. John L. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: JMacro 0.6 and JMacro-RPC, featuring cross-platform json-rpc, easy AJAX applications, evented reactive panels and more
jmacro: http://hackage.haskell.org/package/jmacro jmacro-rpc: http://hackage.haskell.org/package/jmacro-rpc jmacro-rpc-snap: http://hackage.haskell.org/package/jmacro-rpc-snap jmacro-rpc-happstack: http://hackage.haskell.org/package/jmacro-rpc-happstack I'm happy to announce the release of JMacro 0.6 (0.6.3 actually) which brings a host of improvements. JMacro is a quasiquoted library for the programmatic generation of JavaScript code. It lets you write in a superset of JavaScript with haskell-like syntax and compile-time guarantees of syntactic correctness, and is intended to be used for both embedded javascript and compilers and libraries targeting JavaScript--where hygienic naming, proper scoping, and anti-quotation are especially important. Documentation is on the Haskell Wiki: http://www.haskell.org/haskellwiki/Jmacro This release brings a host of improvements to efficiency, driven largely by user-submitted patches and requests. Text is used more uniformly, as opposed to String, and JSON integration is provided via aeson rather than the json package. Additionally, nearly all of JavaScript is supported, including more obscure operators, as well as labels, and labeled break and continue. The big news, however, is JMacro-RPC, which provides multi-server tools for serving JSON-RPC 2.0 [1] remote procedure calls, as well as binding to them from both Haskell and JavaScript. On the Haskell side, rpc server functions and caller stubs are automatically generated by typeclasses. On the JavaScript side, which is less typed, a function is exposed to marshall javascript function arguments directly into RPC calls to a located URL. [1] http://jsonrpc.org/specification On top of these RPCs, JMacro-RPC provides the conversation page abstraction, which allows the easy creation of web-applications with server side state. The user simply provides a function from JavaScript - Page that splices in some JavaScript, and a list of functions they wish to be accessible from the page. All JavaScript within the page then has access to these functions, which run, transparently, server-side, with access to page-invocation-local shared state. Backends exist for JMacro-RPC for Happstack and Snap, and can be easily written for any other server or framework. JMacro-RPC now also provides the Panels library, which is even higher-level, providing the convenience of continuation-style web development with no scaling hassle. On the server side, Panels are entirely stateless, storing no client-specific state (so requests can be sharded to multiple servers as well without worrying about session replication). Code is written with a set of combinators over Panels, which package up display and behavior simultaneously. Panels, inspired by FRP, can provide Signals, which are sampleable, Events, which are discrete and can trigger updates, and Sinks which can be bound to Signals (behaving similarly to FRP wormholes). Semantics, by virtue of client-server interaction, are necessarily evented rather than continuous. As such, this is properly a system for declarative, event-driven reactivity rather than genuine FRP. Such a system is impoverished compared to the richer continuous-time or fully stream-based discrete-time semantics provided by of real FRP libraries. However, it is more than powerful enough for the sorts of user interfaces Panels are designed to build, and holds the added advantage of being straightforward, tractable, and a tight fit for client-server interactions. While Signals are applicative and Sinks are contravariant functors, which exposes at least some flavor of FRP, simple Signals and Sinks which don't require server-side processing (and are safely distinguished as such by types) can be bound to one-another purely on the client-side, avoiding unnecessary round-trips. The Panels code combines concepts from FRP [1][2], Self-Adjusting Computation [3], ASP.NET update panels [4], and research in stable naming schemes for bound variables [5]. The JavaScript rts driving evented updates is designed to be reasonably efficient and leak-free. Between basic RPCs, Conversations, and Panels, JMacro-RPC is intended to provide the full power scale for writing robust AJAX web applications with complex server-side logic. Because it is designed to be usable from any Haskell web framework or server, it is suitable for widespread adaptation. Patches, bug-reports, contributions, feature requests, documentation, etc. all are very welcome. [1] http://www.haskell.org/haskellwiki/Functional_Reactive_Programming [2] http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming [3] http://www.umut-acar.org/self-adjusting-computation [4] http://msdn.microsoft.com/en-us/library/bb399001(v=vs.100).aspx [5] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.66.6645 (I am not a number: I am a free variable, McBride and McKinna. See section four, on
