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
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
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
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
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
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
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
On Dec 18, 2007 8:54 PM, Manuel M T Chakravarty [EMAIL PROTECTED] 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
Judah Jacobson:
On Dec 18, 2007 8:54 PM, Manuel M T Chakravarty
[EMAIL PROTECTED] 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
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
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
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
On Dec 18, 2007 11:18 AM, Simon Marlow [EMAIL PROTECTED] 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
Judah Jacobson:
On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty
[EMAIL PROTECTED] 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
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
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
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
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
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
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
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
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
On Dec 14, 2007 1:30 AM, Christian Maeder [EMAIL PROTECTED] 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
On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty [EMAIL PROTECTED] 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
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
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
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
On Dec 16, 2007 3:38 PM, Yitzchak Gale [EMAIL PROTECTED] 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 -
On Sun, 16 Dec 2007 16:43:53 +0100
Juanma Barranquero [EMAIL PROTECTED] wrote:
On Dec 16, 2007 3:38 PM, Yitzchak Gale [EMAIL PROTECTED] 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
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
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
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
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
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
On Sat, 15 Dec 2007 21:31:25 +0300
Bulat Ziganshin [EMAIL PROTECTED] 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
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
On Sun, 16 Dec 2007 03:21:14 +0200
Yitzchak Gale [EMAIL PROTECTED] 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
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?
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
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.
Juanma Barranquero wrote:
On Dec 14, 2007 3:53 PM, Simon Marlow [EMAIL PROTECTED] 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
On Dec 14, 2007 5:09 PM, Simon Marlow [EMAIL PROTECTED] wrote:
Ok. Unless there are any objections, this is what we'll do.
Thanks.
Juanma
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
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
On Fri, 2007-12-14 at 16:09 +, Simon Marlow wrote:
Juanma Barranquero wrote:
On Dec 14, 2007 3:53 PM, Simon Marlow [EMAIL PROTECTED] 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'
On Dec 14, 2007 11:46 PM, Duncan Coutts [EMAIL PROTECTED] 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
On Dec 14, 2007 11:46 PM, Duncan Coutts [EMAIL PROTECTED] 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.
On Dec 15, 2007 2:16 AM, Felix Martini [EMAIL PROTECTED] 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
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
On Dec 12, 2007 7:44 PM, Ian Lynagh [EMAIL PROTECTED] 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
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
On Dec 13, 2007 2:05 PM, Claus Reinke [EMAIL PROTECTED] 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
Juanma Barranquero wrote:
On Dec 13, 2007 2:05 PM, Claus Reinke [EMAIL PROTECTED] 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
On Dec 13, 2007 4:20 PM, Juanma Barranquero [EMAIL PROTECTED] 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
On Dec 13, 2007 4:13 PM, Simon Marlow [EMAIL PROTECTED] 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
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
On Dec 13, 2007 4:49 PM, Claus Reinke [EMAIL PROTECTED] 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
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 -
On Dec 13, 2007 6:03 PM, Claus Reinke [EMAIL PROTECTED] 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
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
=
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
On Dec 13, 2007 11:31 PM, Yitzchak Gale [EMAIL PROTECTED] 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
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
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
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
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
=
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
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
67 matches
Mail list logo
