RE: Missing Folder in ghc?
Yes, I think it was my fault. Incidentally, mail about *building* ghc should go to [EMAIL PROTECTED] Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Wolfgang Thaller | Sent: 03 March 2006 00:40 | To: Ashley Yakeley | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Missing Folder in ghc? | | On 2-Mar-06, at 7:35 PM, Ashley Yakeley wrote: | | Thanks. Now the build process gets stuck here: | | I ran into this yesterday, but didn't have time to look into it; | today, ./darcs-all pull seems to have fixed it. | | Cheers, | | Wolfgang | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
building ghc-6.4.1 with gcc-4.1.0 on x86_64
Hi, I'm having problems building ghc-6.4.1 with gcc-4.1.0 on x86_64 (amd64). It builds fine with gcc-4.1 on 32bit ix86. gcc-4.1.0 is the default compiler in Fedora Core 5, which will be released soon. Below is part of the buildlog where it is failing during stage2 linking. Jens ../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.1 -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -H16M '-#include hschooks.h'-no-link-chk stage2/basicTypes/BasicTypes.o stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o stage2/basicTypes/FieldLabel.o stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o stage2/basicTypes/Module.o stage2/basicTypes/Name.o stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmParse.o stage2/cmm/CmmUtils.o stage2/cmm/MachOp.o stage2/cmm/PprC.o stage2/cmm/PprCmm.o stage2/codeGen/Bitmap.o stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o stage2/codeGen/CgExpr.o stage2/codeGen/CgForeignCall.o stage2/codeGen/CgHeapery.o stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o stage2/codeGen/SMRep.o stage2/compMan/CompManager.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o stage2/deSugar/Desugar.o stage2/deSugar/DsArrows.o stage2/deSugar/DsBinds.o stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o stage2/hsSyn/Convert.o stage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o stage2/iface/BuildTyCl.o stage2/iface/IfaceEnv.o stage2/iface/IfaceSyn.o stage2/iface/IfaceType.o stage2/iface/LoadIface.o stage2/iface/MkIface.o stage2/iface/TcIface.o stage2/main/CmdLineOpts.o stage2/main/CodeOutput.o stage2/main/Config.o stage2/main/Constants.o stage2/main/DriverFlags.o stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o stage2/main/DriverPipeline.o stage2/main/DriverState.o stage2/main/DriverUtil.o stage2/main/ErrUtils.o stage2/main/Finder.o stage2/main/GetImports.o stage2/main/HscMain.o stage2/main/HscStats.o stage2/main/HscTypes.o stage2/main/Main.o stage2/main/PackageConfig.o stage2/main/Packages.o stage2/main/ParsePkgConf.o stage2/main/SysTools.o stage2/main/TidyPgm.o stage2/nativeGen/AsmCodeGen.o stage2/nativeGen/MachCodeGen.o stage2/nativeGen/MachInstrs.o stage2/nativeGen/MachRegs.o stage2/nativeGen/NCGMonad.o stage2/nativeGen/PositionIndependentCode.o stage2/nativeGen/PprMach.o stage2/nativeGen/RegAllocInfo.o stage2/nativeGen/RegisterAlloc.o stage2/ndpFlatten/FlattenInfo.o stage2/ndpFlatten/FlattenMonad.o stage2/ndpFlatten/Flattening.o stage2/ndpFlatten/NDPCoreUtils.o stage2/ndpFlatten/PArrAnal.o stage2/parser/Ctype.o stage2/parser/LexCore.o stage2/parser/Lexer.o stage2/parser/Parser.o
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Cyril, - How to generate an import library at all? Section 11.5.1 of the ghc manual says that the --mk-dll option will cause ghc to create such a library, but ghc 6.4.1 does not do this, at least not on Windows. Or did you use the Microsoft lib.exe? (lib.exe /def Foo.def generates an import library from the DLL but I have no idea how use it. After all, lib.exe does not have any type information on the symbols exported by the DLL, so how is this is supposed to work?) - Assuming I have obtained an import library, how to use in the Microsoft world, i.e. how to bridge the gap from .a to .lib? - Is Visual Studio 7 able to process the header files included from the stub header files generated by ghc? Visual Studio 6 has a lot of problems, e.g. it knows nothing about the type long long. - Didn't you have problems with mangled names? - What is the principal difference between using the import library and writing one on my own? Does the import library do anything else than loading the library and delegating the calls? It would be great if you could give me a recipe (in terms of a shell-command sequence) that demonstrates how you achieved your goal! Michael BTW. If I learn anything from this thread that is not yet contained in the Haskell Wiki page pointed to by Simon, I will add it. Cyril Schmidt wrote: Did you try to link the DLL statically (i.e. via import library) and remove the call to shutdownHaskell() ? It worked for me (I am using Visual Studio 7, though). Cheers, Cyril ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Now -split-objs work with --make
This means that ghc 6.6 starting from current build can optimize EXE sizes by throwing away all unused functions This is a forwarded message ===8==Original message text=== Date: Thu, 2 Mar 2006 09:07:34 -0800 From: Simon Marlow [EMAIL PROTECTED] Subject: patch applied (ghc): Make -split-objs work with --make To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Thu Mar 2 09:05:05 PST 2006 Simon Marlow [EMAIL PROTECTED] * Make -split-objs work with --make This turned out to be a lot easier than I thought. Just moving a few bits of -split-objs support from the build system into the compiler was enough. The only thing that Cabal needs to do in order to support -split-objs now is to pass the names of the split objects rather than the monolithic ones to 'ar'. M ./ghc/compiler/Makefile +2 M ./ghc/compiler/main/DriverPhases.hs +1 M ./ghc/compiler/main/DriverPipeline.hs -19 +50 M ./mk/target.mk -28 ===8===End of original message text=== -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael, - How to generate an import library at all? Check this out: http://www.haskell.org/haskellwiki/GHC/FAQ#How_do_I_link_Haskell_with_C.2B.2B_code_compiled_by_Visual_Studio.3F - Assuming I have obtained an import library, how to use in the Microsoft world, i.e. how to bridge the gap from .a to .lib? See above. - Is Visual Studio 7 able to process the header files included from the stub header files generated by ghc? Visual Studio 6 has a lot of problems, e.g. it knows nothing about the type long long. I could not make Visual Studio 7 understand those, but I didn't try really hard. - Didn't you have problems with mangled names? Haskell would not understand mangled names. You have to declare the Haskell functions as extern C in the C++ code. This, of course, does not count for functions that are passed to/from Haskell via a function pointer. - What is the principal difference between using the import library and writing one on my own? Does the import library do anything else than loading the library and delegating the calls? I don't know :( Just one more piece of advice: if you can compile your C++ code with gcc, you probably can link it statically to the Haskell code, thus avoiding this DLL nightmare. Hope this helps. Cheers Cyril ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
The memory allocated by the runtime system is never freed.
I've submitted a fix fir this.
-- Lennart
Michael Marte wrote:
Hello *,
before filing a bug report, I want others to comment on my problem.
Maybe it's my fault, not ghc's.
I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However,
whether I actually use the library or not, the program (an application
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading
the DLL using FreeLibrary. FreeLibrary works fine, however the program
crashes when it returns to the main event loop. Interestingly, when I
reload the library (FreeLibrary followed by LoadLibrary) the program
continues working. However, every reload cycle causes the virtual size
of the process to increase by about 300K and the fourth reload fails
with the error message getMBlock: VirtualAlloc failed with: 8 (appears
in a message window) accompanied by many repetitions of the message
Timer proc: wait failed -- error code: 6 (appears on stderr) and
followed by the message getMBlocks: misaligned block returned (again
in a message window). Then the programm crashes.
Development takes place on Windows XP Professional using MS Visual
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side
to the Haskell heap. I build the DLL using the command
ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o
dllMain.c
dllMain.c looks as follows:
#include windows.h
#include Rts.h
extern void __stginit_EUzu3820zu85(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need
to start it up. */
startupHaskell(1, args, __stginit_Foo);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
}
return TRUE;
}
I played around with hs_exit instead of shutdownHaskell, I moved
initialization and clean-up from DllMain to my library loader, nothing
helps. Even doing no clean-up whatsoever does not change the behaviour.
Any ideas?
Michael
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-( Michael Lennart Augustsson wrote: The memory allocated by the runtime system is never freed. I've submitted a fix fir this. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: --make keep going?
John Meacham wrote: is there an option to get ghc to keep going if it encounters an error building a file with --make? as in, I'd like it to continue compiling as much as it can only skipping what actually depends on the file that failed rather than completly aborting everything. Certainly possible, and the -k flag is free, too :-) Care to submit a feature req? Cheers, SImon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Now -split-objs work with --make
Bulat Ziganshin wrote: This means that ghc 6.6 starting from current build can optimize EXE sizes by throwing away all unused functions well, not exactly, although that would be a useful enhancement. Currently it only helps when building libraries. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Cyril, I know the Haskell Wiki page you pointed to; it does not answer my specific questions. The decision which compiler to use is not up to me and, as the Wiki page points out, there is no other way to use Haskell modules from within a Visual Studio C++ compiled application than via a DLL: The Windows distribution of GHC comes bundled with the GCC compiler, which is used as backend. That's why linking Haskell with Visual C++ is no different from linking GCC-generated code with the code generated by Visual C++. One cannot statically link together object files produced by those two compilers, but they can be linked dynamically: an executable produced by Visual C++ can invoke a DLL produced by GCC, and vice versa. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: --make keep going?
Hello Simon, Friday, March 3, 2006, 4:51:04 PM, you wrote: is there an option to get ghc to keep going if it encounters an error building a file with --make? as in, I'd like it to continue compiling as much as it can only skipping what actually depends on the file that failed rather than completly aborting everything. SM Certainly possible, and the -k flag is free, too :-) Care to submit a SM feature req? 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 some error. it's not yet feature req, just some thoughts about ideal compilation cycle: first syntax check all modules and print errors, then perform type analysis and report errors, then compile correct modules. what other haskellers think about this? another problem is what ghc tries to print entire block when it encounters error. but this block can contain hundreds of lines! moreover, error message and line number printed at the beginning, so on 25-line terminal it's just impossible to know anything about bug! it will be great to print maximum one line, i think -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael, Sorry, I might have had wrong assumptions about what you want to do. I presume you have a C++ application compiled via Visual Studio 6 that invokes a Haskell DLL. If that's correct, read on; if not, please tell me again what your setting is. To link your Haskell DLL with the C++ application: 1. Create a .def file for your DLL. Say, your Haskell library is HaskellLib.dll, so your .def file will be HaskelLib.def. Suppose the Haskell finction that you want to call from C++ is myHaskellFunc, then the .def file might look like LIBRARY HASKELLLIB EXPORTS myHaskellFunc 2. Create an import library using Visual Studio's lib.exe: lib /DEF:HaskellLib.def /OUT:HaskellLib.lib 3. Add HaskellLib.lib to your Visual Studio project and link. Cheers, Cyril Cyril, I know the Haskell Wiki page you pointed to; it does not answer my specific questions. The decision which compiler to use is not up to me and, as the Wiki page points out, there is no other way to use Haskell modules from within a Visual Studio C++ compiled application than via a DLL: The Windows distribution of GHC comes bundled with the GCC compiler, which is used as backend. That's why linking Haskell with Visual C++ is no different from linking GCC-generated code with the code generated by Visual C++. One cannot statically link together object files produced by those two compilers, but they can be linked dynamically: an executable produced by Visual C++ can invoke a DLL produced by GCC, and vice versa. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 some error. it's not yet feature req, just some thoughts about ideal compilation cycle: first syntax check all modules and print errors, then perform type analysis and report errors, then compile correct modules. what other haskellers think about this? Sounds nice. But is it possible? I have no idea. another problem is what ghc tries to print entire block when it encounters error. but this block can contain hundreds of lines! moreover, error message and line number printed at the beginning, so on 25-line terminal it's just impossible to know anything about bug! it will be great to print maximum one line, i think 25-line terminal and no scroll bar, how poor. I thought that everybody nowadays has access to screens with graphical resolutions, not? Anyway, this would be an nice option, but it should not be the default. What about compiler switch --terse? Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Allocating aligned memory?
In GHC, how can I allocate a chunk of memory aligned to some block size (say, 512 or 1024 bytes)? I tried to specify it in the alignment method in the Storable typeclass, but that does not seem to work. Is Storable.alignment really used in GHC? If so, is there a code example that allocates aligned memory in this way? For the moment I am using the C function memalign() like this: foreign import ccall static stdlib.h memalign :: CInt - CInt - IO (Ptr CChar) do ptr - memalign alignment size fptr - newForeignPtr finalizerFree ptr Is it safe to do so? Thanks, Peng ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Using GHC with SMP and FFI?
[1] Extending the Haskell Foreign Function Interface with Concurrency [2] Haskell on a Shared-Memory Multiprocessor I read the above two papers [1,2] and I have been trying to write an application that uses both FFI and SMP. The first paper [1] shows how FFI is implemented on uniprocessor concurrent Haskell; the second paper [2] shows how SMP Concurrent Haskell is implemented. However, I found little documentation on using FFI with the latest SMP extension. In addition to [1], what has been changed and what should a programmer know if he wants to use FFI in a multithreaded program running on SMP machines? Best, Peng ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Memory leak in Fudgets
I wrote a very simple Fudgets program (just copies stdin to stdout, no graphics involved) leaktest.hs -- module Main where import Graphics.UI.Fudgets.Fudgets main = fudlogue (stdoutF == stdinF) and ran it like this: yes | leaktest I found out that the program grows in memory. Its traditional analog: leaktest2.hs - module Main where import System.IO main = do hGetLine stdin = hPutStrLn stdout main works in constant space. I tried to observe the GC realtime stats with +RTS -Sstderr -M600K It turns out, garbage is collected, number of allocated and collected bytes are mostly constant, and number of live bytes fluctuates, but averagely stays the same: AllocCollectLiveGCGC TOT TOT Page Flts bytes bytes bytes user elapuserelap 316720262144 9528 0.00 0.000.020.02 144 499 (Gen: 0) 262128262144 22188 0.01 0.010.030.0403 (Gen: 0) 262128262144 8276 0.00 0.000.040.0500 (Gen: 0) 262128262144 24612 0.01 0.010.050.0600 (Gen: 0) 262128262144 10680 0.00 0.000.060.0700 (Gen: 0) 262128262144 23376 0.00 0.000.060.0800 (Gen: 0) 262128262144 9444 0.00 0.000.070.0900 (Gen: 0) 262012262144 25492 0.00 0.000.070.1000 (Gen: 0) ... program grows to 10M . 262128262144 1684 0.01 0.01 42.33 66.1000 (Gen: 0) 262128262144 13396 0.01 0.01 42.34 66.1100 (Gen: 0) 262124262144 25540 0.01 0.01 42.35 66.1200 (Gen: 0) 262128262144 11988 0.00 0.00 42.35 66.1300 (Gen: 0) 262128262144 1760 0.00 0.00 42.36 66.1400 (Gen: 0) 262128262144 14464 0.00 0.00 42.37 66.1500 (Gen: 0) 262128262144 1656 0.00 0.00 42.37 66.1600 (Gen: 0) and was interrupted ... 1,614,769,480 bytes allocated in the heap 78,801,952 bytes copied during GC 25,624 bytes maximum residency (6160 sample(s)) 6160 collections in generation 0 ( 10.35s) 1 Mb total memory in use INIT time0.01s ( 0.00s elapsed) MUT time 32.01s ( 55.38s elapsed) GCtime 10.35s ( 10.78s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 42.37s ( 66.16s elapsed) %GC time 24.4% (16.3% elapsed) Alloc rate50,430,027 bytes per MUT second Productivity 75.5% of total user, 48.4% of total elapsed So, what could be the reason of such memory leak? What else may grow if the heap remains constant? How can it be observed? Any ideas are welcome. -- Dimitry Golubovsky Anywhere on the Web ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
