Re: [Haskell] ANNOUNCE: GHC version 6.4
Some minor documentation feedback... At 12:25 11/03/05 +, Simon Marlow wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.4 = I've just been browsing the release notes at: http://haskell.org/ghc/docs/6.4/html/users_guide/release-6-4.html and I notice some broken links about the end of section 1.4.3: [[ Network.URI has been completely rewritten, and now conforms to RFC2732. New module: System.Posix.Error. New module: System.Posix.Signals.Exts. ]] Specifically: http://haskell.org/ghc/docs/6.4/html/libraries/base/Network.URI.html http://haskell.org/ghc/docs/6.4/html/libraries/base/System.Posix.Error.html http://haskell.org/ghc/docs/6.4/html/libraries/base/System.Posix.Signals.Exts.html #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] ANNOUNCE: GHC version 6.4
On 17 March 2005 10:35, Graham Klyne wrote: I've just been browsing the release notes at: http://haskell.org/ghc/docs/6.4/html/users_guide/release-6-4.html and I notice some broken links about the end of section 1.4.3: [[ Network.URI has been completely rewritten, and now conforms to RFC2732. New module: System.Posix.Error. New module: System.Posix.Signals.Exts. ]] Specifically: http://haskell.org/ghc/docs/6.4/html/libraries/base/Network.URI.html http://haskell.org/ghc/docs/6.4/html/libraries/base/System.Posix.Error.h tml http://haskell.org/ghc/docs/6.4/html/libraries/base/System.Posix.Signals .Exts.html Oops, I thought I checked all those. Thanks, should be fixed now. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haskell on Red Hat Enterprise...
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? Regards, Francois Random Thought: --- What nature delivers to us is never stale. Because what nature creates has eternity in it. - Isaac Bashevis Singer, 1904 - 1991 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell on Red Hat Enterprise...
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. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell on Red Hat Enterprise...
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: Haskell on Red Hat Enterprise...
A million thanks Tomasz, Worked like a charm. Have a nice day! Francois 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. Best regards Tomasz Random Thought: --- Love makes the world go 'round, with a little help from intrinsic angular momentum. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
comments on the GHC API
Hi folks, I just had a first look at the sketch for the planned GHC API (ghc/compiler/main/GHC.hs), since we are very keen on using it ... Our group would mostly like to make use of a compilation manager/module system implementation for Haskell---so these are the parts I concentrated on for now. More specifically, the scenario how we would like to use a GHC library is the following: So far, we've implemented a static analysis for (single) Haskell modules. To make our tool ready for a wider use, we would like extend it to full Haskell 98 (plus extensions). What we therefore would like to ask a GHC library is, given a specific module A, to compile all the other modules that A is dependent on, load them into a context for A, and start processing A up to the point where the actual type-checking of A would commence. After that, we would like to query the library about the initial (type) environment of A (that is, get out a complete summary of all the imported bindings, classes, methods, etc) to then proceed with our own analysis instead of using GHC's type inferencer. I see two basic ways how a GHC library could help us to achieve this: - The library both offers a separate module dependency analysis and also lets us use the compiler in one-shot mode. We then could first calculate the dependencies of A, compile them separately, and calculate the initial environment of A manually by combining the interfaces of the imported modules. Of course, we would also need the possibility to access the imports of A (including renamings and such) without the need to compile A as a whole. - Loading a set of targets (using *load*) can be controlled in a more fine-grained way. Instead of just offering the possibility to compile a set of targets either completely or not at all, there is an option to compile targets only up to a certain compilation phase (or alternatively, to optionally keep intermediate results occurring between the phases to be able to retrieve them afterwards.) We, for our part, would need parts of the intermediate result (that is, the type environment and class declarations) existing either before parsing A, after parsing A, or, even better, after renaming A. Other users may be interested in other intermediate results. What do others think? Some more, rather random, remarks: - I guess v_CmdLineMode and friends are iorefs that are supposed to live globally in GHC.hs. Couldn't you also pack them into a separate data type created by *init* and later share them between several sessions. Maybe we could even introduce a Session monad? Looking at all the functions again, they all seem to have Session arguments ... - I guess the exported name *GhcSession* should read *Session* (or better the other way around) - Same for *GhcMode* vs. *GhciMode* - What's the purpose of having a mode argument for newSession? As I read the rest of the API, *load* is the only way to trigger the compilation of targets. And *load* seems to be intended to work similar to the interactive mode only. - What are Module, ModSummary, ModIface, HsTypecheckedGroup, HsGroup, TyThing, and Type standing for (I know of course ...)? How complicated would it be to return already existing (TH) data types instead of exposing/specifying more of GHC's internals? Cheers, Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cpphs (was Re: Haskell on Red Hat Enterprise...)
Andy Moran [EMAIL PROTECTED] writes:
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?
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.
The only real issue currently preventing ghc from adopting cpphs is
ideological (GPL licensing).
http://haskell.org/cpphs/
Regards,
Malcolm
file cpphs.compat
#!/bin/sh
# A minimal compatibility script to make cpphs accept the same
# arguments as real cpp, wherever possible.
# Set this variable as the path to your installed version of cpphs:
CPPHS=/usr/local/bin/cpphs
processArgs () {
TRADITIONAL=no
STRIP=yes
INFILE=-
OUTFILE=-
while test $1 !=
do
case $1 in
-D)shift; echo -D$1 ;;
-D*) echo $1 ;;
-U)shift; echo -U$1 ;;
-U*) echo $1 ;;
-I)shift; echo -I$1 ;;
-I*) echo $1 ;;
-o)shift; echo -O$1 ;;
-o*) echo -O`echo $1 | cut -c3-` ;;
-std*) ;; # ignore language spec
-x)shift ;; # ignore language spec
-ansi*)TRADITIONAL=no ;;
-traditional*) TRADITIONAL=yes ;;
-include) shift; echo $1 ;;
-P)echo --noline ;;
-C)STRIP=no ;;
-CC) STRIP=no ;;
-A)shift ;; # strip assertions
--help)echo $1 ;;
-version) echo -$1 ;;
--version) echo $1 ;;
-*);; # strip all other flags
*) if [ $INFILE = - ]
then INFILE=$1
else OUTFILE=$1
fi ;;
esac
if test $1 != ; then shift; fi
done
if [ $TRADITIONAL = no ]; then echo --hashes; fi
if [ $STRIP = yes ]; then echo --strip;fi
echo $INFILE
if [ $OUTFILE != - ]; then echo -O$OUTFILE; fi
}
exec $CPPHS `processArgs $@`
___
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...)
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...)
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...)
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. In addition, you can paste symbol values into strings using either the ANSI stringification operator (#) or the traditional behaviour of expansion within quotes (SYMBOL). 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)? Both the GPL and LGPL lay obligations on the user of the code only if they re-distribute it - it has no impact on internal use if there is no re-distribution. What if cpphs were distributed with such a GHC binary as an executable? If cpphs is distributed as a stand-alone binary, then you must respect the conditions of the GPL with regard to that program (only), i.e. permit re-distribution, publish modified source code etc. This by itself does not place any further restrictions on any of your own software you distribute with it. In GPL terms, this is mere aggregation, which is non-infective. Your own GHC-produced binary can have any licence you like. It is only if you were to re-use the code from cpphs as a library linked into your own software, that restrictions would apply to your software. In the case of the LGPL, the end user must be given the right to remove cpphs and replace it with a newer version, which tends to imply that you need to link it dynamically rather than statically. However, I expect very few people would need to incorporate cpphs as a library - the stand-alone executable situation is far more likely. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Parse error
Hello!
In the attachment you will find a file, in which I try to access Java from
Haskell using the Java bridge for functional languages.
For details see
http://sourceforge.net/projects/jvm-bridge/
and
http://dapissarenko.com/resources/2005_02_17_eigenvaluesJava/2005_02_17_eigenva
luesJava.pdf
When I try to compile the attached file using
ghc +RTS -c -RTS -package javavm -c EigenvalueCalculatorHaskell.hs -o
EigenvalueCalculatorHaskell.o
I get the error
EigenvalueCalculatorHaskell.hs:28: parse error on input `putStrLn'
Unfortunately, I have not the slightest idea about how to fix/isolate it (I
already commented out almost the whole code).
Please tell me what I could try to correct the error. I appreciate ANY hint.
Many thanks in advance
Dmitri Pissarenko
PS: The source code of the files related to EigenvalueCalculatorHaskell.hs is
located at
http://dapissarenko.com/resources/2005_02_17_eigenvaluesJava/2005_02_17_lik.zip
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
module EigenvalueCalculatorHaskell where
{
import Class_MathLibEigenvalueCalculator;
import EigenvalueCalculatorHaskell_JVM;
import JVMBridge;
import IO;
calculateEigenvalues :: Array (Int, Int) Double - [Double]
calculateEigenvalues matrix = (do
{
calculateEigenvalues_JMathLibEigenvalueCalculator_ArrayArrayJdouble matrix
} :: JVM ());
-- calculateEigenvalues matrix = (do
-- {
-- calculateEigenvalues_JMathLibEigenvalueCalculator_ArrayArrayJdouble matrix
-- } :: JVM ());
main :: IO ();
main = runWithClasspath [./](do
{
let matrix1 = (array ((1,1),(3,3)) [((1,1), 0.0), ((1,2), 0.0), ((1,3),-2.0), ((2,1), 0.0), ((2,2), 7.0), ((2,3), 0.0), ((3,1), 0), ((3,2), 0), ((3,3), -3)]);
--let eigenVal = calculateEigenvalues_JMathLibEigenvalueCalculator_ArrayArrayJdouble (matrix1);
-- eigenvalues - (do {calculateEigenvalues_JMathLibEigenvalueCalculator_ArrayArrayJdouble matrix1} :: JVM ());
--eigenvalues - (calculateEigenvalues_JMathLibEigenvalueCalculator_ArrayArrayJdouble matrix1);
-- putStrLn Eigenvalues of matrix1 (start);
-- putStrLn (show eigenvalues);
putStrLn Eigenvalues of matrix1 (end);
-- callIO (putStrLn (end));
{- let matrix2 = array ((1,1),(3,3)) [((1,1), 1.0), ((1,2), 0.0), ((1,3), 2.0), ((2,1), 0.0), ((2,2), 5.0), ((2,3), 0.0), ((3,1), 3), ((3,2), 0), ((3,3), 2)];
eigenvalues - calculateEigenvalues matrix2;
putStrLn Eigenvalues of matrix2 (start);
putStrLn (show eigenvalues);
putStrLn Eigenvalues of matrix2 (end);
let matrix3 = (array ((1,1),(2,2)) [((1,1), 3.0),
((1,2), 0.0), ((2,1), 4.0), ((2,2), 5.0)]);
eigenvalues - calculateEigenvalues matrix3;
putStrLn Eigenvalues of matrix3 (start);
putStrLn (show eigenvalues);
putStrLn Eigenvalues of matrix3 (end);
let matrix4 = (array ((1,1),(2,2)) [((1,1), -1.0),
((1,2), 3.0), ((2,1), -2.0), ((2,2), 4.0)]);
eigenvalues - calculateEigenvalues matrix4;
putStrLn Eigenvalues of matrix4 (start);
putStrLn (show eigenvalues);
putStrLn Eigenvalues of matrix4 (end);
let matrix5 = (array ((1,1),(2,2)) [((1,1), 0.0),
((1,2), -2.0), ((2,1), 1.0), ((2,2), -3.0)]);
eigenvalues - calculateEigenvalues matrix5;
putStrLn Eigenvalues of matrix5 (start);
putStrLn (show eigenvalues);
putStrLn Eigenvalues of matrix5 (end); -}
} :: JVM ());
}
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Parse error
On Thu, 17 Mar 2005 20:42:30 +0100, Dmitri Pissarenko
[EMAIL PROTECTED] wrote:
Hello!
In the attachment you will find a file, in which I try to access Java from
Haskell using the Java bridge for functional languages.
For details see
http://sourceforge.net/projects/jvm-bridge/
and
http://dapissarenko.com/resources/2005_02_17_eigenvaluesJava/2005_02_17_eigenva
luesJava.pdf
When I try to compile the attached file using
ghc +RTS -c -RTS -package javavm -c EigenvalueCalculatorHaskell.hs -o
EigenvalueCalculatorHaskell.o
I get the error
EigenvalueCalculatorHaskell.hs:28: parse error on input `putStrLn'
Unfortunately, I have not the slightest idea about how to fix/isolate it (I
already commented out almost the whole code).
Please tell me what I could try to correct the error. I appreciate ANY hint.
Use 'do {let {foo = baz}; bar }'. And Haskell code look _a lot_
prettier when using the layout to structure the program.
--
Friendly,
Lemmih
___
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...)
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
Updates for Mac OS X users using Darwinports
Hi, Users of Mac OS X/Darwinports will find new portfiles for ghc (ghc-6.4), nhc98 (nhc-1.18) and hugs98 (March 2005 release). The hmake port has been bumped to version 3.10 and a new port of cpphs (version 0.9) has been added. The darwinports system builds from source, although progress is being made on extending it to provide binary packages as well. A new ghc-devel port will be available soon for those who want to live on the bleeding edge. Thanks to Malcolm Wallace for ironing out some last minute issues with nhc98. Best Wishes, Greg Gregory Wright ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Updated 6.4 Windows installer RC
An updated version of the Windows installer for ghc-6.4 is now available for testing, http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld1.msi md5 checksum: 4a55a5614587cef07a19d7f7728f3a83 It hopefully sorts out the showstopping profiling problems that people have reported; let me know if it doesn't and/or there are other packaging snafus. If nothing major pops up, I'll consider the bits blessed and hook the installer up to the GHC downloads page. Note: - the installer re-uses the product GUIDs of the original 6.4 installer, so if you've already got it installed, it'll remove that install the first time you run it. - the HGL and Win32 packages have been removed from the installer at the suggestion of the package author(s); deemed not quite yet ready for primetime, I believe. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
