Monday, May 28, 2012

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


Monday, April 30, 2012

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!

Friday, March 30, 2012

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!

Friday, March 16, 2012

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...

Monday, March 12, 2012

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!

Friday, March 09, 2012

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 :-))!

Thursday, March 01, 2012

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!

Wednesday, February 15, 2012

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!

Wednesday, February 01, 2012

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!!

Monday, January 16, 2012

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!

Friday, January 13, 2012

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!

Friday, December 30, 2011

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!

Wednesday, December 28, 2011

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...

Monday, December 26, 2011

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!

Saturday, November 12, 2011

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!

Friday, November 11, 2011

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!

Thursday, October 20, 2011

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!

Thursday, October 13, 2011

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?

Friday, October 07, 2011

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.

Friday, September 02, 2011

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!

Wednesday, August 31, 2011

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.

Friday, June 24, 2011

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!

Sunday, May 22, 2011

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...

Monday, April 18, 2011

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!

Friday, April 08, 2011

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!

Friday, April 01, 2011

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!

Monday, March 21, 2011

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!

Monday, March 07, 2011

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!

Friday, January 21, 2011

Evolving a computer with TECS and Genprog

I've started reading The Elements of Computer Systems since it was recommended on Reddit and it's a great read. After the section on boolean gates I decided to have a quick go at build the gates in Haskell. Just implement Nand with pattern matching, and implement all the other gates just in term of functions calls to previously defined gates. The book mentioned "think positive" about implementing Not, so I just T as the second parameter, did't think more about it, even though I wasn't sure having a constant value was OK.



Then I moved on to the other gates. It was interesting to think about boolean logic without Or, for example, after years of only reasoning in terms of And Or and Not. But at some stage I thought "why am I doing this by hand?". I remembered a thread about a new genetic programming library on an Haskell group. Surely generating the gates would be simple enough?
So I got genprog from hackage, and adapted the example for my needs. I started with a very simple system to determine the implementation of Not:



And of course, the result came quickly enough: not a=nand(a,a). No need for a Const at all! Evolution has beaten me! (OK, I'm only a not-so-intelligent designer, I suppose...)
Now, I'm going to see if this approach can take me all the way to the arithmetic unit...

Wednesday, December 01, 2010

EclipseFP 2.0.2 released

I am pleased to announce another release of EclipseFP. Version 2.0.2 should make installation of Scion easier, improve stability and performance of the parsing and building operations, and provide a few new functionalities. You can now configure where the "Open Definition" action will look for definitions (these can be in Haskell source code or Haddock pages): by default it will look in the dependent projects, in your GHC install doc folder, and on Hackage, but you can add more locations in the preferences. You can also generate source distribution via a project export command (that calls cabal sdist).


The release notes are here. To install or upgrade, just point your Eclipse to http://eclipsefp.sf.net/updates. Be sure to configure both the GHC path and the Cabal path in the preferences.


Happy Haskell hacking!

Thursday, November 25, 2010

A simple game in Haskell + SDL

I wanted to play a bit with SDL, and it's always good to step away from actually working on EclipseFP to use it for a "real" project. So I wrote a very primitive game using SDL and SDL_TTF. It's a typing speed game (hence the, ahem, clever pun on the name: TypeClass): you see letters scrolling down the screen and you need to type them, and of course they go faster and faster. Maybe my children will learn to type with it. Maybe not.


I had SDL installed earlier, but of course SDL_TTF proved challenging on my windows machine, but I think it's was all my fault, I probably didn't read the instructions properly or something. Anyway, I only forgotten to set the LIBS variable. When I ran export LIBS=/usr/local/lib/libSDL_ttf.dll.a in my MSYS environment then configure worked fine!


Afterwards it was all plain sailing, really. Just remember to add enableUnicode True in your initialization code so you can get the actual Unicode character typed (I'm on a French keyboard, so typing M gives me the SDL key ;). And of course you need a font file, so I include a GNU FreeFont file with the package. It needs to be in the same folder as the executable.


For some reason, after seeing code that was blocking for SDL events in a loop, I started building the game with two threads, one blocking for events and one looping and drawing, and a MVar in the middle. It worked, but rewriting it in a single normal game loop: process event, update game state, draw made things a lot easier.


This brilliant piece of software that has already made its mark in video game history can be found on Hackage here!


As usual, all feedback is welcome. Possible enhancements are a high score screen, difficulty levels, choosing letters by frequency in English, using Markov chains so that the flow of letters look more natural... The list is infinite!

Thursday, September 30, 2010

EclipseFP 2.0.0 released!

Hello all,

I'm proud to announce version 2.0.0 of EclipseFP, the Eclipse plugin for Haskell coding. The change in the major version number shows that some big changes have been made, even if under the hood:
- the Antlr parsing has been removed
- the JFace based syntax highlighter has been removed
We now rely solely on Scion and the GHC API to provide lexer tokens! This fixes some long standing syntax highlighting bugs while giving us more options for coloring.
Also, we now communicate to the Scion library via standard streams instead of network calls, which should solve some headaches.

There are also loads of bug fixes and small enhancements peppered a bit everywhere, either things that people asked or things that I did for myself, since EclipseFP is (of course) my IDE of choice for my Haskell coding. The release notes can be found here.

Another good news is that I'm not alone in hacking at EclipseFP, scooter has helped a lot with Helios, Cabal 1.6, GHC 6.10 and Mac OS X support, and has a few new features coming up soon!

Just point your Eclipse to the EclipseFP update site, and happy Haskell hacking!!

Friday, September 24, 2010

Haskell Neural Network: plugging a space leak


First, the good news: last week when I posted about my little digit recognition program I had made a mistake in my test code: when I give a rounded eight to my network, it does recognize it, even though it's been trained only with a square eight! Yoohoo!


Also, a few people pointed to online database of handwritten digits so that I could get more data to train my network. I dully downloaded and started working with some files. Soon I knew I had a problem. Not only was the learning slow, but the memory usage of the program showed exponential growth, like using 400MB after a few iterations. Ha ha, I thought, so it's me against lazy evaluation again!


Well, I was right. A couple of strictness annotation in the neuron output calculation function helped performance, nearly making the code twice as fast, but didn't help the memory consumption. Going mad with ! (BangPatterns is your friend) didn't help any more. WTF?


Then I started to read a bit more about seq and Weak Head Normal Form. So when I put a BangPattern in front of a tuple, it evaluates the tuple but not what's inside it. And, lo and behold, if at each learning iteration I traced the network to the standard output, memory usage stayed constant! So I needed to tell Haskell to fully evaluate the network each time, so as not to keep thunks full of arithmetic operations hanging round. A distant memory of a package called deepseq provided me the final help I needed. I didn't use the package itself because I wanted to understand really what's going on, so I just roll out a few lines of my own:



And by calling deepSeq on my network in each iteration, my program runs in constant space! And I looked at the flat line of memory usage in my task manager, and I was pleased. Now, I can try to improve the speed of the dang thing, but that's another set of problems...

Friday, September 17, 2010

Digit recognition with a neural network. First attempt!

I bought myself "On Intelligence", and I thought as the first step on the long road to building an intelligent machine I would go back to neural networks. I have my own little library that seems to work (kind of), so I decided I was going to try to write a little number recognition program. I was inspired of course by ai-junkie, but it was a bit short on details...
So here is the problem: I have a 5x5 grid of LEDs that can be on or off, and I want to recognize the digit that they show. 
The input will be a list of 25 numbers, either 0 (off) or 1 (on)
The output will be a list of 10 numbers, either 0 or 1. The first position of a 1 indicates the result (so if the first element is a 1, it's number 0, etc).
I arbitrarily decide to set the number of hidden neurons to 50, twice the input neurons. So my topology is 25-50-10. 
I train the network with only one version of each digit. For example 3 would be:
*****
    *
 ****
    *
*****
Wrote a few lines of Haskell code to read the training sets (moving from the representation with *, spaces and new lines to the list of 1 and 0, so that 3 becomes: [1.0,1.0,1.0,1.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,1.0,1.0,1.0,1.0,0.0,0.0,0.0,0.0,1.0,1.0,1.0,1.0,1.0,1.0]).
Then I train the network. It learns after 200 iterations, and successfully recognizes the training sets (ok, so things are working as they should be).
Then the real test: can my network recognize small variants of the training set?
Lets's try with:
****
    *
 ***
    *
****
(a slightly rounded 3): the network answers 3!!
Works also for a slightly rounded 6. But then:
 ***
*   *
 ***
*   *
 ***
(rounded 8) gives me 6. Oh dear... I could probably add more cases in the training sets and hopefully resolve the ambiguities, but there are bigger issues (I know I know, I'm very candid, but it's one thing being told something in a book, and another to build something to actually show it to you). For example:
***
* *
***
Is a small zero that doesn't take the full 5 LED width. My network recognizes 0 when it fills the full square, not when it's smaller (tells me it's a 5).
And of course, 1 is a disaster. The training "1" is a vertical row of LEDs on the left. A vertical row of LEDs on the right gives me 9, usually (and I suppose, 9 has all the LEDs on the right on).
So not only is basic training not sufficient to detect simple variations, but also the fact that we deal with absolute positioning of leds mean than scaling and simple side translations are not supported. So I suppose the next step is to not work with absolute positions, but relative positions of "on" LEDs. Another day's work...

Monday, September 06, 2010

EclipseFP development: using the GHC Lexer

The new version of EclipseFP is slowly coming along. Slowly, because of some holidays, because of a lot of bug fixes, and mainly because of some big changes.
There were a few bugs revolving around syntax highlighting. The original code was using some lexing rules from the JFace packages in Eclipse, but it didn't cover some common enough cases of Haskell syntax, and of course was fairly hopeless at more complex stuff (things like Template Haskell). So I could either trod on and fix the lexing rules for everything, or I could use a different approach. So I decided to use Scion again, and to add support for lexing. Now Scion exposes a method that calls the GHC Lexer on an arbitrary Haskell source. We use the result to color highlight properly the Haskell source code. Of course I have to handle things like CPP preprocessing directives and literal source files myself, but that was ok. The two main issues I had to tackle were performance, and advanced lexing options.
Performance was poor at start, and there are two reasons: the underlying Scion code deals with JSON Strings while the socket code uses ByteStrings, and, I think, the Eclipse console. For the first issue, I'm using now AttoJson, so that Json marshalling is done with ByteStrings and try to use ByteString as much as possible in the code. The Eclipse console is a different matter. I think when too much data is written to it it struggles to update the console control, blocks the UI thread and the whole UI becomes unresponsive. For the moment, I have disabled server output in the console for commands (since now getting the tokens from the source code is quite a big response). Since lexing is also done in the UI thread, we've probably lost a bit in that area, but I feel the advantages (less Haskell knowledge in the Java code, more reliance on the GHC code, which I suspect knows about Haskell pretty well) outweigh the costs.
One funny thing with the Lexer I found: for example when you have TemplateHaskell code in your source file, and you have the TemplateHaskell pragma, the Lexer doesn't automatically set the TemplateHaskell flag. So I decided that I was going to enable all the lexer flags, since performance didn't seem to suffer. Be liberal in what you parse...


Anyway, I'm not going to release the next version right now, a bit of testing is still needed, and there are a few little things that I want to fix. The testing is easy, in a way: I use the development version of EclipseFP to hack the Scion code, so by eating my own dog food I hope that I can release something of value to Haskell programmers.
So don't worry, EclipseFP is coming soon!

Wednesday, June 02, 2010

EclipseFP 1.111 released

I have just released version 1.111 of EclipseFP. You can get it from sourceforge or via the Eclipse update site (http://eclipsefp.sourceforge.net/updates/).
This is mostly a bug-fixing release to ensure compatibility with GHC 6.12.1 (Haskell Platform 2010) and IPv6. It also bundles a version of the Scion source code that it builds under the covers to save people from downloading the source code from github and building it themselves.


There aren't too many feature enhancements because I didn't get any requests for it. I'm not too sure a lot of people are using EclipseFP and are interested in seeing it improved. I suppose now with a Cabalized gtk2hs Leksah becomes more attractive. Anyway, if you have requests for EclipseFP let me know!

Friday, May 28, 2010

Gtk2hs and Leksah on Windows, check!

Things have moved since I posted about the difficulty of being a Haskell programmer on Windows. Now, Gtk2hs has been cabalized and put on Hackage. I went into my MSYS prompt, and it installed like a charm! I've downloaded the latest version of Leksah, and it installed and started properly! As I write this I've seen the initial Leksah screen, and it's now busy referencing my packages (I wonder if giving it the location where Cabal stores the packages it downloads was a good idea, it seem to be taking a while...). 
So I think now all the things I was struggling to get working are now installed and doing fine on my Windows 7 machine! There is hope!

Wednesday, May 05, 2010

Haskell SDL on Windows, check! (hacking required)

Things looked grim. Even though Timothy could get it to work, the SDL Haskell library wouldn't build for me. libSDL itself installed ok and the samples compiled and ran. But I couldn't compile the hsc files because of a linker error: gcc couldn't find SDLMain or whatever. In desperation, I posted to Haskell-cafe. I didn't get a single answer or hint. I was truly alone.
OK, it was time to either give up or take drastic action. And I never give up.

By then I had narrowed the problem. The order of arguments to gcc were wrong for linking, according to the gcc manual: the .o file should be referenced before the SDL libraries on the command line. It would work like that for other people, but for me, on my system, in my corner of the universe, the order was wrong, and that was it. If I tried the same order of arguments on the SDL samples, they would fail to link. If I reverted the arguments, they would succeed.
So I was left with the straight and narrow: I managed to get the source code for hsc2hs from darcs. I fiddled for a while with the include-dirs and extra-lib options so I could get it to compile and produce the same error than I had with the Haskell Platform version, and not some stupid errors about hsFFI.h not found or so.

Then I opened up, hands trembling and sweat pouring from my forehead, Main.hs in an editor. Found the offending lines:
    rawSystemL ("linking " ++ oProgName) beVerbose linker
( [f | LinkFlag f <- flags]
++ [oProgName]
++ ["-o", progName]
)

Changed them to:

      rawSystemL ("linking " ++ oProgName) beVerbose linker
( [oProgName]
++ [f | LinkFlag f <- flags]
++ ["-o", progName]
)
So that the name of the o file would be before the libraries.
Recompiled, copied the exe in the Haskell Platform bin folder...
Relaunched the SDL build...
And watched SDL build and install properly!
Gaped at the first sample of Timothy opening up a blank window that would close when I press a key! (OK, the last print fails, but by now little errors are not going to disturb my feeling of invulnerability).
Danced around my desk!
Had a beer!

Friday, April 30, 2010

Happstack on Window, check! (in a long, round-about, fear-inducing way)

The other day I noted that I couldn't install the darcs version of Happstack on my windows machine. There was a build failure that was reported on the mailing list. So I waited a few days, and tried again. But then, before I started building Happstack, something happened. I don't exactly remember what, I think I was a bit to eager with cabal upgrade, and I upgraded some base packages that I shouldn't have. I remember directory-1.0.1.1 failing to build and having to go through MSYS to get it to build. Then more and more things needed to be upgraded and ghc-pkg check was reporting more and more weird things. When I thought I had upgraded everything, I tried happstack. happstack-util built, but then happstack-data reported that happstack-util couldn't be built because it required both time-1.1.4 and time-2-something. Oh oh. I screwed around for a while. Then I saw some posts on the web talking about removing package.conf.d. In my random experiments with cabal upgrade I had managed to install everything in my user profile and not inside my Haskell Platform directory, so there was hope!
I deleted package.conf.d. ghc-pkg list reported a saner list of packages. I tried building happstack again. Then something "funny" happened: every cabal build I was trying to do first tried to reinstall process-1.0.1.2, and failed every time!! And of course process-1.0.1.2 appeared in the ouput of ghc-pkg list... WTF? Ah, ok, directory-1.0.1.1 is still installed, let's kill the beast! And then everything worked! Happstack built, happstack "hello world" server even runs, life is happy again!
I didn't try to investigate why Cabal or directory-1.0.1.1 were insisting on reinstalling something that I have already. I've seen enough weird things and spent enough time this week away from the nice world of pure lazy functional programming and in dirty low-level configuration and build issues to not care too much anymore...

Wednesday, April 28, 2010

WXWidgets and WxHaskell on Windows, check!

Despite my earlier problems, I finally managed to install WXWidgets and WxHaskell on my Windows machine. Pfiu! I started again from scratch, and things went much better when I installed, as recommended, MinGW and MSYS in different folders. When I need to compile stuff, I only put MinGW in my path, and when I need Unixy tools like make I add MSYS. Of course MinGW has its own version of make, mingw32-make, that works when MSYS make doesn't...

So I installed MinGW in c:\dev\MinGW and:
set PATH=c:\dev\MinGW\bin;c:\dev\MinGW\libexec\gcc\mingw32\3.4.5;%PATH%

Then I modified the WxWidgets config.gcc file to set SHARED=1 UNICODE=1 MONOLITHIC=1.
And then:
mingw32-make -f makefile.gcc BUILD=debug
worked!

Setting new environment variables (wxWidgets is installed in c:\ui):
set WXWIN=c:\ui\wxWidgets-2.8.10
set WXCFG=gcc_dll\mswud

Then I could install then wxdirect, wxcore and wx packages using a few more flags than what a default cabal install would do, for example:
runhaskell Setup configure --extra-lib-dirs=c:\dev\MinGW\lib --extra-include-dirs=c:\dev\MinGW\include --extra-include-dirs=c:\dev\MinGW\include\c++\3.4.5\mingw32 --extra-include-dirs=c:\ui\wxWidgets-2.8.10\include --extra-include-dirs=c:\dev\MinGW\include\c++\3.4.5

And it install, and works!

Thursday, April 22, 2010

The sorry plight of a Windows programmer (aka me)

Having secured fame and fortune with MazesOfMonad, my console based RPG, and having some ideas for some games that would look even better with a graphical front end, I decided it was time to take the bulls by the horn and go seriously into Haskell GUI programming. Well, the bull won and I feel truly gored...
So what's wrong? Well, after fooling around on my Windows 7 computer for a few nights I've achieved nothing. I now have three different copies of MinGW installed in different places. I have tried to installed SDL, GTK2HS, WXWidgets and Happstack and I have failed at all of them. I know WXWidgets is manageable because I've done it before, I only seem to have some include paths issues. libSDL itself installed but not the Haskell bindings. I found somebody with the same problem on the web, that then told me he had given up. I even managed to get Darcs errors with Gtk2Hs. In despair I thought I could develop a web based game but even the darcs version of happstack failed to compile, I remembered then some bug mentioned on the mailing list, so I should probably just download the latest stable version instead of the development branch.
Some problems are down to some silly things I did. For example installing the Haskell Platform in a directory with spaces is not a great idea (I don't remember if it was the default), because then a lot of paths referencing its MinGW install are wrong in the MSYS shell...
But most are due to the Unixy nature of a lot of the GUI components. Now I see a configure script and my blood freezes. I run "cabal install foo" and I get the dreaded message "this package has a configure script, you need to dive into Unix hell". Can you tell me why I have three versions of GCC, and two make a configure script crash with "c compiler cannot create executables" and the third one works? Where can I download one single file that will allow me to have a full MSYS/MinGW setup with most of what I need? I'm sure there are solutions to a lot of the problems I have, and maybe I need to spend more time reading the INSTALL files and such, and download everything from the MinGW files page. But why can't it Just Work? I mean, I work with Java at work, we do GUI work in SWT now and before that in Swing, we use a lot of libraries, and we never run into any installation problem. Maybe once or twice over the past couple of years we had a cross-platform compatibility issue or a library conflict. I know, I know, apples and oranges, but I'm now thinking that writing my own lazy, purely functional language with monads on top of the JVM with Java integration is going to be easier than getting a GUI library with Haskell bindings to work.
I like to write applications, not spend my free time trying to get libraries to install.

Friday, April 09, 2010

Found my neural network bug (three years later)

After the university of Waterloo AI Challenge I went back to a bit of AI programming in Haskell. Three years ago I had written some code to implement a neural network, and it didn't seem to learn as fast as the book said it should. I had not worked on that any more, but I decided to look at it again. And I found a bug!! I mixed up the deltas to pass on from one run to the next. Changing two lines of code makes my network learning much faster.
So now onto something a bit more meaty than exclusive or: very simple character recognition. I want to be able to recognize numbers written as a digital alarm clock would display them (at least mine): you have 7 lights, four vertical and three horizontal, and various patterns make the numbers. If all lights are on, it's 8, if only the middle horizontal light is off we have zero, etc...
I just test things with a network that has 7 input neurons (one for each light), 10 output neurons (one for each number) and 8 hidden neurons (the average between input and output)

g<-getStdGen
n<-network 7 8 10
let trainingSet=[
([1,1,1,-1,1,1,1],[1,0,0,0,0,0,0,0,0,0]), -- 0
([-1,-1,1,-1,-1,1,-1],[0,1,0,0,0,0,0,0,0,0]), -- 1
([1,-1,1,1,1,-1,1],[0,0,1,0,0,0,0,0,0,0]), -- 2
([1,-1,1,1,-1,1,1],[0,0,0,1,0,0,0,0,0,0]), -- 3
([-1,1,1,1,-1,1,-1],[0,0,0,0,1,0,0,0,0,0]), -- 4
([1,1,-1,1,-1,1,1],[0,0,0,0,0,1,0,0,0,0]), -- 5
([1,1,-1,1,1,1,1],[0,0,0,0,0,0,1,0,0,0]), -- 6
([1,1,1,-1,-1,1,-1],[0,0,0,0,0,0,0,1,0,0]), -- 7
([1,1,1,1,1,1,1],[0,0,0,0,0,0,0,0,1,0]), -- 8
([1,1,1,1,-1,1,1],[0,0,0,0,0,0,0,0,0,1]) -- 9
]
let (LNS(n',err,ds),e) = run (initialState n) defaultLearningRate trainingSet (1,1000)

And after something like 150 iterations I get a network that has a low error rate. A little helper method to massage the results:

runNumber n inputs=do
let
(_, output)=exec n inputs
normalized=map (\v->if (1-v)>0.5 then 0 else 1) output
return $ elemIndex 1 normalized

Et voila!

Main> runNumber nn [1,-1,1,1,-1,1,1]
Just 3

Now, things are starting to get interesting! Hopefully I won't wait another three years before trying maybe more complex character recognition.