<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-38084287</id><updated>2011-04-22T05:39:23.904+02:00</updated><category term='eclipsefp'/><category term='eclipse'/><category term='darcs'/><category term='announce'/><category term='cohatoe'/><category term='architecture'/><category term='debugging'/><category term='haskell'/><category term='eclipsedarcs'/><category term='development'/><category term='example'/><category term='tutorial'/><title type='text'>Leif Frenzel's Haskell and Eclipse blog</title><subtitle type='html'>Welcome. This blog is about Haskell and Eclipse Plug-In development. I have been working for a while on integrating these two and you will find some details here about those of my projects which belong in that area.</subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>42</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-38084287.post-2131798689458303966</id><published>2009-05-16T10:49:00.002+02:00</published><updated>2009-05-16T11:03:24.156+02:00</updated><title type='text'>EclipseFP is going to be reloaded</title><content type='html'>&lt;span style="font-family: arial;"&gt;Great news: Thomas ten Cate has started a Google Summer of Code project to extend EclipseFP functionality. So there will be some activity on the Haskell IDE front again :-) Of course I'm thrilled that EclipseFP will get some overhaul, but Thomas plans also to integrate GHC via &lt;/span&gt;&lt;a style="font-family: arial;" href="http://code.google.com/p/scion-lib/"&gt;scion&lt;/a&gt;&lt;span style="font-family: arial;"&gt;, an IDE support library. This is an important step towards an IDE core, written in Haskell, that can be used in other development environments (apart from Eclipse/EclipseFP), and so make it easier to spread good Haskell support in a variety of tools.&lt;/span&gt;&lt;span style="font-family: arial;"&gt;&lt;br /&gt;&lt;br /&gt;Thomas has created a blog about this project at &lt;a href="http://eclipsefp.wordpress.com/"&gt;http://eclipsefp.wordpress.com/&lt;/a&gt;&lt;/span&gt;&lt;span style="font-family: arial;"&gt;&lt;br /&gt;&lt;br /&gt;Good luck Thomas, and thanks for this initiative :-)&lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-2131798689458303966?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/2131798689458303966/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=2131798689458303966' title='6 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2131798689458303966'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2131798689458303966'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2009/05/eclipsefp-is-going-to-be-reloaded.html' title='EclipseFP is going to be reloaded'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>6</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-7194005731600458605</id><published>2009-04-24T08:59:00.003+02:00</published><updated>2009-04-24T09:04:21.573+02:00</updated><title type='text'>Clash of cultures at the Karlsruher Entwicklertag</title><content type='html'>For those of you who live in the Karlsruhe area, or happen to be there end-June, this might be interesting: there will be a panel discussion on Wed, June 24th, on the 'Clash of Cultures' between agile and traditional approaches.&lt;br /&gt;&lt;blockquote&gt;&lt;span style="font-size:85%;"&gt;&lt;span style="font-weight: bold;font-family:arial;" &gt;Podiumsdiskussion: "Clash of Cultures – Agilität und hergebrachte Arbeitsmodelle – Beobachtungen aus USA, Europa, Naher Osten und Asien – Unterschiede und Gemeinsamkeiten."&lt;/span&gt;  &lt;span style="font-family:arial;"&gt;&lt;br /&gt;&lt;br /&gt;PD Dr. Andreas Boes (ISF, München); Joe Krebs (AOL, New York), Prof. Dr. Khaled Nagy (Universität Alexandria, POET Egypt), Christian Schmidkonz (SAP, Walldorf), Joseph Pelrine (metaprog, Basel); Simon Roberts (Scrum Center, München)&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family:arial;"&gt;Moderation: Matthias Grund (andrena objects ag, Karlsruhe)&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;/blockquote&gt;This particular discussion is free of charge, but seating is limited,  so you have to register. (Hint: do so early, this will be fully booked soon :-)&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_BynttqNlK3w/SfFj8k61jSI/AAAAAAAAAKw/b9j6qiAK0cI/s1600-h/ET_Logo_Speaker.jpg"&gt;&lt;img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 120px; height: 76px;" src="http://3.bp.blogspot.com/_BynttqNlK3w/SfFj8k61jSI/AAAAAAAAAKw/b9j6qiAK0cI/s320/ET_Logo_Speaker.jpg" alt="" id="BLOGGER_PHOTO_ID_5328149726509763874" border="0" /&gt;&lt;/a&gt;I'll be at the &lt;span style="font-style: italic;"&gt;Entwicklertag &lt;/span&gt;also and give a talk about agile multi-project management (this will be on the second day, i.e. June 23th). For more info, go here: &lt;a href="http://www.andrena.de/Entwicklertag/2009/"&gt;http://www.andrena.de/Entwicklertag/2009/&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-7194005731600458605?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/7194005731600458605/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=7194005731600458605' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/7194005731600458605'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/7194005731600458605'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2009/04/clash-of-cultures-at-karlsruher.html' title='Clash of cultures at the Karlsruher Entwicklertag'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://3.bp.blogspot.com/_BynttqNlK3w/SfFj8k61jSI/AAAAAAAAAKw/b9j6qiAK0cI/s72-c/ET_Logo_Speaker.jpg' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-3031538558825315947</id><published>2008-04-26T11:26:00.003+02:00</published><updated>2008-04-26T11:49:01.225+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.12 preview</title><content type='html'>With this preview version of Cohatoe, we're actually very close to a release candidate for Cohatoe 1.0.&lt;br /&gt;&lt;br /&gt;The most important news is that Cohatoe now supports Windows again. This, and a number of other stability fixes are one of the results of our recent &lt;a href="http://cohatoe.blogspot.com/2008/03/hal-3-and-eclipsefp-hackathon.html"&gt;EclipseFP Hackathon&lt;/a&gt; at the &lt;a href="http://iba-cg.de/hal3.html"&gt;third Haskell in Leipzig meeting (HaL 3)&lt;/a&gt;. (Special thanks to Milan Straka for helping us with this complicated low-level work :-)&lt;br /&gt;&lt;br /&gt;The new preview version is available from the SourceForge download site and from the &lt;a href="http://eclipsefp.sf.net/cohatoe/"&gt;Cohatoe website&lt;/a&gt;. Have fun :-)&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Sharing object code between plugins&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;Almost all other changes in Cohatoe since the 0.9 preview are robustness improvements and small fixes. In addition, it is now possible for a Cohatoe extension to depend on object code contributed in another (Eclipse) plugin. For example, there is some common code for marshalling data types, which is located in the EclipseFP core plugin, which is needed also for the EclipseFP UI plugin. Cohatoe now allows to refer to this shared code via a new attribute in the declaration of an object code folder:&lt;br /&gt;&lt;br /&gt;&amp;lt;haskellFunction codeFile="$os$/obj/EclipseFP/Haskell/UI/Hover/EditorTextHover.o"&lt;br /&gt;[...]&lt;br /&gt;    &amp;lt;objectCodeFolder plugin="net.sf.eclipsefp.haskell.core"&amp;gt;&lt;br /&gt;      $os$/obj/&lt;br /&gt;    &amp;lt;/objectCodeFolder&amp;gt;&lt;br /&gt;&amp;lt;/haskellFunction&amp;gt;&lt;br /&gt;&lt;br /&gt;(An obvious possible improvement would be to have this inferred from the dependency relationship that exists anyway between the UI and Core plugin, and is known on the Eclipse side. However, this is not in scope for the 1.0 release. For the moment, the dependency must be declared manually.)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-3031538558825315947?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/3031538558825315947/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=3031538558825315947' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3031538558825315947'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3031538558825315947'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2008/04/cohatoe-012-preview.html' title='Cohatoe 0.12 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-1989089182666252607</id><published>2008-03-22T08:54:00.003+01:00</published><updated>2008-03-22T09:00:17.128+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><title type='text'>Updated HaL 3 program</title><content type='html'>A short update on the program for HaL 3 (Haskell in Leipzig), which I &lt;a href="http://cohatoe.blogspot.com/2008/03/hal-3-and-eclipsefp-hackathon.html"&gt;mentioned earlier&lt;/a&gt;: there are two more interesting talks on the agenda now - one about using Haskell in the software industry, the other on program verification for big software projects :-)&lt;br /&gt;&lt;br /&gt;You can find the &lt;a href="http://iba-cg.de/hal3.html#engl"&gt;full updated announcement on the HaL3 website&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-1989089182666252607?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/1989089182666252607/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=1989089182666252607' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1989089182666252607'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1989089182666252607'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2008/03/updated-hal-3-program.html' title='Updated HaL 3 program'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-3605003694667953703</id><published>2008-03-16T22:07:00.002+01:00</published><updated>2008-03-16T22:13:20.276+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='eclipsedarcs'/><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><title type='text'>EclipseDarcs 0.4.1 available</title><content type='html'>A new build of EclipseDarcs is now available: version 0.4.1. You can get it as zipped update site from the &lt;a href="http://sourceforge.net/project/showfiles.php?group_id=134526&amp;amp;package_id=147700&amp;amp;release_id=584776"&gt;SourceForge downloads area&lt;/a&gt; or directly using this update site location: &lt;code&gt;http://eclipsedarcs.sf.net/updates&lt;/code&gt;.&lt;br /&gt;&lt;br /&gt;Thanks to Neil Bartlett's contribution, you can now directly select a Darcs executable from the Darcs preference page (Preferences &gt; Team &gt; Darcs). The plugin uses that executable then and doesn't rely on Darcs being on the PATH. There are also some minor robustness fixes in this build; mostly they smooth out things in situations where the plugin previously had written ugly messages to the workspace log. Have fun :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-3605003694667953703?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/3605003694667953703/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=3605003694667953703' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3605003694667953703'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3605003694667953703'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2008/03/eclipsedarcs-041-available.html' title='EclipseDarcs 0.4.1 available'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-4991757522053745664</id><published>2008-03-10T17:44:00.005+01:00</published><updated>2008-03-11T16:19:14.998+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='eclipsefp'/><title type='text'>HaL 3 and EclipseFP Hackathon</title><content type='html'>There will be &lt;a href="http://cohatoe.blogspot.com/2007/07/cohatoe-talk-at-hal-2.html"&gt;another&lt;/a&gt; Haskell in Leipzig (HaL) meeting on April 18th (a Friday) - this is the third already, so it seems to be developing into a nice tradition :-)&lt;br /&gt;&lt;br /&gt;As at previous HaL events, Haskell IDEs are of some interest. Among other things, we'll hear a talk about Leksah, the new Haskell IDE which was recently announced in its first preview version. (For more info and the full program have a look at the HaL 3 website: &lt;a href="http://iba-cg.de/hal3.html" de="" engl=""&gt;http://iba-cg.de/hal3.html&lt;/a&gt;.)&lt;br /&gt;&lt;br /&gt;This time, there will also be a Hackathon weekend (April 19 and 20) with focus on EclipseFP and Cohatoe development :-) So if you don't have plans yet for that weekend (and are reasonably close to Leipzig ;-), why not drop by and have some fun?&lt;br /&gt;&lt;br /&gt;The kick-off for the Hackathon will be on Friday evening as part of the HaL meeting. I've also set up a wiki at &lt;a href="http://leiffrenzel.de/eclipse/wiki/"&gt;http://leiffrenzel.de/eclipse/wiki/&lt;/a&gt; with an idea pool for possible features and some directions on getting started with EclipseFP development. Of course I'll keep you posted on what happened at the Hackathon :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-4991757522053745664?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/4991757522053745664/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=4991757522053745664' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/4991757522053745664'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/4991757522053745664'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2008/03/hal-3-and-eclipsefp-hackathon.html' title='HaL 3 and EclipseFP Hackathon'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-5836156586257126715</id><published>2008-02-15T19:01:00.004+01:00</published><updated>2008-02-15T20:05:48.723+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.9 preview</title><content type='html'>This is another preview version of Cohatoe. Since the last one, I have switched from PC to Mac (and thus from Windows to MacOS X as my primary working OS), and I have also started the transition to GHC 6.8.2 for Cohatoe. So there is now a Cohatoe version for MacOS X, and one for Linux. Both require GHC 6.8.2.&lt;br /&gt;&lt;br /&gt;The transition is not yet complete: Cohatoe is broken on Windows so far (doesn't work yet for GHC 6.8.2, and does no longer work for older versions, so if you are on Windows, you don't want to update Cohatoe ;-); and there are still some issues on both Linux and Mac OS X (details are in the changelog file). But those latter ones can be worked around, and I wanted to make some progress on EclipseFP as well, so I decided to get this out in the current state and switch my attention to EclipseFP for the moment.&lt;br /&gt;&lt;br /&gt;Have fun :-)&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Finding the right path&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;Cohatoe calls some external programs (external, that is, to the Eclipse process), namely &lt;code&gt;ghc-pkg&lt;/code&gt; and runghc, and of course ghc itself (e.g. to ask it for its version and the libraries folder). To do so, it initiates a new process from within Java code, and this process inherits the environment from its parent process (the JVM that runs Eclipse).&lt;br /&gt;&lt;br /&gt;The standard GHC installation is in &lt;code&gt;/usr/local/bin/&lt;/code&gt;, and this  path is added to the &lt;code&gt;PATH&lt;/code&gt; environment variable all right; but that happens in the shell's startup file &lt;code&gt;.profile&lt;/code&gt;. Normally one starts Eclipse by double-clicking the &lt;code&gt;Eclipse.app&lt;/code&gt; in the  &lt;code&gt;eclipse/&lt;/code&gt; folder. In this case, &lt;code&gt;.profile&lt;/code&gt; is not read  and thus &lt;code&gt;PATH&lt;/code&gt; is not updated. Therefore, as far as Cohatoe is concerned, GHC cannot be assumed to be on the &lt;code&gt;PATH&lt;/code&gt;.&lt;br /&gt;&lt;br /&gt;So I have introduced a system property where the path to a GHC installation can be configured: it is named &lt;code&gt;cohatoe.ghc&lt;/code&gt;.&lt;br /&gt;&lt;br /&gt;This also helps with multiple GHC installations (a user could have several GHC versions on the system and might want to put a different one on the &lt;code&gt;PATH&lt;/code&gt; than the one Cohatoe needs).&lt;br /&gt;&lt;br /&gt;You can pass &lt;code&gt;cohatoe.ghc&lt;/code&gt; either on the command line or in the &lt;code&gt;eclipse.ini&lt;/code&gt; file (on Macs, the latter is hidden in &lt;code&gt;Eclipse.app/Contents/MacOS/&lt;/code&gt;). It must point to the folder which contains the GHC executable, e.g. &lt;code&gt;-Dcohatoe.ghc=/usr/local/bin&lt;/code&gt;.  (Make sure you put this into the command line &lt;i&gt;after&lt;/i&gt; the &lt;code&gt;-vmargs&lt;/code&gt;; else Eclipse will take it as an option for Eclipse, not as one that it has to pass to the JVM.)&lt;br /&gt;&lt;br /&gt;If the &lt;code&gt;cohatoe.ghc&lt;/code&gt; property is not set, Cohatoe falls back to assuming GHC to be on the &lt;code&gt;PATH&lt;/code&gt;; if it isn't there either, the only thing we can do is to write a message to the error log.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-5836156586257126715?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/5836156586257126715/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=5836156586257126715' title='5 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5836156586257126715'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5836156586257126715'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2008/02/cohatoe-09-preview.html' title='Cohatoe 0.9 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>5</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-6934517048198290428</id><published>2007-11-20T22:01:00.000+01:00</published><updated>2007-11-20T22:25:11.997+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.8 preview</title><content type='html'>This is an even smaller bugfix build. I mostly did it to have some fixes in for using Cohatoe in the new EclipseFP 2 development branch which is based on Cohatoe. (I'll post about that new development in EclipseFP shortly.)&lt;br /&gt;&lt;br /&gt;Have fun :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-6934517048198290428?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/6934517048198290428/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=6934517048198290428' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6934517048198290428'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6934517048198290428'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/11/cohatoe-08-preview.html' title='Cohatoe 0.8 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-2313734488243620280</id><published>2007-10-20T11:09:00.000+02:00</published><updated>2007-10-20T11:17:28.274+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.7 preview</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Cohatoe Plugin projects&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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 &lt;code&gt;hs-src/&lt;/code&gt; 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).&lt;br /&gt;&lt;br /&gt;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 &lt;i&gt;Toggle Cohatoe Nature&lt;/i&gt;.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Autobuild of Cohatoe projects&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;When you change someting in a Cohatoe project, an automatic build is triggered in the background that re-compiles (if necessary) the sources in &lt;code&gt;hs-src/&lt;/code&gt;. For this purpose, a simple Cabal configuration is generated (into the &lt;code&gt;INTERNAL/cohatoe/&lt;/code&gt; subfolder of the project) and executed. The outputs of the build are displayed on the Console View. If Haskell source files from the &lt;code&gt;hs-src&lt;/code&gt; 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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;Have fun :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-2313734488243620280?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/2313734488243620280/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=2313734488243620280' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2313734488243620280'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2313734488243620280'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/10/cohatoe-07-preview.html' title='Cohatoe 0.7 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-5698270464035078226</id><published>2007-10-14T20:57:00.000+02:00</published><updated>2007-10-14T21:15:47.201+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.6 preview</title><content type='html'>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.&lt;br /&gt;&lt;br /&gt;Have fun :-)&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Changes between 0.6 and 0.5 &lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;&lt;li&gt;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 &lt;span style="font-family: courier new;"&gt;hs-plugins&lt;/span&gt; library when object code is loaded and   when source code is compiled. This removes the requirement that the user   must have the &lt;span style="font-family: courier new;"&gt;cohatoe-api&lt;/span&gt; package installed in addition to their GHC    installation.&lt;/li&gt;&lt;li&gt;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 &lt;span style="font-family: courier new;"&gt;hs-plugins&lt;/span&gt;   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.)&lt;/li&gt;&lt;li&gt;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.&lt;/li&gt;&lt;li&gt;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.&lt;/li&gt;&lt;li&gt;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.&lt;/li&gt;&lt;li&gt;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.&lt;/li&gt;&lt;li&gt;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.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-5698270464035078226?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/5698270464035078226/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=5698270464035078226' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5698270464035078226'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5698270464035078226'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/10/cohatoe-06-preview.html' title='Cohatoe 0.6 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-2517509357259849024</id><published>2007-09-30T16:23:00.000+02:00</published><updated>2007-09-30T16:43:22.886+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='eclipse'/><title type='text'>Eclipse's IDE Metatooling project</title><content type='html'>There is a &lt;a href="http://www.eclipse.org/proposals/imp/"&gt;new initiative&lt;/a&gt; at Eclipse.org for supporting projects who want to build Eclipse-based IDEs for new programming languages: the IMP project ('Eclipse IDE Meta-tooling Platform'). It seems it is a continuation of an IBM-internal project called SAFARI (of which we have seen a presentation at the last EclipseCON). This is great news; I think it will make the 'small step' that I have described in an &lt;a href="http://cohatoe.blogspot.com/2007/09/some-reflections-on-eclipse-based.html"&gt;earlier post&lt;/a&gt; much more extensive.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;The IMP approach&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;Basically the idea behind the IMP approach is that for any IDE you create, there is a lot of stuff that you have (or someone else has) done already for other IDEs. The  language specifics (such as the concrete syntax and semantics) may differ, but when you want to color syntax in the editor, show an Outline view and so on, you find yourself doing basically the same things that are done for any other language IDE. Much of the specifics of a language can be captured in a condensed description such as a grammar - why not derive the common stuff from there?&lt;br /&gt;&lt;br /&gt;With IMP, you start with identifying your language and some basic information (e.g. file extension), and then providing a syntactical description, from which the lexer and parser are generated. From this, IMP can already derive some development support (e.g. mark syntax errors in the code editor). Now the rest of your IDE is built up from 'IDE services', which you can add one by one.&lt;br /&gt;&lt;br /&gt;These IDE services are an abstraction over the well-known Eclipse APIs that one would have to implement when creating an IDE, e.g. project natures, New Project wizards, Outline page, syntax colorer, Code Folding, Content Assist etc. Since the parser is already in place, such IDE services can be generated in order to make use of the AST delivered by it; the generated code can then be customized to particular needs.&lt;br /&gt;&lt;br /&gt;More information in detail can be found in the &lt;a href="http://eclipse-imp.sourceforge.net/documentation/users_guide.html"&gt;IMP Users Guide&lt;/a&gt; and in the &lt;a href="http://eclipse-imp.sourceforge.net/publications/SAFARI-EclipseCon-2007-LongTalk.pdf"&gt;SAFARI presentation from EclipseCON 2007&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;The small step and the big step&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;So much for the small step (that is, what you get for free). What the IMP approach doesn't help with, though, is &lt;a href="http://cohatoe.blogspot.com/2007/09/some-reflections-on-eclipse-based.html"&gt;making the big step&lt;/a&gt;, once the small step is done.&lt;br /&gt;&lt;br /&gt;Well, perhaps for many languages an extensive small step is all that is needed. An IMP-based IDE will have a lot of nice features. Here's a list from their &lt;a href="http://eclipse-imp.sourceforge.net/introduction.html"&gt;website&lt;/a&gt;:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;syntax highlighting, outline view population, package explorer-like navigation, content assistance, project natures and builders, error markers&lt;br /&gt;   &lt;/li&gt;&lt;li&gt;refactoring support (not only "Move" and "Rename", but type- and code-related refactorings requiring non-trivial analysis, e.g. "Extract Method" and "Infer Type Arguments")&lt;br /&gt;   &lt;/li&gt;&lt;li&gt;static program analysis (pointer analysis, type analysis, etc.) in support of the above&lt;br /&gt;   &lt;/li&gt;&lt;li&gt;execution and debugging support&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;For many languages, IDE support of this order will get them quite some way, in particular if it comes mostly for free, or is at any rate easier done than with the current Eclipse APIs :-) Especially experimental languages or languages with a focused field of application (DSLs) will benefit from having such IDE support, and they might have not a real demand for making the big step.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;IMP and established languages&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;But what about established, general-purpose languages? They have been around for a while; there is a community, and there are programming tools. Such languages tend to be self-hosting: given one that is sufficiently general-purpose, as soon as there is some community around it, people will start to write development tools &lt;i&gt;in that language&lt;/i&gt;, for that language. Furthermore, its community works in the target language. They're not so much interesting in building their IDE in Java. (Perhaps even less so in hacking around in generated Java files to 'customize' it?) For taking the big step, making the project attractive to a larger community is essential. To avoid duplication of functionality, it is important to integrate existing tools - but these are written in the target language and don't necessarily integrate quite well with Java and Eclipse concepts.&lt;br /&gt;&lt;br /&gt;Quite possibly, having gained so much by the small step, it might even become more difficult to get started with the big step. If the big step is not done in Java, it will involve much re-work, and there is a certain discouragement for this in the fact that so much already works ...&lt;br /&gt;&lt;br /&gt;As far I can see, the IMP approach doesn't take this into account, and will thus mostly be helpful in areas where languages are restricted to some area of application, or are expected to be experimental and short-lived (or are sufficiently close to Java).&lt;br /&gt;&lt;br /&gt;However that may be, this is definitely an interesting project that addresses a real need, and I'll be interested to follow it and see how it develops. (As a side note: there may well be some potential to integrate Cohatoe with IMP, in order to further reduce the amount of code one has to write on the Eclipse/Java side when implementing plugins in Haskell. I'll have a closer look into this sometime in the future and keep you posted.)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-2517509357259849024?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/2517509357259849024/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=2517509357259849024' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2517509357259849024'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2517509357259849024'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/09/eclipses-ide-metatooling-project.html' title='Eclipse&apos;s IDE Metatooling project'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-8958481619702445291</id><published>2007-09-22T15:56:00.000+02:00</published><updated>2007-09-22T16:06:20.061+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='architecture'/><title type='text'>What Cohatoe is not</title><content type='html'>For understanding what a tool or framework is good for, it is sometimes helpful to eliminate a few potential misunderstandings, i.e. what one might think from a first glace at a description or screenshot, but what is in fact not the case. There is always room for such misunderstandings, since people come from different backgrounds and with different expectations, and since descriptions are never perfect.&lt;br /&gt;&lt;br /&gt;So here is what Cohatoe is not:&lt;ul&gt;&lt;li&gt;&lt;p&gt;&lt;span style="font-style: italic;"&gt;a set of Haskell bindings to the Eclipse APIs&lt;/span&gt;&lt;/p&gt;&lt;p&gt;Cohatoe is not for manipulating a running Eclipse instance (and its UI) from Haskell code, or for 'scripting Eclipse in Haskell'. What we want to do in Haskell is the internal logic, the UI and the general layout of the application are structured by Eclipse concepts.&lt;/p&gt;&lt;p&gt;In this respect Cohatoe is different from the &lt;a href="http://sourceforge.net/projects/jvm-bridge/"&gt;Haskell-JVM-Bridge&lt;/a&gt; (which enables to create and manipulate Java objects in a JVM instance from Haskell code), and from approaches such as &lt;a href="http://www.eclipse.org/dash/"&gt;EclipseMonkey&lt;/a&gt; (where JavaScript code is executed that binds to some Eclipse APIs).&lt;/p&gt;&lt;/li&gt;&lt;li&gt;&lt;p&gt;&lt;span style="font-style: italic;"&gt;support for Haskell-Java language interoperability&lt;/span&gt;&lt;/p&gt;&lt;p&gt;The game is not in particular to make Haskell code talk to Java code, or &lt;i&gt;vice versa&lt;/i&gt;. It is rather to integrate logic that is written in Haskell with Eclipse's plugin model in a way that preserves the modularity and extensibility that comes with this plugin model as it is implemented in Java. There will be some more support for transporting data structures between the Haskell side and the Java side, but the interoperability part of Cohatoe is just a generic vehicle (currently simply a list of strings), and the clients of Cohatoe on both sides (Haskell and Java) have currently to do their marshalling and unmarshalling themselves.&lt;/p&gt;&lt;p&gt;Much more important than the language interoperability aspect is the modularity and extensibility that is so important in the architecture of Eclipse. We want to preserve this modularity and extensibility even when we write or integrate large parts of an application in Haskell.&lt;/p&gt;&lt;/li&gt; &lt;li&gt;&lt;p&gt;&lt;span style="font-style: italic;"&gt;an approach to UI programming in Haskell&lt;/span&gt;&lt;/p&gt;&lt;p&gt;Basically the same as the first point above. The idea is to have the UIs built using Eclipse   APIs. Only the logic is in Haskell.&lt;/p&gt;&lt;/li&gt;&lt;li&gt;&lt;p&gt;&lt;span style="font-style: italic;"&gt;a plugin system for Haskell&lt;/span&gt;&lt;/p&gt;&lt;p&gt;This is what hs-plugins is, and Cohatoe uses hs-plugins in order to load (possibly compile) and execute Haskell code.&lt;/p&gt;&lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-8958481619702445291?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/8958481619702445291/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=8958481619702445291' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/8958481619702445291'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/8958481619702445291'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/09/what-cohatoe-is-not.html' title='What Cohatoe is not'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-3975134370947281045</id><published>2007-09-20T20:07:00.000+02:00</published><updated>2007-09-20T20:42:54.375+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='eclipse'/><title type='text'>Some reflections on Eclipse-based language IDEs</title><content type='html'>A few years ago, when Eclipse's popularity was quickly growing, an interesting phenomenon was going on: a number of small projects were popping up (for a time, at the rate of a dozen or more per week) that implemented some extension to Eclipse, often for supporting some programming language. Some of them died quickly away when the interest of the founders moved on to something else, some of them became obsolete when their main idea was implemented by the Eclipse project itself. But there were some language support plugins that remained active and continued development until today. (EclipseFP is one of them, others include &lt;a href="http://www.phpeclipse.de/"&gt;PHPEclipse&lt;/a&gt;, &lt;a href="http://rubyeclipse.sourceforge.net/"&gt;RDT&lt;/a&gt; (Ruby), &lt;a href="http://erlide.sourceforge.net/"&gt;Erlide&lt;/a&gt; (Erlang), &lt;a href="http://pydev.sourceforge.net/"&gt;PyDev&lt;/a&gt; (Python), &lt;a href="http://e-p-i-c.sourceforge.net/"&gt;EPIC&lt;/a&gt; (Perl) and Eclipse.org's &lt;a href="http://eclipse.org/cdt/"&gt;CDT&lt;/a&gt; project.)&lt;br /&gt;&lt;br /&gt;The obvious paradigm for all Eclipse-based IDE's are are the Java Development Tools (JDT) from Eclipse.org. They were a most important factor in making Eclipse popular, and they pioneered many of the cool IDE features that we have come to expect from Java IDEs nowadays. However, keeping up with JDT proved hard for each of the language support projects. One obvious reason for this is of course that the effort that went into the JDT project exceeded by far the means available to the other projects, all of them (with the exception of CDT) being volunteer projects. But there are other reasons, too; I've got a few observations about one of them.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;The small step and the big step&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;For building language support on the basis of the Eclipse Platform, there is a small step and a big step: the small step is to get basic support, the big step is deep support. In order to make the small step, you just have to do a bit Java coding, learn a few Eclipse APIs, and you need some modest understanding of the target language. To make the big step, you have to implement, or integrate someone else's implementation of, deeply language-aware functionality (i.e. functionality aware of the syntax and semantics of the target language).&lt;br /&gt;&lt;br /&gt;The equivalent of the small step can be done even with many text editors:  they often have a feature where you can enter some syntax rules and get syntax coloring for content formats such as HTML or Java source code. In Eclipse, the small step includes not only syntax coloring, but project types (called 'Project Natures' in Eclipse terminology), integration of external build tools (normally compilers), output parsers to populate the Problems View, import and export wizards, etc.&lt;br /&gt;&lt;br /&gt;The big step, on the other hand, includes all the attractive features such as automated refactorings, search for references to language elements ('Find all calls to this function'), navigation to declarations, debugger integration and so on. (A while ago, I've co-authored an  &lt;a href="http://www.sigs-datacom.de/sd/publications/pub_article_show.htm?&amp;amp;AID=1751&amp;amp;TABLE=sd_article"&gt; article in a German journal&lt;/a&gt; that discussed which features belong into the language-sensitive category; my co-author exemplified the main points from the &lt;a href="http://rubyeclipse.sourceforge.net/"&gt;RDT&lt;/a&gt; project.)&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;What the big step involves&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;What everybody wants, of course, is language support that has taken the big step. But this means that a backend must be built that can analyze the syntactical and semantical structure of source code written in the target language. (And not only source code in the language itself, but also supporting formats, for example - in the Haskell world - Cabal configuration files, GHC package configuration files, etc.) It must understand the concepts behind the structure of the language (e.g. it must know what a module is, and what it means to find the name of a module in the name of a source file, or in a declaration in a Cabal configuration, and so on).&lt;br /&gt;&lt;br /&gt;JDT has achieved this. The Java IDE in Eclipse includes a fully standards- compliant Java compiler, and much of the interesting functionality relies on the source code parsing and incremental compilation facilities provided by it. In addition, JDT maintains a model of all language elements in the workspace; it has representations for all methods, types, (Java)  packages and so on, both from source files and attached libraries. All this is naturally implemented in Java. (It is also certainly helpful that the JDT project can practice 'Eat your own dogfood', i.e. that Eclipse can be built using Eclipse itself.)&lt;br /&gt;&lt;br /&gt;But what are you going to do if your target language isn't the same language as the one Eclipse is implemented in? First of all, there is not really a way around implementing Eclipse plugins at least partially in Java. That's unfavorable: even if you actually want to build all that functionality yourself, chances are that you want to do it in the target language, not in Java. If you don't want to re-implement everything (and that should be the common case), then it's squarely improbable that the existing stuff is written in Java. Haskell is a very good example: there is almost everything you'd like, in various degrees of maturity: source parsers (both for Haskell 98 code and many &lt;a href="http://www.cs.chalmers.se/%7Ed00nibro/haskell-src-exts/"&gt;language extensions&lt;/a&gt;), type inference and typchecking engine (&lt;a href="http://haskell.org/haskellwiki/GHC/As_a_library"&gt;GHC API&lt;/a&gt;), refactoring (&lt;a href="http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html"&gt;HaRe&lt;/a&gt;), API search (&lt;a href="http://haskell.org/hoogle/"&gt;Hoogle&lt;/a&gt;), a debugger (in &lt;a href="http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html"&gt;GHCi&lt;/a&gt;), and lots and lots more.  But guess in what language all that is written ... ;-)&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Interoperability&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;There are the usual options for language interoperability: you can run  executables written in other languages and communicate via standard input and output, or use language interoperability interfaces (such as Haskell's FFI) in conjunction with Java's native interface, JNI. Some languages can be run in an interpreter; others can be compiled to Java Virtual Machine bytecode. Although this is feasible, it's sometimes ugly and complicated, and it often limits  deeper integration (there's only so much information that you can send via console i/o, and in any case if your data is highly structured, you have to put additional effort in serializing and de-serializing it).&lt;br /&gt;&lt;br /&gt;Apart from that, Eclipse has its own dynamic module system, which relies on loading code at runtime on demand - most of the plugins that are actually in an installation may not be loaded at all in a particular session. Furthermore, the entire extensibility model in Eclipse relies on the idea that plugins cannot just plug into pre-existing extension points, but may very well (and very easily) provide new extension points themselves, which are available for anyone else to extend. In order to honor these features of Eclipse, there is much more to interoperate with than just the programming language (Java) and its runtime (the JVM). It's the Eclipse &lt;i&gt;platform concept&lt;/i&gt; that must be taken into account. And there is no obvious way to do that in any other language than Java. (There has been some experimentation recently with executing scripts in the place of Eclipse extensions, usually scripts written in languages that can be compiled to Java bytecode. If you are interested, look at &lt;a href="http://wiki.eclipse.org/Add_the_ability_to_write_plugins_using_jruby_or_groovy."&gt;  this Google Summer of Code project&lt;/a&gt; and  &lt;a href="http://neilbartlett.name/blog/2007/06/13/eclipse-pde-does-scala/"&gt;this post about Eclipse plugins in Scala&lt;/a&gt;).&lt;br /&gt;&lt;br /&gt;Thus taking the big step is not just more difficult for others than JDT for lack of resources. It is &lt;i&gt;inherently&lt;/i&gt; more complicated because it adds the burden of interoperating with the platform from a different language and/or runtime. It also doesn't help of course that naturally the group of potential contributors is smaller if they are required to be fluent in two different languages and sets of APIs. (I know from years of experience as a trainer for Eclipse plugin development that it takes some time to learn to find your way around in the set of Eclipse APIs, even for experienced Java programmers - simply because of their substantial size and the number of associated concepts.)&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;The way out&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;The lesson to be learned from this is, I think, clearly that a crucial piece in building an Eclipse-based IDE for a language must be to make code written in that language interoperate with the Eclipse Platform - that is, it is necessary to make it possible to write Eclipse plugins in that language. Once this is in place it becomes possible to&lt;br /&gt;&lt;ul&gt;&lt;li&gt;re-use existing tools written in the target language,&lt;/li&gt;&lt;br /&gt; &lt;li&gt;find and motivate contributors (i.e. who have an interest and a good knowledge about that language), and finally&lt;/li&gt;&lt;br /&gt; &lt;li&gt;make the big step :-)&lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-3975134370947281045?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/3975134370947281045/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=3975134370947281045' title='9 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3975134370947281045'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3975134370947281045'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/09/some-reflections-on-eclipse-based.html' title='Some reflections on Eclipse-based language IDEs'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>9</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-6412732251749357967</id><published>2007-09-18T23:47:00.000+02:00</published><updated>2007-09-18T23:52:20.149+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='development'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Progress on Cohatoe</title><content type='html'>Here is another update about the latest additions to the Cohatoe repo :-)&lt;br /&gt;&lt;br /&gt;We now manage the library files for the Coahatoe API (the GHC package against which Haskell code for  Cohatoe-based Eclipse plugins must be compiled) next to the server executable in platform-specific fragments. They are automatically found, possibly extracted (when the plugin lives in a &lt;code&gt;.jar&lt;/code&gt; file), and then provided to the hs-plugins library both when object code is loaded and when source code is compiled, in the form of an 'on the fly'-GHC package. This removes the requirement that Cohatoe users had to have the &lt;code&gt;cohatoe-api&lt;/code&gt; package installed in addition to their GHCi installation.&lt;br /&gt;&lt;br /&gt;So far, Cohatoe worked only on machines that had a Cohatoe API installed as GHC package. This is clearly not good, partly because it is not a reasonable pre-requisite (the API should only be needed for &lt;i&gt;developing&lt;/i&gt; Cohatoe-based plugins, but not for &lt;i&gt;using&lt;/i&gt; them), and partly because there might be version conflicts (e.g. if a plugin has been compiled against a later API version than is installed on the user's system).&lt;br /&gt; &lt;br /&gt;The situation is now better: a user who has a GHC installation, but no &lt;code&gt;cohatoe-api&lt;/code&gt; package installed, will be able to run Cohatoe-based plugins. The Cohatoe server locates the Cohatoe API library that is shipped together with it. The additional advantage is that the server executable will always get the version of the API that itself was compiled against. The shipped version has precedence. (Note   that this does not guarantee that the plugins which are loaded are also compiled against that version of the API.) If you want to compile against the Cohatoe API, you still need to install the &lt;code&gt;cohatoe-api&lt;/code&gt; package, of course.&lt;br /&gt;&lt;br /&gt;I have also finalized the version of the &lt;code&gt;cohatoe-api&lt;/code&gt; package to 1.0 (the final release version). 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.&lt;br /&gt;&lt;br /&gt;On the other hand, I was having some trouble with object files that I had compiled against versions of the API (not actually different code, the only difference was in version number). So I think for this package I'm switching to a versioning policy that only updates the version number when the content actually changes.  This means that even after the release the API will only change in version if there are actual changes to the interface. Version numbers will not be increased in step with the other Cohatoe plugins.&lt;br /&gt;&lt;br /&gt;Later versions of Cohatoe will probably need some mechanism to enable running both code that was targeted at the 1.0 version and code that was written for later versions. This means that the old API will probably have to remain available, and the server will have to determine which API to use and to load against. (This will cause some work, but that is definitely not a topic for the 1.0 release, and I'm confident that it can be sorted out.)&lt;br /&gt;&lt;br /&gt;Apart from that, I have also continued working on getting the Linux version ready, and I have cleaned up the Haskell code of the server executable a bit. I think I will be able to get the next preview version out soon.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-6412732251749357967?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/6412732251749357967/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=6412732251749357967' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6412732251749357967'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6412732251749357967'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/09/progress-on-cohatoe.html' title='Progress on Cohatoe'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-7347245059045539028</id><published>2007-09-13T18:58:00.000+02:00</published><updated>2007-09-13T19:04:00.805+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='example'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe presentation video online</title><content type='html'>The video of my presentation at the Haskell in Leipzig 2 meeting is now online :-) You can watch it &lt;a href="http://lepetitfou.dyndns.org/home/"&gt;on Tobias' blog&lt;/a&gt;, along with the other talks from the event. (And don't ask me about the &lt;i&gt;Stolperstein&lt;/i&gt; ;-)&lt;br /&gt;&lt;br /&gt;As &lt;a href="http://cohatoe.blogspot.com/2007/08/next-steps-for-cohatoe.html"&gt;already said&lt;/a&gt;, the talk is in German; there is a &lt;a href="http://sourceforge.net/mailarchive/forum.php?thread_name=469D2E86.7020208%40leiffrenzel.de&amp;amp;forum_name=eclipsefp-develop"&gt;summary&lt;/a&gt; that I've posted to the EclipseFP mailing list earlier, and &lt;a href="http://leiffrenzel.de/papers/cohatoe-hal2-presentation.pdf"&gt;here are the slides&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;Thanks to Tobias and everybody who have made this fun possible :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-7347245059045539028?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/7347245059045539028/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=7347245059045539028' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/7347245059045539028'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/7347245059045539028'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/09/cohatoe-presentation-video-online.html' title='Cohatoe presentation video online'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-5844194519665105082</id><published>2007-09-12T20:48:00.000+02:00</published><updated>2007-09-12T20:52:28.597+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='development'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe development progress</title><content type='html'>Here's a brief status update about the latest few patches that just went into the Darcs repo.&lt;br /&gt;&lt;br /&gt;I have fixed a bug that caused Cohatoe to select the wrong platform-specific fragment, and thus the wrong server executable, if there was more than one present. In other words, if you had Cohatoe running with &lt;i&gt;both&lt;/i&gt; the Linux and the Windows fragment installed, it crashed under Windows because it tried to run the Linux executable - even though the Linux fragment wasn't activated. Cohatoe can now figure out which fragment is the correct one. (I suspect that has troubled nobody but me so far, but it was nagging me a bit. I wanted to catch up with the Linux version, but I had the fragment project disabled because of this bug. I think I will be able to get a well-working Linux version along with the Windows one for the next preview release. I've already re-activated my old Gentoo box for this :-)&lt;br /&gt;&lt;br /&gt;I have also built in an automatism to pass on GHC runtime options to the Cohatoe runtime. If you have some Haskell code contributed via Cohatoe which needs to enable RTS options, you can now specify them on the command line for the Eclipse executable (or better, in the &lt;code&gt;eclipse.ini&lt;/code&gt; file), and they are detected by Cohatoe and passed on to the Haskell server. You can specify the &lt;code&gt;+RTS ... -RTS&lt;/code&gt; as you would pass them to any GHC-compiled executable. (In the &lt;code&gt;eclipse.ini&lt;/code&gt;, take care that you have exactly one option per line, because that's how Eclipse expects them.)&lt;br /&gt;&lt;br /&gt;At the moment, options that are not accepted by the GHC RTS break the Cohatoe server (i.e. the server executable doesn't even start at all). So if you are playing around with the options, you better have &lt;a href="http://cohatoe.blogspot.com/2006/12/how-to-tell-whats-going-on.html"&gt;Cohatoe's tracing&lt;/a&gt; enabled to see what actually happens. Without that, all you see is an &lt;code&gt;IllegalStateException&lt;/code&gt; that complains about a dead server. I will build in some more sophisticated recovery with more info within one of the next iterations.&lt;br /&gt;&lt;br /&gt;Have fun :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-5844194519665105082?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/5844194519665105082/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=5844194519665105082' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5844194519665105082'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5844194519665105082'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/09/cohatoe-development-progress.html' title='Cohatoe development progress'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-2339963613673995466</id><published>2007-09-05T21:19:00.000+02:00</published><updated>2007-09-05T22:36:03.318+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.5 preview</title><content type='html'>Here comes another preview version of Cohatoe. I think it is now time to take a bold step and declare it 'beta' (no longer 'alpha' :-). This means in practice that the features which are in now will pretty much remain the same until version 1.0, but I still expect to have to do some more updates, mainly with fixes and documentation (and perhaps a little more tool support for PDE).&lt;br /&gt;&lt;br /&gt;&lt;i&gt;&lt;b&gt;This version is only available from the new download site at EclipseFP!&lt;/b&gt;&lt;/i&gt; Please make sure that you update your bookmarks :-) Likewise, I have pushed the latest patches &lt;i&gt;only&lt;/i&gt; to the  new repo location. See &lt;a href="http://cohatoe.blogspot.com/2007/08/next-steps-for-cohatoe.html"&gt;this previous post&lt;/a&gt; for links and a little more info.&lt;br /&gt;&lt;br /&gt;Version 0.5 has the &lt;a href="http://cohatoe.blogspot.com/2007/04/cohatoe-extension-wizardry.html"&gt;extension wizardry&lt;/a&gt; that I have mentioned before, and it is well able to handle &lt;a href="http://cohatoe.blogspot.com/2007/04/contributing-source-files.html"&gt;running extensions from Haskell source files&lt;/a&gt; now. (There were several fixes I had to do for this since my last post.) It is basically the version that I have presented at the Haskell in Leipzig 2 meeting.&lt;br /&gt;&lt;br /&gt;Any feedback is appreciated - have fun :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-2339963613673995466?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/2339963613673995466/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=2339963613673995466' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2339963613673995466'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2339963613673995466'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/09/cohatoe-05-preview.html' title='Cohatoe 0.5 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-4518476390178231564</id><published>2007-08-09T21:02:00.000+02:00</published><updated>2007-08-09T21:10:47.947+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Next steps for Cohatoe</title><content type='html'>For those who are interested but haven't subscribed to the EclipseFP mailing list: I have posted a &lt;a href="http://sourceforge.net/mailarchive/forum.php?thread_name=469D2E86.7020208%40leiffrenzel.de&amp;forum_name=eclipsefp-develop"&gt;summary of what I presented&lt;/a&gt; at the &lt;span style="font-style: italic;"&gt;Haskell in Leipzig 2&lt;/span&gt; meeting, in &lt;a href="http://cohatoe.blogspot.com/2007/07/cohatoe-talk-at-hal-2.html"&gt;my talk&lt;/a&gt; about the progress of Cohatoe. The post has also a link to the slides, but the slides are not the whole story of course, since most of the presentation was live demo.&lt;br /&gt;&lt;br /&gt;(Oh, btw: perhaps you should consider to subscribe to the mailing list now, if you are interested in Cohatoe, because we have decided at the EclipseFP project that we would keep the discussion for both Cohatoe and the EclipseFP IDE project on the same mailing list. You can &lt;a href="http://lists.sourceforge.net/mailman/listinfo/eclipsefp-develop"&gt;subscribe here&lt;/a&gt; :-)&lt;br /&gt;&lt;br /&gt;We have now started to integrate Cohatoe back into the EclipseFP project. There won't be any significant changes in the Cohatoe code itself (at least for a while ;-) - but the location of the repo has changed, and the same will go for the download site. Both have been moved to the EclipseFP webspace, so please update your bookmarks :-)&lt;br /&gt;&lt;br /&gt;The new Darcs repository is located here:&lt;br /&gt;&lt;br /&gt;&lt;ul style="font-family: courier new;"&gt;&lt;li&gt;http://eclipsefp.sf.net/repos/cohatoe/trunk&lt;/li&gt;&lt;/ul&gt;&lt;br /&gt;There is a new section on the EclipseFP website for Cohatoe, which has all the links to the download files etc. that were also on the old Cohatoe website. You can either go there from&lt;br /&gt;&lt;a href="http://eclipsefp.sf.net/"&gt;http://eclipsefp.sf.net/&lt;/a&gt; or directly: &lt;a href="http://eclipsefp.sf.net/cohatoe/"&gt;http://eclipsefp.sf.net/cohatoe/&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-4518476390178231564?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/4518476390178231564/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=4518476390178231564' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/4518476390178231564'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/4518476390178231564'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/08/next-steps-for-cohatoe.html' title='Next steps for Cohatoe'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-9029919086788111474</id><published>2007-07-06T18:27:00.000+02:00</published><updated>2007-07-06T18:28:57.600+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe talk at HaL 2</title><content type='html'>There will be another &lt;a href="http://iba-cg.de/haskell.html"&gt;Haskell in Leipzig (HaL)&lt;/a&gt; meeting next week, and I'll be there too and present Cohatoe. The whole idea and many of its technical features owe a lot to the discussion at the first HaL meeting, so I'm thrilled that I was asked to report on the progress there :-)&lt;br /&gt;&lt;br /&gt;So if you are are interested (and somewhere near Leipzig), why not drop by and have some fun?&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-9029919086788111474?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/9029919086788111474/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=9029919086788111474' title='4 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/9029919086788111474'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/9029919086788111474'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/07/cohatoe-talk-at-hal-2.html' title='Cohatoe talk at HaL 2'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>4</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-2442963278364399606</id><published>2007-04-29T17:04:00.000+02:00</published><updated>2008-12-09T02:08:01.681+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='development'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe extension wizardry</title><content type='html'>I have started to add some helpful tools to the Plugin Development Environment (PDE) in Eclipse to facilitate working with Cohatoe. One of the things that still take some time (in my experience when implementing the examples) is creating the source files and manifest entries that are needed for a new Haskell contribution via Cohatoe. It's not much (and mostly boilerplate that is always almost the same stuff), and it can actually be generated from very little input by the user.&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_BynttqNlK3w/RjS3qFIQqNI/AAAAAAAAAFQ/6FO2M68J1Lo/s1600-h/Clipboard02.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://3.bp.blogspot.com/_BynttqNlK3w/RjS3qFIQqNI/AAAAAAAAAFQ/6FO2M68J1Lo/s320/Clipboard02.png" alt="" id="BLOGGER_PHOTO_ID_5058870215003121874" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;So I have first added a wizard for creating a new Cohatoe extension. Suppose that you already have a plugin project. Then you can now just go to the Extensions Tab on the Plugin Manifest editor, click &lt;span style="font-weight: bold;"&gt;Add &gt; Extension Wizards &gt; Cohatoe Development Tools &gt; Haskell Contribution&lt;/span&gt;, and you get a wizard that generates all the files and manifest entries that you need, namely:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;It adds the dependency to the Cohatoe Core plugin to the &lt;code&gt;META-INF/Manifest.mf&lt;/code&gt; file (if it is not already there).&lt;/li&gt;&lt;li&gt;It adds an extension in the &lt;code&gt;plugin.xml&lt;/code&gt; file and declares the Haskell source file along with the Java implementation and interface types.&lt;br /&gt;&lt;/li&gt;&lt;li&gt;It generates the Java interface and implementation types, together with the code necessary to call the server (i.e. what happens inside the implementation class) and with a usage example that can be copied to where you want to call the function from your Java code.&lt;br /&gt;&lt;/li&gt;&lt;li&gt;It generates the skeleton source file for the Haskell module that is called.&lt;/li&gt;&lt;/ul&gt;The only things you have to specify are some workspace locations, in particular the source folder (there is usually only one, so that's probably trivial), a Java package name, and a name for your contribution, from which the name of the Haskell module and the Java types are derived.&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_BynttqNlK3w/RjS3ZVIQqMI/AAAAAAAAAFI/y794_b_7mqM/s1600-h/Clipboard01.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://4.bp.blogspot.com/_BynttqNlK3w/RjS3ZVIQqMI/AAAAAAAAAFI/y794_b_7mqM/s320/Clipboard01.png" alt="" id="BLOGGER_PHOTO_ID_5058869927240313026" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;For the time being, this supports only &lt;a href="http://cohatoe.blogspot.com/2007/04/contributing-source-files.html"&gt;contributing source files&lt;/a&gt;, if you want to change this into an object file contribution, you have to enter the path to the object files manually in the &lt;code&gt;plugin.xml&lt;/code&gt;, in the &lt;code&gt;codeFile&lt;/code&gt; attribute (where originally the source file is specified in what the wizard has generated).&lt;br /&gt;&lt;br /&gt;I think this should considerably ease and speed up the process of creating the plumbing for a new Haskell contribution, and help you to focus on the actually more interesting bits, namely the Haskell code itself, and the places where it is eventually called in the Eclipse plugin :-)&lt;br /&gt;&lt;br /&gt;(NB: this is not yet in the downloadable preview, but in the Darcs repo. But I think I'll do another preview build soon.)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-2442963278364399606?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/2442963278364399606/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=2442963278364399606' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2442963278364399606'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/2442963278364399606'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/04/cohatoe-extension-wizardry.html' title='Cohatoe extension wizardry'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://3.bp.blogspot.com/_BynttqNlK3w/RjS3qFIQqNI/AAAAAAAAAFQ/6FO2M68J1Lo/s72-c/Clipboard02.png' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-3394054074731021585</id><published>2007-04-22T17:12:00.000+02:00</published><updated>2007-04-22T17:19:02.834+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='architecture'/><title type='text'>Contributing source files</title><content type='html'>When working on new examples for Cohatoe, I noticed that it is still somewhat tedious to go through the usual cycle: write some code, compile and run it, make some changes, compile and run again ... One thing that makes it tedious is the need to compile the Haskell code into object files all the time.&lt;br /&gt;&lt;br /&gt;In order to make this nicer, I have extended Cohatoe to run Haskell code from contributed source files. (The actual work of compiling and loading the code is again done by hs-plugins.) You can now just put a Haskell source file into your plugin project, and declare it similarly to how you would have declared an object file.&lt;br /&gt;&lt;br /&gt;There a few rather minor details connected to that change I'm a little unhappy about. One is that I had to change the format of a Cohatoe extension in the &lt;code&gt;plugin.xml&lt;/code&gt; once more. Instead of a (mandatory) &lt;code&gt;objectFile&lt;/code&gt; attribute, the &lt;code&gt;haskellFunction&lt;/code&gt; has now a &lt;code&gt;codeFile&lt;/code&gt; attribute (which says nothing anymore about the content of the file). Whether we treat the file as a source code file or an object file is determined from the file extension. Currently recognized are &lt;code&gt;.o&lt;/code&gt; as extension for object files and &lt;code&gt;.hs&lt;/code&gt; and &lt;code&gt;.lhs&lt;/code&gt; for source files. The alternative would have been to keep the old &lt;code&gt;objectFile&lt;/code&gt; attribute and introduce a new one called &lt;code&gt;sourceFile&lt;/code&gt;. But that would have meant to make them both optional, and the only way to validate that exactly one of them was specified is then in the Java code that reads the extension. The current way has also the advantage that it can be easily extended to other types of contributed Haskell code (I'm in particular thinking of Haskell code that is compiled to JVM bytcode, e.g. via LambdaVM).&lt;br /&gt;&lt;br /&gt;On the downside, of course, that's one more API change which is annoying to any early adopters out there :-( Still I think it's better to make such changes now, that is, early in the cycle.&lt;br /&gt;&lt;br /&gt;Another less-than-optimal thing is that the &lt;code&gt;.o&lt;/code&gt; and &lt;code&gt;.hi&lt;/code&gt; files that hs-plugins generates before loading them end up in the same folder in which the original source file is. There is a number of situations where this could be a problem, including running from a jarred plugin, running from a write-protected folder, and so on. Cohatoe can handle a number of these situations transparently already, but very likely I have still overlooked one or the other. Therefore I regard this as a somewhat unfinished detail.&lt;br /&gt;&lt;br /&gt;Of course, the additional compilation step has an effect on the time needed when first accessing the function; in production mode you would probably still prefer a pre-compiled object file to contributing a source file.&lt;br /&gt;&lt;br /&gt;Looking at the bright side, this new possibility to run contributed Haskell code as source code will help to make life easier during development, and also make it easier to provide platform-independent functionality (always assuming that the code itself doesn't make any assumptions about the OS it runs on, in which case there is no way around keeping platform-specific code in one manner or the other).&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-3394054074731021585?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/3394054074731021585/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=3394054074731021585' title='6 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3394054074731021585'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3394054074731021585'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/04/contributing-source-files.html' title='Contributing source files'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>6</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-1132775571556461854</id><published>2007-04-05T08:35:00.000+02:00</published><updated>2007-04-05T10:50:03.454+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='haskell'/><category scheme='http://www.blogger.com/atom/ns#' term='development'/><category scheme='http://www.blogger.com/atom/ns#' term='tutorial'/><title type='text'>Unit testing in Haskell</title><content type='html'>Test-Driven-Development is a programming technique where you write small programs (test cases) in advance of coding the actual piece of software you want to write. If done well, this helps to clarify the various combinations of input/output/environment for your code, and makes it easier to implement it. As a nice extra, you speed up testing - all you have to do is to run all those test cases again, and they will point out whether everything still works as expected.&lt;br /&gt;&lt;br /&gt;So far so good. (And if you're coming from Java development, you know that song by heart anyway ;-). But can we do this in Haskell? Sure. There are actually two different well-supported approaches in Haskell to do test-driven development. One is more oriented towards functional programming, focusing on declaring properties of functions - this one is supported by &lt;a href="http://www.cs.chalmers.se/%7Erjmh/QuickCheck/"&gt;&lt;span class="blsp-spelling-error" id="SPELLING_ERROR_0"&gt;QuickCheck&lt;/span&gt;&lt;/a&gt; (and not covered in this post); the other is aligned with the 'classical' &lt;a href="http://junit.org/"&gt;&lt;span class="blsp-spelling-error" id="SPELLING_ERROR_1"&gt;JUnit&lt;/span&gt;&lt;/a&gt; tool. There is an implementation of this approach in the form of &lt;a href="http://hunit.sourceforge.net/"&gt;&lt;span class="blsp-spelling-error" id="SPELLING_ERROR_2"&gt;HUnit&lt;/span&gt;&lt;/a&gt;. I have written a &lt;a href="http://leiffrenzel.de/papers/getting-started-with-hunit.html"&gt;tutorial that gives an introduction to unit testing with &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_3"&gt;HUnit&lt;/span&gt;&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://cohatoe.blogspot.com/2007/03/command-line-options-in-haskell.html"&gt;Again&lt;/a&gt;, I would have have preferred to post the full text here, but that is too inconvenient with all the code listings. But you are welcome to comment on the tutorial here on this post.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-1132775571556461854?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/1132775571556461854/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=1132775571556461854' title='4 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1132775571556461854'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1132775571556461854'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/04/unit-testing-in-haskell.html' title='Unit testing in Haskell'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>4</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-5746186731677912942</id><published>2007-03-31T19:17:00.000+02:00</published><updated>2007-03-31T19:25:30.628+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='eclipsedarcs'/><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><title type='text'>EclipseDarcs 0.4 available</title><content type='html'>A new version of &lt;a href="http://eclipsedarcs.org"&gt;EclipseDarcs&lt;/a&gt;, the Darcs integration in the Eclipse IDE, is now available. This is version 0.4 (still a preview, or milestone, version).&lt;br /&gt;&lt;br /&gt;Thanks to Radek, we have now support for ssh repositories (note: this works only if you have passwordless login enabled, and on Windows you need the latest Darcs 1.0.9 release candidate build), and for pulling and pushing all patches from withing the workspace.&lt;br /&gt;&lt;br /&gt;I think this is a great step forward. We're still not yet quite feature complete, and there are some bugs, so please be patient for a little while longer :-)&lt;br /&gt;&lt;br /&gt;There are various options to get the latest version, please look at the &lt;a href="http://eclipsedarcs.org/doku.php?id=installationinstructions"&gt;installation instructions on the EclipseDarcs homepage&lt;/a&gt;. All feedback is very welcome. Enjoy.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-5746186731677912942?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/5746186731677912942/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=5746186731677912942' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5746186731677912942'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5746186731677912942'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/03/eclipsedarcs-04-available.html' title='EclipseDarcs 0.4 available'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-309501265579193679</id><published>2007-03-18T23:38:00.000+01:00</published><updated>2007-03-18T13:47:36.674+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='haskell'/><category scheme='http://www.blogger.com/atom/ns#' term='development'/><category scheme='http://www.blogger.com/atom/ns#' term='tutorial'/><title type='text'>Command-line options in Haskell</title><content type='html'>I'm currently writing a small command-line application, and one of the tasks that needs to be done in that context is handling of command line options. So I've learned the basics of handling command line options in Haskell, and have &lt;a href="http://leiffrenzel.de/papers/commandline-options-in-haskell.html"&gt;logged my results&lt;/a&gt;. Nothing in this post is my own idea, I have just collected what I found when looking around :-)&lt;br /&gt;&lt;br /&gt;My original intention was to post this as a regular blog entry here, but I did not manage to get the Haskell code listings properly formatted. I've tried systematically lots of combinations of the HTML 'code' and 'pre' tags, nbsp escapes and so on - nothing worked. Finally I gave up and put it all into a separate page.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-309501265579193679?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/309501265579193679/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=309501265579193679' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/309501265579193679'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/309501265579193679'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/03/command-line-options-in-haskell.html' title='Command-line options in Haskell'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-6375169530604215841</id><published>2007-03-16T07:34:00.000+01:00</published><updated>2007-03-16T07:46:33.672+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.3 preview</title><content type='html'>The next preview of Cohatoe is now available from the download page, from the update site, and in the Darcs repository (all to be found &lt;a href="http://leiffrenzel.de/eclipse/cohatoe/"&gt;here&lt;/a&gt;). The usual disclaimer (experimental state etc.) applies as before, but my feeling is that it is getting nearer some state where one can actually start some serious playing around with it. (I'm especially hopeful that there will be fewer API changes from now on.)&lt;br /&gt;&lt;br /&gt;I have left out all the &lt;a href="http://cohatoe.blogspot.com/2007/03/progress-on-progress.html"&gt;progress monitoring stuff&lt;/a&gt; I wrote about, but I have re-worked the Cohatoe API to &lt;a href="http://cohatoe.blogspot.com/2007/02/about-losing-purity.html"&gt;execute Haskell functions within the IO monad&lt;/a&gt;. This means that the main entry point for Haskell code that is contributed in an Eclipse plugin (&lt;code&gt;pluginMain&lt;/code&gt;, as declared in the Cohatoe API) is now of type &lt;code&gt;[String] -&gt; IO [String]&lt;/code&gt;. Please note that you have to re-compile any object code against that new API in order to run with the new version of the plugins.&lt;br /&gt;&lt;br /&gt;Another important piece that is now in place is exception handling.  Several sorts of exceptions that are raised during the execution of contributed Haskell code are caught and re-raised on the Eclipse side - instead of just making the server executable break and exit. This makes Cohatoe much more robust.&lt;br /&gt;&lt;br /&gt;Any feedback is most welcome - have fun :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-6375169530604215841?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/6375169530604215841/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=6375169530604215841' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6375169530604215841'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6375169530604215841'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/03/cohatoe-03-preview.html' title='Cohatoe 0.3 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-3824574251925824784</id><published>2007-03-14T06:35:00.000+01:00</published><updated>2007-03-14T06:36:47.829+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='eclipsedarcs'/><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><title type='text'>EclipseDarcs 0.3 available</title><content type='html'>A new version of &lt;a href="http://eclipsedarcs.org"&gt;EclipseDarcs&lt;/a&gt;, the Eclipse IDE support for the Darcs RCS, is now &lt;a href="http://eclipsedarcs.org/doku.php?id=installationinstructions"&gt;available&lt;/a&gt;. This is version 0.3. It is still a preview (milestone) version, and it contains mostly several fixes and minor improvements that have been done over the past months since the 0.2 release. (But watch out for more soon, there are things happening at the moment :-).&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-3824574251925824784?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/3824574251925824784/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=3824574251925824784' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3824574251925824784'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3824574251925824784'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/03/eclipsedarcs-03-available.html' title='EclipseDarcs 0.3 available'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-847226463305956295</id><published>2007-03-13T07:21:00.000+01:00</published><updated>2007-03-13T07:26:19.204+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='architecture'/><title type='text'>Progress on Progress?</title><content type='html'>In the past few days, I have been exploring a side alley of the main topics in Cohatoe: progress monitoring. I think it would be actually nice to have something like a progress monitor API on the Haskell side so that you can send back progress feedback to the omnipresent progress dialogs in Eclipse (and by the way, Eclipse users are very much used to a responsive UI that allows them to send everything into the background that takes more than a few hundred milliseconds time). So I poked around in that area for a while. But it looks as if I have hit a dead end.&lt;br /&gt;&lt;br /&gt;On the Java side, taking progress messages and pass them on to an &lt;code&gt;IProgressMonitor&lt;/code&gt; instance isn't a real problem (although it took a bit to implement, mostly for the message encoding and decoding). But I'm somewhat stuck on the Haskell side.&lt;br /&gt;&lt;br /&gt;Once more, this is more a question of API design than anything else. I don't think there would be a problem at all if we would in general pass a progress monitor 'handle' to the main entry point function. An example would then look like so:&lt;pre&gt;&lt;code&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;import&lt;/span&gt; Cohatoe.API&lt;br /&gt;&lt;br /&gt;resource = plugin {&lt;br /&gt; pluginMain = sayHello&lt;br /&gt;}&lt;br /&gt;&lt;br /&gt;sayHello :: ProgressMonitor -&gt; [String] -&gt; [String]&lt;br /&gt;sayHello _ _ = ["Hello from Haskell"]&lt;/code&gt;&lt;/pre&gt;that is, adding another parameter to the signature of the main entry point function. The progress monitor type would be declared by the Cohatoe API, and the framework would actually create a channel behind that value that sends all progress feedback to the Eclipse side.&lt;br /&gt;&lt;br /&gt;However, I'm uneasy with that. True, there will be a lot of occasions where it makes sense to send progress feedback, but there will be as may where it seems not necessary. Of course, in these cases one can always ignore the progress monitor argument, but it still seems not nice to me to make it a part of the function signature everytime. I would very much more like something similar to this&lt;br /&gt;&lt;pre&gt;&lt;code&gt;myFunction :: [String] -&gt; IO [String]&lt;br /&gt;myFunction args = &lt;span style="font-weight: bold;"&gt;do&lt;/span&gt;&lt;br /&gt; pm &lt;- getProgressMonitor&lt;br /&gt; pmBegin pm "Starting" 100&lt;br /&gt; &lt;span style="color: rgb(51, 51, 255);"&gt;-- actually do something&lt;/span&gt;&lt;br /&gt; pmDone pm&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;But then where to get the progress monitor from? I have tried some approaches that seemed to lead nowhere. I suspect I could do it by designing my own monad, but I'm not deep enough into Haskell yet to do that :-) And I also can't see how that would keep the API neat. So I think for now I'll leave the progress monitoring out in the interest of simplicity and revert the code base.&lt;br /&gt;&lt;br /&gt;(Btw, this was more of an experiment anyway; I don't think that it is a good idea in general to re-model the Eclipse APIs, such as the progress monitors, in Haskell. That's far too much work, and there is a limit anyway, since the Eclipse APIs really assume to be dealing with stateful objects all the time. I've written a bit more about that in my earlier &lt;a href="http://eclipsefp.sourceforge.net/haskell/ExtendingEclipseInHaskell.pdf"&gt;contribution to the Eclipse Languages Symposium&lt;/a&gt;.)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-847226463305956295?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/847226463305956295/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=847226463305956295' title='3 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/847226463305956295'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/847226463305956295'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/03/progress-on-progress.html' title='Progress on Progress?'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>3</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-3997100519480695533</id><published>2007-03-09T04:22:00.000+01:00</published><updated>2007-03-09T04:50:18.289+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='eclipsedarcs'/><category scheme='http://www.blogger.com/atom/ns#' term='darcs'/><title type='text'>Using Darcs (and EclipseDarcs)</title><content type='html'>Radek Grzanka has asked, on the &lt;a href="http://sourceforge.net/mailarchive/forum.php?forum=eclipsedarcs-develop"&gt;EclipseDarcs mailing list&lt;/a&gt;, whether I could share some experiences using Darcs in my programming team (and I'm happy to do so :-). I have introduced Darcs to my team about one and a half year ago when we started to do some projects that involved developers sitting in locations other than our office in Karlsruhe, Germany (including external developers who were located in the US), and which also involved people who are, like I was myself at the time, frequently travelling.&lt;br /&gt;&lt;br /&gt;For me this is one important plus for Darcs: that it allows fine control over what goes into the repository while being offline (on the train, on the plane, or in a Hotel room that hasn't internet access). With source code control systems that require the presence of a server you can check in less frequently, and therefore you tend to either check in too coarse-grained, or you spend much more time figuring out which source changes belonged to which activity when you are checking in. With Darcs, on the other hand, you can code, then record, then code, record and so on, and when you go online the next time, you can still push selectively.&lt;br /&gt;&lt;br /&gt;The teams we are working in are relatively small (up to six people, with some fluctuation), so I couldn't say much on how it works with really big teams. But for us it worked out really well. Darcs is pretty easy to learn and also definitely fun to work with, and that was consistently the feedback I got from all developers. (It also has the occasional bug or sluggishness, especially on Windows, but that's far short of the big-time sucking that CVS can be, in my experience.)&lt;br /&gt;&lt;br /&gt;Darcs is also helpful with branching, which we do a reasonable amount of. However, in this area one still needs some tools or techniques around it, mostly for figuring out diffs between branches. This is one of the areas where EclipseDarcs comes in very handy, namely the repository browsing perspective that allows to conveniently inspect patches. (I have also started work on a repo diff view for the Darcs repository browsing perspective, exactly from this background.) The most needed tool there is a viewer that supports viewing patch dependencies. For instance, imagine you have one release repository and one development repository. The latter holds a bunch of patches which are not yet in the release repository. Someone has the job to 'release' some patches from the development repo to the release repo. So it is important for that guy to see which patches depend on which others, in order to figure out what minimally must be pushed.&lt;br /&gt;&lt;br /&gt;We typically have one central repository on an intranet server that we call the integration repo, or development repo. Developers work on local repos on their machines, and record changes there. All our work items, bug fixes and tasks that we do are structured in an issue tracker. So typically, when somebody has done some implementation task, that's associated with an issue tracker ID and recorded so (stating the issues tracker ID first thing in the patch comment). After that, it is usually either pushed to the integration repo, or sent to another developer who reviews it and then pushes it. On the integration repo, we have automated processes that build, collect compiler warnings, run CheckStyle, run JUnit, run PDE JUnit and so on. That way, we get early feedback about integration problems (that is, problems that go further than simple conflicts in the source text). This sort of setup is relatively common today (much more so than when we introduced it, some five years ago), and often called 'continuous integration'. It is one of the most valuable practices in software development in my view; however, it requires a certain insight and co-operation from the team. (As with many of these so-called 'agile' practices, the people in your team need to understand and value them - else they won't work much better than any other methodologies.) In our practice, we try to push and pull as often as possible (several times a day). This helps to have the entire team up-to-date with recent changes to the code base, and reduces the chance of integration problems.&lt;br /&gt;&lt;br /&gt;In addition to the integration repo, we have branches that hold the released versions. In some cases, they are just subsets of the corresponding integration repo (the latter one holds more patches because some functionality is not yet mature enough to be released to the public, but ok to be integrated with the rest of the code base). In some cases, they are real functionality branches (branches of the main stem that contain some different functionality, e.g. for deployment of a customized version). Naturally, we try to keep the second variant rare - but in my view it is definitely more pleasant to do this with Darcs than with other systems I've worked with.&lt;br /&gt;&lt;br /&gt;And of course we have also learned to love such techniques as those which are described on the Darcs wiki as &lt;a href="http://darcs.net/DarcsWiki/SpontaneousBranches"&gt;spontaneous branches&lt;/a&gt; and &lt;a href="http://darcs.net/DarcsWiki/PreparationBranches"&gt;preparation branches&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;We use EclipseDarcs together with the Darcs command line (the latter one for more complicated recording that spans over multiple files, and for pulling and pushing). EclipseDarcs comes in helpful for inspecting repo contents (as I remarked above), and for adding files, quickly recording single-file changes, and it helps of course by showing which files in the repo have changed since the last recording. Well - and we all know that there is plenty of room for improvement :-) It would be nice to be able some day to have all Darcs functionality integrated in Eclipse, of course. We're only half-way there. But while that is a little inconvenient, I don't think it really should be a reason not to use Darcs. For one thing, the command line interface of Darcs is very convenient, and apart from that I'm convinced that a professional programmer should be able to use a command line tool.&lt;br /&gt;&lt;br /&gt;The source trees we work on are almost always Eclipse Plug-In projects. This is a bit nasty when the contents of a repository must be imported into the workspace for the first time. (Especially because the contents of the pristine tree, under &lt;code&gt;_darcs/pristine/&lt;/code&gt;, are detected by Eclipse and offered as projects to import; one must be very careful not to select these - the best technique for this is to temporarily move the entire &lt;code&gt;_darcs&lt;/code&gt; folder out of the repository, import the projects all at once, and move the &lt;code&gt;_darcs&lt;/code&gt; folder back.) On the other hand, this tends naturally to a well-structured and fine-grained organization of the source tree, which helps when recording, and probably also helps with the Darcs performance. For our purposes, the performance is ok (but again, that pretty much depends on the layout and size of your source trees).&lt;br /&gt;&lt;br /&gt;Perhaps one or two more misc notes: one should checkpoint repos from time to time, it really helps to reduce the time to initially get repo contents. (It is also definitely faster to use &lt;code&gt;darcs get&lt;/code&gt; instead of &lt;code&gt;darcs init &amp;&amp;amp; darcs pull --all&lt;/code&gt;, but that's probably old news :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-3997100519480695533?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/3997100519480695533/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=3997100519480695533' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3997100519480695533'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3997100519480695533'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/03/using-darcs-and-eclipsedarcs.html' title='Using Darcs (and EclipseDarcs)'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-1069268053922719290</id><published>2007-03-04T12:48:00.000+01:00</published><updated>2007-03-04T12:56:32.732+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='eclipse'/><title type='text'>A focused braindump</title><content type='html'>Over the last months, I have written an &lt;a href="http://leiffrenzel.de/papers/feature-relationships.pdf"&gt;informal paper&lt;/a&gt; about some of the more arcane details of Eclipse technology, related to its update/install story. Currently, the approach in this area is based on so-called 'features' (roughly groups of plugins, which in turn are the functional units in Eclipse). The paper gives an overview over the different relationships that can obtain between features, and exposes some problems in the logical system that emerges from these relationships. It also highlights some issues that have arisen in the real-world use of the features approach.&lt;br /&gt;&lt;br /&gt;My goal was to collect some thoughts that I have posted to mailing lists and points I made in technical discussions, mainly to have them all in one place. There is an ongoing discussion at the Eclipse project about this topic, and about replacing the features-approach in future versions of Eclipse, so hopefully this is somewhat useful for summarizing a few lessons learned. I’m confident that the problems described here will soon be a thing of the past.&lt;br /&gt;&lt;br /&gt;Btw, if you are interested in the latest developments, here are a few pointers: the &lt;a href="http://wiki.eclipse.org/index.php/Requirements_for_a_new_update_manager"&gt;requirements pool for a new Update Manager&lt;/a&gt;, the &lt;a href="http://www.eclipse.org/equinox/incubator/provisioning/proposal.php"&gt;Equinox provisioning project proposal&lt;/a&gt;, the &lt;a href="http://www.eclipse.org/proposals/maya/"&gt;Maya project proposal&lt;/a&gt; (somehwat related), and the &lt;a href="http://www.eclipse.org/epp/"&gt;Eclipse Packaging Project homepage&lt;/a&gt; (dito).&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-1069268053922719290?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/1069268053922719290/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=1069268053922719290' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1069268053922719290'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1069268053922719290'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/03/focused-braindump.html' title='A focused braindump'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-8990594584862839160</id><published>2007-02-25T17:45:00.000+01:00</published><updated>2007-02-25T17:47:41.480+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='architecture'/><title type='text'>About losing purity</title><content type='html'>Just so you don't think I've migrated to the Humanities Department - even though the last posts were about history, I'll finally get back to the technical stuff ;-) I'm currently working on a new example and a few API enhancements. Here's a few thoughts about a minor issue on the side:&lt;br /&gt;&lt;br /&gt;When you are contributing Haskell code to Eclipse, via Cohatoe, the entry point so far had to look something like this (taken from the HelloWorld example):&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&lt;span style="font-weight: bold;"&gt;import &lt;/span&gt;Cohatoe.API&lt;br /&gt;&lt;br /&gt;resource = plugin {&lt;br /&gt; pluginMain = sayHello&lt;br /&gt;}&lt;br /&gt;&lt;br /&gt;sayHello :: [String] -&gt; [String]&lt;br /&gt;&lt;span style="color: rgb(0, 0, 153);"&gt;-- and here goes your implementation of HelloWorld&lt;/span&gt;&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;I have been pondering for a while the question of purity in this. While I somewhat like having a pure function here (&lt;code&gt;[String] -&gt; [String]&lt;/code&gt;), I think for real world code what we want is rather something in the IO monad. This is not a technical problem (the code that loads &lt;code&gt;pluginMain&lt;/code&gt; and executes it is in the IO monad anyway). It is just a question of API design. I think that in many cases the Haskell code will be used for doing things like reading source files, writing indices, and other such things that must be done in an IO action.&lt;br /&gt;&lt;br /&gt;I have thought about enabling both (by passing, on the Java side, some flag that requests running in IO, or perhaps by making it something that you have to declare in the &lt;code&gt;plugin.xml&lt;/code&gt;). However, this would load some more work on the user of the API, and I'd rather put a premium on simplicity here, seeing that we want to encourage programmers who don't know much about (or don't care much for) the Java and Eclipse side of things here. And Haskell programmers are used to having an entry point in the IO monad: the &lt;code&gt;main&lt;/code&gt; function in every Haskell program is.&lt;br /&gt;&lt;br /&gt;So, that settles it, from version 0.3 &lt;code&gt;pluginMain&lt;/code&gt; will be of type &lt;code&gt;[String] -&gt; IO [String]&lt;/code&gt; :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-8990594584862839160?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/8990594584862839160/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=8990594584862839160' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/8990594584862839160'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/8990594584862839160'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/02/about-losing-purity.html' title='About losing purity'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-1017190917230105398</id><published>2007-01-28T11:36:00.000+01:00</published><updated>2007-01-28T11:37:58.991+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='haskell'/><category scheme='http://www.blogger.com/atom/ns#' term='eclipsefp'/><title type='text'>History of Haskell</title><content type='html'>Simon Peyton Jones has &lt;a href="http://www.haskell.org/pipermail/haskell/2007-January/019041.html"&gt;announced&lt;/a&gt; the final version of the &lt;a href="http://research.microsoft.com/~simonpj/papers/history-of-haskell/index.htm"&gt;History of Haskell paper&lt;/a&gt; that he has written together with Paul Hudak, John Hughes and Philip Wadler. It is a longish text, but a great read, especially if you have (like me) only started with Haskell in the recent few years.&lt;br /&gt;&lt;br /&gt;(EclipseFP is also mentioned in the section about development tools :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-1017190917230105398?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/1017190917230105398/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=1017190917230105398' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1017190917230105398'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1017190917230105398'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/01/history-of-haskell.html' title='History of Haskell'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-5728078945363229337</id><published>2007-01-13T00:12:00.000+01:00</published><updated>2007-01-13T00:26:21.010+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Some history</title><content type='html'>(This is not technical today but more a piece of personal history. I'm describing some of my background that led me to start the Cohatoe project.)&lt;br /&gt;&lt;br /&gt;One of the key motivations for me to develop Cohatoe came from my experiences in the EclipseFP project. EclipseFP implements a set of plugins that support functional programming in the Eclipse IDE. Originally initiated by me, it has meanwhile got a momentum of its own, and there are a number of people who contribute to it. There is some support for OCaml (currently unmaintained and on hold), but the bulk of the functionality is for supporting Haskell development. When I started the EclipseFP project, I was about to learn Haskell, and coming from a Java background, I wanted to have Eclipse support similar to the one that existed for Java. There was no Eclipse plugin for Haskell, so I decided to write my own. (That was a bit of an unclever decision: I ended up with investing more time writing Eclipse code than actually using it for learning to write Haskell code ;-)&lt;br /&gt;&lt;br /&gt;Usually, if one starts to develop language support in Eclipse, the first thing is to create a source code editor with some syntax coloring; perhaps some minimal Code Assist (automatic code completion) for keywords; a project type and some wizards that support the creation of source files; and a compiler integration that drives a build when files are saved and reports compiler errors and warnings as 'markers' (which show up in the Problems View and as line annotations in the code).&lt;br /&gt;&lt;br /&gt;All these things are pretty easily done, and they can be implemented in Java without a lot of knowledge about the target language specifics going into that code. For instance, for syntax coloring, a simple set of coloring rules (e.g.: apply the comment color from the occurence of '--' until the end of the line) is enough to reasonably color Haskell source files without even actually knowing about the exact syntactical structure of Haskell source code. Eclipse's APIs provide good support for doing these things, and it is not too difficult or too much effort to get some Eclipse-based IDE up and running using them.&lt;br /&gt;&lt;br /&gt;However, Eclipse's own Java Development Tools (JDT) have a lot of functionality that cannot be done without building some deep understanding of the language into the code. Here are some examples:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;&lt;b&gt;&lt;i&gt;Mark Occurrences&lt;/i&gt;&lt;/b&gt;: given a source file and the cursor positioned on some identifier (e.g. in a call to a function), highlight all other occurrences of that identifier in the editor - and of course do not count just any occurrences of the same string of characters, but only those which actually &lt;i&gt;are&lt;/i&gt; the same identifier; don't highlight them in comments, or occurrences of local variables with the same name in a different scope.&lt;/li&gt;&lt;li&gt;&lt;b&gt;&lt;i&gt;Source Outline&lt;/i&gt;&lt;/b&gt; and &lt;i&gt;&lt;b&gt;Code Folding&lt;/b&gt;&lt;/i&gt;: In the Outline View, there is a tree that represents the language elements (type declarations, field declarations, method declarations etc.) from the source code in the editor; and that tree can be used to navigate the code quickly and even change it (for example, deleting or moving field declarations). Code folding allows to collapse regions of the code (for instance a long comment at the top of the source file) into a single line to make the code more easy to read.&lt;/li&gt;&lt;li&gt;&lt;b&gt;&lt;i&gt;Refactoring&lt;/i&gt;&lt;/b&gt;: there are a lot of automated refactorings, like the simple &lt;i&gt;Rename&lt;/i&gt; (of a method or type), which not only changes the type name in the source code, but also adjusts all code that refers to it, and also renames source files accordingly, or more complicated ones such as &lt;i&gt;Extract Method&lt;/i&gt;, which allows to isolate a block of code and put it into a newly created method.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;Such things usually require analysis of the source code as it is done by compilers and other tools.&lt;br /&gt;&lt;br /&gt;(I have written a more extensive article about the topic of &lt;a href="http://www.sigs-datacom.de/sd/publications/pub_article_show.htm?&amp;AID=1751&amp;amp;TABLE=sd_article"&gt;how much language-specific code is needed for which functionalities of an Eclipse-based IDE&lt;/a&gt; - it was written for a German journal, and is therefore in German, so you will unfortunately only be able to read it if you understand that language. My co-author, Markus Barchfeld, is a committer on the &lt;a href="http://rubyeclipse.sourceforge.net/"&gt;Ruby Development Tools, RDT&lt;/a&gt;, and he has made some similar experiences there like the ones I'm describing here.)&lt;br /&gt;&lt;br /&gt;There is plainly no chance of re-implementing all this in Java for a language such as Haskell. (The JDT team was in the enviable position to be able to write their own Java compiler and in addition to use their own tool for building itself.) Therefore, the only sensible way of getting deeper integration would be to somehow re-use existing code that does the job. And happily, all that code exists, is free and could be used for an Eclipse-based IDE (think of the GHC API, HaRe, the Haskell Refactorer, and many other Haskell development tools). It is just necessary to find a way to use Haskell code in an Eclipse plugin without too much hassle and compromise.&lt;br /&gt;&lt;br /&gt;This is what I hope to achieve with Cohatoe. On the way so far I have tried a number of different approaches, and I have discussed it with many people, notably the people on the EclipseFP mailing list. EclipseFP is now maintained by Thiago Arrais. Thiago has written a Haskell parser that does already a pretty cool job in supporting Code Assist and other helpers in the Haskell source editor. It has replaced an earlier approach of mine which used the Haskell parser from the &lt;code&gt;haskell-src&lt;/code&gt; package in the standard libraries, and accessed it via FFI and JNI (Haskell's and Java's respective foreign and native interfaces). That approach had proved to be somewhat unstable (not the parser, but my code that drove it) and had the decisive disadvantage of working only on Windows (because it required the Haskell code to be run in a dll). I also wrote a &lt;a href="http://eclipsefp.sourceforge.net/haskell/ExtendingEclipseInHaskell.pdf"&gt;contribution to the Eclipse Languages Symposium&lt;/a&gt; about a year ago. All this, however, left me a bit frustrated. Somehow I wasn't gettting the feeling that real progress could be made with all the approaches that I had tried.&lt;br /&gt;&lt;br /&gt;When I was at the Haskell in Leipzig meeting last year, however, there was a very engaged discussion, and I decided to have another stab at the problem; I'd like to thank the participants in that meeting, and in particular Johannes Waldmann, for this very encouraging debate. This time I think I have made some progress, and it seems that is mostly thanks to a change in perspective. I'm focusing more on the programming model this time, instead of thinking in terms of choosing a technology that is able to make the connection between the Haskell code and the Java code that runs inside Eclipse. The goal is to design both the Haskell side and the Eclipse side of things in Cohatoe so that developers find themselves at home on either side, no distortion or unwieldy constructs, or extra efforts necessary. So far, this has worked out fine, so let's see what happens next :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-5728078945363229337?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/5728078945363229337/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=5728078945363229337' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5728078945363229337'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/5728078945363229337'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/01/some-history.html' title='Some history'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-4497316901977155182</id><published>2007-01-07T17:38:00.000+01:00</published><updated>2008-12-09T02:08:01.971+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.2 preview</title><content type='html'>I have just released another preview version of Cohatoe. It contains a number of improvements and a cool new example.&lt;br /&gt;&lt;br /&gt;As before, please keep in mind that this is still experimental and the APIs are bound to change a few times more. Actually, a rather severe change has been made already in 0.2 to the format of the &lt;code&gt;plugin.xml&lt;/code&gt; when declaring a Haskell function (see below). (I promise I will stop doing such things of course once the APIs are more mature ;-).&lt;br /&gt;&lt;br /&gt;There is now a changelog file in the SDK feature, where you can check what is new in which versions. The changelog is cumulative and contains all changes since the very beginning. In what follows, I'm giving a commented version of the changelog contents.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Declaring Haskell functions&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;As I mentioned, there have been changes to the schema of the &lt;code&gt;haskellFunctions&lt;/code&gt; extension point (in the plugin  &lt;code&gt;de.leiffrenzel.cohatoe.server.core&lt;/code&gt; The attribute &lt;code&gt;objectCode&lt;/code&gt; has been renamed to &lt;code&gt;objectFile&lt;/code&gt;. This means that all &lt;code&gt;plugin.xml&lt;/code&gt; declarations that use this extension point must be updated.&lt;br /&gt;&lt;br /&gt;The old attribute is left in and  tagged as deprecated, so that uses of the old format can be detected more easily. It will be removed in 0.3. That the attribute is still there doesn't mean that it still works, however. Eclipse will give a warning for each occurrence, so I have decided to leave it in. But the Cohatoe code doesn't read it anymore.&lt;br /&gt;&lt;br /&gt;For situations where the Haskell code that you want to call is distributed over multiple modules, and you would consequently have more than one object file to declare, I have added some support. In the case where your modules are all in the same folder as the declared &lt;code&gt;.o&lt;/code&gt; file, Cohatoe makes sure that they all are passed to hs-plugins, which will be able to load them. In the case where your object files are in a &lt;i&gt;different&lt;/i&gt; folder (inside the plugin's directory structure, of course), you can specify that folder in the &lt;code&gt;plugin.xml&lt;/code&gt;. Here is an example (taken from my unit test cases):&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&amp;lt;haskellFunction&lt;br /&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt;implementation=&lt;span style="color: rgb(51, 51, 255);"&gt;"de.leiffrenzel.cohatoe.server.core.test.functions.MultiFolderModule"&lt;/span&gt;&lt;br /&gt;&lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt;interface=&lt;span style="color: rgb(51, 51, 255);"&gt;"de.leiffrenzel.cohatoe.server.core.test.functions.IMultiFolderModule"&lt;/span&gt;&lt;br /&gt;&lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt;name=&lt;span style="color: rgb(51, 51, 255);"&gt;"Multi-modules in different folders"&lt;/span&gt;&lt;br /&gt;&lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt;objectFile=&lt;span style="color: rgb(51, 51, 255);"&gt;"$os$/obj/MultiFolderModule1.o"&lt;/span&gt;&amp;gt;&lt;br /&gt;&lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt;&amp;lt;objectCodeFolder&amp;gt;$os$/obj2/&amp;lt;/objectCodeFolder&amp;gt;&lt;br /&gt;&amp;lt;/haskellFunction&amp;gt;&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;There may be zero or more &lt;code&gt;objectCodeFolder&lt;/code&gt; elements inside a &lt;code&gt;haskellFunction&lt;/code&gt; element in your declarations now, each of which can declare a plugin-relative path, and all these paths are resolved and passed to the Haskell side where they are used for tracking module dependencies. (As usual, this works also when plugins are deployed and live in a &lt;code&gt;.jar&lt;/code&gt; file.)&lt;br /&gt;&lt;br /&gt;I'm planning to add further support for &lt;i&gt;packages&lt;/i&gt; of object files (as created by the archiver tool). You will be able to declare these packages in a similar manner, but that support is not yet included as of version 0.2.&lt;br /&gt;&lt;br /&gt;Next, I have added some helpful functions that can be used for marshalling data to the Haskell side and unmarshalling the results back. They are located in the class &lt;code&gt;CohatoeUtils&lt;/code&gt;. Actually, they were already available in version 0.1, but there they were not well organized, well named and not even completely implemented. I've done a bit in that area, too.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Error handling&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;I have also started to improve Cohatoe in the area of error handling. This belongs to the large topic of robustness. Since Cohatoe will execute &lt;i&gt;any&lt;/i&gt; Haskell code, it is important that its functioning is not impaired by code that crashes or perhaps is even malicious. Currently, a problem inside contributed code will cause the Haskell server executable to exit, and a restart of Eclipse is needed to get it working again. That is of course not acceptable, and so I have started to tackle the possibly problematic situations one by one.&lt;br /&gt;&lt;br /&gt;The first case, the one that is now handled by Cohatoe, is when your contributed Haskell code calls the &lt;code&gt;Prelude.error&lt;/code&gt; function. This will now no longer break the server, but is instead caught at the Haskell side and reported to the Eclipse side, where the exception is re-thrown as a &lt;code&gt;CohatoeException&lt;/code&gt;.&lt;br /&gt;&lt;br /&gt;The exception type (&lt;code&gt;CohatoeException&lt;/code&gt;) is a subtype of Eclipse's &lt;code&gt;CoreException&lt;/code&gt;, and it carries some useful information in addition to the usual Java exception information. It contains the error message that was used on the Haskell side, and it also knows the plugin identifier of the plugin that contributed the code which has caused the exception.&lt;br /&gt;&lt;br /&gt;Since it is a &lt;code&gt;CoreException&lt;/code&gt;, it also contains an Eclipse &lt;code&gt;IStatus&lt;/code&gt; object that you can conveniently write to the workspace log, like so:&lt;br /&gt;&lt;pre&gt;&lt;span style="font-weight: bold;"&gt;try&lt;/span&gt; {&lt;br /&gt;&lt;span style="color: rgb(0, 153, 0);"&gt;  // ...&lt;/span&gt;&lt;br /&gt;} &lt;span style="font-weight: bold;"&gt;catch&lt;/span&gt;( &lt;span style="font-weight: bold;"&gt;final &lt;/span&gt;CohatoeException cohex ) {&lt;br /&gt;&lt;span style="color: rgb(0, 153, 0);"&gt;  // we don't handle this here, just &lt;/span&gt;&lt;br /&gt;&lt;span style="color: rgb(0, 153, 0);"&gt;  // write it to the workspace log&lt;/span&gt;&lt;br /&gt;  CohatoeExamplesPlugin plugin = CohatoeExamplesPlugin.getDefault();&lt;br /&gt;  plugin.getLog().log( cohex.getStatus() );&lt;br /&gt;}&lt;br /&gt;&lt;/pre&gt;The exception knows also an identifier for the type of exception that was raised. I want to use that for distinguishing between calls to the &lt;code&gt;error&lt;/code&gt; function and other types of errors, such as IO Errors, or problems that occured when hs-plugins tried to load code it couldn't. But that is not yet in - currently only &lt;code&gt;Prelude.error&lt;/code&gt; is handled by Cohatoe.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;New example - Sudoku solver&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;A new example has been introduced: a Sudoku solver View. The View can be found via the menu &lt;b&gt;Window &gt; Show View &gt; Cohatoe Examples&lt;/b&gt;. The Haskell code that does the actual work is a Sudoku solver written by Graham Hutton which can be found at &lt;a href="http://www.cs.nott.ac.uk/%7Egmh/sudoku.lhs"&gt;http://www.cs.nott.ac.uk/~gmh/sudoku.lhs&lt;/a&gt; (thanks to Graham for giving permission to include this code :-).&lt;br /&gt;&lt;br /&gt;This example demonstrates how Haskell code is handled that spans more than just one object file (more background discussion can be found at in &lt;a href="http://cohatoe.blogspot.com/2006/12/code-in-multiple-modules.html"&gt;my earlier post about module dependencies in multiple modules&lt;/a&gt;), and it also gives an example for accessing multiple Haskell functions through a single interface on the Java side.&lt;br /&gt;&lt;br /&gt;I will comment this example in more detail in one of my next posts, but I want to give you at least a screenshot here:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_BynttqNlK3w/RaEkY87w5NI/AAAAAAAAADY/J1Ki_UJ_hcY/s1600-h/Clipboard02.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://3.bp.blogspot.com/_BynttqNlK3w/RaEkY87w5NI/AAAAAAAAADY/J1Ki_UJ_hcY/s320/Clipboard02.png" alt="" id="BLOGGER_PHOTO_ID_5017331470959699154" border="0" /&gt;&lt;/a&gt;That's it from me for now - have fun! Any feedback is very welcome.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-4497316901977155182?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/4497316901977155182/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=4497316901977155182' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/4497316901977155182'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/4497316901977155182'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/01/cohatoe-02-preview.html' title='Cohatoe 0.2 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://3.bp.blogspot.com/_BynttqNlK3w/RaEkY87w5NI/AAAAAAAAADY/J1Ki_UJ_hcY/s72-c/Clipboard02.png' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-8771177286940528326</id><published>2007-01-06T15:00:00.000+01:00</published><updated>2008-12-09T02:08:02.513+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='development'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='architecture'/><title type='text'>Building a server executable</title><content type='html'>Part of the Cohatoe architecture is the Cohatoe server. On the Eclipse side it is represented by a singleton object (of class &lt;code&gt;de.leiffrenzel.cohatoe.server.core.CohatoeServer&lt;/code&gt;), where clients can access it. The server runs in a separate process, and the singleton on the Java side communicates with it via a socket connection. It is implemented in Haskell, and it is able to locate object code that has been contributed via Cohatoe, load and execute it (using hs-plugins).&lt;br /&gt;&lt;br /&gt;That the server is implemented in Haskell means also that it has to be compiled into a native executable, which is of course a different one for each supported OS/WS platform. Currently, that is only Windows (strictly speaking: only 32 bit Windows). But the mechanisms for supporting other platforms are there (mostly provided by Eclipse already), and the Haskell code for the server does not make use of platform specifics (as far as I can see). Cohatoe will automatically locate the correct executable for the platform it runs on (if one is there). Therefore, the only thing that is needed is to build the executable for all the  other platforms. In what follows, I'll describe how to do this and explain a few background details on the way.&lt;br /&gt;&lt;br /&gt;The Haskell source code for the Cohatoe server is located in the plugin &lt;code&gt;de.leiffrenzel.cohatoe.server.core&lt;/code&gt;, in the directory &lt;code&gt;INTERNAL/hs/src/&lt;/code&gt;. The native executables for the various platforms (i.e. Windows, Linux/GTK, MacOSX etc.)  do not reside  in the same plugin. Instead, they are contained in &lt;i&gt;fragments&lt;/i&gt;. Fragments are a special concept in Eclipse's plugin architecture. (They have also recently become part of the OSGi specification, which is implemented by the Eclipse runtime.)&lt;br /&gt;&lt;br /&gt;A fragment is, like a plugin, an OSGi &lt;i&gt;bundle&lt;/i&gt;. In the workspace, it lives as a &lt;i&gt;fragment project&lt;/i&gt; (instead of as a plugin project), and it contains a &lt;code&gt;fragment.xml&lt;/code&gt; instead of a &lt;code&gt;plugin.xml&lt;/code&gt;. But they have a similar directory structure, and they have the usual &lt;code&gt;META-INF/MANIFEST.MF&lt;/code&gt; file where the meta information is located. When deployed, a fragment looks exactly like a plugin. It (usually) lives in a jar file in the &lt;code&gt;plugins/&lt;/code&gt; folder.&lt;br /&gt;&lt;br /&gt;The specific thing about fragments is that they do not exist on their own - they are dependent on a plugin, which is called their &lt;i&gt;host&lt;/i&gt; plugin. They have to declare which plugin their host is by the host's plugin id and version. As an example, here is how this looks like for the fragment with the Cohatoe server executable for Windows:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_BynttqNlK3w/RZ-sIs7w5JI/AAAAAAAAACo/3X8L08hHBFU/s1600-h/Clipboard02.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://4.bp.blogspot.com/_BynttqNlK3w/RZ-sIs7w5JI/AAAAAAAAACo/3X8L08hHBFU/s320/Clipboard02.png" alt="" id="BLOGGER_PHOTO_ID_5016917775414781074" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;When Eclipse starts, it collects all fragments for a given host and adds their contents to the host plugin's. The contents are overlayed only virtually, they are not physically copied to the host plugin's folder. This means that all classes from &lt;code&gt;.jar&lt;/code&gt; files in the fragment appear on the classpath of the host plugin, all files (such as icons, or internationalization properties files) appear on the host plugin's resource path, and so on.&lt;br /&gt;&lt;br /&gt;Take an example: Suppose there is a plugin &lt;b&gt;p&lt;/b&gt;, and a fragment &lt;b&gt;f&lt;/b&gt; that declares &lt;b&gt;a&lt;/b&gt; as its host plugin. Suppose further that &lt;b&gt;f&lt;/b&gt; contains an icon file &lt;code&gt;icons/eview16/myview.gif&lt;/code&gt; (&lt;b&gt;p&lt;/b&gt; does not contain a file with that path and name). Now any code in a plugin that depends on &lt;b&gt;p&lt;/b&gt; will get that icon file from &lt;b&gt;p&lt;/b&gt;, if &lt;b&gt;f&lt;/b&gt; is present, even though &lt;b&gt;p&lt;/b&gt; does not contain it (and in fact doesn't even know about it).&lt;br /&gt;&lt;br /&gt;This mechanism is used by the Eclipse project itself for providing internationalization texts. The plugins of the Eclipse IDE themselves contain only English UI texts. But there is a set of fragments (collectively called the 'language packs') that provide translations of these texts into a number of other languages. These fragments consist of just a lot of &lt;code&gt;.properties&lt;/code&gt; files. When they are present, these files are used by Eclipse to display UI texts in their localized  versions.&lt;br /&gt;&lt;br /&gt;Fragments of the Cohatoe server plugin (&lt;code&gt;de.leiffrenzel.cohatoe.server.core&lt;/code&gt;) which contain the server executables are &lt;i&gt;platform-specific&lt;/i&gt;. That means that there is one fragment for Windows (which you can recognize from the &lt;code&gt;win32.win32.x86&lt;/code&gt; in the name), one for Linux (&lt;code&gt;linux.gtk.x86&lt;/code&gt;) and so on. The three elements in the fragment name stand for Operating System, os (e.g. linux), Window System, ws (e.g. gtk) and OS Architecture, arch (x86).&lt;br /&gt;&lt;br /&gt;The same naming convention is used in Eclipse for other things that are also related to platform-specific code. Another example (in addition to the platform fragments for the server executable which are my topic here) is the location of the Haskell object code which I have mentioned in an earlier post (the &lt;a href="http://cohatoe.blogspot.com/2006/12/simple-example-walkthrough-ii.html"&gt;simple example walkthrough&lt;/a&gt;). Remember that the folder names there also had these 'os' and 'win32' bits? I'll explain the particulars of that in more details in an upcoming post.&lt;br /&gt;&lt;br /&gt;For providing a server executable for a platform, the only thing that is needed is a fragment for that platform, and that fragment should contain a folder &lt;code&gt;server&lt;/code&gt;, in which the executable is placed. The name of the executable must start with &lt;code&gt;haskellserver&lt;/code&gt;. (On Windows, it is called &lt;code&gt;haskellserver.exe&lt;/code&gt;, on other platforms it will be very likely just called &lt;code&gt;haskellserver&lt;/code&gt;.)&lt;br /&gt;&lt;br /&gt;I have organized the Windows fragment so that the build scripts for building the Windows executable are located with the fragment, not with the plugin (where the source code is). This is because I think that there will be platform-specific build scripts in all the other fragments too. The build scripts are in the folder &lt;code&gt;INTERNAL/integration/&lt;/code&gt; in the windows&lt;br /&gt;fragment project.&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_BynttqNlK3w/RZ-sms7w5KI/AAAAAAAAACw/_juzxuDmYrQ/s1600-h/Clipboard03.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://4.bp.blogspot.com/_BynttqNlK3w/RZ-sms7w5KI/AAAAAAAAACw/_juzxuDmYrQ/s320/Clipboard03.png" alt="" id="BLOGGER_PHOTO_ID_5016918290810856610" border="0" /&gt;&lt;/a&gt;As you can see, I'm using Cabal for building the executable. That makes it convenient to declare additional package dependencies. The packages that are currently needed are base, network and parsec, of course hs-plugins and the Cohatoe API package (cohatoe-api), and HaXml. Further dependencies may be added in the future, depending on how much more functionality will go into the server.&lt;br /&gt;&lt;br /&gt;I have wrapped the several Cabal build steps (configure, build, clean) in a Windows batch file. There I'm also doing a pragmatic step to copy the created executable to the correct destination folder. I'm sure that there is a way to extend Cabal so that this can be done in a Cabal build hook - so if I've got a bit of time, I'll probably see to beautify that :-).&lt;br /&gt;&lt;br /&gt;Finally, to execute that build script (i.e. the Windows batch file), I have declared an &lt;i&gt;External Tool&lt;/i&gt; in Eclipse. This functionality in Eclipse is very useful, but seemingly not so well-known. You can create a launch configuration for an external tool ('external' means usually a separate process, but the file may be located inside the workspace, as it is in our case) and then have the launch configuration settings written into a workspace file. Mine is in the &lt;code&gt;Haskell server exectuable - win32.launch&lt;/code&gt; file that you can see in the build folder in the screenshot above. You can configure it on the dialog that you get from the menu &lt;b&gt;Run &gt; External Tools &gt; External Tools ...&lt;/b&gt;.&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_BynttqNlK3w/RZ-s4M7w5LI/AAAAAAAAAC4/weNBLF-fO2w/s1600-h/Clipboard04.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://2.bp.blogspot.com/_BynttqNlK3w/RZ-s4M7w5LI/AAAAAAAAAC4/weNBLF-fO2w/s320/Clipboard04.png" alt="" id="BLOGGER_PHOTO_ID_5016918591458567346" border="0" /&gt;&lt;/a&gt;You can see here that I have just declared the batch file as the executable and the folder which contains it as the working directory. In addition, it is very helpful to specify, on the &lt;b&gt;Refresh&lt;/b&gt; tab, that the entire project should be refreshed automatically after the tool has run.&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_BynttqNlK3w/RZ-tV87w5MI/AAAAAAAAADA/30d_WTlRC_o/s1600-h/Clipboard05.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://1.bp.blogspot.com/_BynttqNlK3w/RZ-tV87w5MI/AAAAAAAAADA/30d_WTlRC_o/s320/Clipboard05.png" alt="" id="BLOGGER_PHOTO_ID_5016919102559675586" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;Finally, on the &lt;b&gt;Common&lt;/b&gt; tab you can specify a location where the launch configuration settings should be stored.&lt;br /&gt;&lt;br /&gt;Now that we have the launch configuration we can simply run it from the menu or from the global Eclipse toolbar (look out for the 'External Tools' button). What's even better, we can also register the External Tool launch configuration as a builder on the Eclipse project that contains the sources, so that it is automatically triggered when these sources change. (But that is left as an exercise to the reader ;-).&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-8771177286940528326?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/8771177286940528326/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=8771177286940528326' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/8771177286940528326'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/8771177286940528326'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/01/building-server-executable.html' title='Building a server executable'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://4.bp.blogspot.com/_BynttqNlK3w/RZ-sIs7w5JI/AAAAAAAAACo/3X8L08hHBFU/s72-c/Clipboard02.png' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-1707592682226305101</id><published>2007-01-03T19:11:00.000+01:00</published><updated>2007-01-03T19:14:31.570+01:00</updated><title type='text'>Indirect programming</title><content type='html'>Yesterday during a debugging session a colleague and I stumbled over a terrific example of what I have called 'indirect programming' &lt;a href="http://leiffrenzel.eu/journal.php?entry=20060924"&gt;elsewhere&lt;/a&gt;:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;  &lt;span style="font-weight: bold;"&gt;private void&lt;/span&gt; start(String organizerId) {&lt;br /&gt;   IBreakpointOrganizer organizer = getOrganizer(organizerId);&lt;br /&gt;   IPropertyChangeListener listener = &lt;span style="font-weight: bold;"&gt;new &lt;/span&gt;IPropertyChangeListener() {&lt;br /&gt;     &lt;span style="font-weight: bold;"&gt;public void&lt;/span&gt; propertyChange(PropertyChangeEvent event) {&lt;br /&gt;     }&lt;br /&gt;   };&lt;br /&gt;   organizer.addPropertyChangeListener(listener);&lt;br /&gt;   organizer.removePropertyChangeListener(listener);      &lt;br /&gt; }&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;Why in the world would someone first add and then immediately remove a listener, and above all a listener with an empty implementation?? Here's why (taken from what happens to be one internal implementation class of &lt;code&gt;IBreakpointOrganizer&lt;/code&gt;):&lt;br /&gt;&lt;pre&gt;&lt;code&gt;  &lt;span style="font-weight: bold;"&gt;public void&lt;/span&gt; addPropertyChangeListener(IPropertyChangeListener listener) {&lt;br /&gt;   getOrganizer().addPropertyChangeListener(listener);&lt;br /&gt; }&lt;br /&gt;&lt;br /&gt; [...]&lt;br /&gt; &lt;span style="font-weight: bold;"&gt;protected &lt;/span&gt;IBreakpointOrganizerDelegate getOrganizer() {&lt;br /&gt;   &lt;span style="font-weight: bold;"&gt;if &lt;/span&gt;(fDelegate == &lt;span style="font-weight: bold;"&gt;null&lt;/span&gt;) {&lt;br /&gt;     &lt;span style="font-weight: bold;"&gt;try &lt;/span&gt;{&lt;br /&gt;       fDelegate = (IBreakpointOrganizerDelegate)&lt;br /&gt;         fElement.createExecutableExtension(ATTR_CLASS);&lt;br /&gt;     } &lt;span style="font-weight: bold;"&gt;catch &lt;/span&gt;(CoreException e) {&lt;br /&gt;       DebugUIPlugin.log(e);&lt;br /&gt;     }&lt;br /&gt;   }&lt;br /&gt;   &lt;span style="font-weight: bold;"&gt;return &lt;/span&gt;fDelegate;&lt;br /&gt; }&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;Adding a listener has the (undocumented) side-effect of initializing the internals of the &lt;code&gt;organizer&lt;/code&gt;. The implementation of the method above makes thus use of a) an implementation detail it shouldn't know; and b) a behaviour that is clearly a side-effect of an entirely different functionality. One can only hope that not, at some future time, a source code cleanup will just clean away that 'useless' add/remove a no-op piece of code ...&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-1707592682226305101?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/1707592682226305101/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=1707592682226305101' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1707592682226305101'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1707592682226305101'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/01/indirect-programming.html' title='Indirect programming'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-1368757067282342691</id><published>2007-01-02T20:59:00.000+01:00</published><updated>2007-01-03T11:01:39.332+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='darcs'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='architecture'/><title type='text'>What's in which package?</title><content type='html'>There are three features in Cohatoe. (Features are a fancy term in Eclipse's terminology for 'installable package' - a feature consists usually of one or more plugins and can be installed or uninstalled via Eclipse's built-in Update Manager). Here is a short explanation what each of them is needed for:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Runtime: this contains only those plugins that are needed at runtime.&lt;/li&gt;&lt;li&gt;Examples: an example plugin that demonstrates various aspects of the use of Cohatoe.&lt;/li&gt;&lt;li&gt;SDK: contains the sources and developer documentation for all of Cohatoe.&lt;/li&gt;&lt;/ul&gt;(The Examples feature depends on the Runtime feature, and the SDK depends on both others. The Runtime feature itself has no dependencies apart from that to the very basic Eclipse runtime plugins. You can even use it in UI-less mode.)&lt;br /&gt;&lt;br /&gt;When you develop an Eclipse plugin that has some functionality implemented in Haskell, you would therefore depend on the &lt;b&gt;&lt;i&gt;Runtime feature&lt;/i&gt;&lt;/b&gt;. This means that the plugins from the runtime feature must be present on the system of the user of your plugins. The best way to achieve this is to have the end user install the Cohatoe runtime feature and then your feature (which contains your plugins).&lt;br /&gt;&lt;br /&gt;For development of such plugins, on the other hand, you will likely want to have the &lt;i&gt;&lt;b&gt;SDK feature &lt;/b&gt;&lt;/i&gt;around. It contains the API documentation, the extension point documentation, and the sources of Cohatoe itself (useful for debugging). Since the SDK feature depends on the Runtime feature, this means that you also must have the Runtime feature installed, which is obvious anyway ;-).&lt;br /&gt;&lt;br /&gt;If you want to hack Cohatoe itself, you could theoretically also use the sources from the SDK feature. However, it is recommended that you get the latest sources from the Darcs repository instead. This means not only that you get the latest changes (which may not yet have been included in the released versions), but also that you will be able to send your changes as patches. Any contribution of patches is very welcome!&lt;br /&gt;&lt;br /&gt;If you don't know Darcs yet - please consider to have a look at it. It is a really nice revision control system (i.e. an alternative to the more widely used like CVS or Subversion), very easy to learn and somewhat addictive once one has used it for a while. It differs from the more mainstream alternatives in that it is not only &lt;i&gt;distributed&lt;/i&gt;, but also &lt;i&gt;change-oriented&lt;/i&gt; (as opposed to version-oriented). You can get a Darcs client and find more information about Darcs at the main Darcs website at &lt;a href="http://darcs.net/"&gt;darcs.net&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;If you want to access the Cohatoe repository, here's what you need:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&gt; darcs get --partial http://leiffrenzel.eu/repos/cohatoe&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;Have fun!&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-1368757067282342691?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/1368757067282342691/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=1368757067282342691' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1368757067282342691'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/1368757067282342691'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/01/whats-in-which-package.html' title='What&apos;s in which package?'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-6893224004930845257</id><published>2007-01-01T17:14:00.000+01:00</published><updated>2008-12-09T02:08:02.920+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='debugging'/><title type='text'>Tracing deployed plugins</title><content type='html'>In a &lt;a href="http://cohatoe.blogspot.com/2006/12/how-to-tell-whats-going-on.html"&gt;previous post&lt;/a&gt; I have explained how to use Cohatoe's debugging options (called &lt;span style="font-style: italic;"&gt;Tracing&lt;/span&gt; in Eclipse) for getting more info about what goes on inside Cohatoe when Haskell functions are registered and called. This is  useful when you are contributing an Eclipse extension and something goes wrong, so that your function call doesn't actually happen.&lt;br /&gt;&lt;br /&gt;You can also use the same tracing options in an Eclipse installation where your plugins are deployed.  This is in some respects a different situation, different from the debugging situation I have described. Your plugins may now reside in &lt;code&gt;.jar&lt;/code&gt; archives, for instance, where they before had lived in project folders in the workspace, and that may have some unforeseen effects.&lt;br /&gt;&lt;br /&gt;And there is another typical problem with deployed Eclipse installations. When you export a plugin,  you have to declare, in the &lt;code&gt;build.properties&lt;/code&gt;, which files should be exported and which not. You can find the &lt;code&gt;build.properties&lt;/code&gt; in the Plugin Manifest editor, from the &lt;b&gt;Build&lt;/b&gt; tab.&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_BynttqNlK3w/RZkzw71u1mI/AAAAAAAAACQ/vNsW4S2Sxxg/s1600-h/Clipboard02.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://1.bp.blogspot.com/_BynttqNlK3w/RZkzw71u1mI/AAAAAAAAACQ/vNsW4S2Sxxg/s320/Clipboard02.png" alt="" id="BLOGGER_PHOTO_ID_5015096575843554914" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;In the screenshot, you can see how this looks in my workspace for the Cohatoe examples. You see that the files needed only at development time (such as Eclipse's &lt;code&gt;.project&lt;/code&gt; file of the &lt;code&gt;.checkstyle&lt;/code&gt; configuration are not checked, but the files that we need to deploy, such as the &lt;code&gt;plugin.xml&lt;/code&gt; or the object files, are checked. A typical case is where a developer first creates a project, later adds some files, such as icons or object files, forgets to check them in the &lt;code&gt;build.properties&lt;/code&gt;, and then wonders why something doesn't work in the deployed version. To me at least, this happens all the time :-).&lt;br /&gt;&lt;br /&gt;One way to detect such a problem, at least with object files contributed via Cohatoe, is to use tracing. In the post I mentioned above I have explained how the tracing output looks like. If an object file was missing, this would be reported in a line in the tracing output.&lt;br /&gt;&lt;br /&gt;Now suppose you have some Eclipse installation, where Cohatoe is installed.&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_BynttqNlK3w/RZk0L71u1nI/AAAAAAAAACY/Yu_9Tu4svZk/s1600-h/Clipboard03.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://1.bp.blogspot.com/_BynttqNlK3w/RZk0L71u1nI/AAAAAAAAACY/Yu_9Tu4svZk/s320/Clipboard03.png" alt="" id="BLOGGER_PHOTO_ID_5015097039700022898" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;This is what a typical Eclipse installation looks like. The only thing that I have added is the &lt;code&gt;.options&lt;/code&gt; file. Its content is quite simple:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;# option for tracing calls to the Cohatoe server,&lt;br /&gt;# including inits and function calls&lt;br /&gt;de.leiffrenzel.cohatoe.server.core/logs = true&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;I have just copied it from the Cohatoe server core plugin. (You can add options for other plugins in here too, and get their tracing output too.) Note that I have switched the value to &lt;b&gt;true&lt;/b&gt;; the original file has &lt;b&gt;false&lt;/b&gt; in this place.&lt;br /&gt;&lt;br /&gt;Now run Eclipse from the command line with the following options:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&gt; cd C:\cohatoetest\eclipse&lt;br /&gt;&gt; eclipse -debug -consolelog&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;You get a console window where you will see the tracing output (and as a nice extra, you will also get the contents of the workspace log appended there, i.e. the output that ususally goes to &lt;code&gt;yourWorkspaceLocation/.metadata/.log&lt;/code&gt;).&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-6893224004930845257?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/6893224004930845257/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=6893224004930845257' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6893224004930845257'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6893224004930845257'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2007/01/tracing-deployed-plugins.html' title='Tracing deployed plugins'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://1.bp.blogspot.com/_BynttqNlK3w/RZkzw71u1mI/AAAAAAAAACQ/vNsW4S2Sxxg/s72-c/Clipboard02.png' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-322311684987736000</id><published>2006-12-31T17:24:00.000+01:00</published><updated>2006-12-31T17:40:32.836+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='architecture'/><title type='text'>Code in multiple modules</title><content type='html'>I am currently working to overcome a limitation that Cohatoe has in its current state: what if your Haskell code makes up more than one module? In this case, you have multiple object files, and of course you must provide all of them to Cohatoe. But you can only declare one of them - so how will the others be available at runtime? (Needless to say, you certainly don't want to have to declare each of them separately, too ;-)&lt;br /&gt;&lt;br /&gt;hs-plugins, which is used by Cohatoe on the Haskell side to load the object code, is able to automatically preload module dependencies. Therefore, as long as the module dependencies (that is, their object files) are available to it on some search path, this should be fine. However, the path to the object files to be loaded is determined by Cohatoe only when the object code is registered. They are presumably (but not necessarily, see below) in some subfolder of the &lt;code&gt;plugins/&lt;/code&gt; folder in the Eclipse installation. Therefore, some more logic is needed in Cohatoe to determine these paths and send them to hs-plugins.&lt;br /&gt;&lt;br /&gt;That's not too difficult, but here are some complications:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;an Eclipse plugin may run out of a &lt;code&gt;.jar&lt;/code&gt; archive&lt;/li&gt;&lt;li&gt;you might want to have several different folders containing object code&lt;/li&gt;&lt;li&gt;you might want to have a lot of object files and they should be packaged into a single archive file&lt;/li&gt;&lt;/ul&gt;The first point is the most pressing. When Eclipse plugins are exported and deployed to an end user's Eclipse installation, they mostly live in &lt;code&gt;.jar&lt;/code&gt; archives. The object files will then be packed into the archives and can't be automatically found by Cohatoe or hs-plugins. For the &lt;code&gt;.o&lt;/code&gt; files that have been declared in the &lt;code&gt;plugin.xml&lt;/code&gt;, and their corresponding &lt;code&gt;.hi&lt;/code&gt; files, Cohatoe uses a trick before sending their path to hs-plugins: it tells the Eclipse runtime that it needs them as 'local file'. The Eclipse runtime then checks if the plugin is currently running out of a file system folder (which is the case both at debug time when the plugin is physically a plugin project in the workspace, and for deployed plugins when they are deployed with the &lt;code&gt;unpack="true"&lt;/code&gt; flag in the &lt;code&gt;feature.xml&lt;/code&gt; of the feature that provides the plugin). If so, it gives us the file system location. If not, this means the plugin runs out of a jar file, and then the Eclipse runtime would extract it into a cache location on the file system and give us the path to that location.&lt;br /&gt;&lt;br /&gt;Now if we make it a convention in Cohatoe that all object files in the same folder as a declared one are also automatically available to hs-plugins, it is not sufficient to just send the path of the folder containing the declared object files, because that folder is not in all cases the folder which hs-plugins actually uses. We have to make the 'as local' conversion for that folder too, and not just for it, but also for all its contents.&lt;br /&gt;&lt;br /&gt;The other two points listed above are actually new features that I could add while I'm at it anyway. hs-plugins provides also a functionality to load libraries of object code.&lt;br /&gt;&lt;br /&gt;I think I will add, in one of the next versions of Cohatoe, a possibility to declare such packages, which can be used as dependencies. I'd like to give that some thought, though, because it seems to me that just giving a file list is a somewhat short way to address the problem. If you could say&lt;pre&gt;&lt;code&gt;&amp;lt;extension point=&lt;span style="color: rgb(51, 51, 255);"&gt;"de.leiffrenzel.cohatoe.server.core.haskellFunctions"&lt;/span&gt;&amp;gt;&lt;br /&gt; &amp;lt;haskellfunction interface=&lt;span style="color: rgb(51, 51, 255);"&gt;"..."&lt;/span&gt;&lt;br /&gt;                 implementation=&lt;span style="color: rgb(51, 51, 255);"&gt;"..."&lt;/span&gt;&lt;br /&gt;                 objectcode=&lt;span style="color: rgb(51, 51, 255);"&gt;"..."&lt;/span&gt;&amp;gt;&lt;br /&gt;  &amp;lt;objectcodepackage path=&lt;span style="color: rgb(51, 51, 255);"&gt;"..."&lt;/span&gt; /&amp;gt;&lt;br /&gt; &amp;lt;/haskellfunction&amp;gt;&lt;br /&gt;&amp;lt;/extension&amp;gt;&lt;/code&gt;&lt;/pre&gt;&lt;br /&gt;that would solve the problem, but it would force you to provide the binaries for the package in every Eclipse plugin that uses them. I would be interested in having some mechanism to address this, so that you can contribute a package independently, and just refer to it. It would then look like this:&lt;pre&gt;&lt;code&gt;&amp;lt;extension point=&lt;span style="color: rgb(51, 51, 255);"&gt;"de.leiffrenzel.cohatoe.server.core.haskellFunctions"&lt;/span&gt;&amp;gt;&lt;br /&gt; &amp;lt;haskellfunction interface=&lt;span style="color: rgb(51, 51, 255);"&gt;"..."&lt;/span&gt;&lt;br /&gt;                 implementation=&lt;span style="color: rgb(51, 51, 255);"&gt;"..." &lt;/span&gt;&lt;br /&gt;                 objectcode=&lt;span style="color: rgb(51, 51, 255);"&gt;"..."&lt;/span&gt;&amp;gt;&lt;br /&gt;   &amp;lt;depends id=&lt;span style="color: rgb(51, 51, 255);"&gt;"myLib"&lt;/span&gt; /&amp;gt;&lt;br /&gt;&amp;lt;/haskellfunction&amp;gt;&lt;br /&gt;&amp;lt;objectcodepackage id=&lt;span style="color: rgb(51, 51, 255);"&gt;"myLib"&lt;/span&gt; path=&lt;span style="color: rgb(51, 51, 255);"&gt;"..."&lt;/span&gt; /&amp;gt;&lt;br /&gt;&amp;lt;/extension&amp;gt;&lt;/code&gt;&lt;/pre&gt;The advantage of this would of course be that any &lt;code&gt;haskellFunction&lt;/code&gt; declaration could just declare a package as a dependency by its id, even if it was actually provided by a different Eclipse plugin.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-322311684987736000?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/322311684987736000/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=322311684987736000' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/322311684987736000'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/322311684987736000'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2006/12/code-in-multiple-modules.html' title='Code in multiple modules'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-6510471447333146519</id><published>2006-12-29T17:51:00.000+01:00</published><updated>2008-12-09T02:08:03.154+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><category scheme='http://www.blogger.com/atom/ns#' term='debugging'/><title type='text'>How to tell what's going on</title><content type='html'>In my last two posts (Cohatoe example walkthrough, &lt;a href="http://http//cohatoe.blogspot.com/2006/12/simple-example-walkthrough-i.html"&gt;part I&lt;/a&gt; and &lt;a href="http://cohatoe.blogspot.com/2006/12/simple-example-walkthrough-ii.html"&gt;part II&lt;/a&gt;) I have explained the basics of how to contribute some Haskell code in an Eclipse plugin so that it can be called from the Java code in that Eclipse plugin (and other Eclipse plugins that depend on it). If you have experimented a little with this, then you might have encountered situations in which something went wrong and you could not immediately see what - so what can you do for diagnostics?&lt;br /&gt;&lt;br /&gt;One helpful instrument is Eclipse's built-in tracing. It is not a full-fledged logging framework, but it can come in helpful. For Cohatoe, I have implemented tracing for the inits and all calls to the Cohatoe server singleton. The server singleton basically manages all registered Haskell functions and delegates calls to them to the native object code. If you switch on the tracing for the Cohatoe server, you will be able to detect problems of three different sorts:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;declaration problems in the plugin manifest file, &lt;code&gt;plugin.xml&lt;/code&gt; (e.g. you have a typo in the declaration of your object files)&lt;/li&gt;&lt;li&gt;initialization problems that occcur when the server is started&lt;/li&gt;&lt;li&gt;problems during calls to the native code (e.g. load errors that occured when object code could not be loaded or exceptions on the Haskell side, like calls to the &lt;code&gt;Prelude.error&lt;/code&gt; function)&lt;/li&gt;&lt;/ul&gt;Especially the latter sort of problem is still very much work in progress. In later versions of Cohatoe, exceptions that are fired on the Haskell side will be transferred to the Java side and re-raised there, where the caller to the &lt;code&gt;evaluate()&lt;/code&gt; method on the server singleton will be responsible for handling them. (Of course, it is even better the Haskell code would already handle them itself :-). But that mechanism is not yet in place as of Cohatoe 0.1, therefore you will only see problems on the Haskell side when you switch on tracing.&lt;br /&gt;&lt;br /&gt;And here's how you do it: Assuming that you have an Eclipse plugin project, and you have at least once run it as an Eclipse application from the &lt;span style="font-weight: bold;"&gt;Run&lt;/span&gt; or &lt;span style="font-weight: bold;"&gt;Debug&lt;/span&gt; menu, then you have a so-called &lt;span style="font-weight: bold; font-style: italic;"&gt;launch configuration&lt;/span&gt; for that launch. Whether tracing is enabled is a property of that launch configuration, and you can switch it on or off on the launch configuration dialog. Select &lt;span style="font-weight: bold;"&gt;Run &gt; Run ...&lt;/span&gt; from the main menu. On the dialog that appears, select the Eclipse application launch configuration for your launch. Here is how the dialog looks like in my examples workspace:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_BynttqNlK3w/RZaAzb1u1kI/AAAAAAAAAB4/zQQ-tsNjGp0/s1600-h/Clipboard01.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://4.bp.blogspot.com/_BynttqNlK3w/RZaAzb1u1kI/AAAAAAAAAB4/zQQ-tsNjGp0/s320/Clipboard01.png" alt="" id="BLOGGER_PHOTO_ID_5014336856258434626" border="0" /&gt;&lt;/a&gt;&lt;br /&gt;Switch to the &lt;span style="font-weight: bold;"&gt;Tracing&lt;/span&gt; tab. Here you can see the tracing options from all plugins which support tracing. In order to enable a particular tracing option, you have first to globally enable the tracing functionality - that's the &lt;span style="font-weight: bold;"&gt;Enable tracing for the selected plugins&lt;/span&gt; checkbox right on top of the &lt;span style="font-weight: bold;"&gt;Tracing&lt;/span&gt; tab. Then you must select the plugins themselves, in our case that is the Cohatoe server plugin, which appears in the list with its plugin id, namely: &lt;code&gt;de.leiffrenzel.cohatoe.server.core&lt;/code&gt;. Finally, check the particular tracing option that you want to enable - this is &lt;code&gt;logs&lt;/code&gt; in our case, which is the only option that Cohatoe currently provides.&lt;br /&gt;&lt;br /&gt;Note that it is not enough to just check the option, you must also check the plugin! If you check the option and not the plugin, you won't see anything. This is how the tab should look like now:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_BynttqNlK3w/RZaEP71u1lI/AAAAAAAAACE/LQ7vyVkumI4/s1600-h/Clipboard02.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://2.bp.blogspot.com/_BynttqNlK3w/RZaEP71u1lI/AAAAAAAAACE/LQ7vyVkumI4/s320/Clipboard02.png" alt="" id="BLOGGER_PHOTO_ID_5014340644419589714" border="0" /&gt;&lt;/a&gt;When you run your launch configuration now and (in the second Eclipse instance that was fired up) trigger some action that calls a Haskell function, you will see some output in the console that obviously came from the Cohatoe server. Here is what I got:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;[Cohatoe Server] No entry 'inexistent.obj' in bundle 'de.leiffrenzel.cohatoe.server.core.test'.&lt;br /&gt;[Cohatoe Server] Initializing server.&lt;br /&gt;[Cohatoe Server] Setting port to 36522&lt;br /&gt;[Cohatoe Server] Setting executable to C:\workspaces\cohatoe\de.leiffrenzel.cohatoe.server.core.win32.win32.x86\server\haskellserver.exe&lt;br /&gt;[Cohatoe Server] Evaluating de.leiffrenzel.cohatoe.example.core.functions.IHelloFunction&lt;br /&gt;[Cohatoe Server] C:\workspaces\cohatoe\de.leiffrenzel.cohatoe.example\os\win32\x86\obj\Hello.o&lt;br /&gt;[Cohatoe Server] &gt; Server process ready&lt;br /&gt;[Cohatoe Server] Response was: Hi, thanks for saying 'Hi Haskell!' to me.§&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;Now what does all this tell us?&lt;br /&gt;&lt;br /&gt;The first line in this tracing output complains about a non-existing object file. This comes from the initialization phase of the Cohatoe server. The server, in that phase, reads all extensions to the &lt;code&gt;haskellFunctions&lt;/code&gt; extension point. In these extensions, the object code for the Haskell functions is declared, and the server needs to locate the object files so that it knows (on the Haskell side of things) where to get them. The line in our trace states that one object file, named 'inexistent.obj', was not actually found, and that this file was declared by the bundle (for which read 'Eclipse plugin') with the id &lt;code&gt;de.leiffrenzel.cohatoe.server.core.test&lt;/code&gt;. In this case, that's fine, because that plugin is the one which contains my unit tests for Cohatoe, and the object file declaration declared deliberately a non-existing object file (because I wanted to test the behaviour of the server in such a case). But if you see such a line in the trace, that indicates that you have either forgotten to provide an object file, or you have mistyped its declaration in the &lt;code&gt;plugin.xml&lt;/code&gt;.&lt;br /&gt;&lt;br /&gt;The next 3 lines tell us a bit about the proceedings inside Cohatoe. The server singleton starts its init routine, determines a free port on the local host, and then fires up a native executable in an external process which listens on that port. That executable knows how to load and execute Haskell functions from object code (using hs-plugins), and is the Haskell side of the Cohatoe server. I will add details about all this in some later posts.&lt;br /&gt;&lt;br /&gt;After these inits, we see now the tracing output for all the calls to Haskell functions. You see the fully qualified name of a Java interface and the file name of an object file. Cohatoe uses Java interfaces as keys for Haskell functions, namely the interfaces that have been declared together with the object code in the &lt;code&gt;plugin.xml&lt;/code&gt;. You can think of these Java interfaces as the placeholders or representatives of your Haskell functions in the Eclipse-plugin world. For every Haskell function that is called, you will see the interface name, object file name, and the response from the Haskell side in the trace.&lt;br /&gt;&lt;br /&gt;You will have noticed that there was another line in between these function call tracing outputs: "&lt;code&gt;&gt; Server process ready&lt;/code&gt;". The '&gt;' character in front of a tracing line indicates that this line comes from the standard output or standard error stream of the native server process. In this case, that's only a friendly message that the server is ready. (It is read asynchronously with low priority on the Java side, and therefore appears sometimes a little later in the trace.) But if, for some reason, your Haskell code causes the server process to write to the error stream, you'll see that output here.&lt;br /&gt;&lt;br /&gt;Finally, when you shut down your debugging Eclipse, you will see some more output:&lt;br /&gt;&lt;pre&gt;[Cohatoe Server] Disposing server.&lt;br /&gt;[Cohatoe Server] Finished out and err of the server process.&lt;br /&gt;&lt;/pre&gt;which obviously informs us about the cleanups which go on at that time.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-6510471447333146519?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/6510471447333146519/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=6510471447333146519' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6510471447333146519'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/6510471447333146519'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2006/12/how-to-tell-whats-going-on.html' title='How to tell what&apos;s going on'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://4.bp.blogspot.com/_BynttqNlK3w/RZaAzb1u1kI/AAAAAAAAAB4/zQQ-tsNjGp0/s72-c/Clipboard01.png' height='72' width='72'/><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-3902817470552202188</id><published>2006-12-28T18:04:00.000+01:00</published><updated>2008-12-09T02:08:03.665+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='example'/><category scheme='http://www.blogger.com/atom/ns#' term='tutorial'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Simple example walkthrough II</title><content type='html'>In the &lt;a href="http://cohatoe.blogspot.com/2006/12/simple-example-walkthrough-i.html"&gt;last post&lt;/a&gt;, we have prepared an Eclipse plugin project for a Hello-World Cohatoe plugin. Lets have a look at the Haskell side now.&lt;br /&gt;&lt;br /&gt;The Haskell code that we are going to contribute will be loaded at runtime by the Cohatoe server core plugin, which in turn delegates the work to &lt;a href="http://http//www.cse.unsw.edu.au/%7Edons/hs-plugins/"&gt;hs-plugins&lt;/a&gt;. hs-plugins is a library by Don Stewart written for exactly this purpose: dynamically locating compiled Haskell code at runtime, loading it and executing it, and all this in a typesafe manner. (hs-plugins can also load and on-the-fly-compile Haskell source code, but that's not a functionality I'm using.)&lt;br /&gt;&lt;br /&gt;Haskell code that can be loaded this way has to fulfill a few conditions: it must provide, by convention, a symbol called 'resource', which is a record and has a field, &lt;code&gt;pluginMain :: [String] -&gt; [String]&lt;/code&gt;, which is the entry point function that Cohatoe will call. (Think of it as a fancy sort of main function.)  Therefore, all Haskell code that is contributed via Cohatoe will include something like this after the module declaration:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&lt;span style="color: rgb(0, 102, 0);"&gt;-- We must import Cohatoe.API and implement resource &lt;/span&gt;&lt;br /&gt;&lt;span style="color: rgb(0, 102, 0);"&gt;-- &lt;/span&gt;&lt;/code&gt;&lt;code style="color: rgb(0, 102, 0);"&gt;so that this code &lt;/code&gt;&lt;code&gt;&lt;span style="color: rgb(0, 102, 0);"&gt;can be dynamically loaded&lt;/span&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;import&lt;/span&gt; Cohatoe.API&lt;br /&gt;&lt;br /&gt;resource = plugin {&lt;br /&gt;&lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt;pluginMain = sayHello&lt;br /&gt;}&lt;br /&gt;&lt;br /&gt;&lt;span style="color: rgb(0, 102, 0);"&gt;-- our code starts here&lt;/span&gt;&lt;br /&gt;&lt;span style="color: rgb(0, 102, 0);"&gt;-- ...&lt;/span&gt;&lt;br /&gt;sayHello = ...&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;As you can see, this needs to import the Cohatoe API. Let's make sure that we have that API available.&lt;br /&gt;&lt;br /&gt;Remember that you downloaded a second file, &lt;span style="font-weight: bold;"&gt;cohatoe-api_0.1.0.zip&lt;/span&gt;? Unzip that archive now and open a command prompt in the cohatoe-api/ folder:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&gt; cd C:\cohatoetest\cohatoe-api&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;Now run the following three commands:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&gt; runhaskell Setup.hs configure&lt;br /&gt;&gt; runhaskell Setup.hs build&lt;br /&gt;&gt; runhaskell Setup.hs install&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;This compiles the &lt;span style="font-weight: bold;"&gt;cohatoe-api&lt;/span&gt; package (which is very small and simple), installs it  and registers it as a package for GHC.&lt;br /&gt;&lt;br /&gt;Now that we have this in place, we can compile the Haskell code that we want to call from our Eclipse plugin. Create a file, e.g. &lt;span style="font-weight: bold;"&gt;Example.hs&lt;/span&gt;, with this content:&lt;br /&gt;&lt;pre&gt;&lt;span style="font-weight: bold;"&gt;module&lt;/span&gt; Example &lt;span style="font-weight: bold;"&gt;where&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;import&lt;/span&gt; Cohatoe.API&lt;br /&gt;&lt;br /&gt;resource = plugin {&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;pluginMain = sayHello&lt;br /&gt;}&lt;br /&gt;&lt;br /&gt;sayHello :: [String] -&gt; [String]&lt;br /&gt;sayHello _ = [&lt;span style="color: rgb(51, 51, 255);"&gt;"Hello from Haskell"&lt;/span&gt;]&lt;br /&gt;&lt;/pre&gt;and compile it like so:&lt;br /&gt;&lt;pre&gt;&gt; ghc -c -package cohatoe-api Example.hs&lt;br /&gt;&lt;/pre&gt;Put the resulting &lt;span style="font-weight: bold;"&gt;Example.o&lt;/span&gt; and &lt;span style="font-weight: bold;"&gt;Example.hi&lt;/span&gt; files into a folder called &lt;span style="font-weight: bold;"&gt;os/win32/x86/obj/&lt;/span&gt; in your plugin:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_BynttqNlK3w/RZVACL1u1gI/AAAAAAAAABI/BMNhcBdwzlE/s1600-h/Clipboard01.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://2.bp.blogspot.com/_BynttqNlK3w/RZVACL1u1gI/AAAAAAAAABI/BMNhcBdwzlE/s320/Clipboard01.png" alt="" id="BLOGGER_PHOTO_ID_5013984166428988930" border="0" /&gt;&lt;/a&gt;(You might have guessed that there is a naming convention for OS platforms at work here in this particular name for the folder. You're right. I'll elaborate on this in a later post.)&lt;br /&gt;&lt;br /&gt;The next thing to do now that we have our Haskell object code, is to register it with Cohatoe as an executable function. This is done via Eclipse's extension mechanism. Cohatoe provides an &lt;span style="font-weight: bold; font-style: italic;"&gt;extension point&lt;/span&gt;, and we'll provide an Eclipse &lt;span style="font-weight: bold; font-style: italic;"&gt;extension&lt;/span&gt; to that extension point now.&lt;br /&gt;&lt;br /&gt;Open the Plugin Manifest Editor by double-clicking the file &lt;span style="font-weight: bold;"&gt;plugin.xml&lt;/span&gt; in the plugin project. First switch to the &lt;span style="font-weight: bold;"&gt;Dependencies&lt;/span&gt; tab. In the &lt;span style="font-weight: bold;"&gt;Required&lt;/span&gt; section, press &lt;span style="font-weight: bold;"&gt;Add&lt;/span&gt; and select &lt;code&gt;de.leiffrenzel.cohatoe.server.core&lt;/code&gt;. By doing this, we make our new plugin dependent on the Cohatoe server core plugin, which we must do because we want to use its extension point. Now switch to the &lt;span style="font-weight: bold;"&gt;Extensions&lt;/span&gt; tab and press &lt;span style="font-weight: bold;"&gt;Add&lt;/span&gt;. Choose the &lt;code&gt;haskellFunctions&lt;/code&gt; extension point (actually, it appears under its fully qualified name, which is &lt;code&gt;de.leiffrenzel.cohatoe.server.core.haskellFunctions&lt;/code&gt;), then right-click it and select &lt;span style="font-weight: bold;"&gt;New &gt; haskellFunction&lt;/span&gt;. Here you get a form where you can fill in the details for the Haskell Function extension that we are just creating:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_BynttqNlK3w/RZVGAb1u1jI/AAAAAAAAABs/wfs9xTLovtk/s1600-h/Clipboard02.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://3.bp.blogspot.com/_BynttqNlK3w/RZVGAb1u1jI/AAAAAAAAABs/wfs9xTLovtk/s320/Clipboard02.png" alt="" id="BLOGGER_PHOTO_ID_5013990733433984562" border="0" /&gt;&lt;/a&gt;As you can see, we have basically to specify three things: a Java interface, a Java class that implements that interface, and the location of the object code of our Haskell function. For the latter, just specify the &lt;code&gt;.o&lt;/code&gt;-file, i.e. &lt;code&gt;$os$/obj/Example.o&lt;/code&gt;. We only need to specify the location of the &lt;code&gt;.o&lt;/code&gt;-file, the location of the corresponding &lt;code&gt;.hi&lt;/code&gt;-file is automatically determined by Cohatoe from that location. (But the &lt;code&gt;.hi&lt;/code&gt;-file must be there in the same folder as the &lt;code&gt;.o&lt;/code&gt;-file, otherwise hs-plugins will not be able to load the code.)&lt;br /&gt;&lt;br /&gt;And what about the interface and implementation class? These are registered together with the object  code so that Java code from Eclipse plugins can call our Haskell function. That Java code will always only see the interface that you specify here. (We will see in a moment what exactly will be visible for any Java code that wants to call our Haskell function.) As a provider of a Haskell function, however, you also have to provide an implementation class for that interface. This is necessary for Cohatoe itself. It will instantiate that implementation class and pass it on to the clients that want to call the Haskell function (they will only see the specified interface as the type of the object that they get). The primary role of this implementation class is that it gives the provider of a Haskell function a hook to implement data marshalling. In our case, there is no data to be transported from the Java to the Haskell side, and only a minimum from the Haskell side to the Java side - thus the implementation class will not have to do much.&lt;br /&gt;&lt;br /&gt;In the screenshot above you see that I have specified &lt;code&gt;cohatoetest.IExampleFunction&lt;/code&gt; as the name of the interface and &lt;code&gt;cohatoetest.ExampleFunction&lt;/code&gt; as the name of the implementation class. These two types do not yet exist. You can easily create them by clicking the link before the type name in the Manifest editor.&lt;br /&gt;&lt;br /&gt;After you have created the source files, their content should look like this:&lt;br /&gt;&lt;pre&gt;&lt;span style="color: rgb(0, 102, 0);"&gt;// cohatoetest.IExampleFunction:&lt;/span&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;package &lt;/span&gt;cohatoetest;&lt;br /&gt;&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;span style="font-weight: bold;"&gt;public interface&lt;/span&gt; IExampleFunction {&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;String sayHello();&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;}&lt;br /&gt;&lt;br /&gt;&lt;span style="color: rgb(0, 102, 0);"&gt;// cohatoetest.ExampleFunction:&lt;/span&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;package &lt;/span&gt;cohatoetest;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;import &lt;/span&gt;de.leiffrenzel.cohatoe.server.core.CohatoeServer;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;public class&lt;/span&gt; ExampleFunction &lt;span style="font-weight: bold;"&gt;implements &lt;/span&gt;IExampleFunction {&lt;br /&gt;&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;span style="font-weight: bold;"&gt;public&lt;/span&gt; String sayHello() {&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;CohatoeServer server = CohatoeServer.getInstance();&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;String[] retVal = server.evaluate( IExampleFunction.&lt;span style="font-weight: bold;"&gt;class&lt;/span&gt;, new String[ 0 ] );&lt;br /&gt;&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;String result = &lt;span style="color: rgb(51, 51, 255);"&gt;"[Got no answer from Haskell.]"&lt;/span&gt;;&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;if( retVal != &lt;span style="font-weight: bold;"&gt;null&lt;/span&gt; &amp;&amp;amp; retVal.length == 1 ) {&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;result = retVal[ 0 ];&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;}&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;span style="font-weight: bold;"&gt;return&lt;/span&gt; result;&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;}&lt;br /&gt;}&lt;br /&gt;&lt;/pre&gt;The only interesting thing here is the implementation of &lt;code&gt;sayHello()&lt;/code&gt; in our implementation class. You see that there is a singleton object of type &lt;code&gt;CohatoeServer&lt;/code&gt;, to which the call to our function is delegated. The Cohatoe server singleton knows about all registered Haskell functions, and it knows how to forward calls to them. Since it is a singleton and shared between all plugins in the running Eclipse instance, we must pass a key to it so that it knows which Haskell function we actually want to evaluate. The Cohatoe server uses the class objects of the interfaces under which functions are registered as keys; you can see that we pass &lt;code&gt;IExampleFunction.class&lt;/code&gt; as a key here. We also pass an empty string array as parameter list. The return value (if everything goes fine) is a one-element &lt;code&gt;String&lt;/code&gt; array that holds the single string returned by our Haskell function.&lt;br /&gt;&lt;br /&gt;(Note that this is a really, really trivial example. What you usually want to do in this implementation is to accept objects of all types as parameters and convert them into a string representation for marshalling, then convert back from strings what you receive as result from the call to the Haskell function. This is deliberately designed so that the interface for the Java code that calls the Haskell function is typesafe. So for example, instead of accepting a &lt;code&gt;String&lt;/code&gt; for a file name, you would use a &lt;code&gt;java.io.File&lt;/code&gt; object in the signature of your interface function, and only convert it into a string inside the implementation. Similarly, you should not return the bare strings that you get from the Haskell side, but instead convert them into objects of a type that really represent your data.)&lt;br /&gt;&lt;br /&gt;This is all - we have now made our Haskell function available to any Java code in any Eclipse plugin that wants to call it. (Strictly speaking, we have made it available to any Eclipse plugin that depends on our own plugin.) To demonstrate how one would call it, we'll put such a call into the &lt;code&gt;run()&lt;/code&gt; method of our 'Hello-World' action. Remember, this was in the class &lt;code&gt;cohatoetest.actions.SampleAction&lt;/code&gt;. Modify the &lt;code&gt;run()&lt;/code&gt; method so that it looks like this:&lt;br /&gt;&lt;code&gt;&lt;/code&gt;&lt;pre&gt;  &lt;span style="font-weight: bold;"&gt;public void&lt;/span&gt; run( &lt;span style="font-weight: bold;"&gt;final &lt;/span&gt;IAction action ) {&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;CohatoeServer server = CohatoeServer.getInstance();&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;Object fun = server.createFunction( IExampleFunction.&lt;span style="font-weight: bold;"&gt;class&lt;/span&gt; );&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;span style="font-weight: bold;"&gt;if&lt;/span&gt;( fun &lt;span style="font-weight: bold;"&gt;instanceof&lt;/span&gt; IExampleFunction ) {&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt;&lt;/code&gt;&lt;code&gt; &lt;/code&gt;IExampleFunction helloFunction = ( IExampleFunction )fun;&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;MessageDialog.openInformation(&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;window.getShell(),&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;span style="color: rgb(51, 51, 255);"&gt;"Cohatoetest Plug-in"&lt;/span&gt;,&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;helloFunction.sayHello() );&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;}&lt;br /&gt;&lt;code&gt; &lt;/code&gt;&lt;code&gt; &lt;/code&gt;}&lt;br /&gt;&lt;/pre&gt;You see again that we use the type of our declared interface as key, this time to obtain an object that (sort of) represents our Haskell function, so that we can call it via that object. The rule is that you can get an object complying to the interface that you pass in as key, or &lt;code&gt;null&lt;/code&gt; (if no function is registered for that interface). Then you can cast and pass your function arguments in a typesafe manner.&lt;br /&gt;&lt;br /&gt;Voila, if you run this, you'll see a friendly message from the Haskell side :-)&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_BynttqNlK3w/RZVDFL1u1iI/AAAAAAAAABg/DonZKthxrww/s1600-h/Clipboard03.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://2.bp.blogspot.com/_BynttqNlK3w/RZVDFL1u1iI/AAAAAAAAABg/DonZKthxrww/s320/Clipboard03.png" alt="" id="BLOGGER_PHOTO_ID_5013987516503479842" border="0" /&gt;&lt;/a&gt;In my next post, I'll explain some troubleshooting aids that come with Cohatoe - just in case you encountered any problems on the way.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-3902817470552202188?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/3902817470552202188/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=3902817470552202188' title='5 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3902817470552202188'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/3902817470552202188'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2006/12/simple-example-walkthrough-ii.html' title='Simple example walkthrough II'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://2.bp.blogspot.com/_BynttqNlK3w/RZVACL1u1gI/AAAAAAAAABI/BMNhcBdwzlE/s72-c/Clipboard01.png' height='72' width='72'/><thr:total>5</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-570466865875009813</id><published>2006-12-28T17:47:00.000+01:00</published><updated>2008-12-09T02:08:04.452+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='example'/><category scheme='http://www.blogger.com/atom/ns#' term='tutorial'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Simple example walkthrough I</title><content type='html'>In my last post I have pointed to the first preview of Cohatoe - so, how does one use it?&lt;br /&gt;&lt;br /&gt;First of all a disclaimer: since this is a preview version, the usage of some of the APIs may change; this is so experimental that things may even change repeatedly. Of course I will make a notice of all changes to the APIs here, but before version 1.0 'API' just means 'candidate API'. The bright side of this is of course that it is also open for suggestions, so if you think the public interfaces of Cohatoe could be improved in a particular respect, please let me know.&lt;br /&gt;&lt;br /&gt;Having said that, let me walk you through a very simple example usage of Cohatoe. In this first post, I will cover the basic installation and plugin development part of this. In a follow-up post we will then get to the Cohatoe-specific stuff (compiling the Haskell code, creating interfaces and classes for Eclipse).&lt;br /&gt;&lt;br /&gt;As prerequisites, you need a Java 5 JRE, an Eclipse 3.2 (or higher) SDK installation and a GHC installation. I am myself currently using GHC 6.4.2 and the latest Eclipse 3.3 milestones. (You should be able to use other Haskell compilers, but I've not yet tried any.)&lt;br /&gt;&lt;br /&gt;First of all, go to the &lt;a href="http://leiffrenzel.de/eclipse/cohatoe/"&gt;download page&lt;/a&gt; and download the packaged update site archive and the cohatoe-api archive. Put them in some folder on your disk, say C:\cohatoetest\.&lt;br /&gt;&lt;br /&gt;Fire up Eclipse and install the features in the update site archive, using Eclipse's update manager: select &lt;span style="font-weight: bold;"&gt;Help &gt; Software Updates &gt; Find and Install&lt;/span&gt; from the menu bar.  Then choose &lt;span style="font-weight: bold;"&gt;Search for new features to install &gt; New Archived Site&lt;/span&gt;, and browse to the downloaded file. Press &lt;span style="font-weight: bold;"&gt;OK&lt;/span&gt; and &lt;span style="font-weight: bold;"&gt;Finish&lt;/span&gt;. You get now a list of features to install:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_BynttqNlK3w/RZP2dqH1cRI/AAAAAAAAAAU/PEUTXR433O0/s1600-h/Clipboard01.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://1.bp.blogspot.com/_BynttqNlK3w/RZP2dqH1cRI/AAAAAAAAAAU/PEUTXR433O0/s320/Clipboard01.png" alt="" id="BLOGGER_PHOTO_ID_5013621799577284882" border="0" /&gt;&lt;/a&gt;Select all of them, press &lt;span style="font-weight: bold;"&gt;Finish &lt;/span&gt;and then confirm the licenses etc. etc., until Eclipse wants to restart. Confirm the restart too :-)&lt;br /&gt;&lt;br /&gt;One of the features that you have just installed is the Cohatoe Examples feature. It contains some example code that demonstrates how to use Cohatoe, including the mandatory 'Hello World' menu item which you will find in the global menu bar right after the restart. You can use it to make sure that your installation of Cohatoe works. After clicking that menu item, you should see a dialog with a friendly message from Haskell:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_BynttqNlK3w/RZP3KaH1cSI/AAAAAAAAAAk/3SA7HN1lBoo/s1600-h/Clipboard02.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://4.bp.blogspot.com/_BynttqNlK3w/RZP3KaH1cSI/AAAAAAAAAAk/3SA7HN1lBoo/s320/Clipboard02.png" alt="" id="BLOGGER_PHOTO_ID_5013622568376430882" border="0" /&gt;&lt;/a&gt;In this example, we will just add another such 'Hello' menu item. It will evaluate a Haskell function and give the result of that computation to the user.&lt;br /&gt;&lt;br /&gt;So let's first create a new plugin project. Select from the menu &lt;span style="font-weight: bold;"&gt;File &gt; New &gt; &lt;/span&gt; &lt;span style="font-weight: bold;"&gt;Project &gt; Plugin Project&lt;/span&gt;, enter a name (like 'cohatoetest'), then press &lt;span style="font-weight: bold;"&gt;Next &lt;/span&gt;and again &lt;span style="font-weight: bold;"&gt;Next&lt;/span&gt;. Now select 'Hello world' and press &lt;span style="font-weight: bold;"&gt;Finish&lt;/span&gt;. We have now a Hello-World plugin that we can extend with some useful code. Before we look into the code, right-click the project and select &lt;span style="font-weight: bold;"&gt;Run As &gt; Eclipse Application&lt;/span&gt;. A second Eclipse instance is now started that contains our newly created plugin project as runtime plugin, and you can see the 'Sample Menu' entry in the main menu bar. Make sure that it gives you a message box when clicking it:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_BynttqNlK3w/RZP3fqH1cTI/AAAAAAAAAAs/Sj6p1rIqtvo/s1600-h/Clipboard03.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://1.bp.blogspot.com/_BynttqNlK3w/RZP3fqH1cTI/AAAAAAAAAAs/Sj6p1rIqtvo/s320/Clipboard03.png" alt="" id="BLOGGER_PHOTO_ID_5013622933448651058" border="0" /&gt;&lt;/a&gt;The code that opens up this message box is in the SampleAction class:&lt;br /&gt;&lt;br /&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_BynttqNlK3w/RZP3qaH1cUI/AAAAAAAAAA0/dOugAO0Ve0A/s1600-h/Clipboard04.png"&gt;&lt;img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://4.bp.blogspot.com/_BynttqNlK3w/RZP3qaH1cUI/AAAAAAAAAA0/dOugAO0Ve0A/s320/Clipboard04.png" alt="" id="BLOGGER_PHOTO_ID_5013623118132244802" border="0" /&gt;&lt;/a&gt;and looks like this:&lt;br /&gt;&lt;pre&gt;&lt;code&gt;&lt;br /&gt; &lt;span style="font-weight: bold;"&gt;public void&lt;/span&gt; run( &lt;span style="font-weight: bold;"&gt;final &lt;/span&gt;IAction action ) {&lt;br /&gt;     MessageDialog.openInformation(&lt;br /&gt;         window.getShell(),&lt;br /&gt;         &lt;span style="color: rgb(51, 51, 255);"&gt;"Cohatoetest Plug-in"&lt;/span&gt;,&lt;br /&gt;         &lt;span style="color: rgb(51, 51, 255);"&gt;"Hello, Eclipse world"&lt;/span&gt; );&lt;br /&gt; }&lt;br /&gt;&lt;/code&gt;&lt;/pre&gt;&lt;br /&gt;We will shortly replace the text in this message box with the result of a computation implemented in Haskell. Stay tuned :-)&lt;br /&gt;&lt;br /&gt;(... to be continued)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-570466865875009813?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/570466865875009813/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=570466865875009813' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/570466865875009813'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/570466865875009813'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2006/12/simple-example-walkthrough-i.html' title='Simple example walkthrough I'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://1.bp.blogspot.com/_BynttqNlK3w/RZP2dqH1cRI/AAAAAAAAAAU/PEUTXR433O0/s72-c/Clipboard01.png' height='72' width='72'/><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-38084287.post-116723437951820690</id><published>2006-12-27T16:40:00.000+01:00</published><updated>2006-12-27T16:46:19.526+01:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='announce'/><category scheme='http://www.blogger.com/atom/ns#' term='cohatoe'/><title type='text'>Cohatoe 0.1 preview</title><content type='html'>I have released a first preview version of Cohatoe. Cohatoe stands for 'Contributing Haskell to Eclipse'. It is a library in the form of a Haskell API and a set of Eclipse plugins, that can be used to access code written in Haskell from Eclipse plugins.&lt;br /&gt;&lt;br /&gt;The Haskell code is contributed via an extension in the plugin.xml. Plugins that provide Haskell code in this manner must also contribute a (minimal) Java API for the Haskell code, and of course the object code of their Haskell functions. The Cohatoe runtime uses then &lt;a href="http://www.cse.unsw.edu.au/%7Edons/hs-plugins/"&gt;hs-plugins&lt;/a&gt; to dynamically load and execute the object code.&lt;br /&gt;&lt;br /&gt;You can find download links and the location of the Darcs repository here: &lt;a href="http://leiffrenzel.de/eclipse/cohatoe/"&gt;http://leiffrenzel.de/eclipse/cohatoe/&lt;/a&gt;. I will add more information and announce further versions on this blog. Have fun :-)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/38084287-116723437951820690?l=cohatoe.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://cohatoe.blogspot.com/feeds/116723437951820690/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=38084287&amp;postID=116723437951820690' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/116723437951820690'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/38084287/posts/default/116723437951820690'/><link rel='alternate' type='text/html' href='http://cohatoe.blogspot.com/2006/12/cohatoe-01-preview.html' title='Cohatoe 0.1 preview'/><author><name>Leif Frenzel</name><uri>http://www.blogger.com/profile/06758262715150769180</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='26' src='http://2.bp.blogspot.com/_BynttqNlK3w/S3zkWs85gNI/AAAAAAAAAPo/LPM8kxwc19o/S220/9.png'/></author><thr:total>0</thr:total></entry></feed>
