Re: Leksah

[Hamish Mackenzie]

Hope you don't mind, I am moving this thread to the groups...


On 14 Sep 2012, at 19:13, Michael Snoyman <mic...@snoyman.com> wrote:

> That video was a great intro to how to work with Leksah. Just showing
> the concept of "make a workspace, then a package" is very helpful.

The Leksah version in the video is a little old, but the instructions given still work. The new versions of Leksah will actually prompt you to do just that if you say try File -> New Module without having a package or workspace open. It also gives you the option of creating a workspace in a default location (for people who don't need more than one).

Another feature of newer versions of leksah is that they start up with a "welcome" package all ready to run. This is another area where a "cabal fork" templating system would probably help.

> I have a feeling that the biggest hurdle we're all working with is how
> to integrate nicely with the GHC API. Incremental compiling, grabbing
> type annotations, intelligent code completion, etc.

Indeed, though Leksah's approach in this area recently is probably better described as muddling along with what we have while we wait for Scion to reach a state where it was ready to use. (JP deserves a lot of credit for taking the time to work on on something we might all be able to use).

We put a lot of effort into having Leksah work with any GHCi (by sending commands over stdio), but our dependancy on .hi files for the metadata collector is still GHC version specific (at least that is my understanding Jurgen is the expert in that area).

<Possibly Crazy Idea>
Something I do think Leksah might have to offer in this area is a hook into Debian Haskell. They very kindly put a huge effort into integrating our metadata builder, so that Debian Haskell packages come with Leksah metadata files. They probably don't care what the format is, so if JP has time to look into how the Leksah metadata is built he might be able to tell us if it would be possible to replace the data (or piggyback a new format along with the old). We can change our format with each minor release of Leksah so it would not be hard for us. I'm thinking there might be a simple call we could make from leksah-server to get the new metadata and the write it into the file along with the current metadata.

We might need to warn the Debian Haskell people when it was happening, so the could do it with a GHC release (when they need to rebuild all the packages).

If we did that then Debian Haskell users could get prebuilt data for EclipseFP (and JP's new metadata would be there for Leksah to use too :-) ).

We also have code that downloads the metadata files from a central repository using that might be useful (sometimes our collector is very slow).
</Possibly Crazy Idea>

> I've started a project on Github to try and coordinate efforts:
> https://github.com/fpco/haskell-ide/wiki . Please add whatever ideas
> you have to the wiki. I've also started a Google Group for more people
> to be able to discuss this together:
> https://groups.google.com/d/forum/haskell-ide

Hopefully it will help.

[JP Moresmau]

Hello!

To my shame I've never used Leksah, because when I tried to install it it seemed to hang forever when collecting information from my system... Sorry!

A few initial comments on your mail:

- the concept of workspace and projects (1 project -> 1 package) is essential to Eclipse, so we had to work with it ourselves. The Cabal file is an essential piece of the puzzle: it defines the project and a lot of its features. We need to think if we that this to stay this way, or if we want a more generic package metadata information for an IDE that could be used to generate a Cabal file when the package is generated for deployment.

- I'm not too sure what you mean by "metadata", so I'll briefly discuss what we use in EclipseFP:

  - buildwrapper (the tool that replaced scion at the backend of EclipseFP) generate metadata from the project haskell modules: the AST, the usage information (which functions are used where in the source code). This is of course highly volatile metadata since it depends of the source code being modified by the user

  - EclipseFP uses the buildwrapper usage files to populate a database. This is used for searches ("show me everywhere in my workspace where this function is used")

  - scion-browser uses a database as well for queries on all the packages installed on the system or on hackage. It uses the hoogle files to populate that database.

So as such there is no metadata in the EclipseFP ecosystem that is being delivered with the product, everything is being built from the source files or hoogle. Given the rate at which Micheal uploads packages on hackage, is it reasonable to have pre computed package metadata (-: ? Of course delivering some metadata precomputed would speed up the install as only the most recent packages would have to be retrieved.

BTW, I'm going to be travelling for the next two weeks, which is unusual for me outside of the holidays season, so I may not be too responsive, sorry about that.

JP