April 2005 - Glasgow-haskell-users

Broken pipe ghci
by Robert van Herk 27 Apr '05

27 Apr '05

Hi all, I have written an application, that for some reason I don't yet understand, crashes. However, when I run the application in ghci, at the moment it crashes ghci crashes along with it. No error messages are given. Both my application and ghci just stop. When I compile it, and run it as a stand-alone application, when it crashes it just stops as well. Again, no error messages are given. What could be wrong? Regards, Robert

3 4

[ ghc-Feature Requests-1189559 ] incomplete patterns and GADT
by SourceForge.net 25 Apr '05

25 Apr '05

Feature Requests item #1189559, was opened at 2005-04-25 08:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1189559&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete patterns and GADT Initial Comment: I would like to compile with -fwarn-incomplete-patterns and use GADTs, but I have bogus error messages. Suppose I define : data T a where C1 :: T Char C2 :: T Float then a function : exhaustive :: T Char -> Char exhaustive C1 = ' ' If I compile with incomplete pattern warnings, I get that my function "exhaustive" is not exhaustive. But if I add a case : exhaust C2 = ' ' then the compiler accurately warns me that this case is inaccessible. Would it be possible to add the accessibility check when compiling with incomplete patterns detection ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1189559&group_…

1 0

H/Direct build on Windows
by Paul Moore 24 Apr '05

24 Apr '05

Hi, I recently posted a message to the Haskell FFI list (title "H/Direct build on Windows (with mingw, by preference...)") asking about problems I have building H/Direct with GHC. I haven't had a reply there yet, and although I'm happy to wait until someone has the time, I was a little unsure as to the best list to use. Hence this message - if there's anyone on this list who might be able to help, who isn't already subscribed to the FFI list, I'd appreciate any suggestions. Thanks in advance, Paul. -- SCSI is not magic. There are fundamental technical reasons why it is necessary to sacrifice a young goat to your SCSI chain now and then. -- John Woods

1 0

Linking shared libraries
by Benjamin Franksen 24 Apr '05

24 Apr '05

I know that ghc cannot produce shared libraries on all systems, but what about just linking existing ones (i.e. for ffi code)? Is there a secret command line switch for that, or do I have to use the C linker? Is there an option in cabal that I have been missing that could help me? Cheers Ben

2 1

RE: Re[4]: garbage collection
by Simon Marlow 23 Apr '05

23 Apr '05

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 will be enough Megablocks have to be allocated on a 1Mb boundary because of the way we map addresses to block descriptors: see Bdescr(). Cheers, Simon

1 0

RE: Re[4]: garbage collection
by Simon Marlow 23 Apr '05

23 Apr '05

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, as i understand you? Neither, it just means someone has to write some code :-) >>> i don't see resons why this can be slower. we will be a "good >>> citizens" - return memory what is not used at current moment and >>> reallocate memory when needed. > >> It might be slower because it involves extra calls to the kernel to >> free/allocate memory, and the kernel has to update its page tables. > > it is very fast, at least in my win xp (120 thousands of 1-mbyte > blocks are unmapped/mapped in one second! That doesn't sound too fast to me... > so, the best solution, i think, will be current one + madvise for > systems that supports it + one small but major change: current code > switches to compacting when more than 30% of > RtsFlags.GcFlags.maxHeapSize is used. it must calculate 30% of > PHYSICAL memory while maxHeapSize is developed to limit VIRTUAL memory > usage I don't understand that comment... there's no difference between physical and virtual memory outside the kernel. Cheers, Simon

1 0

RE: Edison Libraries in ghc 6.4
by Simon Marlow 23 Apr '05

23 Apr '05

On 22 April 2005 05:57, ajb(a)spamcop.net wrote: > G'day all. > > On 20 April 2005 01:46, ajb(a)spamcop.net wrote: >>> Would it help if I cabalised it? > > Quoting Simon Marlow <simonmar(a)microsoft.com>: >> Sure! > > Which raises the question: How? > > I understand that Ross had a smallish tutorial. Anyone know where I > can find it? There's Cabal documentation available on GHC's site: http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html Cheers, Simon

1 0

RE: installing ghc without already having ghc
by Simon Marlow 22 Apr '05

22 Apr '05

On 20 April 2005 15:13, Jessica Brennan wrote: > ghc-6.4-host/libraries/readline > NetBSD-2.0 0 # gmake boot > > ------------------------------------------------------------------------ > ==fptools== gmake boot -r; > in /devel/build/NetBSD/ghc/ghc-6.4-host/libraries/readline > ------------------------------------------------------------------------ > > ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I. > System/Console/Readline.hsc > Readline.hsc: In function `main': > Readline.hsc:677: error: `UNDO_DELETE' undeclared (first use in this > function) > Readline.hsc:677: error: (Each undeclared identifier is reported only > once Readline.hsc:677: error: for each function it appears in.) > Readline.hsc:678: error: `UNDO_INSERT' undeclared (first use in this > function) > Readline.hsc:679: error: `UNDO_BEGIN' undeclared (first use in this > function) > Readline.hsc:680: error: `UNDO_END' undeclared (first use in this > function) > Readline.hsc:1021: error: `MULT_MATCH' undeclared (first use in this > function) > Readline.hsc:1044: error: `SINGLE_MATCH' undeclared (first use in this > function) > gmake: *** [System/Console/Readline.hs] Error 1 > > I have tried this with readline-5.0 both shared and static versions > though I prefer to use the static version. Can anyone with NetBSD help out here? Cheers, Simon

3 2

RE: Re[2]: garbage collection
by Simon Marlow 22 Apr '05

22 Apr '05

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 the peak of a residency spike. > >> You probably only want to disable major collections though: it's safe >> for minor collections to happen. > > no, in that particular case i have very simple and fast algorithm, > which allocates plenty of memory. minor GC's in such situation is just > waste of time. so i want to do: > > disableGC > result <- eatMemory > enableGC > > with a effect that all memory allocated in 'eatMemory' procedure will > be garbage collected only after return from this procedure. currently > i have this stats: > > INIT time 0.01s ( 0.00s elapsed) > MUT time 0.57s ( 0.60s elapsed) > GC time 1.41s ( 1.41s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 1.99s ( 2.01s elapsed) > > %GC time 70.8% (70.1% elapsed) > > Alloc rate 171,249,142 bytes per MUT second > > Productivity 28.7% of total user, 28.4% of total elapsed > > as you see, it is very inefficient 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. >> I guess you're proposing using madvise(M_FREE) (or whatever the >> equivalent is on your favourite OS). This would certainly be a good >> idea if the program is swapping, but might impose an overhead when >> running in memory. I don't know, I haven't tried. > > i don't see resons why this can be slower. we will be a "good > citizens" - return memory what is not used at current moment and > reallocate memory when needed. It might be slower because it involves extra calls to the kernel to free/allocate memory, and the kernel has to update its page tables. 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, without actually swapping them to disk. When the memory is faulted in again, it gets filled with zeros. This is ideal for copying GC: you madvise() the semispace you just copied from, because it contains junk. IIRC, madvise() is a BSD-ish interface, but other OSs probably have similar facilities. We could also consider really returning memory to the OS. This requires more work in the runtime, though. > current implementation only allows memory usage to > grow and that is not perfect too. imho it will be better to release > unneeded memory after major GC and perform next major GC after > allocating fixed amount of memory or, say, after doubling used memory > area GHC has quite a sophisticated block-based storage manager. It's not obvious how to understand your comments in the context of GHC - I suggest you take a look at the source code. Cheers, Simon

3 3

RE: big FFI bug in x86_64
by Simon Marlow 22 Apr '05

22 Apr '05

On 22 April 2005 01:20, John Meacham wrote: > ghc 6.4 x86_64 appears to be interpreting > foreign import "&foo" as importing the value of foo rather than the > address of foo. > > I wrote a test case that demonstrates this problem here > http://repetae.net/john/ghc-bug.tar.gz > > correct output: > > ;./foo > () > 0x080774f0 > 0x080774f4 > 0xdeadbeef > > incorrect output: > > ;./foo > () > 0x00000000deadbeef > 0xffffffffdeadbeef > zsh: segmentation fault (core dumped) ./foo It's actually a bug in the via-C code generator, but you're seeing it on x86_64 because of the lack of a native code generator on that platform. I think I've fixed it now, after testing I'll merge into the 6.4 branch. Cheers, Simon

1 0