From mnislaih at gmail.com Sun Apr 1 11:50:00 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Sun Apr 1 11:49:02 2007 Subject: [Haskell-cafe] ghc-6.7.20070330 on Mac OS X In-Reply-To: <99295021-E577-4005-8426-F98786FAA504@student.unsw.edu.au> References: <99295021-E577-4005-8426-F98786FAA504@student.unsw.edu.au> Message-ID: (redirecting to glasgow-haskell-users) It is well known that the readline lib that comes with OS X is no good, and you need to use a replacement. A nice post from the blogosphere explaining all this: http://mult.ifario.us/articles/2006/10/17/ghc-6-6-and-mac-os-x- readline-quick-fix If that doesn't help, please post the errors that you get when building the readline package. Cheers pepe On 01/04/2007, at 16:33, Ruben Zilibowitz wrote: > I am trying to build this version of GHC on Mac OS X. I'm currently > using GHC 6.6. The build is failing with the following error: > > ghci/InteractiveUI.hs:69:7: > Could not find module `System.Console.Readline': > Use -v to see a list of the files searched for. > < residency (4 samples), 26M in use, 0.02 INIT (0.00 elapsed), 2.11 > MUT (15.73 elapsed), 0.31 GC (0.36 elapsed) :ghc>> > make[2]: *** [depend] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 > > So it seems I need to install the Readline library. But building > the Readline library is also giving me errors on my system. > > Just wondering if someone else has managed to build ghc-6.7.x on > Mac OS X? If so, what did you need to do? > > Cheers, > > Ruben > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From gwright at comcast.net Sun Apr 1 14:34:45 2007 From: gwright at comcast.net (Gregory Wright) Date: Sun Apr 1 14:33:46 2007 Subject: [Haskell-cafe] ghc-6.7.20070330 on Mac OS X In-Reply-To: References: <99295021-E577-4005-8426-F98786FAA504@student.unsw.edu.au> Message-ID: Hi Ruben, The GHC wiki also has information on this, and should be your first stop if you are experiencing build problems: http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX At least under MacPorts, I have had no trouble building 6.7-20070330. I will be releasing a new portfile for ghc-devel in a few days that will build the latest from the darcs repository. Best Wishes, Greg On Apr 1, 2007, at 11:50 AM, Pepe Iborra wrote: > (redirecting to glasgow-haskell-users) > > It is well known that the readline lib that comes with OS X is no > good, and you need to use a replacement. A nice post from the > blogosphere explaining all this: > > http://mult.ifario.us/articles/2006/10/17/ghc-6-6-and-mac-os-x- > readline-quick-fix > > If that doesn't help, please post the errors that you get when > building the readline package. > > Cheers > pepe > From gwright at comcast.net Sun Apr 1 15:40:11 2007 From: gwright at comcast.net (Gregory Wright) Date: Sun Apr 1 15:39:13 2007 Subject: More on FreeBSD/amd64 In-Reply-To: <20070330003605.GA18523@matrix.chaos.earth.li> References: <460B8990.606@gmail.com> <20070330003605.GA18523@matrix.chaos.earth.li> Message-ID: <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> Hi Ian, On Mar 29, 2007, at 8:36 PM, Ian Lynagh wrote: > > Hmm, oh well. > > OK, so we know that the wrong value is being passed to > newPinnedByteArray#, right? There aren't many calls to that: > > libraries/base/Foreign/Marshal/Alloc.hs > libraries/base/GHC/ForeignPtr.hs (4 calls) > libraries/base/GHC/Handle.hs > > so the easiest way forward is probably to print something unique, and > the size passed, in each one and try to work backwards towards the > source. e.g. > > mallocPlainForeignPtrBytes (I# size) = IO $ \s -> > case newPinnedByteArray# size s of { (# s, mbarr# #) -> > > => > > mallocPlainForeignPtrBytes i@(I# size) = do > print ('A', i) > IO $ \s -> > case newPinnedByteArray# size s of { (# s, mbarr# #) -> > > (it might be worth printing something after the existing IO action as > well, just to avoid confusion as to what is happening. > Is there a version of "print" I can use for debugging these libraries? Just adding "print" causes a cycle in module dependencies. I can now start gdb instruction stepping close to the crash and it looks as if the trouble comes from mallocForeignPtr. I'm trying to find out what calls that now. Best Wishes, Greg From igloo at earth.li Sun Apr 1 15:57:35 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Apr 1 15:56:33 2007 Subject: More on FreeBSD/amd64 In-Reply-To: <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> References: <460B8990.606@gmail.com> <20070330003605.GA18523@matrix.chaos.earth.li> <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> Message-ID: <20070401195735.GC16200@matrix.chaos.earth.li> Hi Gregory, On Sun, Apr 01, 2007 at 03:40:11PM -0400, Gregory Wright wrote: > > > mallocPlainForeignPtrBytes i@(I# size) = do > > print ('A', i) > > IO $ \s -> > > case newPinnedByteArray# size s of { (# s, mbarr# #) -> > > > >(it might be worth printing something after the existing IO action as > >well, just to avoid confusion as to what is happening. > > Is there a version of "print" I can use for debugging these libraries? > Just adding "print" causes a cycle in module dependencies. Ah, remove the #if/#endif around the definition of "puts", its export, and the GHC.Pack import in libraries/base/GHC/Handle.hs Thanks Ian From gwright at comcast.net Sun Apr 1 18:10:25 2007 From: gwright at comcast.net (Gregory Wright) Date: Sun Apr 1 18:09:26 2007 Subject: More on FreeBSD/amd64 In-Reply-To: <20070401195735.GC16200@matrix.chaos.earth.li> References: <460B8990.606@gmail.com> <20070330003605.GA18523@matrix.chaos.earth.li> <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> <20070401195735.GC16200@matrix.chaos.earth.li> Message-ID: <0A09DF63-FCA5-4825-9F62-C62D912DF5C3@comcast.net> Hi Ian, On Apr 1, 2007, at 3:57 PM, Ian Lynagh wrote: > > Hi Gregory, > >> Is there a version of "print" I can use for debugging these >> libraries? >> Just adding "print" causes a cycle in module dependencies. > > Ah, remove the #if/#endif around the definition of "puts", its export, > and the GHC.Pack import in libraries/base/GHC/Handle.hs > No such luck. I even copied "puts" into libraries/base/GHC/ ForeignPtr.hs but I still get I cycle because I need withCString to define "puts": Module imports form a cycle for modules: GHC.ForeignPtr imports: GHC.Show GHC.Err GHC.Ptr GHC.IOBase GHC.Base GHC.List Foreign.Storable Foreign.Ptr Foreign.C Control.Monad Foreign.C imports: Foreign.C.Error Foreign.C.String Foreign.C.Types Foreign.C.Error imports: GHC.Base GHC.Num GHC.IOBase Data.Maybe Foreign.Marshal.Error Foreign.C.String Foreign.C.Types Foreign.Ptr Foreign.Storable GHC.IOBase Foreign.C.String imports: GHC.Base GHC.IOBase GHC.Num GHC.Real GHC.List Data.Word Foreign.Storable Foreign.Ptr Foreign.C.Types Foreign.Marshal.Array Foreign.C.Types Data.Typeable imports: GHC.Arr GHC.Stable GHC.ForeignPtr GHC.Ptr GHC.STRef GHC.ST GHC.IOBase GHC.IOBase GHC.Real GHC.Float GHC.Num GHC.Err GHC.Show GHC.Base Data.List Data.Word Data.Int Data.Either Data.Maybe Data.HashTable Foreign.Marshal.Array imports: GHC.Base GHC.Err GHC.List GHC.Num GHC.IOBase Foreign.Marshal.Utils Foreign.Marshal.Alloc Foreign.Storable Foreign.Ptr Control.Monad Foreign.Marshal.Utils imports: GHC.Base GHC.Num GHC.Real GHC.IOBase Foreign.Marshal.Alloc Foreign.C.Types Foreign.Storable Foreign.Ptr Data.Maybe Foreign.Marshal.Alloc imports: GHC.Num GHC.Base GHC.Err GHC.Ptr GHC.Real GHC.IOBase Foreign.ForeignPtr Foreign.Storable Foreign.C.Types Foreign.Ptr Data.Maybe Foreign.ForeignPtr imports: GHC.ForeignPtr GHC.Err GHC.Num GHC.IOBase GHC.Base Foreign.Storable Foreign.Ptr <> gmake[1]: *** [depend] Error 1 gmake: *** [boot] Error 1 gmake: Leaving directory `/tmp/ghc-6.4.2/libraries' GHC.ForeignPtr does seem to be the root of much evil, since everything seems to depend on it. Any other hints on how I could get some output? BTW, I have done some more tracing with gdb and I think I am a bit closer to the underlying bug. Before the bad call to newPinnedByteArray#, there are a number of calls to functions bound to libc's regex functions (e.g., regcomp, regexec). Since this is FreeBSD's libc, there may easily be differences from the much better tested glibc. It looks like the regex functions are being used to look up package names, since I thought I saw a call from somewhere in Cabal.Distribution. I need to check this once I get ghc-6.4.2 rebuilt. Best Wishes, Greg From igloo at earth.li Sun Apr 1 18:22:50 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Apr 1 18:21:47 2007 Subject: More on FreeBSD/amd64 In-Reply-To: <0A09DF63-FCA5-4825-9F62-C62D912DF5C3@comcast.net> References: <460B8990.606@gmail.com> <20070330003605.GA18523@matrix.chaos.earth.li> <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> <20070401195735.GC16200@matrix.chaos.earth.li> <0A09DF63-FCA5-4825-9F62-C62D912DF5C3@comcast.net> Message-ID: <20070401222250.GA15090@matrix.chaos.earth.li> On Sun, Apr 01, 2007 at 06:10:25PM -0400, Gregory Wright wrote: > > >Ah, remove the #if/#endif around the definition of "puts", its export, > >and the GHC.Pack import in libraries/base/GHC/Handle.hs > > > No such luck. I even copied "puts" into libraries/base/GHC/ > ForeignPtr.hs > but I still get I cycle because I need withCString to define "puts": Oh, the 6.4.2 definition is different to the 6.6 definition. Does the 6.6 one work with 6.4.2?: puts :: String -> IO () puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) 0 (fromIntegral (length s)) return () (packCString# come from GHC.Pack) Thanks Ian From vivian.mcphail at paradise.net.nz Mon Apr 2 01:41:54 2007 From: vivian.mcphail at paradise.net.nz (Vivian McPhail) Date: Mon Apr 2 01:42:44 2007 Subject: ghci doesn't run FFi'd code which works under ghc on WinXP Message-ID: <000901c774e9$a02575c0$6601a8c0@box> Hi All, I wrote a binding to matlab matrix.h and mat.h. My test program works when I compile a binary, but when I try to use the code in ghci nothing happens. There are no error messages, but all computations return a blank line. Does this fall into a known class of error? I can provide my source code, but because of licensing requirements I can't provide the .dll's against which the code is linked. TIA Vivian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070402/3767d0de/attachment.htm From simonpj at microsoft.com Mon Apr 2 04:34:33 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Apr 2 04:33:32 2007 Subject: [Haskell-cafe] ghc-6.7.20070330 on Mac OS X In-Reply-To: References: <99295021-E577-4005-8426-F98786FAA504@student.unsw.edu.au> Message-ID: There is also a special page all about building GHC on MaxOSX http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX If it doesn't explain enough about readline (e.g. does it include "the nice post from the blogosphere"?), perhaps someone can enhance it? In general, when building GHC, the place to look is http://hackage.haskell.org/trac/ghc/wiki/Building and there are architecture-specific sub-pages. Do please add painfully-learned information to these wiki pages! thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Pepe Iborra | Sent: 01 April 2007 16:50 | To: Ruben Zilibowitz | Cc: glasgow-haskell-users@haskell.org Users | Subject: Re: [Haskell-cafe] ghc-6.7.20070330 on Mac OS X | | (redirecting to glasgow-haskell-users) | | It is well known that the readline lib that comes with OS X is no | good, and you need to use a replacement. A nice post from the | blogosphere explaining all this: | | http://mult.ifario.us/articles/2006/10/17/ghc-6-6-and-mac-os-x- | readline-quick-fix | | If that doesn't help, please post the errors that you get when | building the readline package. | | Cheers | pepe | | On 01/04/2007, at 16:33, Ruben Zilibowitz wrote: | | > I am trying to build this version of GHC on Mac OS X. I'm currently | > using GHC 6.6. The build is failing with the following error: | > | > ghci/InteractiveUI.hs:69:7: | > Could not find module `System.Console.Readline': | > Use -v to see a list of the files searched for. | > < residency (4 samples), 26M in use, 0.02 INIT (0.00 elapsed), 2.11 | > MUT (15.73 elapsed), 0.31 GC (0.36 elapsed) :ghc>> | > make[2]: *** [depend] Error 1 | > make[1]: *** [stage2] Error 2 | > make: *** [bootstrap2] Error 2 | > | > So it seems I need to install the Readline library. But building | > the Readline library is also giving me errors on my system. | > | > Just wondering if someone else has managed to build ghc-6.7.x on | > Mac OS X? If so, what did you need to do? | > | > Cheers, | > | > Ruben | > | > _______________________________________________ | > Haskell-Cafe mailing list | > Haskell-Cafe@haskell.org | > http://www.haskell.org/mailman/listinfo/haskell-cafe | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From gwright at comcast.net Mon Apr 2 11:57:49 2007 From: gwright at comcast.net (Gregory Wright) Date: Mon Apr 2 11:56:48 2007 Subject: More on FreeBSD/amd64 In-Reply-To: <20070401222250.GA15090@matrix.chaos.earth.li> References: <460B8990.606@gmail.com> <20070330003605.GA18523@matrix.chaos.earth.li> <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> <20070401195735.GC16200@matrix.chaos.earth.li> <0A09DF63-FCA5-4825-9F62-C62D912DF5C3@comcast.net> <20070401222250.GA15090@matrix.chaos.earth.li> Message-ID: <97C4BAA8-C23E-40F1-A288-02C5CF1F8511@comcast.net> Hi Ian, On Apr 1, 2007, at 6:22 PM, Ian Lynagh wrote: > On Sun, Apr 01, 2007 at 06:10:25PM -0400, Gregory Wright wrote: >> >>> Ah, remove the #if/#endif around the definition of "puts", its >>> export, >>> and the GHC.Pack import in libraries/base/GHC/Handle.hs >>> >> No such luck. I even copied "puts" into libraries/base/GHC/ >> ForeignPtr.hs >> but I still get I cycle because I need withCString to define "puts": > > Oh, the 6.4.2 definition is different to the 6.6 definition. > > Does the 6.6 one work with 6.4.2?: > > puts :: String -> IO () > puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) > 0 (fromIntegral (length s)) > return () > > (packCString# come from GHC.Pack) > Still doesn't work. If I include the definition of write_rawBuffer just above puts (I can't import GHC.Handle because of the dependency loop) and dangerously change CInt to Int in the signature (can't import Foreign.C.Types for the same reason) I still get an error message saying that "fromInteger" is out of scope. This is what I have added to libraries/base/GHC/ForeignPtr.hs: import GHC.List ( null ) import GHC.Base import GHC.IOBase import GHC.List ( length ) import GHC.Pack -- this is new import GHC.Ptr ( Ptr(..) ) import GHC.Err import GHC.Show foreign import ccall unsafe "__hscore_PrelHandle_write" write_rawBuffer :: Int -> RawBuffer -> Int -> Int -> IO Int puts :: String -> IO () puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) 0 (length s) return () I'm wondering if I should just give up on trying to print anything out from this deep in the libraries and go back to looking at the debugger trace. My guess is still that a FreeBSD libc function is getting called and somehow storing a 32 bit value in a 64 bit location, with junk in the high order word. As always, hints and firm whacks on the side of the head will be appreciated. Best Wishes, Greg From bulat.ziganshin at gmail.com Mon Apr 2 12:13:16 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Apr 2 12:20:35 2007 Subject: More on FreeBSD/amd64 In-Reply-To: <97C4BAA8-C23E-40F1-A288-02C5CF1F8511@comcast.net> References: <460B8990.606@gmail.com> <20070330003605.GA18523@matrix.chaos.earth.li> <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> <20070401195735.GC16200@matrix.chaos.earth.li> <0A09DF63-FCA5-4825-9F62-C62D912DF5C3@comcast.net> <20070401222250.GA15090@matrix.chaos.earth.li> <97C4BAA8-C23E-40F1-A288-02C5CF1F8511@comcast.net> Message-ID: <1558891665.20070402201316@gmail.com> Hello Gregory, Monday, April 2, 2007, 7:57:49 PM, you wrote: >> puts :: String -> IO () >> puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) >> 0 (fromIntegral (length s)) >> return () >> >> (packCString# come from GHC.Pack) you may try to call C function with a result of (packCString# s) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gwright at comcast.net Mon Apr 2 16:39:02 2007 From: gwright at comcast.net (Gregory Wright) Date: Mon Apr 2 16:38:02 2007 Subject: ghc development version (6.7) from MacPorts Message-ID: Hi, For those who live on the bleeding edge, I have made a port of the latest development version of ghc for OS X through MacPorts. (If you are not familiar with MacPorts, see http://macports.org.) The build is from the darcs repository, and installs its binaries as -6.7. . This naming allows the development version to be installed alongside the released ghc-6.6 with no conflicts. The port should work with OS X 10.3 and later on Intel or PPC. The name of the port is "ghc-devel". Note that because this is really a _development_ version, it may be buggy or not build at all. For day to day use you want the released ghc-6.6. Have fun, Greg From igloo at earth.li Mon Apr 2 20:34:17 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Apr 2 20:33:11 2007 Subject: More on FreeBSD/amd64 In-Reply-To: <97C4BAA8-C23E-40F1-A288-02C5CF1F8511@comcast.net> References: <460B8990.606@gmail.com> <20070330003605.GA18523@matrix.chaos.earth.li> <90699598-67FA-4174-B334-7FF24ED63D2C@comcast.net> <20070401195735.GC16200@matrix.chaos.earth.li> <0A09DF63-FCA5-4825-9F62-C62D912DF5C3@comcast.net> <20070401222250.GA15090@matrix.chaos.earth.li> <97C4BAA8-C23E-40F1-A288-02C5CF1F8511@comcast.net> Message-ID: <20070403003417.GA27616@matrix.chaos.earth.li> Hi Gregory, On Mon, Apr 02, 2007 at 11:57:49AM -0400, Gregory Wright wrote: > > On Apr 1, 2007, at 6:22 PM, Ian Lynagh wrote: > > >Does the 6.6 one work with 6.4.2?: > > > >puts :: String -> IO () > >puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) > > 0 (fromIntegral (length s)) > > return () > > > >(packCString# come from GHC.Pack) > > Still doesn't work. If I include the definition of write_rawBuffer just > above puts (I can't import GHC.Handle because of the dependency loop) > and dangerously change CInt to Int in the signature (can't import > Foreign.C.Types for the same reason) Hmm, the foreign import types already look wrong, in both 6.4.2 and the HEAD. For now I recommend changing the definition in include/HsBase.h to only take and return HsInt, and to do the casting on the C side. include/HsBase.h: # ----------------------------- INLINE HsInt __hscore_PrelHandle_write( HsInt fd, HsAddr ptr, HsInt off, HsInt sz ) { return write(fd,(char *)ptr + off, (int)sz); } # ----------------------------- GHC/ForeignPtr.hs: # ----------------------------- import GHC.List import GHC.Pack import GHC.Num puts :: String -> IO () puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) 0 (length s) return () # ----------------------------- You'll also need to fix the types of the imports in GHC.Handle (there are two of them), and their uses. I successfully built 6.4.2 with these changes. [some hours pass] Actually, HsBase.h contains many type mismatches (I've just pushed a patch to the HEAD), and I think there are more lurking in the base package. I'll probably resume my hunt tomorrow. It's probably not worth debugging further with 6.4 unless we first backport these fixes; it's not particularly unlikely that one of them is the root cause of the bug, after all. Thanks Ian From greenrd at greenrd.org Tue Apr 3 07:43:08 2007 From: greenrd at greenrd.org (Robin Green) Date: Tue Apr 3 08:05:13 2007 Subject: Login problems with trac Message-ID: <20070403124308.1ee73e93@greenrd.ucd.ie> I am having difficulty logging in to GHC's trac. The situation is this: 1. I'm pretty sure I used to log in with username "greenrd" to file bugs (at least, that's what Firefox's password manager tells me!). That no longer works. I get the message below. ------------------------------------------------------------------ Permission Denied To create tickets or edit the wiki, please login with username guest, password guest. TICKET_CREATE privileges are required to perform this operation TracGuide ? The Trac User and Administration Guide ------------------------------------------------------------------ 2. I cannot log in with username "guest" using Firefox 1.5 on my office machine. I just get the same message, when I click "login". This occurs even after I have cleared my web browser's cache. Maybe I need to do something else other than clear the cache? 3. I have been able to log in once as a guest *and* create a ticket - but only on Firefox 2, on my office machine, which is not behind a proxy. 4. Strangest of all, I have not been able to log in as a guest using Firefox 2 on my dorm machine which is behind a proxy - even though Firefox is *not* automatically supplying a username and password! When I attempt to login as guest, I get redirected to http://hackage.haskell.org/trac/ghc and I don't seem to be logged in - a "login" link is still there, instead of a "logout" one. This is all rather confusing. I have not figured out what is going on here. -- Robin From simonpj at microsoft.com Tue Apr 3 08:25:45 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 3 08:24:40 2007 Subject: Login problems with trac In-Reply-To: <20070403124308.1ee73e93@greenrd.ucd.ie> References: <20070403124308.1ee73e93@greenrd.ucd.ie> Message-ID: Simon will help you out, though he is tied up right now. GHC's trac was majorly spammed yesterday, so I think he may have switched off guest access S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Robin Green | Sent: 03 April 2007 12:43 | To: glasgow-haskell-users@haskell.org | Subject: Login problems with trac | | I am having difficulty logging in to GHC's trac. The situation is this: | | 1. I'm pretty sure I used to log in with username "greenrd" to file bugs | (at least, that's what Firefox's password manager tells me!). That no | longer works. I get the message below. | | ------------------------------------------------------------------ | Permission Denied | | To create tickets or edit the wiki, please login with username guest, | password guest. | | TICKET_CREATE privileges are required to perform this operation | | TracGuide ? The Trac User and Administration Guide | ------------------------------------------------------------------ | | 2. I cannot log in with username "guest" using Firefox 1.5 on my | office machine. I just get the same message, when I click "login". This | occurs even after I have cleared my web browser's cache. Maybe I need | to do something else other than clear the cache? | | 3. I have been able to log in once as a guest *and* create a ticket - | but only on Firefox 2, on my office machine, which is not behind a | proxy. | | 4. Strangest of all, I have not been able to log in as a guest using | Firefox 2 on my dorm machine which is behind a proxy - even though | Firefox is *not* automatically supplying a username and password! When I | attempt to login as guest, I get redirected to | http://hackage.haskell.org/trac/ghc and I don't seem to be logged in | - a "login" link is still there, instead of a "logout" one. | | This is all rather confusing. I have not figured out what is going on | here. | | -- | Robin | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonmarhaskell at gmail.com Tue Apr 3 08:37:03 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 3 08:36:03 2007 Subject: Login problems with trac In-Reply-To: References: <20070403124308.1ee73e93@greenrd.ucd.ie> Message-ID: <46124A6F.607@gmail.com> Right, I turned off edit access by unknown users, except guest. I'm not inclined to enable it again until we have a solution, because this time the spam left quite a lot of damage to clean up. I've added greenrd to the 'developer' group, so you should be able to make changes from your account. Cheers, Simon Simon Peyton-Jones wrote: > Simon will help you out, though he is tied up right now. GHC's trac was majorly spammed yesterday, so I think he may have switched off guest access > > S > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On > | Behalf Of Robin Green > | Sent: 03 April 2007 12:43 > | To: glasgow-haskell-users@haskell.org > | Subject: Login problems with trac > | > | I am having difficulty logging in to GHC's trac. The situation is this: > | > | 1. I'm pretty sure I used to log in with username "greenrd" to file bugs > | (at least, that's what Firefox's password manager tells me!). That no > | longer works. I get the message below. > | > | ------------------------------------------------------------------ > | Permission Denied > | > | To create tickets or edit the wiki, please login with username guest, > | password guest. > | > | TICKET_CREATE privileges are required to perform this operation > | > | TracGuide ? The Trac User and Administration Guide > | ------------------------------------------------------------------ > | > | 2. I cannot log in with username "guest" using Firefox 1.5 on my > | office machine. I just get the same message, when I click "login". This > | occurs even after I have cleared my web browser's cache. Maybe I need > | to do something else other than clear the cache? > | > | 3. I have been able to log in once as a guest *and* create a ticket - > | but only on Firefox 2, on my office machine, which is not behind a > | proxy. > | > | 4. Strangest of all, I have not been able to log in as a guest using > | Firefox 2 on my dorm machine which is behind a proxy - even though > | Firefox is *not* automatically supplying a username and password! When I > | attempt to login as guest, I get redirected to > | http://hackage.haskell.org/trac/ghc and I don't seem to be logged in > | - a "login" link is still there, instead of a "logout" one. > | > | This is all rather confusing. I have not figured out what is going on > | here. > | > | -- > | Robin > | _______________________________________________ > | 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 From red5_2 at hotmail.com Tue Apr 3 11:13:50 2007 From: red5_2 at hotmail.com (C Rodrigues) Date: Tue Apr 3 11:12:44 2007 Subject: Login problems with trac In-Reply-To: <20070329102425.3E8A23243CA@www.haskell.org> Message-ID: The wiki has "edit" links if I login as guest, but not if I login as heatsink. Is that also because of the spam issue? _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ From igloo at earth.li Tue Apr 3 13:29:27 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Apr 3 13:28:20 2007 Subject: Login problems with trac In-Reply-To: References: <20070329102425.3E8A23243CA@www.haskell.org> Message-ID: <20070403172927.GA9426@matrix.chaos.earth.li> On Tue, Apr 03, 2007 at 03:13:50PM +0000, C Rodrigues wrote: > The wiki has "edit" links if I login as guest, but not if I login as > heatsink. Should be fixed now. > Is that also because of the spam issue? Yup; you weren't in the developer group, but you are now. Thanks Ian From bulat.ziganshin at gmail.com Thu Apr 5 05:01:19 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 5 05:02:42 2007 Subject: distributed compilation by GHC Message-ID: <71469119.20070405130119@gmail.com> Hello GHC, i'm interested to know how much people are interested in having support for distributed compilation by GHC? it's true that production GHC version doesn't support multi-threaded compilation, so such system will be of benefit even for local usage for users with multi-core chips? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Thu Apr 5 05:23:58 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 5 05:22:47 2007 Subject: ghci doesn't run FFi'd code which works under ghc on WinXP In-Reply-To: <000901c774e9$a02575c0$6601a8c0@box> References: <000901c774e9$a02575c0$6601a8c0@box> Message-ID: <4614C02E.8080208@gmail.com> Vivian McPhail wrote: > Hi All, > > I wrote a binding to matlab matrix.h and mat.h. My test program works > when I compile a binary, but when I try to use the code in ghci nothing > happens. There are no error messages, but all computations return a > blank line. > > Does this fall into a known class of error? > > I can provide my source code, but because of licensing requirements I > can't provide the .dll's against which the code is linked. I can't think of a reason off-hand why this would happen. Could you investigate deeper by adding traces into your code? If you can boil down a small example that doesn't have licensing restrictions, please submit it as a bug report. Cheers, Simon From joelr1 at gmail.com Thu Apr 5 05:33:27 2007 From: joelr1 at gmail.com (Joel Reymont) Date: Thu Apr 5 05:32:09 2007 Subject: distributed compilation by GHC In-Reply-To: <71469119.20070405130119@gmail.com> References: <71469119.20070405130119@gmail.com> Message-ID: Anyone with a multi-core processor would be. Most of the people, I assume. How would you implement this, though? On Apr 5, 2007, at 10:01 AM, Bulat Ziganshin wrote: > it's true that production GHC version doesn't support multi-threaded > compilation, so such system will be of benefit even for local usage > for users with multi-core chips? -- http://wagerlabs.com/ From bulat.ziganshin at gmail.com Thu Apr 5 07:00:13 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 5 07:01:25 2007 Subject: distributed compilation by GHC In-Reply-To: References: <71469119.20070405130119@gmail.com> Message-ID: <651531289.20070405150013@gmail.com> Hello Joel, Thursday, April 5, 2007, 1:33:27 PM, you wrote: my sentence should be read as "is it true...?" - i had lost a track whether it was incorporated in GHC or not. the idea is that GHC should be extended to be able to write out dependencies list built in the --make mode. Then rather simple scripts may be used to distribute the work among many cores/boxes who can enlighten me about presence/absence of multi-core GHC support? > Anyone with a multi-core processor would be. > Most of the people, I assume. > How would you implement this, though? > On Apr 5, 2007, at 10:01 AM, Bulat Ziganshin wrote: >> it's true that production GHC version doesn't support multi-threaded >> compilation, so such system will be of benefit even for local usage >> for users with multi-core chips? > -- > http://wagerlabs.com/ -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Thu Apr 5 08:12:15 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 5 08:11:01 2007 Subject: distributed compilation by GHC In-Reply-To: <651531289.20070405150013@gmail.com> References: <71469119.20070405130119@gmail.com> <651531289.20070405150013@gmail.com> Message-ID: <4614E79F.4020805@gmail.com> Bulat Ziganshin wrote: > Hello Joel, > > Thursday, April 5, 2007, 1:33:27 PM, you wrote: > > my sentence should be read as "is it true...?" - i had lost a track > whether it was incorporated in GHC or not. the idea is that GHC should be > extended to be able to write out dependencies list built in the --make > mode. Then rather simple scripts may be used to distribute the work > among many cores/boxes > > who can enlighten me about presence/absence of multi-core GHC support? GHC itself doesn't support multithreaded --make compilation. I have some old patches to do this, which I used for the measurements in the Haskell Workshop 2005 paper, but it was never completely robust. This is one reason I wrote the 'setup makefile' patch for Cabal[1] recently. With that patch you can get parallel compilation on a multiprocessor using 'make -j' when using Cabal. (I know that not everyone has make, it isn't intended to be a portable solution - the ultimate goal is to use Cabal in GHC's build system, where you need make anyway). Cheers, Simon [1] http://www.haskell.org/pipermail/cabal-devel/2007-March/000448.html From bulat.ziganshin at gmail.com Thu Apr 5 08:20:53 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 5 08:21:59 2007 Subject: distributed compilation by GHC In-Reply-To: <4614E79F.4020805@gmail.com> References: <71469119.20070405130119@gmail.com> <651531289.20070405150013@gmail.com> <4614E79F.4020805@gmail.com> Message-ID: <1136529974.20070405162053@gmail.com> Hello Simon, Thursday, April 5, 2007, 4:12:15 PM, you wrote: >> whether it was incorporated in GHC or not. the idea is that GHC should be >> extended to be able to write out dependencies list built in the --make >> mode. Then rather simple scripts may be used to distribute the work >> among many cores/boxes >> > This is one reason I wrote the 'setup makefile' patch for Cabal[1] recently. > With that patch you can get parallel compilation on a multiprocessor using 'make > -j' when using Cabal. (I know that not everyone has make, it isn't intended to > be a portable solution - the ultimate goal is to use Cabal in GHC's build > system, where you need make anyway). thanks! afaiu, this system don't needs that GHC can print dependency list it's built - dependencies are found by make itself? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Thu Apr 5 08:41:15 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 5 08:40:04 2007 Subject: distributed compilation by GHC In-Reply-To: <1136529974.20070405162053@gmail.com> References: <71469119.20070405130119@gmail.com> <651531289.20070405150013@gmail.com> <4614E79F.4020805@gmail.com> <1136529974.20070405162053@gmail.com> Message-ID: <4614EE6B.4050602@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Thursday, April 5, 2007, 4:12:15 PM, you wrote: > >>> whether it was incorporated in GHC or not. the idea is that GHC should be >>> extended to be able to write out dependencies list built in the --make >>> mode. Then rather simple scripts may be used to distribute the work >>> among many cores/boxes >>> >> This is one reason I wrote the 'setup makefile' patch for Cabal[1] recently. >> With that patch you can get parallel compilation on a multiprocessor using 'make >> -j' when using Cabal. (I know that not everyone has make, it isn't intended to >> be a portable solution - the ultimate goal is to use Cabal in GHC's build >> system, where you need make anyway). > > thanks! afaiu, this system don't needs that GHC can print dependency > list it's built - dependencies are found by make itself? dependencies are generated by 'ghc -M'. Cheers, Simon From joelr1 at gmail.com Thu Apr 5 09:26:08 2007 From: joelr1 at gmail.com (Joel Reymont) Date: Thu Apr 5 09:24:50 2007 Subject: Failed to load interface for `Prelude' Message-ID: Pepe already told me that I need SplitObj=NO on Mac OSX. Can someone tell me why? Is the error below due to split objs? Thanks, Joel -- ../compiler/stage1/ghc-inplace -H32m -O2 -istage2/utils -istage2/ basicTypes -istage2/types -istage2/hsSyn -istage2/prelude - istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal - istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main - istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen - istage2/ghci -Istage2 -DGHCI -package template-haskell -DDEBUGGER - DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE - cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -package regex-compat -ignore-package lang - recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name ghc-6.7.20070404 -fgenerics -c basicTypes/OccName.lhs-boot -o stage2/basicTypes/OccName.o-boot -ohi stage2/basicTypes/OccName.hi-boot ../compiler/stage1/ghc-inplace -H32m -O2 -istage2/utils -istage2/ basicTypes -istage2/types -istage2/hsSyn -istage2/prelude - istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal - istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main - istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen - istage2/ghci -Istage2 -DGHCI -package template-haskell -DDEBUGGER - DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE - cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -package regex-compat -ignore-package lang - recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name ghc-6.7.20070404 -fgenerics -O -c utils/Encoding.hs -o stage2/ utils/Encoding.o -ohi stage2/utils/Encoding.hi basicTypes/OccName.lhs-boot:1:0: Failed to load interface for `Prelude': Use -v to see a list of the files searched for. <> make[2]: *** [stage2/basicTypes/OccName.o-boot] Error 1 make[2]: *** Waiting for unfinished jobs.... utils/Encoding.hs:1:0: Failed to load interface for `Prelude': Use -v to see a list of the files searched for. <> make[2]: *** [stage2/utils/Encoding.o] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 -- http://wagerlabs.com/ From joelr1 at gmail.com Thu Apr 5 10:42:20 2007 From: joelr1 at gmail.com (Joel Reymont) Date: Thu Apr 5 10:41:05 2007 Subject: Failed to load interface for `Prelude' In-Reply-To: <143BF97A-BDB6-4019-A7DE-CBB17B409195@gmail.com> References: <143BF97A-BDB6-4019-A7DE-CBB17B409195@gmail.com> Message-ID: It's driving me nuts but I keep getting the same error with our without split objects! I did manage to build the quickest configuration, it's the performance one I cannot build. On Apr 5, 2007, at 3:02 PM, Pepe Iborra wrote: > The problem is not in the logs you attached, those are from stage2. > The real error shows up when compiling base, if I recall correctly, > but I never had the courage to find out why. -- http://wagerlabs.com/ From naur at post11.tele.dk Thu Apr 5 12:21:02 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Thu Apr 5 12:21:26 2007 Subject: Failed to load interface for `Prelude' In-Reply-To: References: Message-ID: <200704051821.09550.naur@post11.tele.dk> Hello, A long shot, but perhaps worth looking into: The reaction that you report here seems similar to the one reported in trac #1195 Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6: http://hackage.haskell.org/trac/ghc/ticket/1195 That ticket reports two cases where some error was apparently ignored, leading to a sequence of error reports like the one you quote. But the first error, which is probably the interesting one, is buried somewhere earlier in the output and needs to be found "manually", somehow. If you find your problem related to #1195, please attach any additional details that may be relevant to that ticket. Best regards Thorkil On Thursday 05 April 2007 15:26, Joel Reymont wrote: > Pepe already told me that I need SplitObj=NO on Mac OSX. > > Can someone tell me why? > > Is the error below due to split objs? > > Thanks, Joel > > -- > ../compiler/stage1/ghc-inplace -H32m -O2 -istage2/utils -istage2/ > basicTypes -istage2/types -istage2/hsSyn -istage2/prelude - > istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ > coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal - > istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main - > istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ > ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen - > istage2/ghci -Istage2 -DGHCI -package template-haskell -DDEBUGGER - > DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE - > cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package > unix -package Cabal -package regex-compat -ignore-package lang - > recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name > ghc-6.7.20070404 -fgenerics -c basicTypes/OccName.lhs-boot -o > stage2/basicTypes/OccName.o-boot -ohi stage2/basicTypes/OccName.hi-boot > ../compiler/stage1/ghc-inplace -H32m -O2 -istage2/utils -istage2/ > basicTypes -istage2/types -istage2/hsSyn -istage2/prelude - > istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ > coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal - > istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main - > istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ > ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen - > istage2/ghci -Istage2 -DGHCI -package template-haskell -DDEBUGGER - > DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE - > cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package > unix -package Cabal -package regex-compat -ignore-package lang - > recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name > ghc-6.7.20070404 -fgenerics -O -c utils/Encoding.hs -o stage2/ > utils/Encoding.o -ohi stage2/utils/Encoding.hi > > basicTypes/OccName.lhs-boot:1:0: > Failed to load interface for `Prelude': > Use -v to see a list of the files searched for. > < (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.03 MUT (0.10 > elapsed), 0.02 GC (0.02 elapsed) :ghc>> > make[2]: *** [stage2/basicTypes/OccName.o-boot] Error 1 > make[2]: *** Waiting for unfinished jobs.... > > utils/Encoding.hs:1:0: > Failed to load interface for `Prelude': > Use -v to see a list of the files searched for. > < (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.03 MUT (0.12 > elapsed), 0.02 GC (0.02 elapsed) :ghc>> > make[2]: *** [stage2/utils/Encoding.o] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 > > -- > http://wagerlabs.com/ > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From bos at serpentine.com Thu Apr 5 13:47:39 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Apr 5 13:46:24 2007 Subject: distributed compilation by GHC In-Reply-To: <4614E79F.4020805@gmail.com> References: <71469119.20070405130119@gmail.com> <651531289.20070405150013@gmail.com> <4614E79F.4020805@gmail.com> Message-ID: <4615363B.9050000@serpentine.com> Simon Marlow wrote: > This is one reason I wrote the 'setup makefile' patch for Cabal[1] > recently. I haven't seen that patch show up in the cabal tree yet. Do you plan to commit it? I'd love to see it in. References: <71469119.20070405130119@gmail.com> <651531289.20070405150013@gmail.com> <4614E79F.4020805@gmail.com> <4615363B.9050000@serpentine.com> Message-ID: <20070405183902.GA10314@matrix.chaos.earth.li> On Thu, Apr 05, 2007 at 10:47:39AM -0700, Bryan O'Sullivan wrote: > Simon Marlow wrote: > > >This is one reason I wrote the 'setup makefile' patch for Cabal[1] > >recently. > > I haven't seen that patch show up in the cabal tree yet. Do you plan to > commit it? I'd love to see it in. Coincidentally, I just pushed it. Thanks Ian From joelr1 at gmail.com Thu Apr 5 15:46:00 2007 From: joelr1 at gmail.com (Joel Reymont) Date: Thu Apr 5 15:44:43 2007 Subject: Failed to load interface for `Prelude' In-Reply-To: <200704051821.09550.naur@post11.tele.dk> References: <200704051821.09550.naur@post11.tele.dk> Message-ID: <054BABEE-2F14-4B4F-A67C-6BAEF7620504@gmail.com> I think this is the reason. What's my next step? This is Mac OSX 10.4.9 Intel. == make all -r -f Makefile; in /Users/joelr/work/haskell/ghc/ libraries/ base-------------------------------------------------------------------- ----../../compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp - Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name base-2.0 -fgenerics -split-objs -c GHC/Err.lhs-boot -o GHC/Err.o- boot -ohi GHC/Err.hi-boot../../compiler/ghc-inplace -H32m -O2 - fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict- fields -package-name base-2.0 -fgenerics -split-objs -c GHC/ PrimopWrappers.hs -o GHC/PrimopWrappers.o -ohi GHC/ PrimopWrappers.higcc -O -c System/CPUTime_hsc.c -o System/ CPUTime_hsc.ogcc -O -c System/Time_hsc.c -o System/Time_hsc.o../../ compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name base-2.0 - fgenerics -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/ Base.hi/tmp/ghc4826_0/ghc4826_0.split__178.s:unknown:missing indirect symbols for section (__TEXT,__symbol_stub)make[2]: *** [GHC/ PrimopWrappers.o] Error 1make[2]: *** -- http://wagerlabs.com/ From joelr1 at gmail.com Thu Apr 5 15:52:40 2007 From: joelr1 at gmail.com (Joel Reymont) Date: Thu Apr 5 15:51:21 2007 Subject: Failed to load interface for `Prelude' In-Reply-To: <200704051821.09550.naur@post11.tele.dk> References: <200704051821.09550.naur@post11.tele.dk> Message-ID: On Apr 5, 2007, at 5:21 PM, Thorkil Naur wrote: > http://hackage.haskell.org/trac/ghc/ticket/1195 So I found this bug. How do I deal with it? Thanks, Joel -- http://wagerlabs.com/ From fool at cs.utexas.edu Thu Apr 5 18:20:34 2007 From: fool at cs.utexas.edu (Chris McCraw) Date: Thu Apr 5 18:19:18 2007 Subject: Linking and Including nonstandard paths Message-ID: <20070405222034.GC29953@nice.cs.utexas.edu> Hi! We're fairly happy users of ghc in my department. We use it widely for instruction and to some degree for research. I'm the fellow tasked with maintaining the local installation, and I have a couple of simple and seemingly related problems that I'm sure have easy solutions, though I haven't been able to find them. 1) I'd like to embed an additional library search directory in ghc so that it does the equivalent of -L/path/to/extra/dir every time it's used to link something. Unfortunately, our libgmp resides in a nonstandard directory and so *every time* someone wants to compile they must ghc -L/lusr/gnu/lib ... to find -lgmp. I promise, we have thought about moving libgmp into the default search path, and setting $LD_LIBRARY_PATH, but those break a lot of other stuff in our setup, and are really not practical in our environment. We build all of our utilities from source (including ghc) so I would be happy & able to tweak some setting during configure or make or even hack the source--but I can't figure out where to change it. I figured it'd be in configure.mk(.in) but adding "-R /lusr/gnu/lib" to the LD command line did not do the trick in generating a ghc binary that calls ld/collect2 in the same way. 2) When building something, I often need to add an include directory. As an example, GSLHaskell: % runhaskell -I/lusr/gnu/include Setup.hs build [...] [16 of 17] Compiling GSL.Plot ( GSL/Plot.hs, dist/build/GSL/Plot.p_o ) [17 of 17] Compiling GSL ( GSL.hs, dist/build/GSL.p_o ) GSL/gslaux.c:2:26: gsl/gsl_blas.h: No such file or directory GSL/gslaux.c:3:28: gsl/gsl_linalg.h: No such file or directory gsl/gsl_blas.h and friends are indeed in /lusr/gnu/include and I'd like to do the equivalent of adding a $CFLAGS of -I/lusr/gnu/include to the build (or to every build--it'd be grand if that was included by default, though not as necessary as item #1 above) but can't figure out how. I'm working with ghc-6.6 on ubuntu linux, in case that matters. I'm not sure what else is relevant, but am happy to provide details as needed. Help? Thanks in advance! From duncan.coutts at worc.ox.ac.uk Thu Apr 5 18:44:06 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Apr 5 18:43:08 2007 Subject: Linking and Including nonstandard paths In-Reply-To: <20070405222034.GC29953@nice.cs.utexas.edu> References: <20070405222034.GC29953@nice.cs.utexas.edu> Message-ID: <1175813046.22607.42.camel@localhost> On Thu, 2007-04-05 at 17:20 -0500, Chris McCraw wrote: > 1) I'd like to embed an additional library search directory in ghc so > that it does the equivalent of -L/path/to/extra/dir every time it's > used to link something. Unfortunately, our libgmp resides in a nonstandard > directory and so *every time* someone wants to compile they must > ghc -L/lusr/gnu/lib ... > to find -lgmp. Modify the library-dirs used by the rts packages to include your extra linker search path. eg: - library-dirs: /usr/local/lib/ghc-6.6 + library-dirs: /usr/local/lib/ghc-6.6, /lusr/gnu/lib First, backup ghc's package.conf file just in case... Then: $ ghc-pkg describe rts > rts.package.conf $ $EDITOR rts.package.conf $ ghc-pkg update rts.package.conf Duncan From simonpj at microsoft.com Fri Apr 6 03:18:27 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Apr 6 03:17:12 2007 Subject: Linking and Including nonstandard paths In-Reply-To: <1175813046.22607.42.camel@localhost> References: <20070405222034.GC29953@nice.cs.utexas.edu> <1175813046.22607.42.camel@localhost> Message-ID: I wonder if this package.conf hacking would be a good topic for a GHC wiki page? Somewhere here: http://haskell.org/haskellwiki/GHC Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Duncan Coutts | Sent: 05 April 2007 23:44 | To: Chris McCraw | Cc: Glasgow-haskell-users@haskell.org | Subject: Re: Linking and Including nonstandard paths | | On Thu, 2007-04-05 at 17:20 -0500, Chris McCraw wrote: | | > 1) I'd like to embed an additional library search directory in ghc so | > that it does the equivalent of -L/path/to/extra/dir every time it's | > used to link something. Unfortunately, our libgmp resides in a nonstandard | > directory and so *every time* someone wants to compile they must | > ghc -L/lusr/gnu/lib ... | > to find -lgmp. | | Modify the library-dirs used by the rts packages to include your extra | linker search path. eg: | | - library-dirs: /usr/local/lib/ghc-6.6 | + library-dirs: /usr/local/lib/ghc-6.6, /lusr/gnu/lib | | First, backup ghc's package.conf file just in case... | | Then: | $ ghc-pkg describe rts > rts.package.conf | $ $EDITOR rts.package.conf | $ ghc-pkg update rts.package.conf | | Duncan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From naur at post11.tele.dk Sat Apr 7 06:27:47 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Sat Apr 7 06:28:05 2007 Subject: Failed to load interface for `Prelude' In-Reply-To: <054BABEE-2F14-4B4F-A67C-6BAEF7620504@gmail.com> References: <200704051821.09550.naur@post11.tele.dk> <054BABEE-2F14-4B4F-A67C-6BAEF7620504@gmail.com> Message-ID: <200704071227.53482.naur@post11.tele.dk> Hello, I'm afraid that this is outside my direct experience. However, looking at http://lists.apple.com/archives/xcode-users/2006/Oct/msg00578.html that google was kind enough to find for me, some assembler code generation error seems indicated. I can see that you use -O2, but not whether -fasm or -fvia-C (if any) is used. As I recall, the default selection between -fasm and -fvia-C at some point depended on the -O level, but also has changed recently. I would therefore suggest that you experiment with -O2 versus -O0 and -fasm versus -fvia-C to see if some combination will not carry you through. Also: 1. It would probably be useful to give us the exact version of ghc that you are using and also the version you are building. (Sorry if you reported it and I missed it, but I cannot find it right now.) 2. The report that you give contains what seems to be fragments of command lines. It would be useful to have the complete command lines. 3. In #1195, igloo reports that he has included some code to provide additional information in case of ignored errors (which seems involved here). Some additional context that surrounds the first error report would therefore also be useful, I guess. Best regards Thorkil On Thursday 05 April 2007 21:46, Joel Reymont wrote: > I think this is the reason. What's my next step? > > This is Mac OSX 10.4.9 Intel. > > == make all -r -f Makefile; in /Users/joelr/work/haskell/ghc/ > libraries/ > base-------------------------------------------------------------------- > ----../../compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp - > Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name > base-2.0 -fgenerics -split-objs -c GHC/Err.lhs-boot -o GHC/Err.o- > boot -ohi GHC/Err.hi-boot../../compiler/ghc-inplace -H32m -O2 - > fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict- > fields -package-name base-2.0 -fgenerics -split-objs -c GHC/ > PrimopWrappers.hs -o GHC/PrimopWrappers.o -ohi GHC/ > PrimopWrappers.higcc -O -c System/CPUTime_hsc.c -o System/ > CPUTime_hsc.ogcc -O -c System/Time_hsc.c -o System/Time_hsc.o../../ > compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp -Iinclude > -"#include" HsBase.h -funbox-strict-fields -package-name base-2.0 - > fgenerics -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/ > Base.hi/tmp/ghc4826_0/ghc4826_0.split__178.s:unknown:missing indirect > symbols for section (__TEXT,__symbol_stub)make[2]: *** [GHC/ > PrimopWrappers.o] Error 1make[2]: *** > > > -- > http://wagerlabs.com/ > > > > > > From isaacdupree at charter.net Sat Apr 7 18:25:22 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Apr 7 18:22:59 2007 Subject: Wanted: warning option for usages of unary minus Message-ID: <46181A52.8070108@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since the unary negation operator `-' is often considered a wart in Haskell's syntax and in many cases saying "negate" is arguably clearer anyway, I propose adding options to GHC to warn about its use. The only case I don't normally want to be warned about is "negative numeric literals", e.g. (-1), even if in current Haskell they do mean (negate (fromInteger 1)) not (fromInteger (negate 1)) (or equivalently, (fromInteger (negate (fromInteger 1))) as the inner fromInteger === id). I know this would be useful to someone since I caught myself manually cleaning some of my code in this way without the help of warning messages :) Proposed flag names and descriptions (could use a little tidying up) : - -fwarn-unary-minus Causes a warning to be emitted for all usages of the unary operator `-', except those in which its argument is a numeric literal that is not separated from the minus sign by any space (space includes comments). - -fwarn-all-unary-minus For those who hate it with a passion, this option warns about ALL uses of the unary `-' operator, even code like `(-1)'. Opinions? (Should I put a feature request in Trac? Is that what I perhaps should have done in the first place?) Is this simple enough to try to implement myself so I can start getting to know GHC's internals? (I suspect that detecting the adjacency of the "-" to a numeric literal without changing the actual precedence may be a little tricky... -2^6 parses as negate(2^6) and should get a warning, as should (- 2), IMO) Oh, the actual warning message... file:line:column: Warning: Unary minus in expression foo (or, on the next line, In the expression: foo ?) for an appropriate "foo", which has parentheses added to describe the effects of operator precedence, as usual for GHC diagnostic messages (it's just particularly important for making this one easy to understand in some cases) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGBpSHgcxvIWYTTURAt5sAKCEIohHMiuUy9AofhWKzvDOf4rwmgCeJcbj e2RmW+UX2E6omuLpFfIH9fs= =1SnR -----END PGP SIGNATURE----- From duncan.coutts at worc.ox.ac.uk Sun Apr 8 03:39:17 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 8 03:54:59 2007 Subject: Linking and Including nonstandard paths In-Reply-To: References: <20070405222034.GC29953@nice.cs.utexas.edu> <1175813046.22607.42.camel@localhost> Message-ID: <1176017957.5005.0.camel@localhost> On Fri, 2007-04-06 at 08:18 +0100, Simon Peyton-Jones wrote: > I wonder if this package.conf hacking would be a good topic for a GHC wiki page? Somewhere here: > http://haskell.org/haskellwiki/GHC Done. From isaacdupree at charter.net Sun Apr 8 08:35:09 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Apr 8 08:32:40 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <46181A52.8070108@charter.net> References: <46181A52.8070108@charter.net> Message-ID: <4618E17D.4060706@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now I understand why negative unboxed numeric literals are parsed weirdly, after poking around a little! "The parser parses all infix applications as right-associative, regardless of fixity." A negative sign on the left of an expression is parsed as a special case, binding tighter than all infix ops (until the renamer reassociates it) (but '-' is not parsed that way when it _follows_ an expression: ( process -1# ) is treated as _infix_ minus, i.e. subtraction, i.e. likely compile error). Then, before reassociating based on fixity, negation of an unboxed number is performed (in order to allow a sort of numeric literals that are negative and unboxed). Here is a result of this funny treatment: \begin{code} {-# OPTIONS_GHC -fglasgow-exts #-} import GHC.Base main = do putStrLn $ "boxed: " ++ show ( ( - 2 ^ 6 ) :: Int ) -- output: boxed: -64 -- === ( -(2 ^ 6 )) putStrLn $ "unboxed: " ++ show ( I# ( - 2# ^# 6# ) ) -- output: unboxed: 64 -- === ((- 2#)^# 6# ) infixr 8 ^# --just like ^, binds tighter than - (which is infixl 6) ( ^# ) :: Int# -> Int# -> Int# base ^# 0# = 1# base ^# exponent = base *# (base ^# ( exponent -# 1# )) \end{code} This particular combination of behavior, unfortunately, doesn't seem useful for implementing sensible numeric literals, IMHO. My desired warning scheme would have to wait for the renamer to sort out fixities... unless I want to warn about (-1==1) which is ((-1)==1), as well (do I want that warning? how about (1 == -1), or (1 ^^ -1), which both must parse with negation being tightly binding? I hadn't considered those very well yet...). Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGOF8HgcxvIWYTTURAiT5AKC1Zl9JYuSLBPdey/YdmCriY7FaUQCgqzNQ clHWTS162IZWHhlXKJR8NhQ= =zqzy -----END PGP SIGNATURE----- From igloo at earth.li Sun Apr 8 13:02:48 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Apr 8 13:01:24 2007 Subject: Failed to load interface for `Prelude' In-Reply-To: <200704071227.53482.naur@post11.tele.dk> References: <200704051821.09550.naur@post11.tele.dk> <054BABEE-2F14-4B4F-A67C-6BAEF7620504@gmail.com> <200704071227.53482.naur@post11.tele.dk> Message-ID: <20070408170248.GA4904@matrix.chaos.earth.li> On Sat, Apr 07, 2007 at 12:27:47PM +0200, Thorkil Naur wrote: > > 1. It would probably be useful to give us the exact version of ghc that you > are using and also the version you are building. (Sorry if you reported it > and I missed it, but I cannot find it right now.) Ditto. > 3. In #1195, igloo reports that he has included some code to provide > additional information in case of ignored errors (which seems involved here). > Some additional context that surrounds the first error report would therefore > also be useful, I guess. Yes, if you are building a GHC which includes this patch then a full build log would be useful. > > == make all -r -f Makefile; in /Users/joelr/work/haskell/ghc/ > > libraries/ > > base-------------------------------------------------------------------- > > ----../../compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp - > > Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name > > base-2.0 -fgenerics -split-objs -c GHC/Err.lhs-boot -o GHC/Err.o- > > boot -ohi GHC/Err.hi-boot../../compiler/ghc-inplace -H32m -O2 - > > fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict- > > fields -package-name base-2.0 -fgenerics -split-objs -c GHC/ > > PrimopWrappers.hs -o GHC/PrimopWrappers.o -ohi GHC/ > > PrimopWrappers.higcc -O -c System/CPUTime_hsc.c -o System/ > > CPUTime_hsc.ogcc -O -c System/Time_hsc.c -o System/Time_hsc.o../../ > > compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp -Iinclude > > -"#include" HsBase.h -funbox-strict-fields -package-name base-2.0 - > > fgenerics -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/ > > Base.hi/tmp/ghc4826_0/ghc4826_0.split__178.s:unknown:missing indirect > > symbols for section (__TEXT,__symbol_stub)make[2]: *** [GHC/ > > PrimopWrappers.o] Error 1make[2]: *** It's possible that this could be caused by a broken splitter, yes. Adding -v -keep-tmp-files to the above commandline should help clarify things, with the help of the command ouput and the intermediate file contents. Thanks Ian From gwright at comcast.net Sun Apr 8 19:49:24 2007 From: gwright at comcast.net (Gregory Wright) Date: Sun Apr 8 19:48:02 2007 Subject: FreeBSD/amd64 registerised running Message-ID: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> Hi Ian, Simon, I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64. The FreeBSD version is 6.2. The problem with the compiler crash turned out to be simple. In the FreeBSD header file regex.h, regex_t is defined as typedef struct { int re_magic; size_t re_nsub; /* number of parenthesized subexpressions */ __const char *re_endp; /* end pointer for REG_PEND */ struct re_guts *re_g; /* none of your business :-) */ } regex_t; The problem is that the "re_magic" field is defined as an int. When building the .hc files on the i386 host, the re_nsub field is at an offset of 4. On the amd64 target, it is at an offset of 8. In the ghc binding to the regex functions, re_nsub is used to compute how much memory to allocate in a call to allocaBytes. This leads to garbage being passed to newPinnedByteArray#. The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64 target: --- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007 +++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007 @@ -106,7 +106,7 @@ regexec (Regex regex_fptr) str = do withCString str $ \cstr -> do withForeignPtr regex_fptr $ \regex_ptr -> do - nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr + nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr {-# LINE 109 "Posix.hsc" #-} let nsub_int = fromIntegral (nsub :: CSize) allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do With this patch, we are pretty close. However, there still seems to be something wrong with the splitter. I can make a working registerized compiler if I set splitObjs=NO in build.mk, but it seems as if whatever is wrong with ghc-split shouldn't be too hard to fix. The splitting problem shows up as a linking failure. Some variables defined in the text section are changed from global symbols to local symbols by the splitter. An example (just one of several hundred symbols that are changed from global to local): From building ghc-6.6-20070405 on i386: > nm --defined-only libHSbase.a | grep "D " 00000000 D base_TextziReadziLex_zdLr3bklvl122_closure and from building ghc-6.6-20070405 on amd64: > nm --defined-only libHSbase.a | grep "d " 0000000000000000 d base_TextziReadziLex_zdLr3bklvl122_closure The "D" on i386 indicates a global symbol, the "d" on amd64 a local symbol. I've glanced at ghc-split.lprl, but on what files is it invoked? Can I run it from the command line on a file and see check what comes out? The file itself doesn't say what it expects as input, and the section of the Commentary on the splitter is more than terse. The linker is still broken (so no ghci): greenhouse-george> ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.20770405, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. ghc-6.6.20770405: internal error: R_X86_64_PC32 relocation out of range: __isthreaded = 0xfffffff800122aad (GHC version 6.6.20070405 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/ reportabug Abort trap: 6 (core dumped) but I think I understand this. On FreeBSD mmap does not have the MAP_32BIT option that linux does to guarantee a mapping in first 2 GB of address space. But by supplying a hint address in the lower address space we can get the effect the MAP_32BIT option. I thought I had this fixed in the patch I applied to Linker.c, but I have obviously overlooked something. I'm continuing to work on the linker, and expect that it will be working soon. I'd appreciate a some guidance on the splitter question as I am entirely unfamiliar with it. Best Wishes, Greg From igloo at earth.li Mon Apr 9 12:21:32 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Apr 9 12:20:06 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> Message-ID: <20070409162132.GA24512@matrix.chaos.earth.li> On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote: > > I have ghc-6.6 (darcs version from 20070405) running registerized on > FreeBSD/amd64. Excellent! Well done, and thanks for persevering! It would be great if you could let us have a bindist and any necessary patches. > The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64 > target: > > --- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007 > +++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007 > @@ -106,7 +106,7 @@ > regexec (Regex regex_fptr) str = do > withCString str $ \cstr -> do > withForeignPtr regex_fptr $ \regex_ptr -> do > - nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr > + nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr > {-# LINE 109 "Posix.hsc" #-} > let nsub_int = fromIntegral (nsub :: CSize) > allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do Aha! That makes sense: When generating .hc files on the host machine, hsc2hs makes a C program which generates a .hs module (with the host's sizes embedded in it) which is finally compiled down to .hc as normal. So I think to do this in a way that is porting-friendly, hsc2hs would have to convert f = ... #peek regex_t, re_nsub ... into something like -- Haskell: foreign import re_nsub_off :: Int f = ... (\hsc_ptr -> peekByteOff hsc_ptr re_nsub_off) ... /* C */ #import "HsFFI.h" HsInt re_nsub_off(void) { return ... } Unfortunately I don't think we can do anything as nice with #type. > With this patch, we are pretty close. However, there still seems to be > something wrong with the splitter. I can make a working registerized > compiler if I set splitObjs=NO in build.mk, but it seems as if > whatever is > wrong with ghc-split shouldn't be too hard to fix. > > I've glanced at ghc-split.lprl, but on what files is it invoked? Can > I run it from the command line on a file and see check what comes out? If you compile a module with ghc -v -keep-tmp-files then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards. Thanks Ian From gwright at comcast.net Mon Apr 9 12:38:51 2007 From: gwright at comcast.net (Gregory Wright) Date: Mon Apr 9 12:37:24 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <20070409162132.GA24512@matrix.chaos.earth.li> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <20070409162132.GA24512@matrix.chaos.earth.li> Message-ID: Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote: > On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote: >> >> I have ghc-6.6 (darcs version from 20070405) running registerized on >> FreeBSD/amd64. > > Excellent! Well done, and thanks for persevering! > > It would be great if you could let us have a bindist and any necessary > patches. > I will certainly provide patches and a binary distribution that people can use to bootstrap their own compilers. I will try to get ghci running before I put out a release. > If you compile a module with > > ghc -v -keep-tmp-files > > then you should see the commandline it is using, and it should > leave the > files for you to examine, and rerun the commands on, afterwards. I'm giving this a try right now. Best Wishes, Greg From gwright at comcast.net Mon Apr 9 18:49:39 2007 From: gwright at comcast.net (Gregory Wright) Date: Mon Apr 9 18:48:03 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <20070409162132.GA24512@matrix.chaos.earth.li> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <20070409162132.GA24512@matrix.chaos.earth.li> Message-ID: Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote: >> >> With this patch, we are pretty close. However, there still seems >> to be >> something wrong with the splitter. I can make a working registerized >> compiler if I set splitObjs=NO in build.mk, but it seems as if >> whatever is >> wrong with ghc-split shouldn't be too hard to fix. >> >> I've glanced at ghc-split.lprl, but on what files is it invoked? Can >> I run it from the command line on a file and see check what comes >> out? > > If you compile a module with > > ghc -v -keep-tmp-files > > then you should see the commandline it is using, and it should > leave the > files for you to examine, and rerun the commands on, afterwards. > I did this and immediately discovered that the problem is not with ghc-split but with ghc-asm. ".globl" directives are being deleted when they shouldn't be. This is somewhat reminiscent of bug #1167, except that it seems to happen far more frequently on amd64. Perhaps someone has an idea of the top of their head for this one. I wouldn't be surprised if the fix for this also took care of the bug on the less loved linux-ppc platform. Best Wishes. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070409/33a6f948/attachment.htm From simonmarhaskell at gmail.com Tue Apr 10 06:53:39 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 10 06:52:11 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> Message-ID: <461B6CB3.30008@gmail.com> Gregory Wright wrote: > I have ghc-6.6 (darcs version from 20070405) running registerized on > FreeBSD/amd64. The FreeBSD version is 6.2. > > The problem with the compiler crash turned out to be simple. In the > FreeBSD header file regex.h, regex_t is defined as > > typedef struct { > int re_magic; > size_t re_nsub; /* number of parenthesized > subexpressions */ > __const char *re_endp; /* end pointer for REG_PEND */ > struct re_guts *re_g; /* none of your business :-) */ > } regex_t; > > The problem is that the "re_magic" field is defined as an int. When > building > the .hc files on the i386 host, the re_nsub field is at an offset of 4. > On the > amd64 target, it is at an offset of 8. In the ghc binding to the regex > functions, > re_nsub is used to compute how much memory to allocate in a call to > allocaBytes. This leads to garbage being passed to newPinnedByteArray#. > > The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64 target: > > --- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007 > +++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007 > @@ -106,7 +106,7 @@ > regexec (Regex regex_fptr) str = do > withCString str $ \cstr -> do > withForeignPtr regex_fptr $ \regex_ptr -> do > - nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr > + nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr > {-# LINE 109 "Posix.hsc" #-} > let nsub_int = fromIntegral (nsub :: CSize) > allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do > > With this patch, we are pretty close. Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by hsc2hs, but this is done on the *host* rather than the *target* when bootstrapping, and thus generates the wrong results. If you'd run hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, but you can't do this because hsc2hs is a Haskell program. You could take the .c file generated by hsc2hs on the host and compile/run it on the target, but that's a hassle, so instead our policy is that we don't rely on any hsc2hs-generated code for bootstrapping. Unfortunately I broke the rules by accident when I introduced the dependency on regex. I can't think of an easy way to enforce the rule, at least at the moment, since there are other hsc2hs-processed modules that we happen to not depend on in GHC (System.Time and System.CPUTime). This will be fixed as a side effect of http://hackage.haskell.org/trac/ghc/ticket/1160. Also after the base reorg we might find we have no hsc2hs-generated code left in base and we can disable hsc2hs to prevent this happening again. Cheers, Simon From haskell at list.mightyreason.com Tue Apr 10 07:12:00 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Apr 10 07:10:39 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461B6CB3.30008@gmail.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> Message-ID: <461B7100.30308@list.mightyreason.com> Simon Marlow wrote: > Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by > hsc2hs, but this is done on the *host* rather than the *target* when > bootstrapping, and thus generates the wrong results. If you'd run > hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, > but you can't do this because hsc2hs is a Haskell program. You could > take the .c file generated by hsc2hs on the host and compile/run it on > the target, but that's a hassle, so instead our policy is that we don't > rely on any hsc2hs-generated code for bootstrapping. > > Unfortunately I broke the rules by accident when I introduced the > dependency on regex. I can't think of an easy way to enforce the rule, > at least at the moment, since there are other hsc2hs-processed modules > that we happen to not depend on in GHC (System.Time and System.CPUTime). Could the solution be to depend on a pure Haskell regex implementation instead of on a regex-posix / Posix.hsc and the system regex library? The regex-tdfa backend could be modified to work with the regex-base in GHC 6.6 and then regex-compat could quickly be switched to use this instead of regex-posix. -- Chris Kuklewicz From igloo at earth.li Tue Apr 10 10:41:49 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Apr 10 10:40:20 2007 Subject: ANNOUNCE: GHC 6.6.1 Release Candidate Message-ID: <20070410144149.GA22598@matrix.chaos.earth.li> We are pleased to announce the Release Candidate phase for GHC 6.6.1. Snapshots beginning with 6.6.20070409 are release candidates for 6.6.1 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070409-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070409-src-extralibs.tar.bz2 Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux and i386/Linux. More may appear later. The Windows (mingw) binary distributions are currently broken, but we hope to have this resolved soon. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope to release in a couple of weeks, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team From gwright at comcast.net Tue Apr 10 13:40:09 2007 From: gwright at comcast.net (Gregory Wright) Date: Tue Apr 10 13:38:37 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <20070410172318.GA40231@unsane.de> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <20070409162132.GA24512@matrix.chaos.earth.li> <20070410172318.GA40231@unsane.de> Message-ID: Hi Olli, On Apr 10, 2007, at 1:23 PM, Oliver Braun wrote: > Hi Gregory, > > * Gregory Wright [2007-04-09 12:38 -0400]: >>>> I have ghc-6.6 (darcs version from 20070405) running >>>> registerized on >>>> FreeBSD/amd64. > >> I will certainly provide patches and a binary distribution that >> people can use to bootstrap their own compilers. > > It would be nice if you cann provide a bootstrap tarball for > integration > in the FreeBSD lang/ghc port. > I will do this as soon as I get the Linker bugs worked out so we can have ghci. Since this won't make it into 6.6.1 a few patches will have to be applied to the distribution. Best Wishes, Greg From simonmarhaskell at gmail.com Wed Apr 11 03:58:36 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 11 03:57:05 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461B7100.30308@list.mightyreason.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <461B7100.30308@list.mightyreason.com> Message-ID: <461C952C.60405@gmail.com> Chris Kuklewicz wrote: > Simon Marlow wrote: >> Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by >> hsc2hs, but this is done on the *host* rather than the *target* when >> bootstrapping, and thus generates the wrong results. If you'd run >> hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, >> but you can't do this because hsc2hs is a Haskell program. You could >> take the .c file generated by hsc2hs on the host and compile/run it on >> the target, but that's a hassle, so instead our policy is that we don't >> rely on any hsc2hs-generated code for bootstrapping. >> >> Unfortunately I broke the rules by accident when I introduced the >> dependency on regex. I can't think of an easy way to enforce the rule, >> at least at the moment, since there are other hsc2hs-processed modules >> that we happen to not depend on in GHC (System.Time and System.CPUTime). > > Could the solution be to depend on a pure Haskell regex implementation instead > of on a regex-posix / Posix.hsc and the system regex library? Yes, as I mentioned, ticket 1160 (http://hackage.haskell.org/trac/ghc/ticket/1160) is for replacing regex-posix with regex-tdfa, and that would fix this issue. However, Igloo just removed the regex packages from GHC's core package set, so we don't have the problem any more. > The regex-tdfa backend could be modified to work with the regex-base in GHC 6.6 > and then regex-compat could quickly be switched to use this instead of regex-posix. It sounds like a good idea to switch regex-compat to depend on regex-tdfa anyway. Cheers, Simon From simonmarhaskell at gmail.com Wed Apr 11 04:05:21 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 11 04:03:52 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <4618E17D.4060706@charter.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> Message-ID: <461C96C1.40408@gmail.com> I definitely think that -1# should be parsed as a single lexeme. Presumably it was easier at the time to do it the way it is, I don't remember exactly. I'd support a warning for use of prefix negation, or alternatively you could implement the Haskell' proposal to remove prefix negation completely - treat the unary minus as part of a numeric literal in the lexer only. This would have to be optional for now, so that we can continue to support Haskell 98 of course. Cheers, Simon Isaac Dupree wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Now I understand why negative unboxed numeric literals are parsed > weirdly, after poking around a little! > "The parser parses all infix applications as right-associative, > regardless of fixity." > > > A negative sign on the left of an expression is parsed as a special > case, binding tighter than all infix ops (until the renamer reassociates > it) (but '-' is not parsed that way when it _follows_ an expression: ( > process -1# ) is treated as _infix_ minus, i.e. subtraction, i.e. likely > compile error). > > Then, before reassociating based on fixity, negation of an unboxed > number is performed (in order to allow a sort of numeric literals that > are negative and unboxed). Here is a result of this funny treatment: > > \begin{code} > {-# OPTIONS_GHC -fglasgow-exts #-} > > import GHC.Base > > main = do > putStrLn $ "boxed: " ++ show ( ( - 2 ^ 6 ) :: Int ) > -- output: boxed: -64 -- === ( -(2 ^ 6 )) > > putStrLn $ "unboxed: " ++ show ( I# ( - 2# ^# 6# ) ) > -- output: unboxed: 64 -- === ((- 2#)^# 6# ) > > > infixr 8 ^# --just like ^, binds tighter than - (which is infixl 6) > ( ^# ) :: Int# -> Int# -> Int# > base ^# 0# = 1# > base ^# exponent = base *# (base ^# ( exponent -# 1# )) > \end{code} > > This particular combination of behavior, unfortunately, doesn't seem > useful for implementing sensible numeric literals, IMHO. My desired > warning scheme would have to wait for the renamer to sort out > fixities... unless I want to warn about (-1==1) which is ((-1)==1), as > well (do I want that warning? how about (1 == -1), or (1 ^^ -1), which > both must parse with negation being tightly binding? I hadn't considered > those very well yet...). > > > Isaac > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGGOF8HgcxvIWYTTURAiT5AKC1Zl9JYuSLBPdey/YdmCriY7FaUQCgqzNQ > clHWTS162IZWHhlXKJR8NhQ= > =zqzy > -----END PGP SIGNATURE----- > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From haskell at list.mightyreason.com Wed Apr 11 04:23:35 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Apr 11 04:22:04 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461C952C.60405@gmail.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <461B7100.30308@list.mightyreason.com> <461C952C.60405@gmail.com> Message-ID: <461C9B07.7040501@list.mightyreason.com> Simon Marlow wrote: > Chris Kuklewicz wrote: >> Could the solution be to depend on a pure Haskell regex implementation >> instead >> of on a regex-posix / Posix.hsc and the system regex library? > > Yes, as I mentioned, ticket 1160 > (http://hackage.haskell.org/trac/ghc/ticket/1160) is for replacing > regex-posix with regex-tdfa, and that would fix this issue. > > However, Igloo just removed the regex packages from GHC's core package > set, so we don't have the problem any more. > >> The regex-tdfa backend could be modified to work with the regex-base >> in GHC 6.6 >> and then regex-compat could quickly be switched to use this instead of >> regex-posix. > > It sounds like a good idea to switch regex-compat to depend on > regex-tdfa anyway. > After I upgrade to 6.6.1 (using OS X on PPC) then I will make new versions of regex-compat and regex-tdfa. The thing I have to fix is that the current "unstable" regex-tdfa depends on the "unstable" regex-base and I have to make a new branch of regex-tdfa that works against the "stable" regex-base that 6.6 and 6.6.1 use. Mainly this will be erasing code. For 6.8 we can upgrade regex-base to whatever the latest version is then. Current changes in regex-base are (1) use of 'fail' for error handling in RegexMaker, (2) use of newtypes to make avoid Hugs seeing overlapping instances in RegexContext (no more conditional compilation). -- Chris From isaacdupree at charter.net Wed Apr 11 06:38:00 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Apr 11 06:35:22 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461C96C1.40408@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> Message-ID: <461CBA88.4000901@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Marlow wrote: > I definitely think that -1# should be parsed as a single lexeme. > Presumably it was easier at the time to do it the way it is, I don't > remember exactly. > > I'd support a warning for use of prefix negation, or alternatively you > could implement the Haskell' proposal to remove prefix negation > completely - treat the unary minus as part of a numeric literal in the > lexer only. This would have to be optional for now, so that we can > continue to support Haskell 98 of course. > > Cheers, > Simon Yes, I've been thinking about how to implement both - details will come later when I have more time. I think I have a reasonably working idea of how to divide up the cases for warnings for ambiguous-looking use of both infix and prefix minus, as well as actual syntax changes... Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHLqHHgcxvIWYTTURAu4YAJ9v7fd8tkJLztqQxCblRGZy21UxfwCgn7++ OvLrEoLJtP9Uq8oQGeVhwA8= =hTdv -----END PGP SIGNATURE----- From gwright at comcast.net Wed Apr 11 09:29:23 2007 From: gwright at comcast.net (Gregory Wright) Date: Wed Apr 11 09:27:54 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461C952C.60405@gmail.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <461B7100.30308@list.mightyreason.com> <461C952C.60405@gmail.com> Message-ID: <3D53222B-C4DD-4E9E-9D99-5615E2BE6065@comcast.net> Just a further note on the FreeBSD/amd64 port. I have the mangler fixed up now, so the only remaining issue is the linker. I hope to send patches soon. Best Wishes, Greg From bulat.ziganshin at gmail.com Wed Apr 11 13:09:12 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 11 13:11:38 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461C9B07.7040501@list.mightyreason.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <461B7100.30308@list.mightyreason.com> <461C952C.60405@gmail.com> <461C9B07.7040501@list.mightyreason.com> Message-ID: <552526275.20070411210912@gmail.com> Hello Chris, Wednesday, April 11, 2007, 12:23:35 PM, you wrote: > After I upgrade to 6.6.1 (using OS X on PPC) then I will make new versions of > regex-compat and regex-tdfa. The thing I have to fix is that the current > "unstable" regex-tdfa depends on the "unstable" regex-base and I have to make a > new branch of regex-tdfa that works against the "stable" regex-base that 6.6 and > 6.6.1 use. Mainly this will be erasing code. > For 6.8 we can upgrade regex-base to whatever the latest version is then. why not just provide with 6.6.1 both old and new regex-base versions? after all, the exact reason of splitting base was just to get more flexibility. anyone who need old version can use it using cabal/ghc-pkg features, one shouldn't suppose that ghc 6.6.* will forever bundle only the same versions of packages that was shipped at ancient 6.6.0 times -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From naur at post11.tele.dk Wed Apr 11 13:39:24 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Apr 11 13:39:30 2007 Subject: ANNOUNCE: GHC 6.6.1 Release Candidate In-Reply-To: <20070410144149.GA22598@matrix.chaos.earth.li> References: <20070410144149.GA22598@matrix.chaos.earth.li> Message-ID: <200704111939.26170.naur@post11.tele.dk> Hello, On Tuesday 10 April 2007 16:41, Ian Lynagh wrote: > > We are pleased to announce the Release Candidate phase for GHC 6.6.1. > ... A few comments to the source bundles http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src-extralibs.tar.bz2 1. There are binary (.p_o and .p_hi) files present in libraries/HGL/Graphics/HGL/X11 and below. 2. On my PPC Mac OS X 10.4, configure reports checking for DocBook XSL stylesheet directory... no configure: WARNING: cannot find DocBook XSL stylesheets, you will not be able to build the documentation Some time ago, I installed docbook-xsl from mac/darwinports and this complaint disappeared from the HEAD, but not from the 6.6 branch. The relevant HEAD change is this: diff ghc-6.6-for-buildbot-20070221_1000/ghc/configure.ac ghc-HEAD-for-669-20070324_1621/ghc/configure.ac ... 931c976 < FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/docbook /sw/share/xml/xsl/docbook-xsl]) --- > FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/docbook /sw/share/xml/xsl/docbook-xsl /opt/local/share/xsl/d ocbook-xsl]) ... I suppose it would be useful for this change to be merged to 6.6.1. Best regards Thorkil From isaacdupree at charter.net Thu Apr 12 06:07:58 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Apr 12 06:05:15 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461CBA88.4000901@charter.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <461CBA88.4000901@charter.net> Message-ID: <461E04FE.7010507@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Isaac Dupree wrote: > Simon Marlow wrote: >>> I definitely think that -1# should be parsed as a single lexeme. >>> Presumably it was easier at the time to do it the way it is, I don't >>> remember exactly. >>> >>> I'd support a warning for use of prefix negation, or alternatively you >>> could implement the Haskell' proposal to remove prefix negation >>> completely - treat the unary minus as part of a numeric literal in the >>> lexer only. This would have to be optional for now, so that we can >>> continue to support Haskell 98 of course. >>> >>> Cheers, >>> Simon > > Yes, I've been thinking about how to implement both - details will come > later when I have more time. I think I have a reasonably working idea > of how to divide up the cases for warnings for ambiguous-looking use of > both infix and prefix minus, as well as actual syntax changes... not considering warnings, just syntax: 123abc is two valid Haskell tokens. for example: \begin{code} main = (\n c -> print (n,c)) 123Abc data Abc = Abc deriving Show \end{code} prints (123,Abc). So does this suggest that under a negation-is-part-of-numeric-token regime, 123-456 should be two tokens (a positive number then a negative number, here), as is signum-456 ... Presently, GHC doesn't even warn about the first thing (123abc) ^_^ Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHgT9HgcxvIWYTTURAmhLAJ0Zwd8fRYWRIWDjsTRaPx84x80RBwCgjsMA RxcCEg+2T/fraJmnsBYVEhE= =HsSp -----END PGP SIGNATURE----- From bringert at cs.chalmers.se Thu Apr 12 07:14:37 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Thu Apr 12 07:10:57 2007 Subject: ANNOUNCE: GHC 6.6.1 Release Candidate In-Reply-To: <200704111939.26170.naur@post11.tele.dk> References: <20070410144149.GA22598@matrix.chaos.earth.li> <200704111939.26170.naur@post11.tele.dk> Message-ID: On Apr 11, 2007, at 19:39 , Thorkil Naur wrote: > Hello, > > On Tuesday 10 April 2007 16:41, Ian Lynagh wrote: >> >> We are pleased to announce the Release Candidate phase for GHC 6.6.1. >> ... > > A few comments to the source bundles > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410- > src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src- > extralibs.tar.bz2 > > 1. There are binary (.p_o and .p_hi) files present in > libraries/HGL/Graphics/HGL/X11 and below. > > 2. On my PPC Mac OS X 10.4, configure reports > > checking for DocBook XSL stylesheet directory... no > configure: WARNING: cannot find DocBook XSL stylesheets, you will > not be able > to build the documentation > > Some time ago, I installed docbook-xsl from mac/darwinports and > this complaint > disappeared from the HEAD, but not from the 6.6 branch. The > relevant HEAD > change is this: > > diff ghc-6.6-for-buildbot-20070221_1000/ghc/configure.ac > ghc-HEAD-for-669-20070324_1621/ghc/configure.ac > ... > 931c976 > < > FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/ > current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/ > docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl > -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/ > share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/ > docbook /sw/share/xml/xsl/docbook-xsl]) > --- >> > FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/ > current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/ > docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl > -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/ > share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/ > docbook /sw/share/xml/xsl/docbook-xsl /opt/local/share/xsl/d > ocbook-xsl]) > ... > > I suppose it would be useful for this change to be merged to 6.6.1. This is the relevant darcs patch: Mon Sep 18 16:28:31 PDT 2006 bjorn@bringert.net * Added Darwinports path to DocBook XSL stylesheets to configure. M ./configure.ac -1 +1 /Bj?rn From simonmarhaskell at gmail.com Thu Apr 12 08:02:06 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 12 08:00:33 2007 Subject: ANNOUNCE: GHC 6.6.1 Release Candidate In-Reply-To: <200704111939.26170.naur@post11.tele.dk> References: <20070410144149.GA22598@matrix.chaos.earth.li> <200704111939.26170.naur@post11.tele.dk> Message-ID: <461E1FBE.5080909@gmail.com> Thorkil Naur wrote: > Hello, > > On Tuesday 10 April 2007 16:41, Ian Lynagh wrote: >> We are pleased to announce the Release Candidate phase for GHC 6.6.1. >> ... > > A few comments to the source bundles > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src-extralibs.tar.bz2 > > 1. There are binary (.p_o and .p_hi) files present in > libraries/HGL/Graphics/HGL/X11 and below. Thanks, this should now be fixed (from tomorrow's snapshot onwards). Cheers, Simon From simonmarhaskell at gmail.com Thu Apr 12 08:06:15 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 12 08:04:42 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461E04FE.7010507@charter.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <461CBA88.4000901@charter.net> <461E04FE.7010507@charter.net> Message-ID: <461E20B7.1080707@gmail.com> Isaac Dupree wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Isaac Dupree wrote: >> Simon Marlow wrote: >>>> I definitely think that -1# should be parsed as a single lexeme. >>>> Presumably it was easier at the time to do it the way it is, I don't >>>> remember exactly. >>>> >>>> I'd support a warning for use of prefix negation, or alternatively you >>>> could implement the Haskell' proposal to remove prefix negation >>>> completely - treat the unary minus as part of a numeric literal in the >>>> lexer only. This would have to be optional for now, so that we can >>>> continue to support Haskell 98 of course. >>>> >>>> Cheers, >>>> Simon >> Yes, I've been thinking about how to implement both - details will come >> later when I have more time. I think I have a reasonably working idea >> of how to divide up the cases for warnings for ambiguous-looking use of >> both infix and prefix minus, as well as actual syntax changes... > > not considering warnings, just syntax: 123abc is two valid Haskell > tokens. for example: > \begin{code} > main = (\n c -> print (n,c)) 123Abc > data Abc = Abc deriving Show > \end{code} > prints (123,Abc). > So does this suggest that under a negation-is-part-of-numeric-token > regime, 123-456 should be two tokens (a positive number then a negative > number, here), as is signum-456 ... Yes, absolutely. > Presently, GHC doesn't even warn about the first thing (123abc) ^_^ and remember that while '123e 4' is 3 tokens, '123e4' is only 1. Cheers, Simon From dinko.tenev at gmail.com Thu Apr 12 08:59:46 2007 From: dinko.tenev at gmail.com (Dinko Tenev) Date: Thu Apr 12 08:58:09 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461E20B7.1080707@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <461CBA88.4000901@charter.net> <461E04FE.7010507@charter.net> <461E20B7.1080707@gmail.com> Message-ID: This last piece of conversation was *so* reminiscent of a paper[1] I once read, I was almost convinced it was late by 11 days...until I checked :) Cheers, Dinko [1] http://www.research.att.com/~bs/whitespace98.pdf On 4/12/07, Simon Marlow wrote: > > Isaac Dupree wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Isaac Dupree wrote: > >> Simon Marlow wrote: > >>>> I definitely think that -1# should be parsed as a single lexeme. > >>>> Presumably it was easier at the time to do it the way it is, I don't > >>>> remember exactly. > >>>> > >>>> I'd support a warning for use of prefix negation, or alternatively > you > >>>> could implement the Haskell' proposal to remove prefix negation > >>>> completely - treat the unary minus as part of a numeric literal in > the > >>>> lexer only. This would have to be optional for now, so that we can > >>>> continue to support Haskell 98 of course. > >>>> > >>>> Cheers, > >>>> Simon > >> Yes, I've been thinking about how to implement both - details will come > >> later when I have more time. I think I have a reasonably working idea > >> of how to divide up the cases for warnings for ambiguous-looking use of > >> both infix and prefix minus, as well as actual syntax changes... > > > > not considering warnings, just syntax: 123abc is two valid Haskell > > tokens. for example: > > \begin{code} > > main = (\n c -> print (n,c)) 123Abc > > data Abc = Abc deriving Show > > \end{code} > > prints (123,Abc). > > So does this suggest that under a negation-is-part-of-numeric-token > > regime, 123-456 should be two tokens (a positive number then a negative > > number, here), as is signum-456 ... > > Yes, absolutely. > > > Presently, GHC doesn't even warn about the first thing (123abc) ^_^ > > and remember that while '123e 4' is 3 tokens, '123e4' is only 1. > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Cheers, Dinko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070412/8dca64f3/attachment.htm From Malcolm.Wallace at cs.york.ac.uk Thu Apr 12 09:43:29 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Apr 12 09:46:24 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461B6CB3.30008@gmail.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> Message-ID: <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > Also after the base > reorg we might find we have no hsc2hs-generated code left in base and > we can disable hsc2hs to prevent this happening again. Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Will that cause a problem? I'm guessing that even the autoconf'd sources are currently bootstrapped on the host rather than the target, so maybe the changeover will make no difference? Regards, Malcolm From cmb21 at kent.ac.uk Thu Apr 12 09:48:41 2007 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Thu Apr 12 09:47:10 2007 Subject: Buildng ghc-devel from macports Message-ID: Hello, I've been trying to build the ghc-devel package (6.7) from macports. However the build seems to fail half through. Specifically when running the setup for base-2.1: configure: Using compiler: ../../compiler/ghc-inplace configure: Compiler flavor: GHC configure: Compiler version: 6.7.20070411 configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace configure: Using ar found on system at: /usr/bin/ar configure: Using haddock found on system at: /opt/local/bin/haddock configure: Using ld given by user at: /usr/bin/ld configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /opt/local/bin/runghc configure: No runhugs found configure: Using tar found on system at: /usr/bin/tar configure: Using happy: /opt/local/bin/happy configure: Using alex: /opt/local/bin/alex configure: Using hsc2hs: ../../utils/hsc2hs/hsc2hs-inplace configure: No c2hs found configure: No cpphs found configure: No greencard found Setup: Unrecognised flags: --with-cc=gcc make[1]: *** [stamp/configure.library.build-profiling.base] Error 1 make: *** [stage1] Error 2 Hope someone can help! kind regards, Chris. From gwright at comcast.net Thu Apr 12 11:07:03 2007 From: gwright at comcast.net (Gregory Wright) Date: Thu Apr 12 11:05:00 2007 Subject: Buildng ghc-devel from macports In-Reply-To: References: Message-ID: <8DDFD07E-8414-43D8-90CB-583928A98B79@comcast.net> Hi Chris, On Apr 12, 2007, at 9:48 AM, C.M.Brown wrote: > Hello, > > I've been trying to build the ghc-devel package (6.7) from macports. > However the build seems to fail half through. Specifically when > running > the setup for base-2.1: > > configure: Using compiler: ../../compiler/ghc-inplace > configure: Compiler flavor: GHC > configure: Compiler version: 6.7.20070411 > configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace > configure: Using ar found on system at: /usr/bin/ar > configure: Using haddock found on system at: /opt/local/bin/haddock > configure: Using ld given by user at: /usr/bin/ld > configure: No pfesetup found > configure: Using ranlib found on system at: /usr/bin/ranlib > configure: Using runghc found on system at: /opt/local/bin/runghc > configure: No runhugs found > configure: Using tar found on system at: /usr/bin/tar > configure: Using happy: /opt/local/bin/happy > configure: Using alex: /opt/local/bin/alex > configure: Using hsc2hs: ../../utils/hsc2hs/hsc2hs-inplace > configure: No c2hs found > configure: No cpphs found > configure: No greencard found > Setup: Unrecognised flags: > --with-cc=gcc > make[1]: *** [stamp/configure.library.build-profiling.base] Error 1 > make: *** [stage1] Error 2 > > Hope someone can help! > kind regards, > Chris. To tell what's going on I'll need the build.log output of > sudo port -dv build ghc-devel > build.log 2>&1 This will be quite long, and you might want to compress it. You can send it to me directly (I maintain the macports ghc-devel port) if you'd like. Please remember to run > sudo port clean ghc-devel first to clean out any previous stuff. Macports can not yet properly restart an interrupted build. Best Wishes, Greg From simonmarhaskell at gmail.com Thu Apr 12 11:33:27 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 12 11:31:52 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <461E5147.7000408@gmail.com> Malcolm Wallace wrote: > Simon Marlow wrote: > >> Also after the base >> reorg we might find we have no hsc2hs-generated code left in base and >> we can disable hsc2hs to prevent this happening again. > > Ah. I was about to checkin a replacement for System.Posix.Types (in > base) that uses hsc2hs instead of autoconf. Will that cause a problem? > I'm guessing that even the autoconf'd sources are currently bootstrapped > on the host rather than the target, so maybe the changeover will make no > difference? I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work? Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Thu Apr 12 11:44:42 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Apr 12 11:51:27 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461E5147.7000408@gmail.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> <461E5147.7000408@gmail.com> Message-ID: <20070412164442.7eae857b.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > I suppose we could add a dependency on another Haskell compiler just to > run hsc2hs, but that's a pain. I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines. Pipe dreams for now though. Regards, Malcolm From ndmitchell at gmail.com Thu Apr 12 12:14:05 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Apr 12 12:12:27 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <20070412164442.7eae857b.Malcolm.Wallace@cs.york.ac.uk> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> <461E5147.7000408@gmail.com> <20070412164442.7eae857b.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0704120914g29a3f4d2y655358858a313114@mail.gmail.com> Hi > I'm hoping that by the end of this summer, nhc98 will be able to compile > the whole of ghc. :-) Also, and alternatively, the yhc chaps have > mooted the idea of moving from nhc98's front end to ghc's, which might > eventually give you a fully portable bytecode route to bootstrapping ghc > on new machines. We half thought about that, but a more direct goal is to be able to convert GHC Core to Yhc Core, then we can use either GHC's front end (via system) or Yhc's (natively). This would mean that we would be able to compile any library with GHC then use it with Yhc. This project will take about three days, once GHC has a non-broken Core library. Thanks Neil From claus.reinke at talk21.com Thu Apr 12 14:57:55 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Apr 12 14:56:28 2007 Subject: FreeBSD/amd64 registerised running References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com><20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> <461E5147.7000408@gmail.com> Message-ID: <018701c77d34$7c5c8cc0$b8177ad5@cr3lt> > I'm confused. I thought we copied the configuration from the target to the host > as part of the bootstrapping process, but now I can't see how this is supposed > to happen for HsBaseConfig.h. It looks like following the instructions in the > building guide will result in failure if you try to cross-compile between > machines with different word sizes, but I know I've done this in the past :-/ > Ian, any idea how this is supposed to work? > > Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause > problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target > without GHC, but we can run configure. I suppose we could add a dependency on > another Haskell compiler just to run hsc2hs, but that's a pain. how about a repository for platform-specific configuration files? that way you only need the first user on each platform to figure things out, either by installing extra tools or by modifying existing configuration files? btw, lots of things have changed since i last built ghc, but i thought it strange that configure used to rediscover platform-specific configuration data for each sub-project (each running its own configure, but not seeming all that specific in what to test for). claus From Malcolm.Wallace at cs.york.ac.uk Thu Apr 12 15:49:03 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Apr 12 15:47:26 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461E5147.7000408@gmail.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> <461E5147.7000408@gmail.com> Message-ID: <20070412204903.287b312d.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow writes: > > Ah. I was about to checkin a replacement for System.Posix.Types (in > > base) that uses hsc2hs instead of autoconf. > > Anyway, to answer your question, using hsc2hs in System.Posix.Types > will cause problems for bootstrapping GHC, yes, because we can't run > hsc2hs on the target without GHC, but we can run configure. But it is only a problem for cross-compiling - yes? And no more of a problem than ghc already has? So, should I push my patch for building System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs) or not? At the moment, the lack of System.Posix.Types is breaking the nightly builds of Cabal/nhc98. Regards, Malcolm From igloo at earth.li Thu Apr 12 17:31:48 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Apr 12 17:30:12 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <461E5147.7000408@gmail.com> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> <461E5147.7000408@gmail.com> Message-ID: <20070412213148.GA9712@matrix.chaos.earth.li> On Thu, Apr 12, 2007 at 04:33:27PM +0100, Simon Marlow wrote: > > I'm confused. I thought we copied the configuration from the target to the > host as part of the bootstrapping process, but now I can't see how this is > supposed to happen for HsBaseConfig.h. It looks like following the > instructions in the building guide will result in failure if you try to > cross-compile between machines with different word sizes, but I know I've > done this in the past :-/ > Ian, any idea how this is supposed to work? I guess we've just been lucky. "#define HTYPE_INT Int32" is probably true everywhere we've tried in recent years, and probably covers most of the potentially troublesome cases. Thanks Ian From igloo at earth.li Thu Apr 12 17:39:00 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Apr 12 17:37:22 2007 Subject: FreeBSD/amd64 registerised running In-Reply-To: <20070412204903.287b312d.Malcolm.Wallace@cs.york.ac.uk> References: <0D2B7A26-E80E-4C7B-8E26-28047D4EFC6C@comcast.net> <461B6CB3.30008@gmail.com> <20070412144329.497698fd.Malcolm.Wallace@cs.york.ac.uk> <461E5147.7000408@gmail.com> <20070412204903.287b312d.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20070412213900.GB9712@matrix.chaos.earth.li> On Thu, Apr 12, 2007 at 08:49:03PM +0100, Malcolm Wallace wrote: > Simon Marlow writes: > > > > Ah. I was about to checkin a replacement for System.Posix.Types (in > > > base) that uses hsc2hs instead of autoconf. > > > > Anyway, to answer your question, using hsc2hs in System.Posix.Types > > will cause problems for bootstrapping GHC, yes, because we can't run > > hsc2hs on the target without GHC, but we can run configure. > > But it is only a problem for cross-compiling - yes? Yes. > And no more of a problem than ghc already has? No, with the configure method we can run configure on the target and copy the files back to the host. The instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting do so for includes/ghcautoconf.h includes/DerivedConstants.h includes/GHCConstants.h and look like they ought to for libraries/base/include/HsBaseConfig.h too. But we can't run hsc2hs on the target without having a Haskell compiler there. Thanks Ian From isaacdupree at charter.net Thu Apr 12 17:46:10 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Apr 12 17:43:27 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461E20B7.1080707@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <461CBA88.4000901@charter.net> <461E04FE.7010507@charter.net> <461E20B7.1080707@gmail.com> Message-ID: <461EA8A2.2000601@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Marlow wrote: >> So does this suggest that under a negation-is-part-of-numeric-token >> regime, 123-456 should be two tokens (a positive number then a negative >> number, here), as is signum-456 ... > > Yes, absolutely. [see note 1 at the end responding irrelevantly to that] Okay, here we go with the through descriptions... Warn about any "-" that precedes without spaces a numeric literal, that is not an application of "negate" to that literal. This includes when it's infix (n-1) and when it's out-precedenced (-2^6). ===> A file that does not trigger this warning is safe to have negative numeric literals added to the syntax / lexer. [see Note 2 at the end about how commonly this warning might occur in practice] Warn about any "-" that DOES NOT precede-without-spaces a numeric literal, that nonetheless means negate. ===> A file that triggers neither this nor the previous warning is safe to have negative numeric literals added AND interpretation of unqualified operator "-" as negate removed. "Reverse" warnings, for those who want to take advantage of negative numeric literal syntax and then possibly convert to Haskell98 syntax easily: If a "-" isn't followed immediately by a numeric literal, the only thing to watch out for (and warn about) is the "forbidden section" (- 1), which could mean an actual section (\x -> x - 1) in the "new" syntax. For actual negative literals: warn when literal is the left-hand-side an infix expression with relevant precedence ((> 6, which changes program behaviour) or (= 6 and not left-associative, which causes a parse error)). (being on the right-hand side, e.g. (x ^^ -1) is completely unambiguous, and expressions like (-1 + 2) mean the same thing either way). Also, warn if the literal is part of a function application: either it would become infix in '98 syntax (e.g. (signum -2)) or just negate multiple things to the right (e.g. (-1 foo)) (some of these are type errors assuming (->) isn't made an instance of Num, but that's a later stage in the compilation process). Should we allow "positive numeric literals" +37 as well, for symmetry, so we can also break (n+1) as well as (n-1)? (and also break (+1), which is actually an asymmetric problem since that isn't a section in the first place in Haskell98) Implementation notes: I haven't looked at the part of GHC's code where it deals with fixity resolution yet, but I'm concerned that GHC might throw away information about where parentheses were in the original code at the same time - which is important information for determining whether some of the warnings are valid, it seems. For the purpose of warnings, I would explicitly keep track, for unqualified operator "-", whether it was followed by a digit (which is the unique and certain determiner that a numeric literal follows. Octal and hexadecimal start with 0c for some "c" and floating-point always starts with a decimal digit). This would probably involve adding an argument isomorphic to Bool to the constructor "ITminus". Then in compiler/parser/Lexer.x just before the @varsym rule (since alex is first maximal-munch, then top-to-bottom in the .x file, in matching choice), add rules "-" / [0-9] { minus followed by number } "-" { minus not followed by number } ( the [0-9] pattern could be refined perhaps... ) Then this notation has to be carried on through the Parser.y, which shouldn't be too hard. For negative numeric literals, I think extra rules in the lexer would be added, '-' followed by the various numeric literal types (this seems a little repetitious, is there an easier way?). The varieties of literals that were standard in the first place (i.e. non-unboxed) will get " / { extension is on }" qualifications to their patterns. mkHsNegApp (in RdrHsSyn.lhs) will be simplified or removed, since we are moving towards a more sensible treatment of negative literals. Another implementation choice could be to recognize the "minus followed by number" in the parser, but then it might be hard to distinguish between '98-syntax negate, subtraction, and negative unboxed literals, without ambiguity in the parser? (Negative) numeric literals can occur in patterns, not just expressions; that may or may not need tweaks specific to it. Test cases!!!! I suppose I should make a bunch of them, that deal with every oddity I can think of, since I have already been thinking about them... (1 Prelude.-1) is infix with either syntax, and shouldn't (probably) be warned about, etc., etc. -- which explain better what the intended behaviour is anyway. Note 1: I happen to think it's silly to allow two such tokens such that one begins at the same character-location that the previous one ends, but that's clearly a completely separate issue. I have been bitten by - -fglasgow-exts and x$y z (template haskell syntax $identifier, which is rather similar to the proposed negative literal syntax) before; maybe I don't even want infix operators adjacent to identifiers normally! (but in practice everything tends to work out without difficulty) Note 2: looking through the results for http://www.google.com/codesearch for lang:haskell [0-9a-zA-Z_'#)]-[0-9] suggests that expressions like (n-1) without spaces are mildly popular. I wouldn't trust the "number of results" though, because (1) results in comments are included, (2) who knows what code it's searching, and (3) searching for lang:haskell [-][0-9] gave me fewer results than the more restrictive lang:haskell [^0-9a-zA-Z_'#)]-[0-9] . The "#" was included in case there were glasgowIdentifiers#, and the rest of the symbols could have been useful if *&$%- didn't make one infix operator. Feeling excessively thorough, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHqihHgcxvIWYTTURAk54AJ9rsqBgu1kKJqudazzuBm6u5WujiACg2f1Y sTrl1AZrHXxzMtnpez6OSEY= =ktjn -----END PGP SIGNATURE----- From isaacdupree at charter.net Thu Apr 12 19:33:19 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Apr 12 19:30:37 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461EA8A2.2000601@charter.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <461CBA88.4000901@charter.net> <461E04FE.7010507@charter.net> <461E20B7.1080707@gmail.com> <461EA8A2.2000601@charter.net> Message-ID: <461EC1BF.1090701@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Er, > For the purpose of warnings, I would explicitly keep track, for > unqualified operator "-", whether it was followed by a digit (which is > the unique and certain determiner that a numeric literal follows. Octal > and hexadecimal start with 0c for some "c" and floating-point always > starts with a decimal digit). This would probably involve adding an > argument isomorphic to Bool to the constructor "ITminus". Then in > compiler/parser/Lexer.x just before the @varsym rule (since alex is > first maximal-munch, then top-to-bottom in the .x file, in matching > choice), add rules > "-" / [0-9] { minus followed by number } > "-" { minus not followed by number } > ( the [0-9] pattern could be refined perhaps... ) > Then this notation has to be carried on through the Parser.y, which > shouldn't be too hard. > > For negative numeric literals, I think extra rules in the lexer would be > added, '-' followed by the various numeric literal types (this seems a > little repetitious, is there an easier way?). The varieties of literals > that were standard in the first place (i.e. non-unboxed) will get " / { > extension is on }" qualifications to their patterns. mkHsNegApp (in > RdrHsSyn.lhs) will be simplified or removed, since we are moving towards > a more sensible treatment of negative literals. Another implementation > choice could be to recognize the "minus followed by number" in the > parser, but then it might be hard to distinguish between '98-syntax > negate, subtraction, and negative unboxed literals, without ambiguity in > the parser? When the "new" syntax is switched on, assuming this includes removing "-" as general prefix negate, ITminus would always be not followed by a number (by design; those become single negative-number tokens). Furthermore, we don't really want to treat "-" specially in this case. So I guess the rule > "-" { minus not followed by number } should be more like "-" / { not "new" syntax } { minus not followed by number } , and the case that interprets "..", "=>", "->", etc. would have its "-" case removed (whether "new" syntax or not). The only this this "don't treat '-' specially in this case" might fall afoul of is this proposed warning option: > If a "-" isn't followed immediately by a numeric literal, the only > thing to watch out for (and warn about) is the "forbidden section" > (- 1), which could mean an actual section (\x -> x - 1) in the "new" > syntax. , if it proves difficult to detect at the appropriate point whether an infix-operator was written as the u