On Wed, Oct 31, 2012 at 2:52 PM, Mikhail Glushenkov < the.dead.shall.rise@gmail.com> wrote:

On Wed, Oct 31, 2012 at 6:22 PM, Johan Tibell wrote:> Since sandboxing is working today (with a few minor tweaks yet to be

...

done) and it can be transparently replaced with a better solution once we have one, I think we should enable it by default in 1.18.

Will that be the next cabal-install release or the one after that?

The next one. -- Johan

Recently, I had to add a MIN_VERSION macro to my code because of the old-time / time change in directory, but couldn't test the library in ghci because the macro was not defined.

I discovered that configuring ghci with

:set -optP-include -optPdist/build/autogen/cabal_macros.h

tells ghci about the macro, but I find this even more cumbersome than dist/build/<executable>/<executable>.

So, if I'm not missing something, it may also be comfortable to add a

cabal ghci

command which tells ghci about cabal's configuration.

You can put the required options in a .ghci file in you project root. I use [3] as a starting point for new projects, [2] and [3] are real world examples. `cabal ghci` could still be useful, but I think a general solution is not trivial. It would probably need to accept qualified targets, e.g. `ghci test:properties` to start ghci in a way suitable for a test-suite with the name "properties". Moreover, it would be awesome if it would regenerate generated source files on :reload. I'm not sure if this is feasible without changes to GHCi, but a custom macro, e.g. :cabal-reload could still work. Cheers, Simon [1] http://hpaste.org/77144 [2] https://github.com/ghc/haddock/blob/ghc-7.6/.ghci [3] https://github.com/sol/doctest-haskell/blob/master/.ghci

On Fri, 2012-11-02 at 11:25 +0100, Simon Hengel wrote:

...

Recently, I had to add a MIN_VERSION macro to my code because of the old-time / time change in directory, but couldn't test the library in ghci because the macro was not defined.

I discovered that configuring ghci with

:set -optP-include -optPdist/build/autogen/cabal_macros.h

tells ghci about the macro, but I find this even more cumbersome than dist/build/<executable>/<executable>.

So, if I'm not missing something, it may also be comfortable to add a

cabal ghci

command which tells ghci about cabal's configuration.

You can put the required options in a .ghci file in you project root. I use [3] as a starting point for new projects, [2] and [3] are real world examples.

`cabal ghci` could still be useful, but I think a general solution is not trivial. It would probably need to accept qualified targets, e.g. `ghci test:properties` to start ghci in a way suitable for a test-suite with the name "properties".

Yes, we have been working on this. Last weekend I was updating the code for doing the qualified target stuff cabal build exe:foo etc.

Moreover, it would be awesome if it would regenerate generated source files on :reload. I'm not sure if this is feasible without changes to GHCi, but a custom macro, e.g.

:cabal-reload

could still work.

The GSoC project that started this off did that, and the necessary changes are in ghc now. Duncan

On Fri, 2012-11-02 at 16:52 +0100, Simon Hengel wrote:

Duncan,

...

...

Moreover, it would be awesome if it would regenerate generated source files on :reload. I'm not sure if this is feasible without changes to GHCi, but a custom macro, e.g.

:cabal-reload

could still work.

The GSoC project that started this off did that, and the necessary changes are in ghc now.

That is interesting. I'd be interested in how exactly that works. Is there a place where I can read about it? Or if not, can you point me to the related commits?

http://lambdasandwich.blogspot.co.uk/2011/08/ending-gsoc.html For the changes to ghci see the ghc git repo. Look for stuff related to .ghci file handling. That was the main extension needed, so we could specify a .ghci file on the command line. Duncan

Hi, On Fri, Nov 2, 2012 at 10:48 AM, Björn Peemöller wrote:

So, if I'm not missing something, it may also be comfortable to add a

cabal ghci

command which tells ghci about cabal's configuration.

There was a "cabal repl" GSoC project last year. The patches haven't been merged yet, since they require some reworking. Duncan knows more about the current state of affairs. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On Fri, Nov 2, 2012 at 8:43 AM, Duncan Coutts wrote:

...

*cabal build should imply cabal install --only-dependencies * If you're currently working on a package, the right [1] way to build it is as follows:

cabal install --only-dependencies cabal build

I've been thinking along similar lines recently. We should be thinking about package environments (which spans multiple packages) rather than individual packages, and the UI should reflect that. Right now it's very much centred on individual packages, not collections.

So "cabal configure" should configure/reconfigure the package environment, not the individual package. It should make an install plan for the current environment (which at minimum is a single target package and its dependencies but could be several packages in the same env). Then of course executing that install plan by building any of the targets should go and build deps as necessary.

Should I interpret this as you're in favor of the first steps towards such a change, as described above (automatically install dependencies), with a flag to opt out? -- Johan

Hi, On Thu, Nov 29, 2012 at 3:45 PM, Simon Hengel wrote:

So personally I think it is a better approach to first release the feature, and give people time to try whether there use case are covered.

The idea is to put out a release candidate some time before the final release to give people an opportunity to voice their concerns.

For context: I run my test in GHCi. Sometimes this requires some work, but I have a working setup for all my projects. For me (and probably for others who are serious about TDD), the sandbox feature is only useful if running tests within GHCi works.

This will probably be covered by the "cabal repl" feature that Duncan is working on. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Hi Simon, On Thu, Nov 29, 2012 at 6:45 AM, Simon Hengel wrote:

Hi Johan,

On Wed, Oct 31, 2012 at 10:22:36AM -0700, Johan Tibell wrote:

...

*Sandboxing should be used by default*

I'm a little bit late on this one. But I'm somewhat skeptical here. As I understand it, the sandboxing feature is not yet released. I think there is a chance that the first version will not cover all use cases.

So personally I think it is a better approach to first release the feature, and give people time to try whether there use case are covered.

We may very well end up doing this. There's no rush to make it default. We can make a release with opt-in sandboxes and decide three months later if we want to make it the default. -- Johan

On Thu, Nov 29, 2012 at 8:20 AM, Simon Hengel wrote:

On Thu, Nov 29, 2012 at 07:54:34AM -0800, Johan Tibell wrote:

...

We may very well end up doing this. There's no rush to make it default. We can make a release with opt-in sandboxes and decide three months later if we want to make it the default.

Nice.

So I guess the idea is that we will have a release candidate (as Mikhail suggested). If there are major issues that we can't get fixed before the release, we make it opt-in?

We might make it opt-in in any case, since we cannot really test everyone's usage patterns. I think what we'll do is to make it opt-in and at the same time announce our intentions to make it default and encourage people to try it out for an extended period of time. -- Johan