ANNOUNCE: GHC version 6.8.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
72 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Christian Maeder-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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Christian Maeder-2
In reply to this post by Manuel M T Chakravarty
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.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Simon Marlow-5
In reply to this post by Juanma Barranquero
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero
On Dec 14, 2007 3:53 PM, Simon Marlow <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Simon Marlow-5
Juanma Barranquero wrote:
> On Dec 14, 2007 3:53 PM, Simon Marlow <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero
On Dec 14, 2007 5:09 PM, Simon Marlow <[hidden email]> wrote:

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

Thanks.

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Duncan Coutts
In reply to this post by Simon Marlow-5

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

> Juanma Barranquero wrote:
> > On Dec 14, 2007 3:53 PM, Simon Marlow <[hidden email]> wrote:
> >> But do you really want getHomeDirectory to return $HOME?
> >
> > Yes!
> >
> > If I define %HOME, it is *exactly* because I don't want to use
> > Windows' idea of a home directory (which could be perhaps more
> > accurately defined as "hidden away storage area for
> > automatically-saved configuration settings").
>
> Ok.  Unless there are any objections, this is what we'll do.

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

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

If a particular application (like ghci) wants to consult $HOME in
preference to getHomeDirectory it can do so. I don't think we need to
make all Haskell programs behave in a non-standard way especially since
most other programs are not going to.

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

Duncan

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero
On Dec 14, 2007 11:46 PM, Duncan Coutts <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Felix Martini
In reply to this post by Duncan Coutts
On Dec 14, 2007 11:46 PM, Duncan Coutts <[hidden email]> 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\.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero
On Dec 15, 2007 2:16 AM, Felix Martini <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Iavor Diatchki
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 <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: ANNOUNCE: GHC version 6.8.2

Bulat Ziganshin-2
In reply to this post by Juanma Barranquero
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:[hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

sethk
On Sat, 15 Dec 2007 21:31:25 +0300
Bulat Ziganshin <[hidden email]> 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 <[hidden email]>

>
> --
> Best regards,
>  Bulat                            mailto:[hidden email]
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

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

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

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

Thanks,
Yitz
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

sethk
On Sun, 16 Dec 2007 03:21:14 +0200
"Yitzchak Gale" <[hidden email]> wrote:

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

Why is it *not* trivial to wrap the function?  Regardless of whether you like the resulting solution, it is undeniably trivial to change the name of a function, create a new function with the (original) name, and have that new function call the original function, or call the original function based on some criteria, or implement different behavior entirely?  I did so here, and in roughly 10 minutes I verified that the behavior was exactly as one would expect.

Now, you may not approve of the resulting behavior, but that's an entirely separate question of whether something is, or isn't, trivial to implement.  I wrote a few lines of code; certainly seemed trivial to me.

I have a bit more sympathy for your assertion that changing the default behavior is not something to be done lightly, but if a small modification allows you to implement either the old or new behavior, the question becomes what should the default behavior be?  (Or perhaps the *default* behavior?  I've always found that the use of punctuation as a substitute for rational discussion is an attempt to be insulting rather than to enter into a discussion on the merits.

If you believe something is not trivial, then state your reasons.  If you don't have a reason, hold the bluster and the asterisks.

Seth

>
> The current behavior is not more WIndows native - it is
> arguably much worse. The %HOMEPATH% variable
> should definitely not be used. The folder that it points
> to is not a "home directory" and should not be used
> that way. But if there is no other way to provide a value
> for getHomeDirectory, I guess that is still better than
> throwing a run-time exception, but at least obtain
> the path in a somewhat Windows-friendly way by
> using the API properly.
>
> It is just not true that using %HOME% creates
> problems. This is a widespread convention, in
> active use. Admittedly ad-hoc, but it works.
> Does anyone know of even a single
> incident in which this created a problem?
>
> Better native Windows integration is definitely an
> important goal. The whole idea of a ".ghci"
> file is very Unixy, for example. There is a
> lot of work to be done in this direction. Pulling
> the rug out from under %HOME% without
> providing a reasonable alternative is not the
> way to begin.
>
> By "reasonable alternative", I mean a way that
> users can configure GHC's notion of
> "home directory" at run-time on Windows.
>
> Truthfully, I don't think this should be the first
> priority for better Windows integration. Wouldn't
> our time be better spent on Visual Studio integration
> and WinAPI support? Not to mention .NET...
>
> Thanks,
> Yitz
>


--
Seth Kurtzberg <[hidden email]>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Yitzchak Gale
Hi Seth.

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

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

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

That may be trivial when writing a new program, but it may also
be difficult or even impossible when the code is already in use
and shared among many other existing programs.

Summarizing:

o The current (until recently) method has been in place for a
long time, and works fine.

o It follows a widely-used convention, though arguably a
somewhat messy one.

o It provides a prominent behavior, so changing it suddenly
is very painful.

o It is dubious whether the change, as implemented, achieves
its intended purpose at all, namely better Windows integration.

o Even if you believe that it does, the small amount of value
it provides is not worth the cost.

I support providing a default value for the home directory
when the user does not specify one. It would be nice if
this could be done in a more Windowsy way.

Since another of my points is that we are focusing
too much on this issue, I will say no more and gracefully
accept whatever the community decides at this point.

Thanks,
Yitz
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Duncan Coutts
In reply to this post by Yitzchak Gale

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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

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


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

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

This is the ideal solution for ghci on Windows.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Yitzchak Gale
Hi Felix,

You have described your own style of using
some of the Window's Known Folders. In my
opinion your style is a bit Unixy, but that's fine,
you should be allowed to do it that way in GHC.
But GHC should not force others to do it only that way.

btw, years ago I used to use the Profile folder as
if it were a "home directory". It caused me no
end of problems. But if it works for you, it should
certainly be possible for you to do it that way.

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

Felix Martini wrote:
> That's not correct. It is the user's home folder aka user profile
> folder

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

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

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

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

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

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

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

It is not the current behavior, and it is not a task
for Windows. Windows will never do it. There is no
such thing as a "home folder" on Windows.

The new current behavior is to ask the Windows API for
the user's Profile folder, and force it to be used
as if it were a "home directory". That is wrong.

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

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

As Duncan Coutts pointed out, the getAppUserDataDirectory
function makes much more sense - that is a notion
that ought to exist on all platforms.

> This is the ideal solution for ghci on Windows.

Yes, that is the right place to put the ".ghci" file.

Ach, here I go again. I've got to get back to work...

Regards,
Yitz
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Juanma Barranquero
On Dec 16, 2007 3:38 PM, Yitzchak Gale <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
1234