EclipseFP and performance

OK, ok, performance in EclipseFP could be better. I'll try to present a bit the challenges and why things are the way they are.

You see, EclipseFP used scion for a while, and scion was a long running process, which ended up eating loads of memory, and had a few issues due to the GHC API maintaining state and not releasing memory (I've written about this elsewhere). So I rewrote the whole Haskell backend with BuildWrapper, and I took opposite approach: BuildWrapper is an short-lived executable. You start BuildWrapper with some parameters, it does its stuff and outputs some JSON answer. And that's fine for a lot of operations. But people have started to complain that when they edit a source file, the feedback loop is quite slow, and they keep seeing that the synchronization job keeps on running all the time. That's because every time Eclipse says that the editor has changed (not every keystroke, luckily), EclipseFP goes back to BuildWrapper to analyze the source. So it fires the BuildWrapper executable (and only this can be slow if you have an over zealous anti virus running), which in turn builds up a GHC session, analyses the AST, writes it to JSON, and tears everything down. For small projects and fast machines, this is acceptable. But I eat my own dogfood, of course, and when working on BuildWrapper itself, I noticed things could be too slow for comfort. Sometimes it would take 4 seconds to analyze completely a file.

So I went the middle route. I create another command in BuildWrapper that makes the executable stay around and listen for more commands. More specifically, there is now a long running build command, that can repeatedly analyze a file while staying in the GHC session. It won't have the same issues as the long running scion because it's tied to the file you're editing. When you close the file in Eclipse, the executable dies. When you change something in the Cabal file, the executable restarts to it can take into account new modules, flags or dependencies. The synchronization job now runs in something like a quarter of the time, and even faster.

I believe we have a happy medium: most operations are short-lived and we don't need to worry about memory usage or stray processes, but where performance matters (when you're in the flow and writing Haskell and don't want to wait for the editor to catch up) we have a long running process that's efficient, but not too persistent.

This will be part of the upcoming 2.5.0 release of EclipseFP. Of course people are welcome to get the source and test it for themselves before the official release!

EclipseFP 2.4.2 released

Hello, I've just released 2.4.2 to fix a bug that caused HLint suggestions to not appear any more.

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

Happy Haskell Hacking!

EclipseFP 2.4.1 released

Hello, a quick release  to patch a bug in the preferences page, causing a NullPointerException, if you don't have buildwrapper set up at all.
There is also an enhancement done with a new call to BuildWrapper, which has been bumped to 0.6.4: autocompletion also shows local variables. This only works if your module could be compiled successfully (so that we could get a GHC AST to retrieve the local bindings). One area of work where EclipseFP could improve would be to be able to automatically recover from some errors to be able to generate the AST and the related information even in the face of errors.

As usual, point Eclipse to http://eclipsefp.sf.net/updates to update. Release notes are here.

Thanks to all the users for updating and telling me of issues, and also for all the kind words I received!

Happy Haskell Hacking!

EclipseFP 2.4.0 released!

Hello, I've just released version 2.4.0 of EclipseFP, the set of Haskell development plugins for Eclipse, along with BuildWrapper 0.6.3 and scion-browser 0.2.13.
The main change in that version is the support for HTF and the Haskell-specific test results view, which removes the dependency on the JDT Junit View. I've blogged about these changes earlier, here and here.
There are also improvements in GHCi support and various bug fixes.

The release notes can be viewed here. To install or update, just point your Eclipse to the update site http://eclipsefp.sf.net/updates.


Thanks to all users, and especially to all the people that submitted bug reports and requests for enhancements. Now, I'll also accept pull requests :-).
Happy Haskell Hacking!

EclipseFP and HTF: demo video

The next version of EclipseFP will integrate with the upcoming version of HTF, a great Haskell Framework for automated tests. As a preview of things to come, I've uploaded a video on YouTube.
In this video, I create a small library project, using the tutorial code from the HTF tutorial, then use the HTF Test Suite wizard in the Cabal editor to generate automatically the cabal test-suite stanza, the main module and a test module per library module I want to test.
The I paste in the actual HTF code, and run the test suite. The results show in the new Haskell Test Results View. I correct the mistakes, wait for the rebuild, and the tests pass!

This will be part of the EclipseFP 2.3.3 release (or maybe I'll call it 2.4), that will be released probably as soon as HTF version 0.10 is released.

I'm still experimenting with screen captures and YouTube video, so apologies if the video is not crystal clear. Best viewed on the large viewer, I guess.

Improved test support in EclipseFP

Last year during his GSoC, Alejandro Serrano did a great job of integrating test-framework results in the JUnit view. This has served me well in my own endeavors (buildwrapper has 50 something HUnit test cases).

But there were a few limitations:
- using the JUnit view added a dependency on JDT plugins
- the view only gave an error when double clicking on a test result because there was no link between a test and the source code it was in
- the test results only appeared once the full test suite had run

I have reviewed the options, and the upcoming version of EclipseFP will have the following changes:
- A specific view for Haskell test results. Basically a rip-off of the JUnit view, without the progress bar because it's a custom control the JUnit UI guys wrote and life's too short. It's got history so you can get back to previous runs, and shows errors or failures in the bottom text area.
- Integration with HTF. While the test-framework integration will still work, using HTF gives us:
   - Jump to location (from test result to test definition location or failure location), thanks to the HTF preprocessor
   - Running updates thanks to HTF generating JSON output after each test and not in one big file at the end.
   - Automated discovery of tests based on naming conventions
   - Easy reduction of test cases to run from a command line argument
   - Elapsed time of tests
   - while still retaining integration with HUnit and QuickCheck

Thanks Stefan Wehr for your great work! Make sure to read his tutorial on HTF.

I've ported the buildwrapper test suite to HTF, and voila!

Since HTF relies on a few pragmas, I'm now going to work on a couple of wizards to simplify creation of the HTF Cabal test-suite and a HTF module. Watch this space!

I've finally figured out the UI the users want

After years of struggling with "we'd like to be able to tweak X and Y, and be able to do Z as well, but it has to be really intuitive and easy to use". Yes, it's the responsibility of the developers (or of the user interface design guru if you're lucky enough to have one) to provide a powerful yet easy to use interface, with intuitive navigation, sensible defaults, expert modes, etc, but sometimes it just gets too much. If you want to be the one that decides when to change gears, you have to know how to use the clutch.

EclipseFP: first timid step towards live programming

The title is sensationalist. All I've done is tweak a bit how we interface between GHCi and the Eclipse debugging framework. What that allows now (in the development version of EclipseFP) is to have expressions (in the Debug Expressions View) evaluated even if you're not stopped at a breakpoint.
So when you work directly in GHCi, you type in expressions to check the results. But when you change some code and hit :reload, your bindings are lost, you need to retype the expressions. EclipseFP does all that for you.

I've posted a video of a simple session in action on YouTube. It's my first video ever! It just shows a trivial arithmetic function being changed and how the result refreshes as soon as you select back the running program in the Debug view. Best viewed large...

EclipseFP 2.3.2 released

I decided to release a new version of EclipseFP, 2.3.2. There also new versions of buildwrapper (0.6.2) and scion-browser (0.2.11) on hackage, even though they are not strictly required (but they compile under GHC 7.6).
This new minor releases offers some bug fixes and performance improvements. Hopefully the installation has been made easier (it is possible to install all helper executables from one place). The debugging mode has also been enhanced, with GHCi history support and the possibility to select expressions in the source code and add them to the Expressions view or see their current value in a popup (when stopped at a breakpoint).

As usual, just point your Eclipse to http://eclipsefp.sf.net/updates. The full release notes can be found here.

Thanks to all the users, bug reporters and contributors!

Happy Haskell Hacking!!

OpenAlchemist: the start of an AI in Haskell

Lately I've been quite addicted to OpenAlchemist, a Tetris-like game developed by I think a couple of French developers (cocorico!). The code is in C++, there doesn't seem to be a clear API to integrate with the engine, the forums are closed, but I still wanted to write an AI for the game..

So I've written a little something in Haskell and posted it on Github just in case it's of interest to somebody. I basically use the Win32 API to capture the game window and save it as a BMP, then I use the bmp library to open the BMP, and some home grown image recognition to see which shapes are displayed on the screen. Then comes the "easy" part, checking the possible combinations and seeing which one yields the higher score. So far the AI hasn't beaten my own high score, so there's still work to do!

I'm still struggling with shape recognition sometimes, so this is an area that needs an improvement. I probably need to read up a bit on the proper algorithms that people have found to do this kind of things instead of just writing my own, but hey, one needs to have fun!

Using GHCi History in the EclipseFP Debugger

I've been asked if the EclipseFP debugger could provide stack traces. Links to great presentations about the subject were even presented! Simon Marlow's explanation of what can be done now regarding stack traces was great, but doesn't solve my problem: the debugging session in EclipseFP uses the GHCi debugger, basically sending GHCi commands and parsing the ouput, and Simon's new solutions require -prof flags, and hence don't work with GHCi.
For the time being I've done something that is not stack traces, but can provide some context when debugging, using the GHCi history. If when invoking a function in GHCi function, you start with :trace, then the :hist command gives you the last 50 evaluation steps. EclipseFP now calls :hist automatically on reaching a breakpoint and parses its output. It represents them as stack frames in the debug view, even that's not what they are. This way, clicking on them opens and select the relevant code, so hopefully you can get an idea of where you are and what you code is doing.
A screenshot showing the history on the program given as an example in the debugging article of the Monad Reader (PDF warning!):

This will be part of the EclipseFP 2.3.2 release, hopefully this will be helpful to some.

Making working from home an attractive option for developers (and their employers)

Warning! This is not a technical post about EclipseFP or Haskell in particular, but rather some ramblings...

I’m a software programmer. I work mainly from home. I love it. But I’m aware that very few job postings offer the possibility to work remotely, and that if ever I have or want to change jobs, I will need to move somewhere else, where there’s a decent job market, to be able to work.

Now, I suppose it’s easy for me to work from home, for a variety of reasons:

•           I have been working on the same project for a few years with success, so my management can trust me to do the work well;
•           I manage a small team of people I’ve known for a long time and that have worked, like me, for years on the project, so instant messaging, emails, a few phone calls and the occasional meeting in person is sufficient interaction: they know what I expect from them, and for better or worse work mainly in their comfort zone;
•           I work in a company that has grown mainly by acquisitions so has development centers all over the globe, in which taking time zones into account for meetings is natural, for example;
•           I like to think of myself as self-motivated, organized and committed, so I don’t need somebody behind my back telling me to work harder ;
•           I enjoy the technical work so I don’t want to be promoted to a management only role, where office politics and being physically close to the movers and shakers of the company matter.

A few of these reasons are specific to me and my situation, but it seems that generally speaking, a few factors could be seen as promoting working from home:

•           The technology is here. At least in the western world, most houses have fast internet access. We have email, instant messaging, phone and video over the internet. We have distributed source control management. We have web interfaces for most tools we may use. We have cloud computing and virtualization so you can log into a remote machine and work on it as if it were local.
•           With the wave of outsourcing, managers should be used to have remote workers, even in different time zones. Of course there was a backlash against outsourcing, but I think the bad experiences with it were more down to the unreasonable expectations (pay less money, get more work done) than to the actual distance between managers and workers.
•           Companies may want to be seen as environment friendly. Encouraging people to commute and/or move to big cities is not a good thing in that regard. I barely use the car during the week now that I can work in my slippers.

Of course I’m well aware of all the objections a company can raise.

•           How could I pay a good salary to somebody I don’t see? But are you only judging the value of an employee by the number of hours she puts in? The end result, working code in a shipping product, can be evaluated the same.
•           How can I build a team spirit if nobody is in the same room? Well, we’re talking computer programmers here. Of course social interactions are good (and I get plenty of that in my personal life, thank you), but I strive on writing good code, making a successful product, and feeling I can satisfy customers and win new ones. I don’t need to be in the same office as the sales people to have that motivation. Meeting the people in the office from time to time is of course OK, the cost of travel and some hotel nights is nothing compared to the office lease and fuel savings.
•           How safe is my code going to be if programmers log on from any kind of location? Well, it happens that I have to travel (to a customer, to another office) so the problem is there even if your employees are not traveling remotely most of the time. Use efficient security procedures (the ones that don’t get in the way of getting work done so that people don’t get so fed up with them that they try to bypass them at all costs) and encrypted connections, I suppose…
•           How do I train my new or junior staff? That is a real issue. If somebody needs to be hand-held to get started, it won’t be doable remotely. So you may want to organize a few face to face sessions between new recruits and senior employees at the beginning. But when hiring experienced developers, this should not be an issue. Your code and your processes are well documented, right?

What more can we do to encourage companies to offer home working? Do we just need higher fuel prices to that employees cannot afford commuting? I hope we can be a bit more proactive. Can more technology help? Do we need more tools?

•           Integrating IDEs with communication tools so that communicating over live code is easier
•           Helping distributed design sessions using things like touch screens and motion capture sensors to better communicate the hand gestures that sometimes help conveying ideas better than word (but on the contrary, I sometimes feel that having to put down an idea in word helps it make clearer, and a trace of that thought can be kept)

Or do we have the tools and just need to get used to them?  Or is it just a shift in employee-employer relationship that may happen slowly and can’t be rushed? In this case, we need to push more stories like 37Signals, about how successful software companies are hiring remote employees and loving it!

EclipseFP 2.3.1 released

It's my pleasure to announce a new release of EclipseFP, the Eclipse plugins for Haskell development.


Main features in that release are command history in GHCi console and Stylish Haskell integration (see my previous post).
We've also enhanced tooltips, that now use HTML rendering and can combine errors/warnings with "thing at point" information. The error markers also show again squiggly lines at their exact location.


I'm pleased to be able to say "we" once again. Martijn Schrage has heavily contributed to this release, both on the Haskell and Eclipse sides. Thanks Martijn for the great work!


There are also releases of buildwrapper and scion-browser, the EclipseFP Haskell helper executables.
Update your plugins via the EclipseFP update site (http://eclipsefp.sf.net/updates), as usual. You can view the release notes here.


Happy Haskell Hacking!

EclipseFP: integrating stylish-haskell

Stylish-haskell is a new code formatter for Haskell, and people have asked for it to be integrated in EclipseFP. This will be part of the 2.3.1 release.

You install stylish-haskell and set its path as with any helper executable (if it's your path you don't even need to specify the path in EclipseFP). Then there's a preference page to set preferences for all projects in your workspace, and a property page on each project if you want project-specific settings:

Then it's only a matter of right-clicking on the source, and choose Source-> Format. Or of course Ctrl+Shift+F which is the standard formatting shortcut in Eclipse. EclipseFP handles writing the YAML configuration file for you!

Don't know yet when EclipseFP 2.3.1 will be released, pretty soon I think!

Command history in EclipseFP GHCi console

It seems to be a very basic functionality, but when you launch a GHCi session in EclipseFP, you don't have command history. You see the GHCi prompt, you can type all GHCi commands, but if you want to use the REPL repeatedly, you have the retype the same command every time. A few users have of course asked for command history.
Funny thing is, Eclipse doesn't give that out of the box, and on the web you can see a few frustrated people asking for it in their console views. But there seem to be no obvious solution. I was rapidly becoming one of these frustrated people, so I had a look.
The most obvious is to create our own view to handle GHCi interaction, and manage the GHCi process ourselves. Doable, but that means rewriting the whole console UI (multiple console, potentially different colors for input/output, etc). So instead I had a look at contributing to the console Eclipse opens for us.
Oh boy. As usual with Eclipse, the console API is quite daunting at first. You can create your own console, or you can just add contributors to the console UI, but since we're using the Eclipse standard classes for displaying a process, we're quite limited, and a lot of classes are created for us without any possibility of injecting our own. And nowhere did I find an easy way to just listen to what the user is sending to the process input stream!
So I didn't give up, and I managed to register key listeners and verify listeners on the actual console StyledText control, so I can listen to key presses and such. I then maintain the history of commands. There is a drop down action to see the list of commands, you can choose one from there, or you can use Control-Up and Control-Down to navigate the list. It also works when you paste in text from elsewhere. This will account for 95% of the cases, I hope. There are definitely things that don't work well: if you edit a command in the middle it won't record the proper one, for example, but these bugs I think I can live with for the moment.
For the moment it's enabled on interactive consoles (mainly for GHCi), but probably that code could be used outside of EclipseFP if anybody is interested. And of course if somebody has a better solution to the problem, let me know!

Command history will be part of the next minor release of EclipseFP, 2.3.1.

EclipseFP 2.3.0 released!

Hello, this is my pleasure to announce a new release of EclipseFP, 2.3.0, and of its companion Haskell packages, Buildwrapper (0.6.0) and Scion-Browser (0.2.9).
EclipseFP is a set of Eclipse plugins for Haskell development.

You can see the release notes for full details, but these are the main points:

• you can do search and replace in a Haskell aware manner. Basically we keep a database of where everything is defined and used in all the modules of your workspace, which lets you open a module, search for definitions or usage, rename things everywhere they're used.
• better integration with Yesod: when you have a yesod project, you can easily launch "yesod devel" on it.
• Preferences to specify the paths of all the Haskell tools we use
• More quick fixes: add OverloadedString, install missing package, etc.

Hopefully you'll find this release and its new features helpful. Of course, post any issue to the sourceforge forum. As usual, use the Eclipse install feature to update/install your plugins by pointing it to http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

Usage queries in EclipseFP 2.3.0

This post is to present a new functionality of EclipseFP 2.3.0: the ability to search where a specific item (function, type, constructor, module) is being used in a project or in the whole workspace.
The way it's done under the hood can be visualized by the following diagram:

• The EclipseFP code invokes the BuildWrapper executable when a file in the project has changed. BuildWrapper uses the GHC API to load the Haskell module from files, and get the AST. We actually use both the RenamedSource and the TypecheckedSource to combine information from both. From the AST we get a list of all the usages in the file: all the functions, for example, used in the file, and where. All this information is stored in a hidden bwinfo file,  in JSON format.
• EclipseFP then picks up the generated file and parses it. The usage data is then written in a SQLite database, whose file is stored in the plugin folder.
• All Haskell searches are then done against the SQLite database.

For the user, this gives the following possibilities:
- open a Haskell module from a dialog showing all known local modules in the workspace
- perform contextual searches for usages of a given object
- perform a search by typing a name in a dialog and maybe specifying additional criteria (search references and/or declarations, search constructors and/or types, etc).
- perform contextual rename of a given object. You can rename a function and everywhere where that function is invoked will be changed, using the Eclipse refactoring plugin.

I'm planning on releasing EclipseFP 2.3.0 pretty soon, so that people can start testing!

Autocomplete enhancements in EclipseFP 2.3.0

Hello,
Following improvements in the core of EclipseFP and BuildWrapper, autocomplete in EclipseFP 2.3.0 manages to give you proposals coming from other modules from your project, and adding the relevant imports on the fly if needed. However, there were already concerns about autocomplete giving back a lot of proposals and feeling cluttered. The preference of restricting the proposals to only those coming from existing imports or only to the packages referenced in the project cabal file applied all the time, so it wasn't easy to balance between the two concerns of power and clarity.
So I've made the following change: the preference is gone. Instead you can choose what you want at runtime, in the fashion of Java completion proposals. So let me show you how it works now.
First of all, if you trigger "content assist" without a prefix, you only get the list of symbols the current module knows about: functions defined in the module and in imported modules, because it would be too much to bring back everything. In this case, you get a simple list:

If you have a prefix, you get first the list of known symbols:

But pressing Ctrl-Space again shows you symbols from other modules in your project or packages you have referenced in your cabal file (it shows you the module name after the function name):

And you can press Ctrl-Space again to get all matching symbols in packages you haven't indicated in your cabal file (you can see the package name before the module name):

Of course, pressing Ctrl-Space again brings you back to the initial list.

Hope this answers the concerns people had, and will make EclipseFP more pleasant to use.

Oh, and I don't have a date for the 2.3.0 release, but hopefully sometime this summer. I still need to build the rename functionality (now I have search working, so rename shouldn't be too difficult to implement).

Happy Haskell Hacking

EclipseFP progress report April 2012

There's not going to be a new EclipseFP release at the end of April, I'm not going to keep the monthly release rhythm I had over the past couple of months. In fact, I have a few simple things I could have done that warranted a release (thanks tobbebex for all the suggestions), but I had already started the next big step, so I want to finish what I'm on before moving to other things.
The goal now is to have a database of usages over all projects in the workspace, so you can see where each module is imported, where each function is used, and then potentially do things like workspace-wide renames and such.
The way it's implemented at the moment:
- on the buildwrapper side, I use the GHC API to load all the modules for a given cabal component in a project, and extract usage information from the RenamedSource.
- the usage information is serialized as JSON to a file in the buildwrapper temporary folder
- these files will be read by EclipseFP after it's called buildwrapper generateUsage call
- the information will then be stored in a sqlite database stored in the workspace plugin folder.

So it will use sqlite as scion-browser does, but on the Eclipse side for performance reasons.

Most of the Haskell side of things is done, and I've started the Eclipse side. So far, this has allowed me the humble but useful "open a module" dialog, similar to "Open Type" in the JDT: it lists all the Haskell modules defined in the workspace and let you select one or several for opening the corresponding file in the editor. Selecting a module in the list shows in which project the file belongs. Wildcards are supported of course.

Hopefully all of this will prove useful.

Happy Haskell Hacking!

EclipseFP 2.2.4 released

I can't believe I've managed to keep the rhythm again, but a month after 2.2.3, here's 2.2.4! It's another minor release featuring:
- task tags: TODO, FIXME, etc in source code translate to task tags. This is configurable.
- GTK wizard: creates a new executable with the default sample GTK code and GTK dependency.
- Documentation generation goes through cabal haddock: less hassle, more power.
- You can now configure extra cabal parameters for your projects. For example, you can add more include and library directories that are specific to your install without modifying the cabal file.
- Hopefully better content assist: using the power of scion-browser to be able to provide more and better auto complete proposals.
- Better handling of related projects (for declaration resolution, breakpoint resolution, etc).

There are also a few bug fixes in there of course. Thanks to everybody for their feedback! Buildwrapper and scion-browser have had minor releases too.

I haven't yet started the big addition that would be a workspace wide embedded database to be able to do Haskell-sensitive searches and replace, but I've though about it, so I have a good idea on how I'm going to attack that. Hopefully for a 2.3.0!

The full release notes can be found here. As usual, to install, just point your Eclipse update UI to http://eclipsefp.sf.net/updates. 


New to eclipseFP? Check out the web site, and there's documentation inside Eclipse too...


Happy Haskell Hacking with EclipseFP!

Heads-up: EclipseFP moving to Java 1.6

Up to now EclipseFP kept Java 1.5 compatibility. Java 6 does not bring that much in terms of API so I was happy to keep it that way. However, I moved a few months back to Eclipse Indigo and since then I've had problem generating the plugin code. I have the feeling that exporting plugins compiled with a 1.6 JDK in 1.5 compatibility mode didn't work well (ending up in errors like "class java.lang.Object could not be resolved", which is scary enough in Java). So I bit the bullet and changed the compatibility level on all plugins. They do now require 1.6.
This change will come in EclipseFP 2.2.4 which I think will be released pretty soon (next week maybe) with a few minor enhancements. So if you were still stuck with Java 1.5, get ready to move... I suppose it will not affect many people anyway, but I'd rather warn in advance to avoid nasty surprises...

Can Frege (Haskell on Java) deliver?

As you know, I'm the main (and more or less, at the moment the sole) developer for EclipseFP. It's going reasonably well, I'm putting a few enhancements here and there, and there are a few big things that I'm planning to do that would be exciting to do and hopefully to use.

However, I can't shake off a nagging feeling that maybe my energy is not 100% useful to the community. The compelling argument of EclipseFP is that it allows developers that are familiar with Eclipse to develop in Haskell as easily as possible: they can concentrate on writing their Haskell code and not have to learn another IDE to do it. But I'm wondering if really there is an audience (apart for myself).
- Unix Hackers will use Vi/Emacs and will scoff at the very notion of using an IDE.
- People really into Haskell would probably prefer an IDE written in Haskell like Leksah, especially since such an IDE actually proves that developing GUI programs in Haskell is possible!
- People that are in the Eclipse/Java world and want to go into functional programming can do so in Scala, Clojure and of course now Frege. Frege now boasts an Eclipse plug-in as well, so really the incentive is great: you can use a Haskell-like language in Eclipse, with probably better integration that what EclipseFP can achieve since everything in Frege boils down to Java. I suppose you could even write the Eclipse plugin code in Frege.

I'm even tempted to make the jump myself. Maybe with Frege I'll get a ecosystem that's doesn't consider Windows as a second grade platform. But can it deliver, in terms of power, performance, reliability?
One thing is clear: Frege is moving forward, which is more that can be said, as far as I know, of others Haskell on the JVM efforts (even the Wiki page says that it'd be a hard job to do, obviously the Frege developers didn't let themselves be scared).

I'll be interested in hearing feedback on people's experience with Frege, and I think I'll take it for a spin myself soon. I'll post my experiences!

Revamping Haddock generation in EclipseFP

My attention was attracted to Haddock documentation generation when Serguei Trofimovich tried to build the documentation for buildwrapper. Not only did he fix some issues with it in my code (thanks Serguei!), but I then realized that I couldn't build the docs from EclipseFP. EclipseFP does provide a Haddock generation wizard, but it forgets to pass the proper GHC options, so if you reference hidden packages for example it won't work. The wizard seemed also very complex.
So I did what I do best, I hacked and slashed. I've removed the full haddock plugin and replaced it with a one page export wizard that uses cabal haddock, and only exposes the options cabal haddock supports. Works well.
So if ever you're reading this and you were using the old Haddock wizard in EclipseFP and really you need some features from it to be kept, give me a shout! Otherwise, you can have a look at the new wizard by getting the source from github.

Hopefully I'll release version 2.2.4 of EclipseFP soon enough, anyway.

Happy Haskell Hacking (and slashing :-))!

EclipseFP 2.2.3 released!

I didn't mean to make it exactly one month since last release, but EclipseFP 2.2.3 is out! There is also a new release of buildwrapper to go with it (0.5.0) and Alejandro released scion-browser 0.2.7 yesterday.
This comes with both bug fixes and minor enhancements that I hope you like. The readme has all the details, but basically:
- Michael Jones has tested EclipseFP thoroughly on Mac OSX, so it should run fine on that platform now. Please remember that UI applications may not use the same PATH as your Terminal, which may explain why things are not found, etc. Thanks Michael for the work!
- We have tried to improve autocomplete and text hovers by adding documentation and types when possible, autocompletion of pragmas, etc.
- Hopefully everything should build and work fine under GHC 7.4.1.

Hopefully the next step will be a big one: I'd like to be able to put together the GHC analysis of all modules of the project in some kind of DB to do things like project and workspace-wide type-aware searches, safe renaming, etc.

Thanks to the supportive users that not only report issues but are happy to investigate, you know who you are!

Happy Haskell hacking in EclipseFP!

Samples of NXT (Lego Mindstorms) programming in Haskell

I've just created a new repository on GitHub called nxt-samples. It's only got one program now, a Bumper program that has the robot going straight till it hits something, then reversing and turning a bit, and going again (inspired by this Bumper Car, even though mine has tracks and no wheel). I've put this up because I didn't find it easy to get started programming a NXT robot, even with the excellent NXT library. Samples on the web were pretty scarce.

A few things bit me:
- not waiting for the final orders to be sent to the robot before exiting the program. This got me wondering a long time why the robot wasn't performing in a consistent manner. Now I'm resetting the motors at the start and end of the program.
- I found it's more reliable to check how much the motors have moved by repeatedly and wait till you reach the amount you wanted in the first place
- I added a simple command: when you press space the robot halts and the program stops. However, this doesn't work on Windows: you need to press space AND enter. Look here to see the woeful story of a Windows only, 4 year old, GHC bug that was fixed, but then reverted as it caused regressions in Cygwin and such. Every few months, that poor bug gets pushed to next release...  I know I'm so uncool to use Windows, but really... Can Haskell be really successful without working well on the OS that a lot of corporate developers still use?

Hopefully I'll add to these samples as I go on playing with NXT... Any feedback appreciated!

EclipseFP 2.2.2 released!

A quick message to say a new version of EclipseFP has been released. It's a bit of a rushed released, because a series of cascading updates meant that scion-browser and EclipseFP got out of sync. A while back I had made changes to the scion-browser API to improve performance, and then persistent got upgraded and a new compatible version of scion-browser got released on sunday. Unfortunately my API changes got released too, which meant a lot of headaches for the poor users that upgraded. So I've released 2.2.2 which is compatible with scion-browser 0.2.5.
It does bring a few enhancements, though:
- outline, tooltips and jump to definition should be much faster
- HLint suggestions can be applied via the quick fix action on the suggestion marker
- clean project does what it advertises: deletes the whole .dist-buildwrapper directory

As usual, just use the update site from inside Eclipse to upgrade. Please report all bugs on the Source forge forum or tracker.

Happy Haskell hacking!!

Lego Mindstorms, Haskell, Windows: all set!

A new version of the NXT library has been released, and it supports Windows!! I lamented a few weeks ago that it only ran on Unix/MacOs (requiring the unix package and using Posix file descriptors), but that's a thing of the past. It was really easy to port Mitar's code to use the serialport package instead of file descriptors. Now Mitar has merged back my changes, we've tested the code on Linux and Windows, and it's been released on Hackage!

So now I can control my Lego Mindstorm robot from Haskell on my Windows machine! World domination is only a couple more steps away!

I wish to point out that Mitar's code is extremely well commented and a pleasure to work with, which of course made the adaptation to Windows a lot easier. Thank you!

EclipseFP 2.2.1 released

It is my pleasure to announce a new version of EclipseFP. Release 2.2.1 does not bring huge changes in the UI, but comes with important bug fixes and small enhancements. More importantly, it integrates with the latest versions of buildwrapper and scion-browser. You can see the release notes here.

We tried to enhance the performance and stability of EclipseFP, while making it easier to work with. The "open definition" action for example should be able to resolve a lot more symbols than before, including in type annotations. Quick fixes and auto-completion we've also worked on.

I wish to thank all users of EclipseFP, most notably all the people that submit bug reports or questions to the forum and thus help make the product move forward!

The instructions to install are the same as always: point your Eclipse to the update site http://eclipsefp.sourceforge.net/updates/. Once you restart EclipseFP should install or update buildwrapper and scion-browser.

Happy Haskell Hacking!

EclipseFP and "the future of programming"

Paul Chiusano's essay "The Future Of Programming" has sparkled a lot of debate, for example on Reddit. His points on IDEs remind me somewhat on what Luke Palmer has to say on them. And he's strongly in favor of lazy, statically-typed, functional languages.

I suddenly find myself in a strange (good?) position: as a maintainer of an IDE (ok, plugins) for Haskell, I can somehow participate towards fulfilling that dream. I know, I know, we're far from it, and EclipseFP has not yet reached the ease of use and power of the JDT in Eclipse. But maybe we can achieve success by doing things differently, not by trying to mimic what's already there and anyway applies to a different language.

We've already started to take some steps in the right direction: for example, Alejandro is working on a version of scion-browser that stores its data in a database. It's not such a big leap to envision that a lot of information about the developer's projects and modules could be kept in that database, to give accurate and fast searching and refactoring operations. We'll also need to think about providing an editor that is a lot more structured than the standard text-with-foldable-sections editor we have now, but it's not clear now if

• the benefits of a structured editor justify developing an interface programmers are not used to
• people would take the plunge even if we could prove tangible benefits

I can already see a clear advantage in having an editor that always force you to have valid code: EclipseFP loses a lot of functionality (thingAtPoint for example doesn't work) if the module you're working on has errors, because the GHC API can provide a lot more info once the module can be analysed correctly. With things like "undefined" and type-directed autocomplete support we could have modules that are always correct. I'm not sure myself that having a compiling module with loads of undefined that fails miserably at run-time is such a great proposition, but hey... In Java, Eclipse let you run a file with errors and only throws a run-time error when you access the incorrect code.

So we'll have to overcome usability and performance issues, deal with GHC limitations and programmers' expectations, but we're in the position to at least try, and see if we can move forward a little bit!

Lego Mindstorms and Haskell?

Santa brought me a Lego Mindstorms kit! Suddenly the time I'm going to have available for EclipseFP is greatly reduced (I joke). I'm having fun building my first little models and fiddling with the graphical interface for programming the little beasts, but I was wondering if I could use Haskell to control the robots. Things look bleak:
- the NXT library on Hackage looks good, but requires unix... Maybe getting it to work on Windows would be easy, but I wonder...
- the fantom development kit (fantom is the low level communication API for Mindstorms, if I understand correctly) comes with a Windows version that will only work with Visual C++. It uses C++ lib and dll files whose name mangling is not compatible with MinGW.

So as a Windows and MinGW user, I'm in a bit of a ditch. I'm wondering now about the Urbi platform, that seems to be open source and to have a module for Mindstorms. It seems to provide a C++, Java and scripting interfaces, so it may be possible to get a Haskell wrapper on top of it. I wonder has anybody worked on Haskell bindings for Urbi? Might be interesting...

Buildwrapper 0.2.2 released

Hello all, I've just released a new version of buildwrapper, which is one of the backend Haskell executables used in EclipseFP. This is a bug fixing release, addressing some of the issues reported by people. Just install the new version via cabal install or via the EclipseFP cabal packages views.
There is ongoing work on EclipseFP and scion-browser, so a new version of both should hit the shelves pretty soon, in a matter of weeks!

Happy Haskell Hacking!

EclipseFP helper executables for Windows

Since people had sometimes problems building Haskell executables we use in EclipseFP, I thought I'd help by putting versions of the current Windows executables on sourceforge. So in you run Windows and have trouble building scion-browser or buildwrapper, you can grab them from here.

I know this isn't really in the spirit of "build from sources so you can check them yaddi yadda", but since even Cabal does it...

As usual, use at your own risk, etc.

Happy Haskell Hacking!

EclipseFP 2.2.0 released!

I'm glad to announce that EclipseFP 2.2.0 has been released. EclipseFP is a set of Eclipse plugins for Haskell development.

The minor version increase is justified by the replacement of the Scion library for the backend by the BuildWrapper executable. I appreciate that lots of work went and is still going into Scion, but I decided that building my own Haskell backend was better for EclipseFP. It calls cabal directly for building, which allows EclipseFP to support things like new style component dependencies (the executable in a project depends on its own library), c files (now my HJVM project, which call Java from Haskell can build, and even report errors in the C code), etc. Note the the haskell code is not bundled with EclipseFP anymore but gets downloaded and installed from Hackage.

This version also comes with a new view, allowing the installation of cabal packages from Hackage. There are also bug fixes and small enhancements all round.

To install, just use the built-in Eclipse install/update functionality. The update site URL is http://eclipsefp.sourceforge.net/updates. The release notes can be found here.

Happy Haskell Hacking with EclipseFP!

GUI Testing using OCR: project Sikuli

I had a great idea this morning... and then realized that there was an open source project already doing it.
I thought: instead of using specific testing frameworks for each UI technology I have (a tool for the web, a tool for SWT UIs, etc) what about a tool that could recognize the text on screen and click or type in the proper places. The same technology for everything type of UI, and something that doesn't rely on pixel perfect positioning to work! Turns out (surprise!) I'm not the first one that had the idea, and looking around I stumbled on Project Sikuli. This looks great: it uses images to find "interesting" parts of your UI and there's also support for text recognition. So potentially you could say "click on the button that says 'Submit'"! It integrates with Java code so you can easily have JUnit tests using it.
Unfortunately, for my own purposes I couldn't get very far easily because of lack of support for transparent images (or, more precisely, it takes into account transparent areas for images, so it doesn't recognize an image if the background changes, which happens if your desktop theme changes, if you use the same icon in different contexts in your UI, etc). But it still looks like a promising tool!

Manage Cabal packages from inside EclipseFP

I'm thinking the new version of EclipseFP will not bundle the Haskell code we use, but will download it from Hackage, which would make sense: we would be able to update the Haskell side without requiring a EclipseFP upgrade, and vice versa. I would expect Haskell developers would be quite used to install packages from Hackage using cabal install. However, let's try to minimize the number of things that a user would need to go outside of EclipseFP to do on a normal Haskell project. So I've added another view:

This view lets you see the list of packages you've installed, with their version, or the full list from Hackage, that you can filter by typing the prefix of the name you're looking for. From there you can install the packages as either Global or User, see the package information, or click on the "More Information" link to open the Hackage page directly.
You can also update the list. This GUI is only a wrapper above the cabal list and cabal info commands.
Hopefully this will be useful to people! Should I add a text field somewhere to be able to specify more options to cabal install, or is that overkill for a GUI?

New backend for EclipseFP

A while ago I was wondering how I could enhance EclipseFP, regarding things like memory usage, support for multi components projects, etc. I now have a working version for adventurous testers!

The main thing is the removal of Scion. EclipseFP now uses another backend component called "buildwrapper". There is no server, buildwrapper is only an executable that can be launched with flags, and writes a JSON result on the standard output. This means no more huge memory usage, and less synchronization headaches.

Buildwrapper uses a copy of the project inside a hidden folder. This means that when we want to get say build errors on a dirty editor content, we can write the dirty content to the file inside the hidden folder, and launch a build process on these files, thus avoiding the limitations that the GHC API has on building from a StringBuffer (doesn't work for files requiring preprocessing, etc).

We only use the GHC API to get the types of things in a source file, but we use Cabal to build the project. Buildwrapper actually launches the cabal executable and parses the results. I know, sounds crude compare to an API only approach, but I have the feeling it just works better. Basically the IDE will now behave a lot close to what you get if you were building your project from the command line. And then you get additional goodies, like multi component support (so you can have the executable of your project reference the library in the same project, and it works!).

Buildwrapper uses haskell-src-exts for outline. I've actually seen cases where it needed language pragmas to parse correctly that GHC didn't need, but such is life.

Performance seems to be quite good, except for things that use the GHC API, where there's a little lag. Hopefully the fact that we don't use gigs of memory any more will make up for it.
I'm also thinking about distribution. EclipseFP came with Scion and Scion-browser bundled, if only because we used a different version of scion than the one on Hackage. I think that moving forward we'll rely on cabal install and Haskage. I'm going to add a simple interface to run cabal install inside EclipseFP, so you shouldn't have to go outside to install a package. So the EclipseFP preferences will just ask the user for the path to the buildwrapper and scion-browser executables, with an option to install them from hackage.

If people want to start testing, just go on github, and grab the BuildWrapper repository (main branch) and the EclipseFP project (buildwrapper branch). For the moment, BuildWrapper probably only builds on GHC 7.0. Once I have the feeling it's robust enough and there's no big flaw in the new architecture, I can work on enhancing portability.

EclipseFP 2.1.0 released!

It's been a little while, but finally a new version of EclipseFP has been released! This version is mainly the work of Alejandro Serrano, who has worked on EclipseFP (and the underlying utilities) during his GSoC project. There are lots of new features in that version, mainly :

• A package/module browser
• Hoogle integration
• Support for running tests
• HLint warnings
• Support for running executables and get profiling graphs
• SourceGraph generation
• Better auto completion information

Lots, I'm telling you. There are also fixes and internal enhancements that hopefully should make your life easier.
You can just run the update from your Eclipse IDE. You can find the full release notes there.
Note that Alejandro has also created a new web site for EclipseFP, that you can find there. Alejandro, big thanks for your hard work and your dedication!


Any feedback is welcome, and of course bug reports and requests for enhancements!


Happy Haskell hacking in Eclipse!

Hoogle Command Line on Windows

The new upcoming version of EclipseFP will feature Hoogle integration, thanks to the work of Alejandro Serrano, so I was doing some testing on one of my Windows machine (yes, I'm a Haskell hacker and a Windows user, so what?)... No real problem using Hoogle via the command line, but since it does require some other things to be installed, I though I'd post them there for reference.

Unlike Cabal, Hoogle uses external tools for some of its operations. These tools are I'd say part of any self-respecting Unix distribution, but not of Windows. So you'll need:

wget: http://gnuwin32.sourceforge.net/packages/wget.htm
At time of writing, the download page is http://sourceforge.net/projects/gnuwin32/files/wget/1.11.4-1/wget-1.11.4-1-setup.exe/download

gzip: http://gnuwin32.sourceforge.net/packages/gzip.htm
At time of writing, the download page is http://sourceforge.net/projects/gnuwin32/files/gzip/1.3.12-1/gzip-1.3.12-1-setup.exe/download

tar: http://gnuwin32.sourceforge.net/packages/gtar.htm
At time of writing, the download page is http://sourceforge.net/projects/gnuwin32/files/tar/1.13-1/tar-1.13-1-bin.exe/download

Install everything in the same directory and put the bin subdirectory in your PATH. hoogle data should run fine.

Note also that since it's using wget, if you have an HTTP proxy you need to configure wget to use it (Cabal uses the internet explorer connection settings and finds the proxy settings from that). The files is etc\wgetrc in the directory you installed wget, find the http_proxy entry and adapt to your settings.

EclipseFP: the way forward??

This is not the usual "hey I managed to get some code to work, check it out" blog post. Bear with me as I'm just thinking out loud. This is about EclipseFP and how we can move it forwards.

At the moment EclipseFP works pretty well for simple, smallish Haskell projects. People have noted some performance issues on large projects, and part of it is the huge memory footprint of GHC when used through its API. After a couple of hours of working on a yesod project (so we're talking quasi quotation, template haskell, etc), the scion server takes 1Gb of memory... Restarting brings it back to reasonable levels, which seems to point to memory leaks in the GHC API.
Maybe more critically, people are now asking for features that get increasingly harder to implement using Scion:
- static GHC flags like -threaded (Nominolo's working on a version of Scion that could handle these)
- C or HSC sources (or other kind of stuff requiring a preprocessor)
- Having executables or test suites referencing the library component directly in the Cabal file

The main thing with these is that Cabal handles them fine, so basically typing cabal build at the command prompt solves these issues, which undermines the usefulness of having an IDE in the first place... But they require more than just calling the GHC API: building and linking a library in-place, calling a c compiler, hsc2hs, etc...
Of course Cabal publishes an API. So for example the code used by Cabal to build an in-place version of the library I could access, in theory, from Scion. But then Cabal calls the ghc executable, so the Cabal API gives me no easy way to get back errors from GHC, etc...

What does accessing the GHC API gives us? An AST, that can be generated from an unsaved file (so you don't need to save your haskell source file to see your errors, our up to date outline, etc). All the rest (syntax highlighting, jump to definition, etc) could probably be done from the AST.

So I'm wondering now if scrapping scion totally would not be a good idea. A rough outline of how things could work would be:
- create a temp folder in which we will work, copy in it all the project files (sources, etc)
- use cabal to build in that folder
- parse cabal output to get errors and their location
- unsaved files in the EclipseFP editor could have their unsaved contents copied into that folder (that folder represent the current state of the project, which may not be what is really saved on disk)
- have only a simple Haskell executable that given a module file, loads it using all the built files in the temp folder, and return the AST in some easy to parse format. Firing and getting the result would ensure GHC cannot grab loads of memory and not release it
- the IDE code then gets the AST and does all it needs to it
- the AST could even be saved in that temp folder in some format, so that the Java code would only request it when the original file is more recent, which would allow easy parsing of dependent modules AST (for example to retrieve all the symbols exported, etc)

There are a lot of ugly bits in there, maybe, but that would solve my problems... I suppose all of that could be written in Haskell and we could keep a similar enough API to scion, so that the Java code wouldn't need change too much...

For the moment I'm not going to reach into things anyway, but if anybody has some feedback, I'll gladly take any opinion on board!

Haskell + FFI + Java + SWT: crazy, maybe, but working!

A few years ago I noted that being able to mix Haskell code and a Java GUI might be a good idea, since Java UIs have matured enormously, and Haskell UI library are still struggling to gain wide adoption, a recent thread on cafe being proof. SWT bindings were mentioned, so I had a look at both the Java and the C SWT code, for windows. Two immediate things sprang to view:
1. The SWT C library is using JNI, duh. It relies on JNI for some operations so you can't just use the SWT.dll in your haskell code that easily
2. The SWT C bindings are very low level, and there is a wealth of Java code on top of that to provide a lot ow glue and boilerplate code for all kind of widgets, and it would be long and painful to rewrite it all in Haskell.

My Java to Haskell code converter only being a dream at the moment (one day...), the next reasonable (ahem) option was then obvious: start a few blown JVM from Haskell and use it to drive SWT classes.
I'm a Java expert, I can say, and my Haskell is slowly coming on, but the glue in between has to be C, so it wasn't a smooth ride, but I finally got it working! So what's happening is this:
- The Haskell applications starts as they all do, in a main :: IO() function
- Haskell invokes some C code that starts a new JVM, passing it a classpath. The C code acts then as a facade hiding some of the intricacies of accessing the JVM
- Haskell uses the foreign C functions to create ands manipulate the SWT Java objects
- I even got callbacks working, meaning you can register a Haskell listener on a SWT button, and hence have Haskell code calculate the results of that button click.

And I have proof! Here's a simple SWT Shell with one button:

When you click the button:

And the handler for the button click is written in Haskell (I have a MVar called count for the number of times the user clicked):

do
    modifyMVar count (\c->do
        let nc=c+1
        let s=if nc==1 then "once." else ((show nc)++ " times.")
        text3<-toJString ("Clicked "++s)
        voidMethod button "setText" "(Ljava/lang/String;)V" [JObj text3]
        return(nc,())
        )

You can see here the invocation of the setText method of the SWT Button, which for the moment requires knowing the exact JNI signature, and the translation from Haskell strings to Java strings.

Of course, there is still loads to do. I probably need to automatically generate bindings to the Java objects to simplify greatly their manipulation, wrap stateful operations in a monad, etc. But this may open a new way for Haskell GUI. Or it may just be a crazy idea that has already taught me a lot about FFI and JNI...

Pirates 0.2: fixes and a chat interface

I released a little update to my Pirates Yesod/Canvas game. Nothing too dramatic, but the new version, still at http://pirates.dyndns-free.com boasts:

• Fixes in the collision detection code
• A chat interface, so you can talk to the other ship you're fighting with. Stock up on pirates insults!
• Fixes in handling of games when a ship leaves the game before it's finished

As I said, nothing too fancy, but I find that polishing off bugs and adding unplanned features is often a good exercise, especially for personal projects where the temptation is great to just move to something else when it kinda works. The chat interface was interesting: the server side code was done in a few minutes, using the same event system as the rest, but I struggled longer with the HTML to get the right positions for everything, as usual... Now it's on the right hand side, outside of the canvas area, which makes the full game area much bigger than the original 800x600, but I don't think I get a lot of mobile users anyways (-;.

I could probably make the game more appealing long term by having a bigger area where more than 2 ships could battle, and have more of a RPG feel to it (maybe be able to log in and out so you keep your ship, be able to repair it in harbours, etc...). I'll see what I have time to do. Any suggestions welcome!

Pirates!! A multi-player browser game with Yesod and Canvas

I can finally open to the public a little game I've made! You can now go to http://pirates.dyndns-free.com and play!
The game is simple: you're sailing a pirate ship, and you have to sink your opponent. You can use cannons, ram the other ship, board it with your blood-thirsty crew. Your speed depends of course on the direction and strength of the wind. You can play alone versus a very dumb AI (mainly to get the hang of the controls), against a friend in a private game, or against any dog on the internet. 
The technology stack is as follows:

• Hosting is on a free Amazon EC2 instance. Performance is probably not going to be great, but should be sufficient I hope for the traffic I'll be getting!
• Server side is Yesod 0.7. Coming from the Java/JSP/Struts world it was such a pleasure to work in Haskell, with type safe templates. I have no web server, just warp, since there are very few static files (a few sprites and the tile image).
• Client side uses Canvas with a sprinkling of JQuery.

As you can see, no database. Information about current games is purely in memory, and I don't keep any long term information about players. I suppose that allowing players to log in with their Google or Facebook id, and keep statistics on their battles would be good, but I'm not sure this little game will get enough traction to warrant it, really... 
The AI also is not great shake, there are only two bots: The Sitting Duck turns to face the wind and stays there. The Drunken Sailor just goes randomly through all possible actions. But hey, it's a multi-player game!
I'm not too sure if I chose the best route for concurrency. I use MVars and modifyMVar.
In fact the more difficult bit was to design the control. I didn't want to a do a full 3D environment, and opted for a top view, but the velocity of the ships was essential, and so providing just direction keys as in more static games wouldn't have worked. Hopefully the way the control works, being disposed on a copy of the boat icon at the top of screen, that turns when you boat turns, will work well. The icons are probably a bit small, it's fine for a mouse but I don't think it could work on a touch screen, unless you have tiny fingers.


A little bit of personal info: inspiration from this game comes from the French magazine "Jeux et Stratégies", that my dad used to get when I was young, and that got me into games. We have still kept all the issues, and issue 22 from August 1983 describes a simple ship battle game, rules written by Michel Brassinne (French warning!). Thanks!


Still it was fun to do!! Hope you enjoy playing it a little!

Install GHC7 and Yesod on Amazon Linux

I've been working lately on a multi-player web game, to actually get to know HTML Canvas (on the client) and Yesod (on the server) properly. I have a first fully functional version of the game, so now is the time to think about hosting. Michael initiated a discussion about it, and in the meantime I decided to investigate Amazon since they offer free instances now on EC2.
The free AMIs (images) come with a version of Linux specific to Amazon, but apparently binary compatible with CentOS, on which GHC and the Haskell Platform have been reported to successfully build.
These are the steps I followed to get everything working, hopefully they can be useful to somebody else. So as per the Amazon Getting Started guide, you connect to your instance with the ec2-user.
First we install through the package manager some useful packages:

sudo yum install make
sudo yum install gcc
sudo yum install zlib-devel
sudo yum install glut
sudo yum install glut-devel

I didn't find gmp, so I downloaded and installed in the default location:

curl -O ftp://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2
tar -xjvf gmp-4.3.2.tar.bz2
cd gmp-4.3.2
./configure
make
sudo make install

But afterwards I had issues building some Haskell packages because it didn't like the default install folder of /usr/local/lib, it preferred /usr/lib, so I did:
sudo cp /usr/local/lib/libgmp.* /usr/lib/
But I suppose ./configure --prefix=/usr/lib/ would be the preferred way to do that.

Libbsd is also required otherwise unix-compat fails:

curl -O http://libbsd.freedesktop.org/releases/libbsd-0.2.0.tar.gz
tar -xzvf libbsd-0.2.0.tar.gz
cd libbsd-0.2.0
sudo make install

Then for GHC, I just downloaded the generic binary and installed that. I decided to install Haskell under my home folder.

curl -O http://haskell.org/ghc/dist/7.0.2/ghc-7.0.2-i386-unknown-linux.tar.bz2
tar -xjvf ghc-7.0.2-i386-unknown-linux.tar.bz2
cd ghc-7.0.2
./configure --prefix=/home/ec2-user/haskell
make install

Make sure we know how to find it:
export PATH=$PATH:/home/ec2-user/haskell/bin

Then get the Haskell Platform source and build that, since there is no binary (yet) for our platform:

curl -O http://lambda.galois.com/hp-tmp/2011.2.0.0/haskell-platform-2011.2.0.0.tar.gz
tar -xzvf haskell-platform-2011.2.0.0.tar.gz
cd haskell-platform-2011.2.0.0
./configure --prefix=/home/ec2-user/haskell
make
make install

Once you're there, it's back to familiar ground:

cabal update
cabal install yesod

And there we are!! My deployment platform is ready!

EclipseFP 2.0.4 released: supports GHC 7!

Hello, the demand was HUGE (well, everything is relative :-)) for a version of EclipseFP that could build and run on GHC7. Since the 2.0.3 release there is now a Haskell Platform release that contains GHC7, so we had no excuse... And there it is! Thanks have to go mainly to Alejandro Serrano, for getting Scion to compile with GHC7 and to Thomas Schilling and Matti Niemenmaa, who upgraded their libraries for GHC7.


So what we have is a scion backend that should build both with 6.12 and 7.0, and hopefully work the same on both. We now support test-suite sections in Cabal files, with limited support for running test suites (running just cabal test with no options).


On my To Do list are full support for test-suites (having full launch configurations for Cabal defined tests) and HLint integration. But I'd also like to work on my own project, so don't expect that a release every two weeks is going to be our normal cruising speed.


As usual, just install from the Eclipse update site: http://eclipsefp.sf.net/updates, and bug reports or feature requests should go to the SourceForge forum or the development mailing list.


Happy Haskell Hacking!

EclipseFP 2.0.3 released

It's my pleasure to release EclipseFP version 2.0.3. EclipseFP is a set of Eclipse plugins for Haskell development. Scooter and I have tried to add a few features and hopefully to fix the bugs that were reported by users.

Main things in this version are code completion templates, which enables you to code even quicker!! We also enhanced the Cabal support (you can now set Cabal flags from the project properties, run Cabal install on the project) and simplified the installation (more settings are auto detected).

EclipseFP is alive and well (I use it for all my Haskell work) so please send us all your feedback, bug reports, feature requests!

Use the standard Eclipse Updates Site  or download files. Enjoy!