Everything is broken

This week was I suppose fairly typical. Started using a new library, the excellent sqlg that provides the TinkerPop graph API on top of relational databases. Found a bug pretty quickly. Off we go to contribute to another open source project, good for my street cred I suppose. Let’s fork it, and open the source code in IDEA (Community edition). After years of hearing abuse about Eclipse, I’m now trying to use “the best IDE ever” (say all the fan boys) instead. Well, that didn’t go so well, apparently importing a Maven project and resolving the dependencies proves too much for IDEA. I fought with it for a while, then gave up.

Fired up Eclipse, it opened and built the sqlg projects without a hitch. Wrote a test, fixed the bug, raised a PR, got it accepted with a thank you, life is good.

Then I find another bug. Except that upon investigation, it’s not in sqlg, it’s in the actual TinkerPop code. The generics on a map are wrong, there are values that are not instances of the key class (thanks generics type erasure!). So I can fix by changing the method signature, or change the keys. Both will break existing code. Sigh…

Oh, and the TinkerPop project doesn’t build in Eclipse. The Eclipse compiler chokes on some Java 8 code. Off to the Eclipse bug tracker. Maybe I need to have three different Java IDEs to be able to handle all the projects I may find bugs in.

Everything isbroken. Off I go to my own code to add my own bugs.

Scratching an itch: generating Cabal data-files field automatically

Maybe I didn't look hard enough, but I'm not aware of a tool to generate the contents of the Cabal data-files field automatically when you have loads of folders to include. Cabal has very simple wildcard matching for files references in this field, by design (to avoid including too much data in a source distribution). So it only supports wildcards to replace the file name inside a directory for a given extension, and doesn't support sub directories.

For the reload project - first release on Hackage! - I had to include loads of files, all the Polymer web components the UI depends on, which are all on different sub directories, with a bunch of different extensions. So I wrote a little tool to generate the field automatically, and put it on Hackage too.

You pass it a directory name, possibly some subdirectories and extensions to ignore, and it generates all the required entries. Saved me loads of time, and scratched my own itch!

Another Web-based Haskell IDE

After giving up on EclipseFP, I've worked a bit on haskell-ide-engine and leksah, contributing little things here and there to try to make the Haskell IDE ecosystem a little bit better. But at some point, I tried to update the GTK libraries on my Ubuntu machine to get leksah to run, and broke my whole desktop. Hours of fun followed to get back to a working system. So I thought again at my efforts last year to have a web based IDE for Haskell, because using the browser as the UI saves users a lot of pain, no UI libraries to install or update!

I started another little effort that I call "reload", both because it's another take on something I had started before and of course because it issues ":reload" commands to ghci when you change files. I have changes the setup, though. Now I use Scotty for the back end, with a REST API, and I use a pure Javascript front-end, with the Polymer library providing the web component framework and material design. I also use a web socket to send back GHCi results from the back end to the browser. I still use ghcid for the backend, maybe one day when haskell-ide-engine is released I can use that instead.

The functionality is fairly simple yet: there is a file browser on the left, and the editor (I'm using the ACE web editor) on the right. There is no save button, any change is automatically saved to disk (you use source version control, right?). On the server, there is a GHCi session for each cabal component in your project, and any change causes a reload, and you can see the errors/warnings in a menu and in the editor's annotations. You can build, run tests and benchmarks, and I've just added ":info" support. The fact that we're using GHCi makes it fast, but I'm sure there's loads of wrinkles to iron out still.

Anyway, if you're interested in a test ride, just clone from Github and get going!

Starting out on Android

Oohhh, it's been a while since I've posted. I spent some time working on haskell-ide-engine, but then I got Haskell fatigue and decided to look at Android instead. A change is as good as a rest!

Coming from the Java world, it's not difficult to get into Android. I followed the guide on the Google site to get the basics. At first I got a bit afraid of the unholy mix of Gradle build scripts, visual layout editor, XML files and Java code, but you get over it. The IDE has some nice touches and it's good to get useful autocompletion in resources like ids and strings. I liked the warning about SDK level APIs and missing resources once I started translated my app into French.

But I have to say, when I was working on EclipseFP I often ran into IDEA fanatics that swore that IDEA was miles ahead of Eclipse. Android Studio famously moved from Eclipse to IDEA, and frankly, I don't see what the hype is about. Yes, Eclipse has some annoying bugs and idiosyncrasies. But Android Studio, at least with the default settings, as I haven't spent much time customizing it, is not such a wonderful IDE. It's slow to start up, the view layout is sometimes confusing, the font is too fine or small in places (I must be getting old, but sometimes I couldn't see that a semi colon was in fact a colon) and the warning/error markers in the gutter are way too small and nearly invisible, to the point that sometimes the build fails and I can't see where in the source is the error! Maybe there's a special "grumpy old man with failing eye sight" setting to make things bigger.

Since I believe that you learn by doing, I've developed my first app, and I'm in the process of publishing it to the App Store (so I can claim I'm a published Android developer in my CV, wink). Apart from the fact that you need to supply an icon in 2 million different sizes, which is challenging for somebody with my artistic abilities, it's a straightforward process. My app is an uninteresting workout log app (to record how much weight you supposedly lift at the gym) that's purely local (no social features, so you can't boast online about the weights you may have lifted), but hey, it's a start. The code is of course on Github.

I've also wrote a basic game using the framework presented here, and the nice asset from Kenney (see note about artistic abilities above). Nothing fancy, just a rabbit hopping over holes and getting carrots for points, but just seeing my little game running on my family's phones and tablets is nice! It's on Github too.

A new Haskell IDE!

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

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

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

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

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

Happy Haskell Hacking!

EclipseFP 2.6.1 released!

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

Release notes can be found here.

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

Happy Haskell Hacking!

EclipseFP reaches 100 stars!

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

Happy Haskell Hacking!

EclipseFP 2.6.0 released!

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

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

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

Happy Haskell Hacking!

Haskell Worksheet in EclipseFP 2.6

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

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

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

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

Cabal sandbox support in EclipseFP 2.6

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

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

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

EclipseFP 2.5.6 released

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

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

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

Happy Haskell Hacking!

Acme editor for Haskell development?

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

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

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

Happy Haskell Hacking, on Acme or not!

EclipseFP 2.5.5 released!

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

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

Happy Haskell Hacking!

EclipseFP: laundry list for 2.6

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

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

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

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

EclipseFP: package version bounds in dependencies

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

You have four options:

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

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

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

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

EclipseFP 2.5.4 released

Hello folks, a new bug-fixing release of EclipseFP. Nothing major, mainly fixed a big bug that caused the plugin to randomly not start properly in Kepler, and few little enhancements to make life easier. The full release notes have all the details.

I'm also pleased to announce a new contributor, Maik Riechert, who contributed a hyperlink detector so that hyperlinks in source files can be followed.

As usual, just update from within Eclipse using update site http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

EclipseFP 2.5.3 released

Hello, I've just released a new version of EclipseFP, 2.5.3. This is a minor release for bug fixes, general stability and hopefully better performance.

You can find the release notes here: https://raw.github.com/JPMoresmau/eclipsefp/master/docs/releasenotes/net.sf.eclipsefp.haskell_2.5.3.txt.

I don't have a lot of time for EclipseFP at the moment, being busy on other projects, but I'm well aware that there are a few enhancements that people have asked for in the queue. I'll try to address these later on, and of course I'll happily accept pull request on https://github.com/JPMoresmau/eclipsefp.

As usual install or update by pointing your Eclipse to http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

Eclipse Hate and Haskell IDEs

A few weeks ago I was reading the comments about the release of Android Studio on reddit. I was a bit shocked by all the Eclipse hate. But hey, I suppose I use Eclipse and not IntelliJ, so I don't know what I'm missing and how great it would be to work on IDEA. But then I was surprised to see that there has been no release of ideah, the Haskell plug-in for IDEA, for a year and a half. How come there isn't more momentum if IntelliJ is such a great IDE to build on and work with?

Maybe we're just suffering from too much dispersion in the Haskell IDE space. We have plug-ins for the major IDEs, but none of them can probably called great (I know, some people positively hate EclipseFP, but for my defence I'll say I get much more bug reports and feature requests than pull requests, I probably need a course on "building a passionate programming community around your open source project"). They however have the massive advantage of being able to reuse a wealth of existing code (I can use the Eclipse Git plugin to work with Github, I don't need somebody to write the Haskell version). An IDE in Haskell like Leksah or something built on top of Yi would be amazing to showcase that you can do real applications in Haskell (since you still get people saying that Haskell is only for toying with), but then you need to build everything, which requires people (see note above on building a community). Then we have web based editors like the offering from FPComplete, but for developers to use them on real projects we need to think on how to package a web based interface and what it means for a development work-flow: I'm not sure developers would embrace developing using a browser. Of course we have plug-ins for the Unixy editors, emacs and vim, but if we want to open up Haskell to non hackers, maybe we need something more...

So can we continue like that and hope to have a few decent environments? Or shall we all agree on a direction and unite to provide the one true development environment for Haskell? Sometimes people say "Haskell is so different and advanced as a programming language, it needs a new type of editor/IDE". I don't disagree with it, but who has the vision of what the Haskell IDE should be?

EclipseFP 2.5.2 released

I'm happy to announce a new bug-fixing release of EclipseFP. You can see the release notes here.
A few issues around the use of cabal-dev were found, as expected, and fixed, and a couple of little feature requests have been put in.
Hope this helps! As usual, just upgrade Eclipse using the update site http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

EclipseFP 2.5.1 released

Quickly on the heels of 2.5.0 I'm releasing 2.5.1. This is mainly to fix an issue that caused the Editor->Syntax preference page to not open.
This release also add the possibility to change the font and colors of the tooltip in the editor (under Preferences->General->Appearance->Colors and Fonts, Haskell). It also searches for executables under $HOME/Library/Haskell/bin, which seems to be a path for executables on MacOS.
Also, some UI enhancements for Eclipse 4.2. The full release notes are here.

To upgrade just point your Eclipse to http://eclipsefp.sf.net/updates. Report any issue to the SourceForge forum.

Happy Haskell Hacking