[Hackage] #382: 'cabal ghci' mode

newer
Cabal-install and GHC

older
patch applied (cabal): Only pass...

Hackage

28 Oct 2008 28 Oct '08

5:33 a.m.

Show replies by date

Hackage

3 Feb 3 Feb

9:07 p.m.

...

Obviously it should also pre-process any necessary modules, compile C files and call ghci with all the right flags.

Would this still load any previously-built (and not stale) .o files? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/382#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

Hackage

11:23 p.m.

...

Would this still load any previously-built (and not stale) .o files?

I don't see why not. That's up to ghc's normal recompilation checker. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/382#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#382: 'cabal ghci' mode ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: major | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ---------------------------------+------------------------------------------ Changes (by batterseapower): * cc: batterseapower+Cabal382@hotmail.com (added) Comment: I'm about to attach a patch I slapped together that implements this functionality. However, I just talked to Duncan and he says: {{{ dcoutts: BSP_: btw, if possible it'd be nice to export appropriate util functions from the GHC module and actually implement the feature in the cabal program (cabal-install package) [23:36] dcoutts: BSP_: eg we should be able to reuse a function for constructing ghc command lines [23:36] BSP_: it wasn't clear to me what the division of responsibility between cabal and cabal-install was [23:36] dcoutts: BSP_: here's how I see it now... [23:36] dcoutts: the program is for the user interface, it's a tool for devs [23:37] rfh_ left the chat room. [23:37] dcoutts: the lib is there to provide an implementation of the Cabal build system interface, which is currently specified as a command line interface [23:37] thetallguy1 left the chat room. (Read error: 104 (Connection reset by peer)) [23:38] BSP_: ok.. but the line is definitely blurred by the presence of stuff like CommandUI in the Cabal library itself [23:38] cognominal left the chat room. (Read error: 113 (No route to host)) [23:38] dcoutts: the lib has to implement a minimal cli so that package build scripts can call configure, build etc [23:39] dcoutts: BSP_: the crucial test I think is, does the rpm build script need it [23:40] dcoutts: I mean consider a random source rpm that has scripts for doing the build [23:40] BSP_: OK [23:40] dcoutts: it needs to configure, build, haddock, install [23:40] dcoutts: it's a machine api [23:40] dcoutts: where as cabal ghci blah is definitely aimed at end users, humans [23:41] BSP_: right [23:41] BSP_: btw i've called it "cabal interactive" instead, since theoretically you could implement the same thing for other compilers.. [23:42] dcoutts: BSP_: good, I do have qualms about it being too ghc specific [23:42] dcoutts: BSP_: and if people complain about the length of the command then we can remind them that we do provide command line completion! [23:42] BSP_: [23:43] dcoutts: currently only for bash, but others would be easy, the feature is built into cabal itself [23:44] thetallguy1 joined the chat room. [23:53] dcoutts: BSP_: if you're working on that area perhaps I can persuade you to do a little refactoring of the GHC module, particularly the way ghc command lines are constructed [23:54] BSP_: dcoutts: there is a lot of redundancy - but perhaps I should wait for your patches before changing it any further [23:54] dcoutts: Saizan and I started on an approach with a big GhcOptions record and a function renderGhcOptions :: GhcOptions -> [String] [23:55] dcoutts: the idea is that functions that generate or mess with options would use the nice structured GhcOptions values [23:55] dcoutts: I've got half an implementation of the idea I can send you [23:57] dcoutts: BSP_: pushing the changes now... [23:57] BSP_: dcoutts: cheers [00:00] dcoutts: BSP_: some early attempts here http://haskell.org/~duncan/cabal/GHC.hs [00:00] dcoutts: diff it vs the current ./Distribution/Simple/GHC.hs [00:00] pumpkin: oh wow, it's BSP on IRC! [00:01] dcoutts: BSP_: it's the commented out bit about GhcOptions [00:01] dcoutts: BSP_: so we'd make GhcOptions an instance of Monoid and functions like packageHsGhcOptions :: BuildInfo -> LocalBuildInfo -> GhcOptions [00:01] BSP_: pumpkin: hey there i think i recognise your name from github.. [00:02] pumpkin: yup! 'tis me [00:02] BSP_: dcoutts: right, i'll take a look - no promises though [00:02] dcoutts: BSP_: sure [00:02] dcoutts: BSP_: ideally it'd make it easy for you to do the ghci bits in an external module, in cabal-install [00:03] dcoutts: BSP_: ah, of course we'll have to branch cabal-install and have the new head branch use the head version of the Cabal library [00:04] dcoutts: the current stable cabal-install uses the released stable Cabal version [00:06] BSP_: ok }}} So in summary: * The GHC module needs a serious refactoring, perhaps using a GhcOptions monoid * The patch should be for cabal-install, not cabal * The second thing kind of depends on the first, so it makes sense to do these together I'll make these changes to the patch if I find the time, but if not at least the incomplete patch is here with the ticket. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/382#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

Peter Gammie

9 Jun 9 Jun

4:52 a.m.

I'm not sure it's appropriate to respond to tickets here, but here goes... I'd like to see the cabal library support invoking an interpreter in the same way that it supports invoking a compiler, for the simple reason that I want to build a tool on top of it. Specifically, I want to use GHCi to do testing, and it really requires Cabal integration to work well. I have a prototype that I hope to push out the door sometime this month. You can take a look at Lemmih's cabal-test for an example of what a Cabal GHCi API would need to provide (at a minimum). Moreover I think the right generalisation is to think of GHCi/Hugs as interpreters (or as having read-eval loops) and GHC/NHC/JHC/... as batch compilers, and play to the characteristic strengths of each class. Thanks also for your feedback on the test hook. cheers peter On 28/05/2009, at 10:06 AM, Hackage wrote:

...

#382: 'cabal ghci' mode --------------------------------- +------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: major | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: --------------------------------- +------------------------------------------ Changes (by batterseapower):

* cc: batterseapower+Cabal382@hotmail.com (added)

Comment:

I'm about to attach a patch I slapped together that implements this functionality. However, I just talked to Duncan and he says:

{{{ dcoutts: BSP_: btw, if possible it'd be nice to export appropriate util functions from the GHC module and actually implement the feature in the cabal program (cabal-install package) [23:36] dcoutts: BSP_: eg we should be able to reuse a function for constructing ghc command lines [23:36] BSP_: it wasn't clear to me what the division of responsibility between cabal and cabal-install was [23:36] dcoutts: BSP_: here's how I see it now... [23:36] dcoutts: the program is for the user interface, it's a tool for devs [23:37] rfh_ left the chat room. [23:37] dcoutts: the lib is there to provide an implementation of the Cabal build system interface, which is currently specified as a command line interface [23:37] thetallguy1 left the chat room. (Read error: 104 (Connection reset by peer)) [23:38] BSP_: ok.. but the line is definitely blurred by the presence of stuff like CommandUI in the Cabal library itself [23:38] cognominal left the chat room. (Read error: 113 (No route to host)) [23:38] dcoutts: the lib has to implement a minimal cli so that package build scripts can call configure, build etc [23:39] dcoutts: BSP_: the crucial test I think is, does the rpm build script need it [23:40] dcoutts: I mean consider a random source rpm that has scripts for doing the build [23:40] BSP_: OK [23:40] dcoutts: it needs to configure, build, haddock, install [23:40] dcoutts: it's a machine api [23:40] dcoutts: where as cabal ghci blah is definitely aimed at end users, humans [23:41] BSP_: right [23:41] BSP_: btw i've called it "cabal interactive" instead, since theoretically you could implement the same thing for other compilers.. [23:42] dcoutts: BSP_: good, I do have qualms about it being too ghc specific [23:42] dcoutts: BSP_: and if people complain about the length of the command then we can remind them that we do provide command line completion! [23:42] BSP_: [23:43] dcoutts: currently only for bash, but others would be easy, the feature is built into cabal itself [23:44] thetallguy1 joined the chat room. [23:53] dcoutts: BSP_: if you're working on that area perhaps I can persuade you to do a little refactoring of the GHC module, particularly the way ghc command lines are constructed [23:54] BSP_: dcoutts: there is a lot of redundancy - but perhaps I should wait for your patches before changing it any further [23:54] dcoutts: Saizan and I started on an approach with a big GhcOptions record and a function renderGhcOptions :: GhcOptions -> [String] [23:55] dcoutts: the idea is that functions that generate or mess with options would use the nice structured GhcOptions values [23:55] dcoutts: I've got half an implementation of the idea I can send you [23:57] dcoutts: BSP_: pushing the changes now... [23:57] BSP_: dcoutts: cheers [00:00] dcoutts: BSP_: some early attempts here http://haskell.org/~duncan/cabal/GHC.hs [00:00] dcoutts: diff it vs the current ./Distribution/Simple/GHC.hs [00:00] pumpkin: oh wow, it's BSP on IRC! [00:01] dcoutts: BSP_: it's the commented out bit about GhcOptions [00:01] dcoutts: BSP_: so we'd make GhcOptions an instance of Monoid and functions like packageHsGhcOptions :: BuildInfo -> LocalBuildInfo -> GhcOptions [00:01] BSP_: pumpkin: hey there i think i recognise your name from github.. [00:02] pumpkin: yup! 'tis me [00:02] BSP_: dcoutts: right, i'll take a look - no promises though [00:02] dcoutts: BSP_: sure [00:02] dcoutts: BSP_: ideally it'd make it easy for you to do the ghci bits in an external module, in cabal-install [00:03] dcoutts: BSP_: ah, of course we'll have to branch cabal- install and have the new head branch use the head version of the Cabal library [00:04] dcoutts: the current stable cabal-install uses the released stable Cabal version [00:06] BSP_: ok }}}

So in summary:

* The GHC module needs a serious refactoring, perhaps using a GhcOptions monoid * The patch should be for cabal-install, not cabal * The second thing kind of depends on the first, so it makes sense to do these together

I'll make these changes to the patch if I find the time, but if not at least the incomplete patch is here with the ticket.

-- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/382#comment:9

...
Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

-- http://peteg.org/

Hackage

21 Oct 21 Oct

8:47 p.m.

5735

Age (days ago)

6093

Last active (days ago)

List overview

Download

11 comments

2 participants

participants (2)

Hackage
Peter Gammie

[Hackage] #382: 'cabal ghci' mode

tags

participants (2)