- Haskell-Cafe - Haskell.org

ANN haskdogs-0.3.2
by Sergey Mironov 13 May '13

13 May '13

Hi. I'm pleased to announce haskdogs-0.3.2, a source navigation helper. Haskdogs is a small HSH-based tool which calls hasktags to create tag file for entire haskell project. It takes into account first-level dependencies by recursively scanning imports and adding matching packages to the final tag list. As a result, programmer can use her text editor supporting tags (vim, for example) to jump directly to definition of any function she uses. Note that haskdogs call Unix shell commands like 'test' or 'mkdir' so this tool will likely fail to work on pure Windows platforms. In return, haskdogs is pretty small - only 125 lines long. Changes: * Generate extended tag file by default (hasktags -c -x) * Add -d command line option which allows user to specify additional source directories * Fix no-sources bug Github: https://github.com/ierton/haskdogs See also Vim-hint at https://github.com/ierton/haskdogs#vim-hint Install: cabal install hasktags haskdogs Usage: haskdogs [-d (FILE|'-')] [FLAGS] FLAGS will be passed to hasktags as-is followed by a list of files. Defaults to -c -x. Basically, just run haskdogs in your Haskell project directory Thanks to yihuang for the contributions! Sergey

1 0

Haskell Platform's libstdc++-6.dll may be interfering with other applications
by Andrew Pennebaker 13 May '13

13 May '13

I use a number of different programming languages, so I have Haskell Platform, Strawberry Perl, Node.js, RVM, and Git Bash installed at the same time. I've noticed that compiling packages with C dependencies (e.g. using node-gyp during "npm install node-mhash", or doing "cpan install PAR::Packer") often crashes during the build process with a popup: The procedure entry point __gxx_personality_sj0 could not be located in the dynamic link library libstdc++-6.dll. As Roderich Schupp points out<https://rt.cpan.org/Public/Bug/Display.html?id=84949>, it appears that the different libstdc++-6.dll's are interfering with one another. Haskell Platform comes with one, Vagrant comes with one, GIMP comes with one, MinGW comes with one, and Strawberry Perl comes with two! Objdump seems to indicate that Haskell Platform's DLL is the one to blame. $ find /c/ -name libstdc++-6.dll 2>/dev/null /c/DevKit/mingw/bin/libstdc++-6.dll /c/Program Files/GIMP 2/bin/libstdc++-6.dll /c/Program Files/Haskell Platform/2012.4.0.0/mingw/bin/libstdc++-6.dll /c/strawberry/c/bin/libstdc++-6.dll /c/strawberry/perl/bin/libstdc++-6.dll /c/vagrant/vagrant/embedded/mingw/bin/libstdc++-6.dll $ objdump -ax /c/DevKit/mingw/bin/libstdc++-6.dll | ack gxx_personality [3896] __gxx_personality_sj0 $ objdump -ax /c/Program\ Files/GIMP\ 2/bin/libstdc++-6.dll | ack gxx_personality [3499] __gxx_personality_sj0 $ objdump -ax /c/Program\ Files/Haskell\ Platform/2012.4.0.0/mingw/bin/libstdc++-6.dll | ack gxx_personality [3401] __gxx_personality_v0 $ objdump -ax /c/strawberry/c/bin/libstdc++-6.dll | ack gxx_personality [3510] __gxx_personality_sj0 $ objdump -ax /c/strawberry/perl/bin/libstdc++-6.dll | ack gxx_personality [3510] __gxx_personality_sj0 $ objdump -ax /c/vagrant/vagrant/embedded/mingw/bin/libstdc++-6.dll | ack gxx_personality [3896] __gxx_personality_sj0 Would updating Haskell Platform's libstdc++-6.dll fix this issue? Is there some way to cordon Haskell Platform off from the rest of the system, while still making ghc.exe and friends available on PATH? Here are my system specs, I figure they're highly relevant. $ specs haskell perl node ruby git os Specs: specs 0.4 https://github.com/mcandre/specs#readme cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.2 ghc-pkg field haskell-platform version version: 2012.4.0.0 cpan --version c:\strawberry\perl\bin/cpan version 1.5902 calling Getopt::Std::getopts (version 1.07 [paranoid]), running under Perl version 5.16.2. [Now continuing due to backward compatibility and excessive paranoia. See 'perldoc Getopt::Std' about $Getopt::Std::STANDARD_HELP_VERSION.] Nothing to install! perl --version This is perl 5, version 16, subversion 2 (v5.16.2) built for MSWin32-x86-multi-thread Copyright 1987-2012, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. npm --version 1.2.17 node --version v0.10.3 bundle --version Bundler version 1.3.2 gem --version 2.0.3 ruby --version ruby 1.9.3p374 (2013-01-15) [i386-mingw32] git --version git version 1.8.0.msysgit.0 systeminfo | findstr /B /C:"OS Name" /C:"OS Version" OS Name: Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 3 Build 2600 -- Cheers, Andrew Pennebaker www.yellosoft.us

2 1

ANN: stm-chans 2.0.0
by wren ng thornton 13 May '13

13 May '13

-------------------------------------------- -- stm-chans 2.0.0 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.{TChan,TQueue} but with additional features. -------------------------------------------- -- Changes (since 1.3.1) -------------------------------------------- * (by kudah) Added TMQueue and TBMQueue, which are like the corresponding T*Chans except using the new T*Queue data types in stm >= 2.4. We use CPP to provide compatibility shims for older versions of stm. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers the following data types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. * Control.Concurrent.STM.TMQueue: Closeable FIFO queues. Like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. * Control.Concurrent.STM.TBMQueue: Bounded Closeable FIFO queues. Combines the capabilities of TBChan and TMChan. In addition, the stm-chans package offers a (partial) compatibility layer for various changes to the stm package. These include backwards compatibility for the T*Queue types, as well as various API improvements (see ticket #5104 [1]). [1] http://hackage.haskell.org/trac/ghc/ticket/5104 -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

1 0

Stream processing
by oleg＠okmij.org 13 May '13

13 May '13

I'm a bit curious > * be reliable in the presence of async exceptions (solved by conduit, > pipes-safe), > > * hold on to resources only as long as necessary (solved by conduit > and to some degree by pipes-safe), Are you aware of http://okmij.org/ftp/Streams.html#regions which describes both resource deallocation and async signals. Could you tell what you think is deficient in that code? > * ideally also allow upstream communication (solved by pipes and to > some degree by conduit). Are you aware (of, admittedly) old message whose title was specifically ``Sending messages up-and-down the iteratee-enumerator chain'' http://www.haskell.org/pipermail/haskell-cafe/2011-May/091870.html (there were several messages in that thread). Here is the code for those messages http://okmij.org/ftp/Haskell/Iteratee/UpDown.hs

3 2

Google Summer of Code Proposal - Communicating with mobile devices
by Marcos Pividori 13 May '13

13 May '13

Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM – It is a Spanish commented version because it was a project for my University, I will replace it for an English version in the next weeks) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be really grateful if you could give me your opinion about this project and the proposal. I want some feedback in order to know if this would be a useful tool and what you would like to get out of it. *Communicating with mobile devices* * * *Abstract* The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily. When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are: - Google Cloud Messaging (Android) - Apple Push Notification Service (iPhone / iPad) - Microsoft Push Notification Service (Windows Phone) - BlackBerry Push Service (BlackBerry) - Windows Push Notification Services (Windows 8) - etc. Once we have this libraries, I will investigate the possibility of mainting a "back and forth" communication between a server and mobile devices and I will develop a library to handle this. * * *Motivation and expected benefits* I think this idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them. Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner. Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast). This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed. This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available. The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc. As all the libraries to access to these services are developed in Java, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user. *Deliverables.* * * * An API library to build and send messages including: - GCM and a demo Android app. - APN and a demo iOS app. - Microsoft Push Notification Service (Windows Phone) and a demo app. - Documentation for all the code developed. Including the explantation on how to use the server library and how to try the demo apps. * A library to handle a "back and forth" comunication between a server and mobile devices. Tools to mantain a state of the connection and manage with a lot of devices at the same time. A Yesod app example of the use of this library and a demo app for each OS (Android, iOS, Windows Phone, etc) to manage this communication. * Optionally: - an API for communication through BlackBerry Push Service (BlackBerry). - an API for communication through Windows Push Notification Services (Windows 8). *Technical Considerations* In the developing of the APIs for the communication through Push Notifications, I will aim to develop a good abstraction and find the properties in common between the differents services in order to develope an customizable tool but at the same time with a common structure. I want to let the user build messages and send these in a simple way following each protocol. Also, I will abstract the process of registering the devices in the server and let the user manage the different registrations behind a similar abstraccion. To develop a “back and forth” comunication between a server and mobile devices, I will investigate the different possibilities of maintaining a state of the connection. It could be through the use of cookies stored by the clients or maintaining some extra information in the server which would enable it to identify the different connections and provide the appropiate services.

3 3

GPGPU
by Christopher Howard 12 May '13

12 May '13

Has anybody on the list been playing around with OpenCL at all? I'm just starting to look into it - need to get a newer Radeon card, I think - but I'm strongly interested in GPGPU programming. -- frigidcode.com

4 6

Re: [Haskell-cafe] Categories (cont.)
by wren ng thornton 11 May '13

11 May '13

On 5/8/13 12:14 PM, Conal Elliott wrote: > Hi Wren, > > Have you taken this "constrained categories" experiment further, > particularly for adding products? As I mentioned in a haskell-cafe note > yesterday, I tried and got a frightening proliferation of constraints when > defining method defaults and utility functions (e.g., left- or > right-associating). I haven't investigated further since my previous emails on the idea. When working with them, though, I did notice that things work out a lot better with separate unary constraints on domains and codomains, as opposed to having a binary constraint that relates domains to codomains. (The latter is, of course, strictly more powerful; which may be the problem.) As another part of that project, however, I've been working on type-level arithmetic, and that also leads to a frightening proliferation of constraints. The problem is that even though we can implement the definitions of addition, comparison, etc, there's no good way to teach the constraint solver facts like: m < S m m <= m+n -- For natural numbers, not integers. m <= n -> exists o. n == m+o m <= n -> n <= o -> m <= o etc The introduction of these facts would introduce nondeterminism into the resolution of constraints--- since the solver would need to decide between using the inductive definitions vs these auxilliary facts. My impression is that the difficulties here are the same for both cases... -- Live well, ~wren

1 0

Stream processing
by Ertugrul Söylemez 11 May '13

11 May '13

Hello everybody, I'm trying to formulate the stream processing problem, which doesn't seem to be solved fully by the currently existing patterns. I'm experimenting with a new idea, but I want to make sure that I don't miss any defining features of the problem, so here is my list. A stream processing abstraction should: * have a categorically proven design (solved by iteratees, pipes), * be composable (solved by all of them), * be reasonably easy to understand and work with (solved by conduit, pipes), * support leftovers (solved by conduit and to some degree by iteratees), * be reliable in the presence of async exceptions (solved by conduit, pipes-safe), * hold on to resources only as long as necessary (solved by conduit and to some degree by pipes-safe), * ideally also allow upstream communication (solved by pipes and to some degree by conduit). * be fast (solved by all of them). Anything else you would put in that list? 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.

3 3

I wish cabal-dev to travel back in time
by Alberto G. Corona 11 May '13

11 May '13

Hi Café: I created just now an issue in cabal-dev: https://github.com/creswick/cabal-dev/issues/101 When compiling old developments, I wish cabal-dev to install and build dependencies that were available at a that time I don't know if there are alternatives to solving this issue. I think that this is very useful and necessary, specially now when library updates are increasingly frequent. Maybe this problem is already solved and I just don´t know (as is often the case, for example when, in a sudden aha moment, I reinvented cabal-install months after the release). That is the reason why I tell you about it here in order to discuss it. motivation: I´m installing now an old soft development. Since many of my dependencies were labeled with -any or with > , neither I neither cabal know which library versions are the right ones. By taking into account a date parameter, cabal-dev can figure out which libraries were the latest and the right ones at that time. -- Alberto.

3 2

Re: [Haskell-cafe] Reinventing a solution to configuration problem
by oleg＠okmij.org 11 May '13

11 May '13

I guess you might like then http://okmij.org/ftp/Haskell/types.html#Prepose which discusses implicit parameters and their drawbacks (see Sec 6.2).

1 0