EclipseFP 2.6.2 released!

I've just released EclipseFP 2.6.2. This is mainly a bug fixing release with a better handling of cabal sandboxes and related functionality. It wraps also an important change in scion-browser, which should now mean that Hoogle uses all the packages present in your sandbox, so should give better results.

Browse the release notes!

Install by pointing your eclipse to http://eclipsefp.sf.net/updates.

This release is brought to you by me, myself and I. I would love to see more people contribute, even if only to install the development versions to provide some testing before the release, or write some documentation. There's work that can be done on the Haskell side, on the Java side, etc. Contact me if you're not sure, or send me pull requests! The code is at https://github.com/JPMoresmau/eclipsefp, https://github.com/JPMoresmau/BuildWrapper and https://github.com/JPMoresmau/scion-class-browser.

Happy Haskell Hacking!!

A new Haskell IDE!

Well, that title is click-bait. It's only a proof of concept, so far (-:, sorry!

I wanted to play with Threepenny-GUI since it allowed to do UI the FRP way, without having the troubles of getting a proper UI library to work. And I was going through a period of frustration with EclipseFP, so I thought about something else for a while... It's got the romantic name of HWIDE!

So in fact, this is a very simple integration of CodeMirror and Threepenny-GUI, to be able to edit Haskell sources inside your browser. When you save your buffer, the data is written to disk, and if a cabal file could be found for that source file, a cabal build (in a sandbox) is attempted (with a configure if needed). The output is then parsed by code ripped off BuildWrapper, and the errors/warnings are displayed, so you can click on them and see the offending line in the code.

That's all, really, and even that is not 100% perfect, but it's a start. I could get to play a bit with Events and Behaviors, develop some little widgets. If some FRP experts want to have a look at the code and offer some advice, I'd be all ears!

I probably won't have much time to turn this into the next generation Haskell IDE, but please fork and hack to your heart's content! The repository is at https://github.com/JPMoresmau/dbIDE.

Happy Haskell Hacking!

Learning Scala via unit tests

Last month I followed a big data training session, and we used Scala to write algorithms for Spark. I had looked at Scala some years ago but I think at the time the Eclipse support wasn't very good (the pot calling the kettle black, eh?), and it piqued my curiosity again. So I started looking at tutorials, and found Scala Labs. The idea is interesting: you get a project with sources and tests, and you need to make all the tests pass. The source code for both the code to change and the unit tests is heavily documented, and guides you through the language nicely. And seeing the green ticks appear always triggers the proper reward areas of my brain (-:

I had a little issue getting the code to compile using Eclipse, since there's a sbt-launch-0.13.0.jar library at the root of the project, and Eclipse used that as the top library, and it had a weird version of the List class, that wasn't genericized! I removed that jar from the class path and everything worked fine.

I'm not aware of a similar tutorial for Haskell, but that would be a good idea!

Fame at last!

I was reading the book "Haskell Data Analysis Cookbook" when suddenly, my name pops up! Funny to see a link to a 7 year old blog entry, who knew I would go down in history for a few line of codes for a perceptron? It's deep in Chapter 7, for those interested. Maybe this is a sign that I should abandon everything else and spend my time on AI, since it's obviously where fame and riches abound! Right...

EclipseFP 2.6.1 released!

I've just released EclipseFP 2.6.1. EclipseFP is a set of Eclipse plugins for Haskell development. This is a bug fixing release, mainly for GHC 7.8 support.

Release notes can be found here.

As usual, download from http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

BuildWrapper/EclipseFP and GHC 7.8

I've been working on some issues related to GHC 7.8 in BuildWrapper and EclipseFP. On the EclipseFP side, mainly the quickfixes are affected, because EclipseFP parses the GHC error messages to offer them, and the quotes characters have changed in the GHC 7.8 messages.

On the BuildWrapper side, things are more complex. Adapting to API changes wasn't a big deal, but it seems that GHC bugs involving the GHC API, static linking and other unknowns cause some things to break. The solution I've found was to build BuildWrapper with the -dynamic flag. But I couldn't upload this to hackage because Cabal thinks that -dynamic is a debug flag (it starts with d). I've sent a bug fix to Cabal, so in the next release that'll be fixed. So if you're using GHC 7.8 and BuildWrapper, you may want to rebuild the executable with -dynamic (uncomment the relevant line in the cabal file).

Note: BuildWrapper comes with a comprehensive test suite (90 tests covering all aspects). So you can always build the tests and run them to ensure everyting is OK on your system.

Happy Haskell Hacking!

EclipseFP reaches 100 stars!

This week, the EclipseFP github project reached a hundred stars! Thanks to all users and contributors!! I know still a lot of work is needed to make EclipseFP even better (and faster (-:), so please do not hesitate to participate, on the Eclipse side, on the Haskell side, or on the documentation!

Happy Haskell Hacking!

EclipseFP 2.6.0 released!

It's my pleasure to announce the release of EclipseFP 2.6.0. EclipseFP is a set of Eclipse plugins for Haskell development.
The full release notes can be found here. Of particular interest is :

• Support for cabal 1.18 sandboxes
• Worksheet for live programming (like GHCi expressions but automatically refreshed on save)

As usual, just install by pointing your Eclipse to http://eclipsefp.sf.net/.

Happy Haskell Hacking!

Reflecting on Ubuntu

It's been a while now since I moved to Ubuntu as my Haskell development OS. On the whole working in Ubuntu is a pleasant experience. I adapted easily to the UI, the support groups have loads of answers when I have an issue, and things usually install well, be it Haskell libraries or additional tools. I like that 99% of the time the upgrades do not require a restart. I have a few gripes, though.

• Eclipse is not always stable and crashes from time to time (a couple of times a week), say. I haven't found any fix for that yet. It seems to be a UI library issue, maybe something to do with SWT. 
• Maybe it's linked, but I've had some cases where Eclipse seemed to starve the machine of resources, and it was a huge pain to kill it. In Windows I go Ctrl-Alt-Del and kill the process via the task manager, and that's not an issue. On Ubuntu going Ctrl-Alt-F1 to go to another session, login, find the process and kill it tooks ages. I tried to change to setting to forbid an application to take to much resources but I don't think it helped. There's maybe another way to kill a misbehaving application that I'd love to know...
• There are still some rough edges for things that should be simple. I can't get my printer to work (a run of the mill Canon printer), and there's a limit to the number of hours I'm willing to spend on getting something stupid like that to work. The other day RhythmBox (the software that apparently tries to play my CDs) crashed repeatedly after the first song on a CD that plays fine on Windows (maybe RhythmBox doesn't like Michael Schenker?). Seriously? Playing a CD is too hard?

So in the end, after hearing for years that Windows was not a great OS, I don't find Ubuntu that more stable or solid. I love not to be on a third-grade OS for Haskell libraries, don't get me wrong, so I'll stick with it, and hopefully the issues will go away!

Hidden Markov Models for Natural Language Tagging, in Haskell

I became intrigued in Hidden Markov Models after reading Kurzweil, who claims they can be used to model the thinking process in the brain. There is much debate about that, but these are interesting AI structures. This page I think has a good introduction.

I was working though the (partial) online book on Natural Language Processing with Haskell, and thought of combining the two. I used Mike Izbicki's hmm library for a one order Hidden Markov Model implementation. Once I initialized the model properly using the training data, I got around 91% accuracy on tagging, which is on par with the rules based approach presented in the nlpwp book.

I used the strategy outline in this paper to deal with unknown words (words in the test set not met in the training set): replace these words with a token that is also used for low frequency words in the training set. So far I've used only one token but I suppose being a bit more fined grained (to distinguish words starting with a capital letter, currency amounts, numbers) will improve results.

Performance is not very good even with some parallelism, so I think I need to spend more time on it, but it's definitely encouraging. It'll be a little bit of time till I have a thinking brain, though, but there is hope!

Beginning Haskell: the Book!

It's my pleasure to relay the news of the publication of a new Haskell book, Beginning Haskell. It's written by one of EclipseFP contributors, Alejandro, and I've had the pleasure to be a technical reviewer of the book. I learned a lot, so I can heartily recommend it! It takes the reader from the very basics of functional programming to some intermediate and advanced Haskell techniques. Alejandro of course talks about it better than me.

Happy Haskell Reading! Thanks Alejandro for the great work!

Haskell Worksheet in EclipseFP 2.6

A sneak preview of the worksheet functionality in the upcoming EclipseFP release. I have a Haskell module with a few functions, and the worksheet displays some results using different rendering modes:

• Simple text: shows the result of the expression as GHCi would
• HTML/SVG: renders HTML markup and SVG images in a SWT Browser element. In the screenshot there's Blaze HTML and Diagrams SVG
• JSON: display JSON objects and arrays in a tree

We use BuildWrapper and the GHC API to execute the expressions every time the file is saved. The expressions are persistent and hence survive restarting Eclipse.

I don't know when EclipseFP 2.6 will be released, but you can of course get the current code from github.

Cabal sandbox support in EclipseFP 2.6

I seem to have managed to free myself a bit of time, which means I can work a bit on EclipseFP 2.6.  I've added support for cabal sandboxes, so you'll be able to use sandboxing with cabal 1.18 in pretty much the same way cabal-dev was supported. You can have a per project or per workspace sandbox, and the fact that add-source is dynamic simplifies the internal code somehow. Cabal-dev is still supported.

A nice side effect of supporting Cabal 1.18 (thanks again to dynamic-cabal) is that we can use a sandbox to install the executables we need, like buildwrapper and scion-browser. Up to now, if you hadn't installed them, you'd get a dialog box asking you if you wanted to. Users have complained that this was an unnecessary step, but I didn't want to install executables with many dependencies into the user's package database without a notice. Now, executables get installed into a specific sandbox, so the install may be a bit longer if you already had some dependencies, but we don't mess up anything on your system.
The only issue is that inside a cabal sandbox, all packages need to be coherent: you cannot have two different versions of the same library. This shouldn't normally be an issue, but it is at the moment, because we try to install HLint and SourceGraph, that both require a different version of haskell-src-exts. I have sent a patch to Ivan Lazar Miljenovic so that SourceGraph can support the latest version of haskell-src-exts so hopefully this will be sorted by the time EclipseFP 2.6 hit the metaphorical shelves.

So hopefully EclipseFP 2.6 will be easier to install and will take advantage of the latest Cabal functionality!

Dynamic-cabal to solve dependency hell in BuildWrapper

As I've explained in several places, we have an issue in BuildWrapper (the underlying Haskell program for the EclipseFP plugins): BuildWrapper depends on both the GHC API and the Cabal API. Since GHC itself has a dependency on Cabal, once you've installed GHC, BuildWrapper can only use the same version of the Cabal API that was used by that GHC. Moreover, some Cabal files (setup-config in the dist directory for example) are cabal version dependent (since they only serialize Haskell structures, this is for safety). The net result is that if you install a newer version of Cabal and cabal-install, BuildWrapper still uses the old version, and hence the Cabal library BuildWrapper uses and the cabal-install executable have different versions, and hell breaks loose.

I have looked at solving the issue in GHC itself: GHC does not need to have a dependency to the Cabal API. I had started investigating with help from GHC devs, but it was end of October, and I had understood that GHC 7.8 was to be released in November, so there was no time to do such a change. So I thought I would wait for the next release. But it's now end of December, and GHC 7.8 still hasn't been released. So should we have to wait another year to solve that issue? Gasp!

But then, out of the blue, help came! Benno Fünfstück released dynamic-cabal, with the promise that it would solve exactly this issue! I actually should have had that idea myself, but hey... Basically, dynamic-cabal provides simpler structures than the full Cabal API, and extracts them from the Cabal API via dynamic code generation. The code is generated and ran dynamically using the GHC API. Since the running code itself doesn't depend on GHC, it can use the latest version of the Cabal library, and hence read the setup-config file properly!

I have now rewritten parts of BuildWrapper to use dynamic-cabal, and I only had to add minor enhancements to dynamic-cabal. I have upgraded my own cabal-install to 1.18 and everything works (my GHC still uses Cabal 1.16)!! I'm not releasing that version yet because it will provide some new features for EclipseFP 2.6, but if really you want to give it a try just build it from Github.

So my thanks go to Benno! A big hurdle has been cleared on EclipseFP's path to world domination!

EclipseFP 2.5.6 released

It's my pleasure to announce a new version of the Eclipse plugins for Haskell development, version 2.5.6! This is a minor, bug fixing release. The release notes can be found here.

To install, just point Eclipse to the update site: http://eclipsefp.sf.net/updates.

I expect that the next version will be a 2.6 with more features, as hopefully I'll have more free time.

Happy Haskell Hacking!

Reactive-banana-SDL on Hackage!

I've uploaded to Hackage the reactive-banana-sdl library. This library was developed by R. Kyle Murphy(orclev), and I've just added a couple of functions and some documentation in the code. Orclev didn't want to maintain it anymore so I've taken the maintainer role, but I'm certainly not a FRP expert (in fact I started to use the library to learn about FRP), so be gentle...

I have a little typing game called TypeClass, which uses the library. You can have a look at the code, it may help you get started.

There's not that much there, but hopefully this can be of use to some people, and let me know what goodies we could add!

Happy Reactive SDL Hacking!

Acme editor for Haskell development?

 A post on reddit made me discover the Oberon system and the Acme editor, that drew inspiration from it. There is a cool video on YouTube of the Acme editor in action. The concept that "everything is Text" and "every bit of text can be an executable action" looks really powerful, even if it looks like it would take a bit of practice to get used to the mouse chording and the intensive usage of the three mouse buttons.

Working with an IDE that's quite heavy (understatement of the year), I'm certainly drawn to that simplicity and power much more than to other editors like Emacs and Vi, where it seems you have to remember an near-infinite list of arcane key combinations to be productive.

So I'm wondering, are there people out there using Acme or Oberon or Plan 9 for Haskell development? How do you find it? What good ideas could be applicable to other environments? I'm always looking out for ways to improve EclipseFP and Haskell development tools in general, is this a path worth exploring?
I've seen that blog entry, from somebody apparently using Erlang, and I noticed the following: Other sacrifices are syntax highlighting, automatic indentation, specific language support. Is that true? Isn't there a way to add syntax highlighting in Acme? And I suppose the specific language support you get by exposing your tool via the Acme system for text commands...

Happy Haskell Hacking, on Acme or not!

EclipseFP 2.5.5 released!

It is my pleasure to announce a new release of EclipseFP, version 2.5.5. EclipseFP are Eclipse plugins for Haskell development. This is mainly a bug fix release with only small enhancements, so I recommend everybody upgrade (from the update site http://eclipsefp.sf.net/updates).
The release notes can be found here.

I'm hoping that the next release will be a major one, with big enhancements. So I'll gladly have contributors if people want to join the fun!

Happy Haskell Hacking!

EclipseFP: laundry list for 2.6

I seem to have a bit more free time these days to work on EclipseFP, so I was thinking about what we should try to add in the next major release. In no particular order:

• Sandboxing via Cabal 1.18 support and not only cabal-dev. Maybe also using cabal repl could replace some code in the GHCi launch configuration management.
• HSpec 
• Cabal bench
• An Haskell worksheet similar to the Scala worksheet. This would allow a better integration with the UI than running a GHCi launch, and would be able to persist test expressions over reloads and even Eclipse restarts. This would help people to play around with their code and see the results straight away. We could add things like time of execution, history of timings so you could check if you're improving the performance, pluggable graphical representations, save as unit test (make a unit test that checks that the given expression always give the current result)... Note that buildwrapper already has code to perform evaluations of expressions using the GHC API, but this is not used yet by the Eclipse front-end.
• Integrate HaRe (into buildwrapper since it now uses the GHC API?) to provide more refactorings.
• See if new versions of tools we depend on, like haskell-src-exts, can do more things for us or allow us to get rid of some of our code to rely on theirs (yeah!)

Let me know if you have some great idea that's not on the list, or if any of these are of special interest to you. I know there some other requests that people have made that I haven't implemented yet, so you can also check the issue list and comment on those you'd like to see treated with higher priority.

If you feel the urge to fork the github repository and start working on something, please don't refrain, I'll be happy to get more contributors!

EclipseFP: package version bounds in dependencies

Coming in EclipseFP 2.5.5, the cabal editor lets you specify what policy you want to use in respect to versin bounds when adding a dependency to a package, instead of just referencing the package without any constraints, or having to type them by hand:

You have four options:

• None: as before, doesn't generate any bound
• Current major version: will restrict to the major version of the package you currently have
• Current major version from current minor: the minor version of the package you currently have is going to be the lowest version allowed, up to the next major version. This is the default, since it assumes the current version you have is the one you're testing against
• Current minor version: only use the minor version of the package you currently have

The text field shows you the actual values that get generated. This field is now read-only since you can first select a package then change the version restriction options. If you want to enter manually the version bounds, you can still do that on the main page where all the current dependencies are listed.

I hope it will let you conform to the Package Versioning Policy and provide reasonable dependency bounds on your libraries.

No date on the 2.5.5 release yet, there's a couple of things I'd like to do first. The Github version should be usable if any of you want to live on the edge (and perform some valuable testing!).