Announcement: Beta of Leksah IDE available

Jürgen Nicklisch-Franken

31 Mar 2009 31 Mar '09

6:20 p.m.

I'm proud to announce release 0.4.4 of Leksah, the Haskell IDE written in Haskell. Leksahs current features include: * On the fly error reporting with location of compilation errors * Completion * Import helper for constructing the import statements * Module browser with navigation to definition * Search for identifiers with information about types and comments * Project management support based on Cabal with a visual editor * Haskell customised editor with "source candy" * Configuration with session support, keymaps and flexible panes For further information: leksah.org Please don't compare what we have reached to IDE's like VisualStudio, Eclipse or NetBeans. I started Leksah June 1997 and work on it in my spare time for fun. I started the project for various reasons. One was to contribute to make Haskell successful in industry, because I suffer from the use of inappropriate programming languages like C, C++, C# or Java in my daily job. Another was to contribute to open source, which I'm using privately almost exclusively. The first alpha version of Leksah was published February 2008. Since the beginning of this year Hamish Mackenzie joined the project and merged his Funa project with Leksah, which gave a real boost. I thank the people who have encouraged and helped me with their comments, enthusiasm and support. I learned as well that the IDE issue is a controversial theme in the community. I learned that "IDEs are big evil nasty things", that "if you need an IDE, something is wrong with your language", that it is scientifically proved, that "real cool hackers will always use Emacs or vi". Most stupid I found the recurring comment: "Every few years there is someone who starts a Haskell IDE project and then gives up after a few years.". That will be true for Leksah as well, if it will not be accepted and supported by the community. The current state of Leksah is a proof of concept, that an IDE for Haskell is not a difficult thing to do if the community supports it and that it will in my view be of great help and will contribute tremendously to spread Haskell. So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude. Jürgen Nicklisch-Franken

Show replies by date

Achim Schneider

31 Mar 31 Mar

7:19 p.m.

J__rgen Nicklisch-Franken wrote:

...

So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude.

I did (the previous version, tbh), and couldn't find anything to seriously bicker about... a few problems regarding metadata generation, but that was dealt with as soon as I RTFM'ed. Ah, yes, you shouldn't be able to close the toolbar by pressing on one of its buttons that incidentally looks just like the one to close a file. Completition already rocks, the interface is nicely configurable (although I resorted to editing config and session files instead of using gui commands[1]), project management worked out fine (after I figured out that I had to manually configure leksah to pass --user to cabal), all in all it's an impressive piece of code that radiates later uberness instead of lacking features. Last, but not least, it's _fast_, _waaaaaaaaay_ more zappy than eclipse. As far as basic IDE features are concerned, it's also complete. The one thing that keeps me from switching to it, right now, is the editor not being a vi. While gtksourceview might be, in theory, a usable editor, my muscle memory tells me otherwise. It'd be like switching to autoconf for C development instead of just copying over my beloved OMakefile. Providing refactoring support would make it irresistible... maybe it's time to add a plugin layer, so that things like vacuum or a wrapper around hp2ps can register themselves with leksah, without giving up their identity as stand-alone projects. Plugability is the one feature that made eclipse big, and it won't hurt leksah, either. [1] I utterly failed to figure out how to do stuff[2], seriously. Eclipse has a really nice drag&drop interface with visual feedback to rearrange stuff, but I'm not the kind of guy who drops a program for lacking such bells&whistles. [2] "Stuff" being rearranging divisions such that it's first split horizontally, the console/type view etc. taking up the bottom part and the upper part being split vertically into source view/module browser. I just can't stand wrapped lines on the console. Somehow, I think it should be the default arrangement. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

jutaro

1 Apr 1 Apr

1:17 p.m.

Thanks Achim, maybe you are right with Plugins. In the moment I'm more focused on adding additional features. But wish the day, that so many want to add features that a plugin system will be essential, we have it. With the GUI arrangement like splitting etc. leksah is quite flexible, but it doesn't support drag and drop, so maybe I'm the only one who knows how to use it. Well our capacity is limited, and no high priority on drag and drop and such thinks. Jürgen Achim Schneider wrote:

...

J__rgen Nicklisch-Franken wrote:

...
So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude.

I did (the previous version, tbh), and couldn't find anything to seriously bicker about... a few problems regarding metadata generation, but that was dealt with as soon as I RTFM'ed. Ah, yes, you shouldn't be able to close the toolbar by pressing on one of its buttons that incidentally looks just like the one to close a file.

Completition already rocks, the interface is nicely configurable (although I resorted to editing config and session files instead of using gui commands[1]), project management worked out fine (after I figured out that I had to manually configure leksah to pass --user to cabal), all in all it's an impressive piece of code that radiates later uberness instead of lacking features. Last, but not least, it's _fast_, _waaaaaaaaay_ more zappy than eclipse. As far as basic IDE features are concerned, it's also complete.

The one thing that keeps me from switching to it, right now, is the editor not being a vi. While gtksourceview might be, in theory, a usable editor, my muscle memory tells me otherwise. It'd be like switching to autoconf for C development instead of just copying over my beloved OMakefile.

Providing refactoring support would make it irresistible... maybe it's time to add a plugin layer, so that things like vacuum or a wrapper around hp2ps can register themselves with leksah, without giving up their identity as stand-alone projects. Plugability is the one feature that made eclipse big, and it won't hurt leksah, either.

[1] I utterly failed to figure out how to do stuff[2], seriously. Eclipse has a really nice drag&drop interface with visual feedback to rearrange stuff, but I'm not the kind of guy who drops a program for lacking such bells&whistles. [2] "Stuff" being rearranging divisions such that it's first split horizontally, the console/type view etc. taking up the bottom part and the upper part being split vertically into source view/module browser. I just can't stand wrapped lines on the console. Somehow, I think it should be the default arrangement.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Neil Mitchell

1:47 p.m.

Hi Just tried it out, a few notes: * Very easy install - if only gtk2hs could be installed with cabal it would have been perfect. * Select the package you have installed. I didn't have a clue what to do here. Do you mean where I keep my Haskell programs? Or where GHC installs them? Can't you figure it out - its a confusing dialog which looks redundant. * Turning off "To Candy" was an essential first step for me! I can perhaps see <- as candy, but replacing $ with diamond is just confusing. * I opened a .cabal file, and expected to see the files in the source in a Window somewhere. I didn't. * The UI feels a little clunky, this could be the Gtk feel of the app (which in time I'd get over), or the choice of UI (the left-pane is quite large). Anything you could do to simplify/streamline the UI would be great. All in all looks quite neat. This is definitely going somewhere, and looks like it will be quite good by the end. Thanks Neil On Wed, Apr 1, 2009 at 6:17 PM, jutaro wrote:

...

Thanks Achim, maybe you are right with Plugins. In the moment I'm more focused on adding additional features. But wish the day, that so many want to add features that a plugin system will be essential, we have it.

With the GUI arrangement like splitting etc. leksah is quite flexible, but it doesn't support drag and drop, so maybe I'm the only one who knows how to use it. Well our capacity is limited, and no high priority on drag and drop and such thinks.

Jürgen

Achim Schneider wrote:

...
J__rgen Nicklisch-Franken wrote:

...
So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude.

I did (the previous version, tbh), and couldn't find anything to seriously bicker about... a few problems regarding metadata generation, but that was dealt with as soon as I RTFM'ed. Ah, yes, you shouldn't be able to close the toolbar by pressing on one of its buttons that incidentally looks just like the one to close a file.

Completition already rocks, the interface is nicely configurable (although I resorted to editing config and session files instead of using gui commands[1]), project management worked out fine (after I figured out that I had to manually configure leksah to pass --user to cabal), all in all it's an impressive piece of code that radiates later uberness instead of lacking features. Last, but not least, it's _fast_, _waaaaaaaaay_ more zappy than eclipse. As far as basic IDE features are concerned, it's also complete.

The one thing that keeps me from switching to it, right now, is the editor not being a vi. While gtksourceview might be, in theory, a usable editor, my muscle memory tells me otherwise. It'd be like switching to autoconf for C development instead of just copying over my beloved OMakefile.

Providing refactoring support would make it irresistible... maybe it's time to add a plugin layer, so that things like vacuum or a wrapper around hp2ps can register themselves with leksah, without giving up their identity as stand-alone projects. Plugability is the one feature that made eclipse big, and it won't hurt leksah, either.

[1] I utterly failed to figure out how to do stuff[2], seriously. Eclipse has a really nice drag&drop interface with visual feedback to rearrange stuff, but I'm not the kind of guy who drops a program for lacking such bells&whistles. [2] "Stuff" being rearranging divisions such that it's first split horizontally, the console/type view etc. taking up the bottom part and the upper part being split vertically into source view/module browser. I just can't stand wrapped lines on the console. Somehow, I think it should be the default arrangement.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jeff Heard

2:50 p.m.

I have one problem so far (and one segfault), but I like the IDE a lot. When I create a new package inside one of my current source directories, it adds all the modules in that directory to *both* the exposed and additional unexposed modules list, resulting in a net zero modules in the package. Is this a known problem? Am I missing something? I can't see how to add or remove modules from either of these lists. -- Jeff On Wed, Apr 1, 2009 at 1:47 PM, Neil Mitchell wrote:

...

Hi

Just tried it out, a few notes:

* Very easy install - if only gtk2hs could be installed with cabal it would have been perfect.

* Select the package you have installed. I didn't have a clue what to do here. Do you mean where I keep my Haskell programs? Or where GHC installs them? Can't you figure it out - its a confusing dialog which looks redundant.

* Turning off "To Candy" was an essential first step for me! I can perhaps see <- as candy, but replacing $ with diamond is just confusing.

* I opened a .cabal file, and expected to see the files in the source in a Window somewhere. I didn't.

* The UI feels a little clunky, this could be the Gtk feel of the app (which in time I'd get over), or the choice of UI (the left-pane is quite large). Anything you could do to simplify/streamline the UI would be great.

All in all looks quite neat. This is definitely going somewhere, and looks like it will be quite good by the end.

Thanks

Neil

On Wed, Apr 1, 2009 at 6:17 PM, jutaro wrote:

...
Thanks Achim, maybe you are right with Plugins. In the moment I'm more focused on adding additional features. But wish the day, that so many want to add features that a plugin system will be essential, we have it.

With the GUI arrangement like splitting etc. leksah is quite flexible, but it doesn't support drag and drop, so maybe I'm the only one who knows how to use it. Well our capacity is limited, and no high priority on drag and drop and such thinks.

Jürgen

Achim Schneider wrote:

...
J__rgen Nicklisch-Franken wrote:

...
So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude.

I did (the previous version, tbh), and couldn't find anything to seriously bicker about... a few problems regarding metadata generation, but that was dealt with as soon as I RTFM'ed. Ah, yes, you shouldn't be able to close the toolbar by pressing on one of its buttons that incidentally looks just like the one to close a file.

Completition already rocks, the interface is nicely configurable (although I resorted to editing config and session files instead of using gui commands[1]), project management worked out fine (after I figured out that I had to manually configure leksah to pass --user to cabal), all in all it's an impressive piece of code that radiates later uberness instead of lacking features. Last, but not least, it's _fast_, _waaaaaaaaay_ more zappy than eclipse. As far as basic IDE features are concerned, it's also complete.

The one thing that keeps me from switching to it, right now, is the editor not being a vi. While gtksourceview might be, in theory, a usable editor, my muscle memory tells me otherwise. It'd be like switching to autoconf for C development instead of just copying over my beloved OMakefile.

Providing refactoring support would make it irresistible... maybe it's time to add a plugin layer, so that things like vacuum or a wrapper around hp2ps can register themselves with leksah, without giving up their identity as stand-alone projects. Plugability is the one feature that made eclipse big, and it won't hurt leksah, either.

[1] I utterly failed to figure out how to do stuff[2], seriously. Eclipse has a really nice drag&drop interface with visual feedback to rearrange stuff, but I'm not the kind of guy who drops a program for lacking such bells&whistles. [2] "Stuff" being rearranging divisions such that it's first split horizontally, the console/type view etc. taking up the bottom part and the upper part being split vertically into source view/module browser. I just can't stand wrapped lines on the console. Somehow, I think it should be the default arrangement.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

jutaro

4:11 p.m.

Hi Jeff, I just tried it out and it didn't work for me too. So I've released it to early I guess. One problem I see is that the background build is even active when no project is open. So it always ask you to open a file, and you can't cancel this. This can be avoided by unselecting the symbol in the toolbar that looks like a recycle sign. Switch it on again, if you're ready with a project. I will fix this in the next release. However, in the visual cabal editor, can't you select and unselect modules in a checkbox at the side? Jürgen I have one problem so far (and one segfault), but I like the IDE a lot. When I create a new package inside one of my current source directories, it adds all the modules in that directory to *both* the exposed and additional unexposed modules list, resulting in a net zero modules in the package. Is this a known problem? Am I missing something? I can't see how to add or remove modules from either of these lists. -- Jeff -- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

jutaro

4:01 p.m.

Hi Neil, Neil Mitchell wrote:

...

Hi

Just tried it out, a few notes:

* Very easy install - if only gtk2hs could be installed with cabal it would have been perfect.

* Select the package you have installed. I didn't have a clue what to do here. Do you mean where I keep my Haskell programs? Or where GHC installs them? Can't you figure it out - its a confusing dialog which looks redundant.

I guess you mean the dialog which should help leksah to find sources for installed packages. It needs this so you can go to all the definitions in the base packages ... This is very handy if it works. Look to the manual for details. Neil Mitchell wrote:

...

* Turning off "To Candy" was an essential first step for me! I can perhaps see <- as candy, but replacing $ with diamond is just confusing.

Yeah, I've should have taken this out. But just edit the candy file to your taste. Neil Mitchell wrote:

...

* I opened a .cabal file, and expected to see the files in the source in a Window somewhere. I didn't.

Yes, thats a bit of a problem. As 1. the project has to be compiled. and 2. metadata has to be collected. Then it appears in the modules window. Neil Mitchell wrote:

...

* The UI feels a little clunky, this could be the Gtk feel of the app (which in time I'd get over), or the choice of UI (the left-pane is quite large). Anything you could do to simplify/streamline the UI would be great.

You can do some adjustments on your own. On MS Windows we have some problems though. Neil Mitchell wrote:

...

All in all looks quite neat. This is definitely going somewhere, and looks like it will be quite good by the end.

Thanks Jürgen Neil Mitchell wrote:

...

Thanks Neil

On Wed, Apr 1, 2009 at 6:17 PM, jutaro wrote:

...
Thanks Achim, maybe you are right with Plugins. In the moment I'm more focused on adding additional features. But wish the day, that so many want to add features that a plugin system will be essential, we have it.

With the GUI arrangement like splitting etc. leksah is quite flexible, but it doesn't support drag and drop, so maybe I'm the only one who knows how to use it. Well our capacity is limited, and no high priority on drag and drop and such thinks.

Jürgen

Achim Schneider wrote:

...
J__rgen Nicklisch-Franken wrote:

...
So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude.

I did (the previous version, tbh), and couldn't find anything to seriously bicker about... a few problems regarding metadata generation, but that was dealt with as soon as I RTFM'ed. Ah, yes, you shouldn't be able to close the toolbar by pressing on one of its buttons that incidentally looks just like the one to close a file.

Completition already rocks, the interface is nicely configurable (although I resorted to editing config and session files instead of using gui commands[1]), project management worked out fine (after I figured out that I had to manually configure leksah to pass --user to cabal), all in all it's an impressive piece of code that radiates later uberness instead of lacking features. Last, but not least, it's _fast_, _waaaaaaaaay_ more zappy than eclipse. As far as basic IDE features are concerned, it's also complete.

The one thing that keeps me from switching to it, right now, is the editor not being a vi. While gtksourceview might be, in theory, a usable editor, my muscle memory tells me otherwise. It'd be like switching to autoconf for C development instead of just copying over my beloved OMakefile.

Providing refactoring support would make it irresistible... maybe it's time to add a plugin layer, so that things like vacuum or a wrapper around hp2ps can register themselves with leksah, without giving up their identity as stand-alone projects. Plugability is the one feature that made eclipse big, and it won't hurt leksah, either.

[1] I utterly failed to figure out how to do stuff[2], seriously. Eclipse has a really nice drag&drop interface with visual feedback to rearrange stuff, but I'm not the kind of guy who drops a program for lacking such bells&whistles. [2] "Stuff" being rearranging divisions such that it's first split horizontally, the console/type view etc. taking up the bottom part and the upper part being split vertically into source view/module browser. I just can't stand wrapped lines on the console. Somehow, I think it should be the default arrangement.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

David Waern

4:13 p.m.

2009/4/1 jutaro :

...

I guess you mean the dialog which should help leksah to find sources for installed packages. It needs this so you can go to all the definitions in the base packages ... This is very handy if it works. Look to the manual for details.

Maybe could add support to Cabal for installing sources? Should be very useful to have in general. David

Duncan Coutts

2 Apr 2 Apr

5:56 a.m.

On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:

...

2009/4/1 jutaro :

...
I guess you mean the dialog which should help leksah to find sources for installed packages. It needs this so you can go to all the definitions in the base packages ... This is very handy if it works. Look to the manual for details.

Maybe could add support to Cabal for installing sources? Should be very useful to have in general.

http://hackage.haskell.org/trac/hackage/ticket/364 Duncan

David Waern

7:24 a.m.

2009/4/2 Duncan Coutts :

...

On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:

...
2009/4/1 jutaro :

...
I guess you mean the dialog which should help leksah to find sources for installed packages. It needs this so you can go to all the definitions in the base packages ... This is very handy if it works. Look to the manual for details.

Maybe could add support to Cabal for installing sources? Should be very useful to have in general.

http://hackage.haskell.org/trac/hackage/ticket/364

Jutaru, perhaps a nice Hackathon project? :-) David

Simon Marlow

8:09 a.m.

David Waern wrote:

...

2009/4/2 Duncan Coutts :

...
On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:

...
2009/4/1 jutaro :

...
I guess you mean the dialog which should help leksah to find sources for installed packages. It needs this so you can go to all the definitions in the base packages ... This is very handy if it works. Look to the manual for details. Maybe could add support to Cabal for installing sources? Should be very useful to have in general. http://hackage.haskell.org/trac/hackage/ticket/364

Jutaru, perhaps a nice Hackathon project? :-)

I think there's some design work to do there. See the discussion on the GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2630. In short: just keeping the source code around isn't enough. You need some metadata in order to make sense of the source code - for example, you can't feed the source code to the GHC API without knowing which additional flags need to be passed, and those come from the .cabal file. Also you probably want to stash the results of the 'cabal configure' step so that you can get a view of the source code that is consistent with the version(s?) you compiled. We need to think about about backwards and forwards-compatibility of whatever metadata format is used. And then you'll need Cabal APIs to extract the metadata. So we need to think about what APIs make sense, and the best way to do that is to think about what tool(s) you want to write and use that to drive the API design. Perhaps all this is going a bit too far. Maybe we want to just stash the source code and accept that there are some things that you just can't do with it. However, I imagine that pretty soon people will want to feed the source code into the GHC API, and at that point we have to tackle the build metadata issues. Cheers, Simon

jutaro

8:27 a.m.

Hi Simon, you quite nicely describe what leksah is doing already. Try to find find the source code for all installed packages by locating cabal files, parse the module sources via the Ghc API (actually not so much the API), using info from cabal files for this (which is a dark art). It extracts comments and locations. It's quite an ad hoc solution. On my machine it's 97% successful, but its a notorious support theme, because it depends so much on the environment. Jürgen Simon Marlow-7 wrote:

...

David Waern wrote:

...
2009/4/2 Duncan Coutts :

...
On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:

...
2009/4/1 jutaro :

...
I guess you mean the dialog which should help leksah to find sources for installed packages. It needs this so you can go to all the definitions in the base packages ... This is very handy if it works. Look to the manual for details. Maybe could add support to Cabal for installing sources? Should be very useful to have in general. http://hackage.haskell.org/trac/hackage/ticket/364

Jutaru, perhaps a nice Hackathon project? :-)

I think there's some design work to do there. See the discussion on the GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2630.

In short: just keeping the source code around isn't enough. You need some metadata in order to make sense of the source code - for example, you can't feed the source code to the GHC API without knowing which additional flags need to be passed, and those come from the .cabal file. Also you probably want to stash the results of the 'cabal configure' step so that you can get a view of the source code that is consistent with the version(s?) you compiled. We need to think about about backwards and forwards-compatibility of whatever metadata format is used.

And then you'll need Cabal APIs to extract the metadata. So we need to think about what APIs make sense, and the best way to do that is to think about what tool(s) you want to write and use that to drive the API design.

Perhaps all this is going a bit too far. Maybe we want to just stash the source code and accept that there are some things that you just can't do with it. However, I imagine that pretty soon people will want to feed the source code into the GHC API, and at that point we have to tackle the build metadata issues.

Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Jeff Heard

3 Apr 3 Apr

11:46 a.m.

Jurgen... I have one more question, or rather request... I'm running under Ubuntu, and I get inconsistencies with packages that I build and install via Leksah not showing up when I configure other packages that depend on them. Then I notice that you're using runhaskell Setup.lhs ... to configure build and install. I wonder if you could change all that from "runhaskell Setup.lhs" to "cabal" wherever you run it? That would make things a lot more consistent overall, and probably jive better with the way most people install packages. -- Jeff On Thu, Apr 2, 2009 at 8:27 AM, jutaro wrote:

...

Hi Simon, you quite nicely describe what leksah is doing already. Try to find find the source code for all installed packages by locating cabal files, parse the module sources via the Ghc API (actually not so much the API), using info from cabal files for this (which is a dark art). It extracts comments and locations. It's quite an ad hoc solution. On my machine it's 97% successful, but its a notorious support theme, because it depends so much on the environment. Jürgen

Simon Marlow-7 wrote:

...
David Waern wrote:

...
2009/4/2 Duncan Coutts :

...
On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:

...
2009/4/1 jutaro :

...
I guess you mean the dialog which should help leksah to find sources for installed packages. It needs this so you can go to all the definitions in the base packages ... This is very handy if it works. Look to the manual for details. Maybe could add support to Cabal for installing sources? Should be very useful to have in general. http://hackage.haskell.org/trac/hackage/ticket/364

Jutaru, perhaps a nice Hackathon project? :-)

I think there's some design work to do there. See the discussion on the GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2630.

In short: just keeping the source code around isn't enough. You need some metadata in order to make sense of the source code - for example, you can't feed the source code to the GHC API without knowing which additional flags need to be passed, and those come from the .cabal file. Also you probably want to stash the results of the 'cabal configure' step so that you can get a view of the source code that is consistent with the version(s?) you compiled. We need to think about about backwards and forwards-compatibility of whatever metadata format is used.

And then you'll need Cabal APIs to extract the metadata. So we need to think about what APIs make sense, and the best way to do that is to think about what tool(s) you want to write and use that to drive the API design.

Perhaps all this is going a bit too far. Maybe we want to just stash the source code and accept that there are some things that you just can't do with it. However, I imagine that pretty soon people will want to feed the source code into the GHC API, and at that point we have to tackle the build metadata issues.

Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

jutaro

12:25 p.m.

Hello Jeff, I'm not so shure if I understand what you mean (and I'm off for vacations in a few minute). So lets find out later. But you may try to set the --user to your config flags in menu: Packages/Edit Flags. Jürgen Jeff Heard wrote:

...

Jurgen... I have one more question, or rather request... I'm running under Ubuntu, and I get inconsistencies with packages that I build and install via Leksah not showing up when I configure other packages that depend on them. Then I notice that you're using runhaskell Setup.lhs ... to configure build and install. I wonder if you could change all that from "runhaskell Setup.lhs" to "cabal" wherever you run it? That would make things a lot more consistent overall, and probably jive better with the way most people install packages.

-- Jeff

On Thu, Apr 2, 2009 at 8:27 AM, jutaro wrote:

...
Hi Simon, you quite nicely describe what leksah is doing already. Try to find find the source code for all installed packages by locating cabal files, parse the module sources via the Ghc API (actually not so much the API), using info from cabal files for this (which is a dark art). It extracts comments and locations. It's quite an ad hoc solution. On my machine it's 97% successful, but its a notorious support theme, because it depends so much on the environment. Jürgen

Simon Marlow-7 wrote:

...
David Waern wrote:

...
2009/4/2 Duncan Coutts :

...
On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:

...
2009/4/1 jutaro : > I guess you mean the dialog which should help leksah to find sources > for installed packages. It needs this so you can go to all the > definitions > in the base packages ... This is very handy if it works. Look to the > manual > for details. Maybe could add support to Cabal for installing sources? Should be very useful to have in general. http://hackage.haskell.org/trac/hackage/ticket/364

Jutaru, perhaps a nice Hackathon project? :-)

I think there's some design work to do there. See the discussion on the GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2630.

In short: just keeping the source code around isn't enough. You need some metadata in order to make sense of the source code - for example, you can't feed the source code to the GHC API without knowing which additional flags need to be passed, and those come from the .cabal file. Also you probably want to stash the results of the 'cabal configure' step so that you can get a view of the source code that is consistent with the version(s?) you compiled. We need to think about about backwards and forwards-compatibility of whatever metadata format is used.

And then you'll need Cabal APIs to extract the metadata. So we need to think about what APIs make sense, and the best way to do that is to think about what tool(s) you want to write and use that to drive the API design.

Perhaps all this is going a bit too far. Maybe we want to just stash the source code and accept that there are some things that you just can't do with it. However, I imagine that pretty soon people will want to feed the source code into the GHC API, and at that point we have to tackle the build metadata issues.

Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Henning Thielemann

4 Apr 4 Apr

6:38 p.m.

On Fri, 3 Apr 2009, Jeff Heard wrote:

...

Jurgen... I have one more question, or rather request... I'm running under Ubuntu, and I get inconsistencies with packages that I build and install via Leksah not showing up when I configure other packages that depend on them. Then I notice that you're using runhaskell Setup.lhs ... to configure build and install. I wonder if you could change all that from "runhaskell Setup.lhs" to "cabal" wherever you run it?

I think 'cabal' has more dependencies (zlib, HTTP) and is thus more difficult to port than Setup.lhs.

jutaro

1 Apr 1 Apr

1:30 a.m.

I know its 1. of April, but when I wrote that I started with Leksah June 1997 it was no intentional joke, it was just late at night. I started June 2007. Jürgen jutaro wrote:

...

I'm proud to announce release 0.4.4 of Leksah, the Haskell IDE written in Haskell. Leksahs current features include: * On the fly error reporting with location of compilation errors * Completion * Import helper for constructing the import statements * Module browser with navigation to definition * Search for identifiers with information about types and comments * Project management support based on Cabal with a visual editor * Haskell customised editor with "source candy" * Configuration with session support, keymaps and flexible panes For further information: leksah.org

Please don't compare what we have reached to IDE's like VisualStudio, Eclipse or NetBeans. I started Leksah June 1997 and work on it in my spare time for fun. I started the project for various reasons. One was to contribute to make Haskell successful in industry, because I suffer from the use of inappropriate programming languages like C, C++, C# or Java in my daily job. Another was to contribute to open source, which I'm using privately almost exclusively. The first alpha version of Leksah was published February 2008. Since the beginning of this year Hamish Mackenzie joined the project and merged his Funa project with Leksah, which gave a real boost.

I thank the people who have encouraged and helped me with their comments, enthusiasm and support. I learned as well that the IDE issue is a controversial theme in the community. I learned that "IDEs are big evil nasty things", that "if you need an IDE, something is wrong with your language", that it is scientifically proved, that "real cool hackers will always use Emacs or vi". Most stupid I found the recurring comment: "Every few years there is someone who starts a Haskell IDE project and then gives up after a few years.". That will be true for Leksah as well, if it will not be accepted and supported by the community. The current state of Leksah is a proof of concept, that an IDE for Haskell is not a difficult thing to do if the community supports it and that it will in my view be of great help and will contribute tremendously to spread Haskell.

So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude.

Jürgen Nicklisch-Franken

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Benjamin L.Russell

2:29 a.m.

Your logo, a lowercase lambda merged with an inverted version of the same sharing a single spine, loosely resembles an uppercase 'H', and could possibly serve as a Haskell logo. It is simple, can represent simultaneously both "lambda" and "Haskell," and can easily be enlarged or reduced without loss of legibility. Why didn't you submit it in the Haskell Logo Competition? The next time this competition comes around, if you don't mind, please submit this logo as an entry! -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

jutaro

12:59 p.m.

Hi Benjamin, Nice that you like the logo. The idea to turn the lambda around came from the name of the project. But actually I'm feeling totally incapable of graphics design and the icons coming with leksah are an example of bitty plagiarism. So I will definitely not participate in any Logo competition, but feel free to use the idea. By the way, if you have any inclination for this, may you like to help with the graphic design of the leksah a bit? E.g. We have this little symbols representing data, newtype, variable, class ... They all look awful. Jürgen Nicklisch-Franken Benjamin L.Russell wrote:

...

Your logo, a lowercase lambda merged with an inverted version of the same sharing a single spine, loosely resembles an uppercase 'H', and could possibly serve as a Haskell logo. It is simple, can represent simultaneously both "lambda" and "Haskell," and can easily be enlarged or reduced without loss of legibility. Why didn't you submit it in the Haskell Logo Competition?

The next time this competition comes around, if you don't mind, please submit this logo as an entry!

-- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Henning Thielemann

4:24 p.m.

On Wed, 1 Apr 2009, Benjamin L.Russell wrote:

...

Your logo, a lowercase lambda merged with an inverted version of the same sharing a single spine, loosely resembles an uppercase 'H', and could possibly serve as a Haskell logo. It is simple, can represent simultaneously both "lambda" and "Haskell," and can easily be enlarged or reduced without loss of legibility. Why didn't you submit it in the Haskell Logo Competition?

Because it is already the Leksah logo? :-)

John Van Enk

3 Apr 3 Apr

2:26 p.m.

What's the chance things like hsc2hs and c2hs will ever be supported? :) I'm aware this is a horribly difficult task (or I think it is). Perhaps it would be possible to find the .hsc and .chs files and run the corresponding processor over them and extract data/types/functions from the corresponding .hs files? I tried running leksah on one of my projects which uses a lot of FFI without much success. /jve 2009/3/31 Jürgen Nicklisch-Franken

...

I'm proud to announce release 0.4.4 of Leksah, the Haskell IDE written in Haskell. Leksahs current features include: * On the fly error reporting with location of compilation errors * Completion * Import helper for constructing the import statements * Module browser with navigation to definition * Search for identifiers with information about types and comments * Project management support based on Cabal with a visual editor * Haskell customised editor with "source candy" * Configuration with session support, keymaps and flexible panes For further information: leksah.org

Please don't compare what we have reached to IDE's like VisualStudio, Eclipse or NetBeans. I started Leksah June 1997 and work on it in my spare time for fun. I started the project for various reasons. One was to contribute to make Haskell successful in industry, because I suffer from the use of inappropriate programming languages like C, C++, C# or Java in my daily job. Another was to contribute to open source, which I'm using privately almost exclusively. The first alpha version of Leksah was published February 2008. Since the beginning of this year Hamish Mackenzie joined the project and merged his Funa project with Leksah, which gave a real boost.

I thank the people who have encouraged and helped me with their comments, enthusiasm and support. I learned as well that the IDE issue is a controversial theme in the community. I learned that "IDEs are big evil nasty things", that "if you need an IDE, something is wrong with your language", that it is scientifically proved, that "real cool hackers will always use Emacs or vi". Most stupid I found the recurring comment: "Every few years there is someone who starts a Haskell IDE project and then gives up after a few years.". That will be true for Leksah as well, if it will not be accepted and supported by the community. The current state of Leksah is a proof of concept, that an IDE for Haskell is not a difficult thing to do if the community supports it and that it will in my view be of great help and will contribute tremendously to spread Haskell.

So I please the members of the community to pause for a moment and try out Leksah with a benevolent attitude.

Jürgen Nicklisch-Franken

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /jve

5891

Age (days ago)

5895

Last active (days ago)

List overview

Download

19 comments

11 participants

participants (11)

Achim Schneider
Benjamin L.Russell
David Waern
Duncan Coutts
Henning Thielemann
Jeff Heard
John Van Enk
jutaro
Jürgen Nicklisch-Franken
Neil Mitchell
Simon Marlow