Saturday, October 20, 2007

Cohatoe 0.7 preview

This version mostly completes what I started in the 0.6 version, with a particular focus on the tool support that comes with the Cohatoe SDK. It introduces the notion of a Cohatoe Plugin project, i.e. a project that contains both Java code and Haskell code for an Eclipse plugin. I have also added some more developer documentation to the Cohatoe entry in the Eclipse Help system.

Cohatoe Plugin projects

A Cohatoe Plugin project is a special type of project in the workspace. It inherits from Eclipse's (PDEs) own plugin project, but in addition it 'knows' about Cohatoe-based extensions and facilitates their development. For instance, it gives a warning if there is no dependency to the Cohatoe server core plugin.

More important, once a project is marked as a Cohatoe project, it is ensured whenever files in the project change that the Haskell source files in hs-src/ get compiled and the object code is placed at the object code folder for the current platform (ignoring contents of the object code folder which belong to other platforms). This should facilitate a lot of handling (and you can ignore the details of the naming conventions for platform-specific folder names).

If you use the Cohatoe extension wizard for creating new extensions, the project where you do this is automatically marked as a Cohatoe project. You can also set and unset this mark by right-clicking a project in the workspace and selecting Toggle Cohatoe Nature.

Autobuild of Cohatoe projects

When you change someting in a Cohatoe project, an automatic build is triggered in the background that re-compiles (if necessary) the sources in hs-src/. For this purpose, a simple Cabal configuration is generated (into the INTERNAL/cohatoe/ subfolder of the project) and executed. The outputs of the build are displayed on the Console View. If Haskell source files from the hs-src folder are mentioned in the build output (normally in error and warning messages), you can click them and an editor opens on the respective source location. (It helps if you have EclipseFP installed, of course, since in this case the editor that opens is EclipseFP's Haskell source editor). If you want to configure compiler options or package dependencies for the autobuild, you can do so in the Cabal configuration file.

I think this is an important step for EclipseFP (of which Cohatoe is a part). On the way to transform it into a self-hosted IDE for Haskell that is partly implemented in Haskell, it is necessary to have better support for the development of the Haskell bits in the workspace. EclipseFP has good editing support, but since it is a more general IDE for Haskell development, it would not be good to build knowledge about Cohatoe structures directly into it. The Cohatoe SDK plugins now add this on top of EclipseFP and JDT/PDE.

Have fun :-)

Sunday, October 14, 2007

Cohatoe 0.6 preview

Here comes another step towards the 1.0 release version of Cohatoe. This one has taken much longer than I had hoped, and I'm also somewhat running out of time for today, so I just give you the 'official changelog'. There'll be more soon.

Have fun :-)

Changes between 0.6 and 0.5

  • A binary version of the Cohatoe API against which the Haskell server executable was compiled is delivered with the Cohatoe server core plugin, and it is provided to the hs-plugins library when object code is loaded and when source code is compiled. This removes the requirement that the user must have the cohatoe-api package installed in addition to their GHC installation.
  • The Cohatoe API package (the GHC package against which Haskell code for Cohatoe-based Eclipse plugins must be compiled) is now finalized as version 1.0.0. The reason for this is mostly to avoid complications when versions are continuously updated: the .hi files that must be provided for hs-plugins to load the object code contain the versions of package dependencies, and thus fail to load if only a version of the API with a newer version number is available. On the other hand, the API doesn't change at all (apart from the version number itself), so it makes sense to keep the version number stable. There remains a minimal risk that the API must be changed again before the release, in which case some early adopters would possibly have to recompile. (But this is very unlikely.)
  • Fixed a bug in locating the Haskell server executable: when multiple platform-specific fragments of the Cohatoe server core plugin were present, an arbitrary executable was picked.
  • The function factory in the CohatoeServer singleton is now generic (in the Java sense, i.e. has a type parameter. This adds some compile-time typesafety and removes the need for some casts.
  • The Cohatoe development tools (Cohatoe SDK) contain now a Cohatoe project type that can be toggled via a context menu entry on project resources in the workspace. Adding the Cohatoe nature means that the Eclipse autobuild runs over Cohatoe projects and makes checks and re-compiles the object code for Cohatoe extensions. This feature is still experimental.
  • Started to write developer documentation; in particular, there is now a Plug-In Developer's Guide that describes the Cohatoe SDK tooling, and there are also some context help entries for the Cohatoe extension wizard.
  • Added an installation tester application to the SDK. This is a small, headless standalone application that runs a Cohatoe extension in order to check whether all pre-requisites in an installation are there for running Cohatoe-based extensions.