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. Just because I happen to have gmp on my Mac, I don't want to build a dependency into all binaries generated by ghc that prevent me from using these binaries on other Macs. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr performance
Hello Scott, Sunday, December 16, 2007, 11:57:33 PM, you wrote: > My question is: what exactly does GHC.Prim.touch# do? This appears to it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc optimizer that data were accessed so it doesn't free the memory -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ForeignPtr performance
Hi, I do a lot of programming with small compound objects, things like 3d vectors or RGBA tuples for images. For performance reasons, I keep them in StorableArrays, since there is no way to use these things with UArrays. (But that's a topic for another thread.) Some how the notion got into my head that StorableArrays were slow, I think from old versions of GHC. So I've gotten into the habit of using withStorableArray and peek/poke to work on my arrays. This, as you can imagine, is cumbersome. Not only because of the extra typing, but also because I have to do everything in the IO monad, even if the array is read-only. So I'm thinking about writing my own IArray instance using ForeignPtr for storage and unsafePerformIO for access. I did a little experiment, comparing > forM_ [0..lots] $ \i -> withForeignPtr fp $ \p -> pokeElemOff p i i to > withForeignPtr fp $ \p -> forM_ [0..lots] $ \i -> pokeElemOff p i i And there seemed to be no difference in running time, which is great. So I'm thinking of making unsafeAt something like > unsafeAt (MyArray fp) i = unsafePerformIO $ withForeignPtr fp $ \p -> > peekElemOff p i My question is: what exactly does GHC.Prim.touch# do? This appears to be the critical function of withForeignPtr, and if I write my IArray instance as above, I have no way to float this touch# out of my loops, as I currently do using withStorableArray. It appears from my simple experiment that touch# does nothing at runtime. But maybe this is only because no memory is allocated inside my simple loop? Maybe if I write non-trivial loops, then touch# will actually cost something? Intensely curious, Scott ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 <[EMAIL PROTECTED]> wrote: > Felix Martini wrote: > > On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote: > >> No, the two are not the same. It is the User Profile folder. > >> It is not a Unix-style home directory - there is no such concept > >> on Windows. The two are used very differently. > > > > I guess we disagree about that. I believe what Micosoft calls the user > > profile folder is equivalent to what is called the user home folder in > > Unix. This is especially obvious in Vista, most folder names are the > > same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music. > > FWIW, here on Linux I didn't like all my automatically > generated-in-$HOME stuff being spewed all over my own organization, so > > ]echo $HOME > /Users/me/HOME > (I'm in GoboLinux which uses "/Users" rather than "/home", which isn't > important to this) > > and my .zshrc has > cd; cd .. > (a.k.a. cd /Users/me) > to take me to my personal home directory in the non-Unix sense. It's a > bit of a nuisance sometimes, but worth it for me; the worst that happens > is sometimes I have to go up a level first in file-chooser dialogs or > "~/../" paths. > > Isaac > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
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 to do instead, > > as there always was until now. It depends on a lot > > of factors - exactly how are you using this > > "home directory", how does it interact with other > > apps, details about the platform, etc.. > > > > If nothing is specified, then, as a last resort, there is no > > choice but to use the Profile folder as the default. > > FWIW, I agree 100% with this. > > Juanma Indeed, what's the alternative? Also, in general deployed programs are compiled and linked. Behavior related to ghci initialization is not going to break deployed software. Changes to the behavior of a development tool are in a different class than changes that may impact deployed programs. Seth > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Seth Kurtzberg <[EMAIL PROTECTED]> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
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 - 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 Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 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 Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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. This is the ideal solution for ghci on Windows. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
