ANNOUNCE: GHC version 6.8.2

newer
Re: [Haskell-cafe] Re: #haskell...

Ian Lynagh

12 Dec 2007 12 Dec '07

1:44 p.m.

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

Show replies by date

Manuel M T Chakravarty

13 Dec 13 Dec

12:29 a.m.

Ian Lynagh wrote:

...

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 =============================================================

The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading.

A binary distribution for Mac OS X 10.5 (Leopard) is available from http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 To use this binary distribution, you need to have "readline" from MacPorts installed. Manuel PS: This time around, there should be no dependency on MacPorts' "gmp", but this is hard for me to test locally.

Christian Maeder

5:08 a.m.

Manuel M T Chakravarty wrote:

...

To use this binary distribution, you need to have "readline" from MacPorts installed.

Manuel

PS: This time around, there should be no dependency on MacPorts' "gmp", but this is hard for me to test locally.

What does your "otool -L" say to your binary? otool -L compiler/stage2/ghc-6.8.2 compiler/stage2/ghc-6.8.2: /opt/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Does this not indicate that /opt/local/lib/libgmp.3.dylib is needed? Christian

Manuel M T Chakravarty

8:11 p.m.

Christian Maeder:

...

Manuel M T Chakravarty wrote:

...
To use this binary distribution, you need to have "readline" from MacPorts installed.

Manuel

PS: This time around, there should be no dependency on MacPorts' "gmp", but this is hard for me to test locally.

What does your "otool -L" say to your binary?

otool -L compiler/stage2/ghc-6.8.2 compiler/stage2/ghc-6.8.2: /opt/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Does this not indicate that /opt/local/lib/libgmp.3.dylib is needed?

Yes, it does. That's very strange for the *stage2* compiler. I ran otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those binaries don't depend on "gmp"). Ian, why would a stage2 compiler depend on an external gmp? I thought it would always use the one bundled with ghc. Manuel

Ian Lynagh

8:32 p.m.

On Fri, Dec 14, 2007 at 12:11:17PM +1100, Manuel M T Chakravarty wrote:

...

...
otool -L compiler/stage2/ghc-6.8.2 /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0)

Yes, it does. That's very strange for the *stage2* compiler. I ran otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those binaries don't depend on "gmp").

Ian, why would a stage2 compiler depend on an external gmp? I thought it would always use the one bundled with ghc.

Do you mean the one in gmp/ in the ghc repo? That's only used if there isn't an external GMP on the system; it's basically only there because we don't want to require that Windows users install GMP. I'm not sure where GMP frameworks on OS X fit in. Incidentally, I suspect the otool output actually means it depends on /some/ libgmp.3.dylib, and it is using one that it found in /opt/local/lib/libgmp.3.dylib, but I could be wrong. Thanks Ian

Christian Maeder

14 Dec 14 Dec

4:30 a.m.

Ian Lynagh wrote:

...

I'm not sure where GMP frameworks on OS X fit in.

The framework does not fit it at all, because the binary has not been built with it. Conversely, a binary built with (some) frameworks can't do anything with corresponding dylibs. (We haven't agreed yet, if dylibs or frameworks should be preferred.)

...

Incidentally, I suspect the otool output actually means it depends on /some/ libgmp.3.dylib, and it is using one that it found in /opt/local/lib/libgmp.3.dylib, but I could be wrong.

The full path /opt/local/lib/libgmp.3.dylib is (somehow) stored in the binary, but libgmp.3.dylib will be found in any other path, too. Possibly the DYLD_LIBRARY_PATH has to be set for uncommon paths. HTH Christian

Judah Jacobson

17 Dec 17 Dec

10:24 p.m.

On Dec 14, 2007 1:30 AM, Christian Maeder wrote:

...

Ian Lynagh wrote:

...
Incidentally, I suspect the otool output actually means it depends on /some/ libgmp.3.dylib, and it is using one that it found in /opt/local/lib/libgmp.3.dylib, but I could be wrong.

The full path /opt/local/lib/libgmp.3.dylib is (somehow) stored in the binary, but libgmp.3.dylib will be found in any other path, too. Possibly the DYLD_LIBRARY_PATH has to be set for uncommon paths.

Today I did some digging around the source of dyld (the dynamic loader) to understand its behavior when loading frameworks, and ended up learning about how it loads ordinary libraries as well. In particular, if otool -L lists a dependency on /opt/local/lib/libgmp.3.dylib, then the loader will look for all of the following: - [[dir]]/opt/local/lib/libgmp.3.dylib where [[dir]] is any entry from the colon-separated variable $DYLD_ROOT_PATH - /opt/local/lib/libgmp.3.dylib - [[dir]]/libgmp.3.dylib, where [[dir]] is any entry from the following colon-separated variables: - LD_LIBRARY_PATH - DYLD_LIBRARY_PATH - DYLD_FALLBACK_LIBRARY_PATH If DYLD_FALLBACK_LIBRARY_PATH is not set in the environment, it defaults to: "$HOME/lib:/usr/local/lib:/usr/lib" The rest of the variables listed above default to empty. So in conclusion, there should be no harm with linking OS X binaries against absolute paths like /opt/local. In fact, it might be preferable, since it lets us support both users of MacPorts and users who have GMP stored in a standard location. (Of course, this doesn't address the question of whether dynamically linking against GMP is good to begin with.) Best, -Judah

Manuel M T Chakravarty

16 Dec 16 Dec

8:53 p.m.

Ian Lynagh:

...

On Fri, Dec 14, 2007 at 12:11:17PM +1100, Manuel M T Chakravarty wrote:

...
...
otool -L compiler/stage2/ghc-6.8.2 /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0)

Yes, it does. That's very strange for the *stage2* compiler. I ran otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those binaries don't depend on "gmp").

Ian, why would a stage2 compiler depend on an external gmp? I thought it would always use the one bundled with ghc.

Do you mean the one in gmp/ in the ghc repo? That's only used if there isn't an external GMP on the system; it's basically only there because we don't want to require that Windows users install GMP.

It seems to be a matter of the precise ld call parameters whether the gmp/ in the ghc repo is used or the external one. In using the stage1 compiler to link the stage2 compiler, the external one wins, but in linking other programs with the stage1 compiler, the internal gmp wins. Actually, I think, we should use the gmp/ in the ghc repo by default (at least on non-Linux). Why? I don't think it is nice to build binaries by default that I can't copy to and run on another computer running the same OS without having to install extra fancy stuff like gmp. In other words, your average Mac doesn't have gmp installed. Just because I happen to have gmp on my Mac, I don't want to build a dependency into all binaries generated by ghc that prevent me from using these binaries on other Macs. Manuel

Christian Maeder

17 Dec 17 Dec

5:04 a.m.

Manuel M T Chakravarty wrote:

...

Actually, I think, we should use the gmp/ in the ghc repo by default (at least on non-Linux). Why? I don't think it is nice to build binaries by default that I can't copy to and run on another computer running the same OS without having to install extra fancy stuff like gmp. In other words, your average Mac doesn't have gmp installed. Just because I happen to have gmp on my Mac, I don't want to build a dependency into all binaries generated by ghc that prevent me from using these binaries on other Macs.

Right, the (hets) binaries that we create also depend on readline-5 that is not installed on average Macs. Therefore we've invented this GNUreadline framework, which can be at least copied into one's home directory (without too much effort). Do you think ghc should provide readline-5 as internal library, too? I wouldn't mind giving up this dylib and framework confusion, but wasn't there a license problem (maybe for our GNUreadline framework, too)? Christian

Ian Lynagh

5:19 a.m.

On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty wrote:

...

It seems to be a matter of the precise ld call parameters whether the gmp/ in the ghc repo is used or the external one. In using the stage1 compiler to link the stage2 compiler, the external one wins, but in linking other programs with the stage1 compiler, the internal gmp wins.

Hmm, that's interesting. The internal GMP should only be built if HaveLibGmp != YES and HaveFrameworkGMP != YES, in which case it should always use the internal one, and there shouldn't be an external one to use anyway.

...

Actually, I think, we should use the gmp/ in the ghc repo by default

If you want to use it when building a bindist that might be used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it. The disadvantages of using it are it might be out of date (we had some Windows segfaults a while ago that were fixed by updating the in-tree gmp) and wasted space. Thanks Ian

Manuel M T Chakravarty

8:58 p.m.

Ian Lynagh:

...

On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty wrote:

...
It seems to be a matter of the precise ld call parameters whether the gmp/ in the ghc repo is used or the external one. In using the stage1 compiler to link the stage2 compiler, the external one wins, but in linking other programs with the stage1 compiler, the internal gmp wins.

Hmm, that's interesting. The internal GMP should only be built if HaveLibGmp != YES and HaveFrameworkGMP != YES, in which case it should always use the internal one, and there shouldn't be an external one to use anyway.

At least on Mac OS (and also on Windows) and probably any other platform, except Linux, this is IMHO the wrong policy. FWIW, the current build system uses the internal GMP even if another one is installed (at least a non-framework one). However, the behaviour is a bit flacky (eg, if package readline is also used, it uses the external GMP due to some difference between the Darwin linker and other Unix linkers). It also needs to recompile installPackage and ifBuildable with the stage1 compiler (like the stuff below utils/) as both go into a binary distribution. I have fixed this all and am currently validating a patch.

...

...
Actually, I think, we should use the gmp/ in the ghc repo by default

If you want to use it when building a bindist that might be used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it.

The disadvantages of using it are it might be out of date (we had some Windows segfaults a while ago that were fixed by updating the in-tree gmp) and wasted space.

Sure we waste some space, but the alternative is worse. Programs compiled with GHC will essentially not run on any computer, but the one where they were compiled. For example, the number of Macs with gmp installed is minuscule. The default should be to build programs that run everywhere with minimal hassle (not programs that save some space, but are unusable on most computers). Manuel PS: Readline is a different matter. It is used by ghci, so needs to be installed with ghc, but this dependency does not propagate into compiled programs, unless a program explicitly uses package readline (at which point I believe it is on this program's developer to make sure their users have readline available).

Judah Jacobson

18 Dec 18 Dec

12:46 a.m.

On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty wrote:

...

Ian Lynagh:

...
On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty wrote:

...
Actually, I think, we should use the gmp/ in the ghc repo by default

If you want to use it when building a bindist that might be used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it.

The disadvantages of using it are it might be out of date (we had some Windows segfaults a while ago that were fixed by updating the in-tree gmp) and wasted space.

Sure we waste some space, but the alternative is worse. Programs compiled with GHC will essentially not run on any computer, but the one where they were compiled. For example, the number of Macs with gmp installed is minuscule. The default should be to build programs that run everywhere with minimal hassle (not programs that save some space, but are unusable on most computers).

My understanding was that one major reason to dynamically link against GMP is to satisfy the LGPL, not just to save disk space. I found a couple old but relevant posts by Wolfgang Thaller, who originally created HaskellSupport.framework (now GMP.framework): http://www.haskell.org/pipermail/glasgow-haskell-users/2002-June/003494.html http://www.haskell.org/pipermail/cvs-ghc/2005-March/023769.html The gist of those posts is the following: - Statically linking against GMP puts extra license requirements on any ghc-compiled program; thus, dynamic linking is preferable. - On OS X, installing new frameworks is very easy (just drag-and-drop the framework into ~/Library/Frameworks or /Library/Frameworks; the former doesn't even need admin privileges). This doesn't seem like much to ask of users. Best, -Judah

Manuel M T Chakravarty

11:54 p.m.

Judah Jacobson:

...

On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty wrote:

...
Ian Lynagh:

...
On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty wrote:

...
Actually, I think, we should use the gmp/ in the ghc repo by default

If you want to use it when building a bindist that might be used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it.

The disadvantages of using it are it might be out of date (we had some Windows segfaults a while ago that were fixed by updating the in- tree gmp) and wasted space.

Sure we waste some space, but the alternative is worse. Programs compiled with GHC will essentially not run on any computer, but the one where they were compiled. For example, the number of Macs with gmp installed is minuscule. The default should be to build programs that run everywhere with minimal hassle (not programs that save some space, but are unusable on most computers).

My understanding was that one major reason to dynamically link against GMP is to satisfy the LGPL, not just to save disk space. I found a couple old but relevant posts by Wolfgang Thaller, who originally created HaskellSupport.framework (now GMP.framework):

http://www.haskell.org/pipermail/glasgow-haskell-users/2002-June/003494.html http://www.haskell.org/pipermail/cvs-ghc/2005-March/023769.html

The gist of those posts is the following: - Statically linking against GMP puts extra license requirements on any ghc-compiled program; thus, dynamic linking is preferable.

Dynamic linking is preferable, because it is the simplest way to comply with the LGLP (specifically, Section 4(d)) in a closed-source program. However, it is incorrect to say that static linking leads to extra license requirements. All that is required is to enable users to use the program with a modified version of the GMP. There are two simple ways of doing that: (a) provide access to the .o files of your program so that they can statically link with a different version of the GMP or (b) to provide a version of the program linking GMP dynamically alongside the statically linked version. In any case, no change of the closed-source program's licence is required. Besides, it is far from clear whether the distinction between static and dynamic linking is legally sound: http://www.oslawblog.com/2005/01/static-linking-gpl-and-lgpl.html

...

- On OS X, installing new frameworks is very easy (just drag-and-drop the framework into ~/Library/Frameworks or /Library/Frameworks; the former doesn't even need admin privileges). This doesn't seem like much to ask of users.

I think it is. It means, Haskell programs are more hassle to install than, say, C programs. Manuel

Judah Jacobson

19 Dec 19 Dec

12:18 p.m.

On Dec 18, 2007 8:54 PM, Manuel M T Chakravarty wrote:

...

Judah Jacobson:

...
- Statically linking against GMP puts extra license requirements on any ghc-compiled program; thus, dynamic linking is preferable.

Dynamic linking is preferable, because it is the simplest way to comply with the LGLP (specifically, Section 4(d)) in a closed-source program. However, it is incorrect to say that static linking leads to extra license requirements. All that is required is to enable users to use the program with a modified version of the GMP. There are two simple ways of doing that: (a) provide access to the .o files of your program so that they can statically link with a different version of the GMP or (b) to provide a version of the program linking GMP dynamically alongside the statically linked version.

In any case, no change of the closed-source program's licence is required.

Thanks for the correction and list of alternatives; both seem pretty reasonable. Either way, I guess you're "optimizing" for the casual user rather than for a hacker wanting to update GMP who won't be stopped by needing to statically link a bunch of .o files anyway.

...

...
- On OS X, installing new frameworks is very easy (just drag-and-drop the framework into ~/Library/Frameworks or /Library/Frameworks; the former doesn't even need admin privileges). This doesn't seem like much to ask of users.

I think it is. It means, Haskell programs are more hassle to install than, say, C programs.

That's fair, although I think it's still less hassle than, e.g., installing a Ruby program on OS X Panther (which required first installing the whole of Ruby itself). Best, -Judah

Manuel M T Chakravarty

6:26 p.m.

Judah Jacobson:

...

On Dec 18, 2007 8:54 PM, Manuel M T Chakravarty wrote:

...
Judah Jacobson:

...
- Statically linking against GMP puts extra license requirements on any ghc-compiled program; thus, dynamic linking is preferable.

Dynamic linking is preferable, because it is the simplest way to comply with the LGLP (specifically, Section 4(d)) in a closed-source program. However, it is incorrect to say that static linking leads to extra license requirements. All that is required is to enable users to use the program with a modified version of the GMP. There are two simple ways of doing that: (a) provide access to the .o files of your program so that they can statically link with a different version of the GMP or (b) to provide a version of the program linking GMP dynamically alongside the statically linked version.

In any case, no change of the closed-source program's licence is required.

Thanks for the correction and list of alternatives; both seem pretty reasonable. Either way, I guess you're "optimizing" for the casual user rather than for a hacker wanting to update GMP who won't be stopped by needing to statically link a bunch of .o files anyway.

That's right. Make it dead simple for the 99.999% of users who couldn't care less about GMP as long as it does implement Haskell's Integer nicely. The LGPL requires use to enable the remaining 0.001% to hack GMP to their hearts content. We need to meet this requirement, but these are power users who don't need the simplest install possible.

...

...
...
- On OS X, installing new frameworks is very easy (just drag-and- drop the framework into ~/Library/Frameworks or /Library/Frameworks; the former doesn't even need admin privileges). This doesn't seem like much to ask of users.

I think it is. It means, Haskell programs are more hassle to install than, say, C programs.

That's fair, although I think it's still less hassle than, e.g., installing a Ruby program on OS X Panther (which required first installing the whole of Ruby itself).

Yes, but on Leopard, Ruby is preinstalled, as is Python, and I'd like the barrier to entry to be as low as possible. Manuel

Christian Maeder

18 Dec 18 Dec

3:17 a.m.

Ian Lynagh wrote:

...

If you want to use it when building a bindist that might be used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it.

I've tried it, but still all binaries had dependencies on GMP.framework. (As non-root I don't get rid of /Library/Frameworks/GMP.framework and maybe that's not even desirable for old binaries.) Christian

Ian Lynagh

13 Dec 13 Dec

1:02 p.m.

Hi Manuel, On Thu, Dec 13, 2007 at 04:29:13PM +1100, Manuel M T Chakravarty wrote:

...

Ian Lynagh wrote:

...
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 =============================================================

A binary distribution for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

Thanks! I've made this available from the 6.8.2 download page. Ian

Alex Jacobson

3:32 p.m.

Will this also work with Tiger or do I have to upgrade? -Alex- Manuel M T Chakravarty wrote:

...

Ian Lynagh wrote:

...
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 =============================================================

The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading.

A binary distribution for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

To use this binary distribution, you need to have "readline" from MacPorts installed.

Manuel

PS: This time around, there should be no dependency on MacPorts' "gmp", but this is hard for me to test locally. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Manuel M T Chakravarty

8:05 p.m.

Alex Jacobson:

...

Will this also work with Tiger or do I have to upgrade?

I don't know. I have no box with Tiger to test. Give it a try. The worst that can happen is that it is going to complain about some missing libraries or similar. Manuel

...

Manuel M T Chakravarty wrote:

...
Ian Lynagh wrote:

...
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 =============================================================

The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. A binary distribution for Mac OS X 10.5 (Leopard) is available from http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 To use this binary distribution, you need to have "readline" from MacPorts installed. Manuel PS: This time around, there should be no dependency on MacPorts' "gmp", but this is hard for me to test locally.

Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Christian Maeder

14 Dec 14 Dec

4:36 a.m.

Manuel M T Chakravarty wrote:

...

Alex Jacobson:

...
Will this also work with Tiger or do I have to upgrade?

it will not work on Tiger

...

I don't know. I have no box with Tiger to test. Give it a try. The worst that can happen is that it is going to complain about some missing libraries or similar.

configure will crash already, because utils/pwd/pwd has been built with newer libs. C.

Alex Jacobson

17 Dec 17 Dec

12:35 p.m.

I just built from source on Tiger fine. -Alex- Christian Maeder wrote:

...

Manuel M T Chakravarty wrote:

...
Alex Jacobson:

...
Will this also work with Tiger or do I have to upgrade?

it will not work on Tiger

...
I don't know. I have no box with Tiger to test. Give it a try. The worst that can happen is that it is going to complain about some missing libraries or similar.

configure will crash already, because utils/pwd/pwd has been built with newer libs.

C.

Manuel M T Chakravarty

8:08 p.m.

I wrote,

...

Ian Lynagh wrote:

...
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 =============================================================

The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading.

A binary distribution for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

To use this binary distribution, you need to have "readline" from MacPorts installed.

Manuel

PS: This time around, there should be no dependency on MacPorts' "gmp", but this is hard for me to test locally.

I just updated the binary distribution at http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 It *definitely* does not require any version of GMP to be pre- installed anymore. All that is needed it MacPort's readline. Ian, can you please update the binary on the download page? Manuel PS: Moreover, binaries produced by the above compiler will run on any Leopard box.

Ian Lynagh

23 Dec 23 Dec

9:04 a.m.

On Tue, Dec 18, 2007 at 12:08:50PM +1100, Manuel M T Chakravarty wrote:

...

I wrote,

...
Ian Lynagh wrote:

...
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 =============================================================

A binary distribution for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

I just updated the binary distribution at

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

Ian, can you please update the binary on the download page?

Done! Thanks Ian

alpheccar

11:02 a.m.

Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ? I had no problems to build the 6.8.1 but with 6.8.2, I get the error: ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. - Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts - package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing - fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/ Twins.o -ohi dist/build/Data/Generics/Twins.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for powerpc-apple-darwin): lookupVers1 base:GHC.Prim sym{tc} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[2]: *** [dist/build/Data/Generics/Twins.o] Error 1 make[1]: *** [make.library.base] Error 2 make: *** [stage1] Error 2 Thanks, Christophe.

Gregory Wright

1:11 p.m.

Hi Christophe, On Dec 23, 2007, at 11:02 AM, alpheccar wrote:

...

Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ? I had no problems to build the 6.8.1 but with 6.8.2, I get the error:

I was able to build 6.8.2 three times on PPC/Tiger (10.4.11) without error using 6.6.1 as a boostrap compiler. What are you using to compile 6.8.2?

...

../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. - Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts - package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing - fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/ Twins.o -ohi dist/build/Data/Generics/Twins.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for powerpc-apple-darwin): lookupVers1 base:GHC.Prim sym{tc}

Please report this as a GHC bug: http://www.haskell.org/ghc/ reportabug

Best Wishes, Greg

alpheccar

1:18 p.m.

Hi Greg, I used 6.8.1 as bootstrap. I have a 6.6.1 so I'll try again with it. But it is good news to know that it is building on your Mac. Now I have more hope :-) Thanks, Christophe.

...

Hi Christophe,

On Dec 23, 2007, at 11:02 AM, alpheccar wrote:

...
Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ? I had no problems to build the 6.8.1 but with 6.8.2, I get the error:

I was able to build 6.8.2 three times on PPC/Tiger (10.4.11) without error using 6.6.1 as a boostrap compiler. What are you using to compile 6.8.2?

...
../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. - Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts - package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing - fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/ Twins.o -ohi dist/build/Data/Generics/Twins.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for powerpc-apple-darwin): lookupVers1 base:GHC.Prim sym{tc}

Please report this as a GHC bug: http://www.haskell.org/ghc/ reportabug

Best Wishes, Greg

Simon Marlow

2 Jan 2 Jan

7:48 a.m.

alpheccar wrote:

...

Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ? I had no problems to build the 6.8.1 but with 6.8.2, I get the error:

../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts -package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing -fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/Twins.o -ohi dist/build/Data/Generics/Twins.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for powerpc-apple-darwin): lookupVers1 base:GHC.Prim sym{tc}

This is a new bug in 6.8.2 that we discovered just before Christmas: http://hackage.haskell.org/trac/ghc/ticket/2011 the workaround is simple: just make clean in libraries/base. Cheers, Simon

Juanma Barranquero

13 Dec 13 Dec

7:50 a.m.

On Dec 12, 2007 7:44 PM, Ian Lynagh wrote:

...

The GHC Team is pleased to announce a new patchlevel release of GHC.

With the Windows release of GHC 6.8.2, GHCi does not find .ghci in %HOME% (though it finds it in the current directory): C:\wrk> echo %HOME% C:\home C:\wrk> ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :quit Leaving GHCi. C:\wrk> cd %HOME% C:\home> ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. ** Reading .ghci ** Prelude> :quit Leaving GHCi. C:\home> type .ghci putStrLn "** Reading .ghci **" C:\home> Juanma

Claus Reinke

8:05 a.m.

...

With the Windows release of GHC 6.8.2, GHCi does not find .ghci in %HOME% (though it finds it in the current directory):

try %HOMEDRIVE% %HOMEPATH% instead? or the result of 'System.Directory.getHomeDirectory'. you might have set %HOME% to help some unix software along, but this variable doesn't seem to exist by default. claus http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-... http://en.wikipedia.org/wiki/Home_directory

Juanma Barranquero

9:56 a.m.

On Dec 13, 2007 2:05 PM, Claus Reinke wrote:

...

try %HOMEDRIVE% %HOMEPATH% instead?

Doesn't work either.

...

you might have set %HOME% to help some unix software along, but this variable doesn't seem to exist by default.

It worked in 6.8.1. With which I mean, GHCi had no trouble finding .ghci at %HOME% in 6.8.1. Juanma

Simon Marlow

10:13 a.m.

Juanma Barranquero wrote:

...

On Dec 13, 2007 2:05 PM, Claus Reinke wrote:

...
try %HOMEDRIVE% %HOMEPATH% instead?

Doesn't work either.

...
you might have set %HOME% to help some unix software along, but this variable doesn't seem to exist by default.

It worked in 6.8.1.

With which I mean, GHCi had no trouble finding .ghci at %HOME% in 6.8.1.

Yes, see this ticket which was fixed in 6.8.2: http://hackage.haskell.org/trac/ghc/ticket/1838 GHCi now uses getHomeDirectory, so you need to put your .ghci file wherever getHomeDirectory says your home directory is. Cheers, Simon

Juanma Barranquero

10:20 a.m.

On Dec 13, 2007 4:13 PM, Simon Marlow wrote:

...

Yes, see this ticket which was fixed in 6.8.2:

I suppose that is a fix for some people; it is a regression for me...

...

GHCi now uses getHomeDirectory, so you need to put your .ghci file wherever getHomeDirectory says your home directory is.

Is there any way to influence what getHomeDirectory thinks? Juanma

Juanma Barranquero

10:25 a.m.

On Dec 13, 2007 4:20 PM, Juanma Barranquero wrote:

...

I suppose that is a fix for some people; it is a regression for me...

In fact, it'd be better if GHC/GHCi would do what Emacs on Windows does: use HOME if defined, else use ShGetFolderPath to find the Windows-defined "home directory". Juanma

Claus Reinke

10:49 a.m.

...

...
I suppose that is a fix for some people; it is a regression for me...

In fact, it'd be better if GHC/GHCi would do what Emacs on Windows does: use HOME if defined, else use ShGetFolderPath to find the Windows-defined "home directory".

in the interest of backwards-compatibility, perhaps. but as the links i gave should demonstrate, there is no %HOME% on windows, unless you invent it. most users who define %HOME% probably mean it to override the system standard %HOMEPATH%, at least in those programs that look for %HOME%. but that is a guess that would need to be documented for each of those programs, and makes them different from the majority of code on that platform. and not looking for %HOMEPATH% if there's no %HOME% is always a bug. if you absolutely want to define a %HOME%, and you also absolutely want to keep it different from %HOMEPATH% (which means you have two homes to take care of!), then you could try a simple workaround: %HOMEPATH%\.ghci: :cmd System.Environment.getEnv "HOME" >>= \h->readFile (h++"/.ghci") %HOME\.ghci -- as before claus

Juanma Barranquero

11:12 a.m.

On Dec 13, 2007 4:49 PM, Claus Reinke wrote:

...

in the interest of backwards-compatibility, perhaps.

That is a good reason, yes.

...

but as the links i gave should demonstrate, there is no %HOME% on windows, unless you invent it.

Sorry, it's not me who invented it. There are many tools (from Unix origin) that use HOME in Windows if defined. In fact, let me think... oh, yeah, I remember, GHCi itself used it until this very same morning... :)

...

and not looking for %HOMEPATH% if there's no %HOME% is always a bug.

That's why I suggest using HOME if defined, ShGetFolderPath if not.

...

if you absolutely want to define a %HOME%, and you also absolutely want to keep it different from %HOMEPATH% (which means you have two homes to take care of!)

No. I don't "take care" of the Windows-provided home dir, because it is mostly used *automatically* by programs that write their setting files to it. It is rare indeed the Windows program that requires the user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there.

...

%HOMEPATH%\.ghci:

:cmd System.Environment.getEnv "HOME" >>= \h->readFile (h++"/.ghci")

%HOME\.ghci

-- as before

Thanks, I'll use that. However, I still think that breaking back-compatibility is Not a Good Idea. Juanma

Claus Reinke

12:03 p.m.

...

Sorry, it's not me who invented it. There are many tools (from Unix origin) that use HOME in Windows if defined. In fact, let me think... oh, yeah, I remember, GHCi itself used it until this very same morning... :)

yes, but ghc/ghci switched from unix-emulated to windows-native long ago - since then, they've tried to behave more like other windows programs, with no built-in knowledge of unixisms. now, imagine the surprise when, in your %HOME%/.ghci, you do home <- System.Directory.getHomeDirectory System.Directory.getDirectoryContents home and the script ghci claims to be executing isn't even there!-) or imagine switching between console (no HOME) and bash (inherited HOME) ghci: now you see .ghci, now you don't..

...

No. I don't "take care" of the Windows-provided home dir, because it is mostly used *automatically* by programs that write their setting files to it. It is rare indeed the Windows program that requires the user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there.

it would be useful if ghci could read/write its current settings (perhaps split into a .cabal file with settings and a .ghci file with scripts/definitions). but you wouldn't want it to ovewrite your old .ghci, and some of us would still like to know where it ends up so that we can check and edit it manually, or copy it elsewhere;-)

...

Thanks, I'll use that. However, I still think that breaking back-compatibility is Not a Good Idea.

in general, i would agree. perhaps my fault for filing that ticket in absolutes, which led to a fix replacing, rather than augmenting, the old, erroneous behaviour. but a HOME-overrides-HOMEPATH approach, while backwards-compatible, suffers from the same inconsistency issues as the old please-define-HOME-yourself approach (even worse: you might get different versions of .ghci). so, one would have to implement the overriding approach consistently (including getHomeDirectory), and issue warnings and documentation to make users aware of any such overriding taking place (and should it be optional, to avoid deviating from the platform standard?).. as a short-term deprecation workaround for ghc-6.8.x, that makes some sense, but in the long-term? claus

Juanma Barranquero

12:21 p.m.

On Dec 13, 2007 6:03 PM, Claus Reinke wrote:

...

perhaps my fault for filing that ticket in absolutes, which led to a fix replacing, rather than augmenting, the old, erroneous behaviour.

It's not a matter of "fault", but sure it would've been wiser to suggest (or implement) the new behavior without forgetting those of us who were used to the current ways :)

...

so, one would have to implement the overriding approach consistently (including getHomeDirectory), and issue warnings and documentation to make users aware of any such overriding taking place (and should it be optional, to avoid deviating from the platform standard?)..

As I've said, Emacs already does that and there's no trouble at all.

...

as a short-term deprecation workaround for ghc-6.8.x, that makes some sense, but in the long-term?

Personally, I wouldn't want to use %HOMEDRIVE%%HOMEPATH%, neither short-term nor long-term, unless forced to do so. Juanma

Yitzchak Gale

5:31 p.m.

Juanma Barranquero wrote:

...

...
In fact, it'd be better if GHC/GHCi would do what Emacs on Windows does: use HOME if defined, else use ShGetFolderPath to find the Windows-defined "home directory".

I agree, that is closer to the correct behavior. Except that on Vista ShGetFolderPath is deprecated. Use ShGetKnownFolderPath instead on Vista. On Vista, users may have their settings stored somewhere else on the network. The old interface does not support that. Claus Reinke wrote:

...

in the interest of backwards-compatibility, perhaps. but as the links i gave should demonstrate, there is no %HOME% on windows, unless you invent it.

%HOMEPATH% is *not* the usual Windows native way of finding a place for files like dot-ghci. Your link to MS documentation of %HOMEPATH% for XP doesn't use the word "legacy", but it certainly smells that way to any modern Windows developer. It is a throwback to the old DOS days. I was unable to find any mention of %HOMEPATH% at all for Vista on the MS site, though it does still seem to exist. Anyone have a link? Note that the old cmd.exe shell itself is deprecated on Vista - the new MSH shell is based on .NET. There I think you would use the IKnownFolders interface to get (something vagualy analagous to) the home directory, not %HOMEPATH% Also, %HOMEPATH% is unsuitable for a Unix-style home directory on pre-Vista systems, because it usually points to a directory with spaces in its path name. %HOME% is the de-facto standard for Unix-like shell applications that were ported to Windows and need a home directory. If someone sets that, it means they want to use the folder in that way. And yes, that is the way GHCi has been working until now, so I think it should still be supported if someone sets it. Otherwise, the native Windows way is via ShGetFolderPath on pre-Vista, and ShGetKnownFolder on Vista. The installer should create a GHC subfolder of that, and that is where dot-ghci should go on Windows, unless %HOME% is set.

...

now, imagine the surprise when, in your %HOME%/.ghci, you

do home <- System.Directory.getHomeDirectory System.Directory.getDirectoryContents home

and the script ghci claims to be executing isn't even there!-)

Yes, that is a problem. A user who sets %HOME% has indicated that this should be used. I think that should be returned by getHomeDirectory. If you like using "Documents and Settings..." no one is forcing you to set %HOME% to anything, you can just use the default settings. Thanks, Yitz

Juanma Barranquero

5:48 p.m.

On Dec 13, 2007 11:31 PM, Yitzchak Gale wrote:

...

I agree, that is closer to the correct behavior. Except that on Vista ShGetFolderPath is deprecated. Use ShGetKnownFolderPath instead on Vista.

Aha, I didn't know that. Thanks.

...

Also, %HOMEPATH% is unsuitable for a Unix-style home directory on pre-Vista systems, because it usually points to a directory with spaces in its path name.

That's one big reason why I don't use it as HOME.

...

%HOME% is the de-facto standard for Unix-like shell applications that were ported to Windows and need a home directory. If someone sets that, it means they want to use the folder in that way. And yes, that is the way GHCi has been working until now, so I think it should still be supported if someone sets it.

Yes.

...

Yes, that is a problem. A user who sets %HOME% has indicated that this should be used. I think that should be returned by getHomeDirectory.

Exactly! Juanma

Simon Marlow

14 Dec 14 Dec

9:53 a.m.

Juanma Barranquero wrote:

...

...
%HOME% is the de-facto standard for Unix-like shell applications that were ported to Windows and need a home directory. If someone sets that, it means they want to use the folder in that way. And yes, that is the way GHCi has been working until now, so I think it should still be supported if someone sets it.

Yes.

...
Yes, that is a problem. A user who sets %HOME% has indicated that this should be used. I think that should be returned by getHomeDirectory.

Exactly!

I can imagine that you might want GHCi to look in $HOME, for backwards compatibility. But do you really want getHomeDirectory to return $HOME? That's a very un-Windowsy thing to do, and I don't think we ought to be baking Un*x behaviour into APIs that are supposed to do whatever is native on the current platform. Cheers, Simon

Juanma Barranquero

10:07 a.m.

On Dec 14, 2007 3:53 PM, Simon Marlow wrote:

...

I can imagine that you might want GHCi to look in $HOME, for backwards compatibility.

Yes.

...

But do you really want getHomeDirectory to return $HOME?

Yes! If I define %HOME, it is *exactly* because I don't want to use Windows' idea of a home directory (which could be perhaps more accurately defined as "hidden away storage area for automatically-saved configuration settings").

...

That's a very un-Windowsy thing to do, and I don't think we ought to be baking Un*x behaviour into APIs that are supposed to do whatever is native on the current platform.

We're talking about an override for people that specifically define it. Juanma

Simon Marlow

11:09 a.m.

Juanma Barranquero wrote:

...

On Dec 14, 2007 3:53 PM, Simon Marlow wrote:

...
But do you really want getHomeDirectory to return $HOME?

Yes!

If I define %HOME, it is *exactly* because I don't want to use Windows' idea of a home directory (which could be perhaps more accurately defined as "hidden away storage area for automatically-saved configuration settings").

Ok. Unless there are any objections, this is what we'll do. Cheers, Simon

Juanma Barranquero

11:29 a.m.

On Dec 14, 2007 5:09 PM, Simon Marlow wrote:

...

Ok. Unless there are any objections, this is what we'll do.

Thanks. Juanma

Duncan Coutts

5:46 p.m.

On Fri, 2007-12-14 at 16:09 +0000, Simon Marlow wrote:

...

Juanma Barranquero wrote:

...
On Dec 14, 2007 3:53 PM, Simon Marlow wrote:

...
But do you really want getHomeDirectory to return $HOME?

Yes!

If I define %HOME, it is *exactly* because I don't want to use Windows' idea of a home directory (which could be perhaps more accurately defined as "hidden away storage area for automatically-saved configuration settings").

Ok. Unless there are any objections, this is what we'll do.

It sounds like a bad idea to me. I agree with your initial reaction and principle that we don't want to "be baking Un*x behaviour into APIs that are supposed to do whatever is native on the current platform." I can just imagine the bug report and eventually figuring out that some application the user had installed had set $HOME and this was messing up finding files. If a particular application (like ghci) wants to consult $HOME in preference to getHomeDirectory it can do so. I don't think we need to make all Haskell programs behave in a non-standard way especially since most other programs are not going to. On the other hand, for a cygwin build there's a very reasonable argument for using $HOME since that's what is native for the environment/platform. I suspect what Juanma would really like is a cygwin build. Duncan

Juanma Barranquero

7:19 p.m.

On Dec 14, 2007 11:46 PM, Duncan Coutts wrote:

...

I can just imagine the bug report and eventually figuring out that some application the user had installed had set $HOME and this was messing up finding files.

There are not many (there is any, other than perhaps Cygwin?) which set %HOME on Windows. There are many (unix ports) who can *use* HOME if you defined it.

...

On the other hand, for a cygwin build there's a very reasonable argument for using $HOME since that's what is native for the environment/platform. I suspect what Juanma would really like is a cygwin build.

You suspect wrong. I wouldn't install Cygwin in my computer under any circumstance (I did, in the past, and came to hate it quite quickly). If I need GNU tools I install MSYS/MinGW, or GnuWin32. What I would really like is exactly what I've asked for. Juanma

Felix Martini

8:16 p.m.

On Dec 14, 2007 11:46 PM, Duncan Coutts wrote:

...

It sounds like a bad idea to me. I agree with your initial reaction and principle that we don't want to "be baking Un*x behaviour into APIs that are supposed to do whatever is native on the current platform."

I agree with Duncan. getHomeDirectory should follow the Windows API. There are other unix-style dot-config files in my Windows home folder as well. Ideally the ghci config file would be put into <AppData>\GHC\.

Juanma Barranquero

8:24 p.m.

On Dec 15, 2007 2:16 AM, Felix Martini wrote:

...

I agree with Duncan. getHomeDirectory should follow the Windows API. There are other unix-style dot-config files in my Windows home folder as well. Ideally the ghci config file would be put into <AppData>\GHC\.

Have you installed any program that automatically set up %HOME so it would interfere with the default behavior proposed? Because what Yitzchak Gale proposed and I seconded does not mean that getHomeDirectory will not "follow the Windows API", unless very specifically requested by setting HOME. Juanma

Iavor Diatchki

15 Dec 15 Dec

12:31 p.m.

Hi, I also agree with Duncan---basic library functions should provide a mechanism and not try to enforce a policy. Applications that are interested in supporting the %HOME% convention can easily do so by defining a function that first checks for that environment variable, and only if it is not set, then use the 'getHomeDirectory' function. On Dec 14, 2007 5:24 PM, Juanma Barranquero wrote:

...

Because what Yitzchak Gale proposed and I seconded does not mean that getHomeDirectory will not "follow the Windows API", unless very specifically requested by setting HOME.

Setting an environment variable is just one way for the user to specify the location of the configuration data for the program. Other options are to use a command line flag, or setting an entry in the Windows registry, for example. -Iavor

Bulat Ziganshin

1:31 p.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

Hello Juanma, Saturday, December 15, 2007, 4:24:43 AM, you wrote:

...

Because what Yitzchak Gale proposed and I seconded does not mean that getHomeDirectory will not "follow the Windows API", unless very specifically requested by setting HOME.

i'm against this idea. one can setup HOME for some specific program and then find that all his ghc-compiled programs are changed their behavior. ghc don't have a goal of emulating Unix standards in windows environment so such behavior will look unexpectedly -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Seth Kurtzberg

2:08 p.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Sat, 15 Dec 2007 21:31:25 +0300 Bulat Ziganshin wrote:

...

Hello Juanma,

Saturday, December 15, 2007, 4:24:43 AM, you wrote:

...
Because what Yitzchak Gale proposed and I seconded does not mean that getHomeDirectory will not "follow the Windows API", unless very specifically requested by setting HOME.

i'm against this idea. one can setup HOME for some specific program and then find that all his ghc-compiled programs are changed their behavior. ghc don't have a goal of emulating Unix standards in windows environment so such behavior will look unexpectedly

I too agree, and would add that (as someone pointed out earlier) it's trivial to wrap the function in question. Further, not only is it trivial but it's "more correct" in the sense that O/S specific behavior should be isolated whenever possible, and such isolation is certainly possible here. Create a class that defines, but does not implement, the required methods, and create an instance for the O/S in use. That's clean, simple, and is guaranteed to not break existing working programs. -- Seth Kurtzberg

...

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Yitzchak Gale

8:21 p.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back. I would say it is quite ironic that some people are arguing against this by saying that it will lead to more bug reports. It is *not* "trivial to wrap the function in question", and it is not "more correct". The current behavior is not more WIndows native - it is arguably much worse. The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a "home directory" and should not be used that way. But if there is no other way to provide a value for getHomeDirectory, I guess that is still better than throwing a run-time exception, but at least obtain the path in a somewhat Windows-friendly way by using the API properly. It is just not true that using %HOME% creates problems. This is a widespread convention, in active use. Admittedly ad-hoc, but it works. Does anyone know of even a single incident in which this created a problem? Better native Windows integration is definitely an important goal. The whole idea of a ".ghci" file is very Unixy, for example. There is a lot of work to be done in this direction. Pulling the rug out from under %HOME% without providing a reasonable alternative is not the way to begin. By "reasonable alternative", I mean a way that users can configure GHC's notion of "home directory" at run-time on Windows. Truthfully, I don't think this should be the first priority for better Windows integration. Wouldn't our time be better spent on Visual Studio integration and WinAPI support? Not to mention .NET... Thanks, Yitz

Seth Kurtzberg

8:56 p.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Sun, 16 Dec 2007 03:21:14 +0200 "Yitzchak Gale" wrote:

...

Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back. I would say it is quite ironic that some people are arguing against this by saying that it will lead to more bug reports.

It is *not* "trivial to wrap the function in question", and it is not "more correct".

Why is it *not* trivial to wrap the function? Regardless of whether you like the resulting solution, it is undeniably trivial to change the name of a function, create a new function with the (original) name, and have that new function call the original function, or call the original function based on some criteria, or implement different behavior entirely? I did so here, and in roughly 10 minutes I verified that the behavior was exactly as one would expect. Now, you may not approve of the resulting behavior, but that's an entirely separate question of whether something is, or isn't, trivial to implement. I wrote a few lines of code; certainly seemed trivial to me. I have a bit more sympathy for your assertion that changing the default behavior is not something to be done lightly, but if a small modification allows you to implement either the old or new behavior, the question becomes what should the default behavior be? (Or perhaps the *default* behavior? I've always found that the use of punctuation as a substitute for rational discussion is an attempt to be insulting rather than to enter into a discussion on the merits. If you believe something is not trivial, then state your reasons. If you don't have a reason, hold the bluster and the asterisks. Seth

...

The current behavior is not more WIndows native - it is arguably much worse. The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a "home directory" and should not be used that way. But if there is no other way to provide a value for getHomeDirectory, I guess that is still better than throwing a run-time exception, but at least obtain the path in a somewhat Windows-friendly way by using the API properly.

It is just not true that using %HOME% creates problems. This is a widespread convention, in active use. Admittedly ad-hoc, but it works. Does anyone know of even a single incident in which this created a problem?

Better native Windows integration is definitely an important goal. The whole idea of a ".ghci" file is very Unixy, for example. There is a lot of work to be done in this direction. Pulling the rug out from under %HOME% without providing a reasonable alternative is not the way to begin.

By "reasonable alternative", I mean a way that users can configure GHC's notion of "home directory" at run-time on Windows.

Truthfully, I don't think this should be the first priority for better Windows integration. Wouldn't our time be better spent on Visual Studio integration and WinAPI support? Not to mention .NET...

Thanks, Yitz

-- Seth Kurtzberg

Yitzchak Gale

10:14 p.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

Hi Seth. Sorry, my asterisks were not at all meant to be a flame. Please accept my sincere apologies if it appeared that way. I wrote:

...

...
It is *not* "trivial to wrap the function in question", and it is not "more correct".

Seth Kurtzberg wrote:

...

Why is it *not* trivial to wrap the function? Regardless of whether you like the resulting solution, it is undeniably trivial to change the name of a function, create a new function with the (original) name, and have that new function... implement different behavior...

That may be trivial when writing a new program, but it may also be difficult or even impossible when the code is already in use and shared among many other existing programs. Summarizing: o The current (until recently) method has been in place for a long time, and works fine. o It follows a widely-used convention, though arguably a somewhat messy one. o It provides a prominent behavior, so changing it suddenly is very painful. o It is dubious whether the change, as implemented, achieves its intended purpose at all, namely better Windows integration. o Even if you believe that it does, the small amount of value it provides is not worth the cost. I support providing a default value for the home directory when the user does not specify one. It would be nice if this could be done in a more Windowsy way. Since another of my points is that we are focusing too much on this issue, I will say no more and gracefully accept whatever the community decides at this point. Thanks, Yitz

Duncan Coutts

16 Dec 16 Dec

4:56 a.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Sun, 2007-12-16 at 03:21 +0200, Yitzchak Gale wrote:

...

The current behavior is not more WIndows native - it is arguably much worse. The %HOMEPATH% variable should definitely not be used.

It is not.

...

The folder that it points to is not a "home directory" and should not be used that way. But if there is no other way to provide a value for getHomeDirectory, I guess that is still better than throwing a run-time exception, but at least obtain the path in a somewhat Windows-friendly way by using the API properly.

It does. It uses SHGetFolderPath with csidl_PROFILE which gets us something like "C:/Documents And Settings/user". Note that for data files like the .ghci file it's probably better to use getAppUserDataDirectory "ghci" which will return $HOME/.ghci on unix systems and "C:/Documents And Settings/user/Application Data/ghci" on Windows. Duncan

Felix Martini

7:54 a.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Dec 16, 2007 2:21 AM, Yitzchak Gale wrote:

...

The current behavior is not more WIndows native - it is arguably much worse. The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a "home directory" and should not be used that way.

That's not correct. It is the user's home folder aka user profile folder, see e.g. http://support.microsoft.com/kb/101507. The environment variables %homedrive% and %homepath% are set by Windows for use by (legacy) scripts. Think of them as readonly variables. Modifying environment variables is not a Windows convention. There are other ways to change the location of a user's profile folder.

...

By "reasonable alternative", I mean a way that users can configure GHC's notion of "home directory" at run-time on Windows.

This is not a task for GHC, but Windows itself. GHC should just use the win api to ask Windows for the user's home folder. That is the current behaviour. On Dec 16, 2007 10:56 AM, Duncan Coutts wrote:

...

Note that for data files like the .ghci file it's probably better to use getAppUserDataDirectory "ghci" which will return $HOME/.ghci on unix systems and "C:/Documents And Settings/user/Application Data/ghci" on Windows.

This is the ideal solution for ghci on Windows.

Yitzchak Gale

9:38 a.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

Hi Felix, You have described your own style of using some of the Window's Known Folders. In my opinion your style is a bit Unixy, but that's fine, you should be allowed to do it that way in GHC. But GHC should not force others to do it only that way. btw, years ago I used to use the Profile folder as if it were a "home directory". It caused me no end of problems. But if it works for you, it should certainly be possible for you to do it that way. I wrote:

...

...
The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a "home directory" and should not be used that way.

Felix Martini wrote:

...

That's not correct. It is the user's home folder aka user profile folder

No, the two are not the same. It is the User Profile folder. It is not a Unix-style home directory - there is no such concept on Windows. The two are used very differently.

...

see e.g. http://support.microsoft.com/kb/101507.

That is an ancient article about NT 4.0, and even then it was only about how to deal with legacy scripts back in those days.

...

The environment variables %homedrive% and %homepath% are set by Windows for use by (legacy) scripts. Think of them as readonly variables. Modifying environment variables is not a Windows convention. There are other ways to change the location of a user's profile folder.

Correct. That is one of the reasons that this folder is not suitable for use as a home directory.

...

...
By "reasonable alternative", I mean a way that users can configure GHC's notion of "home directory" at run-time on Windows.

...

This is not a task for GHC, but Windows itself. GHC should just use the win api to ask Windows for the user's home folder. That is the current behaviour.

It is not the current behavior, and it is not a task for Windows. Windows will never do it. There is no such thing as a "home folder" on Windows. The new current behavior is to ask the Windows API for the user's Profile folder, and force it to be used as if it were a "home directory". That is wrong. As long as GHC has a built-in notion of "home directory", which doesn't exist on Windows, there needs to be a user-configurable way to specify what to do instead, as there always was until now. It depends on a lot of factors - exactly how are you using this "home directory", how does it interact with other apps, details about the platform, etc.. If nothing is specified, then, as a last resort, there is no choice but to use the Profile folder as the default. As Duncan Coutts pointed out, the getAppUserDataDirectory function makes much more sense - that is a notion that ought to exist on all platforms.

...

This is the ideal solution for ghci on Windows.

Yes, that is the right place to put the ".ghci" file. Ach, here I go again. I've got to get back to work... Regards, Yitz

Juanma Barranquero

10:43 a.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:

...

As long as GHC has a built-in notion of "home directory", which doesn't exist on Windows, there needs to be a user-configurable way to specify what to do instead, as there always was until now. It depends on a lot of factors - exactly how are you using this "home directory", how does it interact with other apps, details about the platform, etc..

If nothing is specified, then, as a last resort, there is no choice but to use the Profile folder as the default.

FWIW, I agree 100% with this. Juanma

Seth Kurtzberg

11:45 a.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Sun, 16 Dec 2007 16:43:53 +0100 "Juanma Barranquero" wrote:

...

On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:

...
As long as GHC has a built-in notion of "home directory", which doesn't exist on Windows, there needs to be a user-configurable way to specify what to do instead, as there always was until now. It depends on a lot of factors - exactly how are you using this "home directory", how does it interact with other apps, details about the platform, etc..

If nothing is specified, then, as a last resort, there is no choice but to use the Profile folder as the default.

FWIW, I agree 100% with this.

Juanma

Indeed, what's the alternative? Also, in general deployed programs are compiled and linked. Behavior related to ghci initialization is not going to break deployed software. Changes to the behavior of a development tool are in a different class than changes that may impact deployed programs. Seth

...

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Seth Kurtzberg

Felix Martini

1:37 p.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:

...

No, the two are not the same. It is the User Profile folder. It is not a Unix-style home directory - there is no such concept on Windows. The two are used very differently.

I guess we disagree about that. I believe what Micosoft calls the user profile folder is equivalent to what is called the user home folder in Unix. This is especially obvious in Vista, most folder names are the same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music.

Isaac Dupree

2:36 p.m.

Felix Martini wrote:

...

On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:

...
No, the two are not the same. It is the User Profile folder. It is not a Unix-style home directory - there is no such concept on Windows. The two are used very differently.

I guess we disagree about that. I believe what Micosoft calls the user profile folder is equivalent to what is called the user home folder in Unix. This is especially obvious in Vista, most folder names are the same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music.

FWIW, here on Linux I didn't like all my automatically generated-in-$HOME stuff being spewed all over my own organization, so ]echo $HOME /Users/me/HOME (I'm in GoboLinux which uses "/Users" rather than "/home", which isn't important to this) and my .zshrc has cd; cd .. (a.k.a. cd /Users/me) to take me to my personal home directory in the non-Unix sense. It's a bit of a nuisance sometimes, but worth it for me; the worst that happens is sometimes I have to go up a level first in file-chooser dialogs or "~/../" paths. Isaac

Seth Kurtzberg

3:48 p.m.

Isaac makes an important point (although I'm not sure it's the point he intended to make :) ), there is really nothing in the definition of UNIX itself that specifies or requires a home directory. It's a convention followed by shells, primarily. Seth On Sun, 16 Dec 2007 14:36:55 -0500 Isaac Dupree wrote:

...

Felix Martini wrote:

...
On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:

...
No, the two are not the same. It is the User Profile folder. It is not a Unix-style home directory - there is no such concept on Windows. The two are used very differently.

I guess we disagree about that. I believe what Micosoft calls the user profile folder is equivalent to what is called the user home folder in Unix. This is especially obvious in Vista, most folder names are the same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music.

FWIW, here on Linux I didn't like all my automatically generated-in-$HOME stuff being spewed all over my own organization, so

]echo $HOME /Users/me/HOME (I'm in GoboLinux which uses "/Users" rather than "/home", which isn't important to this)

and my .zshrc has cd; cd .. (a.k.a. cd /Users/me) to take me to my personal home directory in the non-Unix sense. It's a bit of a nuisance sometimes, but worth it for me; the worst that happens is sometimes I have to go up a level first in file-chooser dialogs or "~/../" paths.

Isaac

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Isaac Dupree

17 Dec 17 Dec

4:40 p.m.

Seth Kurtzberg wrote:

...

Isaac makes an important point (although I'm not sure it's the point he intended to make :) ), there is really nothing in the definition of UNIX itself that specifies or requires a home directory. It's a convention followed by shells, primarily.

$HOME is a convention too prevalent to not have one in a running system, unless you try really hard. But I've only seen it used for two things that I remember: - dot-files (and sometimes non-dot ones for IMHO ill-behaved programs) as a per-user search and automatic generation location - default location for shells (graphical file search as well as command-line) - which IMO should be controllable by a different variable - and '~' as a sort of synonym, I guess, even in some contexts that don't allow arbitrary environment variable substitution? any others? Isaac

Felix Martini

5:41 p.m.

New subject: Re[2]: ANNOUNCE: GHC version 6.8.2

On Dec 16, 2007 10:56 AM, Duncan Coutts wrote:

...

Note that for data files like the .ghci file it's probably better to use getAppUserDataDirectory "ghci" which will return $HOME/.ghci on unix systems and "C:/Documents And Settings/user/Application Data/ghci" on Windows.

I've added a proposal and a patch to Trac (http://hackage.haskell.org/trac/ghc/ticket/1987). -Felix

Simon Marlow

18 Dec 18 Dec

5:18 a.m.

Felix Martini wrote:

...

On Dec 16, 2007 10:56 AM, Duncan Coutts wrote:

...
Note that for data files like the .ghci file it's probably better to use getAppUserDataDirectory "ghci" which will return $HOME/.ghci on unix systems and "C:/Documents And Settings/user/Application Data/ghci" on Windows.

I've added a proposal and a patch to Trac (http://hackage.haskell.org/trac/ghc/ticket/1987).

I'd like to suggest a slight change to this. Currently we put the user package database in <appdata>\ghc\<arch>-<os>-<ghcversion>\package.conf so perhaps the GHCi startup file should be <appdata>\ghc\ghci.cfg To keep all the GHC-related settings together in <appdata>\ghc. Additionally, I propose we make no changes to what happens on Unix, and no changes to getHomeDirectory. Cheers, Simon

Juanma Barranquero

5:43 a.m.

On Dec 18, 2007 11:18 AM, Simon Marlow wrote:

...

I'd like to suggest a slight change to this. Currently we put the user package database in

<appdata>\ghc\<arch>-<os>-<ghcversion>\package.conf

so perhaps the GHCi startup file should be

<appdata>\ghc\ghci.cfg

To keep all the GHC-related settings together in <appdata>\ghc.

Additionally, I propose we make no changes to what happens on Unix, and no changes to getHomeDirectory.

That's orthogonal to allowing %HOME to override <appdata>. Juanma

Simon Marlow

17 Dec 17 Dec

4:17 a.m.

Yitzchak Gale wrote:

...

Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back.

Only GHCi has changed here. Perhaps you're under the impression that we recently changed the behaviour of getHomeDirectory? In fact, it was introduced in GHC 6.4 and has always had the same behaviour, calling SHGetFolderPath on Windows. Cheers, Simon

Yitzchak Gale

5:24 a.m.

I wrote:

...

...
Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back.

Simon Marlow wrote:

...

Only GHCi has changed here. Perhaps you're under the impression that we recently changed the behaviour of getHomeDirectory? In fact, it was introduced in GHC 6.4 and has always had the same behaviour, calling SHGetFolderPath on Windows.

Thanks, Simon. Yes, I was originally under that mistaken impression, but Duncan set me straight. I am glad that %HOMEPATH% is not being used, though ShGetFolderPath sometimes gives the wrong answer on Vista. So having a customizable notion of home directory on Windows would be a new feature for getHomeDirectory. For GHCi it would be rescuing a recently removed one. -Yitz

6348

Age (days ago)

6369

Last active (days ago)

List overview

Download

66 comments

17 participants

participants (17)

Alex Jacobson
alpheccar
Bulat Ziganshin
Christian Maeder
Claus Reinke
Duncan Coutts
Felix Martini
Gregory Wright
Ian Lynagh
Iavor Diatchki
Isaac Dupree
Juanma Barranquero
Judah Jacobson
Manuel M T Chakravarty
Seth Kurtzberg
Simon Marlow
Yitzchak Gale