Re: [Haskell-cafe] Re: HDBC, character encoding
On 04/04/2008, at 9:27 PM, John Goerzen wrote: I can see this being a performance and ease-of-use win in some situations. I don't think it's an actual feature difference, though. If you can represent it as a [Word8], you can represent it as a [Char], and it will be converted to the same underlying data for the trip through FFI. Sure. I prefer to keep things separate: Char is for Unicode characters, [Word8]/ByteString is for concrete representations. It's more about type safety than efficiency. cheers peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in Hugs, Haskell behavior question
On Apr 4, 2008, at 23:15 , Fritz Ruehr wrote: In any case, opinions about the behavior aside, there is a Hugs internal error here, so I hope that much is useful. I am not greatly surprised by that: a numeric constant like `2' is really a polymorphic value `(fromInteger 2 :: Num a => a)' per the Report, and if Hugs does that conversion at the wrong time then it might well end up attempting to turn a function call into a pattern (normally impossible in Haskell, as any attempt would either shadow the function or raise a syntax error). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in Hugs, Haskell behavior question
Derek: yes, I caught this in the language description not long after hitting "send": I had forgotten about that. But then I anticipated the behavior Ryan shows below, where using a variable that's part of a "strange" pattern will cause an error (I didn't want to check it while driving home--cell phone user/drivers are bad enough!--so thanks, Ryan, for verifying :) ). In any case, opinions about the behavior aside, there is a Hugs internal error here, so I hope that much is useful. The strange cases make for interesting academic discussions, at least. -- Fritz On Fri 4 Apr 08, at 6:49 pm, Derek Elkins wrote: Top-level bindings are irrefutable, so 2 = 3 is fine, if vacuous. On Fri 4 Apr 08, at 6:53 pm, Ryan Ingram wrote: On 4/4/08, Fritz Ruehr <[EMAIL PROTECTED]> wrote: In fact, even this goes through without a hitch! 2 = 3 This is hilarious. Maybe bindings that don't actually bind anything should be an error? Or at least a warning? In ghci: Prelude> let 2 = 3 -- no problem Prelude> let (2,x) = (3,4) -- no problem Prelude> x *** Exception: :1:4-16: Irrefutable pattern match failed for pattern (2,x) -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in Hugs, Haskell behavior question
On 4/4/08, Fritz Ruehr <[EMAIL PROTECTED]> wrote: > In fact, even this goes through without a hitch! > >2 = 3 This is hilarious. Maybe bindings that don't actually bind anything should be an error? Or at least a warning? In ghci: Prelude> let 2 = 3 -- no problem Prelude> let (2,x) = (3,4) -- no problem Prelude> x *** Exception: :1:4-16: Irrefutable pattern match failed for pattern (2,x) -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in Hugs, Haskell behavior question
On Fri, 2008-04-04 at 18:34 -0700, Fritz Ruehr wrote: > In lab the other day I was showing pattern bindings to a student and > broached a limiting case, one with no variables to be bound in the > pattern. I was surprised to find that Hugs crashed when I tried a > pattern binding at top level like this: > > (2,[1,4],5) = (2,[1,4],5) > > It also crashed on the simpler: > > [2] = [2] > > On the other hand, this turns out to be acceptable: > > 2 = 2 > > In fact, even this goes through without a hitch! > > 2 = 3 > > I'm not sure from the language definition yet whether this last > should give an "Unmatched pattern" error, but if it's intended > behavior, it does look a little odd. > > Would anyone care to argue for or against allowing this? > > In any case, the more structured patterns cause the latest (Sep 06) > Hugs release to crash, with "INTERNAL ERROR: compileGlobalFunction". > > (GHC allows the strange "2 = 3" and handles the structured ones fine, > including even "(1,[2,3],4) = (4,[3,37],42)". I haven't checked any > other compilers.) Top-level bindings are irrefutable, so 2 = 3 is fine, if vacuous. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Bug in Hugs, Haskell behavior question
In lab the other day I was showing pattern bindings to a student and broached a limiting case, one with no variables to be bound in the pattern. I was surprised to find that Hugs crashed when I tried a pattern binding at top level like this: (2,[1,4],5) = (2,[1,4],5) It also crashed on the simpler: [2] = [2] On the other hand, this turns out to be acceptable: 2 = 2 In fact, even this goes through without a hitch! 2 = 3 I'm not sure from the language definition yet whether this last should give an "Unmatched pattern" error, but if it's intended behavior, it does look a little odd. Would anyone care to argue for or against allowing this? In any case, the more structured patterns cause the latest (Sep 06) Hugs release to crash, with "INTERNAL ERROR: compileGlobalFunction". (GHC allows the strange "2 = 3" and handles the structured ones fine, including even "(1,[2,3],4) = (4,[3,37],42)". I haven't checked any other compilers.) -- Fritz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
Don Stewart wrote: > length, take, drop and index working on machine-sized Ints by default > are really a bit of a wart, aren't they? Definitely. See http://cdsmith.wordpress.com/2007/07/05/find-the-bug/ for my account of this problem when I ran into it last summer. In particular, the combination of these functions using Int and too much reliance on type inference can be fatal. Overflow is possible in most languages; but in Haskell you get used to not dealing with it by assuming that numeric types default to Integer. Then, in some remote corner somewhere, just one use of 'length' may result in an inferred type of Int for half the numbers in the program. The problem is likely to be in a piece of code completely unrelated to where the symptoms occur. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
ndmitchell: > Hi > > > We can however write function like this: > > > > eqLengths [] [] = True > > eqLengths (x:xs) (y:ys) = eqLengths ys xs > > eqLengths _ _ = False > > > > which looks just fine for me. > > I have this defined function. I also have lenEq1, lenGt1, and a few > other variants. It works, but it just doesn't feel elegant. > > Note: In case anyone gets the wrong impression, I am not suggesting > lazy naturals be the standard numeric type in Haskell, just that by > not going that way we have paid a cost in terms of elegance. > I'd be happy if we had an (unbounded) Nat type in the first place... -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
Hi > We can however write function like this: > > eqLengths [] [] = True > eqLengths (x:xs) (y:ys) = eqLengths ys xs > eqLengths _ _ = False > > which looks just fine for me. I have this defined function. I also have lenEq1, lenGt1, and a few other variants. It works, but it just doesn't feel elegant. Note: In case anyone gets the wrong impression, I am not suggesting lazy naturals be the standard numeric type in Haskell, just that by not going that way we have paid a cost in terms of elegance. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
On Fri, Apr 4, 2008 at 7:14 PM, Jake Mcarthur <[EMAIL PROTECTED]> wrote: > On Apr 4, 2008, at 11:31 AM, Loup Vaillant wrote: > > > I mean, could we calculate this equality without reducing > > length ys to weak head normal form (and then to plain normal form)? > > > > Yes. Suppose equality over Nat is defined something like: > > Z == Z = True > S x == S y = x == y > x == y = False > > And also suppose the length function actually returns a Nat instead of an > Int. Now the expression reduces as: > > length xs == length ys > S (length xs') == S (length ys') > Z == S (length ys'') > False > > That would not be possible without lazy Nats. One thing to notice is that with lazy Nats this code: length [] == length [1..] would terminate, while on 64 bit platform it is "almost bottom" :-) Theoretically it is even worse: genericLength [] == genericLength [1..] :: Integer will never terminate and eat infinite amount of memory along the way, while genericLength [] == genericLength [1..] :: Nat will do just fine. We can however write function like this: eqLengths [] [] = True eqLengths (x:xs) (y:ys) = eqLengths ys xs eqLengths _ _ = False which looks just fine for me. Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The range operator
Stefan O'Rear wrote: On Fri, Apr 04, 2008 at 08:58:06PM +0100, PR Stanley wrote: Hi folks [x, y..z] What's the role of x? Cheers, Paul First number in the output; also all pairs differ as much as the first two numbers do. Try e.g [1, 2 .. 10] and [0, 2 .. 10] More to the point, the range y..z goes in steps of y-z. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The range operator
On Fri, Apr 04, 2008 at 08:58:06PM +0100, PR Stanley wrote: > [x, y..z] > What's the role of x? It's the first argument passed to enumFromThenTo. See sections 3.10 and 6.3.4 of the Haskell report. Ciao, Kili -- There's a limit to how many buttons a shirt should have. -- Theo de Raadt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The range operator
On Fri, Apr 04, 2008 at 08:58:06PM +0100, PR Stanley wrote: > Hi folks > [x, y..z] > What's the role of x? > Cheers, > Paul First number in the output; also all pairs differ as much as the first two numbers do. Try e.g [1, 2 .. 10] and [0, 2 .. 10] Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The range operator
Hi folks [x, y..z] What's the role of x? Cheers, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
"Neil Mitchell" <[EMAIL PROTECTED]> writes: >> length, take, drop and index working on machine-sized Ints by default >> are really a bit of a wart, aren't they? > Yes. Also, having strict Int's by default is a bit ugly, [..] > (Not that it isn't a worthwhile trade off, but it is still loosing > something to gain something else) Presumably you refer to the latter point - Int strictness - here? I don't think "optimizing" list operations (take, length etc) to Int buys you much performance - traversing the list is going to be far more expensive. (Or so I believe - anybody care to benchmark it?) Unfortunately, the "genericLenght" name is about as clumsy syntactically as Int is semantically, so it's about an even trade-off :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
On Apr 4, 2008, at 11:31 AM, Loup Vaillant wrote: I mean, could we calculate this equality without reducing length ys to weak head normal form (and then to plain normal form)? Yes. Suppose equality over Nat is defined something like: Z == Z = True S x == S y = x == y x == y = False And also suppose the length function actually returns a Nat instead of an Int. Now the expression reduces as: length xs == length ys S (length xs') == S (length ys') Z == S (length ys'') False That would not be possible without lazy Nats. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: HDBC, character encoding
John Goerzen wrote: > I've looked at the Data.ByteString.Internal API, and it looks like > that ought to work. Oddly, the Data.ByteString.Lazy.Internal API does > not seem to export enough to work with it in FFI. It doesn't usually make sense to use lazy ByteStrings directly with the FFI. Most often, you'll work with the strict chunks, and wrap them up. One exception would be for C functions that let you do scatter/gather I/O, such as writev. You'd still be dealing with strict chunks when calling the function, but the wrapper API might expose a lazy interface. http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Doing without IORef
Jinwoo Lee wrote: > I haven't used ReaderT. What are the advantages when using ReaderT > instead of StateT in this case? A StateT lets you replace one IORef with another, since it gives you mutable state. A ReaderT gives you *immutable* state, so the type system guarantees that you'll always be using the same IORef. http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mostly for Neil: tagsoup problems
Hi Magnus, > Does the cabal file for Tagsoup require a version of Cabal newer than 1.1.6? > In case it does it doesn't say so. I suspect this is the cause of the > rather cryptic error message: "setup: tagsoup.cabal:20: 'Executable' stanza > starting with field 'ghc-options'". The version in the darcs repo has a Cabal-Version field, asking for 1.2 or above. I'll try and make a new release with this change included in the next week. > I also noticed that the Haddock-umentation on Neil's side is for version > 0.1, while Hackage has version 0.4. I was rather confused by that at first, > since the module names had changed :) Woops. I had linked directly to the haddock of the central module, rather than the haddock index. I will fix this later today. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
Hi > > > I meant: > > > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ? > > > > Division by 0 is still an error. What I mean is: > > Yes, but this particular one need not be performed. Will it be? Oh, sorry, I misread that. Even with current Haskell's Int's that is lazy enough to work, and won't crash. > > Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the > > Int's aren't equal, since we don't have proper lazy naturals. If we > > did, it would take 2 steps. > > Err, really? I mean, could we calculate this equality without reducing > length ys to weak head normal form (and then to plain normal form)? Not without lazy naturals, or some other way of returning the result of length lazily. > What do you mean by "proper Lazy naturals"? Peano ones? Yes Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
2008/4/4, Neil Mitchell <[EMAIL PROTECTED]>: > > > > Also, having strict Int's by default is a bit ugly, in an > > > > otherwise lazy-by-default language. > > > > > I meant: > > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ? > > Division by 0 is still an error. What I mean is: Yes, but this particular one need not be performed. Will it be? > length xs == length ys > > Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the > Int's aren't equal, since we don't have proper lazy naturals. If we > did, it would take 2 steps. Err, really? I mean, could we calculate this equality without reducing length ys to weak head normal form (and then to plain normal form)? What do you mean by "proper Lazy naturals"? Peano ones? Loup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] mostly for Neil: tagsoup problems
Neil, and others, Does the cabal file for Tagsoup require a version of Cabal newer than 1.1.6? In case it does it doesn't say so. I suspect this is the cause of the rather cryptic error message: "setup: tagsoup.cabal:20: 'Executable' stanza starting with field 'ghc-options'". I also noticed that the Haddock-umentation on Neil's side is for version 0.1, while Hackage has version 0.4. I was rather confused by that at first, since the module names had changed :) /M ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
> > > Also, having strict Int's by default is a bit ugly, in an > > > otherwise lazy-by-default language. > > I meant: > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ? Division by 0 is still an error. What I mean is: length xs == length ys Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the Int's aren't equal, since we don't have proper lazy naturals. If we did, it would take 2 steps. Read this: http://citeseer.ist.psu.edu/45669.html - it argues the point I am trying to make, but much better. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
2008/4/4, Neil Mitchell <[EMAIL PROTECTED]>: > > Also, having strict Int's by default is a bit ugly, in an > otherwise lazy-by-default language. You do mean that, for example (\x -> x + 1) (1/0 :: Int) <=> _|_ ? Does it bites often (and how, if you have any example)? cheers, Loup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: HDBC, character encoding
On 2008-04-04, Peter Gammie <[EMAIL PROTECTED]> wrote: >> through, however it is obtained, and let the programmer set the >> encoding as desired. If this approach isn't working for people, I'd >> like to fix it, but want to make sure it's done right. > > Assuming you're talking about the FFI's mandated behaviour, I'm not > very comfortable with the encoding depending on the C locale, for two > main reasons: > > - the program I'm hacking runs on some web host's server that is an > unknown quantity. > - GHC has a few quirks in how it implements the FFI, better to avoid > the part that interprets characters. > > If you want to be general, I guess you could abandon String (at the > HDBC level) and use [Word8]/ByteString everywhere, then provide some > convenience wrappers. Then you can uniformly handle binary and textual > data. I am not familiar with your project though. I've looked at the Data.ByteString.Internal API, and it looks like that ought to work. Oddly, the Data.ByteString.Lazy.Internal API does not seem to export enough to work with it in FFI. I can see this being a performance and ease-of-use win in some situations. I don't think it's an actual feature difference, though. If you can represent it as a [Word8], you can represent it as a [Char], and it will be converted to the same underlying data for the trip through FFI. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
On Fri, Apr 04, 2008 at 12:34:54PM +0100, Neil Mitchell wrote: > > length, take, drop and index working on machine-sized Ints by default > > are really a bit of a wart, aren't they? > > Yes. Also, having strict Int's by default is a bit ugly, in an > otherwise lazy-by-default language. It's a place where Haskell decided > to remove mathematical elegance for pragmatic speed... > > (Not that it isn't a worthwhile trade off, but it is still loosing > something to gain something else) Personally, I like Ints. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows CE, Xscale Compiler?
At 14:37 04/04/2008, you wrote: And how would I cross compile something for that platform with ghc? (There seems to be no port, which is fine) Don't look at me mate. :-) PR Stanley schrieb: I'm surprised you can't use the Glasgow implementation on CE. At 13:55 04/04/2008, you wrote: Is there any Haskell compiler for Windows CE on a XScale platform? I googled around a bit and found references to a Hugs implementation but couldn't find any place to download it. I have the opportunity to program a teledrive[1] and would very much like to avoid something disfunctional like C. [1] http://www.iavproducts.com/de/produkte/teledrive/teledrive.php ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows CE, Xscale Compiler?
I'm surprised you can't use the Glasgow implementation on CE. At 13:55 04/04/2008, you wrote: Is there any Haskell compiler for Windows CE on a XScale platform? I googled around a bit and found references to a Hugs implementation but couldn't find any place to download it. I have the opportunity to program a teledrive[1] and would very much like to avoid something disfunctional like C. [1] http://www.iavproducts.com/de/produkte/teledrive/teledrive.php ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Windows CE, Xscale Compiler?
Is there any Haskell compiler for Windows CE on a XScale platform? I googled around a bit and found references to a Hugs implementation but couldn't find any place to download it. I have the opportunity to program a teledrive[1] and would very much like to avoid something disfunctional like C. [1] http://www.iavproducts.com/de/produkte/teledrive/teledrive.php signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..]
Hi > length, take, drop and index working on machine-sized Ints by default > are really a bit of a wart, aren't they? Yes. Also, having strict Int's by default is a bit ugly, in an otherwise lazy-by-default language. It's a place where Haskell decided to remove mathematical elegance for pragmatic speed... (Not that it isn't a worthwhile trade off, but it is still loosing something to gain something else) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Doing without IORef
Hi Andrew, I haven't used ReaderT. What are the advantages when using ReaderT instead of StateT in this case? Thanks, jinwoo On Fri, Apr 4, 2008 at 2:07 PM, <[EMAIL PROTECTED]> wrote: > G'day all. > > Quoting Jinwoo Lee <[EMAIL PROTECTED]>: > > Thanks everyone! > > Now I think using IORef is the most practical way to do this. > > > > Just a suggestion: Store it in a ReaderT instead of a StateT. > > Cheers, > Andrew Bromage > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Jinwoo Lee Always remember that you are unique. Just like everyone else. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: trying to install ghc-6.8.2 both binaries and sources
[EMAIL PROTECTED] wrote: > I am operating under the assumption that Idid have a broken gcc. Your gcc is not broken, but a bit old (for a new ghc-6.8.2) > Which we'll further canonicalise into: i386-unknown-linux > checking for path to top of build tree... pwd: timer_create: Operation > not supported > configure: error: cannot determine current directory This timer_create error is due to an old glibc. If it comes from the installation of http://www.haskell.org/ghc/dist/6.8.2/ghc-6.8.2-i386-unknown-linux.tar.bz2 than you have to install an older version (i.e. ghc-6.4.2) http://www.haskell.org/ghc/download_ghc_642.html#x86linux If you (or what or however installs your software) installed my version http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-linux.tar.bz2 (or your version was created differently) than try the above ghc-6.8.2 version first. Usually ghc is installed under /usr/local/ so the binary script is /usr/local/bin/ghc. If no idea why your ghc is /usr/bin/ghc. It's either a link or it was installed using --prefix=/usr. (debian users may know) Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
