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!