News aggregator

CFP : Extended deadline : Functional Art, Music,Modelling and Design (FARM 2015)

General haskell list - Thu, 05/14/2015 - 11:12am
************************************************************ Call for Papers and Demos : FARM 2015 The 3rd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Vancouver, Canada, 5 September, 2015 affiliated with ICFP 2015 http://functional-art.org EXTENTED Submission Deadline : 27 May, 2015 (optional abstract submission : 17 May, 2015) ************************************************************ The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for expl
Categories: Incoming News

Suggestion: "Sizable" super class for Storable

haskell-cafe - Thu, 05/14/2015 - 9:50am
Storable instances have a size, given by sizeOf. In many cases, we're not interested in peeking/poking data but only passing it opaquely via the FFI. A common use case is when the C API offers an "init" function such as: void mycontext_init(mycontext *context); For these cases it would be useful to know the size of "mycontext", so we could malloc it and pass a pointer to mycontext_init. Also, it allows Haskell-side code to decide how it wants to allocate the data, perhaps using some other (external) mechanism not related to the specific API that the FFI bindings are wrapping. c2hs would benefit by allowing users to use the '+' notation in function parameters (which generate malloc-and-pass style code), without having to guess the size of the structure. Instead, it could simply use the Sizable (TM) instance to get the size, and the user will define Sizable in any way they want (for example, using the {#sizeof#} macro, which is somewhat unreliable, or by hard-coding or manually entering the size or b
Categories: Offsite Discussion

JP Moresmau: EclipseFP end of life (from me at least)

Planet Haskell - Thu, 05/14/2015 - 7:09am
Hello, after a few years and several releases, I am now stopping the maintenance of EclipseFP and its companion Haskell packages (BuildWrapper, ghc-pkg-lib and scion-browser). If anybody wants to take over I' ll gladly give them all what's required to get started. Feel free to fork and continue!

Why am I stopping? Not for a very specific reason, though seeing that I had to adapt BuildWrapper to GHC 7.10 didn't exactly fill me with joy, but more generally I got tired of being the single maintainer for this project. I got a few pull requests over the years and some people have at some stage participated (thanks to you, you know who you are!), but not enough, and the biggest part of the work has been always on my shoulders. Let's say I got tired of getting an endless stream of issues reports and enhancement requests with nobody stepping up to actually address them.

Also, I don't think on the Haskell side it makes sense for me to keep on working on a GHC API wrapper like BuildWrapper. There are other alternatives, and with the release of ide-backend, backed up by FPComplete, a real company staffed by competent people who seem to have more that 24 hours per day to hack on Haskell tools, it makes more sense to have consolidation there.

The goal of EclipseFP was to make it easy for Java developers or other Eclipse users to move to Haskell, and I think this has been a failure, mainly due to the inherent complexity of the setup (the Haskell stack and the Java stack) and the technical challenges of integrating GHC and Cabal in a complex IDE like Eclipse. Of course we could have done better with the constraints we were operating under, but if more eyes had looked at the code and more hands had worked on deck we could have succeeded.

Personally I would now be interested in maybe getting the Atom editor to use ide-backend-client, or maybe work on a web based (but local) Haskell IDE. Some of my dabblings can be found at https://github.com/JPMoresmau/dbIDE. But I would much prefer to not work on my own, so if you have an open source project you think could do with my help, I'll be happy to hear about it!

I still think Haskell is a great language that would deserve a top-notch IDE, for newbies and experts alike, and I hope one day we'll get there.

For you EclipseFP users, you can of course keep using it as long as it works, but if no other maintainers step up, down the line you'll have to look for other options, as compatibility with the Haskell ecosystem will not be assured. Good luck!

Happy Haskell Hacking!

Categories: Offsite Blogs

Bizarre ld error when trying to compile my program

Haskell on Reddit - Thu, 05/14/2015 - 6:34am

Someone solved it, both in the comments and on the IRC channel. Thanks for the help, everyone!

Hey, everyone!

I am working on this project here: https://github.com/pharpend/louse. When I try to compile the program with cabal install, I get this bizarre error with ld

Resolving dependencies... In order, the following will be installed: louse-0.1.0.0 +dev (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring louse-0.1.0.0... Building louse-0.1.0.0... Failed to install louse-0.1.0.0 Build log ( /home/pete/.cabal/logs/louse-0.1.0.0.log ): Configuring louse-0.1.0.0... Building louse-0.1.0.0... Preprocessing library louse-0.1.0.0... In-place registering louse-0.1.0.0... Preprocessing executable 'louse' for louse-0.1.0.0... [2 of 2] Compiling Main ( bin/louse.hs, dist/build/louse/louse-tmp/Main.o ) [Data.Louse.Bugs changed] Linking dist/build/louse/louse ... /home/pete/src/louse/dist/build/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x536e): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/src/louse/dist/build/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x65d2): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/src/louse/dist/build/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.data+0x8a0): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_closure' collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: louse-0.1.0.0 failed during the building phase. The exception was: ExitFailure 1

If I compile only the library, and try to compile the executable with plain ghc, the same thing happens:

Linking louse ... /home/pete/.cabal/lib/x86_64-linux-ghc-7.10.1/louse_0flN1wT55XYAdEZ4du8MhO/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x536e): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/.cabal/lib/x86_64-linux-ghc-7.10.1/louse_0flN1wT55XYAdEZ4du8MhO/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x65d2): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/.cabal/lib/x86_64-linux-ghc-7.10.1/louse_0flN1wT55XYAdEZ4du8MhO/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.data+0x8a0): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_closure' collect2: error: ld returned 1 exit status

The function that ld is complaining about: https://github.com/pharpend/louse/blob/master/Data/Louse/Config.hs#L38

readLouseConfig :: IO (Maybe LouseConfig) readLouseConfig = do configPath <- _config_path configPathExists <- doesFileExist configPath if configPathExists then do configBytes <- B.readFile configPath pure (decodeStrict configBytes) else pure Nothing

If I comment out the do-block, and replace the definition with pure Nothing, then everything compiles just fine-and-dandy. It's weird because the library compiles just fine, so it's not a type error. There's some weird undefined symbol in the generated code.

submitted by pharpend
[link] [11 comments]
Categories: Incoming News

Eve: the development diary of a programming environment aimed at non-programmers

Lambda the Ultimate - Thu, 05/14/2015 - 6:27am

In spring 2012 Chris Granger successfully completed a Kickstarter fundraising and got $300K (instead of the requested $200K) to work on a live-feedback IDE inspired by Bret Victor "Inventing on principle" talk. The IDE project was called Light Table. It initially supported Clojure (the team's favourite language) only, but eventually added support for Javascript and Python. In January 2014, Light Table was open sourced, and in October 2014 the Light Table development team announced that they decided to create a new language, Eve, that would be a better fit for their vision of programming experience.

There is little public about Eve so far, no precise design documents, but the development team has a public monthly Development Diary that I found fairly interesting. It displays an interesting form of research culture, with in particular recurrent reference to academic works that are coming from outside the programming-language-research community: database queries, Datalog evaluation, distributed systems, version-control systems. This diary might be a good opportunity to have a look at the internals of a language design process (or really programming environment design) that is neither academic nor really industrial in nature. It sounds more representative (I hope!) of the well-educated parts of startup culture.

Eve is a functional-relational language. Every input to an Eve program is stored in one of a few insert-only tables. The program itself consists of a series of views written in a relational query language. Some of these views represent internal state. Others represent IO that needs to be performed. Either way there is no hidden or forgotten state - the contents of these views can always be calculated from the input tables.

Eve is designed for live programming. As the user makes changes, the compiler is constantly re-compiling code and incrementally updating the views. The compiler is designed to be resilient and will compile and run as much of the code as possible in the face of errors. The structural editor restricts partially edited code to small sections, rather than rendering entire files unparseable. The pointer-free relational data model and the timeless views make it feasible to incrementally compute the state of the program, rather than starting from scratch on each edit.

The public/target for the language is described as "non-programmers", but in fact it looks like their control group has some previous experience of Excel. (I would guess that experimenting with children with no experience of programming at all, including no Excel work, could have resulted in very different results.)

Posts so far, by Jamie Brandon:

Some random quotes.

Retrospective:

Excited, we presented our prototype to a small number of non-programmers and sat back to watch the magic. To our horror, not a single one of them could figure out what the simple example program did or how it worked, nor could they produce any useful programs themselves. The sticking points were lexical scope and data structures. Every single person we talked to just wanted to put data in an Excel-like grid and drag direct references. Abstraction via symbol binding was not an intuitive or well-liked idea.

[...]

Our main data-structure was now a tree of tables. Rather than one big top-level function, we switched to a pipeline of functions. Each function pulled data out of the global store using a datalog query, ran some computation and wrote data back. Having less nesting reduced the impact of lexical scope and cursor passing. Using datalog allowed normalising the data store, avoiding all the issues that came from hierarchical models.

At this point we realised we weren't building a functional language anymore. Most of the programs were just datalog queries on normalised tables with a little scalar computation in the middle. We were familiar with Bloom and realised that it fit our needs much better than the functional pidgin we had built so far - no lexical scoping, no data-structures, no explicit ordering. In late March we began work on a Bloom interpreter.

October:

Where most languages express state as a series of changes ('when I click this button add 1 to the counter'), Eve is built around views over input logs ('the value of the counter is the number of button clicks in the log'). Thinking in terms of views makes the current language simple and powerful. It removes the need for explicit control flow, since views can be calculated in any order that is consistent with the dependency graph, and allows arbitrary composition of data without requiring the cooperation of the component that owns that data.

Whenever we have tried to introduce explicit change we immediately run into problems with ordering and composing those changes and we lose the ability to directly explain the state of the program without reference to data that no longer exists.

[...]

In a traditional imperative language, [context] is provided by access to dynamic scoping (or global variables - the poor mans dynamic scope) or by function parameters. In purely functional languages it can only be provided by function parameters, which is a problem when a deeply buried function wants to access some high up data and it has to be manually threaded through the entire callstack.

December:

Eve processes can now spawn subprocesses and inject code into them. Together with the new communication API this allowed much of the IDE architecture to be lifted into Eve. When running in the browser only the UI manager lives on the main thread - the editor, the compiler and the user's program all live in separate web-workers. The editor uses the process API to spawn both the compiler and the user's program and then subscribes to the views it needs for the debugging interface. Both the editor and the user's program send graphics data to the UI manager and receiving UI events in return.
Categories: Offsite Discussion

LambdaCms: CMS in Haskell project has open intern positions

Haskell on Reddit - Thu, 05/14/2015 - 4:28am

About a year ago I announced open internship positions at Hoppinger for building a CMS with Haskell. The resulted in the proud announcement of LambdaCms here on Reddit about eight months later. An interesting remark: one of the interns managed to score an 9.5/10 for the project resulting in a cum laude.

While LambdaCms is usable, incredibly fast (2-10ms responses), and comes with a nice list of features, it is still quite basic in the realm of CMSes.

We have decided to commit to another internship project in order to improve it further. Currently one intern, student at the Rotterdam University of Applied Sciences, has committed to work on the project from September '15 to January '16. By this message we want to announce that, in the second half of 2015, we still have one or two positions open on this project.

submitted by cies010
[link] [4 comments]
Categories: Incoming News

CFP: Extended Deadline: Functional High-Performance Computing (held with ICFP)

General haskell list - Thu, 05/14/2015 - 1:35am
====================================================================== CALL FOR PAPERS FHPC 2015 The 4th ACM SIGPLAN Workshop on Functional High-Performance Computing Vancouver, British Columbia, Canada, Canada September 3, 2015 https://sites.google.com/site/fhpcworkshops/ Co-located with the International Conference on Functional Programming (ICFP 2015) EXTENDED Submission Deadline: Friday, 22 May, 2015 (anywhere on earth) ====================================================================== The FHPC workshop aims at bringing together researchers exploring uses of functional (or more generally, declarative or high-level) programming technology in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specificat
Categories: Incoming News

CFP: Extended Deadline: Functional High-Performance Computing (held with ICFP)

haskell-cafe - Thu, 05/14/2015 - 1:35am
====================================================================== CALL FOR PAPERS FHPC 2015 The 4th ACM SIGPLAN Workshop on Functional High-Performance Computing Vancouver, British Columbia, Canada, Canada September 3, 2015 https://sites.google.com/site/fhpcworkshops/ Co-located with the International Conference on Functional Programming (ICFP 2015) EXTENDED Submission Deadline: Friday, 22 May, 2015 (anywhere on earth) ====================================================================== The FHPC workshop aims at bringing together researchers exploring uses of functional (or more generally, declarative or high-level) programming technology in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specificat
Categories: Offsite Discussion

maintaining pre-AMP+FTP-Prelude in external package

libraries list - Wed, 05/13/2015 - 12:50pm
The Prelude of GHC-7.10/base-4.8 introduces several name clashes mostly due to the AMP and FTP: (<*) clashes with Accelerate, (<*>) clashes with NumericPrelude, (and (<>) would clash with HMatrix if added to Prelude), 'join', 'pure', 'traverse', 'fold' clash with custom defined functions. "import Prelude hiding (pure)" is not yet supported by GHC-7.4 (as shipped with Ubuntu 12.04) and in newer GHC versions it generates an annoying warning. The only remaining option is to explicitly import identifiers from Prelude. What about maintaining the pre-AMP+FTP-Prelude in a package on Hackage? Then we could maintain compatibility with a range of GHC versions by disabling import of Prelude and importing preamplified (so to speak) Prelude. The base-compat package seems to support the other way round, that is, providing new 'base' functions to old compilers.
Categories: Offsite Discussion

Fedora ghc-7.10.1 repo

glasgow-user - Wed, 05/13/2015 - 4:28am
Hi, It is a bit later than I wanted but I have prepared a Fedora Copr repo for ghc-7.10.1. https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.1/ (note the EPEL7 and F20 builds are currently quick builds and the F21+ builds are perf builds) I will probably add a cabal-install build soon. Let me know if you find any problems or if it is useful. :) Jens
Categories: Offsite Discussion

Proposal: Generalize forever to Applicative

libraries list - Tue, 05/12/2015 - 6:05am
This looks like a no-brainer to me: forever :: Applicative f => f a -> f b forever a = let x = a *> x in x _______________________________________________ Libraries mailing list Libraries< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Categories: Offsite Discussion

mapM /= traverse?

libraries list - Mon, 05/11/2015 - 8:15pm
I was hoping that in GHC 7.10 we would make mapM = traverse for lists, but it appears this isn't the case: the Traversable instance for lists overrides mapM to be the manually-defined version in terms of foldr. Why is this? Fusion? Unfortunately since I want mapM = traverse (for Haxl) I'll need to continue to redefine it in our custom Prelude. Cheers, Simon
Categories: Offsite Discussion

RFC: "Native -XCPP" Proposal

glasgow-user - Wed, 05/06/2015 - 12:08pm
Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and
Categories: Offsite Discussion

Looking for retainers of PINNED objects

glasgow-user - Wed, 04/29/2015 - 5:37am
Hi all, I'm profiling a fairly large program which seems to have a space leak. The heap profiling (-hc) shows that PINNED objects are accumulated over time. In order to check the retainers of the objects, I ran the retainer profiling. Unfortunately it didn't output anything with -hr -hcPINNED. Also, this is just a guess though, the retainer profiling without any filters (I mean just -hr) doesn't seem to include PINNED objects at all. Is there a way to check what retains the PINNED objects? Thanks, Mitsutoshi _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

SIMD

glasgow-user - Sat, 04/11/2015 - 5:44pm
What’s the story with this? I tried to follow the instructions here: https://ghc.haskell.org/trac/ghc/wiki/SIMD <https://ghc.haskell.org/trac/ghc/wiki/SIMD> but I get Dominic Steinitz dominic< at >steinitz.org http://idontgetoutmuch.wordpress.com _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!

~d

Categories: Incoming News