Re: Faster, GHC, and floating point.
* [EMAIL PROTECTED] [2003-10-21T11:39+0200]: > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). Did you add the SSE options etc. to the C++ program as well when comparing Haskell vs. C++? What is the SSE speedup of C++ vs. C++/with SSE? Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More problems compiling GHC on Mac OS X
* Kirsten Chevalier <[EMAIL PROTECTED]> [2003-03-17T01:09-0800]:
> configure says:
>
> checking for sendfile in sys/sendfile.h... no
> checking for sendfile in sys/socket.h... no
>
> I tried building again just now, just to be sure, and still got the same error
> message ("Sendfile.hsc:19: Variable not in scope: `c_sendfile'").
Try removing c_sendfile from the export list.
Cheers,
Michael
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
jadetex (was: Re: reaping fd's and flushing buffers)
On Thu, Jan 09, 2003 at 02:37:03AM -0800, William Lee Irwin III wrote: > On Mon, Jan 06, 2003 at 06:13:27AM -0800, William Lee Irwin III wrote: > > Thanks, I've started brewing up a tree and I'll take that for a spin > > when it's done cooking. > > ouch! jadetex needs an upgrade (ghc debian maintainer?). Probably related to this bug: http://bugs.debian.org/171985 ? (also includes hint for workaround) Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
On Mon, Nov 25, 2002 at 11:22:56AM -0500, Dean Herington wrote: > Is even the following example from the library report (section 11.8.2) > problematic? > > import System > import Char( toUpper ) > > main = do > [f1,f2] <- getArgs > s <- readFile f1 > writeFile f2 (map toUpper s) yes, if f1 == f2. Lots of puzzled students resulting... :) Cheers, M/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
On Mon, Nov 25, 2002 at 10:09:01AM -, Simon Marlow wrote: > It is nice, but it introduces too many problems. What happens to any > I/O errors encountered by the lazy I/O? They have to be discarded, > which means you can't effectively use lazy I/O for robust applications > anyway. *mumble*Exceptions*mumble*, but that of course opens another can of worms... Maybe something similar to exceptions, but better suited to laziness... somehow... hmm... Cheers, Michael p.s.: [x] Lazy I/O must die, just for the record. :) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO and IORefs
On Mon, Nov 18, 2002 at 10:36:05AM -0800, Hal Daume III wrote:
> You can't. CSE (common subexpression elimination) will replace any
> occurances of 'newState 0' in a function body with the same value.
>
> In short: don't use upIO :)
Sorry, cannot resist to pour a little salt onto the wound :)
[232]% grep global ghc/compiler/utils/Util.lhs
, global
global :: a -> IORef a
global a = unsafePerformIO (newIORef a)
[233]%
ghc/compiler/HsVersions.h:
[...]
#ifdef __GLASGOW_HASKELL__
#define GLOBAL_VAR(name,value,ty) \
name = Util.global (value) :: IORef (ty); \
{-# NOINLINE name #-}
#endif
[237]% grep -r GLOBAL_VAR ghc/compiler | wc -l
90
Muahahah... ;-P
Cheers,
Michael
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Docs missing?
Package: ghc5-doc Version: 5.04-1 Severity: minor [Bcc:ed to [EMAIL PROTECTED]] * Jorge Adriano <[EMAIL PROTECTED]> [2002-07-21T23:09+0100]: > 1. The User's Guide: > file:/usr/share/doc/packages/ghc/docs/users_guide/users-guide.html > The correct link is actually: > file:/usr/share/doc/packages/ghc/docs/users_guide/users_guide/users-guide.html In the ghc5-doc Debian packages these files live under: /usr/share/doc/ghc5-doc/html/users_guide/ To install the html docs I used: $(MAKE) -C build-stage$(MAXSTAGE) \ install-docs \ prefix=$(CURDIR)/$(destdir)/$(prefix) \ datadir=$(CURDIR)/$(destdir)/$(prefix)/share/doc/$(package) with 'SGMLDocWays="html dvi ps"' in mk/build.mk. Unfortunately, the link does not work here either, since the file users-guide.html is named book1.html :( . But that's another problem, I think, and likely related to docbook-utils. > Base: file:/usr/share/doc/packages/ghc/docs/base/index.html > Haskell98: file:/usr/share/doc/packages/ghc/docs/haskell98/index.html > Network: file:/usr/share/doc/packages/ghc/docs/network/index.html > Haskell-src: file:/usr/share/doc/packages/ghc/docs/haskell-src/index.html > None of this links work. I can't find the libraries documentation anywhere in > file:/usr/share/doc/packages/ghc/docs/ Their counterparts all work on Debian. > Same goes to hslibs - the "old haskell libraries". > file:/usr/share/doc/packages/ghc/docs/hslibs/book-hslibs.html Same as before - the file is called book1.html here. Sad enough, in the Debian happy package I fixed^Wkludged around this some time ago (in 1.11-2). From debian/rules: - # grrr, this changes every now and then :( sgmldocindex := book1.html - Unless anyone objects, I'll delay fixed Debian packages until 5.04.1 is released. Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 5.04 released
* Ashley Yakeley <[EMAIL PROTECTED]> [2002-07-11T17:06-0700]: > At 2002-07-11 11:22, Eray Ozkural wrote: > > >> A Windows installer for 5.04 is now available via the GHC downloads > >> page: http://haskell.org/ghc/download_ghc_504.html > > > >/me pings debian people. we can't lag behind windows, come on ;) Why not? > I'm sure Michael Weber is working on it even as we speak... ETA is next weekend. Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fwd: Can I install HOpenGL in Windows?
* Denver <[EMAIL PROTECTED]> [2001-10-26T01:25+1000]: > >Please help. I would like to use HOpenGL within Windows, so I wanted >to ask whether it was possible, and if it is, I would like to request >for help. Any help greatly appreciated. Hi! I'm sorry, I don't know much about the Windows port of GHC, but I'm sure the folks at [EMAIL PROTECTED] can be of some help, or maybe the author of HOpenGL can step in... [Sven, AYT? =)] I'll do a Cc: to the list. To subscribe to any of the GHC mailing lists, please visit http://haskell.org/ghc/mailing-lists.html Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Installation Location
On Thu, Oct 25, 2001 at 03:18:33 -0700, Ashley Yakeley wrote: > At 2001-10-25 03:01, Simon Marlow wrote: > > >I've wondered at various times in the past whether there ought to be a > >link from /usr/local/includes/ghc to /usr/local/lib/ghc-5.02/includes. > > Won't help, my GHC is installed at /usr/lib/ghc-5.02/, exactly where the > Debian package put it. And now that location is hard-coded in my Makefile. What about (finally!) adding the `--print-include-path' and `--print-library-path' switches to ghc? That would be a clean solution, IMO. IIRC, this has been asked for several times in the past, but was never implemented. I guess it would make at least Malcolm's life much easier for the nhc98 scripts... :) Cheers, Michael -- /~\ ASCII ribbon | inbox, n.: \ / campaign |A catch basin for everything you don't want to deal X against |with, but are afraid to throw away. / \ HTML mail| ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with .ghci (fwd)
On Tue, Jul 10, 2001 at 19:54:11 +0100, Chris Webb wrote: > Jose Emilio Labra Gayo <[EMAIL PROTECTED]> writes: > > > However, if I write my own ".ghci", I obtain: > [...] > > *** WARNING: ./.ghci is writable by someone else, IGNORING! > If doing this annoys you too much, I guess you could easily fix the > checkPerms function (somewhere around line 200 of InteractiveUI.hs) > to understand that if you're the only member of a group, it doesn't > matter whether or not g+w is set. erm, how about leaving this intact and setting the umask instead to 022? There was a reason to stick this code there... Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 "I WILL NOT SEND LARD THROUGH THE MAIL" -- Bart Simpson in 2F04 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Patch ghci to recognize :q!
On Wed, Jun 27, 2001 at 10:32:47 +0200, Volker Stolz wrote: > Maybe I'm the only one who happens to type > :q! to leave ghci all the time, maybe not. > Would somebody object to a patch which will cause > ghci to quit on ":q!"? Oh, and I want C-x C-c ... and C-K Q while we're at it... ;-p (No, this is NOT a serious request :)) Cheers, Michael -- /~\ ASCII ribbon | beta test, v: To voluntarily entrust one's data, one's \ / campaign | livelihood and one's sanity to hardware or software X against | intended to destroy all three. In earlier days, / \ HTML mail| virgins were often selected to beta test volcanos. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compile problems with ghc-5.0
* Gérard Milmeister <[EMAIL PROTECTED]> [2001-05-12T13:28+0200]: > I use Redhat 6.2. > The binary install is ok, but when I compile ghc-5.0 from source > using ghc-5.0, I get the following error after 'make all': > > ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc > ../../../ghc/utils/hsc2hs/hsc2hs-inplace: > /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin: > No such file or directory > > Furthermore, most available libraries seem to be uncompilable > with ghc-5.0, e.g. c2hs and gtk2hs. For c2hs I provided a patch for configure, which made it think it's dealing with ghc-4.11. I don't have it at hand, but you can ask Manuel Chakravarty. AFAIK, he already updated the c2hs CVS repo and provided a Real Solution(tm). Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 "I WILL NOT SELL MIRACLE CURES" -- Bart Simpson in 9F16 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)]
* Marc van Dongen <[EMAIL PROTECTED]> [2001-05-11T10:52+0100]: > Manuel M. T. Chakravarty ([EMAIL PROTECTED]) wrote: > > [received message twice] > > Am I just the only one or does everybody receive > messages posted to [EMAIL PROTECTED] and > [EMAIL PROTECTED] twice? I find > it a bit (I know I am exaggerating) annoying. > Is there a way to avoid this? Use procmail to eliminate dups... .procmailrc: :0 Whc: msgid.lock | formail -D 8192 msgid.cache :0 a: duplicates More info: man procmail procmailex procmailrc Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 But... but There's no BLINK tag in LaTeX! -- seen on /. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The (Interactive) Glasgow Haskell Compiler -- version 5.00
On Sun, Apr 22, 2001 at 16:44:54 +0200, Michael Weber wrote: > > The (Interactive) Glasgow Haskell Compiler -- version 5.00 > > > > > > We are pleased to announce a new major release of the Glasgow Haskell > > Compiler (GHC), version 5.00. The source distribution is freely > > available via the World-Wide Web and through anon. FTP, under a > > BSD-style license. See below for download details. Pre-built > > packages for Linux, FreeBSD, Solaris and Win32 are also available. > [...] > Debian packages for GHC 5.00 are available for some days now in the > 'unstable' distribution. They should have hit the mirrors already, so > please choose the nearest one. More info on that below. [...] > Availability > [...] > As a consequence, GHC is built against the latest libraries in > 'unstable', including libc6 (>= 2.2.2-2). I am sorry, but at the > moment I cannot make any promises about when packages for 'stable' > (aka potato) will be available. Ok, big thanks to Kevin Glynn, who provided me with a Debian potato machine and allowed me to burn quite some CPU cycles [Hi Kevin! =)]. There are now updated packages for ghc4, ghc5 and happy for POTATO available (libc6 >= 2.1.2). So, basically, potato (aka current 'stable') users need not upgrade to 'testing' or 'unstable' to get a running GHC 5.00 (or GHCi). The packages are available at my APT store (see below), but NOT from Debian directly. IMPORTANT NOTE: === These packages depend on libgmp3, just like the packages in 'unstable', so you need the libgmp3(-dev) packages. Since they are not available for potato, I recompiled them and made them available, too. To make things even more complicated, libgmp3 does not play well with the libgmp2 provided by potato, so I rebuild new libgmp2 packages, too. I did my best to nevertheless provide a smooth upgrade path to the woody or sid distributions, so this should not lead to any problems at all. If there is something, that does not work, please let me know ASAP. However, for APT users this should be quite unimportant, since APT should pull in the necessary stuff on it's own. If not, again please let me know. You can also try to upgrade libgmp2 first, then install libgmp3(-dev), and then the GHC suite. In any case, please let me know about any trouble you experienced. APT lines: deb http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian potato/ deb-src http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian potato/ Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
make maintainer-clean (was: Re: The (Interactive) Glasgow Haskell Compiler -- version 5.00)
On Mon, Apr 23, 2001 at 15:00:08 +0100, Simon Marlow wrote: > > Mon, 16 Apr 2001 00:15:39 +1000, Manuel M. T. Chakravarty > > <[EMAIL PROTECTED]> pisze: > > > > > The source tar ball misses the configure scripts (it has the > > > `configure.in's, but the source tar ball should be > > > autoconf'ed, shouldn't it?) > > > > BTW, IMHO 'make maintainer-clean' should not delete configure scripts > > (comments say that it doesn't, but it does). > > I dunno. 'make distclean' leaves the configure scripts in place, 'make > maintainer-clean' is supposed to get you back to a pristine tree as it > would be if it were just checked out from CVS. erm, not that I say, sticking to the standards is mandatory, but... ;) $ info standards 'Managing Releases' 'Makefile Conventions' 'Standard Targets' [...] The reason we say "almost everything" is that running the command `make maintainer-clean' should not delete `configure' even if `configure' can be remade using a rule in the Makefile. More generally, `make maintainer-clean' should not delete anything that needs to exist in order to run `configure' and then begin to build the program. This is the only exception; `maintainer-clean' should delete everything else that can be rebuilt. [...] There should be an additional target, e.g. "make cvs-clean", or similar. Cheers, Michael -- /~\ ASCII ribbon | "I would rather spend 10 hours reading someone else's \ / campaign | source code than 10 minutes listening to Musak waiting X against | for technical support which isn't." / \ HTML mail| -- Dr. Greg Wettstein, Roger Maris Cancer Center ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The (Interactive) Glasgow Haskell Compiler -- version 5.00
> The (Interactive) Glasgow Haskell Compiler -- version 5.00 > > > We are pleased to announce a new major release of the Glasgow Haskell > Compiler (GHC), version 5.00. The source distribution is freely > available via the World-Wide Web and through anon. FTP, under a > BSD-style license. See below for download details. Pre-built > packages for Linux, FreeBSD, Solaris and Win32 are also available. [...] Debian packages for GHC 5.00 are available for some days now in the 'unstable' distribution. They should have hit the mirrors already, so please choose the nearest one. More info on that below. Important Changes/Notes === * It is possible now to install the new packages of ghc4 and ghc5 simultaneously. The system-wide default (/usr/bin/ghc) can be chosen via the 'alternatives' system. For more info on that, refer to the according docs[1]. * The ghc[45] and related packages are now dependent on libgmp3(-dev) instead of libgmp2(-dev). This is due to some forthcoming changes in Debian and because libgmp2 isn't maintained upstream for some time now. * Also, there are new packages for happy and c2hs available. happy is the latest CVS version, since 1.9 didn't play with ghc5 well. It should work with both ghc4 and ghc5 now. c2hs is compiled for ghc5, so it won't work with ghc4. If you are still dependent on ghc4&c2hs, you may want to recompile it yourself[2] and mark it as 'hold'. * As usual, the packages come with all sorts of documentation. They're viewable via the 'doc-base' infrastructure at http://localhost/doc/HTML/ (provided the 'dhelp' package and the usual WWW tools are installed) Along with other formats like PostScript/DVI, the HTML documentation also is browseable at: /usr/share/doc/ghc*/* [1] man update-alternatives [2] 1) make ghc4 the default compiler 2) install all build dependencies (with apt-get >= 0.5.3, you can achieve this with: ``apt-get build-dep c2hs'') 3) build the source: ``apt-get source --compile c2hs''. That should download the c2hs sources and produce packages suited for use with ghc4. Availability Currently, the latest packages on the Debian servers are for 'unstable' (aka sid). They will hit the 'testing' distribution (aka woody) in about 10 days, provided no critical bugs pop up during that period. As a consequence, GHC is built against the latest libraries in 'unstable', including libc6 (>= 2.2.2-2). I am sorry, but at the moment I cannot make any promises about when packages for 'stable' (aka potato) will be available. However, a complete list of all mirrors is available from: http://www.debian.org/misc/README.mirrors You can use the package `netselect'[3] to determine the fastest of a list of servers. [3] http://packages.debian.org/stable/net/netselect.html APT lines: deb http://ftp.debian.org/debian/ unstable main contrib deb-src http://ftp.debian.org/debian/ unstable main contrib WWW: http://packages.debian.org/unstable/devel/ghc4.html http://packages.debian.org/unstable/devel/ghc5.html http://packages.debian.org/unstable/devel/happy.html http://packages.debian.org/unstable/devel/c2hs.html Name Version Description -- ghc4 4.08.1-5 GHC - the Glasgow Haskell Compilation system ghc4-doc 4.08.1-5 Documentation for GHC - the Glasgow Haskell Compilation system ghc4-libsrc 4.08.1-5 Library Sources of GHC - the Glasgow Haskell Compilation system ghc4-prof4.08.1-5 Profiling Libs for GHC - the Glasgow Haskell Compilation system ghc5 5.00-1 GHC - the Glasgow Haskell Compilation system ghc5-doc 5.00-1 Documentation for GHC - the Glasgow Haskell Compilation system ghc5-libsrc 5.00-1 Library Sources of GHC - the Glasgow Haskell Compilation system ghc5-prof5.00-1 Profiling Libs for GHC - the Glasgow Haskell Compilation system c2hs 0.8.2-2 C->Haskell Interface Generator happy1.9+1.10.20010417-1 The Parser generator for Haskell Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to implement timeouts for IO operations?
On Wed, Apr 18, 2001 at 21:36:04 +0200, Johannes Waldmann wrote: > A slightly related point, I was having difficulties with TimeDiff > values - I got negative tdPicosecs sometimes, > and some functions (show) even dumped core. > > Are such problems known (I am using a binary ghc-4.08)? > For the moment, I switched to Posix.EpochTime. > > > I found TimeDiff and ClockTime quite restrictive: > they are not instances of Num, I can't add/subtract/negate TimeDiffs; > and I cannot generate a zero ClockTime. > (In my application, I need to simulate two clocks, > where always one is running, the other one is stopped - > as used in tournament Chess.) Despite my humble try, TimeDiff and ClockTime (Time.lhs) are still b0rked. Use on your own risk (and read the comments at the top). Sorry for that... Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building ghci
On Thu, Apr 12, 2001 at 18:35:23 +0200, Wolfhard Buß wrote: > Hello, > i just built and installed ghc 5.00 from the sources > with the help from ghc 4.08.2. > ghci responds with 'ghc-5.00: not built for interactive use'. just rebuild ghc-5.00 with itself again. Cheers, M/ -- /~\ ASCII ribbon | "Don't worry about people stealing your ideas. If your \ / campaign | ideas are any good, you'll have to ram them down X against | people's throats." / \ HTML mail| -- Howard Aiken ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do I force evaluation?
On Tue, Mar 13, 2001 at 09:40:09 +0200, Matthias Fischmann wrote:
> Yes, that does not look very nice but it should work. In a private
> response, I was also pointed out the alternative solution of using
> case together with `seq` to trigger evaluation, which looked like the
> default way to me (what else is seq for?):
suppose sth. like:
foo someRecord = do
...
foo someRecord{ field = field' }
this may lead to quite some memory allocation (I had this case once,
IIRC), and eventually it can be reduced by using `seq`:
foo someRecord = do
...
let r = someRecord{ field = field' }
r `seq` foo r
>
> | case monstrousDS `seq` True of True -> hPutStr stderr "ok."
*hmm* this just evaluates to WHNF, no?
>From hugs:
Prelude> case (42,error "foo") `seq` True of True -> putStrLn "yow"
yow
> I first tried to wrap this in a `force' function, thereby proving that
> I still haven't grasped the concept entirely. (-:
forceEval x = if x == x then x else x
but this *still* needs a decent equality on `x'... 8->
> But maybe it is possible to make a primitive of this in the same way
> as has been done with assert?
This would definitely help to e.g. keep exceptions inside
`catch'-blocks sometimes (of course at the expense of not being able
to use infinite data structures at the same time there)...
Cheers,
Michael
--
/~\ ASCII ribbon | "I would rather spend 10 hours reading someone else's
\ / campaign | source code than 10 minutes listening to Musak waiting
X against | for technical support which isn't."
/ \ HTML mail| -- Dr. Greg Wettstein, Roger Maris Cancer Center
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Interface Files _ HOWTO?
On Fri, Oct 20, 2000 at 18:09:04 +0200, Ingo Sander wrote: > So, how do I compile this in GHC? I hoped, that it would be enough to > compile all files with the -c option (generating .hi and .o files) and > then compiling Main.hs to get an executable program. Howeve, I get the > following: > >> ghc Main.hs [...] > ld: fatal: Symbol referencing errors. No output written to a.out try $ ghc -c Main.hs $ ghc -o ThisIsMyExecutable *.o That is, compile Main.hs also into an .o file, /then/ link the whole thing into an executable... > So, what's wrong, and am I totally on the wrong track... (I studied the > GHC User Guide, but could not find the answer to my problem). normally, one employs `make' for building programs with more than one module, because it keeps track of dependencies (ghc -M *hs) etc. There is a users-guide section on Makefiles for GHC, IIRC. HTH Cheers, Michael -- /~\ ASCII ribbon | "Never buy anything that mentions Windows on the package. \ / campaign | Except sheets of glass. Or plastic. And that smelly X against | blue stuff that removes dirt without leaving a residue." / \ HTML mail| -- jhicklepgh.nauticom.net in c.o.l.d.s. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: shared libgmp2 (was: Re: GHC RPMs for RedHat 7)
On Thu, Oct 19, 2000 at 17:39:54 +0200, Michael Weber wrote: > On Thu, Oct 19, 2000 at 17:24:04 +0200, George Russell wrote: >> On this subject, where am I to get the libgmp2.a required by 4.08.1 >> (on Linux anyway). I tried compiling the very latest version of GMP >> but it only produced a libgmp.a file. Is that the same? [snipped my right solution to the wrong problem] I can't read, shoot me 8-} My internal pre-parser recognized the words "GHC", "libgmp.a" and "RedHat" in a single email, therefore bypassed the rest of the mail, and immediately sent the wrong answer... Sorry! The patch is obviously for getting a .so library... Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 The reason computer chips are so small is computers don't eat much. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
shared libgmp2 (was: Re: GHC RPMs for RedHat 7)
On Thu, Oct 19, 2000 at 17:24:04 +0200, George Russell wrote: > On this subject, where am I to get the libgmp2.a required by 4.08.1 > (on Linux anyway). I tried compiling the very latest version of GMP > but it only produced a libgmp.a file. Is that the same? Everyone and their brothers is patching it. I've no idea, why upstream didn't incorporate the patch... Maybe, they have done it in the new version (libgmp3)... Anyway, I attached a patch for libgmp2-2.0.2, ie. the old version... Cheers, Michael -- /~\ ASCII ribbon | beta test, v: To voluntarily entrust one's data, one's \ / campaign | livelihood and one's sanity to hardware or software X against | intended to destroy all three. In earlier days, / \ HTML mail| virgins were often selected to beta test volcanos. diff -ur -x Makefile gmp-2.0.2-orig/Makefile.in gmp-2.0.2/Makefile.in --- gmp-2.0.2-orig/Makefile.in Thu Jun 6 19:21:19 1996 +++ gmp-2.0.2/Makefile.in Sat May 23 15:55:11 1998 @@ -27,10 +27,13 @@ infodir = $(prefix)/info includedir = $(prefix)/include +MV = mv CC = gcc LOCAL_CC = $(CC) CFLAGS = -g -O XCFLAGS = +PICFLAGS = -fPIC + AR = ar AR_FLAGS = rc RANLIB_TEST = [ -f /usr/bin/ranlib -o -f /bin/ranlib ] @@ -51,19 +54,23 @@ extract-double.c insert-double.c OBJS = memory.o mp_set_fns.o mp_clz_tab.o version.o stack-alloc.o mp_bpl.o \ extract-double.o insert-double.o +SHOBJS = $(foreach OBJECT, $(OBJS), shared/$(OBJECT)) FILES = gmp.h mp.h gmp-impl.h longlong.h urandom.h move-if-change \ mkinstalldirs INSTALL COPYING.LIB ChangeLog Makefile.in \ NEWS README SPEED TODO config.guess config.sub configure configure.in \ gmp.info* gmp.texi texinfo.tex $(SRCS) INCLUDES = -I. -Impn -I$(srcdir) -FLAGS_TO_PASS = "CC=$(CC)" "CFLAGS=$(CFLAGS)" "XCFLAGS=$(XCFLAGS)" +FLAGS_TO_PASS = "CC=$(CC)" "CFLAGS=$(CFLAGS)" "XCFLAGS=$(XCFLAGS)" +"PICFLAGS=$(PICFLAGS)" "MV=$(MV)" -all: libgmp.a +all: libgmp.a libgmp.so .c.o: $(CC) -c $(INCLUDES) $(CFLAGS) $(XCFLAGS) $< +%.o : ../%.c + $(CC) -c $(INCLUDES) $(CFLAGS) $(XCFLAGS) $(PICFLAGS) $< -o $@ + libgmp.a: mpn/libmpn.a mpz/libmpz.a mpf/libmpf.a mpq/libmpq.a $(OBJS) rm -rf tmpdir mkdir tmpdir @@ -78,6 +85,22 @@ mv tmpdir/$@ . rm -rf tmpdir +shared: + mkdir shared + +libgmp.so: shared mpn/shared mpz/shared mpf/shared mpq/shared $(SHOBJS) + rm -rf tmpdir + mkdir tmpdir + for i in mpn mpz mpf mpq; \ + do \ + mkdir tmpdir/$$i; \ + cp -p $$i/shared/* tmpdir/$$i; \ + done + cp -p shared/* tmpdir/ + cd tmpdir; $(CC) -shared -Wl,-soname,libgmp.so.2 -o libgmp.so.2.0.2 *.o */*.o + mv tmpdir/libgmp.so.2.0.2 .;ln -s libgmp.so.2.0.2 libgmp.so + rm -rf tmpdir + libmp.a: mpn/libmpn.a mpbsd/libmpbsd.a $(OBJS) rm -rf tmpdir mkdir tmpdir @@ -103,6 +126,15 @@ mpbsd/libmpbsd.a: force cd mpbsd; $(MAKE) $(FLAGS_TO_PASS) libmpbsd.a +mpn/shared: force + cd mpn; $(MAKE) $(FLAGS_TO_PASS) libmpn.so +mpz/shared: force + cd mpz; $(MAKE) $(FLAGS_TO_PASS) libmpz.so +mpf/shared: force + cd mpf; $(MAKE) $(FLAGS_TO_PASS) libmpf.so +mpq/shared: force + cd mpq; $(MAKE) $(FLAGS_TO_PASS) libmpq.so + check: libgmp.a cd mpz/tests; $(MAKE) $(FLAGS_TO_PASS) check cd mpq/tests; $(MAKE) $(FLAGS_TO_PASS) check @@ -142,6 +174,10 @@ -chmod a-x $(libdir)/libgmp.a $(INSTALL_DATA) $(srcdir)/gmp.h $(includedir)/gmp.h -chmod a-x $(includedir)/gmp.h + $(INSTALL_DATA) libgmp.so.2.0.2 $(libdir)/libgmp.so.2.0.2 + cd $(libdir);rm -f libgmp.so libgmp.so.2 libgmp.so.2.0 + cd $(libdir);ln -s libgmp.so.2.0.2 libgmp.so.2 + cd $(libdir);ln -s libgmp.so.2 libgmp.so install-bsdmp: installdirs libmp.a gmp.info install-info-files $(INSTALL_DATA) libmp.a $(libdir)/libmp.a -chmod a-x $(libdir)/libmp.a @@ -152,9 +188,10 @@ do $(INSTALL_DATA) $$f $(infodir)/$$f; done -chmod a-x $(infodir)/gmp.info* # Attempt to edit the info directory node - if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \ - install-info --dir-file=$(infodir)/dir $(infodir)/gmp.info; \ - else true; fi +# Do this from the rpm spec file. +# if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \ +#install-info --dir-file=$(infodir)/dir $(infodir)/gmp.info; \ +#else true; fi installdirs: $(srcdir)/mkinstalldirs $(srcdir)/mkinstalldirs $(includedir) $(libdir) $(infodir) @@ -168,6 +205,7 @@ clean mostlyclean: rm -f *.o libgmp.a libmp.a gmp.dvi gmp.ps tmp.* tmp-* + rm -rf shared libgmp.so.2.0.2 libgmp.so rm -f gmp.?? gmp.??s gmp.log gmp.toc gmp.*aux gmp*.html -cd mpn; $(MAKE) $@ -cd mpz; $(MAKE) $@ diff -ur -x Makefile gmp-2.0.2-orig/mpf/Makefile.in gmp-2.0.2/mpf/Makefile.in --- gmp-2.0.2-orig/mpf/Makefile.in Fri May 24 14:29:16 1996 +++ gmp-2.0.
Re: hslibs / posix library features??
On Tue, Sep 19, 2000 at 10:04:55 -0700, Sigbjorn Finne wrote: > POSIX.1 only defines #defined constants upto B38400, so anything > beyond that is non-standard [...] ... which does not necessarily imply, that GHC is not going to support it ;-) Marcus Shawcroft wrote: >> Can these missing rates be added to hslib without breaking other >> platforms? patch attached... the non-standard baud rates are added, and a function ``isBaudRateSupported'' for testing, whether they are supported... NOTE: For now, I'm not going to apply the patch to the CVS tree... There are several reasons for it: * at first, as Sigbjorn pointed out, they are not covered by POSIX.1 and therefore this DOES become a policy issue... I'd like to hear the opinion of The GHC Team (which is at ICFP currently, AFAIK)... * The Posix* modules are said to be rewritten once the new FFI has settled enough, so I don't want to spent too much time on them now... * I added instances (Enum, Bounded, Eq) to BaudRate. Sure, I could do without them, but they're nevertheless useful... but this is an incompatible change, it *might* break existing code... BTW: Is there any particular reason, why the other Posix* data types lack these instances? At least Eq should be supported, IMHO... Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 "I WILL NOT BURY THE NEW KID" -- Bart Simpson in 9F03 --- /home/michaelw/.backup/PosixTTY.lhs!!!mnt!sda5!src!devel!ghc4!ghc-current!hslibs!posix!.~1~ Mon Apr 10 17:19:42 2000 +++ hslibs/posix/PosixTTY.lhs Tue Sep 19 23:00:50 2000 @@ -35,12 +35,14 @@ withOutputSpeed, withTime, withoutCC, -withoutMode +withoutMode, +isBaudRateSupported ) where import GlaExts import IOExts ( unsafePerformIO ) +import Maybe (fromMaybe) import IO import PosixUtil @@ -284,6 +286,23 @@ | B9600 | B19200 | B38400 + | B57600 + | B115200 + | B230400 + | B460800 + | B50 + | B576000 + | B921600 + | B100 + | B1152000 + | B150 + | B200 + | B250 + | B300 + | B350 + | B400 +deriving (Enum,Bounded,Eq) + inputSpeed :: TerminalAttributes -> BaudRate inputSpeed termios = unsafePerformIO $ do @@ -406,45 +425,53 @@ -- Convert Haskell BaudRate to unsigned integral type (Word) baud2Word :: BaudRate -> Word -baud2Word B0 = ``B0'' -baud2Word B50 = ``B50'' -baud2Word B75 = ``B75'' -baud2Word B110 = ``B110'' -baud2Word B134 = ``B134'' -baud2Word B150 = ``B150'' -baud2Word B200 = ``B200'' -baud2Word B300 = ``B300'' -baud2Word B600 = ``B600'' -baud2Word B1200 = ``B1200'' -baud2Word B1800 = ``B1800'' -baud2Word B2400 = ``B2400'' -baud2Word B4800 = ``B4800'' -baud2Word B9600 = ``B9600'' -baud2Word B19200 = ``B19200'' -baud2Word B38400 = ``B38400'' +baud2Word B0 = ``B0'' +baud2Word B50 = ``B50'' +baud2Word B75 = ``B75'' +baud2Word B110 = ``B110'' +baud2Word B134 = ``B134'' +baud2Word B150 = ``B150'' +baud2Word B200 = ``B200'' +baud2Word B300 = ``B300'' +baud2Word B600 = ``B600'' +baud2Word B1200= ``B1200'' +baud2Word B1800= ``B1800'' +baud2Word B2400= ``B2400'' +baud2Word B4800= ``B4800'' +baud2Word B9600= ``B9600'' +baud2Word B19200 = ``B19200'' +baud2Word B38400 = ``B38400'' +baud2Word B57600 = ``B57600'' +baud2Word B115200 = ``B115200'' +baud2Word B230400 = ``B230400'' +baud2Word B460800 = ``B460800'' +baud2Word B50 = ``B50'' +baud2Word B576000 = ``B576000'' +baud2Word B921600 = ``B921600'' +baud2Word B100 = ``B100'' +baud2Word B1152000 = ``B1152000'' +baud2Word B150 = ``B150'' +baud2Word B200 = ``B200'' +baud2Word B250 = ``B250'' +baud2Word B300 = ``B300'' +baud2Word B350 = ``B350'' +baud2Word B400 = ``B400'' -- And convert a word back to a baud rate --- We really need some cpp macros here. word2Baud :: Word -> BaudRate -word2Baud x = -if x == ``B0'' then B0 -else if x == ``B50'' then B50 -else if x == ``B75'' then B75 -else if x == ``B110'' then B110 -else if x == ``B134'' then B134 -else if x == ``B150'' then B150 -else if x == ``B200'' then B200 -else if x == ``B300'' then B300 -else if x == ``B600'' then B600 -else if x == ``B1200'' then B1200 -else if x == ``B1800'' then B1800 -else if x == ``B2400'' then B2400 -else if x == ``B4800'' then B4800 -else if x == ``B9600'' then B9600 -else if x == ``B19200'' then B19200 -else if x == ``B38400'' then B38400 -else error "unknown baud rate" +word2Baud x = fromMaybe (error "unknown baud r
Re: Installing GHC from source only
On Wed, Sep 13, 2000 at 10:37:42 +0100, Malcolm Wallace wrote: [shameless nhc98 advertising :-)] > It can also be very easily bootstrapped on a new machine via C. Well... Did you try it on the Alpha processor? :-) Lesson #1: sizeof(unsigned int) != sizeof(void*) Cheers, Michael -- /~\ ASCII ribbon | "... I had a girlfriend there." - "I see, that makes \ / campaign | everything complex." - "Yes, it goes from LOGSPACE X against | to EXPTIME." - "What happened? You started talking like / \ HTML mail| this and she dumped you?" -- M. Lange and R. Vestergaard
Re: Buildung documentation on FreeBSD
On Sat, Sep 09, 2000 at 10:23:31 +0200, Volker Stolz wrote: > When configuring a recent ghc, ./configure complains about not finding > DOCBOOK - which is no wonder as it keeps looking in strange hardcoded > places like /usr/lib. Could someone please enlighten me about what changes > would be necessary? I have [open]jade and the different flavours of docbook > installed. Hi! the check is done at /configure.in:510: dnl ** check for jade/openjade & determine a working catalog AC_PATH_PROGS(JadeCmd,openjade jade,jade) FPTOOLS_DOCBOOK_CATALOG(Catalog, $JadeCmd, docs/fptools-both.dsl, /etc/sgml.catalog ... if test -z "$Catalog"; then AC_MSG_RESULT([Warning: You will not be able to build the documentation.]) fi To make autoconf find the [open]jade executable, it should be sufficient to have it in your PATH, so I guess the catalog is not found. Try adding the path to your catalog in the FPTOOLS_DOCBOOK_CATALOG() macro call (right before "/etc/sgml.catalog", space-separated). If this doesn't work, I guess your docbook setup is hosed... (BTW: the actual macro implementation is at aclocal.m4:723). Please report back, whether it works and what you had to change... Cheers, Michael -- /~\ ASCII ribbon | "EG at the moment ghc -fwarn-martian-invasions doesn't \ / campaign | complain, and I think it should. (Unless ghc is rather X against | cleverer than I thought . . .)" / \ HTML mail| -- gerinformatik.uni-bremen.de on [EMAIL PROTECTED]
Re: Compiler error: AClass
On Mon, Jul 31, 2000 at 12:23:19 -0400, Kirsten R. Chevalier wrote:
> Hi,
> I'm trying to compile a program using GHC 4.08 on a Linux system, and I'm
> getting an error simply consisting of "AClass", with no output files from
> the compiler. When I compile with -v, I get the following output:
>
> The Glorious Glasgow Haskell Compilation System, version 4.08
[compiler yada yada]
> The code that seems to be causing the problem is this:
>
> class MonadT t where
>lift :: Monad m => m a -> t m a
>liftInside :: (Monad m, MonadT t2) => t m a -> t (t2 m) a
>
> Any advice? Thanks in advance,
> kirsten
This has been reported before. It's a bug, that's fixed in CVS and the
upcoming 4.08.1. See the ghc-bugs archives ("What is
`AClass'?"-thread) for more...
Cheers,
Michael
--
/~\ ASCII ribbon | "The sendmail configuration file is one of those files
\ / campaign | that looks like someone beat their head on the keyboard.
X against | After working with it... I can see why!"
/ \ HTML mail| -- Harry Skelton
Re: Installing on Red Hat Linux
> "Bill Halchin" <[EMAIL PROTECTED]> wrote, >> [...] I think it was "gpm". [...] ~~~ On Sat, Jul 29, 2000 at 20:44:19 +1000, Manuel M . T . Chakravarty wrote: > The painless approch is to install the gpm package that ghc ~~~ > asks for. In fact, I would assume that the `gpm' rpm is ~~~ GPM is the `General Purpose Mouse', while GMP is `GNU Math Precision' and GHC obviously needs the latter one... (plus, as Manuel already pointed out, the gmp-devel package on Redhat). Just to clarify things a bit... Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton
Re: GHC 4.08 on Alpha Linux
On Fri, Jul 28, 2000 at 05:53:35 -0400, Alexander Williams wrote: > I'm running SuSE Linux 6.4 on an Alpha 3000 (no laughing, its the > office), and I was wondering if anyone'd come up with a good method > of compiling GHC from ... well, scratch? HC files will be mostly > useless, compiled as they are for the x86. About a year ago, I tried it on my Alpha, but 1) it was a half-baked try... =) 2) GHC has IIRC never been running on Alpha/Linux GHC once run on Alpha/OSF, so you might try bootstrapping ghc-2.10 on Linux/Alpha first. From my mental cache, in current GHCs (at least with 4.03, which I tried IIRC), there are quite some #ifdef's broken for 8 byte long's, maybe the asm-mangler needs some attention to work with the GNU toolchain for Alpha, etc... In short: many hours of fun... =) As a starting point, I'd try to run configure on the Alpha (maybe you need to adjust some things), copy the configure stuff into a x86 tree, re-running config.status and then generating HC files, which can be copied back to the Alpha tree... Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: ANNOUNCEMENT: hMPI [HaskellMPI] 0.9.0 available
On Thu, Jul 20, 2000 at 21:08:21 -0400, Benjamin Leon Russell wrote:
> Do you have any plans on making a Windows 9x/NT/2000-compatible
> version anytime soon?
Well, unfortunately, I don't have access to a Windoze box with a GHC
installed[1], so I just had no chance of testing it. Therefore, I
didn't advertise it as being Windows compatible. However, in theory,
it _should_ work, since hMPI doesn't use anything *nix-special, IMO.
If you do have the resources, it would be very kind, if you could test
it on Windows and give me some feedback about the results. If there
are changes necessary to make it Windows compatible, I'll try my best
to incorporate them.
[1] we've got Linux/{i386,alpha}, Solaris/SPARC, xBSD, etc. but
Windows only on the secretary's computer, and they'll beat me up,
if I dare to install GHC on it and develop software there ;-)
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
Never promise to complete any project within six months of the end of
the year -- in either direction.
ANNOUNCEMENT: hMPI [HaskellMPI] 0.9.0 available
[Xposted to ghc-users & haskell mailing lists] Hi! I'd like to announce (finally!) the first OFFICIAL PRE-release :) of hMPI, a Haskell binding for a message passing interface conforming to the MPI 1.1/1.2 standard. It's available from http://www-i2.informatik.rwth-aachen.de/Software/Haskell/libs/hmpi-0.9.0.tar.gz or http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ (click on the "Haskell libraries" section) hMPI is an acronym for HaskellMPI. It enables programmers to write distributed Haskell applications which run on a cluster of workstations, with taking full advantage of all MPI features (like fast communication interfaces, different cluster topologies, etc.), and of course all the neat Haskell stuff (e.g. type safety, , ...) The license is LGPL-2.1 . hMPI is compatible with LAM and MPICH, but by far not all functions are implemented. However, basic MPI needs 6 functions and currently there are about 50 functions available (not all are tested thoroughly). Others will be supported in future releases. Installation should be fairly easy (undoubtedly, someone will prove me wrong... :-p), since the package is AUTOMAKE'ed and AUTOCONF'ed, and should detect Haskell compiler, MPI C libraries, flags, headers, available MPI functions etc automatically [if not, it's a bug, so please report it] There are three interfaces, which permit access to MPI from Haskell: * [MPI_CCalls.hs] the raw C function call interface (you DON'T want this one...) * [MPI.hs] everything marshalled into nice Haskell datatypes, except that you are still able to fiddle with memory chunks when sending/receiving data. Reasons to choose this interface are efficiency (although you pay with less safety) and that you have a completely different idea of data marshalling than I have ;) ... * [HaskellMPI.hs] (nearly) full support for basic Haskell types like Chars, Ints, Floats, Doubles, and lists of them. You don't have to worry about memory allocation, even for immediate (== non-blocking) send and receive requests. There is also a marshalling interface to provide your own datatypes (however, there are only few helper functions available, currently). More powerful communication abstractions will follow very likely in a future release. Currently, documentation is nearly non-existant, so you should be somewhat familiar with MPI. I tried to model the binding as close as possible (and useful) to C interface. Otherwise, `fptags' and `M-x grep' are your friends... ;) There are also some example programs included (mostly tiny tests, and a distributed mandelbrot thingy). Help and comments welcome, as usual. This library is an open-source, free-software project, so Free Software Rule #1 applies here: contribute nothing, expect nothing... ;) - Changes since the previous (inofficial) release: * removed ALL occurrences of `litlit's. They've always been an ugly hack and caused quite some trouble (with -O2, for example). Now, the binding should be quite portable to other Haskell compilers (modulo some GHC extensions) * MPE was nuked for now (it may be resurrected in the future, however) * EasyMPI nuked, for now (I have some other ideas, which I have to sort out a bit first) * TerminationCheck nuked, will be reimplemented in near future * `Intracomm' has been renamed to `Comm' -- Prerequesites Architecture: i386-linux, sun-sparc-solaris2 Build-Depends: mpich (>= 1.1.2) | lam, ghc4 (>= 4.08), make (>= 3.77), autoconf (>= 2.12) lam: LAM (http://www.mpi.nd.edu/lam/) is a freely available implementation of the MPI (Message Passing Interface) standard for Linux. I highly recommend it in favour of MPICH! mpich: MPICH is a freely available, portable implementation of the MPI (Message Passing Interface) standard (http://www-unix.mcs.anl.gov/mpi/). It can be found at http://www.mcs.anl.gov/mpi/mpich/. I tested with MPICH 1.1.2 (Solaris2, Linux) and MPICH 1.2.0 (Linux). Note, that I found some bugs and non-compliances to the MPI standard at least in MPICH <= 1.2.0. ghc4: You need the Glasgow Haskell Compiler GHC (version 4.08 or above, tested with 4.08). Since the hMPI binding uses quite some GHC extensions (FFI interface, ...), I'm afraid, you are stuck with it. However, if you manage to get it compiled with some other Haskell compiler (nhc98 is THE candidate), I'd like to hear about that. make: Because of some really nice makefile features (includes, make variables, conditions), you need GNU make (tested with 3.78.1) autoconf: tested with 2.13 -- Cheers, Michael -- /~\ ASCII ribbon | "The sendmail configuration file is one of those files \ / campaign | that looks like someone beat their head on the keyboard. X against | After working with it...
Re: What is `AClass'?
On Sun, Jul 16, 2000 at 16:49:35 -0700, Martin Pokorny wrote:
> Hi all,
>
> I'm a beginner to functional programming and Haskell, so please bear
> with me. I am working on some numerical programming routines, and I
> ran into a small problem trying to compile a module of mine. I'm using
> ghc version 4.08.0, which I downloaded from Michael Weber's web site
> for my Debian Gnu/Linux system. The compilation stops before producing
> an object file and prints out `AClass', with no further output. Is
> there something else I can do to get more information regarding this
> failure (besides the -v option, which I tried to no avail)? Or should
> I just try to isolate this problem and post the code to this list for
> further help?
[Cc & F'up to [EMAIL PROTECTED] set]
Hi!
can you please send the source which produced the fault? If possible,
try to narrow it as much as you can...
Marcin reported a fault with AClass before, it looked like this:
module Test where
class Lookup c k a where
lookupAll :: Sequence seq a => c -> k -> seq a
class Lookup (s a) Int a => Sequence s a where
foo :: s a
panic! (the `impossible' happened):
AClass .Test.Sequence{-r8,x-}
Did the compiler output look similar? Or was it really just `AClass'?
Cheers,
Michael
--
/~\ ASCII ribbon | "i have decided to release the first 24GB of my genetic
\ / campaign | code under the Artistic License. since this is DFSG
X against | compatible, could it go in main?"
/ \ HTML mail| -- debian-devel <[EMAIL PROTECTED]>
Re: [ANNOUNCE] GHC 4.08 released
On Thu, Jul 06, 2000 at 14:38:47 +0100, Reuben Thomas wrote: >The Glasgow Haskell Compiler -- version 4.08 > == > > We are pleased to announce a new release of the Glasgow Haskell > Compiler (GHC), version 4.08. The source distribution is freely > available via the World-Wide Web and through anon. FTP; details below. Might I add, that I've just today uploaded new Debian versions of Happy (1.7-1) and GHC (4.08.0-1), See http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ for details. As usual, the packages come with full documentation, profiling libs, etc. Furthermore, they are APT-able by adding the following lines to /etc/apt/sources.list on your Debian system: - deb http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian unstable/ deb-src http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian unstable/ - Cheers, Michael -- /~\ ASCII ribbon | "If builders built buildings the way programmers wrote \ / campaign | programs, then the first woodpecker that came along X against | would destroy civilization." / \ HTML mail| -- Gerald Weinberg
numericEnumFromThenTo strangeness
Hi!
I'm slightly puzzled about the definition of list enumerations in
GHC (and possibly other Haskell implementations)...
Example:
``[0, 2 .. 9] :: [Int]''
==> [0, 2, 4, 6, 8]
Quite what one expects, right?
Now consider the case for Floats and friends:
``[0.0, 2 .. 9] :: [Float]''
==> [0.0, 2.0, 4.0, 6.0, 8.0, 10.0]
*eh?* The latter list comprehension is IIRC translated into
``numericEnumFromThenTo 0.0 2.0 9.0'', which in turn is (in current
GHC's) defined as:
\begin{code}
numericEnumFromThenTo :: (Ord a, Fractional a) => a -> a -> a -> [a]
numericEnumFromThenTo e1 e2 e3 =
takeWhile pred (numericEnumFromThen e1 e2)
where
mid = (e2 - e1) / 2
pred | e2 > e1 = (<= e3 + mid)
| otherwise = (>= e3 + mid)
\end{code}
IMHO, it's a bit counterintuitive, isn't it? To me, e3 is considered
as upper bound and NONE of the elements of the resulting list should
be GREATER than this bound (except for rounding errors, which might
not be so easy to catch).
Nevertheless, this behaviour is defined by the Haskell98 standard!
(See ~ #3.10)
Can somebody please point me to the rationale behind the design
decision? Undoubtedly there is one, but I don't seem to be able to
find it... ?:-}
Cheers,
Michael
p.s.: feel free to redirect this message to a more appropriate list,
but then please keep me in the CC field. Thanks!
--
/~\ ASCII ribbon | Compaq Safety & Comfort Guide:
\ / campaign | "Stand up and take a few minutes to stretch and
X against | exercise several times a day."
/ \ HTML mail|
Re: GHC Version numbers (was: RE: 4.07 release candidate snapshot ava ilable)
On Mon, Jun 19, 2000 at 04:38:21 -0700, Simon Marlow wrote: > > Ok, here's my proposal for the version numbering issue. I think we should > bite the bullet and fix the numbering scheme to something sensible now, even > though it means changing version 4.07 to be called 4.08. Any objections? Cool, I'm seeing light at the end of the tunnel... (hopefully, it's not a train... :-)) > Stable releases are named > > x.yy.z > > where yy is even, z is the patchlevel (omitted if zero). Is there a reason, why omitting z if zero? Making the version number *always* a triple "x.yy.z" is a) more consistent, b) easier to parse (you can rely on having three dot-separated fields and c) additionally a good break, since version numbers up to now are only pairs like "x.yy", so you can just say "Oh, version is not a triple, so it must be a GHC from The Dark Ages(tm)" and continue accordingly. > patchlevel changes are *strictly bug-fix only*, so we > don't bump the __GLASGOW_HASKELL__ version. No change > to the policy here, except that we've screwed up a couple > of times in the past :) Patchlevels don't break binary > compatibility, i.e. you can upgrade your compiler a > patchlevel without breaking anything. Agreed. > Unstable versions are named > > x.yy.preMMDD well, I've no _really_ strong arguments against it, but is there any good reason I've missed for having anything but numbers (and the dot for separation) in a version? It's perfectly sufficient, and I've always wondered, why people did sth. like the above... (Remember, now an even middle number is indicator for a stable version, so _that_ particular argument is void now). BTW: if version numbers should contain alphabet chars, they'd be called "version alphanumerics", right? ;-) [agreeing with rest of proposal] Oh, and might I bring the switch `--numeric-version' (for example, emits just "4.09.2609" on a single line) into scope... Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: Mutable Arrays
On Tue, May 09, 2000 at 11:37:46 +0100, Marc van Dongen wrote: > What does one have to do to use mutable arrays? > An old program won't compile anymore with a very > recent ghc from CVS. I am using GlaExts. $ cvs log ghc/lib/std/PrelArr.lhs revision 1.19 date: 2000/03/14 12:16:00; author: simonmar; state: Exp; lines: +57 -57 Simplfy the mutable array story: - rename MutableArray to STArray (and similarly for all operations on MutableArray, eg newArray is now newSTArray). - remove the extra level of indirection between STArrays and MutableArrays. - remove the MutableArray interface from hslibs/lang/MutableArray. This module will go away soon - Andy, don't bother porting it to Hugs. Cheers, Michael -- Lehrstuhl-Kinderkrippe Michael Weber <[EMAIL PROTECTED]> Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: strangeness with `Exception.tryAll'
On Mon, May 08, 2000 at 07:30:18 -0700, Simon Marlow wrote: > If you embed the (error "BANG") inside a data structure, then it can indeed > excape from the tryAll because seq only evaluates to WHNF. Thanks a bunch, that pointed me in the right direction! > tryAll (runST (return (error "BANG!"))) > > will return (Right (error "BANG!")), because return isn't strict. Nope, main = tryAll (runST (return (error "BANG!"::( >>= print yields `Left "BANG!"'! but main = tryAll (runST ( return ((error "BANG!", 42) :: (Int,Int)) )) >>= print leads to an error (for the reason you mentioned). Maybe someone can add a note about this gotcha in the docs (sec-exception.html#3.8.3)? Cheers, Michael -- Don't worry, honey, just two more lemmas ...
strangeness with `Exception.tryAll'
Hi!
I'm not quite sure, whether this is a bug at all, so maybe someone can
explain this behaviour to me:
Consider the following piece of code:
\begin{code}
import Exception
foo = do
res <- tryAll (someObscureComputationThatThrowsErrors)
putStr "This is immediately printed: "
print res -- here res gets evaluated (which usually takes some time)
-- and the error occurs despite the `tryAll'
someObscureComputationThatThrowsErrors :: (Int,Int)
someObscureComputationThatThrowsErrors = runST $
-- ...
if condition
then return (1,1)
else error "BANG"
main = foo
\end{code}
The above code (i.e., the code, from where this example is derived) lets the
program die with error "BANG" (if condition is False), although there is a
`tryAll' statement, that should catch these errors!
This (mis)behaviour goes away, if I slightly modify the function, like:
\begin{code}
someObscureComputationThatThrowsErrors' :: (Int,Int)
someObscureComputationThatThrowsErrors' =
forceEval someObscureComputationThatThrowsErrors
where
forceEval x = if x == x then x else x
\end{code}
i.e., the error is caught, if I *force the evaluation* inside the `tryAll'
statement, which is what I expected tryAll to do...
BTW: in hslibs/lang/Exception.lhs, `tryAll' is defined with
"tryAll a = ... (a `seq` return (Right a)) ..."
^^^
How is the possible, that the error emerges from the `tryAll' statement?
Is there another possible reason for this behaviour?
(ghc-4.07, CVS version 2000/05/04)
[Sorry, but I was unable to find a small example, that triggers this "bug".
Things like (tryAll (runST (return (error "BANG" work as expected]
Cheers,
Michael
--
Lehrstuhl-Kinderkrippe Michael Weber <[EMAIL PROTECTED]>
Lehrstuhl für Informatik II
RWTH Aachen
WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
ANNOUNCE: new GHC snapshot for Debian available
Hi! After some months of silence, finally I made a snapshot of the weekend's CVS version of GHC for Debian available. As usual, it's compiled with "everything on", including a full set of profiling libs in an additional package. If I recall correctly from a GHC HQ mail, profiling is (at least partly) working now. It's downloadable via: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ and APT-able via: deb http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian unstable/ deb-src http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian unstable/ Cheers, Michael -- Lehrstuhl-Kinderkrippe Michael Weber <[EMAIL PROTECTED]> Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: GHC include files
On Tue, Feb 29, 2000 at 17:06:01 +, Marcin 'Qrczak' Kowalczyk wrote:
> BTW, I see lack of standard way of conveniently installing a Haskell
> library. For example c2hs installs in its own subdirectory and provides a
> script c2hs-config which outputs compiler and linker flags necessary to
> link an application with c2hs libs. OK, but should every package provide
> its own script?
At least, the idea is flexible and those scripts are easily adaptable...
> Putting C headers in a standard place like /usr/include or
> /usr/local/include and C libraries in /usr/lib is convenient.
Not a good idea, if there is more than one version of a software installed
on a system...
> IMHO there should be a flag similar to -syslib which tells the compiler
> and linker to use a package of a given name from such standard
> directory (hoping that there will be no name clashes): search for
> interfaces there and link a library. Not depending on whether it is
> under /usr/lib or /usr/local/lib - packages themselves should not be
> required to separately announce where they reside.
>
> It's possible that a package requires some additional compiler flags when
> it is used.
the "script" solution addresses this problem, too...
(cf. `xxx-config--libs')
> Will ghc change interface format with each version? :-)
This is the biggest problem (and, interestingly, the least addressed :-)).
Especially for binary distribution builders, it's quite inconvenient to
rebuild every GHC-library on the system to match with the latest compiler
version :-(
I thought about a scheme similar to the tex-font generation (if the font is
"compiled" for a particular resolution (dpi), it's re-used; if not, it is
created).
[I'll describe that in another mail...]
On Wed, Mar 01, 2000 at 04:34:43 -0800, Simon Marlow wrote:
> What we need is a way for external library writers to be able to package up
> and distribute a library that will install onto a system with an existing
> GHC such that you can say '-syslib ' to get the new library. This is
> pretty straightforward, we just need to separate out the syslib
> configuration stuff from the driver, and write a (perl?) script to do the
> installation. The script would be part of GHC, and invoked as part of the
> library installation.
This would not address the .hi-file versionitis...
And what, if the library needs additional compiler flags?
On Wed, Mar 01, 2000 at 14:29:41 +0100, Sven Panne wrote:
> Just a few remarks and personal opinions from a RPM builder's view:
>
>* IMHO the whole /usr/local hierarchy is completely obsolete for
> and "real" programs should only be used for quick local hacks.
> => GHC should reside under /usr/{bin,lib,include}
... and the GNU/Hurd people try to obsolete the /usr tree IIRC :-)
... and there is the /opt tree (for big packages) ...
quoting FHS-pre2.1#4.6 "/usr/local : Local hierarchy":
[...]
This directory should always be empty after first installing a FHS-
compliant system. No exceptions to this rule should be made other than
the listed directory stubs.
Locally installed software should be placed within /usr/local rather
than /usr unless it is being installed to replace or upgrade software in
/usr.
[...]
So, /usr/local is perfectly ok for software that is not installed via a
package management system and should be the default for a source dist or
binary-tarballs[2].
[2] a single tarball bindist is _NO_ package management! (Go away,
slackware users! :-))
There is no single solution... that's one of the reasons, why autoconf
exists, right? :-) (Hi Sven, Manuel!) :-))
>> Include files, on the other hand, should really be in
>> /usr/local/include/ghc, so f.e. #include has a chance of
>> working. [...]
I'd favour a scheme, in which ghc can tell me, where the include files
reside: the perl driver already knows about the location, so why not adding
an option: `ghc --print-includedir'?
This would also be the cleanest solution, if there is more than one version
of ghc installed...
Honestly, if a project has more than two source files, I let `make' care
about dependencies etc. and
GHCINCLUDES := $(shell $(HC) --print-includedir)
[...]
%.o: %.hs
$(HC) $(GHCINCLUDES) $(MOREOPTIONS) $< -o $@
is not very complicated, is it?
On Wed, Mar 01, 2000 at 07:59:25 -0800, Simon Marlow wrote:
> In a package system the choice of installation directories is moot, as you
> point out. The only issue is whether several versions are allowed to
> co-exist.
There is also the possibility to have more than one _flavour_ of a specific
version installed, for example ghc-4.06 and ghc-4.06-debugging...
Cheers,
Michael
p.s.: I'm just browsing through my overflowing mail folders, sorry if I
miss some of the messages...
--
Lehrstuhl-Gärtnerei Michael Weber <[EMAIL PROTECTED]>
Lehrstuhl für Informatik II
RWTH Aachen
WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: CONTRIB/pphs
On Thu, Feb 03, 2000 at 10:00:21 -0200, José Romildo Malaquias wrote: >> $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs co fptools/CONTRIB/pphs [...] > I tried exactly that and got > > cvs checkout: in directory fptools: > cvs checkout: cannot open CVS/Entries for reading: No such file or directory > cvs [checkout aborted]: cannot open CVS/Entries.Static: No such file or directory The above line worked for me... Just in case you don't trust me :) [272] michaelw@talos /tmp/ $ date Don Feb 3 12:58:55 CET 2000 [273] michaelw@talos /tmp/ $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs co fptools/CONTRIB/pphs cvs server: Updating fptools/CONTRIB/pphs U fptools/CONTRIB/pphs/README U fptools/CONTRIB/pphs/pphs.c cvs server: Updating fptools/CONTRIB/pphs/docs U fptools/CONTRIB/pphs/docs/Code.tex U fptools/CONTRIB/pphs/docs/Error_Messages.tex ... > What may be wrong? Maybe, there is an old directory ./CVS/ causing some trouble? Cheers, Michael -- Lehrstuhl-BeleuchtungMichael Weber <[EMAIL PROTECTED]> Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: CONTRIB/pphs
On Thu, Feb 03, 2000 at 09:18:44 -0200, José Romildo Malaquias wrote: > On Wed, Feb 02, 2000 at 04:57:40AM -0800, Simon Peyton-Jones wrote: >> It's in fptools/CONTRIB/pphs not fptools/ghc/CONTRIB/pphs > > So, how can I get it? It used to be distributed with the ghc sources, $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs login [password `cvs'] $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs co fptools/CONTRIB/pphs dead easy... :-) Cheers, Michael -- Lehrstuhl-BeleuchtungMichael Weber <[EMAIL PROTECTED]> Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: 4.06 binary
On Mon, Jan 31, 2000 at 12:08:35 +0300, S.D.Mechveliani wrote: > Then, I am going to install 4.06-binary (if I can find it!) primary site: http://haskell.org/ghc/dist/4.06/ghc-4.06-i386-unknown-linux.tar.gz unofficial mirror (Hi Simon! Got my mail? :-)): http://www-i2.informatik.rwth-aachen.de/mirrors/haskell.org/ghc/dist/4.06/ghc-4.06-i386-unknown-linux.tar.gz [I noticed you have Debian Linux installed...] Debian packages (not the newest release, but sufficient to build it, AFAIK): http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian/unstable/binary-i386/devel/ghc4_4.06.2109-1.deb companion profiling libs (although I doubt they're useful, since profiling doesn't work fully, IIRC. You have to use ghc-3.0[23]): http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian/unstable/binary-i386/libs/ghc4-prof_4.06.2109-1.deb Cheers, Michael -- Lehrstuhl-Beleuchtung Michael Weber <[EMAIL PROTECTED]> Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: Segmentation Fault
On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] > OK, after hacking ghc-inplace to stop it deleting all its files (is there > a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Cheers, Michael -- Lehrstuhl-Gärtnerei Michael Weber <[EMAIL PROTECTED]> Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
ANNOUNCE: GHC & Happy now officially part of Debian
The subject says it all, just wanted to show-off a bit ;-) Thanks to Aaron Van Couwenberghe for sponsoring the packages... However, I'll keep the Haskell page up & running, usually, you'll find new versions some days earlier here... Cheers, Michael -- Lehrstuhl-Gärtnerei Michael Weber <[EMAIL PROTECTED]> Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: GHC 4.04.19990916 produces coredumping executable
On Sun, Dec 05, 1999 at 16:35:42 +, Ian Jackson wrote: > I'm using a GHC binary package from Debian GNU/Linux, binary package > version 4.04.19990916-0slink1 built by Michael Weber > <[EMAIL PROTECTED]>. As soon as I get it to compile > I'll try a compiler installation I built myself. > [...] > -davenant:stalk> ./nettlestalk > foo > Segmentation fault (core dumped) I'm using 4.04.19990916-2 and it doesn't coredump, but shows the same deadlock error, you mentioned in the other mail: [509]$ ./nettlestalk foo nettlestalk: fatal error: No threads to run! Deadlock? IMHO, the segmentation fault is related to same library subtelties, since both packages are build from the same sources... [511]$ dpkg -l 'ghc*' 'libc6*' 'gcc*'|grep ^ii ||/ NameVersionDescription +++-===-==- ii ghc44.04.19990916- GHC - the Glasgow Haskell Compilation system ii ghc4-doc4.04.19990916- Documentation for GHC - the Glasgow Haskell ii ghc4-libsrc 4.04.19990916- Library Sources of GHC - the Glasgow Haskell ii ghc4-prof 4.04.19990916- Profiling Libs for GHC - the Glasgow Haskell ii libc6 2.1.2-10 GNU C Library: Shared libraries and timezone ii libc6-dev 2.1.2-10 GNU C Library: Development libraries and hea ii gcc 2.91.66-2 The GNU (EGCS) C compiler. Cheers, Michael
Re: Linux and glibc
On Thu, Oct 28, 1999 at 04:29:51 -0700, Simon Marlow wrote: > We at GHC HQ have just upgraded our remaining glibc 2.0 machine here to > glibc 2.1, so at least we'll have fewer compatibility problems. But that > means we won't be able to build glibc 2.0 binaries from now on: is this > going to cause anyone severe grief? I'm still supporting packages of GHC and Happy for Debian/glibc-2.0 (a.k.a. `Slink'). The latest publicly available one is from 1999/09/16... If there is demand, I'd be willing to provide plain tarballs, too. Just bug me enough... :-) Cheers, Michael -- Those who open their minds too far often let their brains fall out. Those who open their minds too far often let their brains fall out. Those who open their minds too far often let their braGeneral Protection Fault in msborg32.dll.
Re: RFC: An extended Addr module
On Tue, Oct 12, 1999 at 02:50:33 -0700, Simon Peyton-Jones wrote:
[non-H98 compliant version]
>> That's of course exactly what one wants to write, but AFAIK this is not
>> Haskell 98, so I wanted to avoid it. Or is it Haskell 98? %-}
> It's not H98, but you could instead write
> instance Marshalable a => Marshalable (Vec3 a) where
> indexOffAddr buf off = do
> let sizeOfPolymorphicA = sizeOf (indexOffAddr buf 0)
> ...
> Pretty wierd, but it should work.
Second try... should now be H98 compliant & not-so-weird... ;-)
\begin{code}
instance Marshalable a => Marshalable (Vec3 a) where
indexOffAddr buf off =
let [x, y, z] = map (indexOffAddr buf) [off, off + soPA, off + 2*soPA]
soPA = sizeOf x
in Vec3 x y z
readOffAddr buf off = do
x <- readOffAddr buf off
let soPA = sizeOf x
[y, z] <- mapM (readOffAddr buf) [off + soPA, off + 2*soPA]
return $ Vec3 x y z
...
\end{code}
Cheers,
Michael
--
"Hi, I'm new at Alpha..this might sound dumb even..
Can I install Windows 95/98 on Dec Alpha machine?"
-- Brian Seo in comp.os.linux.alpha
Re: Staying alive
On Wed, Oct 06, 1999 at 12:04:03 +0200, Sven Panne wrote: > Michael Weber wrote: >>marshalListN :: Int -> [a] -> IO Addr > > I don't see a reason for the duplication of length information, e.g. > what should `marshalListN 1000 [1,2,3]' mean? And > `marshalListN 2 [1,2,3]' is equivalent to `marshalList (take 2 [1,2,3])'. Yes... I thought about this, but otherwise there would be a `marshalList' and `marshalListN' with same type signature, which I also regarded as confusing. >> where `marshalList' stores the list length at the beginning of the buffer, >> like: [ marshalList code deleted ] > This seems to be a rather special case, e.g. why should the length be > marshaled as an Int? Some ancient Pascals on PCs used a byte length prefix > for strings. And what about alignment? There could/must be some padding if > the alignment constraints for the list element type are stronger than the > ones for Int. Yes, I know. I cursed on this stupid Pascal string limit in school :-) But how else can you marshall an arbitrary length list? For Int lists, there is no zeroElem... BTW: This is what is done in XDR (eXternal Data Representation standard, see RFC1832). The length is at the beginning, coded as big-endian 32Bit unsigned int (we could use `writeInt32OffAddr . ccall_to_htonl' for this...) > It seems that both spellings are possible and both "feel right", depending > on the speaker and the dictionary. :-) That's what I expected... :-) Cheers, Michael
Re: Staying alive
[My apologies: some day - I promise - I'll learn to choose the right mailing
list... 8->]
On Mon, Oct 04, 1999 at 13:45:43 +0200, Sven Panne wrote:
[micro-marshalling]
> I know Manuel's code already and the one H/Direct produces. Has anybody
> else some FFI-related code and/or suggestions? This could be a wonderful
> topic for the wish list, but it would be nice to see the problems and needs
> for APIs different from GTK+ and OpenGL first.
Maybe it's worth to know how many objects a list has (without explicit
zeroElem), so I'd suggest to extend the class to:
marshalList ::[a] -> IO Addr
marshalListN :: Int -> [a] -> IO Addr
unmarshalList ::Addr -> IO [a]
unmarshalListN:: Int -> Addr -> IO [a]
where `marshalList' stores the list length at the beginning of the buffer,
like:
marshalList xs = do
let len = length xs
lenSize = sizeOf len
buf <- malloc (lenSize + len * sizeOf (head xs))
writeIntOffAddr buf 0 len
zipWithM_ (writeOffAddr (buf `plusAddr` lenSize)) [ 0 .. ] xs
return buf
and `instance Marshalable Int {...}'
> P.S. for the native speakers: Which spelling is correct, "marshaling" or
> "marshalling"? Ispell says "marshaling", but this looks a bit odd to me.
dictd knows both:
--
>From The Free On-line Dictionary of Computing (20Jul99) [foldoc]:
marshalling
(US -ll- or -l-) The process of packing one
or more items of data into a {message buffer}, prior to
transmitting that message buffer over a communication channel.
The packing process not only collects together values which
may be stored in non-consecutive memory locations but also
converts data of different types into a standard
representation agreed with the recipient of the message.
marshaling
Alternative US spelling of "{marshalling}".
(1998-03-16)
--
I'd vote for the "double-L" variant... :-)
Cheers,
Michael
--
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats."
-- Howard Aiken
Re: Patches for GHC 4.04pl1?
On Tue, Sep 21, 1999 at 21:54:55 +0200, Matthias Kilian wrote: >> The best thing to do is use the anoncvs repository, and just 'cvs update' >> to get the latest patches. If you're running over a phone line then it >> might help to make ssh do some compression. or, alternatively, make CVS do the compression with `cvs -z6' ... > Yes, but this requires at least one complete checkout. Of course, after > this is done, cvs update will only load the diffs to newer versions. You can also use the Debian *.orig.tar.gz tarballs. These are not Debian specific in ANY way, but merely a checkout/update of the CVS repo. The CVS specific files are left in the archive, so that one can easily update from there. The web-pages (and, from now on, the tarball name itself) tell you the date, when they were updated last time. > And: isn't there a risk to update the local sources to a `unstable' > revision? well, 4.04 also was `official', but not `stable' wrt. ghc-2.95... ;-)) Honestly, GHC seems to be improving whenever I look at it. I tend to see this more or less as "bleeding edge" development: if you work with it and something breaks, tell the upstream people, and normally you get fixes very quickly. If you hate waiting, try whether previous versions work (IIRC, our site has versions installed down to 0.29 :-)). Besides, if the current CVS version is screwed, in most cases this compiler won't compile itself... > I'll use cvs to get the latest ghc, but nevertheless I suggest to publish > patch files for future releases of ghc. This shouldn't be too difficult: > > cvs co -r lastRel -d ghc.old ghc > cvs co -D now ghc > cd ghc > diff -rNu ../ghc.old . > ../ghc.diffs > cvs tag -F lastRel > cd .. > cvs -q rel -d ghc.old > cvs -q rel -d ghc $ cvs rdiff -r rev1 [-r rev2] ghc should do the same, besides the tagging stuff. Alternatively, if there's already a co'd copy, you can do $ cvs diff -r oldRev | cvs-fix.pl where cvs-fix.pl fixes the broken +++/--- lines: directory structure isn't honored (at least, up to cvs-1.10.4). cvs-fix.pl is attached. Cheers, Michael -- The games industry is "a transfer of funds from the rich to the lucky". -- /. on 1999/08/20 cvs-fix.pl
GHC 4.04pl1 Debian packages available
Hi! subject says it all... :-) They packages for the unstable distribution are available at: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ or via APT installation method: just add deb http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian unstable/ deb-src http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian unstable/ to /etc/apt/sources.list Packages for the stable dist will be available on Monday... Cheers, Michael
Dynamic.lhs and Distributed Programming
Hi!
Is there any more information floating around wrt. the Dynamic extensions of
GHC (or hugs)?
The lib-docs say, it may be usable in Distributed Programming, but currently
I have no idea how to transport values of type Dynamic over some kind of net
connection to another instance of a program and then receive it on the other
side (the net connection itself is NOT the problem!).
IIRC, Dynamic is typed like "data Dynamic = Dynamic TypeRep Obj". `TypeRep'
is a tag, which denotes the 'real' type and `Obj' is a placeholder to which
the data is converted to via `unsafeCoerce' (*ugh*, strong type system, eh?
:-)).
One problem is, how to write a send/recv pair, which has default methods for
"standard" Dynamic types (Int, Chars, Tuples, Lists, etc.), but is also
extendable, to add later handling of arbitrary algebraic data types,
invented by a user.
Sending/receiving data of type Int, Char, etc. directly (without Dynamic)
can be done with a "class ... where { send :: ..., recv :: ... }", with a
default of sending string representations of data, provided it is of
instanced Read and Show. With Dynamic, this isn't possible any more...
Next, `mkTyCon' works ok with one node, but the mapping on Ints with this
`unsafePerformIO (newIORef 0)' hack has to be extended to make it's usage
safe between several nodes.
Just wondering,
Michael
--
W*ndoze NT is faster... CRASHING!
Re: Grumbles about building GHC from the CVS repository
On Fri, Sep 03, 1999 at 14:33:57 +0200, George Russell wrote: > (1) The repository is very puritanical about having to have autoconf and > happy installed. Since the chances of my wanting to muck about with the > configuration file/GHC parsers are nill, why not include the configure > script and Parser.hs/ParseIface.hs in the CVS repository. Sorry, but I strongly object this! There should *never* be any files in the repo that can be generated by some tools. Imagine, what would happen to diffs: not easy to read, size blow-up, bogus conflicts, etc. ... If these generated files are difficult to build, they _may_ be included in a source distribution. But, autoconf isn't that complicated to install and IIRC, there are Happy distributions for all supported platforms available, so why not use them for bootstrapping a `fresh' machine? This is a one-time effort, then you have a sane build environment. Pack your version, and next time, you can start with them (that's the way, which worked for me, YMMV). It's another case, if one wants to port the GHC suite to non-supported or "broken" platforms (the Alpha port was in a not-so-good shape the last time I looked at it... Sven? ;-)), but then the Happy and autoconf dependancies are your smallest problems... :-) Cheers, Michael -- W*ndoze NT is faster... CRASHING!
Re: NON-daemonic forking
On Mon, Aug 23, 1999 at 11:30:47 +0200, George Russell wrote:
> Michael Weber <[EMAIL PROTECTED]> wrote
> [snip]
> > forkChild :: IO () -> IO (MVar ())
> > forkChild p = do
> > mvar <- newEmptyMVar
> > forkIO (p >> putMVar mvar ())
> > return mvar
> This does not of course synthesise a non-daemonic forkIO from a daemonic one, because
> it requires the parent thread to wait for the MVar. I suppose that a possible
>alternative
> to having separate daemonic and non-daemonic forking would be to have an atexit-type
> function:
>atThreadExit :: IO () -> IO()
> which forkChild could use to wait for the mvar. But I'm not sure I like this, unless
> there are other likely uses for atThreadExit.
You're right. With the above code, the parent chooses, for which children it
has to wait (like this is done with Un*x fork() syscalls).
If I get it right, you want a forked process to be able to shutdown the
whole system?
\begin{code}
import Concurrent( forkIO, yield )
import System( exitWith, ExitCode(ExitSuccess) )
import Monad ( mapM_ )
main :: IO ()
main = do
forkIO (forever $ putChar 'a')
forkIO (mapM_ putChar (replicate 1 'b') >> exitWith ExitSuccess)
forever $ return ()
where
forever :: IO a -> IO a
forever p = p >> yield >> forever p
\end{code}
Cheers,
Michael
--
* Chemical Engineering is like looking for a black cat in a dark room.
* Software Engineering is like looking for a black cat in a dark room in
which there is no cat.
multiplying is one problem (was: Re: gcc2.95 and GHC)
On Sat, Aug 07, 1999 at 16:21:47 +0200, Matthias Kilian wrote:
> - I tried to compile ghc and it's libraries using gcc -fno-strict-aliasing
> (since this may be a problem), but it doesn't help, so you don't have to try
> this options to find the error.
so did I...
||/ NameVersionDescription
+++-===-==-
ii gcc 2.95.1-0pre2 The GNU C compiler.
ii libc6 2.1.2-0pre7GNU C Library: Shared libraries and timezone
ii libgmp2 2.0.2-3Multiprecision arithmetic library
ii libgmp2-dev 2.0.2-3Multiprecision arithmetic library developers
> Here is the example program, which consists of three modules, Primes, Hamming
> and HammingMain:
[Hamming removed]
The whole thing boils down to:
\begin{code}
module Main (main) where
main :: IO ()
main = if 1*2 == 0 then putStrLn "GHC(GCC 2.95) can't multiply, eh?"
else putStrLn "not reached"
\end{code}
Strange, isn't it?
BTW: (+),(-),(/) work nevertheless...
Cheers,
Michael
--
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats."
-- Howard Aiken
Re: NON-daemonic forking
On Fri, Aug 20, 1999 at 15:34:51 +0200, George Russell wrote:
> Einar Karlson, my predecessor, asked for daemonic forking as for Java. In
> Java you have ordinary threads and daemonic threads; the process ends when
> only daemonic threads are still running. The GHC team seem to have gone
> ahead and made all forked thread daemonic! So can we have ordinary threads
> back please? Still, daemonic threads are nice, and I wonder whether we
> should really have two fork functions, since I can't right now think of a
> way of synthesising one from the other.
How about this one :-)
\begin{code}
import Concurrent( forkIO, MVar, newEmptyMVar, putMVar, readMVar, yield )
main :: IO ()
main = do
t1 <- forkChild (forever $ putChar 'a')
t2 <- forkChild (forever $ putChar 'b')
waitForChilds [t1, t2]
where
forever :: IO a -> IO a
forever p = p >> yield >> forever p
\end{code}
\begin{code}
forkChild :: IO () -> IO (MVar ())
forkChild p = do
mvar <- newEmptyMVar
forkIO (p >> putMVar mvar ())
return mvar
waitForChilds :: [MVar ()] -> IO ()
waitForChilds [] = return ()
waitForChilds (p:ps) = readMVar p >> waitForChilds ps
\end{code}
Cheers,
Michael
--
W*ndoze NT is faster... CRASHING!
Re: ignore mkdependHS ?
On Thu, Aug 12, 1999 at 10:24:39 +0200, I wrote: > # DO NOT DELETE: Beginning of Haskell dependencies > B.o : B.hs > B.o : ./A.hi > A.o : A.hs > # DO NOT DELETE: End of Haskell dependencies > > As you can see, A.o does not depend on B.hs or B.o, but on B.hi, so it has > to be recompiled *only*, iff the interface file of A changes (if no relevant > information to the outside world changes, only A.o gets updated, if you > recompile A; A.hi then remains the same). Ok, sorry for that, I must have been drunken, when writing the above... What I really wanted to say, is: B.o does not depend on A.hs or A.o, but on A.hi, so it has to be recompiled only, iff the _interface file_ of A changes (if no relevant information to the outside world changes, only A.o gets updated, if you recompile A; A.hi still remains the same). Cheers, Michael -- Question: "Why isn't MPI2 already ported to Windows NT?" Bill Gropp: "Performance... and NT users expect a different behaviour... Actually, they expect it to crash more often... :-) No, they just don't want to './configure;make;make install'. They want to run InstallShield..."
Re: Using another gcc, linker, and so on
On Wed, Aug 11, 1999 at 12:39:06 +0200, George Russell wrote: > It would be nice if the ghc command had options which made it call > a different hsc/gcc/ld than the one hardwired by the installation > procedure into the Perl script. Currently I am playing games with > my PATH to achieve this effect. Have a look at the -pgm* options. For example, with '-pgmcfoo' (IIRC) would use 'foo' as C compiler. Cheers, Michael -- * Mechanical Engineering is like looking for a black cat in a lighted room. * Systems Engineering is like looking for a black cat in a dark room in which there is no cat and someone yells "I got it!"
Re: ignore mkdependHS ?
On Wed, Aug 11, 1999 at 16:39:18 +0400, S.D.Mechveliani wrote:
> Could the people, please, explain me the behaviour of ghc-4.04 -M
> (mkdependHS) ?
> For a long time my large project compiles (`makes') and works without
> any special file dependency forming. No -M, no mkdependHS used.
> Probably, this is since i had eliminated the interface cycles (?).
You always have to "half-order" your modules before compilation. For example:
\begin{code}
module A where
foo = id
\end{code}
\begin{code}
module B where
import A
bar = foo
\end{code}
B depends on A, therefore A < B, i.e. A has to be compiled before B,
otherwise the compiler complains about a missing .hi file for A.
Sure, you can order the modules by hand, but with 'ghc -M'/mkdependHS you
get it for free ;-)
$ touch Makefile # just a bogus Makefile
$ ghc -M B.hs A.hs
$ cat Makefile
# DO NOT DELETE: Beginning of Haskell dependencies
B.o : B.hs
B.o : ./A.hi
A.o : A.hs
# DO NOT DELETE: End of Haskell dependencies
Note, that with 'ghc -M' the module order in not relevant, it nevertheless
generates rules, that take care of the right ordering.
As you can see, A.o does not depend on B.hs or B.o, but on B.hi, so it has
to be recompiled *only*, iff the interface file of A changes (if no relevant
information to the outside world changes, only A.o gets updated, if you
recompile A; A.hi then remains the same).
If you want to delegate the dependency information to a file other than
'Makefile' or 'makefile', you can use:
$ ghc -M -optdep-f -optdep.depend ...
and in Makefile, use 'include .depend'.
Cheers,
Michael
--
Everything is controlled by a small evil group to which, unfortunately,
no one we know belongs.
-- fortune cookie
Re: I thought concurrent haskell was _preemptive_!
[Sorry, I accidently mailed this to the -bugs list. See its archives for the
complete source]
On Thu, Jul 29, 1999 at 12:19:10 +0200, George Russell wrote:
> I would like to add my strong support, as the person in charge of
> transferring the UniForM workbench, for the implementation of wait
> functions on input and output handles and input on Posix.FD which don't
> block everything else to be done urgently.
Wanna have a workaround for this? :-)
Today, I was playing around with green-card, and now I do have an (almost)
non-blocking hGetline...
Consider this piece of code, which was suggested by Peter Amstutz, who
started this thread:
\begin{code}
main = do
hSetBuffering stdin NoBuffering
forkIO (loop 'a')
booga
where
loop ch = hPutChar stdout ch >> loop ch
booga = do out <- almostPreemptiveGetLine 100 stdin
hPutStrLn stdout out
booga
\end{code}
After starting this program, you get blasted by 'a' chars, and if you type
in a line (still getting your terminal full of a's), it is printed in the
middle of these a's, just as one would expect...
Do I get a cookie now? :-)
How was this achieved?
Basically, I made a Haskell wrapper for select(2), so if one needs another
preemptive Input/Output function, it is possible to (non-blockingly) test,
whether there is I/O ready...
This is not really a solution, but I bet, it'll work in quite some
situations until Concurrent Haskell is *really* preemptive. ;-)
BTW: This should work with sockets, too, I didn't test, but I did a directly
coded (i.e. without green-card), similar function for sockets some weeks
ago, which worked...
Cheers,
Michael
--
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats."
-- Howard Aiken
Debian glibc2.1.1 packages of GHC and HAPPY available now
Hi! for those, who want to join the glibc2.1.1 hype, there are now Debian packages available for this ;-) The old ones did also work (I didn't expect that...), but broke some dependancies. These errors go away with the new packages. As usual, they can be found at http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ Cheers, Michael
Re: Preprocessor question
On Tue, Jul 13, 1999 at 03:26:27 -0700, Simon Marlow wrote:
> > Use `gcc -E -` then.
>
> Good point :-)
nearly..., but we have to use '$CPP -x c-header' which would expand to
'gcc -E -x c-header', otherwise gcc wants to link those temporary *.lpp
files :-(
IMHO '-x c-header' just means to gcc:
"READ MY LIPS: THIS HAS TO BE PREPROCESSED, NOT LINKED"
But afters some more tests, I have to admit that it's worse: in mkdependHS,
$Cpp must be run *with* '-' in '&run_something("... | $Cpp...");'.
In hscpp OTOH, it has to be run *without* dash, because hscpp gets its input
from command line, and else waits forever on stdin...
Nevertheless, this is pretty much straight-forward to me: if there is input
from stdin, one has to use '-', otherwise not...
> We also like to get as clean a cpp as possible - if you go through gcc -E
> you get a whole bunch of symbols defined, and cpp gets passed the -lang-c
> flag (whatever that means, but it looks pretty scary).
also goes away with '-x c-header'
Cheers,
Michael
--
Fog Lamps, n. (see also ->"Idiot Lights"):
Excessively (often obnoxiously) bright lamps mounted on the
fronts of automobiles; used on dry, clear nights to indicate that the
driver's brain is in a fog. -- fortune cookie
Re: Preprocessor question
On Tue, Jul 13, 1999 at 17:47:27 +0900, Manuel M. T. Chakravarty wrote: > Simon Marlow <[EMAIL PROTECTED]> wrote, > It isn't strictly speaking hardcoded, it's set up when you configure a binary distribution. So if you move gcc or install a new version, you need to re-install ghc. Yes, and that's a thing which should not happen: one installs a new package and mysteriously other packages begin to break... :-( Even worse: consider this being done by the admin or automatically, i.e. where problem resolution isn't simple... >>> I am sure that it is clear that a binary distribution with strict >>> dependencies on locations of other tools is far from ideal. That's exactly why I wrote the original message :-) > > This probably isn't the case for RPM's, but as you noted in your message > > it's up to the package builder to arrange for the location of cpp and other > > tools to be configured at install time. >>> [...] it would be nice if the path (and any other similar dependencies) >>> where located in a dedicated file where they are easy to find and patch. > > One possibility would be to have a `ghc-cpp' script, which is a one liner > and just `exec's cpp. We could either patch this script or have different > versions `ghc-cpp-', which are linked to `ghc-cpp'. What do you > think? *hmm* IMHO we already have one: 'hscpp'. As I said, ghc doesn't make use of $RAWCPP, and mkdependHS could use hscpp instead of calling cpp directly. Besides, SimonM mentioned that 'gcc -E' is a Bad Thing. I tried CPPs from gcc-2.7.2.3, gcc-2.8.1 and egcs-2.91.66, and they do accept input from stdin (note the dash): == $ echo TEST|gcc -E -DTEST=works - # 1 "" works == However, cpp does the same without the dash, but adding a dash _doesn't_ break things. == $ echo TEST|cpp -DTEST=works - # 1 "" works == Regarding unusual places where CPP lives on some systems, this should be (is already?) solved by autoconf. IIRC, ghc relies heavily on gcc's/egcs's features on all platforms, so we loose, if there is none, anyway. autoconf will always prefer an installed gcc over any other compiler, and thus also "gcc -E" over anything else. So the only things we have do, are: * in aclocal.m4, set $fptools_cv_gnu_cpp="$CPP -" and put this into hscpp's $RAWCPP * make mkdependHS use hscpp * remove $RAWCPP from perl scripts, that don't make use of it BTW: I tried Solaris and Linux platforms only, maybe the *BSD, OSF, and Windows folks should do the above tests, too... Cheers, Michael -- standard construction, def: "sort of a mathematical equivalent of 'hey you'" -- Phil Wadler, "Monads"
Preprocessor question
Hi! Please, can somebody explain, why the preprocessor is hardcoded in the GHC perl scripts? IIRC ghc (the perlscript itself) doesn't even reference $RAWCPP. mkdependHS and hscpp do, but why an absolute path and this obscure "-iprefix" parameter? Again, "-iwithprefix" is never used... Would it break things, if there is '$RAWCPP = "cpp -traditional"' only? Cheers, Michael -- W*ndoze NT is faster... CRASHING!
GHC binary packages for Solaris & Debian Linux available...
Ok world, I put up a webpage with GHC binaries of recent CVS snapshots, featuring Sparc-Solaris2 and Debian Linux packages there (I think this is *really* new, isn't it? :-), no need for "extra-terrestrians" any more...) I'll struggle to have them as up-date as possible, so they're intended for users that lack enough time, memory and CPU cycles, to build the binaries themselves... The Debian binaries support some nice Debian features, like alternatives etc., but the source package is a bit rough by now. Improvements are on the way. However, I'm looking for $\beta$-testers... The packages can be found at: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ Comments welcome Cheers, Michael -- W*ndoze NT is faster... CRASHING!
questions about Foreign in ghc-4.02
Hi!
Maybe it's too early today 8-) for me, but could it be that the Foreign
interface is a bit *ummh* strange?
If I import PrelForeign( makeForeignObj ), it has the type
makeForeignObj :: Addr -> IO ForeignObj
On the other hand, importing from Foreign( makeForeignObj ) the export
header(!) states (yes, only a comment, but a misleading one...):
makeForeignObj -- :: Addr{-obj-} -> IO ForeignObj
but later in the module:
makeForeignObj :: Addr -> Addr -> IO ForeignObj
makeForeignObj obj finaliser = do
fobj <- PF.makeForeignObj obj
^^^--- NOTE THIS (*)
addForeignFinaliser fobj (app0 finaliser)
return fobj
(*) although the line
--import qualified PrelForeign as PF ( makeForeignObj )
is commented out!
And PrelForeign doesn't provide an 'addForeignFinaliser'...
So, if someone could have a look at the following code snippet, and tell me,
whether there is a nicer way to do this... (at least, the import's don't
make me feel well...)
(Actually, it works, I think:
'foo' does nothing but strdup'ing its argument and returning the pointer to
the newly allocated string.
'foo_free' free's the malloc'ed pointer...
I added some debug output to the C functions. They're freeing the right
memory, and I hope, not too early... :-) (the "memory freed" output does
show up *after* displaying the returned string with "putStr"... )
)
BEGIN test.lhs
\begin{code}
{-# OPTIONS -fglasgow-exts #-}
import Foreign( addForeignFinaliser )
import PrelForeign( unpackCStringFO, makeForeignObj, ForeignObj )
foreign import "foo_free" unsafe foo_free :: ForeignObj -> IO ()
bar :: [Int] -> IO ForeignObj
bar list = do addr <- _ccall_ foo (show list)
fo <- makeForeignObj addr
addForeignFinaliser fo (foo_free fo)
return fo
main = do r0 <- bar [1..11999]
putStr $ unpackCStringFO r0
putStrLn "."
\end{code}
END test.lhs
Confused,
Michael
--
XXXVII:
Ninety percent of the time things will turn out worse than you expect.
The other 10 percent of the time you had no right to expect so much.
Re: gcc 2.8.1 / egcs on Sparc
On Tue, May 18, 1999 at 03:39:45 -0700, Simon Marlow wrote: > I just got around to looking into why gcc 2.8.1 and egcs don't work with GHC > on the sparc. Rather embarassingly, it turned out to be not only our fault > but a single-line fix :-| Below is a patch against the latest sources, > which I've tested with both gcc 2.8.1 and egcs 1.1.2 (released version). Did this work for someone for ghc-4.02? I tried it (yes, fptools/driver/ghc-asm.l?prl both do contain this line in the solaris2-section...) Nevertheless, ghc/driver/ghc BUS ERRORs... :-( Configuration: Solaris 2.7 gcc 2.8.1 ghc 4.01 pl 0 (binary version) ghc-4.02-src.tar.gz BTW: I also made this uahalf/uaword-change change in the binary-ghc's (4.01) ghc-asm.prl, just to be sure... Did I miss something? Cheers, Michael -- Never buy anything that mentions Windows on the package. Except sheets of glass. Or plastic. And that smelly blue stuff that removes dirt without leaving a residue. -- [EMAIL PROTECTED] in c.o.l.d.s.
assembler problem when compiling ghc-4.02
Hi!
Finally I have a self-compiled solaris-ghc that does not buserror when being
used... but now there is another problem:
When compiling ghc/lib/std/PrelNumExtra.lhs, ghc (well, it's 'as') says:
../../../ghc/driver/ghc -optc-g -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O
-split-objs -odir PrelNumExtra -H30m -K2m -c PrelNumExtra.lhs -o PrelNumExtra.o
-osuf o
ghc: ignoring heap-size-setting option (-H20m)...not the largest seen
NOTE: Simplifier still going after 4 iterations; bailing out.
NOTE: Simplifier still going after 4 iterations; bailing out.
[...]
ghc: module version changed to 1; reason: no old .hi file
/tmp/ghc9205.hc:15368: warning: assignment makes integer from pointer without a cast
/tmp/ghc9205.hc:15372: warning: assignment makes pointer from integer without a cast
/tmp/ghc9205.hc:15377: warning: assignment makes pointer from integer without a cast
/tmp/ghc9205__1.s: Assembler messages:
/tmp/ghc9205__1.s:5: Error: Can't emit reloc {- *UND*-seg symbol
"PrelNumExtra_zdwtpl2_entry"} @ file address 20.
/tmp/ghc9205__1.s:6: Error: Can't emit reloc {- *UND*-seg symbol
"PrelNumExtra_zdwtpl2_entry"} @ file address 32.
/tmp/ghc9205__1.s:7: Error: Can't emit reloc {- *UND*-seg symbol
"PrelNumExtra_zdwtpl2_entry"} @ file address 44.
/tmp/ghc9205__1.s:8: Error: Can't emit reloc {- *UND*-seg symbol
"PrelNumExtra_zdwtpl2_entry"} @ file address 56.
[...]
Does that sound familiar? Is there a way to fix this?
Cheers,
Michael
--
Never buy anything that mentions Windows on the package.
Except sheets of glass. Or plastic. And that smelly blue
stuff that removes dirt without leaving a residue.
-- [EMAIL PROTECTED] in c.o.l.d.s.
BEGIN_HASKELL98_SYSTEM ignored?
Hi!
Today I downloaded the green-card (current version) from their website and
tried to compile it. ghc (4.03pre) complained about this fail <-> ioError function
problem, but at the top of LexM.hs the source says:
{- BEGIN_HASKELL98_SYSTEM
fail = ioError
END_HASKELL98_SYSTEM -}
I had to explicitly s/fail/ioError/g to make it compile.
Does the preprocessor ignore the BEGIN_HASKELL98_SYSTEM directive?
Cheers,
Michael
--
Never buy anything that mentions Windows on the package.
Except sheets of glass. Or plastic. And that smelly blue
stuff that removes dirt without leaving a residue.
-- [EMAIL PROTECTED] in c.o.l.d.s.
