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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
distribution?
Thank you,
Michael Marte
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
33 matches
Mail list logo
