Subject: message
[This message is sent through a WWW-Email gateway.]
[The authenticity of the sender can not be validated.]
[Message sent from the following machine - 64.208.99.35 ]
[after accessing this URL http://www.dcs.gla.ac.uk/scripts/global/send_message?glasgow-haskell-users@dcs.gla.ac.uk+message]
--
Hi,
I am facing problems with dynamic linking under Linux. For example I have two programs , test.cxx and client.cxx. I compile test.cxx to get a shared library. Now test.cxx has a function called callme() which is not declared but not defined. I could compile this to get the .so. However , on trying to compile , client.cxx with this .so, I get undefined reference to callme(). Note that client.cxx DOES NOT call the function callme().
Is there a way to go around this problem and get the linker to search for only those functions which are called ?
I would be greatly indebted 2 U if U could suggest a way out.
Thanking you in anticipation,
Pradipto Kolay
Design Engineer (Wipro GE Medical Systems)
Pradipto.kolay@geind.ge.com
Code :
Test.cxx -
#include <iostream.h>
char *printhello()
{
cout << "Hello world " << endl << flush;
}
void func()
{
callme();
}
gcc -shared -embedded-relocs -o libTest.so test.o
(Works fine)
client.cxx -
#include <iostream.h>
extern char *printhello(void );
main()
{
printhello();
}
g++ -v client.cxx -L. -Bdynamic -lTest
O/P :
./libTest.so: undefined reference to `callme'
collect2: ld returned 1 exit status
g++: file path prefix `dynamic' never used
--
From Dominic.J.Steinitz@BritishAirways.com Mon Jan 15 09:08:13 2001
Date: 15 Jan 2001 09:08:13 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: Too Strict?
Can someone help? The program below works fine with small files but when I try to use it on the one I need to (about 3 million lines of data) it produces no output. The hard disk is hammered - I assume this is the run time system paging. My suspicion is that the program is trying to read in the whole file before processing it. Is this correct? If so, how do I make the program lazy so that it processes a line at time?
By the way, the MD5 function which I use and is included as part of HSLIBS has the type String -> IO String. The MD5 algorithm really is a function and should have type String -> String. Do people agree and if so how do I get it changed?
Dominic.
-- Compile with ghc -o test test.hs -static -package util
-- under Windows.
module Main(main) where
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
import MD5
import Char
-- showHex and showHex' convert the hashed values to
-- human-readable hexadecimal strings.
showHex :: Integer -> String
showHex =
map hexDigit .
map (fromInteger . (\x -> mod x 16)) .
takeWhile (/=0) .
iterate (\x -> div x 16) .
toInteger
hexDigit x
| (0 <= x) && (x <= 9) = chr(ord '0' + x)
| (10 <= x) && (x <=16) = chr(ord 'a' + (x-10))
| otherwise = error "Outside hexadecimal range"
powersOf256 = 1 : map (*256) powersOf256
showHex' x =
showHex $
sum (zipWith (*)
(map ((\x -> (mod x 16)*16 + (div x 16)) .
toInteger .
ord) x)
powersOf256)
-- The type Anon and function anonymize hide the anonymisation
-- process. In this case, it's a hash function
-- digest :: String -> IO String which implements MD5.
type Anon a = IO a
class Anonymizable a where
anonymize :: a -> Anon a
-- MyString avoids overlapping instances of Strings
-- with the [Char]
data MyString = MyString String
deriving Show
instance Anonymizable MyString where
anonymize (MyString x)
= do s <- digest x
return ((MyString . showHex') s)
instance Anonymizable a => Anonymizable [a] where
anonymize xs = mapM anonymize xs
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
a <- anonymize((map MyString) (lines s))
hPutStr h (unlines (map (\(MyString x) -> x) a))
main = readAndWriteAttrVals
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From C.Reinke@ukc.ac.uk Mon Jan 15 14:56:46 2001
Date: Mon, 15 Jan 2001 14:56:46 +0000
From: C.Reinke C.Reinke@ukc.ac.uk
Subject: Too Strict?
> Can someone help? The program below works fine with small files but when I
> try to use it on the one I need to (about 3 million lines of data) it
> produces no output. The hard disk is hammered - I assume this is the run time
> system paging. My suspicion is that the program is trying to read in the
> whole file before processing it. Is this correct? If so, how do I make the
> program lazy so that it processes a line at time?
I was about to apply GHood to your program to see whether such a tool could
help to find the problem, so I started to cut down your code. However,
in the simplified version of the program, one can see what is going on
without any graphical tool.. (nevertheless, observation of the simplified
code with GHood confirms your suspicion immediately, and it points out
the spine of the list as the problem, too, so the tool is useful!-) (*)
In effect, your anonymize comes down to a "mapM" over a list of actions
applied to input lines, and all of the resulting IO-actions are placed
before the single "hPutStr". So, even if the results of the individual
actions in the list may not be needed until later, the whole spine of
the list of lines has to be traversed before "hPutStr" can be executed,
meaning that all input is read before any output is produced (and thus
before any computation results are requested, blowing up memory usage).
For the problem at hand, you could simply output each line as it is
processed instead of just returning it into a list for later use (see
variant _1 below). If you would want to keep both the modular program
structure and the explicit line-by-line IO-style, you would need to
interleave the input and output commands somehow (perhaps similar to
variant _2 below?).
Hth,
Claus
(*) Please note that our web-server is being upgraded today..
(web-pages and GHood download will not be available until
tomorrow, hence no URL here :-(
PS The simplified code (+ variations) with observations:
module Main(main) where
import Observe
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
let action l = return (':':l)
a <- mapM action (observe "input" (lines s))
hPutStr h (unlines (observe "output" a))
main = runO readAndWriteAttrVals
readAndWriteAttrVals_1 =
do h <- openFile fileout WriteMode
s <- readFile filename
let action_and_output l = hPutStr h (':':l)
mapM_ (observe "output" action_and_output) (observe "input" (lines s))
main_1 = runO readAndWriteAttrVals_1
readAndWriteAttrVals_2 =
do h <- openFile fileout WriteMode
s <- readFile filename
let { action l = return (':':l)
; as = map action (observe "input" (lines s))
; os = repeat (hPutStr h)
}
mapM id (observe "output" (zipWith (>>=) as os))
main_2 = runO readAndWriteAttrVals_2
From simonmar@microsoft.com Tue Jan 16 11:06:53 2001
Date: Tue, 16 Jan 2001 03:06:53 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: bootstrapping GHC
[ Moved to glasgow-haskell-users@haskell.org... ]
> I found the mailing list discussion on generating the hc boot
> files and
> unregisterized code after a tip from Michael Weber and will eventually
> get around to trying to bootstrap on Linux/PPC.
>
> On the other hand, I'm running into a bit of trouble on the
> SPARC. It's
> actually an UltraSPARC (sparc64). My assumption was that
> ordinary SPARC
> code should just run on it. What's actually happen is illegal
> instructions
> everywhere. The one that seems to stop me dead cold every
> time is here:
>
> 00000000009c4cfc <PrelMain_mainIO_info>:
> 9c4cfc: 00 9c 4c f8 bn 10d80dc <_end+0x69bff4>
> 9c4d00: 00 00 00 00 unimp 0
> 9c4d04: 00 11 00 01 unimp 0x110001
>
> and this is in hsc, which is as far into the bootstrap as I got.
>
> This disassembly looks wrong to me. Perhaps asm mangling is needed; I
> had -fno-asm-mangling set because the assembler was barfing
> on prologue
> nonsense. I'll be looking into that, as I'm not very familiar with the
> real guts of the compiler, or, for that matter, modern SPARC's.
If you're doing an unregisterised bootstrap, there shouldn't be any
problem with assembly mangling since you're just using the OS's native C
compiler (preferably gcc). Although we do have one or two bits of
inline assembly which might be upsetting things: ASSIGN_DBL and PK_DBL
in ghc/includes/StgMacros.h spring to mind.
The PPC folks, particularly Atze Dijkstra <atze@cs.uu.nl> who did the
recent MacOS X port, have gone through the whole unregisterised
bootstrap process recently so they should be able to help. Guys?
Cheers,
Simon
From chak@cse.unsw.edu.au Wed Jan 17 00:11:08 2001
Date: Wed, 17 Jan 2001 00:11:08 GMT
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Do *you* understand GHC?
Neither do I, but I am pretending to:
http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/
This is a - so far, very small - set of notes on GHC
internals to assist my weak memory. Maybe it is also useful
for others.
Cheers,
Manuel
From ger@tzi.de Wed Jan 17 11:22:45 2001
Date: Wed, 17 Jan 2001 12:22:45 +0100
From: George Russell ger@tzi.de
Subject: 4.08.2
Any idea yet when 4.08.2 is going to be released? The bugs I reported some time ago
are now getting to be a serious nuisance. I've tried compiling the 4.08 branch from
source, but thanks to some as-yet-unclarified infelicity in gcc or ghc, I get
a segmentation fault from the resulting hsc.
From simonmar@microsoft.com Wed Jan 17 13:47:49 2001
Date: Wed, 17 Jan 2001 05:47:49 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: An Haskell compilation server
[ moved to glasgow-haskell-users@haskell.org... ]
> Wed, 17 Jan 2001 01:49:25 -0800, Simon Marlow
> <simonmar@microsoft.com> pisze:
>
> > Funny you should say that. The next version of GHC (5.00 - to be
> > released soon) will have hmake-like functionality enabling it to
> > compile multiple modules without exiting,
>
> How to specify .c files to be linked in?
>
> Or to not bother with linking so I will link manually.
No way to do either at the moment. These would be nice things to have
though.
Cheers,
Simon
From Keith.Wansbrough@cl.cam.ac.uk Mon Jan 22 16:38:36 2001
Date: Mon, 22 Jan 2001 16:38:36 +0000
From: Keith Wansbrough Keith.Wansbrough@cl.cam.ac.uk
Subject: Do *you* understand GHC?
> Neither do I, but I am pretending to:
>
> http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/
>
> This is a - so far, very small - set of notes on GHC
> internals to assist my weak memory. Maybe it is also useful
> for others.
Great!! See also Olaf Chitil's old paper on implementing an optimisation pass in GHC:
@UnPublished{
Chitil97:Adding,
author="Olaf Chitil",
title="Adding an Optimisation Pass to the {G}lasgow {H}askell {C}ompiler",
month=nov # " 4",
year="1997",
documentURL="http://www-i2.informatik.RWTH-Aachen.de/~chitil/",
status="copy,unverified",
}
--KW 8-)
--
Keith Wansbrough <kw217@cl.cam.ac.uk>
http://www.cl.cam.ac.uk/users/kw217/
Cambridge University Computer Laboratory.
From ger@tzi.de Tue Jan 23 21:07:10 2001
Date: Tue, 23 Jan 2001 22:07:10 +0100
From: George Russell ger@tzi.de
Subject: 4.08.2
George Russell wrote:
>
> Any idea yet when 4.08.2 is going to be released?
[snip]
Since the absence of any reply presumably means "not for a while yet",
could someone let me have a compiled hsc for the ghc-4.08 head
on something reasonably close to SunOS/sparc Ultra-1?
From Sven.Panne@informatik.uni-muenchen.de Tue Jan 23 22:22:50 2001
Date: Tue, 23 Jan 2001 23:22:50 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: 4.08.2
George Russell wrote:
> Since the absence of any reply presumably means "not for a while yet",
I'm not so sure about this, there has been quite some bug-fixing and it's
not clear to me what's missing for a release. Simon^2?
> could someone let me have a compiled hsc for the ghc-4.08 head
> on something reasonably close to SunOS/sparc Ultra-1?
The current branch-o-mania is a little confusing, but the CVS branch
called "ghc-4-07-branch" (yes, "7", not "8") should contain what you
are looking for. At least I think so... :-} Any bootstrapping problems?
Cheers,
Sven
From rrt1001@cam.ac.uk Tue Jan 23 22:20:20 2001
Date: Tue, 23 Jan 2001 22:20:20 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: 4.08.2
> > Any idea yet when 4.08.2 is going to be released?
> [snip]
> Since the absence of any reply presumably means "not for a while yet",
No, it meant we were all busy with the Haskell Implementors' Workshop. It
should be released within a week.
--
http://sc3d.org/rrt/ | impatience, n. the urge to do nothing
From ger@tzi.de Tue Jan 23 22:30:50 2001
Date: Tue, 23 Jan 2001 23:30:50 +0100
From: George Russell ger@tzi.de
Subject: 4.08.2
Sven Panne wrote:
[snip]
> The current branch-o-mania is a little confusing, but the CVS branch
> called "ghc-4-07-branch" (yes, "7", not "8") should contain what you
> are looking for. At least I think so... :-} Any bootstrapping problems?
Yes, I get a segmentation fault when the compilation process first comes to use
the resulting hsc executable. I have tried several times to avoid this (by
changing gcc or ghc versions) but without success.
From kgolder@wellesley.edu Wed Jan 24 17:35:39 2001
Date: Wed, 24 Jan 2001 12:35:39 -0500
From: Kate S. Golder kgolder@wellesley.edu
Subject: using the GHC parser and renamer
Hi -
We are trying to use the GHC parser and renamer within a program that we
are writing (a program to take a Haskell program written in multiple
modules, and return a program that is a single module) and. We were
wondering if you can think of something that we might be missing. It
compiles fine (when we execute "make all" at the command line), but when
we run the executable it gets through the parser fine, and creates the
uniqueSupply for the renamer, but it doesn't get through the renamer, we
get an errors that say (Main.hs is the file that is being parsed and
renamed):
Main.hs:1:
Could not find interface file for 'Prelude'
in the directories ./*.hi
Main.hs:3:
Bad interface file:: ./ParseAndRenameFile.hi
./ParseAndRenameFile.hi:1 Interface file version error; Expected 0
found version 408
Fail: Compilation had errors
We assume that these are because the renamer needs to look at .hi files,
and that it either can't find them (Prelude.hi) or it has the wrong
version number (ParseAndRenameFile.hi). How do we tell the renamer where
to look for the interface files, and fix the version error?
I've included the three files (Makefile, Main.hs, and
ParseAndRenameFile.hs) at the bottom of this email.
Thanks in advance for you any thoughts you might have,
Kate
===========================================================
Makefile:
HC = ghc-4.08
INTERFACE_FILES =
.:compiler/absCSyn:compiler/basicTypes:compiler/codeGen:compiler/coreSyn:compiler/cprAnalysis:compiler/deSugar:compiler/hsSyn:compiler/javaGen:compiler/main:compiler/nativeGen:compiler/parser:compiler/prelude:compiler/profiling:compiler/rename:compil
er/simplCore:compiler/simplStg:compiler/specialise:compiler/stgSyn:compiler/stranal:compiler/typecheck:compiler/types:compiler/usageSP:compiler/utils:/home/lumberjacks/deforest/ghc-4.08/fptools-binaries/lib/i386-unknown-linux/imports/lang/
HC_OPTS = -cpp -i$(INTERFACE_FILES) $(EXTRA_HC_OPTS) -fglasgow-exts
SRCS = Main.hs ParseAndRenameFile.hs
OBJS = Main.o ParseAndRenameFile.o
.SUFFIXES : .o .hs .hi .lhs .hc .s
all: $(OBJS)
$(HC) -lHSlang -lNewGHC
-L/usr/users/deforest/ghc-4.08/fptools-newgcc-build/lib -o PARF $(HC_OPTS)
$(OBJS)
# Standard suffix rules
.o.hi:
@:
.lhs.o:
$(HC) -c $< $(HC_OPTS)
.hs.o:
$(HC) -c $< $(HC_OPTS)
depend :
$(HC) -M $(HC_OPTS) $(SRCS)
# DO NOT DELETE: Beginning of Haskell dependencies
Main.o : Main.hs
Main.o : ./ParseAndRenameFile.hi
ParseAndRenameFile.o : ParseAndRenameFile.hs
ParseAndRenameFile.o : compiler/basicTypes/UniqSupply.hi
ParseAndRenameFile.o : compiler/rename/Rename.hi
ParseAndRenameFile.o : compiler/utils/FastString.hi
ParseAndRenameFile.o : compiler/hsSyn/HsSyn.hi
ParseAndRenameFile.o : compiler/basicTypes/BasicTypes.hi
ParseAndRenameFile.o : compiler/parser/RdrHsSyn.hi
ParseAndRenameFile.o : compiler/utils/FastString.hi
ParseAndRenameFile.o : compiler/utils/StringBuffer.hi
ParseAndRenameFile.o : compiler/parser/Parser.hi
ParseAndRenameFile.o : compiler/parser/Lex.hi
ParseAndRenameFile.o : compiler/basicTypes/SrcLoc.hi
ParseAndRenameFile.o : compiler/rename/RnMonad.hi
ParseAndRenameFile.o : compiler/main/MkIface.hi
ParseAndRenameFile.o : compiler/typecheck/TcModule.hi
ParseAndRenameFile.o : compiler/basicTypes/Module.hi
ParseAndRenameFile.o : compiler/main/CmdLineOpts.hi
ParseAndRenameFile.o : compiler/main/ErrUtils.hi
ParseAndRenameFile.o : compiler/utils/Outputable.hi
# DO NOT DELETE: End of Haskell dependencies
===========================================================
Main.hs:
module Main where
import ParseAndRenameFile
main :: IO ()
main = parseAndRename "Main.hs"
===========================================================
ParseAndRenameFile.hs:
module ParseAndRenameFile where
import UniqSupply ( mkSplitUniqSupply )
import Rename ( renameModule )
import FastString
--
import IO ( hPutStr, stderr )
import HsSyn
import BasicTypes ( NewOrData(..) )
import RdrHsSyn ( RdrNameHsModule )
import FastString ( mkFastCharString, unpackFS )
import StringBuffer ( hGetStringBuffer )
import Parser ( parse )
import Lex ( PState(..), P, ParseResult(..) )
import SrcLoc ( mkSrcLoc )
import RnMonad ( InterfaceDetails(..) )
import MkIface ( startIface, ifaceDecls, endIface )
import TcModule ( TcResults(..), typecheckModule )
import Module ( ModuleName, moduleNameUserString )
import CmdLineOpts
import ErrUtils ( ghcExit )
import Outputable
parseAndRename filename
= do {(name, parsed) <- parseFile filename;
rn_uniqs <- mkSplitUniqSupply 'r';
maybe <- renameModule rn_uniqs parsed;
putStr "done \n"
}
--parseFile is adapted from parseModule in compiler/main/Main.lhs
parseFile :: String -> IO (ModuleName, RdrNameHsModule)
parseFile filename = do
{buf <- hGetStringBuffer True{-expand tabs-} filename;
case parse buf PState{ bol = 0#,
atbol = 1#,
context = [],
glasgow_exts = glaexts,
loc = mkSrcLoc (mkFastString filename) 1 } of
PFailed err -> do
printErrs err
ghcExit 1
return (error "parseModule") -- just to get the types right
POk _ m@(HsModule mod _ _ _ _ _ _) ->
return (mod, m)
}
where
glaexts | opt_GlasgowExts = 1#
| otherwise = 0#
===========================================================
Thanks again!
From stolz@I2.Informatik.RWTH-Aachen.DE Thu Jan 25 11:51:18 2001
Date: Thu, 25 Jan 2001 12:51:18 +0100
From: Volker Stolz stolz@I2.Informatik.RWTH-Aachen.DE
Subject: limited suspending on readChan possible?
Hello everyone, I thought I´d return to more earthly issue than discovering
bugs in signal handlers etc. :)
I´ve been looking for a way to suspend on an empty channel for only a
limited time. So I came up with a solution which involves dupChan (which
is currently broken as stated in Meurig´s bug-report) and unGetChan:
> timedReadChan ch t = do
> dup <- dupChan ch
> mv <- newEmptyMVar
> forkIO (do
> msg <- readChan dup
> putMVar mv True
> )
> forkIO (do
> threadDelay t
> putMVar mv False
> )
> res <- takeMVar mv
> if res
> then do
> -- we discard dup and re-read from ch:
> msg <- readChan ch
> return (Just msg)
> else (return Nothing)
However, shouldn´t the dupChan be a space-leak par excellence? We end up
having no readers and keep adding new meesages to dup...
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From qrczak@knm.org.pl Thu Jan 25 19:41:58 2001
Date: 25 Jan 2001 19:41:58 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: _scc_
Why
_scc_ "foo"
and not
{-# SCC "foo" #-}
?
IMHO a pragma would be better: does not make the scc-annotated program
non-standard.
(Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary
places.)
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From kort@wins.uva.nl Fri Jan 26 16:40:17 2001
Date: Fri, 26 Jan 2001 17:40:17 +0100
From: Jan Kort kort@wins.uva.nl
Subject: Floating point performance
Hi,
I noticed ghc (version 4.08.1) floating point performance is
really slow on my computer: a 270Mhz sun ultra5. The program
below does 1 milion floating point multiplications and takes
2 seconds to run. I made a profile and it says most of the
time (93%) is spent in the function bar. Any idea what is
going on ?
Regards,
Jan
module Main where
foo :: Double -> [Double]
foo 0 = [1]
foo n = bar n:foo (n-1)
bar :: Double -> Double
bar n = n*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
foldl' :: (a -> b -> a) -> a -> [b] -> a
foldl' _ a [] = a
foldl' f a (x:xs) = (foldl' f $! f a x) xs
main :: IO()
main = putStrLn (show (foldl' (+) 0 (foo 10000)))
---------------------------
Profile:
total time = 2.60 secs (130 ticks @ 20 ms)
total alloc = 24,845,828 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
bar Main 93.1 96.1
foo Main 3.1 2.4
foldl' Main 3.1 1.4
individual inherited
COST CENTRE MODULE entries %time %alloc %time %alloc
MAIN MAIN 0 0.0 0.0 100.0 100.0
main Main 0 0.0 0.0 0.0 0.0
CAF PrelShow 1 0.0 0.0 0.0 0.0
CAF PrelFloat 3 0.0 0.0 0.0 0.0
CAF PrelHandle 3 0.0 0.0 0.0 0.0
CAF Main 9 0.0 0.0 100.0 100.0
main Main 1 0.8 0.0 100.0 100.0
foo Main 10001 3.1 2.4 96.2 98.5
bar Main 10000 93.1 96.1 93.1 96.1
foldl' Main 10002 3.1 1.4 3.1 1.4
From qrczak@knm.org.pl Fri Jan 26 17:16:20 2001
Date: 26 Jan 2001 17:16:20 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Floating point performance
Fri, 26 Jan 2001 17:40:17 +0100, Jan Kort <kort@wins.uva.nl> pisze:
> I made a profile and it says most of the time (93%) is spent in
> the function bar.
Did you compile with optimization turned on (option -O)?
I see similar results without -O but quite different with -O.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Fri Jan 26 15:04:33 2001
Date: Fri, 26 Jan 2001 07:04:33 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: _scc_
> Why
> _scc_ "foo"
> and not
> {-# SCC "foo" #-}
> ?
>
> IMHO a pragma would be better: does not make the scc-annotated program
> non-standard.
>
> (Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary
> places.)
Good suggestion. I'm not sure why it was done the current way; perhaps
it was before the advent of pragmas. Anyway, on my ToDo list it goes...
Cheers,
Simon
From simonmar@microsoft.com Fri Jan 26 15:09:57 2001
Date: Fri, 26 Jan 2001 07:09:57 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: limited suspending on readChan possible?
> Hello everyone, I thought I?d return to more earthly issue
> than discovering
> bugs in signal handlers etc. :)
>
> I?ve been looking for a way to suspend on an empty channel for only a
> limited time. So I came up with a solution which involves
> dupChan (which
> is currently broken as stated in Meurig?s bug-report) and unGetChan:
How about
timeout N . readChan
where timeout is defined according to our Asynchronous Exceptions paper
(see http://www.haskell.org/~simonmar/papers/async.ps.gz).
Cheers,
Simon
From simonpj@microsoft.com Thu Jan 25 12:41:31 2001
Date: Thu, 25 Jan 2001 04:41:31 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: using the GHC parser and renamer
Kate
I'm sorry not to have replied to your earlier message; I've been
away at POPL etc. Incidentally, for implementation-related
things, better to use glasgow-haskell-bugs (albeit it's not actually a
bug)
rather than glasgow-haskell-users.
GHC 4.08 (which is the place from which you got your code, I think)
uses a "driver" written in perl to coordinate its operations. The
driver
runs cpp, then GHC itself (a binary called 'hsc'), then gcc, then as,
then ld.
Run ghc-4.08 with "-v" to see what it does.
My bet is that you are running your bits-of-ghc-plus-bits-of-your-own
binary directly. So it's not getting all the command-line flags it
expects.
(nor are they documented, because it's an internal interface).
| Main.hs:1:
| Could not find interface file for 'Prelude'
| in the directories ./*.hi
It's not looking in the right directories because it hasn't been told
to do so by the command-line flags. If you run ghc-4.08 -v you'll
see how the driver communicates which directctories to look in.
| Main.hs:3:
| Bad interface file:: ./ParseAndRenameFile.hi
| ./ParseAndRenameFile.hi:1 Interface file=20
| version error; Expected 0
| found version 408
The version number it expects to find is again communicated by
a command line flag. For your purposes you may not care, so
one option is to just remove the test. Or ghc-4.08 -v will show
you what the driver is saying to hsc.
Incidentally, Tim Sheard at OGI is building a modular front end for
Haskell, in the spirit of Mark Jones's Typing Haskell in Haskell paper.
It might be worth asking him whether it's in a borrow-able state,
becuase
it's probably less of a monster than GHC.
Simon
From simonpj@microsoft.com Mon Jan 29 09:05:35 2001
Date: Mon, 29 Jan 2001 01:05:35 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: 4.08.2
George
I'm sorry we've been silent. MS has some kind of huge email backlog.
But the real reason is that POPL and a workshop have intervened so
we've been out of action for a fortnight.
The plan is to release 4.08.2 in a matter of days, not weeks. If you build
the head of the ghc-4-07-branch you'll get the current 4.08.2, and we expect
only
tiny changes before the release (e.g. making sure it all works on Sparc).
4.08 remains our "stable branch".
Simon
| -----Original Message-----
| From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de]
| Sent: 23 January 2001 22:23
| To: George Russell
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: 4.08.2
|
|
| George Russell wrote:
| > Since the absence of any reply presumably means "not for a
| while yet",
|
| I'm not so sure about this, there has been quite some
| bug-fixing and it's
| not clear to me what's missing for a release. Simon^2?
|
| > could someone let me have a compiled hsc for the ghc-4.08 head
| > on something reasonably close to SunOS/sparc Ultra-1?
|
| The current branch-o-mania is a little confusing, but the CVS branch
| called "ghc-4-07-branch" (yes, "7", not "8") should contain what you
| are looking for. At least I think so... :-} Any
| bootstrapping problems?
|
| Cheers,
| Sven
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From v-julsew@microsoft.com Mon Jan 29 13:33:23 2001
Date: Mon, 29 Jan 2001 05:33:23 -0800
From: Julian Seward (Intl Vendor) v-julsew@microsoft.com
Subject: Floating point performance
I tried this, with ghc-4.08.1 -O both with and without
profiling, on a Sparc box of I believe around 300 MHz,
and I can't reproduce it at all. Without profiling,
it allocates about 505 k of heap and runs in 0.02
seconds.
Ummm ?
J
| -----Original Message-----
| From: Jan Kort [mailto:kort@wins.uva.nl]
| Sent: Friday, January 26, 2001 4:40 PM
| To: glasgow-haskell-users@haskell.org
| Subject: Floating point performance
|
|
| Hi,
| I noticed ghc (version 4.08.1) floating point performance is
| really slow on my computer: a 270Mhz sun ultra5. The program
| below does 1 milion floating point multiplications and takes
| 2 seconds to run. I made a profile and it says most of the
| time (93%) is spent in the function bar. Any idea what is
| going on ?
|
| Regards,
| Jan
|
| module Main where
|
| foo :: Double -> [Double]
| foo 0 = [1]
| foo n = bar n:foo (n-1)
|
| bar :: Double -> Double
| bar n = n*1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
|
| foldl' :: (a -> b -> a) -> a -> [b] -> a
| foldl' _ a [] = a
| foldl' f a (x:xs) = (foldl' f $! f a x) xs
|
| main :: IO()
| main = putStrLn (show (foldl' (+) 0 (foo 10000)))
|
| ---------------------------
| Profile:
|
| total time = 2.60 secs (130 ticks @ 20 ms)
| total alloc = 24,845,828 bytes (excludes profiling
| overheads)
|
| COST CENTRE MODULE %time %alloc
|
| bar Main 93.1 96.1
| foo Main 3.1 2.4
| foldl' Main 3.1 1.4
|
|
| individual inherited
| COST CENTRE MODULE entries %time %alloc
| %time %alloc
|
| MAIN MAIN 0 0.0 0.0
| 100.0 100.0
| main Main 0 0.0 0.0
| 0.0 0.0
| CAF PrelShow 1 0.0 0.0
| 0.0 0.0
| CAF PrelFloat 3 0.0 0.0
| 0.0 0.0
| CAF PrelHandle 3 0.0 0.0
| 0.0 0.0
| CAF Main 9 0.0 0.0
| 100.0 100.0
| main Main 1 0.8 0.0
| 100.0 100.0
| foo Main 10001 3.1 2.4
| 96.2 98.5
| bar Main 10000 93.1 96.1
| 93.1 96.1
| foldl' Main 10002 3.1 1.4
| 3.1 1.4
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From kort@wins.uva.nl Mon Jan 29 17:15:02 2001
Date: Mon, 29 Jan 2001 18:15:02 +0100
From: Jan Kort kort@wins.uva.nl
Subject: Floating point performance
"Julian Seward (Intl Vendor)" wrote:
>
> I tried this, with ghc-4.08.1 -O both with and without
> profiling, on a Sparc box of I believe around 300 MHz,
> and I can't reproduce it at all. Without profiling,
> it allocates about 505 k of heap and runs in 0.02
> seconds.
>
> Ummm ?
>
> J
I didn't use any optimizations, but I am sure that
passing -O to ghc will make it see that 1*1*... is a
constant expression. I guess turning all optimizations
off is not the right way to test stuff either.
Jan
From shutej@rpi.edu Mon Jan 29 21:07:53 2001
Date: Mon, 29 Jan 2001 16:07:53 -0500
From: Jeremy Shute shutej@rpi.edu
Subject: Using GHC with Green Card under Win32
Sigbjorn:
Yes, this works perfectly now. Thanks!
I've taken the liberty of mailing this to the GHC mailing list so hopefully
it can percolate to the archives and be of use to others (I know I usually
check there first). I hope this won't be considered misuse of the list...
Thanks again!
Jeremy Shute
> -----Original Message-----
> From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com]
> Sent: Monday, January 29, 2001 1:21 PM
> To: Jeremy Shute
> Subject: Re: Troubles running ScriptReg
>
>
> Yes, you don't want to link against the Hugs DLL when
> you're working with ghc compiled code. Try adding
> -package greencard to the final link line.
>
> --sigbjorn
>
> ----- Original Message -----
> From: "Jeremy Shute" <shutej@rpi.edu>
> To: "Sigbjorn Finne" <sigbjorn_finne@hotmail.com>
> Sent: Monday, January 29, 2001 18:53
> Subject: RE: Troubles running ScriptReg
>
>
> > Yes, now things work wonderfully. I've written a little shell script to
> > automate the process, the .o builds fine! Now I'm trying to make use of
> the
> > library:
> >
> >
> >
> > $ ghc -static Main.hs Gimme.o -fglasgow-exts -fvia-C \
> >
> >
> '-iF:\\usr\\share\\ghc\\lib\\imports\\greencard;F:\\usr\\share\\gh
> c\\lib\\im
> > ports\\greencard'
> > Compilation IS NOT required
> > Output file not specified, defaulting to "main.exe"
> > Gimme.o(.text+0x38):ghc1140.c: undefined reference to `__init_StdDIS'
> > Gimme.o(.text+0x144):ghc1140.c: undefined reference to
> > `StdDIS_unmarshallzustringzu_closure'
> > Gimme.o(.text+0x250):ghc1140.c: undefined reference to
> > `StdDIS_unmarshallzustringzu_closure'
> > collect2: ld returned 1 exit status
> >
> >
> >
> > I've crawled the drive and found that the only C code-ish file
> for StdDIS
> > are StdDIS.dll, and that's in greencard\lib\hugs... I don't
> think linking
> > against that would be appropriate. When I omit that trailing
> '-iF:\\...',
> > the same errors are output. Sooo close!
> >
> > Perhaps I should post all this to the mailing list, just so people can
> find
> > it while crawling the archives? I would think these are fairly useful
> > nuggets of info. :-)
> >
> > Jeremy
> >
> >
> >
> > > -----Original Message-----
> > > From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com]
> > > Sent: Friday, January 26, 2001 12:30 PM
> > > To: Jeremy Shute
> > > Subject: Re: Troubles running ScriptReg
> > >
> > >
> > >
> > > Good to hear that you're up and running, at least on the HaskellScript
> > > side. You're close on the GC side too - to properly process the input
> > > you need to use the -i option to inform GC where it can slurp in
> > > StdDIS.gc from (Although the docs says so, the binary doesn't
> > > automatically
> > > figure this out..) So, if you invoke it as follows
> > >
> > > green-card -tghc Gimme.gc -iF:\\usr\\share\\greencard\\lib\\ghc
> > >
> > > the warning should go away. To compile Gimme.hs with ghc-4.08,
> > > use the following command-line:
> > >
> > > ghc -static -c Gimme.hs -fglasgow-exts -fvia-C \
> > >
> > > '-iF:\\usr\\share\\greencard\\lib\\ghc;F:\\usr\\share\\greencard\\
> > > lib\\ghc'
> > >
> > > i.e., you need to kludge around a bit to get DOS-style paths to work
> > > OK & redundantly give it twice, using ';' as separator.
> > >
> > > To generate Hugs-compatible output on a Win32 box, Section 12.2 of
> > > the manual contains accurate info.
> > >
> > > hth,
> > > --sigbjorn
> > >
> > > ----- Original Message -----
> > > From: "Jeremy Shute" <shutej@rpi.edu>
> > > To: "Sigbjorn Finne" <sigbjorn_finne@hotmail.com>
> > > Sent: Friday, January 26, 2001 02:56
> > > Subject: RE: Troubles running ScriptReg
> > >
> > >
> > > > Howdy, Sigbjorn.
> > > >
> > > > Confirming again that Hugs now works great with
> HaskellScript (or what
> > > I've
> > > > tested of it, at least, ;-) )...
> > > >
> > > > Now here I am, staring at Green Card, realizing that you're
> one of the
> > > > authors. You sure do get around in the Haskell world!
> > > >
> > > > I'm running GHC-4.08.1 and Green Card 2 (presumably 2.01, I
> installed
> it
> > > > right before Christmas break). I've looked at the example
> > > online of GDBM,
> > > > and am trying this code:
> > > >
> > > > ----------------------------------------
> > > > %#include "hello.h"
> > > > {-
> > > > Testing... This is Gimme.gc!
> > > > -}
> > > >
> > > > module Gimme( gimme )
> > > >
> > > > where
> > > >
> > > > import StdDIS
> > > > import Foreign( ForeignObj,
> > > > makeForeignObj )
> > > >
> > > > %fun gimme :: IO String
> > > > %code
> > > > %result (string {hello()})
> > > >
> > > > ----------------------------------------
> > > > /*
> > > > Testing... This is hello.h!
> > > > */
> > > >
> > > > char* hello( ) {
> > > > return "Howdy!\n";
> > > > }
> > > >
> > > > ----------------------------------------
> > > >
> > > > I run:
> > > >
> > > > green-card.exe -tghc Gimme.gc
> > > >
> > > > It says:
> > > >
> > > > Warning: unable to find StdDIS in:
> > > >
> > > > Notice how it says nothing after the "in"... I've scoured
> the manual
> > > > looking for ways to set the library path of green card, and
> either I'm
> > > > missing something or it's not there... Reguardless, I suppose
> > > I'm not too
> > > > TERRIBLY concerned at this stage, as I still have a
> Gimme.hs that it's
> > > > produced. The contents of which are (the comment is no longer
> correct,
> > > but
> > > > I left it reguardless):
> > > >
> > > > ----------------------------------------
> > > > {-# OPTIONS -#include "hello.h" #-}
> > > > {-
> > > > Testing... This is Gimme.gc!
> > > > -}
> > > >
> > > > module Gimme( gimme )
> > > >
> > > > where
> > > >
> > > > import StdDIS
> > > > import Foreign( ForeignObj,
> > > > makeForeignObj )
> > > >
> > > > gimme :: IO String
> > > > gimme =
> > > > _casm_ ``do {do {} while(0);} while(0);''
> > > > (unmarshall_string hello()) >>= \ gc_res1 ->
> > > >
> > > > ----------------------------------------
> > > >
> > > > That last line may wrap in your email... gimme= should be
> followed by
> 2
> > > > lines. The file's contents look OK, so I look up where StdDIS.hs is
> > > located
> > > > under my Green Card directory, stuff that onto GHC's command
> > > line, and try
> > > > to whip out an executable of some sort (using the static flag
> > > because it's
> > > > necessary under this version of GHC for Win32). Okay, so here comes
> the
> > > > part where I blame it on GHC instead of Green Card:
> > > >
> > > > I run:
> > > >
> > > > ghc -static -iF:\\usr\\share\\greencard\\lib\\ghc\\ Gimme.hs
> > > >
> > > > It says:
> > > >
> > > > Gimme.hs:15: parse error on input ``'
> > > >
> > > > I have reinstalled Green Card several times, moved things
> around, been
> > > > pretty thorough... Tried various other code, and it always
> > > lands me with
> > > > this message. I can only presume that I'm being foolish, yet again,
> and
> > > > that perhaps this newer version of GHC is mutually exclusive with
> Green
> > > > Card? Please advise.
> > > >
> > > > :-) So far, my experience with the language has been nothing but
> > > positive.
> > > > I tried out Erlang, too, and Haskell just feels cleaner.
> > > However, getting
> > > > the implementations set up is quite daunting...
> > > >
> > > >
> > > >
> > > > Jeremy Shute
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com]
> > > > > Sent: Wednesday, January 17, 2001 7:00 AM
> > > > > To: Jeremy Shute
> > > > > Cc: daan@cs.uu.nl; erik@cs.uu.nl
> > > > > Subject: Re: Troubles running ScriptReg
> > > > >
> > > > >
> > > > > Hi Jeremy,
> > > > >
> > > > > I don't know if anyone else has been trying to help you out,
> > > > > but the HaskellScript binary you're using is not quite
> > > > > up-to-date with the available Hugs98 binaries and libraries,
> > > > > i.e., Addr.addrToInt is a recent addition to the Addr lib.
> > > > >
> > > > > My initial suggestion would be to simply comment-out
> > > > > the 'primitive' declaration for addrToInt and try again --
> > > > > addrToInt isn't used all that much, anyway.
> > > > >
> > > > > --sigbjorn
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Jeremy Shute" <shutej@rpi.edu>
> > > > > To: <daan@cs.uu.nl>; <erik@cs.uu.nl>
> > > > > Cc: <sof@dcs.gla.ac.uk>
> > > > > Sent: Sunday, January 14, 2001 19:17
> > > > > Subject: Troubles running ScriptReg
> > > > >
> > > > >
> > > > > > I'm having some difficulty with HaskellScript under Windows 2000
> > > > > > Professional. My progress so far:
> > > > > >
> > > > > > * Downloaded and installed Hugs 98: November 1999
> version. Chose
> > > > > "typical"
> > > > > > install. Hugs resides in "C:\Hugs98".
> > > > > >
> > > > > > * Downloaded and installed HaskellScript (build 11).
> HaskellScript
> > > > > resides
> > > > > > in "C:\HScript98".
> > > > > >
> > > > > > * Started reading through the documentation and figured I'd try
> > > > > ScriptReg
> > > > > > (in the demos directory) on the included Calculator
> > > example, as noted
> > > at
> > > > > the
> > > > > > bottom of
> > > http://haskell.cs.yale.edu/haskellscript/osexamples.html. A
> > > > > popup
> > > > > > window informed me that Prelude.hs was not found. I
> > > investigated the
> > > > > > contents of my registry and determined that
> HaskellScript doesn't
> > > assume
> > > > > or
> > > > > > ask for any information about Hugs' install directory, so I came
> up
> > > with
> > > > > the
> > > > > > quick fix I've attached. Maybe you can make it useful to
> others...
> > > > > >
> > > > > > * ScriptReg now fails with a MsgBox. The title of the box is
> > > > > "HugsScript"
> > > > > > and the error message follows:
> > > > > >
> > > > > > error: ERROR "C:\Hugs98\lib\exts\Addr.hs" (line 23):
> > > Unknown primitive
> > > > > > reference "addrToInt"
> > > > > >
> > > > > > When the "OK" button is pressed, another message box pops
> > > up, this one
> > > > > > titled "ScriptReg", which states:
> > > > > >
> > > > > > Run-time error '440':
> > > > > >
> > > > > > Automation error
> > > > > >
> > > > > > * Checked out the contents of Addr.hs... Everything looks in
> > > > > order. Line
> > > > > > 14 in this file reads:
> > > > > >
> > > > > > -- data Addr -- in Prelude
> > > > > >
> > > > > > So I looked in Prelude.hs. Line 1605 of Prelude.hs reads:
> > > > > >
> > > > > > data Addr -- builtin datatype of C pointers
> > > > > >
> > > > > > Prelude.hs also contains the appropriate Standard Integral
> > > types. I'm
> > > > > left
> > > > > > wondering if Prelude.hs isn't processed before Addr.hs???
> > > This is the
> > > > > only
> > > > > > suspicion I have, maybe I've missed something?
> > > > > >
> > > > > > I would appreciate any insight you could give me: Two weeks
> > > > > from now I'm
> > > > > > starting on a web spider that's going to have to have bayesian
> > > > > classifiers
> > > > > > and neural networking components. I want to encapsulate these
> parts
> > > in
> > > > > > Haskell, but that would be a much easier case to make to my
> > > boss if my
> > > > > > coworkers could access my code from COM!
> > > > > >
> > > > > > Thanks so much!
> > > > > >
> > > > > > Jeremy
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
From qrczak@knm.org.pl Mon Jan 29 21:24:27 2001
Date: 29 Jan 2001 21:24:27 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Floating point performance
Mon, 29 Jan 2001 18:15:02 +0100, Jan Kort <kort@wins.uva.nl> pisze:
> I didn't use any optimizations, but I am sure that
> passing -O to ghc will make it see that 1*1*... is a
> constant expression.
It does not, because it's n*1*1*1*... where n is not a constant.
Major advantages seem to be from the strictness analysis.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Mon Jan 29 13:25:36 2001
Date: Mon, 29 Jan 2001 13:25:36 -0000
From: Simon Marlow simonmar@microsoft.com
Subject: Floating point performance
> Fri, 26 Jan 2001 17:40:17 +0100, Jan Kort <kort@wins.uva.nl> pisze:
>=20
> > I made a profile and it says most of the time (93%) is spent in
> > the function bar.
>=20
> Did you compile with optimization turned on (option -O)?
> I see similar results without -O but quite different with -O.
Without optimisation, you get the native code generator which produces
particularly brain-dead code for floating point on x86 (mainly due to
Intel's brain-dead design of the x86 floating point unit). With
optimisation, you get gcc.
Cheers,
Simon
From simonpj@microsoft.com Tue Jan 2 09:04:05 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 2 Jan 2001 01:04:05 -0800
Subject: Realtime-GC
Message-ID: <74096918BE6FD94B9068105F877C002D01378459@red-pt-02.redmond.corp.microsoft.com>
Yes -- Andy Cheadle and Tony Field (whose paper is in ICFP00) are
planning to bring their incremental GC fully into GHC, so it'll become
part of the distribution.
I think Andy will be delighted to have a Real Customer! So far, GC
is sufficiently unobtrusive that no one notices, so it'll be fun to have
someone who does.
Are there any other GHC users who notice GC pauses?
Simon
| -----Original Message-----
| From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de]
| Sent: 30 December 2000 22:09
| To: GHC Users
| Cc: Armin Sander
| Subject: Realtime-GC
|
|
| IIRC there was some activity in the realtime GC area
| for GHC (something like experimental support for 4.0x,
| but I can't remember exactly). Any progress yet? It
| would be quite cool to fly through Quake levels without
| those small hiccups. And I'm quite sure there are more
| serious applications which would profit from that, too... :-)
|
| Cheers,
| Sven
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From dongen@cs.ucc.ie Tue Jan 2 09:10:06 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 2 Jan 2001 09:10:06 +0000
Subject: Realtime-GC
In-Reply-To: <74096918BE6FD94B9068105F877C002D01378459@red-pt-02.redmond.corp.microsoft.com>; from simonpj@microsoft.com on Tue, Jan 02, 2001 at 01:04:05AM -0800
References: <74096918BE6FD94B9068105F877C002D01378459@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20010102091006.F354@cs.ucc.ie>
Simon Peyton Jones (simonpj@microsoft.com) wrote:
[snip]
: Are there any other GHC users who notice GC pauses?
Yes. I do. However, it doesn't really bother me a lot
because I am not a real-time person. Happy old year:-).
Regards,
Marc van Dongen
--
Marc van Dongen, CS Dept | phone: +353 21 4903578
University College Cork, NUIC | Fax: +353 21 4903113
College Road, Cork, Ireland | Email: dongen@cs.ucc.ie
From mk167280@students.mimuw.edu.pl Tue Jan 2 16:43:25 2001
From: mk167280@students.mimuw.edu.pl (Marcin 'Qrczak' Kowalczyk)
Date: Tue, 2 Jan 2001 17:43:25 +0100 (CET)
Subject: My program is crashing - help!
Message-ID:
I don't know if this is a bug in my code, in ghc, or in the python
interpreter. I could not find it for a long time. Would somebody please
help me?
In there is a simplest
fragment I could ake which exposes the bug. It requires ghc-4.11 and
python-2.0. It should be tweakable for older versions of both:
- For older ghc versions, either replace Ptr/FunPtr with Addr and
ForeignPtr with ForeignObj, or use QForeign instead of Foreign.
In any case you must install hsc2hs from ghc >= 4.09 or QForeign.
QForeign is at
.
- For older Python versions, fix paths in the Makefile.
The program should do an equivalent of
main = putStr (repeat '9')
but in a very indirect way, calling Python which calls back Haskell for
each digit. On my machine it crashes after several lines of output (inside
malloc).
It is very sensitive to small changes. When compiled with -O, it works
fine. When the PyObject module is merged with Main, it works fine. When
nullFunPtr is passed in Main.hsFunctionNew instead of freeMethodDefPtr, it
still crashes, but if nullFunPtr is replaced with 0 and the corresponding
type in a foreign import is changed to Int, it works fine (well, this
applied to a version before removing unnecessary junk, now it may be
different). When freeMethodDef is written in C and foreign imported
instead of being written in Haskell and foreign exported, it works fine.
Et caetera.
I tried to run it under ghc-4.08.1 and python-1.5 (after necessary
tweaking), but it's very different: it crashes very soon and ltrace shows
that a message about passing a non-tuple as arguments is strcpy'ed just
before the crash. Perhaps the crash is expected, since I don't catch
Python exceptions in the simplified version, but the message is not: I am
passing the result of PyTuple_New(0) (after wrapping in a ForeignPtr).
Anyway, it is very sensitive to small changes of compilers or the source
itself.
Maybe I am using the Python interface in a wrong way, or I am doing some
stupid mistake, or there is a bug in ghc - I really don't know what is
going on. Help!
--
Marcin 'Qrczak' Kowalczyk
From dongen@cs.ucc.ie Tue Jan 2 16:49:50 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 2 Jan 2001 16:49:50 +0000
Subject: My program is crashing - help!
In-Reply-To: ; from mk167280@zodiac.mimuw.edu.pl on Tue, Jan 02, 2001 at 05:43:25PM +0100
References:
Message-ID: <20010102164950.H354@cs.ucc.ie>
Marcin 'Qrczak' Kowalczyk (mk167280@zodiac.mimuw.edu.pl) wrote:
[HEEEEEELP]
Are you using RULES? If you are then
try turning them all off. Just a thought.
Regards,
Marc
From qrczak@knm.org.pl Tue Jan 2 18:24:23 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 2 Jan 2001 18:24:23 GMT
Subject: My program is crashing - help!
References: <20010102164950.H354@cs.ucc.ie>
Message-ID:
Tue, 2 Jan 2001 16:49:50 +0000, Marc van Dongen pisze:
> Are you using RULES?
No. They are ignored anyway when optimization is turned off.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From chak@cse.unsw.edu.au Wed Jan 3 06:11:54 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 03 Jan 2001 17:11:54 +1100
Subject: RULES and -fglasgow-exts
Message-ID: <20010103171154M.chak@cse.unsw.edu.au>
It seems that in order to use RULES pragmas in a module, the
module has to be compiled with -fglasgow-exts (at least,
this is so with 4.08.1). This is a little surprising as
pragmas usually don't require this flag. Indeed, it seems
as if the keyword `forall' within a RULES pragma is what
irritates GHC without -fglasgow-exts - maybe because forall
is an extension in "normal" code?
Cheers,
Manuel
From rrt1001@cam.ac.uk Thu Jan 4 15:03:17 2001
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Thu, 4 Jan 2001 15:03:17 +0000 (GMT)
Subject: Happy InstallShield update
Message-ID:
I just noticed that the Happy 1.9 InstallShield contained a dynamically
linked executable for Happy. This was a Bad Idea, so I've replaced it with a
statically linked executable. This should work for more people.
--
http://sc3d.org/rrt/ | maxim, n. wisdom for fools
From ger@tzi.de Thu Jan 4 19:34:39 2001
From: ger@tzi.de (George Russell)
Date: Thu, 04 Jan 2001 20:34:39 +0100
Subject: "Illegal class assertion"
Message-ID: <3A54D04F.AD5BA65D@tzi.de>
is not a very helpful message, especially as GHC can't be bothered to pinpoint exactly
where the error occurred. In this particular case, "Missing type variable in instance context"
might be more helpful.
From ger@tzi.de Thu Jan 4 20:35:06 2001
From: ger@tzi.de (George Russell)
Date: Thu, 04 Jan 2001 21:35:06 +0100
Subject: instance Bits Int
Message-ID: <3A54DE7A.68A9EBD@tzi.de>
Why isn't Int an instance of Bits?
From rrt1001@cam.ac.uk Fri Jan 5 18:37:25 2001
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Fri, 5 Jan 2001 18:37:25 +0000 (GMT)
Subject: [THRILLSEEKERS] GHC head bursts into action on Windows!
Message-ID:
Those Windows users of GHC who like to live on the bleeding edge may like to
know that the CVS head version of GHC is now alive and kicking on Windows.
Both text and Windowing "hello, world" programs work fine (and probably much
other stuff, since the basic code generation for Intel is quite well tested
now).
I'm particularly keen to get bug reports for the Windows version of GHC (and
in particular for the Win32 API if anyone's using it), since we don't do
much testing of that sort of thing.
--
http://sc3d.org/rrt/ | free, a. already paid for (Peyton Jones)
From Pradipto Kolay Wed Jan 10 04:25:20 2001
From: Pradipto Kolay (Pradipto Kolay )
Date: Wed, 10 Jan 2001 04:25:20 GMT
Subject: message
Message-ID: <200101100425.EAA15384@www.dcs.gla.ac.uk>
[This message is sent through a WWW-Email gateway.]
[The authenticity of the sender can not be validated.]
[Message sent from the following machine - 64.208.99.35 ]
[after accessing this URL http://www.dcs.gla.ac.uk/scripts/global/send_message?glasgow-haskell-users@dcs.gla.ac.uk+message]
--
Hi,
I am facing problems with dynamic linking under Linux. For example I have two programs , test.cxx and client.cxx. I compile test.cxx to get a shared library. Now test.cxx has a function called callme() which is not declared but not defined. I could compile this to get the .so. However , on trying to compile , client.cxx with this .so, I get undefined reference to callme(). Note that client.cxx DOES NOT call the function callme().
Is there a way to go around this problem and get the linker to search for only those functions which are called ?
I would be greatly indebted 2 U if U could suggest a way out.
Thanking you in anticipation,
Pradipto Kolay
Design Engineer (Wipro GE Medical Systems)
Pradipto.kolay@geind.ge.com
Code :
Test.cxx -
#include
char *printhello()
{
cout << "Hello world " << endl << flush;
}
void func()
{
callme();
}
gcc -shared -embedded-relocs -o libTest.so test.o
(Works fine)
client.cxx -
#include
extern char *printhello(void );
main()
{
printhello();
}
g++ -v client.cxx -L. -Bdynamic -lTest
O/P :
./libTest.so: undefined reference to `callme'
collect2: ld returned 1 exit status
g++: file path prefix `dynamic' never used
--
From Dominic.J.Steinitz@BritishAirways.com Mon Jan 15 09:08:13 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 15 Jan 2001 09:08:13 Z
Subject: Too Strict?
Message-ID: <"0288E3A62BDFD005*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Can someone help? The program below works fine with small files but when I try to use it on the one I need to (about 3 million lines of data) it produces no output. The hard disk is hammered - I assume this is the run time system paging. My suspicion is that the program is trying to read in the whole file before processing it. Is this correct? If so, how do I make the program lazy so that it processes a line at time?
By the way, the MD5 function which I use and is included as part of HSLIBS has the type String -> IO String. The MD5 algorithm really is a function and should have type String -> String. Do people agree and if so how do I get it changed?
Dominic.
-- Compile with ghc -o test test.hs -static -package util
-- under Windows.
module Main(main) where
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
import MD5
import Char
-- showHex and showHex' convert the hashed values to
-- human-readable hexadecimal strings.
showHex :: Integer -> String
showHex =
map hexDigit .
map (fromInteger . (\x -> mod x 16)) .
takeWhile (/=0) .
iterate (\x -> div x 16) .
toInteger
hexDigit x
| (0 <= x) && (x <= 9) = chr(ord '0' + x)
| (10 <= x) && (x <=16) = chr(ord 'a' + (x-10))
| otherwise = error "Outside hexadecimal range"
powersOf256 = 1 : map (*256) powersOf256
showHex' x =
showHex $
sum (zipWith (*)
(map ((\x -> (mod x 16)*16 + (div x 16)) .
toInteger .
ord) x)
powersOf256)
-- The type Anon and function anonymize hide the anonymisation
-- process. In this case, it's a hash function
-- digest :: String -> IO String which implements MD5.
type Anon a = IO a
class Anonymizable a where
anonymize :: a -> Anon a
-- MyString avoids overlapping instances of Strings
-- with the [Char]
data MyString = MyString String
deriving Show
instance Anonymizable MyString where
anonymize (MyString x)
= do s <- digest x
return ((MyString . showHex') s)
instance Anonymizable a => Anonymizable [a] where
anonymize xs = mapM anonymize xs
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
a <- anonymize((map MyString) (lines s))
hPutStr h (unlines (map (\(MyString x) -> x) a))
main = readAndWriteAttrVals
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From C.Reinke@ukc.ac.uk Mon Jan 15 14:56:46 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Mon, 15 Jan 2001 14:56:46 +0000
Subject: Too Strict?
In-Reply-To: Message from "Steinitz, Dominic J"
of "15 Jan 2001 09:08:13." <"0288E3A62BDFD005*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID:
> Can someone help? The program below works fine with small files but when I
> try to use it on the one I need to (about 3 million lines of data) it
> produces no output. The hard disk is hammered - I assume this is the run time
> system paging. My suspicion is that the program is trying to read in the
> whole file before processing it. Is this correct? If so, how do I make the
> program lazy so that it processes a line at time?
I was about to apply GHood to your program to see whether such a tool could
help to find the problem, so I started to cut down your code. However,
in the simplified version of the program, one can see what is going on
without any graphical tool.. (nevertheless, observation of the simplified
code with GHood confirms your suspicion immediately, and it points out
the spine of the list as the problem, too, so the tool is useful!-) (*)
In effect, your anonymize comes down to a "mapM" over a list of actions
applied to input lines, and all of the resulting IO-actions are placed
before the single "hPutStr". So, even if the results of the individual
actions in the list may not be needed until later, the whole spine of
the list of lines has to be traversed before "hPutStr" can be executed,
meaning that all input is read before any output is produced (and thus
before any computation results are requested, blowing up memory usage).
For the problem at hand, you could simply output each line as it is
processed instead of just returning it into a list for later use (see
variant _1 below). If you would want to keep both the modular program
structure and the explicit line-by-line IO-style, you would need to
interleave the input and output commands somehow (perhaps similar to
variant _2 below?).
Hth,
Claus
(*) Please note that our web-server is being upgraded today..
(web-pages and GHood download will not be available until
tomorrow, hence no URL here :-(
PS The simplified code (+ variations) with observations:
module Main(main) where
import Observe
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
let action l = return (':':l)
a <- mapM action (observe "input" (lines s))
hPutStr h (unlines (observe "output" a))
main = runO readAndWriteAttrVals
readAndWriteAttrVals_1 =
do h <- openFile fileout WriteMode
s <- readFile filename
let action_and_output l = hPutStr h (':':l)
mapM_ (observe "output" action_and_output) (observe "input" (lines s))
main_1 = runO readAndWriteAttrVals_1
readAndWriteAttrVals_2 =
do h <- openFile fileout WriteMode
s <- readFile filename
let { action l = return (':':l)
; as = map action (observe "input" (lines s))
; os = repeat (hPutStr h)
}
mapM id (observe "output" (zipWith (>>=) as os))
main_2 = runO readAndWriteAttrVals_2
From simonmar@microsoft.com Tue Jan 16 11:06:53 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 16 Jan 2001 03:06:53 -0800
Subject: bootstrapping GHC
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61157AD@TVP-MSG-01.europe.corp.microsoft.com>
[ Moved to glasgow-haskell-users@haskell.org... ]
> I found the mailing list discussion on generating the hc boot
> files and
> unregisterized code after a tip from Michael Weber and will eventually
> get around to trying to bootstrap on Linux/PPC.
>
> On the other hand, I'm running into a bit of trouble on the
> SPARC. It's
> actually an UltraSPARC (sparc64). My assumption was that
> ordinary SPARC
> code should just run on it. What's actually happen is illegal
> instructions
> everywhere. The one that seems to stop me dead cold every
> time is here:
>
> 00000000009c4cfc :
> 9c4cfc: 00 9c 4c f8 bn 10d80dc <_end+0x69bff4>
> 9c4d00: 00 00 00 00 unimp 0
> 9c4d04: 00 11 00 01 unimp 0x110001
>
> and this is in hsc, which is as far into the bootstrap as I got.
>
> This disassembly looks wrong to me. Perhaps asm mangling is needed; I
> had -fno-asm-mangling set because the assembler was barfing
> on prologue
> nonsense. I'll be looking into that, as I'm not very familiar with the
> real guts of the compiler, or, for that matter, modern SPARC's.
If you're doing an unregisterised bootstrap, there shouldn't be any
problem with assembly mangling since you're just using the OS's native C
compiler (preferably gcc). Although we do have one or two bits of
inline assembly which might be upsetting things: ASSIGN_DBL and PK_DBL
in ghc/includes/StgMacros.h spring to mind.
The PPC folks, particularly Atze Dijkstra who did the
recent MacOS X port, have gone through the whole unregisterised
bootstrap process recently so they should be able to help. Guys?
Cheers,
Simon
From chak@cse.unsw.edu.au Wed Jan 17 00:11:08 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 17 Jan 2001 00:11:08 GMT
Subject: Do *you* understand GHC?
Message-ID: <20010117001108I.chak@cse.unsw.edu.au>
Neither do I, but I am pretending to:
http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/
This is a - so far, very small - set of notes on GHC
internals to assist my weak memory. Maybe it is also useful
for others.
Cheers,
Manuel
From ger@tzi.de Wed Jan 17 11:22:45 2001
From: ger@tzi.de (George Russell)
Date: Wed, 17 Jan 2001 12:22:45 +0100
Subject: 4.08.2
Message-ID: <3A658085.8431B8F@tzi.de>
Any idea yet when 4.08.2 is going to be released? The bugs I reported some time ago
are now getting to be a serious nuisance. I've tried compiling the 4.08 branch from
source, but thanks to some as-yet-unclarified infelicity in gcc or ghc, I get
a segmentation fault from the resulting hsc.
From simonmar@microsoft.com Wed Jan 17 13:47:49 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 17 Jan 2001 05:47:49 -0800
Subject: An Haskell compilation server
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F3C8@TVP-MSG-01.europe.corp.microsoft.com>
[ moved to glasgow-haskell-users@haskell.org... ]
> Wed, 17 Jan 2001 01:49:25 -0800, Simon Marlow
> pisze:
>
> > Funny you should say that. The next version of GHC (5.00 - to be
> > released soon) will have hmake-like functionality enabling it to
> > compile multiple modules without exiting,
>
> How to specify .c files to be linked in?
>
> Or to not bother with linking so I will link manually.
No way to do either at the moment. These would be nice things to have
though.
Cheers,
Simon
From Keith.Wansbrough@cl.cam.ac.uk Mon Jan 22 16:38:36 2001
From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough)
Date: Mon, 22 Jan 2001 16:38:36 +0000
Subject: Do *you* understand GHC?
In-Reply-To: Your message of "Wed, 17 Jan 2001 00:11:08 GMT."
<20010117001108I.chak@cse.unsw.edu.au>
Message-ID:
> Neither do I, but I am pretending to:
>
> http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/
>
> This is a - so far, very small - set of notes on GHC
> internals to assist my weak memory. Maybe it is also useful
> for others.
Great!! See also Olaf Chitil's old paper on implementing an optimisation pass in GHC:
@UnPublished{
Chitil97:Adding,
author="Olaf Chitil",
title="Adding an Optimisation Pass to the {G}lasgow {H}askell {C}ompiler",
month=nov # " 4",
year="1997",
documentURL="http://www-i2.informatik.RWTH-Aachen.de/~chitil/",
status="copy,unverified",
}
--KW 8-)
--
Keith Wansbrough
http://www.cl.cam.ac.uk/users/kw217/
Cambridge University Computer Laboratory.
From ger@tzi.de Tue Jan 23 21:07:10 2001
From: ger@tzi.de (George Russell)
Date: Tue, 23 Jan 2001 22:07:10 +0100
Subject: 4.08.2
References: <3A658085.8431B8F@tzi.de>
Message-ID: <3A6DF27E.75BEE5F6@tzi.de>
George Russell wrote:
>
> Any idea yet when 4.08.2 is going to be released?
[snip]
Since the absence of any reply presumably means "not for a while yet",
could someone let me have a compiled hsc for the ghc-4.08 head
on something reasonably close to SunOS/sparc Ultra-1?
From Sven.Panne@informatik.uni-muenchen.de Tue Jan 23 22:22:50 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Tue, 23 Jan 2001 23:22:50 +0100
Subject: 4.08.2
References: <3A658085.8431B8F@tzi.de> <3A6DF27E.75BEE5F6@tzi.de>
Message-ID: <3A6E043A.31D42DE1@informatik.uni-muenchen.de>
George Russell wrote:
> Since the absence of any reply presumably means "not for a while yet",
I'm not so sure about this, there has been quite some bug-fixing and it's
not clear to me what's missing for a release. Simon^2?
> could someone let me have a compiled hsc for the ghc-4.08 head
> on something reasonably close to SunOS/sparc Ultra-1?
The current branch-o-mania is a little confusing, but the CVS branch
called "ghc-4-07-branch" (yes, "7", not "8") should contain what you
are looking for. At least I think so... :-} Any bootstrapping problems?
Cheers,
Sven
From rrt1001@cam.ac.uk Tue Jan 23 22:20:20 2001
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Tue, 23 Jan 2001 22:20:20 +0000 (GMT)
Subject: 4.08.2
In-Reply-To: <3A6DF27E.75BEE5F6@tzi.de>
Message-ID:
> > Any idea yet when 4.08.2 is going to be released?
> [snip]
> Since the absence of any reply presumably means "not for a while yet",
No, it meant we were all busy with the Haskell Implementors' Workshop. It
should be released within a week.
--
http://sc3d.org/rrt/ | impatience, n. the urge to do nothing
From ger@tzi.de Tue Jan 23 22:30:50 2001
From: ger@tzi.de (George Russell)
Date: Tue, 23 Jan 2001 23:30:50 +0100
Subject: 4.08.2
References: <3A658085.8431B8F@tzi.de> <3A6DF27E.75BEE5F6@tzi.de> <3A6E043A.31D42DE1@informatik.uni-muenchen.de>
Message-ID: <3A6E061A.129F308C@tzi.de>
Sven Panne wrote:
[snip]
> The current branch-o-mania is a little confusing, but the CVS branch
> called "ghc-4-07-branch" (yes, "7", not "8") should contain what you
> are looking for. At least I think so... :-} Any bootstrapping problems?
Yes, I get a segmentation fault when the compilation process first comes to use
the resulting hsc executable. I have tried several times to avoid this (by
changing gcc or ghc versions) but without success.
From kgolder@wellesley.edu Wed Jan 24 17:35:39 2001
From: kgolder@wellesley.edu (Kate S. Golder)
Date: Wed, 24 Jan 2001 12:35:39 -0500
Subject: using the GHC parser and renamer
Message-ID:
Hi -
We are trying to use the GHC parser and renamer within a program that we
are writing (a program to take a Haskell program written in multiple
modules, and return a program that is a single module) and. We were
wondering if you can think of something that we might be missing. It
compiles fine (when we execute "make all" at the command line), but when
we run the executable it gets through the parser fine, and creates the
uniqueSupply for the renamer, but it doesn't get through the renamer, we
get an errors that say (Main.hs is the file that is being parsed and
renamed):
Main.hs:1:
Could not find interface file for 'Prelude'
in the directories ./*.hi
Main.hs:3:
Bad interface file:: ./ParseAndRenameFile.hi
./ParseAndRenameFile.hi:1 Interface file version error; Expected 0
found version 408
Fail: Compilation had errors
We assume that these are because the renamer needs to look at .hi files,
and that it either can't find them (Prelude.hi) or it has the wrong
version number (ParseAndRenameFile.hi). How do we tell the renamer where
to look for the interface files, and fix the version error?
I've included the three files (Makefile, Main.hs, and
ParseAndRenameFile.hs) at the bottom of this email.
Thanks in advance for you any thoughts you might have,
Kate
===========================================================
Makefile:
HC = ghc-4.08
INTERFACE_FILES =
.:compiler/absCSyn:compiler/basicTypes:compiler/codeGen:compiler/coreSyn:compiler/cprAnalysis:compiler/deSugar:compiler/hsSyn:compiler/javaGen:compiler/main:compiler/nativeGen:compiler/parser:compiler/prelude:compiler/profiling:compiler/rename:compil
er/simplCore:compiler/simplStg:compiler/specialise:compiler/stgSyn:compiler/stranal:compiler/typecheck:compiler/types:compiler/usageSP:compiler/utils:/home/lumberjacks/deforest/ghc-4.08/fptools-binaries/lib/i386-unknown-linux/imports/lang/
HC_OPTS = -cpp -i$(INTERFACE_FILES) $(EXTRA_HC_OPTS) -fglasgow-exts
SRCS = Main.hs ParseAndRenameFile.hs
OBJS = Main.o ParseAndRenameFile.o
.SUFFIXES : .o .hs .hi .lhs .hc .s
all: $(OBJS)
$(HC) -lHSlang -lNewGHC
-L/usr/users/deforest/ghc-4.08/fptools-newgcc-build/lib -o PARF $(HC_OPTS)
$(OBJS)
# Standard suffix rules
.o.hi:
@:
.lhs.o:
$(HC) -c $< $(HC_OPTS)
.hs.o:
$(HC) -c $< $(HC_OPTS)
depend :
$(HC) -M $(HC_OPTS) $(SRCS)
# DO NOT DELETE: Beginning of Haskell dependencies
Main.o : Main.hs
Main.o : ./ParseAndRenameFile.hi
ParseAndRenameFile.o : ParseAndRenameFile.hs
ParseAndRenameFile.o : compiler/basicTypes/UniqSupply.hi
ParseAndRenameFile.o : compiler/rename/Rename.hi
ParseAndRenameFile.o : compiler/utils/FastString.hi
ParseAndRenameFile.o : compiler/hsSyn/HsSyn.hi
ParseAndRenameFile.o : compiler/basicTypes/BasicTypes.hi
ParseAndRenameFile.o : compiler/parser/RdrHsSyn.hi
ParseAndRenameFile.o : compiler/utils/FastString.hi
ParseAndRenameFile.o : compiler/utils/StringBuffer.hi
ParseAndRenameFile.o : compiler/parser/Parser.hi
ParseAndRenameFile.o : compiler/parser/Lex.hi
ParseAndRenameFile.o : compiler/basicTypes/SrcLoc.hi
ParseAndRenameFile.o : compiler/rename/RnMonad.hi
ParseAndRenameFile.o : compiler/main/MkIface.hi
ParseAndRenameFile.o : compiler/typecheck/TcModule.hi
ParseAndRenameFile.o : compiler/basicTypes/Module.hi
ParseAndRenameFile.o : compiler/main/CmdLineOpts.hi
ParseAndRenameFile.o : compiler/main/ErrUtils.hi
ParseAndRenameFile.o : compiler/utils/Outputable.hi
# DO NOT DELETE: End of Haskell dependencies
===========================================================
Main.hs:
module Main where
import ParseAndRenameFile
main :: IO ()
main = parseAndRename "Main.hs"
===========================================================
ParseAndRenameFile.hs:
module ParseAndRenameFile where
import UniqSupply ( mkSplitUniqSupply )
import Rename ( renameModule )
import FastString
--
import IO ( hPutStr, stderr )
import HsSyn
import BasicTypes ( NewOrData(..) )
import RdrHsSyn ( RdrNameHsModule )
import FastString ( mkFastCharString, unpackFS )
import StringBuffer ( hGetStringBuffer )
import Parser ( parse )
import Lex ( PState(..), P, ParseResult(..) )
import SrcLoc ( mkSrcLoc )
import RnMonad ( InterfaceDetails(..) )
import MkIface ( startIface, ifaceDecls, endIface )
import TcModule ( TcResults(..), typecheckModule )
import Module ( ModuleName, moduleNameUserString )
import CmdLineOpts
import ErrUtils ( ghcExit )
import Outputable
parseAndRename filename
= do {(name, parsed) <- parseFile filename;
rn_uniqs <- mkSplitUniqSupply 'r';
maybe <- renameModule rn_uniqs parsed;
putStr "done \n"
}
--parseFile is adapted from parseModule in compiler/main/Main.lhs
parseFile :: String -> IO (ModuleName, RdrNameHsModule)
parseFile filename = do
{buf <- hGetStringBuffer True{-expand tabs-} filename;
case parse buf PState{ bol = 0#,
atbol = 1#,
context = [],
glasgow_exts = glaexts,
loc = mkSrcLoc (mkFastString filename) 1 } of
PFailed err -> do
printErrs err
ghcExit 1
return (error "parseModule") -- just to get the types right
POk _ m@(HsModule mod _ _ _ _ _ _) ->
return (mod, m)
}
where
glaexts | opt_GlasgowExts = 1#
| otherwise = 0#
===========================================================
Thanks again!
From stolz@I2.Informatik.RWTH-Aachen.DE Thu Jan 25 11:51:18 2001
From: stolz@I2.Informatik.RWTH-Aachen.DE (Volker Stolz)
Date: Thu, 25 Jan 2001 12:51:18 +0100
Subject: limited suspending on readChan possible?
Message-ID: <20010125125118.A22095@agamemnon.informatik.rwth-aachen.de>
Hello everyone, I thought I´d return to more earthly issue than discovering
bugs in signal handlers etc. :)
I´ve been looking for a way to suspend on an empty channel for only a
limited time. So I came up with a solution which involves dupChan (which
is currently broken as stated in Meurig´s bug-report) and unGetChan:
> timedReadChan ch t = do
> dup <- dupChan ch
> mv <- newEmptyMVar
> forkIO (do
> msg <- readChan dup
> putMVar mv True
> )
> forkIO (do
> threadDelay t
> putMVar mv False
> )
> res <- takeMVar mv
> if res
> then do
> -- we discard dup and re-read from ch:
> msg <- readChan ch
> return (Just msg)
> else (return Nothing)
However, shouldn´t the dupChan be a space-leak par excellence? We end up
having no readers and keep adding new meesages to dup...
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From qrczak@knm.org.pl Thu Jan 25 19:41:58 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 25 Jan 2001 19:41:58 GMT
Subject: _scc_
Message-ID:
Why
_scc_ "foo"
and not
{-# SCC "foo" #-}
?
IMHO a pragma would be better: does not make the scc-annotated program
non-standard.
(Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary
places.)
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From kort@wins.uva.nl Fri Jan 26 16:40:17 2001
From: kort@wins.uva.nl (Jan Kort)
Date: Fri, 26 Jan 2001 17:40:17 +0100
Subject: Floating point performance
Message-ID: <3A71A871.52EF6197@wins.uva.nl>
Hi,
I noticed ghc (version 4.08.1) floating point performance is
really slow on my computer: a 270Mhz sun ultra5. The program
below does 1 milion floating point multiplications and takes
2 seconds to run. I made a profile and it says most of the
time (93%) is spent in the function bar. Any idea what is
going on ?
Regards,
Jan
module Main where
foo :: Double -> [Double]
foo 0 = [1]
foo n = bar n:foo (n-1)
bar :: Double -> Double
bar n = n*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
*1*1*1*1*1*1*1*1*1*1
foldl' :: (a -> b -> a) -> a -> [b] -> a
foldl' _ a [] = a
foldl' f a (x:xs) = (foldl' f $! f a x) xs
main :: IO()
main = putStrLn (show (foldl' (+) 0 (foo 10000)))
---------------------------
Profile:
total time = 2.60 secs (130 ticks @ 20 ms)
total alloc = 24,845,828 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
bar Main 93.1 96.1
foo Main 3.1 2.4
foldl' Main 3.1 1.4
individual inherited
COST CENTRE MODULE entries %time %alloc %time %alloc
MAIN MAIN 0 0.0 0.0 100.0 100.0
main Main 0 0.0 0.0 0.0 0.0
CAF PrelShow 1 0.0 0.0 0.0 0.0
CAF PrelFloat 3 0.0 0.0 0.0 0.0
CAF PrelHandle 3 0.0 0.0 0.0 0.0
CAF Main 9 0.0 0.0 100.0 100.0
main Main 1 0.8 0.0 100.0 100.0
foo Main 10001 3.1 2.4 96.2 98.5
bar Main 10000 93.1 96.1 93.1 96.1
foldl' Main 10002 3.1 1.4 3.1 1.4
From qrczak@knm.org.pl Fri Jan 26 17:16:20 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 26 Jan 2001 17:16:20 GMT
Subject: Floating point performance
References: <3A71A871.52EF6197@wins.uva.nl>
Message-ID:
Fri, 26 Jan 2001 17:40:17 +0100, Jan Kort pisze:
> I made a profile and it says most of the time (93%) is spent in
> the function bar.
Did you compile with optimization turned on (option -O)?
I see similar results without -O but quite different with -O.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Fri Jan 26 15:04:33 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 26 Jan 2001 07:04:33 -0800
Subject: _scc_
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F3F0@TVP-MSG-01.europe.corp.microsoft.com>
> Why
> _scc_ "foo"
> and not
> {-# SCC "foo" #-}
> ?
>
> IMHO a pragma would be better: does not make the scc-annotated program
> non-standard.
>
> (Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary
> places.)
Good suggestion. I'm not sure why it was done the current way; perhaps
it was before the advent of pragmas. Anyway, on my ToDo list it goes...
Cheers,
Simon
From simonmar@microsoft.com Fri Jan 26 15:09:57 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 26 Jan 2001 07:09:57 -0800
Subject: limited suspending on readChan possible?
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61157BD@TVP-MSG-01.europe.corp.microsoft.com>
> Hello everyone, I thought I?d return to more earthly issue
> than discovering
> bugs in signal handlers etc. :)
>
> I?ve been looking for a way to suspend on an empty channel for only a
> limited time. So I came up with a solution which involves
> dupChan (which
> is currently broken as stated in Meurig?s bug-report) and unGetChan:
How about
timeout N . readChan
where timeout is defined according to our Asynchronous Exceptions paper
(see http://www.haskell.org/~simonmar/papers/async.ps.gz).
Cheers,
Simon
From simonpj@microsoft.com Thu Jan 25 12:41:31 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 25 Jan 2001 04:41:31 -0800
Subject: using the GHC parser and renamer
Message-ID: <74096918BE6FD94B9068105F877C002D355B85@red-pt-02.redmond.corp.microsoft.com>
Kate
I'm sorry not to have replied to your earlier message; I've been
away at POPL etc. Incidentally, for implementation-related
things, better to use glasgow-haskell-bugs (albeit it's not actually a
bug)
rather than glasgow-haskell-users.
GHC 4.08 (which is the place from which you got your code, I think)
uses a "driver" written in perl to coordinate its operations. The
driver
runs cpp, then GHC itself (a binary called 'hsc'), then gcc, then as,
then ld.
Run ghc-4.08 with "-v" to see what it does.
My bet is that you are running your bits-of-ghc-plus-bits-of-your-own
binary directly. So it's not getting all the command-line flags it
expects.
(nor are they documented, because it's an internal interface).
| Main.hs:1:
| Could not find interface file for 'Prelude'
| in the directories ./*.hi
It's not looking in the right directories because it hasn't been told
to do so by the command-line flags. If you run ghc-4.08 -v you'll
see how the driver communicates which directctories to look in.
| Main.hs:3:
| Bad interface file:: ./ParseAndRenameFile.hi
| ./ParseAndRenameFile.hi:1 Interface file=20
| version error; Expected 0
| found version 408
The version number it expects to find is again communicated by
a command line flag. For your purposes you may not care, so
one option is to just remove the test. Or ghc-4.08 -v will show
you what the driver is saying to hsc.
Incidentally, Tim Sheard at OGI is building a modular front end for
Haskell, in the spirit of Mark Jones's Typing Haskell in Haskell paper.
It might be worth asking him whether it's in a borrow-able state,
becuase
it's probably less of a monster than GHC.
Simon
From simonpj@microsoft.com Mon Jan 29 09:05:35 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 29 Jan 2001 01:05:35 -0800
Subject: 4.08.2
Message-ID: <74096918BE6FD94B9068105F877C002D355B5D@red-pt-02.redmond.corp.microsoft.com>
George
I'm sorry we've been silent. MS has some kind of huge email backlog.
But the real reason is that POPL and a workshop have intervened so
we've been out of action for a fortnight.
The plan is to release 4.08.2 in a matter of days, not weeks. If you build
the head of the ghc-4-07-branch you'll get the current 4.08.2, and we expect
only
tiny changes before the release (e.g. making sure it all works on Sparc).
4.08 remains our "stable branch".
Simon
| -----Original Message-----
| From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de]
| Sent: 23 January 2001 22:23
| To: George Russell
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: 4.08.2
|
|
| George Russell wrote:
| > Since the absence of any reply presumably means "not for a
| while yet",
|
| I'm not so sure about this, there has been quite some
| bug-fixing and it's
| not clear to me what's missing for a release. Simon^2?
|
| > could someone let me have a compiled hsc for the ghc-4.08 head
| > on something reasonably close to SunOS/sparc Ultra-1?
|
| The current branch-o-mania is a little confusing, but the CVS branch
| called "ghc-4-07-branch" (yes, "7", not "8") should contain what you
| are looking for. At least I think so... :-} Any
| bootstrapping problems?
|
| Cheers,
| Sven
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From v-julsew@microsoft.com Mon Jan 29 13:33:23 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Mon, 29 Jan 2001 05:33:23 -0800
Subject: Floating point performance
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60EFB8D@red-msg-06.redmond.corp.microsoft.com>
I tried this, with ghc-4.08.1 -O both with and without
profiling, on a Sparc box of I believe around 300 MHz,
and I can't reproduce it at all. Without profiling,
it allocates about 505 k of heap and runs in 0.02
seconds.
Ummm ?
J
| -----Original Message-----
| From: Jan Kort [mailto:kort@wins.uva.nl]
| Sent: Friday, January 26, 2001 4:40 PM
| To: glasgow-haskell-users@haskell.org
| Subject: Floating point performance
|
|
| Hi,
| I noticed ghc (version 4.08.1) floating point performance is
| really slow on my computer: a 270Mhz sun ultra5. The program
| below does 1 milion floating point multiplications and takes
| 2 seconds to run. I made a profile and it says most of the
| time (93%) is spent in the function bar. Any idea what is
| going on ?
|
| Regards,
| Jan
|
| module Main where
|
| foo :: Double -> [Double]
| foo 0 = [1]
| foo n = bar n:foo (n-1)
|
| bar :: Double -> Double
| bar n = n*1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
| *1*1*1*1*1*1*1*1*1*1
|
| foldl' :: (a -> b -> a) -> a -> [b] -> a
| foldl' _ a [] = a
| foldl' f a (x:xs) = (foldl' f $! f a x) xs
|
| main :: IO()
| main = putStrLn (show (foldl' (+) 0 (foo 10000)))
|
| ---------------------------
| Profile:
|
| total time = 2.60 secs (130 ticks @ 20 ms)
| total alloc = 24,845,828 bytes (excludes profiling
| overheads)
|
| COST CENTRE MODULE %time %alloc
|
| bar Main 93.1 96.1
| foo Main 3.1 2.4
| foldl' Main 3.1 1.4
|
|
| individual inherited
| COST CENTRE MODULE entries %time %alloc
| %time %alloc
|
| MAIN MAIN 0 0.0 0.0
| 100.0 100.0
| main Main 0 0.0 0.0
| 0.0 0.0
| CAF PrelShow 1 0.0 0.0
| 0.0 0.0
| CAF PrelFloat 3 0.0 0.0
| 0.0 0.0
| CAF PrelHandle 3 0.0 0.0
| 0.0 0.0
| CAF Main 9 0.0 0.0
| 100.0 100.0
| main Main 1 0.8 0.0
| 100.0 100.0
| foo Main 10001 3.1 2.4
| 96.2 98.5
| bar Main 10000 93.1 96.1
| 93.1 96.1
| foldl' Main 10002 3.1 1.4
| 3.1 1.4
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From kort@wins.uva.nl Mon Jan 29 17:15:02 2001
From: kort@wins.uva.nl (Jan Kort)
Date: Mon, 29 Jan 2001 18:15:02 +0100
Subject: Floating point performance
References: <68B95AA1648D1840AB0083CC63E57AD60EFB8D@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <3A75A516.26CAB5C7@wins.uva.nl>
"Julian Seward (Intl Vendor)" wrote:
>
> I tried this, with ghc-4.08.1 -O both with and without
> profiling, on a Sparc box of I believe around 300 MHz,
> and I can't reproduce it at all. Without profiling,
> it allocates about 505 k of heap and runs in 0.02
> seconds.
>
> Ummm ?
>
> J
I didn't use any optimizations, but I am sure that
passing -O to ghc will make it see that 1*1*... is a
constant expression. I guess turning all optimizations
off is not the right way to test stuff either.
Jan
From shutej@rpi.edu Mon Jan 29 21:07:53 2001
From: shutej@rpi.edu (Jeremy Shute)
Date: Mon, 29 Jan 2001 16:07:53 -0500
Subject: Using GHC with Green Card under Win32
In-Reply-To:
Message-ID:
Sigbjorn:
Yes, this works perfectly now. Thanks!
I've taken the liberty of mailing this to the GHC mailing list so hopefully
it can percolate to the archives and be of use to others (I know I usually
check there first). I hope this won't be considered misuse of the list...
Thanks again!
Jeremy Shute
> -----Original Message-----
> From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com]
> Sent: Monday, January 29, 2001 1:21 PM
> To: Jeremy Shute
> Subject: Re: Troubles running ScriptReg
>
>
> Yes, you don't want to link against the Hugs DLL when
> you're working with ghc compiled code. Try adding
> -package greencard to the final link line.
>
> --sigbjorn
>
> ----- Original Message -----
> From: "Jeremy Shute"
> To: "Sigbjorn Finne"
> Sent: Monday, January 29, 2001 18:53
> Subject: RE: Troubles running ScriptReg
>
>
> > Yes, now things work wonderfully. I've written a little shell script to
> > automate the process, the .o builds fine! Now I'm trying to make use of
> the
> > library:
> >
> >
> >
> > $ ghc -static Main.hs Gimme.o -fglasgow-exts -fvia-C \
> >
> >
> '-iF:\\usr\\share\\ghc\\lib\\imports\\greencard;F:\\usr\\share\\gh
> c\\lib\\im
> > ports\\greencard'
> > Compilation IS NOT required
> > Output file not specified, defaulting to "main.exe"
> > Gimme.o(.text+0x38):ghc1140.c: undefined reference to `__init_StdDIS'
> > Gimme.o(.text+0x144):ghc1140.c: undefined reference to
> > `StdDIS_unmarshallzustringzu_closure'
> > Gimme.o(.text+0x250):ghc1140.c: undefined reference to
> > `StdDIS_unmarshallzustringzu_closure'
> > collect2: ld returned 1 exit status
> >
> >
> >
> > I've crawled the drive and found that the only C code-ish file
> for StdDIS
> > are StdDIS.dll, and that's in greencard\lib\hugs... I don't
> think linking
> > against that would be appropriate. When I omit that trailing
> '-iF:\\...',
> > the same errors are output. Sooo close!
> >
> > Perhaps I should post all this to the mailing list, just so people can
> find
> > it while crawling the archives? I would think these are fairly useful
> > nuggets of info. :-)
> >
> > Jeremy
> >
> >
> >
> > > -----Original Message-----
> > > From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com]
> > > Sent: Friday, January 26, 2001 12:30 PM
> > > To: Jeremy Shute
> > > Subject: Re: Troubles running ScriptReg
> > >
> > >
> > >
> > > Good to hear that you're up and running, at least on the HaskellScript
> > > side. You're close on the GC side too - to properly process the input
> > > you need to use the -i option to inform GC where it can slurp in
> > > StdDIS.gc from (Although the docs says so, the binary doesn't
> > > automatically
> > > figure this out..) So, if you invoke it as follows
> > >
> > > green-card -tghc Gimme.gc -iF:\\usr\\share\\greencard\\lib\\ghc
> > >
> > > the warning should go away. To compile Gimme.hs with ghc-4.08,
> > > use the following command-line:
> > >
> > > ghc -static -c Gimme.hs -fglasgow-exts -fvia-C \
> > >
> > > '-iF:\\usr\\share\\greencard\\lib\\ghc;F:\\usr\\share\\greencard\\
> > > lib\\ghc'
> > >
> > > i.e., you need to kludge around a bit to get DOS-style paths to work
> > > OK & redundantly give it twice, using ';' as separator.
> > >
> > > To generate Hugs-compatible output on a Win32 box, Section 12.2 of
> > > the manual contains accurate info.
> > >
> > > hth,
> > > --sigbjorn
> > >
> > > ----- Original Message -----
> > > From: "Jeremy Shute"
> > > To: "Sigbjorn Finne"
> > > Sent: Friday, January 26, 2001 02:56
> > > Subject: RE: Troubles running ScriptReg
> > >
> > >
> > > > Howdy, Sigbjorn.
> > > >
> > > > Confirming again that Hugs now works great with
> HaskellScript (or what
> > > I've
> > > > tested of it, at least, ;-) )...
> > > >
> > > > Now here I am, staring at Green Card, realizing that you're
> one of the
> > > > authors. You sure do get around in the Haskell world!
> > > >
> > > > I'm running GHC-4.08.1 and Green Card 2 (presumably 2.01, I
> installed
> it
> > > > right before Christmas break). I've looked at the example
> > > online of GDBM,
> > > > and am trying this code:
> > > >
> > > > ----------------------------------------
> > > > %#include "hello.h"
> > > > {-
> > > > Testing... This is Gimme.gc!
> > > > -}
> > > >
> > > > module Gimme( gimme )
> > > >
> > > > where
> > > >
> > > > import StdDIS
> > > > import Foreign( ForeignObj,
> > > > makeForeignObj )
> > > >
> > > > %fun gimme :: IO String
> > > > %code
> > > > %result (string {hello()})
> > > >
> > > > ----------------------------------------
> > > > /*
> > > > Testing... This is hello.h!
> > > > */
> > > >
> > > > char* hello( ) {
> > > > return "Howdy!\n";
> > > > }
> > > >
> > > > ----------------------------------------
> > > >
> > > > I run:
> > > >
> > > > green-card.exe -tghc Gimme.gc
> > > >
> > > > It says:
> > > >
> > > > Warning: unable to find StdDIS in:
> > > >
> > > > Notice how it says nothing after the "in"... I've scoured
> the manual
> > > > looking for ways to set the library path of green card, and
> either I'm
> > > > missing something or it's not there... Reguardless, I suppose
> > > I'm not too
> > > > TERRIBLY concerned at this stage, as I still have a
> Gimme.hs that it's
> > > > produced. The contents of which are (the comment is no longer
> correct,
> > > but
> > > > I left it reguardless):
> > > >
> > > > ----------------------------------------
> > > > {-# OPTIONS -#include "hello.h" #-}
> > > > {-
> > > > Testing... This is Gimme.gc!
> > > > -}
> > > >
> > > > module Gimme( gimme )
> > > >
> > > > where
> > > >
> > > > import StdDIS
> > > > import Foreign( ForeignObj,
> > > > makeForeignObj )
> > > >
> > > > gimme :: IO String
> > > > gimme =
> > > > _casm_ ``do {do {} while(0);} while(0);''
> > > > (unmarshall_string hello()) >>= \ gc_res1 ->
> > > >
> > > > ----------------------------------------
> > > >
> > > > That last line may wrap in your email... gimme= should be
> followed by
> 2
> > > > lines. The file's contents look OK, so I look up where StdDIS.hs is
> > > located
> > > > under my Green Card directory, stuff that onto GHC's command
> > > line, and try
> > > > to whip out an executable of some sort (using the static flag
> > > because it's
> > > > necessary under this version of GHC for Win32). Okay, so here comes
> the
> > > > part where I blame it on GHC instead of Green Card:
> > > >
> > > > I run:
> > > >
> > > > ghc -static -iF:\\usr\\share\\greencard\\lib\\ghc\\ Gimme.hs
> > > >
> > > > It says:
> > > >
> > > > Gimme.hs:15: parse error on input ``'
> > > >
> > > > I have reinstalled Green Card several times, moved things
> around, been
> > > > pretty thorough... Tried various other code, and it always
> > > lands me with
> > > > this message. I can only presume that I'm being foolish, yet again,
> and
> > > > that perhaps this newer version of GHC is mutually exclusive with
> Green
> > > > Card? Please advise.
> > > >
> > > > :-) So far, my experience with the language has been nothing but
> > > positive.
> > > > I tried out Erlang, too, and Haskell just feels cleaner.
> > > However, getting
> > > > the implementations set up is quite daunting...
> > > >
> > > >
> > > >
> > > > Jeremy Shute
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Sigbjorn Finne [mailto:sigbjorn_finne@hotmail.com]
> > > > > Sent: Wednesday, January 17, 2001 7:00 AM
> > > > > To: Jeremy Shute
> > > > > Cc: daan@cs.uu.nl; erik@cs.uu.nl
> > > > > Subject: Re: Troubles running ScriptReg
> > > > >
> > > > >
> > > > > Hi Jeremy,
> > > > >
> > > > > I don't know if anyone else has been trying to help you out,
> > > > > but the HaskellScript binary you're using is not quite
> > > > > up-to-date with the available Hugs98 binaries and libraries,
> > > > > i.e., Addr.addrToInt is a recent addition to the Addr lib.
> > > > >
> > > > > My initial suggestion would be to simply comment-out
> > > > > the 'primitive' declaration for addrToInt and try again --
> > > > > addrToInt isn't used all that much, anyway.
> > > > >
> > > > > --sigbjorn
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Jeremy Shute"
> > > > > To: ;
> > > > > Cc:
> > > > > Sent: Sunday, January 14, 2001 19:17
> > > > > Subject: Troubles running ScriptReg
> > > > >
> > > > >
> > > > > > I'm having some difficulty with HaskellScript under Windows 2000
> > > > > > Professional. My progress so far:
> > > > > >
> > > > > > * Downloaded and installed Hugs 98: November 1999
> version. Chose
> > > > > "typical"
> > > > > > install. Hugs resides in "C:\Hugs98".
> > > > > >
> > > > > > * Downloaded and installed HaskellScript (build 11).
> HaskellScript
> > > > > resides
> > > > > > in "C:\HScript98".
> > > > > >
> > > > > > * Started reading through the documentation and figured I'd try
> > > > > ScriptReg
> > > > > > (in the demos directory) on the included Calculator
> > > example, as noted
> > > at
> > > > > the
> > > > > > bottom of
> > > http://haskell.cs.yale.edu/haskellscript/osexamples.html. A
> > > > > popup
> > > > > > window informed me that Prelude.hs was not found. I
> > > investigated the
> > > > > > contents of my registry and determined that
> HaskellScript doesn't
> > > assume
> > > > > or
> > > > > > ask for any information about Hugs' install directory, so I came
> up
> > > with
> > > > > the
> > > > > > quick fix I've attached. Maybe you can make it useful to
> others...
> > > > > >
> > > > > > * ScriptReg now fails with a MsgBox. The title of the box is
> > > > > "HugsScript"
> > > > > > and the error message follows:
> > > > > >
> > > > > > error: ERROR "C:\Hugs98\lib\exts\Addr.hs" (line 23):
> > > Unknown primitive
> > > > > > reference "addrToInt"
> > > > > >
> > > > > > When the "OK" button is pressed, another message box pops
> > > up, this one
> > > > > > titled "ScriptReg", which states:
> > > > > >
> > > > > > Run-time error '440':
> > > > > >
> > > > > > Automation error
> > > > > >
> > > > > > * Checked out the contents of Addr.hs... Everything looks in
> > > > > order. Line
> > > > > > 14 in this file reads:
> > > > > >
> > > > > > -- data Addr -- in Prelude
> > > > > >
> > > > > > So I looked in Prelude.hs. Line 1605 of Prelude.hs reads:
> > > > > >
> > > > > > data Addr -- builtin datatype of C pointers
> > > > > >
> > > > > > Prelude.hs also contains the appropriate Standard Integral
> > > types. I'm
> > > > > left
> > > > > > wondering if Prelude.hs isn't processed before Addr.hs???
> > > This is the
> > > > > only
> > > > > > suspicion I have, maybe I've missed something?
> > > > > >
> > > > > > I would appreciate any insight you could give me: Two weeks
> > > > > from now I'm
> > > > > > starting on a web spider that's going to have to have bayesian
> > > > > classifiers
> > > > > > and neural networking components. I want to encapsulate these
> parts
> > > in
> > > > > > Haskell, but that would be a much easier case to make to my
> > > boss if my
> > > > > > coworkers could access my code from COM!
> > > > > >
> > > > > > Thanks so much!
> > > > > >
> > > > > > Jeremy
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
From qrczak@knm.org.pl Mon Jan 29 21:24:27 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 29 Jan 2001 21:24:27 GMT
Subject: Floating point performance
References: <68B95AA1648D1840AB0083CC63E57AD60EFB8D@red-msg-06.redmond.corp.microsoft.com> <3A75A516.26CAB5C7@wins.uva.nl>
Message-ID:
Mon, 29 Jan 2001 18:15:02 +0100, Jan Kort pisze:
> I didn't use any optimizations, but I am sure that
> passing -O to ghc will make it see that 1*1*... is a
> constant expression.
It does not, because it's n*1*1*1*... where n is not a constant.
Major advantages seem to be from the strictness analysis.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Mon Jan 29 13:25:36 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 29 Jan 2001 13:25:36 -0000
Subject: Floating point performance
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F3FD@TVP-MSG-01.europe.corp.microsoft.com>
> Fri, 26 Jan 2001 17:40:17 +0100, Jan Kort pisze:
>=20
> > I made a profile and it says most of the time (93%) is spent in
> > the function bar.
>=20
> Did you compile with optimization turned on (option -O)?
> I see similar results without -O but quite different with -O.
Without optimisation, you get the native code generator which produces
particularly brain-dead code for floating point on x86 (mainly due to
Intel's brain-dead design of the x86 floating point unit). With
optimisation, you get gcc.
Cheers,
Simon