[Haskell-cafe] Announcement: Beta of Leksah IDE available
jefferson.r.heard at gmail.com
Fri Apr 3 11:46:59 EDT 2009
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.
On Thu, Apr 2, 2009 at 8:27 AM, jutaro <jnf at arcor.de> 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
> Simon Marlow-7 wrote:
>> David Waern wrote:
>>> 2009/4/2 Duncan Coutts <duncan.coutts at worc.ox.ac.uk>:
>>>> On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:
>>>>> 2009/4/1 jutaro <jnf at arcor.de>:
>>>>>> 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
>>>>>> in the base packages ... This is very handy if it works. Look to the
>>>>>> for details.
>>>>> Maybe could add support to Cabal for installing sources? Should be
>>>>> very useful to have in general.
>>> 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
>> 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
>> 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
>> metadata issues.
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp22816032p22846713.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe