April 2005 - Libraries

Re: Cabal Installing Executables
by Dominic Steinitz 20 Apr '05

20 Apr '05

On Saturday 16 Apr 2005 9:10 am, Niklas Broberg wrote: > > Can someone tell me what I have to do to install the executables in the > > current directory or my home directory and also set the permissions (and > > ownership) to be that of the installer? > > Give the flag --prefix=/my/chosen/dir when you run ./Setup configure, > that will put the executables in /my/chosen/dir/bin. Very handy. =) > > /Niklas Niklas, Thanks for this. It doesn't quite do what I want. I want the executables in /my/chosen/dir/bin but the library to be in /usr/local/lib rather than /my/chosen/dir/lib. Actually now I think about it, what I really want is for the user of the package would build it, test it and then install it. The executables are actually tests and examples. I'd like the installer to be able to run the tests locally and then, if they are happy, install it. I suppose a solution is: 1. ./Setup configure --prefix=/my/chosen/dir ./Setup build ./Setup install --user 2. Run the tests in /my/chosen/dir/bin 3. ./Setup unregister --user ./Setup clean ./Setup configure ./Setup build ./Setup install One final thought: why is there no uninstall? Dominic.

4 5

RE: Cabal vs Haskell (was RE: build-depends harmful (was RE: import resolution))
by Simon Marlow 20 Apr '05

20 Apr '05

On 20 April 2005 02:00, S. Alexander Jacobson wrote: > You appear be proposing to change the definition of a Haskell program > from a set of Haskell modules connected by import to a set of Cabal > packages connected by build-depends. Not at all - the definition of a Haskell program is still a collection of modules with distinct names. If we were to "lift the overlap restriction" then the definition would change to a collection of modules with distinct (package name, module name) pairs. Two changes are required: - define module name as (package name, module name) pair - in the context of each module's source, there is a mapping from module name to package name that is used to resolve an import. the definition doesn't require Cabal, or build-depends. Given that this model doesn't rely on Cabal or build-depends, I'm afraid I don't understand the rest of your post. I think you may have misunderstood what the module overlap restriction is. > == Lifting The Overlap Restriction == > > The Haskell model is much simpler for the user and sacrifices little > expressive power. > > Under the Haskell model, M.T means the same thing in every module and > lifting the overlap restriction means programs just have a lookup > table mapping module names to module locations; resolution follows > simply and directly without worrying about package structure. If programs are still collections of modules with distinct names, then the module overlap restriction is still in place. Perhaps you could define some terms more precisely, to avoid confusion: for example things like "module location", and what you understand by "overlap restriction". Cheers, Simon

2 1

RE: Cabal compiling with profiling
by Simon Marlow 20 Apr '05

20 Apr '05

We could extend the .cabal syntax along the lines of: Package: foo Version: 1.0 etc. extensions: CPP extra-libraries: X11 [Release] ghc-options: -O2 [Debug] ghc-options: -O0 -DDEBUG and extend PackageDescription to include multiple BuildInfos, each with an attached configuration tag. How does that sound? The .cabal syntax remains backwards compatible. Cheers, Simon On 20 April 2005 09:07, Krasimir Angelov wrote: > What I have in mind is to have multiple .buildinfo files. One for each > configuration. For example <pkg>.buildinfo.debug & > <pkg>.buildinfo.release. Each hook can check for a specific > --config=<..> command line option and will load the appropriate > .buildinfo file. The disadvantage here is that in this way I need to > maintain multiple files in addition to the central .cabal file. > Another trouble is that with hooks API I cann't change the destination > directory where the .hi and .o files are created. They all will go to > dist/build while I need to keep them separated. > > It would be simpler if the Cabal library was aware of this > configurations. In this case the configuration descriptions can be > moved to .cabal file. We can have few predefined configurations like > "Debug", "Release", "Profiling", ... which are always with predefined > options. For Debug we can add -DDEBUG option to GHC, for Release -O > option and maybe -split-obj and for Profiling -prof option. Of course > we have to leave the user to change the default options and he have to > be able to define its own configurations. > > Cheers, > Krasimir > > On 4/19/05, Isaac Jones <ijones(a)syntaxpolice.org> wrote: >> Krasimir Angelov <kr.angelov(a)gmail.com> writes: >> >>> We need something more general in VSHaskell. Usually each project in >>> the Visual Studio environment has two configurations "Debug" and >>> "Release" but the user can define his own configurations. The only >>> difference between each configuration is in the command line >>> switches passed to the compiler. >> >> Or to the configure step? >> >>> For Haskell projects this mean that each configuration will have >>> different HookedBuildInfo associated. The profiling can be >>> implemented in this more general framework if we add "Profiling" >>> configuration. I still don't have clear design for configurations in >>> Cabal. My first thought was that I can do this on top of hooks API >>> but I am not sure whether it will be flexible enough. >> >> Can you flesh this out a bit? What do you mean by "configurations in >> cabal"? What are the issues that you're facing with the hooks? We >> need good feedback on the hooks. >> >> peace, >> >> isaac >> > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1

Cabal compiling with profiling
by Isaac Jones 20 Apr '05

20 Apr '05

I have a patch from Arthur Baars to build profiling libraries for GHC. I'm wondering how people think it should be integrated? Should we have a --prof option that JUST builds profiling libraries, or which builds both non profiling and profiling? I know that the makefile system has some "ways" that I think are related to profiling. Should we have something more flexible, or is --prof or --with-prof flexible enough? peace, isaac

3 4

RE: build-depends harmful (was RE: import resolution)
by Simon Marlow 19 Apr '05

19 Apr '05

On 18 April 2005 21:18, S. Alexander Jacobson wrote: > I just reread my prior post and realized that it was not entirely in > english. Trying again... > > Module names in import statements refer to module specifications not > module implementations. e.g. if Prelude refers to a spec not an > implementation, then use of any module that uses the Prelude must also > refer to a spec rather than an implementation. > > Module users select hardware platform, operating system, compiler, > etc. They should also be selecting the best modules implementations > for their context. Module packagers lack enough information about user > context to do so. > > The problem with build-depends and the Package Overlap Restriction is > that they move decision making from module users to module packagers. > Build-depends is far more egregious than POR and far more optional. I think you misunderstand build-depends. It allows the author of a library to specify which implementations of a dependency are compatible with the source code of the current package; i.e. which packages will satisfy the dependency. (I'd be happier if you'd call the Package Overlap Restriction the Module Overlap Restriction, since it really has nothing to do with packages: Haskell 98 contains this restriction). > Packages should simply be collections of module implementations with > meta-data about how/where those implementations are best used. > > Users should then select implementations from (Hackage) catalogs of these > (Cabal) packages as needed. > > Therefore, we need to remove build-depends tags from Cabal files (or > change their semantics), and make Hackage a full catalog > serving/replication protocol. Removing build-depends would impose the restriction that a module can never change its interface, ever. Additionally, users are required to choose between available implementations, whether they want to or not. This appears to be the nub of the issue: I'm opposed to adding this restriction. Perhaps you could elaborate on how you would implement versioning in that scenario, and how we could add to or change existing interfaces? Cheers, Simon

2 1

RE: Cabal compiling with profiling
by Simon Marlow 19 Apr '05

19 Apr '05

On 19 April 2005 03:25, Isaac Jones wrote: > I have a patch from Arthur Baars to build profiling libraries for GHC. > I'm wondering how people think it should be integrated? Should we > have a --prof option that JUST builds profiling libraries, or which > builds both non profiling and profiling? I know that the makefile > system has some "ways" that I think are related to profiling. Should > we have something more flexible, or is --prof or --with-prof flexible > enough? --with-prof sounds good, which would build (and install etc.) the prof way in addition to the normal way. In the future we might need more of these (eg. --with-smp), but since each one needs a different flag to GHC I don't think there's anything more general we can reasonably do. Cheers, Simon

3 2

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Marlow 19 Apr '05

19 Apr '05

On 15 April 2005 23:45, S. Alexander Jacobson wrote: > On Thu, 14 Apr 2005, Simon Peyton-Jones wrote: >> The Right Thing to >> do must be to regard the "full module name" as being the package name >> pre-pended to the module name. > > I don't think that is right. As far as I understand, module names in > import statements identify specifications not implementations. > Otherwise, it would be incorrect for different compilers to implement > the Prelude differently. Resolution of imported module names to > meanings or specifications is fundamentally different from resolution > of module names to implementations. The former is the domain of the > programmer and the later is the domain of the compiler/interpreter. No, a module name specifies a module, that's all. A Haskell program currently consists of a collection of modules, each with a distinct name. If the overlap restriction were lifted, a Haskell program would consist of a collection of modules, each of which is identified by a distinct (module name, package name) pair. This is what Simon is referring to in the comment above. You apparently want to impose a further restriction: that a module name identifies an interface. The same interface, for all time. That sounds like a pretty restrictive world to live in! We can't ever change the interface of a module without changing its name, which would lead to lots of weird module names and probably version numbers cluttering up the module namespace. >> b) We worry about error messages like "cannot unify M.T with M.T" >> (meaning different M's!) > > I think the Haskell report is pretty clear that M.T always means M.T. > So, I interpret this as an error in the status quo that can result > from multiple packages requiring conflicting implementations of M. If we lifed the module overlap restriction (what this discussion was about), then a program could contain multiple Ms, and therefore multiple M.Ts, which would be incompatible. [ rest of post deleted.. I'll answer the later version ] Cheers, Simon

1 0

RE: Cabal compiling with profiling
by Simon Marlow 19 Apr '05

19 Apr '05

On 19 April 2005 11:33, Malcolm Wallace wrote: >>> I have a patch from Arthur Baars to build profiling libraries for >>> GHC. I'm wondering how people think it should be integrated? >>> Should we have a --prof option that JUST builds profiling >>> libraries, or which builds both non profiling and profiling? >> >> --with-prof sounds good, which would build (and install etc.) the >> prof way in addition to the normal way. > > I agree. > >> In the future we might need more of these (eg. --with-smp), but since >> each one needs a different flag to GHC I don't think there's anything >> more general we can reasonably do. > > I can envisage --with-tracing too, to build a Hat-enabled version > of a package, which involves not only extra compiler flags but extra > pre-processor and library dependencies too. > > In general, do you think these flags should combine in a linear > fashion (one of each 'way') or cross-product (all possible > permutations)? In GHC some combinations make sense, and others don't (eg. "unreg" doesn't mix with "smp", but "unreg" works with "prof"). A reasonable approach would be to build all combinations that make sense. (I'm just using "unreg" as an example, I don't think we need --with-unreg). Cheers, Simon

1 0

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Peyton-Jones 18 Apr '05

18 Apr '05

I've not been following the details of this thread, but I can say this: | PS In my last few posts I assumed you had rejected removing the | overlap restriction because that is what I interperted you to have | said e.g. here: | | We're not going to support this, at least for the forseeable future. | It's a pretty big change: every entity in the program becomes | parameterised by the package name as well as the module name, because | module names can overlap. Simon and I regard this as a shortcoming of Haskell, and of GHC in particular. Just because package A happens to use a module called Foo.Baz should not prevent package B from doing so. The Right Thing to do must be to regard the "full module name" as being the package name pre-pended to the module name. There is no difficulty in principle. But a) There are engineering considerations here. Notably, we are already concerned about the length of symbol names (in binaries, connected up by the linker), and this'd make them longer still. b) We worry about error messages like "cannot unify M.T with M.T" (meaning different M's!) c) We could probably do GHC, but what about Hugs and NHC?? d) It would be a fair amount of work, and there are plenty of competing things we'd like to do. Furthermore e) While this is the Right Thing, the workaround is easy: in package P, make your (internal) module names start "P.", to keep them out of other people's hair. (The fact that package names don't have the same lexical syntax as module names is a fly in this ointment.) I think that summarises the reasons why there has been no movement on this particular front, at least as I understand it. Simon

3 3

Re: Environment variable does not work (especially DARCS_EDITOR)
by Benedikt Schmidt 16 Apr '05

16 Apr '05

[ crossposted to libraries(a)haskell.org ] Tommy Pettersson <ptp(a)lysator.liu.se> writes: > A likely source of the problem can be that pico aborts if its > stdin or stdout isn't a tty. I have that problem with nvi. > If you run darcs 1.0.2 you can try and set DARCS_EDITOR to > "pico </dev/tty >/dev/tty". If you run a later build you > may have to write a wrapper script like > > #!/bin/sh > pico </dev/tty >/dev/tty > > since the to-be-next stable darcs not always perform the > redirection on the system call any longer. > > Or, if this turns out to be the problem, and if you know how > to make darcs do this redirection of stdin/out in a portable > way, fix it in the darcs source. The problem seems to be related to rawSystem and the ghc RTS (at least GHC 6.4). GHC sets stdin/stdout/stderr to nonblocking mode on startup and nvi doesn't like that. There is a comment in ghc/rts/RtsUtils.c that resetNonBlockingFd is called before exiting because leaving standard file descriptors in nonblocking mode confuses some shells. module Main where import System.Cmd main = rawSystem "nvi" [] The test program works after applying the following patch to GHC that disables nonblocking mode after the fork and before the exec. diff -u -r1.7 runProcess.c --- libraries/base/cbits/runProcess.c 27 Mar 2005 13:41:19 -0000 1.7 +++ libraries/base/cbits/runProcess.c 16 Apr 2005 19:08:52 -0000 @@ -62,6 +62,10 @@ dfl.sa_handler = (void *)quithandler; (void)sigaction(SIGQUIT, &dfl, NULL); } + + resetNonBlockingFd(fdStdInput); + resetNonBlockingFd(fdStdOutput); + resetNonBlockingFd(fdStdError); dup2 (fdStdInput, STDIN_FILENO); dup2 (fdStdOutput, STDOUT_FILENO); I'm not sure how to handle that in darcs without copying/reimplementing the parts of System.Cmd we need. Benedikt

1 0