Re: Haskell on Red Hat Enterprise...

2005-03-17 Thread Andy Moran
Tomasz Zielonka wrote:
On Thu, Mar 17, 2005 at 10:02:56AM -0500, Francois Meehan wrote:
Hi all,
I need Haskell to be installed on a Red advance server 3. Could not find
RPM's
for it. Tried compiling for tar file, won't pass the ./configure, giving
me configure: error: GHC is required unless bootstrapping from .hc
files. error.
Could someone give me some pointers on how to do this?

I was installing GHC 6.2.2 on RH AS r3 on x86 recently and the generic
binary distribution for Generic Linux with glibc 2.3 worked fine. Just
download it from the website, configure, make in-place, and you have a
working GHC in 5 minutes. You can use this GHC to compile another, newer
versions. There is a generic binary x86/Linux glibc 2.3 version of GHC
6.4 on the website too.
This was my experience on Fedora Core 3 too.
If building on RHEL3 or FC3, you will likely need to ./configure 
--with-gcc=gcc33 (provided you have gcc-compat installed). The latest 
gcc on these systems is 3.4. With 3.4, changes were made to the 
-traditional version of the C preprocessor that make it incompatible 
with the way in which many of the Haskell modules in the GHC source tree 
reify make/build variables as Haskell strings.

Have we converged on a long-term solution for this problem? Is hscpp 
ready for the job?

Cheers,
Andy
--
Andy Moran  Ph. (503) 626 6616, x113
Galois Connections Inc.  Fax. (503) 350 0833
12725 SW Millikan Way, Suite #290  http://www.galois.com
Beaverton, OR 97005 [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: cpphs (was Re: Haskell on Red Hat Enterprise...)

2005-03-17 Thread Andy Moran
Malcolm Wallace wrote:
Have we converged on a long-term solution for this problem? Is hscpp 
ready for the job?
I believe cpphs is in good shape.  There has been one bug report, and
no new feature requests, in the last 4 months since 0.8 was released,
with 235 downloads of that version.  Over a slightly longer period,
it has been used internally by hmake and nhc98 in preference to cpp,
with no visible problems.
With the attached compatibility script, it is largely possible to use
cpphs as a drop-in replacement for cpp.  (The script just translates
the command-line argument format.)  e.g.
ghc -cpp -pgmP cpphs.compat 
works as expected.
I notice that cpphs understands CPP stringification (if invoked with 
--hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen) 
have to do with fooling -traditional into turning macro constants into 
Haskell strings, which can more readily be done with the #-operator. So, 
would using cpphs mean would could do away with the string gap hack?

The only real issue currently preventing ghc from adopting cpphs is
ideological (GPL licensing).
		http://haskell.org/cpphs/
What implications does the LGPL have for a GHC binary that was built 
using  cpphs, if the GHC binary were used solely within an organization 
(i.e. not distributed)? What if cpphs were distributed with such a GHC 
binary as an executable?

A
--
Andy Moran  Ph. (503) 626 6616, x113
Galois Connections Inc.  Fax. (503) 350 0833
12725 SW Millikan Way, Suite #290  http://www.galois.com
Beaverton, OR 97005 [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: cpphs (was Re: Haskell on Red Hat Enterprise...)

2005-03-17 Thread Andy Moran
Andy Moran wrote:
I notice that cpphs understands CPP stringification (if invoked with 
--hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen) 
have to do with fooling -traditional into turning macro constants into 
Haskell strings, which can more readily be done with the #-operator. So, 
would using cpphs mean would could do away with the string gap hack?
Ahem. ... would using cpphs mean _we_ could do away with ...
A
--
Andy Moran  Ph. (503) 626 6616, x113
Galois Connections Inc.  Fax. (503) 350 0833
12725 SW Millikan Way, Suite #290  http://www.galois.com
Beaverton, OR 97005 [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: cpphs (was Re: Haskell on Red Hat Enterprise...)

2005-03-17 Thread Andy Moran
Malcolm Wallace wrote:
Andy Moran [EMAIL PROTECTED] writes:
I notice that cpphs understands CPP stringification (if invoked with 
--hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen) 
have to do with fooling -traditional into turning macro constants into 
Haskell strings, which can more readily be done with the #-operator. So, 
would using cpphs mean we could do away with the string gap hack?
Without seeing the examples in question, I can't say for definite, but
cpphs /does/ preserve string gaps in source code in all cases.
Here's an example, from 6.2.1's ghc/utils/ghc-pkg/Main.hs:
-- hackery to convice cpp to splice GHC_PKG_VERSION into a string
version :: String
version = tail \
   \ GHC_PKG_VERSION
HEAD uses a Makefile-generated Version.hs instead. Simon M.: are all 
instances of the above trick replaced by analogues of this much neater 
mechanism?

In addition, you can paste symbol values into strings using either the
ANSI stringification operator (#) or the traditional behaviour of
expansion within quotes (SYMBOL).
So, cpphs' version of traditional is truer to tradition than gcc's, it 
seems. gcc -E -traditional -x c doesn't expand within quotes, which is 
why hacks like the above were introduced.

Cheers,
Andy
--
Andy Moran  Ph. (503) 626 6616, x113
Galois Connections Inc.  Fax. (503) 350 0833
12725 SW Millikan Way, Suite #290  http://www.galois.com
Beaverton, OR 97005 [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: @-bindings broken in 6.0?

2003-06-18 Thread Andy Moran
On Wednesday 18 June 2003 01:04 am, Simon Peyton-Jones wrote:

 Better syntax here would be welcome if anyone can think of some.

Why not add a '|' after the initial '[':

[|t|  ...  |]
and
[|p| ... |]

It may be a little more heavyweight but it is symmetrical (and probably makes 
parsing easier too).

I haven't played with Template Haskell at all, so I don't know if '[|' is 
already a distinguished token.

Cheers,

Andy

-- 
Andy Moran  Ph.  (503) 526 3472
Galois Connections Inc. Fax. (503) 350 0833
3875 SW Hall Blvd.http://www.galois.com
Beaverton, OR 97005[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users