RE: Re[2]: C--

On 01 August 2005 14:25, Bulat Ziganshin wrote: > Monday, August 01, 2005, 4:13:16 PM, you wrote: > >> On 31 July 2005 08:10, Bulat Ziganshin wrote: > >>> can you please say about value of using C-- in GHC? will this > >> It should reduce compile time compared to compiling via C, though I >> It

RE: Re[2]: C--

| SPJ> Actually using C-- itself as an output medium keeps slipping down the | SPJ> agenda, mainly because no one asks for it! | | because you don't advertise it! :) if you will advertise the | following, preferably with less or more concrete numbers, then we will | know whether we want it or no

RE: Re[4]: C--

| so, C-- will never be compiled faster than asm, and, at this moment, | cannot give a better optimization than C? as a result, it's use will have no | meaning until qc-- compiler will advance in it's optimization? For those people interested only in getting their Haskell programs compiled, that'

Re: Re-entrant TcRnIf

There are quite a lot of dependencies between different parts of the AST. The renamer takes the whole parser output and then discovers its dependencies. After that you can split things into smaller units based on this dependency graph. The renamer and type checker do not necessarily need to be i

RE: Re-entrant TcRnIf

hat the renaming is preserved (i.e. I can't go all the way down to "LHsExpr RdrName"). Thoughts? Regards, Philip -Original Message- From: Thomas Schilling [mailto:nomin...@googlemail.com] Sent: dinsdag 11 juni 2013 13:46 To: Holzenspies, P.K.F. (EWI) Cc: glasgow-haskell-

RE: Re[2]: garbage collection

On 20 April 2005 15:56, Bulat Ziganshin wrote: > Tuesday, April 19, 2005, 4:15:53 PM, you wrote: > >>> 1) can you add disableGC and enableGC procedures? this can >>> significantly improve performance in some cases > >> Sure. I imagine you want to do this to avoid a major collection >> right at

RE: Re[2]: garbage collection

On Thu, 2005-04-21 at 10:57 +0100, Simon Marlow wrote: > I mentioned madvise() above: this is a compromise solution which > involves telling the kernel that the data in memory is not relevant, but > doesn't actually free the memory. The kernel is free to discard the > pages if memory gets tight, w

RE: Re[4]: garbage collection

On 22 April 2005 13:26, Bulat Ziganshin wrote: >> I see (I think). Unfortunately currently the size of the allocation >> area is fixed after a GC, so you'll have to change the code in the >> runtime to keep allocating more blocks for the nursery. > > so that it is either impossible or too hard,

RE: Re[4]: garbage collection

On 22 April 2005 12:59, Bulat Ziganshin wrote: > also while viewing MBlock.c i wonder why you are aligning megablocks > to megabyte boundary - may be 8-byte aligning would be enough? > megablocks are never copied or allocated as whole, and even in this > case aligning to CPU cache line boundary wi

Re: Re[2]: Benchmarking GHC

On Thu, 2006-10-19 at 21:10 +0400, Bulat Ziganshin wrote: > btw, writing this message i thought that > -fconvert-strings-to-ByteStrings option will give a significant boost > to many programs without rewriting them :) This kind of data refinement has a side condition on the strictness of the func

RE: Re[2]: Benchmarking GHC

Bulat Ziganshin wrote: > Hello Simon, > > Friday, October 20, 2006, 1:38:39 PM, you wrote: > >>> -O2 -funbox-strict-fields >>> >> I'm not sure that -funbox-strict-fields always improves performance, > > we search for solution that improves performance ON AVERAGE Not really: would you turn on a

Re: Re[4]: Benchmarking GHC

Hi So to summarise this thread "compile with -O2", unless you want to start looking at specific programs and checking how the flags perform etc. Thanks, Neil On 10/20/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: Hello Simon, Friday, October 20, 2006, 3:12:29 PM, you wrote: -O2 -funbo

Re: Re[2]: ForeignPtr performance

Thanks for the response guys. I'm still curious as to the specific mechanism by which a strictly compile-time function affects the run-time behavior of the GC. Bulat says that touch# makes the runtime aware that the fptr object is still in use, but how does it do this if, at runtime, it doesn't do

RE: Quick question re RULES

| PrelBase contains the appended code. Am I correct in | assuming that the stuff is structured as it is, because the | "map" rule first `breaks' the map `open', which exposes it | to the various foldr/build rules, and if no foldr/build rule | matches, the "mapList" rule `closes' it again in a lat

RE: Quick question re RULES

Simon Peyton-Jones <[EMAIL PROTECTED]> wrote, > Is this a propos of your new transformations for parallelism? Precisely! Trying to figure out how to generate the fastest possible array code with GHC. Manuel ___ Glasgow-haskell-users mailing list [EM

Re: FW: RE: x86_64 port

000 > To: John Goerzen <[EMAIL PROTECTED]> > Cc: glasgow-haskell-users@haskell.org > Subject: RE: x86_64 port > > On 04 March 2005 16:59, John Goerzen wrote: > > > On Fri, Mar 04, 2005 at 04:57:04PM -, Simon Marlow wrote: > >> On 04 March 2005 14:04, John Go

RE: FW: RE: x86_64 port

On 04 March 2005 17:32, Kurt Roeckx wrote: > I have no idea what ghc has too do with gcc, A bit of background: GHC uses gcc as a backend compiler. GHC generates C code that is compiled using gcc (we also have a native code generator for some platforms; but not for x86_64 yet). > or what the pro

Re: FW: RE: x86_64 port

On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: > $ cat bug.c > register void * R1 __asm__("%r13"); > > extern void g(void); > static void f(void) { > R1 = g; > goto *R1; > } > $ gcc -S -O bug.c > $ > > And take a look at the generated assembly for the function f: > > f: > .

RE: FW: RE: x86_64 port

On 07 March 2005 16:18, David Brown wrote: > On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: > >> $ cat bug.c >> register void * R1 __asm__("%r13"); >> >> extern void g(void); >> static void f(void) { >> R1 = g; >> goto *R1; >> } >> $ gcc -S -O bug.c >> $ >> >> And take a look a

RE: FW: RE: x86_64 port

On 07 March 2005 16:40, Simon Marlow wrote: > On 07 March 2005 16:18, David Brown wrote: > >> On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: >> >>> $ cat bug.c >>> register void * R1 __asm__("%r13"); >>> >>> extern void g(void); >>> static void f(void) { >>> R1 = g; >>> goto *R

Re: FW: RE: x86_64 port

On Mon, Mar 07, 2005 at 04:59:38PM -, Simon Marlow wrote: > The mystery as to why this doesn't affect us on x86 is solved: on x86 we > generate slightly different C code, including a dummy function call: > > extern void g(void); > static void f(void) { > R1 = g; > dummy(); > goto *R1; >

Re: FW: RE: x86_64 port

In message <[EMAIL PROTECTED]> David Brown <[EMAIL PROTECTED]> writes: > On Mon, Mar 07, 2005 at 04:59:38PM -, Simon Marlow wrote: > > > The mystery as to why this doesn't affect us on x86 is solved: on x86 we > > generate slightly different C code, including a dummy function call: > > > > ex

Re: FW: RE: x86_64 port

On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: > > $ cat bug.c > register void * R1 __asm__("%r13"); > > extern void g(void); > static void f(void) { > R1 = g; > goto *R1; > } > $ gcc -S -O bug.c > $ > > And take a look at the generated assembly for the function f: > > f: >

Re: FW: RE: x86_64 port

On Mon, Mar 07, 2005 at 09:15:01AM -0800, David Brown wrote: > > gcc 3.3.4 on AMD64 appears to generate correct code when the dummy call is > present. Ick. It generates the following code here: subq$8, %rsp movl$g, %r13d movl$0, %eax calldummy

Re: FW: RE: x86_64 port

On Mon, Mar 07, 2005 at 07:01:16PM +0100, Kurt Roeckx wrote: > Also, it should be a "movq $g, %rax" instead of movl. The default x86_64 model on gcc is -mcmodel=small, which assumes that all symbols are within the first 2GB. If you compile it with -mcmodel=medium it'll generate: movabsq $g,

RE: FW: RE: x86_64 port

On 07 March 2005 18:01, Kurt Roeckx wrote: > On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: >> >> $ cat bug.c >> register void * R1 __asm__("%r13"); >> >> extern void g(void); >> static void f(void) { >> R1 = g; >> goto *R1; >> } >> $ gcc -S -O bug.c >> $ >> >> And take a look

Re: Newby question re quicksort

I think you miss something important here: quickslop :: (Ord a) => [a] ->[a] quickslop [] = [] quickslop (x:xs) = quickslop [a | a <- xs, a <= x] ++ [x] ++ quickslop [b | b <- xs, b > x] -- View this message in context: http://www.nabble.com/Newby-question-re-quicksort-t

Re: Re: ANN: Happstack 0.4.1

On Mon, Dec 21, 2009 at 6:31 AM, wrote: > Hello, > > That sort of missing symbol error at link time is often (but not always) a > sign that some libraries got recompiled but not others. So there are > references to the old symbol names hanging around. > > I would try to ghc-pkg unregister syb-wit

RE:

isDigit, readDec, and isAscii are defined in module Char, not in the Prelude, at least in Haskell 98 http://haskell.systemsz.cs.yale.edu/definition/ Maybe the version of Hugs you are using is pre-Haskel98. Anyway, just say 'import Char' Simon > -Original Message- > From: Dion M

RE:

[ moved to [EMAIL PROTECTED] ] > please check your link > . At the moment > it is impossible to get the sources for the "happy" library, > and without this > sources it is impossible to compile ghc. That link works for me. If you still have trouble down

Re: Fw: Re: Re[2]: No more ExitException? <- documentation bug

On Thu, Jan 28, 2010 at 08:32:57AM +0100, Volker Wysk wrote: > > As you can see, it throws the ExitCode, not an ExitException. The > documentation is faulty. Thanks for the report; fixed. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-has

RE: Re[2]: Unicode source files

erent encodings, >> or just UTF-8. If we only want to support UTF-8, then we can keep >> the StringBuffer in UTF-8 and also FastStrings. (or you could >> re-encode the other encodings into UTF-8). > > srcParseErr contains call to "stepOnBy (-len)", and doing

Re: qualified re-export of Data.Set

On Mon, 2005-06-06 at 15:18 +0400, Serge D. Mechveliani wrote: > Dear GHC developers, > > Please, how to re-export (qualified) Data.Set, Data.Map ? [snip] > For ghc-6.4, I need qualified import of Data.Set, Data.Map > and need to re-export it. I am trying [snip] > I wond

Re: [Haskell] Re: lambda calculus theory

"Marc A. Ziegert" <[EMAIL PROTECTED]> writes: > > I'm searching for a good mathematical oriented introduction to the > > theory of lambda calculus or other theoretical foundations of Lisp/ > > Haskell, i.e. monads or such (of course in the web there are much > > hints, but what is the best fo

RE: Re[2]: Patch for Word64

On 24 November 2005 11:07, Bulat Ziganshin wrote: > Hello Matt, > > Thursday, November 24, 2005, 7:52:23 AM, you wrote: > int64ToWord64# = unsafeCoerce# word64ToInt64# = unsafeCoerce# > >> (W32# x#) + (W32# y#) = W32# (narrow32Word# (x# `plusWord#` y#)) >> (W64# x#) + (W6

Re: HEADS UP! Re: darcs switchover

Nobody shouted, so I propose we throw the final switch now. If you have uncommitted patches in CVS, just move them over to a darcs tree and continue from there. Just to be clear, this is what's happening: - the darcs repositories listed at http://hackage.haskell.org/trac/ghc/wiki/GhcD

Re: Re[2]: --make keep going?

On Friday 03 March 2006 15:10, Bulat Ziganshin wrote: > it will also be great to make syntax analysis of all source files > before compiling them. typical situation - after correcting program i > run --make, long wait while some modules will be compiled and only > after that ghc complains about som

Re: Re[2]: Replacement for GMP

Hi Bulat, don't forget about speed/memory efficiency of any programs that use Integer "just for case" but really most of their numbers fit in 32/64 bits. i have one particular program of this type - it builds list of all files on disk and Integers are used to save filesizes. i will be glad if, v

Re: Re[4]: Replacement for GMP

Hi Bulat, the same binary that also wants to use GMP. (Of course, we could *copy* GMP, changing all the function names. That would eliminate the problem!) isn't it rather easy task for some automated tool? i think that even existing tools may be found I know copyrights are weak compared t

RE: Re[2]: subtle inlining problem

| > The same thing should work in an instance decl, for the same | > reason, but I have not tried it recently. And, assuming it does | > work, it ought to be documented. If you check, and send me draft | > words, I'll add them to the user manual | | ok, but i don't undertsand what you mean by "i

Re: [Haskell-cafe] Re: #haskell works

Hello Simon, Thursday, December 20, 2007, 4:01:59 PM, you wrote: > Fixing it all properly means some fairly significant architectural changes, > and dropping the via-C backend oh, thank you. from my POV, C backend still may be used together with "non-registerized" compilers. in particular, i hop

Re: [Haskell-cafe] Re: #haskell works

On Thu, 2007-12-20 at 16:54 +0300, Bulat Ziganshin wrote: > Hello Simon, > > Thursday, December 20, 2007, 4:01:59 PM, you wrote: > > > Fixing it all properly means some fairly significant architectural changes, > > and dropping the via-C backend > > oh, thank you. from my POV, C backend still m

Re: [Haskell-cafe] Re: #haskell works

Bulat Ziganshin wrote: Hello Simon, Thursday, December 20, 2007, 4:01:59 PM, you wrote: Fixing it all properly means some fairly significant architectural changes, and dropping the via-C backend oh, thank you. from my POV, C backend still may be used together with "non-registerized" compiler

RE: [dongen@cs.ucc.ie: Re: Debugging techniques]

| This is really a big problem. I have been strugling with it | myself. The safest thing to do is to use `error' (sad but | true). That's the only thing I can recommend:-( This is a long-standing and embarassing bug which is alas not quick to fix. But have now been embarassed fo often that we (a

Re: [dongen@cs.ucc.ie: Re: Debugging techniques]

Simon Peyton Jones ([EMAIL PROTECTED]) wrote: : | This is really a big problem. I have been strugling with it : | myself. The safest thing to do is to use `error' (sad but : | true). That's the only thing I can recommend:-( : : This is a long-standing and embarassing bug which is : alas not quic

RE: Re : Extensible records in Haskell

ded otherwise. Simon | -Original Message- | From: Nicolas Oury [mailto:Nicolas.Oury@;ens-lyon.fr] | Sent: 06 November 2002 08:38 | To: [EMAIL PROTECTED] | Subject: Re : Extensible records in Haskell | | > > Hello, is there something like extensible records in ghc? | | >Are you w

Re: Re : Extensible records in Haskell

On Wed, 6 Nov 2002, Keean Schupke wrote: > Just a quick point, which I'm sure you realise, but static typing gives > you guarantees about the runnability of > a program that dynamic typing breaks... You can do almost anything you > would want to use dynamic types for > using a sufficently broad

Re: Re : Extensible records in Haskell

> Just a quick point, which I'm sure you realise, but static typing > gives you guarantees about the runnability of a program that dynamic > typing breaks... Which, presumably, is why he wants T-Rex which gives strong typing and extensible records and comes from the same great source (MP Jones) t

Re: Re : Extensible records in Haskell

t is easy to understand, safe and avoid to rename with different names some fields that should have the same name. * ... I could try find other reasons tomorrow. Simon | -Original Message- | From: Nicolas Oury [mailto:Nicolas.Oury@;ens-lyon.fr] | Sent: 06 November 2002 08:38 | To: [EMAIL P

Re: Re : Extensible records in Haskell

On Wednesday 06 November 2002 10:48 pm, Nicolas Oury wrote: > I am going to try to persuade you: > > * first of all, it seems to be needed in order to make "first class > modules" (cf your paper) . And I think that a true module system would > be useful. But I may be wrong. > > * As far as I am co

Re: Re: Extensible records in Haskell

Thanks, have read the paper, however also saw the paper by Simon Peyton-Jones and Mark Jones on Lightweight Extensible Records for Haskell, which I think Simon refered to in an earlier post... would it not be better to have this instead? Regards, Keean Schupke. Alastair Reid wrote: Actu

Re: Re : Extensible records in Haskell

I just read your proposal for "lightweight extensible records for Haskell" and find it great. But I just wonder : why not keeping both records systems (Haskell 98 and extensible) with their own syntax, introducing for example [{..}] for extensible records for example. This would resolve perform

Re: Re : Extensible records in Haskell

Are you sure extensible records are needed, I used to really want them until I developed some idioms which seem to replace most needs for them. (1) Haskell Records just plain old haskell records can be used in an extensible fashion quite easily, just provide an alternate to the constructor which f

Re: re-opening a closed stdin?

In local.glasgow-haskell-users, you wrote: > Is there any way in GHC to reopen stdin if it has been closed? You can call 'System.Posix.IO.dup stdin' and save this value. However, I think you then need to explicitely read from this fd as it is not possible to reset what GHC thinks stdin is currentl

RE: re-opening a closed stdin?

> There's probably a really obvious answer to this, but I can't find it. > > Is there any way in GHC to reopen stdin if it has been closed? There's no way to do this at present, except in GHCi where you can revert CAFs to their unevaluated state. > You may wonder why I'd want this. Well I'm wri

Re: re-opening a closed stdin?

> You can call 'System.Posix.IO.dup stdin' and save this value. > However, I think you then need to explicitely read from this fd as > it is not possible to reset what GHC thinks stdin is currently to > this new fd (I'll dig into this and maybe we'll get a >setStdin :: Fd -> IO () > from this,

Re: re-opening a closed stdin?

Simon Marlow writes: > I've been thinking about duplicating/replacing Handles for a while. > Here's a possible interface: > > -- |Returns a duplicate of the original handle, with its own buffer > -- and file pointer. The original handle's buffer is flushed, > including > -- discarding any

Re: re-opening a closed stdin?

ever, this may affect the semantics of closing that descriptor (e.g. a TCP socket isn't "closed" at the TCP layer until *all* corresponding descriptors have been closed). Also, you can't (AFAICT) re-assign Haskell's stdin globally operation in the manner of ANSI C's freopen(

RE: re-opening a closed stdin?

> Simon Marlow writes: > > I've been thinking about duplicating/replacing Handles for a while. > > Here's a possible interface: > > > > -- |Returns a duplicate of the original handle, with its > own buffer > > -- and file pointer. The original handle's buffer is flushed, > > including > >

RE: re-opening a closed stdin?

we'll get a > >setStdin :: Fd -> IO () > > from this, IIRC somebody else was asking for this, too). > > How does this interact with Simon's proposal for hDuplicate? If you actually want to change what stdin/stdout/stderr refer to, or re-open one of these file d

Re: re-opening a closed stdin?

Bernard James POPE wrote: > [Dean wrote:] > Wouldn't you want the debugger to use stdin and stdout for its > interaction with the > > user, and run the object program with stdin and stdout handles of its own > > creation? (In that case your question seems moot.) I've always been very confused >

Re: re-opening a closed stdin?

On Wed, 20 Nov 2002, Volker Stolz wrote: (snip) > The other way involves opening /dev/stdin on hosts that support this > (with the same limitation as above), including that that's currently (snip) Sometimes /dev/tty will work too. -- Mark ___ Glasgow-h

Re: re-opening a closed stdin?

"Simon Marlow" <[EMAIL PROTECTED]> writes: > One reason, I think, is lazy I/O(*). It's to stop you accidentally [...] > (*) kill it! die! die! So you want main = readFile "/dev/zero" >> return () to terminate violantly rather than terminate peacefully? :) Seriously, I understand that the IO

RE: re-opening a closed stdin?

> "Simon Marlow" <[EMAIL PROTECTED]> writes: > > > One reason, I think, is lazy I/O(*). It's to stop you accidentally > > [...] > > > (*) kill it! die! die! > > So you want > main = readFile "/dev/zero" >> return () > to terminate violantly rather than terminate peacefully? :) > > Seriousl

Re: re-opening a closed stdin?

Simon Marlow: > [Lazy I/O] is nice, but it introduces too many problems. What > happens to any I/O errors encountered by the lazy I/O? They have to > be discarded, which means you can't effectively use lazy I/O for > robust applications anyway. Surely they are thrown as exceptions which can the

Re: re-opening a closed stdin?

On Mon, Nov 25, 2002 at 10:09:01AM -, Simon Marlow wrote: > It is nice, but it introduces too many problems. What happens to any > I/O errors encountered by the lazy I/O? They have to be discarded, > which means you can't effectively use lazy I/O for robust applications > anyway. *mumble*Exc

RE: re-opening a closed stdin?

> Simon Marlow: > > [Lazy I/O] is nice, but it introduces too many problems. What > > happens to any I/O errors encountered by the lazy I/O? They have to > > be discarded, which means you can't effectively use lazy I/O for > > robust applications anyway. > > Surely they are thrown as exceptions

Re: re-opening a closed stdin?

Simon Marlow wrote: > > Simon Marlow: > > > [Lazy I/O] is nice, but it introduces too many problems. What > > > happens to any I/O errors encountered by the lazy I/O? They have to > > > be discarded, which means you can't effectively use lazy I/O for > > > robust applications anyway. > > > > Sur

Re: re-opening a closed stdin?

On Mon, Nov 25, 2002 at 11:22:56AM -0500, Dean Herington wrote: > Is even the following example from the library report (section 11.8.2) > problematic? > > import System > import Char( toUpper ) > > main = do > [f1,f2] <- getArgs > s <- readFile f1 > writeFile f2 (map t

RE: re-opening a closed stdin?

> Simon Marlow wrote: > > > > Simon Marlow: > > > > [Lazy I/O] is nice, but it introduces too many problems. What > > > > happens to any I/O errors encountered by the lazy I/O? > They have to > > > > be discarded, which means you can't effectively use lazy I/O for > > > > robust applications a

Re: re-opening a closed stdin?

"Simon Marlow" <[EMAIL PROTECTED]> writes: > It is nice, but it introduces too many problems. What happens to any > I/O errors encountered by the lazy I/O? They have to be discarded, > which means you can't effectively use lazy I/O for robust applications > anyway. Damn, I forgot that "file" me

RE: Unregistered build (was Re: AMD64)

On 02 June 2004 18:40, Bennett Todd wrote: > I too would be happy with an unregistered build. > > I've tried off and on to port ghc to my linux distro (uses static > linking against uClibc, glibc isn't present at all). Every time I go > through the process, I get stuck at the point where I seem t

Re: Unregistered build (was Re: AMD64)

2004-06-14T16:06:05 Simon Marlow: > You probably don't want to install the registerised build; just use it > to build a fresh tree: > > $ ./configure > --with-ghc=/unregisterised-build/ghc/compiler/ghc-inplace > $ make Thanks, I'll give it another go. It'll be a few days before I can get back

Re: Unregistered build (was Re: AMD64)

Well I just tried it and that's what happened: ==fptools== make boot - --no-print-directory -r; in ghc-6.2.1/ghc/utils/ghc-pkg ghc-test/usr/bin/ghc -M -o

Re: Unregistered build (was Re: AMD64)

This was causing the error: version = tail "\ \ GHC_PKG_VERSION" However, when i moved it all in one line it worked and i got as far as this but i think that's the end of the line for now: ==fptools== make boot -wr; in ghc

RE: Unregistered build (was Re: AMD64)

On 14 June 2004 21:57, Gerd M wrote: > Well I just tried it and that's what happened: > > ==fptools== make boot - --no-print-directory -r; > in ghc-6.2.1/ghc/utils/ghc-pkg > ---

Re: Unregistered build (was Re: AMD64)

2004-06-14T16:06:05 Simon Marlow: > You probably don't want to install the registerised build; just use it > to build a fresh tree: > > $ ./configure > --with-ghc=/unregisterised-build/ghc/compiler/ghc-inplace > $ make Everything was fine up to there, but "make" does nothing at all. I follow

RE: Unregistered build (was Re: AMD64)

On 15 June 2004 14:18, Bennett Todd wrote: > 2004-06-14T16:06:05 Simon Marlow: >> You probably don't want to install the registerised build; just use >> it to build a fresh tree: >> >> $ ./configure >> --with-ghc=/unregisterised-build/ghc/compiler/ghc-inplace >> $ make > > Everything was fi

Re: Unregistered build (was Re: AMD64)

2004-06-15T14:52:53 Simon Marlow: > On 15 June 2004 14:18, Bennett Todd wrote: > > ./distrib/hc-build ... > > ./configure --with-ghc=`pwd`/ghc/compiler/ghc-inplace > > make > > > > That last make didn't do anything. > > After hc-build, you should unpack a completely fresh GHC source tree, > somew

Re: Unregistered build (was Re: AMD64)

2004-06-15T14:52:53 Simon Marlow: > After hc-build, you should unpack a completely fresh GHC source tree, > somewhere else. Then 'cd' into this tree, and issue the configure/make > commands. Alas, no joy; again, "make" does nothing. These Makefiles are cleverer than I am, I can't quite figure ou

RE: Unregistered build (was Re: AMD64)

Simon Marlow wrote: After hc-build, you should unpack a completely fresh GHC source tree, somewhere else. Then 'cd' into this tree, and issue the configure/make commands. I tried this and got as far as: ==fptools== make all -

RE: Unregistered build (was Re: AMD64)

On 16 June 2004 11:00, Gerd M wrote: > Simon Marlow wrote: >> After hc-build, you should unpack a completely fresh GHC source tree, >> somewhere else. Then 'cd' into this tree, and issue the >> configure/make commands. > > I tried this and got as far as: > ---

RE: Unregistered build (was Re: AMD64)

On 15 June 2004 16:24, Bennett Todd wrote: > 2004-06-15T14:52:53 Simon Marlow: >> After hc-build, you should unpack a completely fresh GHC source tree, >> somewhere else. Then 'cd' into this tree, and issue the >> configure/make commands. > > Alas, no joy; again, "make" does nothing. > > These

RE: Unregistered build (was Re: AMD64)

Simon Marlow wrote: It looks like HC bootstrapping is enabled in this tree; it shouldn't be. Just use a completely fresh source tree, don't configure with --enable-hc-boot, and don't unpack any HC files into it. If I use a fresh source tree without HCs then I need the unregistered build to compile

Re: Unregistered build (was Re: AMD64)

2004-06-16T10:33:49 Simon Marlow: > On 15 June 2004 16:24, Bennett Todd wrote: > > 2004-06-15T14:52:53 Simon Marlow: > >> After hc-build, you should unpack a completely fresh GHC source tree, > >> somewhere else. Then 'cd' into this tree, and issue the > >> configure/make commands. > > > > Alas,

RE: Unregistered build (was Re: AMD64)

On 16 June 2004 13:19, Gerd M wrote: > Simon Marlow wrote: >> It looks like HC bootstrapping is enabled in this tree; it shouldn't >> be. Just use a completely fresh source tree, don't configure with >> --enable-hc-boot, and don't unpack any HC files into it. >> > If I use a fresh source tree wit

Re: Unregistered build (was Re: AMD64)

2004-06-16T13:26:45 Simon Marlow: > Bennett, who said he had a working unregisterised build. I'm by no means a Haskell expert, or even a Haskell programmer; but my unregistered build does do hello.hs successfully. -Bennett pgp9V3uOTefQY.pgp Description: PGP signature ___

RE: Unregistered build (was Re: AMD64)

On 16 June 2004 13:50, Bennett Todd wrote: > 2004-06-16T10:33:49 Simon Marlow: >> On 15 June 2004 16:24, Bennett Todd wrote: >>> 2004-06-15T14:52:53 Simon Marlow: After hc-build, you should unpack a completely fresh GHC source tree, somewhere else. Then 'cd' into this tree, and issue th

RE: Unregistered build (was Re: AMD64)

I managed to create an unregistered build that compiles the hello world example. # file hello hello: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped But when I tried to build a registered compiler with it (by using

RE: Unregistered build (was Re: AMD64)

On 17 June 2004 10:59, Gerd M wrote: > I managed to create an unregistered build that compiles the hello > world example. > # file hello > hello: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for > GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped Great! > /tmp/ghc7

Re: Unregistered build (was Re: AMD64)

2004-06-17T09:04:40 Simon Marlow: > Hmmm. Try these please: > > make show VALUE=ProjectsToBuild > make show VALUE=ProjectsThatExist > make show VALUE=SUBDIRS bash-2.05b$ make show VALUE=ProjectsToBuild ProjectsToBuild="" bash-2.05b$ make show VALUE=ProjectsThatExist ProjectsThatExist="

RE: Unregistered build (was Re: AMD64)

Simon Marlow wrote: This one looks like a failure from GCC, not GHC. If possible, you should send a bug report to the GCC folks or Gentoo as requested. You could try using a different version of GCC to work around the problem. Unfortunately I've only got one gcc version installed at the moment and

Re: Unregistered build (was Re: AMD64)

On Thursday 17 June 2004 15:01, Gerd M wrote: > Unfortunately I've only got one gcc version installed at the moment and I'm > not sure if installing another version won't break something... Maybe I > will give it another try later this week, thanks for your help so far! > Regards > Gerd Since I'm

RE: Unregistered build (was Re: AMD64)

On 17 June 2004 14:08, Peter Robinson wrote: > > ==fptools== make all -wr; > in /home/thaldyron/var/ghcbuild/ghc-6.2.20040613/libraries/base > > rm -f

Re: Unregistered build (was Re: AMD64)

Well the build finally succeeded but unfortunately I immediately get a segfault when running ghc/ghci. I've attached the output of # strace -o log ./ghc Cheers Peter On Thursday 17 June 2004 15:25, Simon Marlow wrote: > On 17 June 2004 14:08, Peter Robinson wrote: > > >

RE: Unregistered build (was Re: AMD64)

On 17 June 2004 16:29, Peter Robinson wrote: > Well the build finally succeeded but unfortunately I immediately get a > segfault when running ghc/ghci. > I've attached the output of > # strace -o log ./ghc It looks like registerised compilation on x86_64 isn't quite working yet, then. If you're

Re: Unregistered build (was Re: AMD64)

On Thursday 17 June 2004 17:38, Simon Marlow wrote: > It looks like registerised compilation on x86_64 isn't quite working > yet, then. If you're up to debugging this, then I suggest you start > from a simpler program - try hello world registerised, and then slightly > larger programs if that work

Re: Unregistered build (was Re: AMD64)

listener: > On Thursday 17 June 2004 17:38, Simon Marlow wrote: > > It looks like registerised compilation on x86_64 isn't quite working > > yet, then. If you're up to debugging this, then I suggest you start > > from a simpler program - try hello world registerised, and then slightly > > larger p

RE: Unregistered build (was Re: AMD64)

On 17 June 2004 13:09, Bennett Todd wrote: > 2004-06-17T09:04:40 Simon Marlow: >> Hmmm. Try these please: >> >> make show VALUE=ProjectsToBuild >> make show VALUE=ProjectsThatExist >> make show VALUE=SUBDIRS > > bash-2.05b$ make show VALUE=ProjectsToBuild > ProjectsToBuild="" > bash-2.0

RE: Unregistered build (was Re: AMD64)

On 17 June 2004 17:30, Peter Robinson wrote: > On Thursday 17 June 2004 17:38, Simon Marlow wrote: >> It looks like registerised compilation on x86_64 isn't quite working >> yet, then. If you're up to debugging this, then I suggest you start >> from a simpler program - try hello world registerise

  1   2   3   4   5   6   7   8   9   10   >