- Glasgow-haskell-users

problems with haxml
by Siemens Entwicklungsteam 29 Jun '01

29 Jun '01

Hello, we are developing haskell programs with XML interfaces (using haxml). So far, we tested all our source files in HUGS98, which always worked fine. Now we have to compile them with ghc(version 4.08.2 with Cygwin in Windows NT) which causes several errors. Linking Xml2Haskell.o, XmlParse.o, XmlTypes.o etc. to it reduced the number of errors a lot. The only one that is left now is the following one: XmlParse.o(.text+0x20):fake: undefined reference to `__init_IOExts' Unfortunately this sounds pretty much chinese to us. We think linking IOExts.o to the file, might help - unfortunately we don't know where to find this object file. We would highly appreciate any help since our realease deadline is in three days and we start getting nervous, thanx, Kilian PS: We also tried to use hmake which unfortuantely always returned the error message: module IO not found. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0

GHC Alpha port?
by Ken Shan 27 Jun '01

27 Jun '01

Hello, A few users at our site have asked about running GHC on Alpha machines. In addition to following the instructions at http://www.haskell.org/ghc/docs/4.08.2/building/sec-port-info.html I'm also personally curious about what work would involved in making GHC work again on Alphas. Could someone give an overview? Thanks in advance. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig .

1 0

Re: Patch ghci to recognize :q!
by Ashley Yakeley 27 Jun '01

27 Jun '01

At 2001-06-27 01:41, Michael Weber wrote: >> Would somebody object to a patch which will cause >> ghci to quit on ":q!"? > >Oh, and I want C-x C-c >... and C-K Q while we're at it... ;-p Ya wusses. "kill -9" from another shell is the way to go. -- Ashley Yakeley, Seattle WA

1 0

RE: ThreadId
by Simon Marlow 27 Jun '01

27 Jun '01

> How much of a thread's memory is kept alive - after the > thread has terminated - as long as a program holds on to the > thread's `ThreadId'? The following ToDo comment in > `PrelConc' seems to indicate that it is currently more than > we really want: > > data ThreadId = ThreadId ThreadId# > -- ToDo: data ThreadId = ThreadId (Weak ThreadId#) > -- But since ThreadId# is unlifted, the Weak type must use open > -- type variables. > > In combination with finalisers, this can be troublesome. At the moment, the thread is kept completely alive by holding the ThreadId. Doing the weak pointer thing doesn't seem too hard. Something like this should work: data ThreadId = ThreadId (Weak# ThreadId#) mkThreadId :: ThreadId# -> IO ThreadId mkThreadId t = IO $ \s -> case mkWeak# t t (unsafeCoerce# 0#) s of (# s, w #) -> (# s, ThreadId w #) but you'll also need to update the other operations on ThreadIds. Cheers, Simon

1 0

Patch ghci to recognize :q!
by Volker Stolz 27 Jun '01

27 Jun '01

Maybe I'm the only one who happens to type :q! to leave ghci all the time, maybe not. Would somebody object to a patch which will cause ghci to quit on ":q!"? -- Volker Stolz * vs(a)foldr.org * PGP + S/MIME

2 1

GHC 5.00.2 RPM apparently circular dependency demands
by Byron Hale 26 Jun '01

26 Jun '01

Hi, This is probably ignorance on my part, but I am having trouble installing ghc.5.00.2 with the new RPMs. Here is the data I have recorded. Perhaps different installation parameters are required? Redhat Linux 6.2, I686 SMP Glasgow Haskell Compilation System, version 5.00.1 rpm --version RPM version 4.0.2 rpm -U ghc-5.00.2-rh62-1.i386.rpm error: failed dependencies: ghc = 4.08 is needed by ghc-prof-4.08-1 ghc = 5.00.1 is needed by ghc-prof-5.00.1-1 rpm -i --force ghc-5.00.2-rh62-1.i386.rpm Segmentation fault (core dumped) Thanks in advance. Byron Hale byron.hale(a)einfo.com

4 3

Re: GHC core representation
by Sigbjorn Finne 25 Jun '01

25 Jun '01

simonpj(a)microsoft.com writes: >> >> ....Josef wanting to squirrel away ExtCore and .hi's only.... > > This would be a Good Thing and not too hard. > How would you like to specify where to stop? "After the last > blob of debug output" might be a reasonable answer, but > we definitely also want to be able to carry on. Yet another flag? FWIW, GHCen up until 5.xx let you achieve this with their command line options, e.g., foo$ ghc-4.08.2 -noC foo.hs -ddump-ds -ohi Foo.hi ..... foo$ --sigbjorn

1 0

RE: GHC core representation
by Simon Peyton-Jones 25 Jun '01

25 Jun '01

| * I would like to make GHC generate only the core file and | the hi file, nothing more. However, I haven't found a way of | making GHC stop after outputting the hi file. Being able to | do this is useful in some other cases as well; I sometimes | look at the raw core that comes is printed with the -ddump* | flags. It is often the case that I don't want anything to be | generated then. This would be a Good Thing and not too hard. How would you like to specify where to stop? "After the last blob of debug output" might be a reasonable answer, but we definitely also want to be able to carry on. Yet another flag? | * Speaking of arguments, it would be a nice thing if one | could get the output in A-normal-form. This is done by GHC | anyway when converting to STG and in some cases it would be | really useful. GHC is controlled by a little script, one "instruction" of which is "dump the ext-core". I have long wanted to externalise the script file so that you can write it youself; just one more thing we have not done yet. Simon

2 1

RE: [ ghc-Bugs-434259 ] <<loop>>
by Simon Peyton-Jones 25 Jun '01

25 Jun '01

Folks, Sorry to bother you all with this, but someone submitted the enclosed bug report to SourceForge. Unfortunately, s/he didn't give an email address, nor did s/he give a source file that we can compile to expose the bug. If you submitted this, could you declare your identity! Otherwise this will stay unfixed. (Pls also try with 5.00.2 because it may well be fixed already.) Simon | -----Original Message----- | From: noreply(a)sourceforge.net [mailto:noreply@sourceforge.net] | Sent: 18 June 2001 19:47 | To: noreply(a)sourceforge.net | Subject: [ ghc-Bugs-434259 ] <<loop>> | | | Bugs item #434259, was updated on 2001-06-18 11:46 | You can respond by visiting: | http://sourceforge.net/tracker/?func=detail&atid=108032&aid=43 | 4259&group_id=8032 | | Category: Compiler (Parser) | Group: None | Status: Open | Resolution: None | Priority: 5 | Submitted By: Nobody/Anonymous (nobody) | Assigned to: Nobody/Anonymous (nobody) | Summary: <<loop>> | | Initial Comment: | ghc -c -fglasgow-exts Typedecl.hs (and without flag) | ghc-5.00: panic! (the `impossible' happened, GHC | version 5.00): | <<loop>> | | Please report it as a compiler bug to | glasgow-haskell-bugs(a)haskell.org, or | http://sourceforge.net/projects/ghc/. | | | data Val = | ....... | | Fun (Val -> TM Val) | | | type TM a = EnvT | ( ST1 Record | ( ST3 String | ( MaybeT | ( IdM)))) a | | | | | ---------------------------------------------------------------------- | | You can respond by visiting: | http://sourceforge.net/tracker/?func=detail&atid=108032&aid=43 4259&group_id=8032 _______________________________________________ Cvs-ghc mailing list Cvs-ghc(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

1 0

ThreadId
by Manuel M. T. Chakravarty 24 Jun '01

24 Jun '01

How much of a thread's memory is kept alive - after the thread has terminated - as long as a program holds on to the thread's `ThreadId'? The following ToDo comment in `PrelConc' seems to indicate that it is currently more than we really want: data ThreadId = ThreadId ThreadId# -- ToDo: data ThreadId = ThreadId (Weak ThreadId#) -- But since ThreadId# is unlifted, the Weak type must use open -- type variables. In combination with finalisers, this can be troublesome. Cheers, Manuel

1 0