headers
Ian Lynagh | 12 Dec 19:44
Gravatar

ANNOUNCE: GHC version 6.8.2


   =============================================================
    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
~~~~~~~~~~
(Continue reading)

Permalink | Reply |
headers
Manuel M T Chakravarty | 13 Dec 06:29
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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.
Permalink | Reply |
headers
Christian Maeder | 13 Dec 11:08
Favicon

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Manuel M T Chakravarty | 14 Dec 02:11
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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
(Continue reading)

Permalink | Reply |
headers
Ian Lynagh | 14 Dec 02:32
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Christian Maeder | 14 Dec 10:30
Favicon

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Judah Jacobson | 18 Dec 04:24

Re: ANNOUNCE: GHC version 6.8.2

On Dec 14, 2007 1:30 AM, Christian Maeder <Christian.Maeder <at> dfki.de> 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"
(Continue reading)

Permalink | Reply |
headers
Manuel M T Chakravarty | 17 Dec 02:53
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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.
(Continue reading)

Permalink | Reply |
headers
Christian Maeder | 17 Dec 11:04
Favicon

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Ian Lynagh | 17 Dec 11:19
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Manuel M T Chakravarty | 18 Dec 02:58
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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
>
(Continue reading)

Permalink | Reply |
headers
Judah Jacobson | 18 Dec 06:46

Re: ANNOUNCE: GHC version 6.8.2

On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty <chak <at> cse.unsw.edu.au> 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
(Continue reading)

Permalink | Reply |
headers
Manuel M T Chakravarty | 19 Dec 05:54
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

Judah Jacobson:
> On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty  
> <chak <at> cse.unsw.edu.au> 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
(Continue reading)

Permalink | Reply |
headers
Judah Jacobson | 19 Dec 18:18

Re: ANNOUNCE: GHC version 6.8.2

On Dec 18, 2007 8:54 PM, Manuel M T Chakravarty <chak <at> cse.unsw.edu.au> 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
(Continue reading)

Permalink | Reply |
headers
Manuel M T Chakravarty | 20 Dec 00:26
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

Judah Jacobson:
> On Dec 18, 2007 8:54 PM, Manuel M T Chakravarty  
> <chak <at> cse.unsw.edu.au> 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%
(Continue reading)

Permalink | Reply |
headers
Christian Maeder | 18 Dec 09:17
Favicon

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Ian Lynagh | 13 Dec 19:02
Gravatar

Re: ANNOUNCE: GHC version 6.8.2


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
Permalink | Reply |
headers
Alex Jacobson | 13 Dec 21:32

Re: ANNOUNCE: GHC version 6.8.2

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 <at> haskell.org
(Continue reading)

Permalink | Reply |
headers
Manuel M T Chakravarty | 14 Dec 02:05
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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 <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
(Continue reading)

Permalink | Reply |
headers
Christian Maeder | 14 Dec 10:36
Favicon

Re: ANNOUNCE: GHC version 6.8.2

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.
Permalink | Reply |
headers
Alex Jacobson | 17 Dec 18:35

Re: ANNOUNCE: GHC version 6.8.2

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.
Permalink | Reply |
headers
Manuel M T Chakravarty | 18 Dec 02:08
Favicon
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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.
(Continue reading)

Permalink | Reply |
headers
Jules Bean | 18 Dec 11:48

Re: Re: ANNOUNCE: GHC version 6.8.2

Manuel M T Chakravarty wrote:
> PS: Moreover, binaries produced by the above compiler will run on any 
> Leopard box.

That's great news.

Can you add a note about how you achieved that to

http://hackage.haskell.org/trac/ghc/ticket/1540

please?

My previous attempts to distribute ghc-compiled softrware to other mac 
users have always fallen foul of dependencies on gmp...

Jules
Permalink | Reply |
headers
Manuel M T Chakravarty | 20 Dec 01:46
Favicon
Gravatar

Re: [Haskell] Re: ANNOUNCE: GHC version 6.8.2

Jules Bean:
> Manuel M T Chakravarty wrote:
>> PS: Moreover, binaries produced by the above compiler will run on  
>> any Leopard box.
>
> That's great news.
>
> Can you add a note about how you achieved that to
>
> http://hackage.haskell.org/trac/ghc/ticket/1540
>
> please?
>
> My previous attempts to distribute ghc-compiled softrware to other  
> mac users have always fallen foul of dependencies on gmp...

I have added some remarks to that ticket, but it really should work  
out of the box now if you use my binary dist for Macs or with the HEAD.

Manuel
Permalink | Reply |
headers
Ian Lynagh | 23 Dec 15:04
Gravatar

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
alpheccar | 23 Dec 17:02
Favicon

Re: ANNOUNCE: GHC version 6.8.2

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

<<ghc: 49130112 bytes, 8 GCs, 2017280/3944448 avg/max bytes residency  
(2 samples), 17M in use, 0.01 INIT (0.05 elapsed), 1.01 MUT (2.52  
elapsed), 0.30 GC (3.20 elapsed) :ghc>>
make[2]: *** [dist/build/Data/Generics/Twins.o] Error 1
make[1]: *** [make.library.base] Error 2
make: *** [stage1] Error 2

Thanks,
Christophe.
Permalink | Reply |
headers
Gregory Wright | 23 Dec 19:11
Favicon

Re: ANNOUNCE: GHC version 6.8.2


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
(Continue reading)

Permalink | Reply |
headers
alpheccar | 23 Dec 19:18
Favicon

Re: ANNOUNCE: GHC version 6.8.2

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)
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 2 Jan 13:48

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Juanma Barranquero | 13 Dec 13:50

Re: ANNOUNCE: GHC version 6.8.2

On Dec 12, 2007 7:44 PM, Ian Lynagh <igloo <at> earth.li> 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>
(Continue reading)

Permalink | Reply |
headers
Claus Reinke | 13 Dec 14:05

Re: ANNOUNCE: GHC version 6.8.2

> 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-us/ntcmds_shelloverview.mspx

http://en.wikipedia.org/wiki/Home_directory
Permalink | Reply |
headers
Juanma Barranquero | 13 Dec 15:56

Re: ANNOUNCE: GHC version 6.8.2

On Dec 13, 2007 2:05 PM, Claus Reinke <claus.reinke <at> talk21.com> 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
Permalink | Reply |
headers
Simon Marlow | 13 Dec 16:13

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero wrote:
> On Dec 13, 2007 2:05 PM, Claus Reinke <claus.reinke <at> talk21.com> 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
Permalink | Reply |
headers
Juanma Barranquero | 13 Dec 16:20

Re: ANNOUNCE: GHC version 6.8.2

On Dec 13, 2007 4:13 PM, Simon Marlow <simonmarhaskell <at> gmail.com> 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
Permalink | Reply |
headers
Juanma Barranquero | 13 Dec 16:25

Re: ANNOUNCE: GHC version 6.8.2

On Dec 13, 2007 4:20 PM, Juanma Barranquero <lekktu <at> gmail.com> 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
Permalink | Reply |
headers
Claus Reinke | 13 Dec 16:49

Re: ANNOUNCE: GHC version 6.8.2

>> 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
(Continue reading)

Permalink | Reply |
headers
Juanma Barranquero | 13 Dec 17:12

Re: ANNOUNCE: GHC version 6.8.2

On Dec 13, 2007 4:49 PM, Claus Reinke <claus.reinke <at> talk21.com> 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:
>
(Continue reading)

Permalink | Reply |
headers
Claus Reinke | 13 Dec 18:03

Re: ANNOUNCE: GHC version 6.8.2

> 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;-)
(Continue reading)

Permalink | Reply |
headers
Juanma Barranquero | 13 Dec 18:21

Re: ANNOUNCE: GHC version 6.8.2

On Dec 13, 2007 6:03 PM, Claus Reinke <claus.reinke <at> talk21.com> 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
Permalink | Reply |
headers
Yitzchak Gale | 13 Dec 23:31

Re: ANNOUNCE: GHC version 6.8.2

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?
(Continue reading)

Permalink | Reply |
headers
Juanma Barranquero | 13 Dec 23:48

Re: ANNOUNCE: GHC version 6.8.2

On Dec 13, 2007 11:31 PM, Yitzchak Gale <gale <at> sefer.org> 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!
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 14 Dec 15:53

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Juanma Barranquero | 14 Dec 16:07

Re: ANNOUNCE: GHC version 6.8.2

On Dec 14, 2007 3:53 PM, Simon Marlow <simonmarhaskell <at> gmail.com> 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
Permalink | Reply |
headers
Simon Marlow | 14 Dec 17:09

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero wrote:
> On Dec 14, 2007 3:53 PM, Simon Marlow <simonmarhaskell <at> gmail.com> 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
Permalink | Reply |
headers
Juanma Barranquero | 14 Dec 17:29

Re: ANNOUNCE: GHC version 6.8.2

On Dec 14, 2007 5:09 PM, Simon Marlow <simonmarhaskell <at> gmail.com> wrote:

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

Thanks.

             Juanma
Permalink | Reply |
headers
Duncan Coutts | 14 Dec 23:46

Re: ANNOUNCE: GHC version 6.8.2


On Fri, 2007-12-14 at 16:09 +0000, Simon Marlow wrote:
> Juanma Barranquero wrote:
> > On Dec 14, 2007 3:53 PM, Simon Marlow <simonmarhaskell <at> gmail.com> 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
(Continue reading)

Permalink | Reply |
headers
Juanma Barranquero | 15 Dec 01:19

Re: ANNOUNCE: GHC version 6.8.2

On Dec 14, 2007 11:46 PM, Duncan Coutts <duncan.coutts <at> worc.ox.ac.uk> 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
Permalink | Reply |
headers
Felix Martini | 15 Dec 02:16

Re: ANNOUNCE: GHC version 6.8.2

On Dec 14, 2007 11:46 PM, Duncan Coutts <duncan.coutts <at> worc.ox.ac.uk> 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\.
Permalink | Reply |
headers
Juanma Barranquero | 15 Dec 02:24

Re: ANNOUNCE: GHC version 6.8.2

On Dec 15, 2007 2:16 AM, Felix Martini <fmartini <at> gmail.com> 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
Permalink | Reply |
headers
Iavor Diatchki | 15 Dec 18:31

Re: ANNOUNCE: GHC version 6.8.2

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 <lekktu <at> gmail.com> 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
Permalink | Reply |
headers
Bulat Ziganshin | 15 Dec 19:31

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 <at> gmail.com
Permalink | Reply |
headers
Seth Kurtzberg | 15 Dec 20:08

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

On Sat, 15 Dec 2007 21:31:25 +0300
Bulat Ziganshin <bulat.ziganshin <at> gmail.com> 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 "fo