Stretching the Storage Manager a little too much...
[I am reading ghc-bugs via the list archives, Cc'ing me would make me see responses faster] Here's a simple memoization function: applyMemo :: (Eq a1,Show a1) = (a1 - b) - MVar [(a1,b)] - (a1 - b) applyMemo f refTable x1 = unsafePerformIO $ do -- print x1 table - takeMVar refTable let key = x1 case lookup key table of Nothing - do let result = f x1 putMVar refTable $! (key,result):table return result Just memo - putMVar refTable table return memo The code above is a cut-down example. Initially, I tried to use Data.HashTable, then IORef (Data.Map ...), then MVars. However, what remains is that I get funny results: loop, thread blocked indefinitely, hangs, depending on the exact implementation of applyMemo, whether I use ghci or ghc, and which function I memoize (something with a more interesting call pattern than fib). This is with ghc-6.6 from haskell.org on MacOSX/Intel, same hangs on amd64-linux. I have some speculation what's going wrong, namely that one version of the unsafePerformIO code is interrupted by another (triggered by some lazy computation), the latter then blocks on the MVar, and the RTS cannot proceed. Oh, and uncommenting the print statement makes the error go away, presumably because x1 is fully evaluated? Anyway, this code is more or less lifted from the Stretching the Storage Manager paper [1], and since then there have been quite some invasive changes to the RTS, if I am not mistaken. What am I doing wrong, and how can I do it right? :) (If pressed I could provide actual code which triggers the bug, but it will take me a while to extract it, and also I would rather have it not public for now.) Cheers, Michael [1] http://research.microsoft.com/Users/simonpj/Papers/weak.ps.gz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Symbol referencing problem in GHC HEAD.
* Simon Marlow [EMAIL PROTECTED] [2003-03-21T13:02+]: GCC has __umoddi3 in libgcc.a. It generates calls to that function and others for some 64-bit operations. On our RedHat box here, __umoddi3 is also exported by libc.so, which is why we don't get any link errors. Perhaps on your box it isn't? Just as a short note, IIRC in the sparc-*-linux port this problem also showed up: * GHCi: dies with unresolved symbols while loading HSbase_cbits.o (__umoddi3 and friends; again: maybe just due to a wrong build...) Cheers, Michael ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: building 5.04.3 on sparc-solaris-2.6
* Malcolm Wallace [EMAIL PROTECTED] [2003-03-19T14:33+]: Anyway, I changed mk/config.h to add #define HAVE_ALTZONE #define HAVE_TIMEZONE and received the same error. I will now `make clean' and rebuild from scratch, to see if it makes any difference. You may have to copy (and modify) config.h to ghc/includes as well. See ghc/includes/Makefile Cheers, Michael ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug#171518: ghc --make does not play nice with FFI wrapper
- Forwarded message from Richard Braakman [EMAIL PROTECTED] - Date: Tue, 03 Dec 2002 03:26:54 +0200 From: Richard Braakman [EMAIL PROTECTED] Subject: Bug#171518: ghc --make does not play nice with FFI wrapper To: Debian Bug Tracking System [EMAIL PROTECTED] Reply-To: Richard Braakman [EMAIL PROTECTED], [EMAIL PROTECTED] X-Mailer: reportbug 2.9 Message-Id: E18J1pu-0004Vc-00@night Package: ghc5 Version: 5.04-1 Severity: normal I have a module SDL.Bare.Audio with this declaration: foreign import ccall safe wrapper mkSDL_AudioSpec_Callback :: SDL_AudioSpec_Callback u - IO (FunPtr (SDL_AudioSpec_Callback u)) When compiling Audio.hs, this results in the creation and compilation of Audio_stub.c. Unfortunately, if I'm using ghc --make, if it decides to skip compilation of Audio.hs, it never realizes that it also needs to link in Audio_stub.o, causing this failure at the end: ghc: linking ... build/Audio.o(.text+0x89): In function `s3Fk_ret': : undefined reference to `SDLziBareziAudio_d3K2' collect2: ld returned 1 exit status I tried to work around it by putting Audio_stub.o on the command line by hand, but then it fails when compiling from a clean tree, because it ends up linking the file twice. Richard Braakman -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux night 2.4.7 #1 Thu Jun 27 13:02:24 EEST 2002 i686 Locale: LANG=C, LC_CTYPE=fi_FI.ISO8859-1 Versions of packages ghc5 depends on: ii gcc 2:2.95.4-17The GNU C compiler. ii libc6 2.3.1-5GNU C Library: Shared libraries an ii libgmp3 4.0.1-3Multiprecision arithmetic library ii libgmp3-dev 4.0.1-3Multiprecision arithmetic library ii libncurses5 5.3.20021109-1 Shared libraries for terminal hand ii libreadline4 4.3-4 GNU readline and history libraries ii libreadline4-dev 4.3-4 GNU readline and history libraries ii perl [perl5] 5.6.1-7Larry Wall's Practical Extraction -- no debconf information - End forwarded message - ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Object Splitting and the Base Package Makefile
* Wolfgang Thaller [EMAIL PROTECTED] [2002-10-09T00:42+0200]: When building the library archive libHSbase.a, the makefile system includes not only all the split object files, but also the file PrimopWrappers.o. Consequently [at least on Mac OS X], ranlib generates a warning about duplicate symbols and fails to generate a sorted symbol table for the library (it generates an unsorted symbol table instead, which leads to slower linking). Happens with the current HEAD. In a related issue, it seems that in ghc-5.04 libraries *_hsc.o files are left out when linking with SplitObjs=YES. michaelw@stargate:.../build-stage1/libraries/network$ rm libHSnetwork.a michaelw@stargate:.../build-stage1/libraries/network$ make libHSnetwork.a rm -f libHSnetwork.a libHSnetwork.a.tmp (echo cbits/ancilData.o; /usr/bin/find Network_split Network/BSD_split Network/CGI_split Network/Socket_split Network/URI_split -name '*.o') | xargs ar q libHSnetwork.a : libHSnetwork.a michaelw@stargate:.../build-stage1/libraries/network$ rm libHSnetwork.a michaelw@stargate:.../build-stage1/libraries/network$ make libHSnetwork.a SplitObjs=NO rm -f libHSnetwork.a /usr/bin/ar clqslibHSnetwork.a Network.o Network/BSD.o Network/CGI.o Network/Socket.o Network/URI.o Network/BSD_hsc.o Network/Socket_hsc.o cbits/ancilData.o : libHSnetwork.a michaelw@stargate:.../build-stage1/libraries/network$ make show VALUE=EXTRA_OBJS EXTRA_OBJS=cbits/ancilData.o michaelw@stargate:.../build-stage1/libraries/network$ make show VALUE=C_OBJS C_OBJS=Network/BSD_hsc.o Network/Socket_hsc.o cbits/ancilData.o michaelw@stargate:.../build-stage1/libraries/network$ With SplitObjs=YES, Network/BSD_hsc.o and Network/Socket_hsc.o are missing from the archive, since different linking commands are used. After a short look into .../mk/target.mk, $(EXTRA_OBJS) seems to be the culprit. Can somebody please verify that it is indeed the case and the attached fix doesn't break anything else (and do a check-in, if so)? (I'm a bit short on time). Cheers, Michael p.s.: is $(STUBOBJS) needed there? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: link in documentation
* Simon Marlow [EMAIL PROTECTED] [2002-07-22T14:46+0100]: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/posix /doc/posix.sgml?rev=1.14content-type=text/x-cvsweb-markup it has See XRef LinkEnd=sec-Concurrent-Haskell for details on how to communicate between threads. but the HTML doesn't have a link here. Looking at Fixed, thanks. I noted this in my ghc build, and fixed it by using sec-Concurrent-Haskell in both places though :) sorry, haven't been able to fold that back in the tree. Related to that, there are two more places where the db2xxx tools choke: ==fptools== /usr/bin/make all -wr; in /opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/hslibs/doc db2html -d /opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/docs/fptools-both.dsl hslibs.sgml output is hslibs Using catalogs: /etc/sgml/catalog Using stylesheet: /opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/docs/fptools-both.dsl Working on: /opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/hslibs/doc/hslibs.sgml jade:/opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/hslibs/doc/../posix/doc/posix.sgml:768:40:X: reference to non-existent ID SEC-CONCURRENT-HASKELL jade:/opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/hslibs/doc/../util/doc/Select.sgml:82:16:X: reference to non-existent ID SEC-SCHEDULING jade:/opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/hslibs/doc/../util/doc/Select.sgml:83:21:X: reference to non-existent ID SEC-ASYNCHRONOUS-EXCEPTIONS jade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'SEC-CONCURRENT-HASKELL' jade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'SEC-SCHEDULING' jade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'SEC-ASYNCHRONOUS-EXCEPTIONS' make[3]: *** [hslibs.html] Error 8 make[2]: *** [all] Error 1 make[2]: Leaving directory `/opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/hslibs' make[1]: *** [all] Error 1 make[1]: Leaving directory `/opt/src/build/debian/ghc5/ghc5-5.04/build-stage1' make: *** [stamps/stage1-stamp] Error 2 No immediate idea where to fix those (I tried one place without effect), so I reverted to: db2html -e noidref ... # turns idref errors off to make the build go through... hint: a full build (required for Debian, else the tools don't let you upload (easily...)) takes about 9 hours on my machine... : Cheers, Michael ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loading non-existing module in 5.02
On Thu, Sep 27, 2001 at 10:29:04 +0100, Simon Marlow wrote: A :l X -- trying non-existing module can't find module `X' -- all right Prelude :m A `A' is not currently loaded -- ? Prelude The ':load' command begins by unloading all of the existing modules - this is specified quite clearly in the documentation. I think this is the right behaviour, because to hold on to them might cause a space leak. Would it be possible to check for the existance of X first, and unload the modules only iff it actually exists and can be loaded? Cheers, M/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in Time module
On Wed, Sep 26, 2001 at 16:21:09 +0200, Koen Claessen wrote:
I discovered a bug in the Time module. If I run the
following code snippet:
Just one? ;)
[...]
The TimeDiff value has a tdSec field greater than 59, and a
tdMin field of 0. I guess this is a bug.
I am running ghc-5.00.2 on Linux.
Well, it's consistent with the comments in the code...
From ghc/lib/std/Time.hsc:
[...]
diffClockTimes :: ClockTime - ClockTime - TimeDiff
-- diffClockTimes is meant to be the dual to `addToClockTime'.
-- If you want to have the TimeDiff properly splitted, use
-- `normalizeTimeDiff' on this function's result
--
-- CAVEAT: see comment of normalizeTimeDiff
diffClockTimes (TOD sa pa) (TOD sb pb) =
noTimeDiff{ tdSec = fromIntegral (sa - sb)
-- FIXME: can handle just 68 years...
, tdPicosec = pa - pb
}
normalizeTimeDiff :: TimeDiff - TimeDiff
-- FIXME: handle psecs properly
-- FIXME: ?should be called by formatTimeDiff automagically?
--
-- when applied to something coming out of `diffClockTimes', you loose
-- the duality to `addToClockTime', since a year does not always have
-- 365 days, etc.
--
-- apply this function as late as possible to prevent those rounding
-- errors
normalizeTimeDiff td =
[...]
The behaviour is arguable, but the Time module badly needs a rewrite,
anyway... there are still quite some more problems lurking in there...
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
SPITWADS ARE NOT FREE SPEECH
-- Bart Simpson in 8F01
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-5.02/libreadline.so.3
On Mon, Sep 24, 2001 at 11:00:49 +0200, Ch. A. Herrmann wrote:
Dear Haskellers,
in ghc-5.02/distrib/INSTALL, there is the following hint:
Linux users: GHCi-5.00 needs libreadline.so.3.
hrm... then what did I do wrong? :)
[209]% ldd /usr/lib/ghc-5.00.2/ghc-5.00.2
libdl.so.2 = /lib/libdl.so.2 (0x4001e000)
libreadline.so.4 = /lib/libreadline.so.4 (0x40022000)
libncurses.so.5 = /lib/libncurses.so.5 (0x40047000)
libm.so.6 = /lib/libm.so.6 (0x40087000)
libgmp.so.3 = /usr/lib/libgmp.so.3 (0x400a9000)
libc.so.6 = /lib/libc.so.6 (0x400cb000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
Why does ghci need libreadline.so.3, specifically?
Please tell me how to adapt the makefile or something else to get
it running. I'm sorry not to be an installation expert; maybe it's
a simple thing to do.
I can't recall doing anything special to achieve this...
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
Don't worry, honey, just two more lemmas ...
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc via ftp
On Tue, Jun 26, 2001 at 15:02:28 +0200, Michael Sperber [Mr. Preprocessor] wrote: Salve glorious Glasgow Haskell teamsters! The ghc release notes keep announcing that the ghc distro is available via anonymous ftp, referring to details below. However, there never seem to be any details, and ftp.haskell.org sadly doesn't answer my prayers on the ftp command line. Any chance of making anonymous ftp available so I could mirror ghc? weell, :) I'm already mirroring the haskell.org/ghc/ tree (for quite some time now), and we're quite good connected. Feel free to use it. =) The mirror can be found at: http://www-i2.informatik.rwth-aachen.de/mirrors/haskell.org/ SimonM, maybe it would be a good idea to put a link for the mirror on the GHC pages? Cheers, Michael p.s.: I'm using wget for this. Works(tm). -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 SPITWADS ARE NOT FREE SPEECH -- Bart Simpson in 8F01 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: No luck installing on SuSE 7.1
* William Chesters [EMAIL PROTECTED] [2001-05-09T20:58+0200]: William Chesters writes: However the toy exe I build terminates with an Illegal instruction signal (whether or not I use -via-C), and the same quite quickly happens to ghci if I play around. If I copy the toy exe onto a Mandrake (~ RedHat) 6.0 machine I get the same. (If I copy it onto an RH5 machine I get segfault instead.) Although, I just copied it onto an RH5.2 machine, as opposed to 5.1, and it worked. So the situation is, SuSE 7.1 with readline 3 added, Linux 2.4.0, AMD K6-2: -- compiler runs, up to a point -- toy compiled executable gives SIGILL You may try: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ghc/ghc-5.00-2.i386.rpm NOTE: I build this package on SuSE 7.0, IIRC. It /should/ work. I was able to rebuild GHC several times with itself. No docs, though. Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 The California State Lottery is a tax on people who can't do math -- /. on 1999/08/20 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]
On Mon, Apr 30, 2001 at 12:19:32 +0100, Simon Marlow wrote: So, I think a safe solution is to ensure that the .ghci file belongs to the user. Checking for decent permissions would increase security, but well, IMO it's the users' fault, if he creates a 777 .ghci :-P I've thought about this a bit more. It's not enough to just check the owner and permissions of .ghci if the current *directory* is world writable. If user X writes/modifies ./.ghci, then it gets the ownership of X, doesn't it? How do I trick the file system to keep the ownership of the modified file to the original user? Cheers, Michael ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]
* BENNETT,ANDY (HP-Unitedkingdom,ex1) [EMAIL PROTECTED] [2001-04-27T15:10+0100]: While I agree that there is a potential security hole, I think it is something that you could possibly tackle with the OS security mechanisms. I don't know much about Windows, or other Unix platforms, but if they are the same as HP-UX doing the following will let you have a group writable directory, with a .ghci only modifyable by the owner (and not deletable or renamable either). Make sure the permissions on things are as follows: [...] No one other than the user (owner) may touch the contents of the file then even though others may use the directory. The problem is with directories like /tmp, or more generally directories, which are not under the user's immediate control. $ echo ':! some-evil-script.sh' /tmp/.ghci Then wait, until somebody steps into the boobie trap: if one cd's to /tmp and executes ghci (to test stuff, for example; i do this frequently) there the script gets executed. I think that was Michal's original point. BTW: not allowing :! isn't enough, you can still use other tricks to (over)write files or even start programs... So, I think a safe solution is to ensure that the .ghci file belongs to the user. Checking for decent permissions would increase security, but well, IMO it's the users' fault, if he creates a 777 .ghci :-P Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]
Please, preserve the Cc: when replying. - Forwarded message from Michal Politowski [EMAIL PROTECTED] - Date: Sat, 21 Apr 2001 18:57:01 +0200 From: Michal Politowski [EMAIL PROTECTED] Subject: Bug#94739: ./.ghci -- isn't it dangerous? To: Debian Bug Tracking System [EMAIL PROTECTED] Reply-to: Michal Politowski [EMAIL PROTECTED], [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] Package: ghc5 Version: 5.00-1 Severity: normal ghci will load .ghci from current directory and it can contain :! shell commands, so if I run ghci in a directory writable by others bad things can happen eg. to my files. On the other hand it's useful. Maybe it could be less dangerous if the immediately damaging stuff (:!) was disabled and some warning printed if the file was writable (or owned) by someone else? -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux Amber 2.2.19 #1 Thu Mar 29 15:52:51 CEST 2001 i586 Versions of packages ghc5 depends on: ii gcc 1:2.95.3-7 The GNU C compiler. ii libc6 2.2.2-4GNU C Library: Shared libraries an ii libgmp3 3.1.1-4Multiprecision arithmetic library ii libgmp3-dev 3.1.1-4Multiprecision arithmetic library ii libncurses5 5.2.20010318-1 Shared libraries for terminal hand ii libreadline4 4.2-2 GNU readline and history libraries ii perl 5.6.0-21 Larry Wall's Practical Extracting ii perl [perl5] 5.6.0-21 Larry Wall's Practical Extracting -- Michal Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message - End forwarded message - -- /~\ ASCII ribbon | phase i'm stuck with junkies and bums \ / campaign | pleh family? X against | phase you're not that close to me :) / \ HTML mail| -- IRC, #argv ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in dependency generation
On Thu, Apr 19, 2001 at 20:49:25 -0600, Alastair Reid wrote: PPUnits.hs: can't find one of the following: `is.hi' `is.hs' `is.lhs' Obviously, the dependency generating code is being confused by the function name "import'". I'd go fix the relevant regexp myself except that I can't figure out where it lives. I think, a similar bug has IIRC already been reported and identified. Julian is having a look into it... 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 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-5.00: not built for interactive use
On Tue, Apr 17, 2001 at 21:20:04 +0200, Markus Lauer wrote: Hi, I compiled ghc-5.00 from the source distribution (config --prefix=.; make; make install). when I call ghci I get ghc-5.00: not built for interactive use Is there anything special to enable GHCi? You have to build ghc-5.00 with another ghc-5.00 to get the interactive stuff. IOW, rebuild it with your newly obtained ghc-5.00. 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-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiling ghc-5 with x86 HC files
* "Manuel M. T. Chakravarty" [EMAIL PROTECTED] [2001-04-16T14:21+1000]: which automates the process. More details at http://haskell.cs.yale.edu/ghc/docs/4.08.2/building/sec-booting-from-c.html I just found that this documentation seems to have disappeared since the 5.00 release. I think, I am going to resurrect it as part of the GHC Commentary. it's still there, you just have to (IIRC): $ cd fptools/docs $ cvs update -dP Cheers, M/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: How to install ghc/happy on Sparc from source?
On Thu, Mar 01, 2001 at 18:00:36 +0100, Frank Steiner wrote: Hi, Hi Frank, I need to install a recent ghc version on a Sparc running Solaris. I cannot use the precompiled binaries as I don't have access to /usr/local and it seems that this path is hard-compiled into the binaries. hmm, AFAIR ``./configure --prefix=/some/path'' works... You can also use: $ ./configure $ make in-place 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/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: fptools/configure thinks happy 1.10 1.9
[ Volker, is your Mail-Followup-To:-header intended like this? ]
* Volker Stolz [EMAIL PROTECTED] [2001-01-26T14:57+0100]:
[ configure thinks: happy-1.10 happy-1.9 ]
And in a sense, it is right. I'd really like to come up with a fix, but
I guess...
[ perl thingy ]
perl vers.pl "1.9" "1.10" ; echo $?
1
perl vers.pl "4.08.1" "4.08"; echo $?
0
[982]% perl vers.pl 4.09 4.08.1
zsh: exit 1 perl vers.pl 4.09 4.08.1
[983]%
BTW:
Using perl in autoconf... What next? Slicing bread with the
Swiss Army Chainsaw(tm)? heart surgery? splitting atom cores? B)
quote
The `configure' script [...] should not use any utilities directly
except these:
cat cmp cp diff echo egrep expr false grep install-info
ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true
/quote
sequence_compare () {
# usage:
# ``IFS="." sequence_compare 1.2.3 -lt|-le|-eq|-ge|-gt 4.5''
# - no *sh- or system-specific features
# - relies on IFS as field separator
a="$1"; op="$2"; b="$3";
while test -n "$a$b"
do
set -- $a; h1="$1"; shift 2/dev/null; a="$*"
set -- $b; h2="$1"; shift 2/dev/null; b="$*"
test -n "$h1" || h1=0; test -n "$h2" || h2=0
test ${h1} -eq ${h2} || break
done
test ${h1} "$op" ${h2}
}
Of course, for autoconf functions are VERBOTEN, and therefore the
original $IFS has to be saved later restored...
Cheers,
Michael
p.s.: http://www.focusresearch.com/gregor/psh/ (interactive perl shell) =)
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
"Ada is PL/I trying to be Smalltalk."
-- Codoso diBlini
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: VB: Bug, perhaps to do with functional dependencies?
* John Hughes [EMAIL PROTECTED] [2001-01-22T20:10+0100]:
liam@HEMPC ~/BDDs
$ ghc -static -c -fglasgow-exts Pigeon.hs
[...]
basicTypes/Var.lhs:194: Non-exhaustive patterns in function
readMutTyVar
This is a nice one. If you change it in a sublte way:
+++ Pigeon.hi
pigeon n t =
- do a-at 1
+ do a-at
orBDD t a a
- where at i = varBDD t 0
+ where at = varBDD t 0
it compiles, but GHC emits:
zonkIdOcc: FunDep_aMr
zonkIdOcc: FunDep_aMr
This leads to Imperative.hi, in which you are using Functional
Dependencies, obviously. While I don't know jack about them, I
remember them causing some glitches in GHC (which might already be
solved in CVS). However, I edited the FD away in Imperative.hi and
Pigeon.hs compiled (even your original version).
+++ Imperative.hi
-1 class {PrelBase.Monad m} = Imperative s m :: (* - *) | m - s where {st ::
__forall [a] = PrelST.ST s a - m a} ;
+1 class {PrelBase.Monad m} = Imperative s m :: (* - *) where {st :: __forall [a]
+= PrelST.ST s a - m a} ;
There is no file Var.lhs on my machine: I assume it's part of the
source of GHC.
yes. fptools/ghc/compiler/basicTypes/Var.lhs
What's the behaviour that is wrong, in my opinion? Well, firstly (and
mainly) that the compiler rejects the program at all. Secondly that
the error message refers to a non-existent source file. And thirdly,
since when have non-exhaustive patterns been an error? That's about
it!
internal compiler error =) Maybe someone should mark them in a more
obvious way...
Grateful for help -- it would be fun to see how much speedup I get
from GHC...!
Want to beat SMV/BMC? =)
Cheers,
M/
--
() 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/
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Change sigTTOU/TTIN to IGNORE by default
* Simon Marlow [EMAIL PROTECTED] [2001-01-16T02:17-0800]: [...] The Solaris man page has this exact same paragraph, although I can find no mention of this behaviour in the POSIX book I have, the Linux man pages (surprise :-) or the Glibc docs. Well, yes the man pages *ummh* sort of suck, but the info files are not that bad... [75]$ info libc 'Access to the Terminal' B-) I guess it's another one of those dark corners that Volker seems to wonder into with alarming regularity :) Yes, Volker and I have been joking about this, too... =) Cheers, M/ -- 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. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Change sigTTOU/TTIN to IGNORE by default
* Michael Weber [EMAIL PROTECTED] [2001-01-16T00:00+0100]: [...] So, a solution seems to be, to block SIGTTOU during the call of tcsetattr [...] BTW: Eventually, the following functions need the same shielding: tcsetattr, tcsendbreak, tcflow, tcflush Cheers, M/ -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. -- fortune cookie ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Segmentation fault in GHC compiled program
On Mon, Oct 16, 2000 at 09:09:08 +0100, Martin Böhme wrote: Dear GHC team, While testing Martin Erwig's functional graph library, I encountered what I believe is a bug in GHC. My test program crashes with a segmentation fault for graphs above a certain size. *hmm* I just tested the program with up to 3 nodes and it worked (although I had to increase the stack size a bit for 1+ nodes...) $ ./TestFGL 1 Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. $ ./TestFGL +RTS -K5M 1 [normal output follows...] BTW: I used ghc-4.06 / egcs-2.91.66, 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. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: New Version of plusAddr and HDirect Conflict
[CC field left intact, despite nonexistant Mail-Followup-To] On Tue, Oct 03, 2000 at 13:52:38 +, Steinitz, Dominic J wrote: Pointer.lhs:103: Couldn't match `AddrOff' against `Int' Expected type: AddrOff Inferred type: Int In the application `toInt i' In the second argument of `plusAddr', namely `(toInt i)' `toInt' is a Glasgow Extension and is considered evil now IIRC (it always was, but there were some efficiency reasons, which are now resolved...) `AddrOff' is instance of `Num', so use `fromIntegral' instead of `toInt'... Cheers, M/ -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 "I WAS NOT TOLD TO DO THIS" -- Bart Simpson in 5F13
Re: Bug in GHC?
On Tue, Jul 25, 2000 at 15:17:27 +0200, Hannah Schroeter wrote: I have this problem with a self compiled GHC, checked out with -rghc-4-07-branch (which should be 4.08, at most with additional commits *on that branch*), checked out about July 18. Btw, the same bug appears on a Debian Linux/x86 system with the binary package ghc4-4.08.0-1 from Michael Weber [EMAIL PROTECTED]. ... which is not surprising, because I checked it out with ``-rghc-4-07-branch'' :-) Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 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: 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 THIS.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]
The Revenge Of The Obnoxious Time Module...
Hi all!
I took a look (or maybe some more) at the well-known, totally buggy
Time module...
I think, I sorted out the main problems and fixed them:
* toClockTime couldn't deal properly with anything but local
TZ-encoded CalendarTime's (i.e. not with UTC-encoded CT's for
example)
* as a result, addToClockTime did weird things
* diffClockTimes, in some situations, gave strange results, i.e. "1
day, -22 hours" instead of "2 hours"
* timeDiffToString always returned "c", regardless of its parameters
[this one was really hard to find ;-)]
For the tedious details, refer to the comments in the patch for
[Time.lhs,Locale.lhs,toClockSec.c]. There's also a BUGS/TODO list with
some open issues... comments welcome!
I tested on Linux, so if someone could try the patch on a Solaris
version of GHC, it would be of greater help.
Besides normal testing and debugging, I recompiled the time001 test
and it still produced the same output, which made me wonder. So I
recompiled it with the old (broken) version of Time and tested again.
Result: running the old time001 like (Bashism ahead)
$ env TZ=foo ./time001
and foo `elem` [CET,EST,PST8,PST8PDT,...] yields different results,
which is clearly wrong, since we're using UTC encoding. Did somebody
ever try to run time001 with a TZ /= UTC or friends? :-)
Anyway, the modified version always yields the same result, regardless
of the TZ setting, which is IMHO The Right Behaviour(tm)...
Oh, BTW: 2 remarks
1) *ahem* Hereby I state, that I really doubt, that anyone has been
using the Time-module for longer than a couple of compilation
runs, ever... ;-)
2) Does anybody know a mail address of the inventor(s) of the Unix
Time Handling Functions (KR, maybe?)? I'd like to "thank" them for
this great stuff... I thought about a source+binary release of
ghc-4.07, tar'ed, uuencoded and piped through hexdump, and of
course, split into 1k-pieces, just to be sure, it gets through...
:-)
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
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.
diff -bur ghc4-4.07.2615.orig/ghc/lib/std/Locale.lhs
ghc4-4.07.2615/ghc/lib/std/Locale.lhs
--- ghc4-4.07.2615.orig/ghc/lib/std/Locale.lhs Thu Jan 14 19:12:51 1999
+++ ghc4-4.07.2615/ghc/lib/std/Locale.lhs Sat Jun 17 13:49:35 2000
@@ -5,13 +5,21 @@
\begin{code}
-module Locale(TimeLocale(..), defaultTimeLocale) where
+module Locale
+( TimeLocale(..)
+, defaultTimeLocale
+
+, iso8601DateFormat
+, rfc822DateFormat
+)
+where
import Prelude -- so as to force recompilations when reqd.
data TimeLocale = TimeLocale {
wDays :: [(String, String)], -- full and abbreviated week days
months :: [(String, String)], -- full and abbreviated months
+intervals :: [(String, String)],
amPm :: (String, String), -- AM/PM symbols
dateTimeFmt, dateFmt, -- formatting strings
timeFmt, time12Fmt :: String
@@ -31,6 +39,15 @@
("September", "Sep"), ("October", "Oct"),
("November", "Nov"), ("December", "Dec")],
+intervals = [ ("year","years")
+, ("month", "months")
+, ("day","days")
+, ("hour","hours")
+, ("min","mins")
+, ("sec","secs")
+, ("usec","usecs")
+],
+
amPm = ("AM", "PM"),
dateTimeFmt = "%a %b %e %H:%M:%S %Z %Y",
dateFmt = "%m/%d/%y",
@@ -38,4 +55,14 @@
time12Fmt = "%I:%M:%S %p"
}
+
+iso8601DateFormat :: Maybe String - String
+iso8601DateFormat timeFmt =
+"%Y-%m-%d" ++ case timeFmt of
+ Nothing - "" -- normally, ISO-8601 just defines -MM-DD
+ Just fmt - ' ' : fmt -- but we can add a time spec
+
+
+rfc822DateFormat :: String
+rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z"
\end{code}
diff -bur ghc4-4.07.2615.orig/ghc/lib/std/Time.lhs
ghc4-4.07.2615/ghc/lib/std/Time.lhs
--- ghc4-4.07.2615.orig/ghc/lib/std/Time.lhsThu May 4 19:03:16 2000
+++ ghc4-4.07.2615/ghc/lib/std/Time.lhs Sat Jun 17 16:23:19 2000
@@ -8,6 +8,109 @@
"time.h", adapted to the Haskell environment), It follows RFC 1129 in
its use of Coordinated Universal Time (UTC).
+CHANGES:
+2000/06/17 [EMAIL PROTECTED]:
+ * `toClockTime' previously didn't honor the `tz' field of a
+`CalendarTime', which led to time warping when applying
+
+ = (toUTCTime (toClockTime ... (toUTCTime (toClockTime someTime) ... )))
+
+continuously.
+
+Now it accepts at least local- and UTC-encoded `CalendarTime's
+(TODO: test, whether all timezones work) and converts
Re: Bug in ghc and mkdependHS scripts?
On Fri, May 26, 2000 at 09:35:20 +0200, S. Achterop IWI-120 3932 wrote: When installing ghc, using a locally make binary-dist, some path's in ghc-4.07 and mkdependHS scripts are given the wrong value. [wrong values in ghc perl driver] You did set BIN_DIST=1 in mk/build.mk or when running `make', didn't you? 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/
How to handle hi-file versionitis/a possible library scheme
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 has already been "compiled" for a particular resolution (dpi), it's re-used; if not, it is created). But here we're talking about binary libraries, and this may rise some security issues. I had something like the following in mind: * Create a new group `ghc' on the system * The library sources are installed under sourcedir/package/ (readonly). sourcedir:=`prefix/share/ghc-libsrc/' * Create spooldir:=`/var/spool/haskell/compiler/version/' for all installed compilers. owner: root.ghc, mode: 3777 (for all dirs below spooldir) hi-files go into spooldir/package/imports/, libs to spooldir/package/ * Make those GHC programs, which write to spooldir, setgid `ghc'. This would ideally be one single program called `ghc-recompile', which has one parameter, package, and handles all the stuff to recompile a library to let it match the compiler version. Of course, ghc-recompile must be designed carefully wrt. to security, i.e. environment cleanup, maybe some protections mechanisms to let programs,scripts,etc. called from within ghc-recompile write exclusively to spooldir/package, logging, limit uids to 100+, etc... ghc-recompile has to be compiled statically to prevent possible misuse by playing tricks with library preloads, etc... * If a needed interface file/library is not found at the appropriate directory in spooldir, and if the sources are available under sourcedir, the library is recompiled. This implies, that there must be some kind of "instruction" (Makefile,script,...) in sourcedir/package/ to rebuild a library version. This script is called by ghc-recompile. So, the admin just has to install the lib sources and the compiler, and if someone wants to use an already installed library, he just _can_! (if s/he's so unfortunate to be the first user, compilation just takes longer this time). Comments? Cheers, Michael -- Of course, we all know that debian/rules... -- Joey Hess
Re: panic! (the `impossible' happened):
On Fri, Feb 04, 2000 at 11:27:19 +0100, George Russell wrote: [...] However I didn't use -Onot. build.mk (minus comments and blank lines was): ^ HAPPY = /usr/local/pub-bkb/ghc/ghc-latest/bin/happy -a -g -c GhcLibHcOpts += -H20m HC_OPTS += -H30m -Onot ^ ? BTW: not giving _any_ optimization options is equivalent to -Onot, IIRC. 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: DocBook tools versionitis?
On Tue, Jan 25, 2000 at 10:33:30 +0100, Sven Panne wrote: Last night's build from CVS failed because of the docs: [...] The `-d' option seems strange: panne@marutea:/usr/src/packages/SOURCES/fptools db2dvi --version db2dvi - docbook-tools 0.5 panne@marutea:/usr/src/packages/SOURCES/fptools db2dvi --help Usage: db2dvi [OPTION]... FILE Run a DocBook SGML document trough various programs. [...] At least debian, (and Redhat IIRC) have different db2xxx tools, it seems... The Debian version of db2dvi (the package name is `cygnus-stylesheets') contains the following lines: [...] # Dave Mason's option to specify a different stylesheet case $1 in -d) DB_STYLESHEET=$2 shift 2 ;; esac [...] IIRC, Sven's version is SuSE home-brewed (and incompatible, of course) ;-)... BTW: I'm, too, not very happy with these db2xxx tools (or jade, the scripts are merely wrappers, IIRC)... the html pages generated from "installation" and "libs" looked better with the old sgmltools. In the current version (with db2html), some links are messed, the generated html files have crappy names... well, this all might go away, once they're truly converted to DocBook, but at least one argument remains: You have to use a stylesheet-capable browser to view the html pages... bye-bye lynx, w3m... :-( Just my $0.02EUR 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/
make in-place broken?
Hi! It seems, `make in-place' on a binary distribution (gen'ed with `make binary-dist Project=Ghc', CVS 2000/01/09) doesn't produce a working system, because: ghc/drivers/ghc-inplace (which I believe is copied to bin/arch/ghc-4.06.prl in the binary dist) contains the following lines: [...] $libdir="/usr/local/lib"; $libexecdir="/usr/local/lib"; $datadir="/usr/local/share"; $bindir="/usr/local/bin"; $TMPDIR="/tmp"; $TOP_PWD="/usr/local"; [...] The `in-place' $*dir variables are cat'ed to the _top_ of ghc-4.06.prl, with the consequence that the variables are overridden with the lines listed above... Is this true, or did I miss an important step? 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: make in-place broken?
On Tue, Jan 18, 2000 at 03:49:35 -0800, Simon Marlow wrote: BIN_DIST=1 in your build.mk file in order to build a binary distribution. I bet that's the problem. In fact, that fixed the problem... thanks cheers, Michael -- Lehrstuhl-BeleuchtungMichael Weber [EMAIL PROTECTED] Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
some patches to CVS ghc from 2000/01/09
Hi!
I had to apply some patches to make today's GHC build, they're attached.
The patch to ghc/mk/paths.mk is necessary, because the ordering of variables
is important when using "simply expanded variables", i.e. the `:=' ones (I'm
using make-3.78.1).
BTW: Might I still suggest to change this CString.lhs:unpackCStringIO case:
\begin{code}
unpackCStringIO :: Addr - IO String
unpackCStringIO addr
| addr == nullAddr = return ""
\end{code}
to:
\begin{code}
unpackCStringIO :: Addr - IO String
unpackCStringIO addr
| addr == nullAddr = return "(null)"
\end{code}
Cheers,
Michael
--
Compaq Safety Comfort Guide:
"Stand up and take a few minutes to stretch and exercise several times a
day."
--- ghc4-4.06.2109/hslibs/lang/CString.lhs.orig Sun Jan 9 16:45:19 2000
+++ ghc4-4.06.2109/hslibs/lang/CString.lhs Sun Jan 9 16:45:11 2000
@@ -75,7 +75,7 @@
ch - readCharOffAddr addr (I# nh)
if ch == '\0'
then return []
- else do
+else do
ls - unpack (nh +# 1#)
return (ch : ls)
--- /tmp/fooSun Jan 9 15:22:36 2000
+++ ghc4-4.06.2109/ghc/mk/paths.mk Sun Jan 9 15:45:22 2000
@@ -25,21 +25,22 @@
GHC_UTILS_DIR := $(TOP)/utils
GHC_INTERPRETER_DIR:= $(TOP)/interpreter
-GHC_INPLACE:= $(GHC_DRIVER_DIR)/ghc-inplace
GHC_HSCPP_DIR := $(GHC_UTILS_DIR)/hscpp
-GHC_HSCPP := $(GHC_HSCPP_DIR)/hscpp
+GHC_HSP_DIR:= $(GHC_HSC_DIR)
+GHC_HSC_DIR:= $(GHC_COMPILER_DIR)
GHC_MKDEPENDHS_DIR := $(GHC_UTILS_DIR)/mkdependHS
+GHC_SYSMAN_DIR := $(GHC_RUNTIME_DIR)/gum
+GHC_UNLIT_DIR := $(GHC_UTILS_DIR)/unlit
+
+GHC_INPLACE:= $(GHC_DRIVER_DIR)/ghc-inplace
+GHC_HSCPP := $(GHC_HSCPP_DIR)/hscpp
GHC_MKDEPENDHS := $(GHC_MKDEPENDHS_DIR)/mkdependHS-inplace
GHC_HSP:= $(GHC_HSP_DIR)/hsp
-GHC_HSP_DIR:= $(GHC_HSC_DIR)
GHC_HSC:= $(GHC_HSC_DIR)/hsc
-GHC_HSC_DIR:= $(GHC_COMPILER_DIR)
GHC_SYSMAN := $(GHC_RUNTIME_DIR)/gum/SysMan
-GHC_SYSMAN_DIR := $(GHC_RUNTIME_DIR)/gum
UNLIT := $(GHC_UNLIT_DIR)/unlit
GHC_UNLIT := $(GHC_UNLIT_DIR)/unlit
-GHC_UNLIT_DIR := $(GHC_UTILS_DIR)/unlit
#-
# Stuff for the C-compiling phase in particular...
Re: strange evaluation problem
On Fri, Jan 07, 2000 at 09:44:09 +0100, Michael Weber wrote: Unfortunately, this neithers explains Sven's problem nor mine, since unpackCStringIO needn't be present to show the error. It seems, today's GHC made the problem disappear (or, at least, it disappeared between 1999/12/06 and 2000/01/09), my test case now works as expected... Sven, what about yours? Did the change happen casually or did somebody put some work in it (if so, thanks! :-) )? Cheers, Michael -- If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. -- Gerald Weinberg
Re: Deadlock again (was Re: GHC 4.04.19990916 produces coredumpin g executable)
On Sun, Jan 09, 2000 at 15:24:03 +, Ian Jackson wrote:
* `foreign' seems to have become a keyword ! My program uses it as a
variable/function name and I had to rename it to avoid a parse error.
I couldn't find anything about it in my documentation.
IIRC, it is only, iff option `-fglasgow-exts' is given, which allows
something like:
\begin{code}
foreign import "foo" bar :: IO ()
\end{code}
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: Deadlock again (was Re: GHC 4.04.19990916 produces coredumping executable)
On Sun, Jan 02, 2000 at 18:36:41 +, Ian Jackson wrote:
-davenant:stalk ./nettlestalk
ready
seqd
nettlestalk: fatal error: No threads to run! Deadlock?
-davenant:stalk
The problem is in NettleAction.hs:
\begin{code}
runGame_noUnitNotifs :: Game - Timestamp - [Callback] - GM rt - (Maybe rt, Game,
[Callback], [Notification])
runGame_noUnitNotifs g ts cbs acts =
let gc = GameContext g ts cbs [] emptySet
(mrt, gc') = runSFM gc acts
(GameContext g' _ cbs' nfs' unfs') | isEmptySet unfs' = gc'
-- ^ ^
in (mrt, g', cbs', nfs')
\end{code}
See the cycle? Removing the guard does the trick (BTW: I tested with 19991206).
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: Still problems with non-blocking I/O?
On Mon, Dec 06, 1999 at 11:34:22 +0900, Manuel M. T. Chakravarty wrote:
Moin GHC Hackers,
I think there is still a problem with non-blocking I/O hosing some shells
on abnormal program termination. This is on Linux, using bash and the
latest sources from CVS.
[...]
This bug is quite annoying, because it makes all ghc compiled programs
unsuitable for normal usage (one Ctrl-C to much and your shell is gone...).
Yes? really? ;-)
Since I'm suffering from this problem for quite a while (Solaris...), I
wrote a Q'n'D C program which resets the standard handles to blocking IO.
Volker Stolz (Hi!) came up with the idea to put it into the shell prompt,
like:
export PS1='`block`\$ '
for bash. The ticks (') are important, otherwise `block' will expand only
only time, and not on every printing of the prompt.
BTW: Volker also told me, that on Solaris the bash sometimes gobbles 99% CPU
time after a GHC compiled program crashed..., this is cured by block.c, too.
Cheers,
Michael
BEGIN
WORKAROUND_FOR_SUICID_ENDANGERED_USERS_BUT_THE_PROBLEM_SHOULD_DEFINITELY_BE
_SOLVED-AREA
block.c:
--
#include stdio.h
#include errno.h
#include fcntl.h
int
block_fd (int fd)
{
int tmp;
if ((tmp = fcntl (fd, F_GETFL, 0)) != -1) {
tmp = ~ O_NONBLOCK;
return fcntl (fd, F_SETFL, tmp);
} else {
perror ("fcntl[GETFL]");
}
return -1;
}
int
main ()
{
block_fd (fileno (stdin));
block_fd (fileno (stdout));
block_fd (fileno (stdin));
}
--
Lehrstuhl-Gärtnerei Michael Weber [EMAIL PROTECTED]
Lehrstuhl für Informatik II
RWTH Aachen
WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
CVS checkout broken?
Hi! If I do a new CVS checkout with $ cvs -d:pserver:[EMAIL PROTECTED]:/cvs co -dfptools-199912 fpconfig I get the whole bunch (CONTRIB, happy, haggis, hdirect, nofib, etc.), despite the `modules' file shows: fpconfig -a !fptools/ghc !fptools/haggis !fptools/happy !fptools/hslibs !fptools/nofib !fptools/green-card !fptools/literate !fptools/hdirect !fptools/common-rts !fptools/CONTRIB fptools Is this a problem with my cvs client or with the repo? 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: Happy v1.6.
On Thu, Sep 30, 1999 at 19:16:48 +0100, Alex Ferguson wrote: My next worry is that when I try to build ghc from source on an Alpha, I'll get bitten on the bum by the ghc-needs-Happy-needs-(recent)-ghc syndrome, or otherwise spend mucho time wrestling with the Happy build setup to get round this. Generate the two happy generated files manually, on a machine with a working happy... ghc/compiler/rename/ParseIface.y ghc/compiler/parser/Parser.y To fool `configure', make a shell script `happy', like: #! /bin/sh cat EOM Happy Version 1.6 EOM Cheers, Michael -- If it doesn't work, force it. If it breaks, it needed replacing anyway.
Re: ghc-4.04, Alpha.
On Fri, Oct 01, 1999 at 02:10:16 +0100, Alex Ferguson wrote: In order to install ghc-4.04, I need to install the binary v. of 2.10 (this should be OK for doing that, right?) Last time I checked (some months ago), GHC 4.x wasn't in a shape that it could be build at all on Alpha architecture! I *dimly* remember problems wrt. some 64bit stuff (missing or duplicated definitions, etc.) If you still want to give it a try, I bet you're *very, very* welcome, but prepare to deeply dive into GHC's sources... :-) /bin/sh: syntax error at line 1: `;' unexpected gnumake[1]: *** [config-pkgs] Error 2 gnumake[1]: Leaving directory `/usr/local/users/abf/ghc210/fptools' gnumake: *** [in-place] Error 2 Looks like a problem in the Makefile, a variable seems to be empty... Cheers, Michael -- Of course, we all know that debian/rules... -- Joey Hess
`forall' subtelties (was: Re: core dumps when making use of IORefs)
On Wed, Sep 22, 1999 at 00:36:27 +0200, Hannah Schroeter wrote:
On Tue, Sep 14, 1999 at 12:43:11AM -0700, Simon Peyton-Jones wrote:
{-# notInline test #-}
test :: IORef [a]
test = unsafePerformIO $ newIORef []
main = do
writeIORef test [42]
bang - readIORef test
print (bang :: [Char])
Hmmm. The type of test should be IORef (forall a.[a]).
So you should be able to put into it only values of type
forall a.[a], nothing more or less specific.
GHC doesn't accept the type `IORef (forall a.[a])':
ghc-test.hs:6: Unexpected forall type: forall a. [a]
Compilation had errors
I also tried `IORef [forall a.a]', which gives:
ghc-test.hs:6: parse error on input `forall'
Compilation had errors
and `IORef [(forall a.a)]', which gives:
ghc-test.hs:6: Unexpected forall type: forall a. a
Compilation had errors
At least, the latter two cases should IMHO be treated equal, so this seems
to be a bug in the parser.
Finally, I tried `forall a.IORef [a]' (as only change), but this is just a
more verbose writing of `IORef [a]' according to Haskell Report#4.1.2 and
GHC-users-guide#5.6. Naturally, the program compiles and dumps core as
before.
Cheers,
Michael
--
The First Commandment for Technicians:
Beware the lightening that lurketh in the undischarged capacitor,
lest it cause thee to bounce upon thy buttocks in a most untechnician-like
manner. -- fortune cookie
version numbering
Hi!
The latest CVS GHC doesn't compile with older 4.04 versions (George Russell
already reported this, IIRC). The reason are the following files:
ghc/compiler/basicTypes/Const.lhs
ghc/compiler/coreSyn/CoreUnfold.lhs
ghc/compiler/deSugar/DsForeign.lhs
ghc/compiler/nativeGen/StixInfo.lhs
ghc/compiler/simplCore/ConFold.lhs
ghc/compiler/typecheck/TcGenDeriv.lhs
All of them have something like:
\begin{code}
#if __GLASGOW_HASKELL__ = 404
import GlaExts ( fromInt )
#endif
\end{code}
I had to change this stuff, compile GHC, install it (this one is now capable
of compiling itself), undo the changes and then compile it again with the
newly generated GHC.
Two compilation runs are not a problem, since I always compile GHC twice,
but changing and undoing the changes wasn't fun (at least, not at 3am :-))
So: next time, can you please increase the minor number instead of just the
patch level (or find a way to make the #ifdef's honor the patchlevel, too)
Just my 0.02 Euro...
Cheers,
Michael
Re: GHC, GCC 2.95 on Sparc Solaris, and PrelList.hi
On Wed, Aug 25, 1999 at 11:04:27 +0200, George Russell wrote: I am trying to get GHC, with the latest PrimOps.h fix, to compile with gcc 2.95 on Sparc Solaris. I now have an hsc but it doesn't get very far with compiling the standard library because when it gets to PrelEnum.lhs, it complains that *hmm* wasn't the latest fix (the "mummy, don't overwrite my operands" one) just i386 specific? [...] What is going on? It would be nice if I could at last stop using a prehistoric version of GCC . . . at least 2.8.1 works on Solaris... Cheers, Michael -- W*ndoze NT is faster... CRASHING!
Re: Large FiniteMap causes SIGSEGV in ghc-4.04
On Sat, Aug 21, 1999 at 11:59:25 +, Marcin 'Qrczak' Kowalczyk wrote: import FiniteMap main = print . fmToList . listToFM $ [(i,0) | i - [1..3]] This program simply segfaults. With less than 2 elements it works. With ghc-4.02 it works. *hmm* this works with ghc-4.04 of 1999/08/03 on Linux, but I had to increase stack size, i.e. ./fmtest +RTS -K2M Also, I have a project that generates big finite maps (5+ elements, ~30M mem) and had never problems with that (on Solaris and Linux)... 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: Field label bug?
On Mon, Aug 16, 1999 at 16:40:30 -0500, Michael Hobbs wrote:
Is this a bug with ghc-4.04 or just a "feature" of Haskell 98 that I was
unaware of? I get a parse error with the following code:
data Point = Pt {pointx, pointy :: Float}
abs (Pt {pointx, pointy}) = sqrt (pointx*pointx + pointy*pointy)
*hmm* at least hugs also complains:
ERROR "recs.hs" (line 2): Haskell 98 does not support missing field bindings
But you can also do:
\begin{code}
abs (Pt pointx pointy) = sqrt (pointx*pointx + pointy*pointy)
\end{code}
if you don't want to mention field names...
Cheers,
Michael
--
Today, signature's out...
works (was: Re: ghc from CVS (1999/07/31) throws core...)
On Tue, Aug 03, 1999 at 01:49:36 -0700, Simon Marlow wrote: Yesterday's sources were fully broken due to a bogus commit made by me. Things should be ok now. Bad luck to me :-( However, I just wanted to give some feedback that now it's working again (1999/08/03) on Linux (packages downloadable this afternoon). Cheers, Michael -- W*ndoze NT is faster... CRASHING!
ghc from CVS (1999/07/31) throws core...
Hi! I tried to recompile the latest ghc (1999/07/31) on a Linux/glibc2.1.1 system (egcs 2.91.66), but there seems to be a problem: the build works, but the resulting compiler produces executables, that throw core, even with "main = return ()". I have a CVS version from 1999/07/10, and this one works. I subsequently recompiled this version with itself several times, no problem. Since the old version still compiles (I tried this night), and also Manuel produced a glibc2.1 version of ghc: did anyone change some parts of the rts or compiler, that could be touchy to specific glibc versions? Or is the problem related elsewhere? I wish, I could have provided more debugging info, but strace's and gdb's output isn't very helpful at all. How do I enable those IF_DEBUG(...) macros (or something that helps tracking down the problem)? I tried, but it seems I overlooked something... However, I "hello-debugged" the problematic version and traced it to ghc/rts/Schedule.c: case ThreadEnterGHC: ret = StgRun((StgFunPtr) stg_enterStackTop); The case statement is reached, but then the segmentation fault happens somewhere in StgRun() or something it calls (*hmm* I don't regard this info as very helpful at all, since this is pretty early in the startup process...) Cheers, Michael -- * Software Engineering is like looking for a black cat in a dark room in which there is no cat. * 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: ghc from CVS (1999/07/31) throws core...
On Mon, Aug 02, 1999 at 12:54:23 +0100, Marc van Dongen wrote:
[...]
I've noticed that as well. Code like
does not produce proper error messages anymore which it did with
ghc-4.02. One wonders where the performance boost came from:-)
$ cat tmp.lhs
module Main( main ) where
main = putStr $ show q
where q = quot 1 0
[...]
$ a.out
Arithmetic Exception (core dumped)
Yes, but:
\begin{code}
module Main( main ) where
main = putStr $ show q
where q = quot 1 (0::Int)
\end{code}
gives: Fail: Prelude.Integral.quot{Int}: divide by 0
IIRC, Integer isn't Div-By-Zero-checked (for performance reasons).
But my core dumps, don't give any "blahblah exception (core dumped)"
messages. The programs just die (at a very early stage). I still think, it's
something with glibc stuff...
Cheers,
Michael
--
XXXVI: The thickness of the proposal required to win a multimillion dollar
contract is about one millimeter per million dollars. If all the
proposals conforming to this standard were piled on top of each other
at the bottom of the Grand Canyon it would probably be a good idea.
Makefile cleanups
Hi! I attached a patch that does some additional cleanups to a build tree (equiv.: makes the packager's life easier ;-)) I wasn't sure, which files should go into $(CLEAN_FILES) and which into $(MAINTAINER_CLEAN_FILES), maybe someone could have a look at my choice. regarding the perl scripts: they're modules, i.e. not standalone-executable, so there shouldn't be the '#!'-hack on top of them. It does no harm, but causes two Debian-related errors, which go away when removing the line... 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!" --- ghc4-4.04.orig/glafp-utils/sgmlverb/Makefile +++ ghc4-4.04/glafp-utils/sgmlverb/Makefile @@ -7,6 +7,8 @@ override SRC_FLEX_OPTS=-8 +CLEAN_FILES += sgmlverb.c + # # For src distributions, include flex output. # --- ghc4-4.04.orig/mk/target.mk +++ ghc4-4.04/mk/target.mk @@ -921,6 +921,7 @@ ps :: $(SGML_PS) CLEAN_FILES += $(SGML_TEXT) $(SGML_DOC)*.html $(SGML_PS) $(SGML_DVI) +MOSTLY_CLEAN_FILES += $(patsubst %.vsgml, %.sgml, $(VSGML_SRCS)) #can't use +$(SGML_SRCS), they're maybe needed endif --- ghc4-4.04.orig/ghc/compiler/Makefile +++ ghc4-4.04/ghc/compiler/Makefile @@ -287,6 +287,8 @@ # Extra tidy, remove the .hc files (if you've got them). MAINTAINER_CLEAN_FILES += $(wildcard */*.hc) +# Remove happy generated files +MAINTAINER_CLEAN_FILES += $(patsubst %.y,%.hs,$(wildcard */*.y)) #- --- ghc4-4.04.orig/ghc/docs/Makefile +++ ghc4-4.04/ghc/docs/Makefile @@ -6,6 +6,6 @@ # export WAYS= -SUBDIRS = users_guide +SUBDIRS = libraries users_guide include $(TOP)/mk/target.mk --- ghc4-4.04.orig/ghc/utils/stat2resid/parse-gcstats.prl +++ ghc4-4.04/ghc/utils/stat2resid/parse-gcstats.prl @@ -1,4 +1,3 @@ -#!/local/sun4/bin/perl # # Subroutines to parses a ghc Garbage Collection stats file # --- ghc4-4.04.orig/ghc/utils/stat2resid/process-gcstats.prl +++ ghc4-4.04/ghc/utils/stat2resid/process-gcstats.prl @@ -1,4 +1,3 @@ -#!/local/sun4/bin/perl # # Subroutines which derive information from # ghc garbage collection stats -- %gcstat
more quirks...
Hi!
now, this is interesting:
\begin{code}
data Foo label = Const
main = print 1
\end{code}
"ghc-4.04 -c test.hs" works, but "ghc-4.04 -fglasgow-exts -c test.hs" yields:
Foo label
test.hs:2: Illegal data/newtype declaration
Compilation had errors
Instead of 'label', using 'unsafe', 'export' or 'dynamic' results in the
same behaviour. I can't remember having this with 4.02 or less...
Cheers,
Michael
BTW: ghc-4.04's parser generated by Friday's CVS happy
--
Don't worry, honey, just two more lemmas ...
Re: Reading 8bit characters from a socket fails
On Fri, Jul 02, 1999 at 01:59:25 -0700, Simon Marlow wrote: rm -f PrelBase.o ; if [ ! -d PrelBase ]; then mkdir PrelBase; else find PrelBase -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelBase -H10m -optCrts-M128M -c PrelBase.lhs -o PrelBase.o -osuf o make[3]: *** [PrelBase.o] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 This smells like the glibc-2.1 problem. *hmm* if this is a linux system, I'd bet it is a memory overcommitment/trashing problem. Linux just shot ghc, because there is too less memory. The original poster said something about 32Megs... IMHO you'll need 128M++, otherwise the machine gets into serious swapping if you try to compile 4.04 with 4.04, for example... :-) for older versions, it's _slightly_ better. We've now got a RH 6 machine (Dual PIII-500 ... mmm, yummy), so I'll take a look at this today. Sounds great... did you follow the 'zombie problem' mails of Kirstin and me, when telling make to do more than one job at a time? The subject was "smp and make"... Cheers, Michael
parser quirks...
Hi!
consider this piece of code:
\begin{code}
class Dumb a where
foo, death, something :: a
instance Dumb Int where
foo = 1
death =
something = 1
\end{code}
yields 'Internal Happy error' with CVS from 1999/06/30 and happy-1.5 (sorry,
I didn't check out the CVS version of happy by now, so I cannot test that...)
BTW: is it just me, or does someone else notice, that every new version of
ghc takes more memory to compile itself? :-)
for example: rename/ParseIface.hs from 4.04 compiled with 4.04 needs about
'-H120m' and ghc says in "ghc: ..." something about 4.5 *GIGABYTES*! 8-O
And parser/Parser.hs will probably need a bigger '-Hsize'... (couldn't
test that, I'll upgrade memory tomorrow ;-))
There isn't a simple way to let happy split the generated files into smaller
pieces, is it? However, would that knock down memory usage?
Cheers,
Michael
--
Compaq Safety Comfort Guide:
"Use the minimum amount of force that is needed to push down the keys. Avoid
banging on the keys using more force than is required."
ghc/rts/Makefile issue
Hi! does it any harm to include the appended patch? Otherwise, StgRun.p_o and callfun.p_o won't get cleaned out... I did a successful build with this patch, so it doesn't seem to break things... Cheers, Michael --- ghc/rts/Makefile.orig Tue Jun 29 08:40:32 1999 +++ ghc/rts/MakefileTue Jun 29 08:40:50 1999 @@ -64,7 +64,7 @@ SRC_HC_OPTS += -I$$PVM_ROOT/include endif -C_SRCS = $(SRCS_RTS_C) $(SRCS_RTS_HC) # $(SRCS_RTS_S)??? +C_SRCS = $(SRCS_RTS_C) $(SRCS_RTS_HC) $(SRCS_RTS_S) SRC_MKDEPENDC_OPTS += -I. -I../includes
Re: smp and make
On Wed, Jun 16, 1999 at 15:57:00 -0400, Kirstin S. Reese wrote: when building ghc on an smp machine, gmake arguments of -j ?? are overridden by -rj 1, in an unneccesary fashion. However, I cannot find where this is defined for MFLAGS. Any one know about this? Hi! Actually, this is normal behaviour of make (see: make.info: "Communicating Options to a Sub-`make'"). If you call the toplevel make with option "-jval", all sub-make's get "-rj 1", only. You could try just "-j", this is passed along to all sub-makes without change, but the number of parallel jobs isn't limited... useless, unless you do have a *really* big machine with lots of processors and mem :-) BTW: (1) you could also try to use "-j -lmax-load", which limits the number of jobs according to the load value specified, but this isn't a real solution, try and you'll see why... (2) I modified ghc/Makefile to add "-j2" explicitly to MFLAGS, but then, after some time, the ghc's turned into zombies... (same with (1))... strange... I didn't figure out why this happened, can somebody test this? Cheers, 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: switch -M ambiguous to ghc
On Thu, Jun 24, 1999 at 16:55:29 +0200, Michael Weber wrote: When I set too big heapsize values... [blah removed] Sorry for that, guys, -optCrts-M seems to be the switch of choice... my apologies, Michael -- No sig is good sig...
happy in aclocal...
Hi! This tiny patch to aclocal.m4 lets "./configure" reject happy versions below 1.4. They won't work with ghc, anyway... :-) Cheers, Michael --- aclocal.m4.orig Thu Jun 24 15:36:06 1999 +++ aclocal.m4 Thu Jun 24 15:37:22 1999 @@ -147,9 +147,10 @@ else fptools_cv_happy_version=""; fi; -if expr "$fptools_cv_happy_version" "" 1.4 /dev/null 21; then +min_happy_version=1.5 +if expr "$fptools_cv_happy_version" "" "$min_happy_version" /dev/null 21; then echo - echo "Happy version 1.4 or later is required to compile GHC." + echo "Happy version $min_happy_version or later is required to compile GHC." exit 1; fi; ]) -- No sig is good sig...
switch -M ambiguous to ghc
Hi!
When I set too big heapsize values with option '-H', hsc complains about
something like "-Hsize bigger than -Msize". Since ghc won't compile (*)
with lower -H values (yes, -dcore-lint also applied), I added "-Msize" to
the command line... AND: it doesn't work!
(*) this happened when compiling ghc-cvs with ghc-4.02 on Linux/x86.
ghc complains about not knowing this switch and "ghc --help" says, "-M" does
something different...
In fact, there is IMHO no way to hand over "-Msize" to hsc...
I patched ghc.lprl, which now has a parameter "-MMsize", yielding an
additional "-Msize" to hsc...
patch is attached...
Cheers,
Michael
--
No sig is good sig...
--- ghc/driver/ghc.lprl.origThu Jun 17 11:03:18 1999
+++ ghc/driver/ghc.lprl Thu Jun 24 15:32:55 1999
@@ -212,6 +212,7 @@
# terrible things to cache behavior.
#
$Specific_heap_size = 6 * 1000 * 1000;
+$Specific_mem_size = 70 * 1000 * 1000;
$Specific_stk_size = 1000 * 1000;
$Scale_sizes_by = 1.0;
@@ -1198,6 +1199,8 @@
sub setupHeapStackSize {
$Specific_heap_size = $Specific_heap_size * $Scale_sizes_by;
push(@HsC_rts_flags, '-H'.$Specific_heap_size);
+ $Specific_mem_size = $Specific_mem_size * $Scale_sizes_by;
+ push(@HsC_rts_flags, "-M$Specific_mem_size");
$Specific_stk_size = $Specific_stk_size * $Scale_sizes_by;
push(@HsC_rts_flags, "-K$Specific_stk_size");
}
@@ -3205,6 +3208,27 @@
$Specific_heap_size = $heap_size;
} else {
print STDERR "$Pgm: ignoring heap-size-setting option ($_)...not the
largest seen\n";
+ }
+ next arg; };
+
+/^(-MM|-Rmax-memsize)(.*)/ do {
+ local($mem_size) = grab_arg_arg(*Args,$1, $2);
+ if ($mem_size =~ /(\d+)[Kk]$/) {
+ $mem_size = $1 * 1000;
+ } elsif ($mem_size =~ /(\d+)[Mm]$/) {
+ $mem_size = $1 * 1000 * 1000;
+ } elsif ($mem_size =~ /(\d+)[Gg]$/) {
+ $mem_size = $1 * 1000 * 1000 * 1000;
+ }
+ if ($mem_size = 0) {
+ print STDERR "$Pgm: resetting mem-size to zero!!! $mem_size\n";
+ $Specific_mem_size = 0;
+
+ # if several heap sizes given, take the largest...
+ } elsif ($mem_size = $Specific_mem_size) {
+ $Specific_mem_size = $mem_size;
+ } else {
+ print STDERR "$Pgm: ignoring mem-size-setting option ($_)...not the
+largest seen\n";
}
next arg; };
CVS ghc: Internal happy error with happy-1.4
Hi! Maybe someone wants to document that the CVS ghc from the last few days (since yacc-happy parser shift?) does not work with happy-1.4. Nevertheless it works with happy-1.5. The offending part (although IMHO Printf.lhs is *NOT* the problem!): ==fptools== make all --no-print-directory -r; in /opt/i2/work2/install/ghc/cvs/fptools-solaris2.7/ghc/lib/misc rm -f Printf.o ; if [ ! -d Printf ]; then mkdir Printf; else find Printf -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -K32m -H100m -dcore-lint -I. -i../posix -i../concurrent -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir Printf -static-c Printf.lhs -o Printf.o -osuf o Internal Happy error make[3]: *** [Printf.o] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 Cheers, Michael
Non-exhaustive patterns in function provSrcLoc
Hi!
Yes, I know, the following code snippets are wrong, because instances are
always imported. The compiler yields an error message, like it should:
Foo1.lhs:2:
Duplicate or overlapping instance declarations
for `Read FooData'
Name.lhs:382: Non-exhaustive patterns in function provSrcLoc
But the "Non-exhaustive patterns" error shouldn't be there, should it?
BTW: is it possible to show the names of the overlapping modules?
Cheers,
Michael
\begin{code}
module Data where
data FooData = FooData
\end{code}
\begin{code}
module Foo2 where
import Data
instance Read FooData where
readsPrec _ _ = [(FooData,"")]
\end{code}
\begin{code}
module Foo3 where
import Data
instance Read FooData where
readsPrec _ _ = [(FooData,"")]
\end{code}
\begin{code}
module Foo1 where
import Data
import Foo2
import Foo3
data Baz = Baz deriving Read -- if this line is commented out - no error
trigger = FooData -- else, if this line is commented out - no error
-- instances only imported if used?
\end{code}
--
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.
Modules with empty export lists
Hi!
The following code produces:
MTest.lhs:2:10: parse error on input: ")"
although this should be perfectly ok... consider a module that just imports
instance declarations...
Cheers,
Michael
\begin{code}
module M() where
instance Show ...
\end{code}
--
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.
Makefile error
Hi! when compiling with Readline support, the compiler (today's CVS) exits, because the posix library is build too late... The appended patch cures this (this is BTW mentioned in the Makefile :-)). Also, there are two obsolete files, which prevent ghc from being build with Readline support. Simply removing ghc/lib/misc/cbits/ghcReadline.[ch] solves it. Cheers, Michael --- ghc/lib/Makefile.orig Fri Jun 11 09:54:22 1999 +++ ghc/lib/MakefileFri Jun 11 09:54:13 1999 @@ -15,7 +15,7 @@ ifeq "$(GhcWithHscBuiltViaC)" "YES" SUBDIRS = std exts else -SUBDIRS = std exts concurrent misc posix +SUBDIRS = std exts concurrent posix misc endif include $(TOP)/mk/target.mk
aclocal.m4 and more than one compiler installed
Hi!
When compiling on a site which has more than one gcc installed, this might
help:
--- aclocal.m4.orig Mon Jun 7 11:32:23 1999
+++ aclocal.m4 Mon Jun 7 11:33:04 1999
@@ -291,7 +291,7 @@
[AC_CACHE_CHECK([how to invoke GNU cpp directly], fptools_cv_gnu_cpp,
[if test "$HaveGcc" = "YES"; then
echo conftest.c
- gcc -v -E conftest.c /dev/null 2conftest.out
+ $CPP -v conftest.c /dev/null 2conftest.out
# \x5c = backslash
echo 'tr/\x5c/\//; /(\S+\/)cpp/ print "[$]{1}cpp -iprefix [$]1";'
conftest.pl
fptools_cv_gnu_cpp="`eval $PerlCmd -n conftest.pl conftest.out`"
If not "$CPP", "$CC -E" should do the same...
Cheers,
Michael
ghc-4.02 picky about trailing whitespaces
Hi!
ghc-4.02 seems to be picky about trailing spaces, i.e.
{-# OPTIONS -fglasgow-exts #-}|- EoLn
is ok, but
{-# OPTIONS -fglasgow-exts #-} |- EoLn
is not recognized... I don't think, that's a good idea...
Cheers,
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.
different behaviour of ghc-4.02 and ghc-pre-4.03
Hi! Consider the following program: data Msg = Value Int | Inc deriving (Show, Read) main = do let v = read "Value 7"::Msg print v When compiled with ghc-4.02, everything's fine, it outputs "Value 7" as expected. But compiled with ghc-pre-4.03 it yields this error message. Fail: Prelude.read: no parse I'm using ghc-pre-4.03-sparc-solaris2.tar.gz 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.
Re: gcc 2.8.1 / egcs on Sparc
On Wed, May 19, 1999 at 08:21:27 -0700, Simon Marlow wrote: [MYSELF wrote]: 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... I probably wasn't clear about this: you need to make this change to the Yes, after it failed _without_ changing the working compiler, I modified this one, too, i.e. I modified both... eg. if you're building 4.02 with 4.01: apply the patch to both 4.01 and 4.02, rebuild 4.02, and you should have a working 4.02. Just to be sure, I changed it, "make clean"'ed and compiled it again... I checked, that the right ghc-asm.prl is in the @INC-Path and that it is modified, also in both compilers... Nevertheless, it still BUS ERRORs. More ideas? Is there a way to track the problem down? 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.
Readline in ghc-4.02
Hi! The Readline.hi file is missing in the i386-linux-glibc binary distribution of ghc-4.02pl0. I took the source distrib., configure'ed it, linked ghc-4.02 of the binary distribution to fptools/ghc/drivers/ghc (unfortunately I was not able to fully compile ghc-4.02, it swapped to death, but that's a memory issue... :-(). Then I cd'ed to fptools/ghc/lib and executed make. This is what happened: [...] ==fptools== make way=p all; PWD = /mnt/sda5/src/fptools/ghc/lib/std rm -f Array.p_o ; if [ ! -d Array ]; then mkdir Array; else find Array -name '*.p_o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir Array -hisuf p_hi -prof -GPrelude -c Array.lhs -o Array.p_o -osuf p_o Array.lhs:41: Could not find valid interface file Ix' Array.lhs:42: Could not find valid interface file PrelList' Array.lhs:43: Could not find valid interface file PrelArr' Array.lhs:44: Could not find valid interface file PrelBase' Compilation had errors make[1]: *** [Array.p_o] Error 1 make: *** [all] Error 1 Ix.hi *does* exist! Any hints? Michael
Re: Why can't GHC print out these strings?
On Fri, Nov 05, 1999 at 15:59:29 +0100, George Russell wrote: Long.hs looks fairly simple to me. However when compiled with ghc -O2, I get a segmentation fault: ghc Long.hs -o long -O2 ./long Segmentation Fault works, regardless of '', '-O', '-O2'... ABC.hs is a little more complicated (it generates an infinite string of ABCs containing no consecutive equal sequences). Whatever I do (ghc, ghc -O or ghc -O2) it falls over with: Fail: resource exhausted Action: writeChunks Reason: insufficient resources works, too... Just tested on: GHC: 4.04-19991022 OS: Solaris 2.7 GHC: 4.04-19990813 OS: Solaris 2.7 GHC: 4.04pl1 OS: Linux Cheers, Michael -- standard construction, def: "sort of a mathematical equivalent of 'hey you'" -- Phil Wadler, "Monads"
