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 "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 <seth <at> cql.com>

> 
> -- 
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
>
(Continue reading)

Permalink | Reply |
headers
Yitzchak Gale | 16 Dec 02:21

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

Permalink | Reply |
headers
Seth Kurtzberg | 16 Dec 02:56

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

On Sun, 16 Dec 2007 03:21:14 +0200
"Yitzchak Gale" <gale <at> sefer.org> 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.
(Continue reading)

Permalink | Reply |
headers
Yitzchak Gale | 16 Dec 04:14

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

Permalink | Reply |
headers
Duncan Coutts | 16 Dec 10:56

Re: 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
Permalink | Reply |
headers
Felix Martini | 16 Dec 13:54

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

Permalink | Reply |
headers
Yitzchak Gale | 16 Dec 15:38

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

Permalink | Reply |
headers
Juanma Barranquero | 16 Dec 16:43

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

On Dec 16, 2007 3:38 PM, Yitzchak Gale <gale <at> sefer.org> 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
Permalink | Reply |
headers
Seth Kurtzberg | 16 Dec 17:45

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

On Sun, 16 Dec 2007 16:43:53 +0100
"Juanma Barranquero" <lekktu <at> gmail.com> wrote:

> On Dec 16, 2007 3:38 PM, Yitzchak Gale <gale <at> sefer.org> 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
(Continue reading)

Permalink | Reply |
headers
Felix Martini | 16 Dec 19:37

Re: 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.
Permalink | Reply |
headers
Isaac Dupree | 16 Dec 20:36

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Seth Kurtzberg | 16 Dec 21:48

Re: ANNOUNCE: GHC version 6.8.2

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 <isaacdupree <at> charter.net> 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 ..
(Continue reading)

Permalink | Reply |
headers
Isaac Dupree | 17 Dec 22:40

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Felix Martini | 17 Dec 23:41

Re: 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
Permalink | Reply |
headers
Simon Marlow | 18 Dec 11:18

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Juanma Barranquero | 18 Dec 11:43

Re: ANNOUNCE: GHC version 6.8.2

On Dec 18, 2007 11:18 AM, Simon Marlow <simonmarhaskell <at> gmail.com> 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
Permalink | Reply |
headers
Simon Marlow | 17 Dec 10:17

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Yitzchak Gale | 17 Dec 11:24

Re: ANNOUNCE: GHC version 6.8.2

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
Permalink | Reply |
headers
Benjamin L. Russell | 20 Dec 03:13
Favicon
Gravatar

Re: Re: ANNOUNCE: GHC version 6.8.2

This fixed the problem, and on Windows XP
Professional, I was able to set GHCi to find .ghci in
%HOMEPATH%, which turned out to be c:\Documents and
Settings\<username>.

However, I would like to override this setting, and
either have GHCi look for .ghci in %HOME%, as opposed
to %HOMEPATH% (so that this value is not automatically
set by the OS), or to set %HOMEPATH% itself to be
c:\home.

However, when I go to the Control Panel, then to the
System applet, then to the Advanced tab, then click on
the Environment Variables button, and then create an
environmental variable called "HOMEPATH" (either local
or global), this setting does not override the default
setting for this environmental variable, and GHCi
still looks for .ghci in the default location
(c:\Documents and Settings\<username>).

Does anybody know how to cause GHCi to look for .ghci
in c:\home?

Benjamin L. Russell

--- Claus Reinke <claus.reinke <at> talk21.com> wrote:

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

Permalink | Reply |
headers
Simon Marlow | 20 Dec 10:32

Re: Re: ANNOUNCE: GHC version 6.8.2

Benjamin L. Russell wrote:
> This fixed the problem, and on Windows XP
> Professional, I was able to set GHCi to find .ghci in
> %HOMEPATH%, which turned out to be c:\Documents and
> Settings\<username>.
> 
> However, I would like to override this setting, and
> either have GHCi look for .ghci in %HOME%, as opposed
> to %HOMEPATH% (so that this value is not automatically
> set by the OS), or to set %HOMEPATH% itself to be
> c:\home.
> 
> However, when I go to the Control Panel, then to the
> System applet, then to the Advanced tab, then click on
> the Environment Variables button, and then create an
> environmental variable called "HOMEPATH" (either local
> or global), this setting does not override the default
> setting for this environmental variable, and GHCi
> still looks for .ghci in the default location
> (c:\Documents and Settings\<username>).
> 
> Does anybody know how to cause GHCi to look for .ghci
> in c:\home?

Create a .ghci file in c:\Documents And Settings\<user>, with the following 
contents:

:cmd readFile "c:\\home\\.ghci"

Cheers,
(Continue reading)

Permalink | Reply |
headers
Hugo Pacheco | 20 Dec 17:53

Re: Re: ANNOUNCE: GHC version 6.8.2

The binaries do work in Leopard, but it misses all library files, such as System.IO.
How can I build them form the sources? I have no cabal-install as well. and the macports 6.6 is broken.

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply |
headers
Alex Jacobson | 20 Dec 19:19

Re: Re: ANNOUNCE: GHC version 6.8.2

My experience with the mac stuff is that you are just better off 
building everything yourself.  It runs in the background while you go 
eat dinner and then you are done.

-Alex-

Hugo Pacheco wrote:
> The binaries do work in Leopard, but it misses all library files, such 
> as System.IO.
> How can I build them form the sources? I have no cabal-install as well. 
> and the macports 6.6 is broken.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell mailing list
> Haskell <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply |
headers
Hugo Pacheco | 20 Dec 20:31

Re: Re: ANNOUNCE: GHC version 6.8.2

>From the ghc-6.8.2 sources then, I'm just afraid of possible errors, and I don't have any previous ghc installed.

Do the sources permit bootstrapping? From what I know...
The source distribution needs an installed GHC (version 6.0 at least). If your platform isn't currently supported with a binary distribution, then you'll need to consult the section on Porting GHC in the Building Guide.

I'm afraid of the same error as macports 6.6.1:

configure: error: GHC is required unless bootstrapping from .hc files.

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply |
headers
Gregory Wright | 20 Dec 21:00
Favicon

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


Hi,

On Dec 20, 2007, at 2:31 PM, Hugo Pacheco wrote:

>From the ghc-6.8.2 sources then, I'm just afraid of possible errors, and I don't have any previous ghc installed.

Do the sources permit bootstrapping? From what I know...
The source distribution needs an installed GHC (version 6.0 at least). If your platform isn't currently supported with a binary distribution, then you'll need to consult the section on Porting GHC in the Building Guide.

I'm afraid of the same error as macports 6.6.1:

configure: error: GHC is required unless bootstrapping from .hc files.


The macports 6.8.2 should be ready soon for Tiger (PPC and Intel) and Leopard (Intel only).
I have had successful builds on these platforms and the Portfile is updated.  However,
the 6.8 branch seems to have introduced a bug in file locking (#1992 in the trac) that
causes the build to fail once out of every four or five times.  This is not acceptable for
a production release, so this has to be tracked down before GHC from macports is
updated.

Sorry for the delay,
Greg



_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply |
headers
Hugo Pacheco | 20 Dec 23:30

Re: Re: ANNOUNCE: GHC version 6.8.2

But is it like days, weeks, months?
I really need GHC installed on my intel mac w/ leopard.

How can I build the libraries in the current leopard release?

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply |
headers
Gregory Wright | 21 Dec 00:00
Favicon

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


On Dec 20, 2007, at 5:30 PM, Hugo Pacheco wrote:

> But is it like days, weeks, months?
> I really need GHC installed on my intel mac w/ leopard.
>

The new macports ghc should be ready in days to a week, most likely.   
If you want I can send you
the portfile to try, I can't guarantee it but it seems to work most of  
the time.  If the build fails,
just "sudo port clean" and try again.

> How can I build the libraries in the current leopard release?

I don't understand your question.  Which libraries do you want to build?

-Greg

> _______________________________________________
> Haskell mailing list
> Haskell <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply |
headers
Benjamin L. Russell | 21 Dec 02:41
Favicon
Gravatar

Re: Re: ANNOUNCE: GHC version 6.8.2

Will a binary version of 6.8.2 be released any time
soon for Mac OS X 10.5.x Leopard running on a PowerPC,
as opposed to an Intel?

I have a first-generation aluminum PowerBook with a
PowerPC currently running Mac OS X 10.2.8 Jaguar, and
am considering upgrading to Leopard next month, but
want to install GHC 6.8.2 on it with a binary.

Does this mean that I should not upgrade to that OS
version?

Benjamin L. Russell

--- Gregory Wright <gwright <at> comcast.net> wrote:

> ...
> The macports 6.8.2 should be ready soon for Tiger
> (PPC and Intel) and  
> Leopard (Intel only).
> I have had successful builds on these platforms and
> the Portfile is  
> updated.  However,
> the 6.8 branch seems to have introduced a bug in
> file locking (#1992  
> in the trac) that
> causes the build to fail once out of every four or
> five times.  This  
> is not acceptable for
> a production release, so this has to be tracked down
> before GHC from  
> macports is
> updated.
> 
> Sorry for the delay,
> Greg
> 
> 
> 
> > _______________________________________________
> Haskell mailing list
> Haskell <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
Permalink | Reply |
headers
Hugo Pacheco | 21 Dec 04:35

Re: Re: ANNOUNCE: GHC version 6.8.2

Hmm, basically, the build from the GHC site ssimply installs the executables, every libary file is missing somehow (all the base package.. etc)

Therefore I have two options to have a working 6.8.x installation:
- wait around a week for a new macport (preferable)
- try to install the missing libraries in the corrent directories

I'm sorry for enquiring about this kind of specific stuff
hugo

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply |
headers
Chris Kuklewicz | 21 Dec 10:58

Re: Re: ANNOUNCE: GHC version 6.8.2

Benjamin L. Russell wrote:
> Will a binary version of 6.8.2 be released any time
> soon for Mac OS X 10.5.x Leopard running on a PowerPC,
> as opposed to an Intel?
> 
> I have a first-generation aluminum PowerBook with a
> PowerPC currently running Mac OS X 10.2.8 Jaguar, and
> am considering upgrading to Leopard next month, but
> want to install GHC 6.8.2 on it with a binary.
> 
> Does this mean that I should not upgrade to that OS
> version?

I have a PPC laptop with OS 10.5.1 Leopard.

The ghc-6.8.1 does not work.  Though there is limited success if you only ever
use -fvia-C.  Fixing one problem (
http://hackage.haskell.org/trac/ghc/ticket/1843 ) has merely revealed another (
http://hackage.haskell.org/trac/ghc/ticket/1958 ).

The problem is being worked on.  But you will not get (PPC && Leopard &&
ghc-6.8) yet.
Permalink | Reply |
headers
Benjamin L. Russell | 21 Dec 11:40
Favicon
Gravatar

Re: Re: ANNOUNCE: GHC version 6.8.2

Thank you; yes, that will work for the time being,
until an option for specifying the %HOME% directory is
re-incorporated back into a future version of GHCi.

It would probably be better if GHCi simply looked for
.ghci in the location specified by the %HOME%
environmental variable (which can be customized),
instead of the one in the %HOMEPATH% variable (which
cannot).

One of the best solutions, in my opinion, would be if
GHCi looked for .ghci in a location specified by a
custom %GHCHOME% environmental variable, since the
%HOME% variable is also used by Emacs.  That way, I
could put .ghci in a location separate from both the
Emacs and OS home directories.

Benjamin L. Russell

--- Simon Marlow <simonmarhaskell <at> gmail.com> wrote:

> Benjamin L. Russell wrote:
> > This fixed the problem, and on Windows XP
> > Professional, I was able to set GHCi to find .ghci
> in
> > %HOMEPATH%, which turned out to be c:\Documents
> and
> > Settings\<username>.
> > 
> > However, I would like to override this setting,
> and
> > either have GHCi look for .ghci in %HOME%, as
> opposed
> > to %HOMEPATH% (so that this value is not
> automatically
> > set by the OS), or to set %HOMEPATH% itself to be
> > c:\home.
> > 
> > However, when I go to the Control Panel, then to
> the
> > System applet, then to the Advanced tab, then
> click on
> > the Environment Variables button, and then create
> an
> > environmental variable called "HOMEPATH" (either
> local
> > or global), this setting does not override the
> default
> > setting for this environmental variable, and GHCi
> > still looks for .ghci in the default location
> > (c:\Documents and Settings\<username>).
> > 
> > Does anybody know how to cause GHCi to look for
> .ghci
> > in c:\home?
> 
> Create a .ghci file in c:\Documents And
> Settings\<user>, with the following 
> contents:
> 
> :cmd readFile "c:\\home\\.ghci"
> 
> Cheers,
> 	Simon
> _______________________________________________
> Haskell mailing list
> Haskell <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
Permalink | Reply |

Gmane