Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
I am still using ghc 6.4.2 for creating my DLL and, as long as the DLL does not open a file, releasing the DLL works fine. I have not yet tried ghc 6.5. Michael SevenThunders wrote: 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. I was wondering if there has been any recent progress on this issue. I have a binary windows distribution of GHC 6.5. from May 02 2006. I created a Haskell DLL that is called from a C stub, which ultimately gets called from Matlab. I'm not sure if Matlab loads and unloads the DLL everytime it's called, but it definately crashes Matlab if one tries to unload the DLL from inside Matlab (using Matlab's clear command). The crash occurs even if no Haskell code is actually called from Matlab. It suffices to simply load the Haskell DLL and then unload it. If you do call the DLL it will work for the first few times and then eventually crash. Presumably there is some kind of memory leak as alluded to elsewhere in this thread. I'm looking for usable workarounds here. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Program slower with local definitions
Hello *, I noticed a five percent speed up by making local definitions global. This is the first version with local definitions: f = some expression based on mySet where mySet = foldl (flip Set.insert) Set.empty myList myList = some constant list Then I moved mySet and myList to the top level which gave me the speed up. Shouldn't both versions show the same behaviour with regard to run time? Doesn't the compiler lift mySet and myList to top level automatically? Are myList and mySet evaluated in every call to f when defined locally? I am using ghc 6.4.2 on Windows XP. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Any way to catch runtime errors in a DLL?
Simon Marlow wrote: Michael Marte wrote: if a runtime error occurs inside a DLL compiled by ghc (like irrefutable pattern match failed or exceptions caused by error), the application that called the DLL function dies. This is ok for development but unacceptable when it happens with a user sitting in front of the display. (It has not yet happened but it's only a question of time.) So my question is: Is there any way to catch and process runtime errors? I am looking for some way to map those errors to exceptions on the C++ side that can be caught if required. It would be ok to kill the Haskell runtime system and unload the DLL if necessary. The FFI doesn't provide any way to propagate exceptions from Haskell to the caller of a foreign export, because there's no standard way to do this. It is your responsibility to catch the exception in Haskell and return an appropriate error code to the caller. To raise a C++ exception, you would probably need another C++ wrapper around each foreign export, translating an error code into the C++ exception. I think my intial problem description should have mentioned that I already have an exception handler: catch (do let result = ... write result to file return 1) (\_ - return 0) However, this handler catches IO exceptions only! Following the advice from this thread I changed the handler as follows: Control.Exception.catch (do result - Control.Exception.evaluate (...) write result to file return 1) (\_ - return 0) This handler actually catches all exceptions. I found that it is important to use Control.Exception.catch, just catch does not work. I do not yet know whether I have to use evaluate. Next thing is to pass the exception messages to the C++ side and I think I know how to achieve this. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Any way to catch runtime errors in a DLL?
Hello *, if a runtime error occurs inside a DLL compiled by ghc (like irrefutable pattern match failed or exceptions caused by error), the application that called the DLL function dies. This is ok for development but unacceptable when it happens with a user sitting in front of the display. (It has not yet happened but it's only a question of time.) So my question is: Is there any way to catch and process runtime errors? I am looking for some way to map those errors to exceptions on the C++ side that can be caught if required. It would be ok to kill the Haskell runtime system and unload the DLL if necessary. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.Sequence?
Simon, I am sorry, I mixed things up. Everything works fine. To find the source for Data.Sequence, I looked up the CVS repository and, I guess, there I saw that Data.Queue is deprecated on the HEAD. My underlying assumption obviously was that CVS was replaced by Darcs before starting development for 6.5. Michael Simon Marlow wrote: Michael Marte wrote: I installed ghc-6-4-2.msi on Windows. The same behaviour is exposed by ghc 6.4.1 on Debian Linux. Not here! Can you tell me *exactly* how you encounter the problem? The deprecation took place on July 29th last year as is clearly visible from the CVS log, see below. You're looking at the HEAD, the 6.4 releases are taken from the ghc-6-4-branch. Our latest sources are in a darcs repository. Data.Sequence is in the CVS repository again, in HEAD only, not 6.4 branch and there is a file Sequence.hi in hslibs-imports/data in my installation. That Sequence module is part of Edison, in the (old) package data. Also, it is called Sequence, as opposed to Data.Sequence, which is in 6.5. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.Sequence?
Simon,
Simon Marlow wrote:
Ross Paterson wrote:
On Wed, May 31, 2006 at 12:20:02PM +0200, Michael Marte wrote:
when importing Data.Queue in 6.4.2, I am told that it is deprecated
and that I should use Data.Sequence instead. However, Data.Sequence
is not part of the base package - it is there but it is missing from
the package.conf file.
Data.Queue ought not to be deprecated in 6.4, as Data.Sequence won't
be available until the next major release.
Michael, there appears to be something strange about your GHC
installation. In 6.4.2, Data.Queue is not deprecated, and the
Data.Sequence library is not present at all.
I installed ghc-6-4-2.msi on Windows.
The same behaviour is exposed by ghc 6.4.1 on Debian Linux.
The deprecation took place on July 29th last year as is clearly visible
from the CVS log, see below.
Data.Sequence is in the CVS repository and there is a file Sequence.hi
in hslibs-imports/data in my installation.
Michael
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Data/Queue.hs
Revision 1.5: download - view: text, markup, annotated - select for diffs
Fri Jul 29 17:17:22 2005 UTC (10 months ago) by ross
Branches: MAIN
CVS tags: cmm-merge2, HEAD
Diff to previous 1.4: preferred, colored
Changes since revision 1.4: +4 -0 lines
document deprecation
-
-- |
-- Module : Data.Queue
-- Copyright : (c) The University of Glasgow 2002
-- License : BSD-style (see the file libraries/base/LICENSE)
--
-- Maintainer : [EMAIL PROTECTED]
-- Stability : experimental
-- Portability : portable
--
-- NOTE: This module is DEPRECATED.
-- The data structure in Data.Sequence is a faster queue and also
-- supports a wider variety of operations.
--
-- Queues with constant time operations, from
-- /Simple and efficient purely functional queues and deques/,
-- by Chris Okasaki, /JFP/ 5(4):583-592, October 1995.
--
-
module Data.Queue
{-# DEPRECATED Use Data.Sequence instead: it's faster and has more
operations #-}
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Data.Sequence?
Hello *, when importing Data.Queue in 6.4.2, I am told that it is deprecated and that I should use Data.Sequence instead. However, Data.Sequence is not part of the base package - it is there but it is missing from the package.conf file. Moreover, there is no documentation available apart from the source code itself. Regarding Data.Sequence itself: - I am missing a function for converting a sequence to a list directly; I have to create a view and convert it to a list. - Isn't the name too fuzzy? After all, a standard Haskell list is a sequence as well. Why not stay with Queue? Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: import prefers module in package over local module
Simon Marlow wrote: Deprecation warnings seem to be working fine: $ ghc -c Foo.hs -package text Foo.hs:2:0: Warning: Module `Pretty' is deprecated: This module has moved to Text.PrettyPrint.HughesPJ Also, the documentation for the text package clearly states in several places that the modules it contains are deprecated. I have got something wrong here: To use, say Text.Html or Text.PrettyPrint.HughesPJ, it is not necessary to use -package text on the command line? So module Pretty is in the package text and Text.Html is part of another package, maybe package base? So there is no need at all for the -package directive in my case? Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: import prefers module in package over local module
Simon Marlow wrote: Tomasz Zielonka wrote: On Wed, May 03, 2006 at 11:53:19AM +0100, Simon Marlow wrote: I'm afraid I don't understand: there's no Pretty module in the standard libraries, only Text.PrettyPrint. There is a Pretty module in the text package. It seems that Michael uses ghc -package text. Ok (text package is deprecated, of course). But still it seems to work for me: GHC 6.4.1 and later find the local Pretty before the text package one. Cheers, Simon In fact, I use -package text. But how come that this package is deprecated? There is a lot of stuff in it. Moreover, I never got a warning that it is deprecated. In contrast, I am being told that I should replace 'import Html' by 'import Text.Html', e.g. As to the fact, that you cannot reproduce my problem, two explanations come to mind: Either the Debian package does not really contain 6.4.1 or the problem arises from my specific combination of parameters, which I do not have at hand right now, unfortunately. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
import prefers module in package over local module
Hello *, I am migrating a project from ghc 6.2 to ghc 6.4. This project has a module called Pretty and that's where my problems start. When importing Pretty, ghc does not consider my local definition but the Pretty module from the standard library (which is an alias for Text.PrettyPrint.HughesPJ). Is this behaviour intended or is it a bug? Can I change it? If it is intended, can somebody explain the rationale to me? BTW, I am using -hidir and -odir and the latest Debian package containing ghc 6.4.1. Thank you, Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: import prefers module in package over local module
Simon, I checked the version of ghc I use: It's 6.4.1. Michael Simon Marlow wrote: Michael Marte wrote: I am migrating a project from ghc 6.2 to ghc 6.4. This project has a module called Pretty and that's where my problems start. When importing Pretty, ghc does not consider my local definition but the Pretty module from the standard library (which is an alias for Text.PrettyPrint.HughesPJ). Is this behaviour intended or is it a bug? Can I change it? If it is intended, can somebody explain the rationale to me? BTW, I am using -hidir and -odir and the latest Debian package containing ghc 6.4.1. Thank you, Michael This was the behaviour in 6.4, if I recall correctly, but it was fixed in 6.4.1. Are you definitely using 6.4.1? (you said 6.4 at the beginning of the message). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote:
Michael Marte wrote:
Now I get the following error:
GHC/PrimopWrappers.hs:565:20: Not in scope: `GHC.Prim.forkOn#'
I think this problem may be releated to the other changes I pulled.
You probably need to rebuild some stuff. If your stage 1 compiler is
up to date, then remove libraries/base/GHC/Base.{o,hi} and build in
libraries/base. That *should* be enough, but if not just 'make clean'
in libraries/base.
Cheers,
Simon
Finally, I succeeded to complete the build! (I had to rebuild from scratch.)
Thank you very much,
Michael
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote: Michael Marte wrote: Yes, I synced my working copy of ghc 6.5 yesterday with darcs pull. Are there any requirements as to which exact version of ghc 6.4 I am supposed to use? I am using the plain 6.4 release but I am able to build the head of the 6.4 branch. BTW. Am I supposed to run configure after syncing the working copy and/or clean the source tree before issueing the make command? The *safest* thing to do after pulling is to completely make clean, autoreconf, and build from scratch. You may be able to avoid being that drastic if you know what you're doing. There are quite a few dependencies in the GHC tree that aren't tracked explicitly, for practical reasons; for example, the build system doesn't know that when the .hi format changes you need to rebuild all your libraries. I suspect something is out of date in your case, but I'm not sure what.If you don't want to rebuild everything, you could try just rebuilding ghc/lib/compat, and then remove ghc/stage1/parser/Lexer.o, build stage 1, and then carry on with stage 2. Cheers, Simon I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote: Michael Marte wrote: I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Ok, could you try this: $ size ghc/lib/compat/cbits/unicode.o $ size ghc/lib/compat/Compat/Unicode.o there should be some code in those modules if the build system is working properly. Cheers, Simon Yes, there is code, i.e. the text segments are not empty. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote: Michael Marte wrote: Simon Marlow wrote: Michael Marte wrote: I did as you said (make clean; autoreconf; configure; make) but it didn't help; I get the same error as before. Ok, could you try this: $ size ghc/lib/compat/cbits/unicode.o $ size ghc/lib/compat/Compat/Unicode.o there should be some code in those modules if the build system is working properly. Cheers, Simon Yes, there is code, i.e. the text segments are not empty. I stared at the code some more, and I think I've found the problem and pushed a patch for it. You'll need to 'darcs pull', make in ghc/lib, rm ghc/compiler/stage1/parser/Lexer.o, make stage 1, and then make stage 2. Cheers, Simon Now I get the following error: GHC/PrimopWrappers.hs:565:20: Not in scope: `GHC.Prim.forkOn#' I think this problem may be releated to the other changes I pulled. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.2 release candidates
Simon Marlow wrote: Hi Folks, We're finally in release-candidate mode for 6.4.2. Please grab a snapshot and try it out: http://www.haskell.org/ghc/dist/stable/dist/ (scroll to the bottom for the latest). The available builds are: x86_64-unknown-linux (Fedora Core 5), i386-unknown-linux (glibc 2.3 era), and Windows (i386-unknown-mingw32). There's a source snapshot if you want to build yourself - please try this if you can, we need to make sure the source bundle builds cleanly. Barring any serious hiccups, the release should be out in a couple of weeks. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Works fine for me on Win32. All DLL problems are gone - no more space leaks and crashes when freeing a DLL generated by ghc! Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still problems building ghc 6.5 with ghc 6.4
Simon Marlow wrote: Michael Marte wrote: Hello *, when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as follows: make -C ghc/compiler stage=2 make[2]: Entering directory `/home/marte/fptools/ghc/compiler' ../../ghc/compiler/ghc-inplace -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/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -threaded -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' -ignore-package ghc -fgenerics -funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi stage2/parser/Lexer.hi parser/Lexer.x:578:10: lexical error in string/character literal at character '\955' ghc: 51822676 bytes, 5 GCs, 98216/98216 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.62 MUT (0.84 elapsed), 0.11 GC (0.13 elapsed) :ghc make[2]: *** [stage2/parser/Lexer.o] Error 1 make[2]: Leaving directory `/home/marte/fptools/ghc/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/marte/fptools' make: *** [bootstrap2] Error 2 Is this problem caused by alex? This is with a recently checked-out HEAD? I thought I fixed this problem. It isn't caused by Alex, the issue is that 6.4 didn't have the necessary Unicode functionality in its base package. The fix was to include it in the libcompat library when building GHC, but for some reason this appears not to be happening for you. Yes, I synced my working copy of ghc 6.5 yesterday with darcs pull. Are there any requirements as to which exact version of ghc 6.4 I am supposed to use? I am using the plain 6.4 release but I am able to build the head of the 6.4 branch. BTW. Am I supposed to run configure after syncing the working copy and/or clean the source tree before issueing the make command? Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Still problems building ghc 6.5 with ghc 6.4
Hello *, when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as follows: make -C ghc/compiler stage=2 make[2]: Entering directory `/home/marte/fptools/ghc/compiler' ../../ghc/compiler/ghc-inplace -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/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -threaded -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' -ignore-package ghc -fgenerics -funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi stage2/parser/Lexer.hi parser/Lexer.x:578:10: lexical error in string/character literal at character '\955' ghc: 51822676 bytes, 5 GCs, 98216/98216 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.62 MUT (0.84 elapsed), 0.11 GC (0.13 elapsed) :ghc make[2]: *** [stage2/parser/Lexer.o] Error 1 make[2]: Leaving directory `/home/marte/fptools/ghc/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/marte/fptools' make: *** [bootstrap2] Error 2 Is this problem caused by alex? Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 release plans
Simon Marlow wrote: Hi Folks, This is a heads up for the forthcoming 6.4.2 release. Our rough timescale is to go into release candidate testing in about a week, and have two weeks of release candidates before the final release. Here are the things we know about and plan to fix before the release: http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedmilestone=6.4.2order=priority If you have anything else for 6.4.2, please let me know. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users What about ticket #716 (Unloading a dll generated by GHC doesn't free all resources)? It's about the RTS not waiting for threads to terminate s.t. the application is very likely to crash when freeing the DLL. As the detour via a DLL is the only way to use Haskell in a C++ application, this bug is quite critical from my point of view. Lennart has proposed to stop the timer thread and provided a patch for this against 6.5. I would be glad to see this patch in 6.4.2 unless someone finds a way to terminate the threads in a controlled fashion. Michael ___ 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?
Simon Marlow wrote: Michael Marte wrote: Lennart Augustsson wrote: I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: 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 wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) The patch hasn't been committed at all, AFAIK. Ok, it am new to Darcs, so this patch is only a proposal contained in the ticket? I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) When compiling with 6.4.1 or later, u_gencat should come from libHSbase_cbits.a in your 6.4.1 installation. Is it there? No, I am compiling with plain 6.4 (a newer Debain package is not available) and it does not have u_gencat in this library. However I can compile the head of the 6.4 branch which in turn should be able to compile the head, shouldn't it? Michael ___ 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 Augustsson wrote: I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: 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 wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) Michael ___ 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, - 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
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: 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
GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
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
Building Win32 DLLs: Manual is not up-to-date
Hello *, I am trying to turn a prototype written in Haskell into something I can call from a Visual Studio C++ 6.0 program. (The prototype is so clean and fast that there is no point in recoding everything.) So I followed the instructions in section 11.5 of the ghc manual (Building and using Win32 DLLs) and ended up as follows: $ ghc -c dllMain.c dllMain.c:4: warning: type defaults to `int' in declaration of `EXTFUN' dllMain.c:4: warning: parameter names (without types) in function declaration dllMain.c:4: warning: data definition has no type or storage class dllMain.c: In function `DllMain': dllMain.c:18: error: `__stginit_Adder' undeclared (first use in this function) dllMain.c:18: error: (Each undeclared identifier is reported only once dllMain.c:18: error: for each function it appears in.) Section 8.2 proposes to add extern void __stginit_Adder(void) which actually works. So it seems that section 11.2 is not up-to-date! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problems with 6.x compilers
Simon, On Wed, 23 Nov 2005, Simon Marlow wrote: On 22 November 2005 17:18, Michael Marte wrote: I am having some annoying problems with the 6.x compilers: 6.4 and 6.4.1: When repeating a build (with ghc --make) all modules are rebuild even if nothing has changed. With earlier compilers, only linking takes place in this setting. Can I change this behaviour? I cannot develop this way. Should not happen, if it does there is a bug. Can you tell us how to repeat the behaviour you're seeing? We aren't seeing any unecessary recompilation here. Like Wolfram Kahl, I am using -ddump-minimal-imports. I cannot check whether the use of this option causes the problem, because I returned to 6.2 already to continue porting my project from ghc 5. 6.2 and up: The object file is named after the module, not after the source file as in 5.04. As there are several main modules in my project, each in its own source file, all I get is a big mess. Any suggestions? The object file is named after the source file, unless you use -odir. The behaviour is clearly specified in the user's guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html#output-files the behaviour has been through several revisions before we arrived at this, and I'm not keen to change it. You can have several Main modules in the same directory if you don't use -odir. If you do use -odir, then you need to use a different value for -odir for each different program. Alternatively use -main-is, as Bulat suggested (actually this is better, IMO). I followed the suggestion of Bulat: I renamed the modules and used -main-is. Thanks everybody! Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problems with 6.x compilers
Hello, I am having some annoying problems with the 6.x compilers: 6.4 and 6.4.1: When repeating a build (with ghc --make) all modules are rebuild even if nothing has changed. With earlier compilers, only linking takes place in this setting. Can I change this behaviour? I cannot develop this way. 6.2 and up: The object file is named after the module, not after the source file as in 5.04. As there are several main modules in my project, each in its own source file, all I get is a big mess. Any suggestions? Thank you, Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-5.02.2 cannot parse string gaps
Hello *, Section 2.6. of the Haskell report says: A string may include a gap---two backslants enclosing white characters---which is ignored. This allows one to write long strings on more than one line by writing a backslant at the end of one line and at the start of the next. For example, Here is a backslant \\ as well as \137, \ \a numeric escape character, and \^X, a control character. ghc-5.02.2 cannot parse string gaps. It accepts \ at the end of a line but not at the beginning of the following line. Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
qforeign-0.65: Bzip2: decompress hangs if data ends prematurely
Hello *, I found that decompress hangs if data ends prematurely, i.e. do content - readFile fp doSomething (Bzip2.decompress content) does not terminate in this case. Data that is corrupt in some other way (for example, decompressing a file that has not been generated with bzip2) is detected and an exception is thrown. Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: qforeign-0.65: Bzip2: problems with [Word8]
On Tue, 16 Oct 2001, Ashley Yakeley wrote: At 2001-10-16 11:12, Michael Marte wrote: But I need String - String! (Reading from a file, decompressing, and feeding it to the XML parser.) How can I do this? The reading from a file part is arguably a misdesign in the standard libraries. There ought to be Word8-based file IO functions for reading/writing the bytes of a file. I'm not sure, but I think the Char-based functions may even do newline conversion. readFile :: FilePath - IO String works fine for me, also when reading binary files. But yes, maybe there should be a function returning IO Word8. Obviously, the implementation of readFile automatically converts from Word8 to Char and it is not only a type cast because Char has 16 bits. I found out that fromIntegral does the conversion from Word8 to Char but I do not know how to convert from Char to Word8. I think fromIntegral will work for that too. No, there is no suitable instance. However, it works like this: map (toEnum . fromEnum) . Bzip2.decompress . map (toEnum . fromEnum) Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problems with libgmp
Hello Simon, So, I can't quite work out what went wrong in your case. If the build didn't detect GMP 2, then it should have just used the one in the tree. Obviously, when linking, it did not use the one in the tree :-( Conclusion: The Linux linker does not behave like other linkers or there is a bug in some Makefile. BTW, you can't use GMP 3 with ghc-4.08.1 (the native code generator at least will break). Ok, I'll to try to get a snapshot from the CVS repository. Thanks, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problems with libgmp
Hello, I am maintaining the Haskell stuff at informatik.uni-muenchen.de. (I took over the job from Sven Panne.) As a first exercise, I try to compile ghc-4.08.1 from scratch. But I always run into trouble with the libgmp stuff. IMHO, my problems are caused by several factors: 1. We use Suse Linux 7.0 (that provides libgmp-3.0.x). 2. The ghc-4.08-1 distribution includes libgmp-2.x.x. 3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names are generated only if the header file is included. 4. The configure script does not recognize that libgmp is installed (because it does not include the header file.) 5. When linking, the linker cannot resolve symbols prefixed by mpz_ (because the 2.x.x header file was used in compilation but the linker uses the shared library provided by Suse Linux.) 5. Even if informed about the local installation of libgmp (by manually changing config.cache), the 2.x.x header file will be used (again resulting in unresolved bindings when linking). The same problems occur when bootstrapping from .hc files. What to do? Should I hack the Makefiles? Should I replace the libgmp distribution included in the ghc distribution by some new 3.x.x distribution? Thank you, Michael Marte ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
