Re: replace GHC 6.6 with 6.10.4 in VisualHaskell
On 12/10/2009 18:16, Luca Ciciriello wrote: Is there a way to use VisualHaskel with GHC 6.10.4? Unfortunately no, Visual Haskell is bitrotted and unmaintained. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
replace GHC 6.6 with 6.10.4 in VisualHaskell
Is there a way to use VisualHaskel with GHC 6.10.4? Luca ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] dropping GHC 6.6 support
[redirecting to ghc-users also] Matthias Kilian wrote: (Which as I understood would make porting a newer ghc to OpenBSD easier). Yes. The only alternatives would be to provide precompiled binaries (which is ugly, imho) or to maintain several versions of ghc in the ports tree (which is a maintainance nightmare). .hc files are ugly too; IMO about as ugly as precompiled binaries (.hc are platform specific and practically unreadable, just like binaries). At least the GHC HQ think so: currently bootstrapping-from-HC only works unregisterised (so it will be slow. Also, inherently, won't ever use GHC's NCG :-) (native code generator) ) -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.6 GADT type unification vs GHC 6.8
GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so. Specifically, GHC 6.8 and all subsequent versions require that when you pattern match on a value of GADT type, * the type of the scrutinee * the type of the result of the case * the types of any free variables used inside the case alternatives are all completely known (rigid in GHC's terminology) at the case expression. The easiest way to make a variable have a rigid type is to give it a type signature. I don't expect to revert to GHC 6.6's behaviour because I don't know how to do (robust, complete) type inference for that. I'll add these remarks to the user manual. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dagit Sent: 21 July 2008 20:44 To: glasgow-haskell-users@haskell.org Subject: GHC 6.6 GADT type unification vs GHC 6.8 Hello, I was wresting with the problem of converting our type witness code in darcs to work with ghc 6.8 and it occurred to me that someone has probably document the change somewhere. In particular, I'm seeing this error message a lot, but 6.6 doesn't give this message: GADT pattern match in non-rigid context for `NilRL' Tell GHC HQ if you'd like this to unify the context The main difference I have observed is that 6.6 infers types in case statements fully, but 6.8 seems to skip them and expects type signatures. Sometimes I'm at a loss to figure out where to add the type signature to satisfy 6.8 and the process becomes tedious and time consuming. I'm using 6.8.2 and I did see this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-December/013952.html What version of GHC do I need to see the improved diagnostics mentioned in that thread? Will the GADT unification in 6.10 be compatible with 6.6? If so, maybe I shouldn't convert the code to work for 6.8. Also, can someone point me to a discussion of the difference or a paper about it? Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 GADT type unification vs GHC 6.8
On Tue, Jul 29, 2008 at 1:07 AM, Simon Peyton-Jones [EMAIL PROTECTED]wrote: GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so. Specifically, GHC 6.8 and all subsequent versions require that when you pattern match on a value of GADT type, · the type of the scrutinee · the type of the result of the case · the types of any free variables used inside the case alternatives are all completely known (rigid in GHC's terminology) at the case expression. Thanks, this makes sense and helps. Is this described in the wobbly types paper, or is paper covering a different topics? I would like to have a cite-able reference. The easiest way to make a variable have a rigid type is to give it a type signature. I don't expect to revert to GHC 6.6's behaviour because I don't know how to do (robust, complete) type inference for that. In that case, good thing I finally figured out what changes to make to darcs so that our type witness code compiles in both 6.6 and 6.8. My changes match what you describe. I'll add these remarks to the user manual. Great! Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.6 GADT type unification vs GHC 6.8
Thanks, this makes sense and helps. Is this described in the wobbly types paper, or is paper covering a different topics? I would like to have a cite-able reference. Excellent question. I believe that what I describe below is a restriction of the system described in the POPL'06 paper http://research.microsoft.com/%7Esimonpj/papers/gadt/gadt-icfp.pdf At this moment I can't remember when we changed to the additional restrictions below. I think the reason was that we wanted to avoid the complexity of fresh mgus described in the paper, but memory is failing me. Dimitrios or Stephanie may have a better memory. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dagit Sent: 29 July 2008 15:14 To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: Re: GHC 6.6 GADT type unification vs GHC 6.8 On Tue, Jul 29, 2008 at 1:07 AM, Simon Peyton-Jones [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so. Specifically, GHC 6.8 and all subsequent versions require that when you pattern match on a value of GADT type, * the type of the scrutinee * the type of the result of the case * the types of any free variables used inside the case alternatives are all completely known (rigid in GHC's terminology) at the case expression. Thanks, this makes sense and helps. Is this described in the wobbly types paper, or is paper covering a different topics? I would like to have a cite-able reference. The easiest way to make a variable have a rigid type is to give it a type signature. I don't expect to revert to GHC 6.6's behaviour because I don't know how to do (robust, complete) type inference for that. In that case, good thing I finally figured out what changes to make to darcs so that our type witness code compiles in both 6.6 and 6.8. My changes match what you describe. I'll add these remarks to the user manual. Great! Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 GADT type unification vs GHC 6.8
On Tue, Jul 29, 2008 at 7:40 AM, Simon Peyton-Jones [EMAIL PROTECTED]wrote: Thanks, this makes sense and helps. Is this described in the wobbly types paper, or is paper covering a different topics? I would like to have a cite-able reference. Excellent question. I believe that what I describe below is a * restriction* of the system described in the POPL'06 paper http://research.microsoft.com/%7Esimonpj/papers/gadt/gadt-icfp.pdf At this moment I can't remember when we changed to the additional restrictions below. I think the reason was that we wanted to avoid the complexity of fresh mgus described in the paper, but memory is failing me. Dimitrios or Stephanie may have a better memory. Thank you. I'm reading it now, and I believe it will work just perfect for my needs. Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6 GADT type unification vs GHC 6.8
Hello, I was wresting with the problem of converting our type witness code in darcs to work with ghc 6.8 and it occurred to me that someone has probably document the change somewhere. In particular, I'm seeing this error message a lot, but 6.6 doesn't give this message: GADT pattern match in non-rigid context for `NilRL' Tell GHC HQ if you'd like this to unify the context The main difference I have observed is that 6.6 infers types in case statements fully, but 6.8 seems to skip them and expects type signatures. Sometimes I'm at a loss to figure out where to add the type signature to satisfy 6.8 and the process becomes tedious and time consuming. I'm using 6.8.2 and I did see this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-December/013952.html What version of GHC do I need to see the improved diagnostics mentioned in that thread? Will the GADT unification in 6.10 be compatible with 6.6? If so, maybe I shouldn't convert the code to work for 6.8. Also, can someone point me to a discussion of the difference or a paper about it? Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: migration guide from ghc-6.6 to ghc-6.8
list of things to watch out for when converting Haskell sources written for ghc-6.6 for compilation with ghc-6.8. Thanks for the pointers. Luckily, only a few changes were needed, http://leiffrenzel.de/eclipse/wiki/doku.php?id=hare_with_gh-6.8 (sic). and most of them related to GHC API. I'm not completely sure whether it's semantically correct but at least it compiles. Best regards, J.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Wanted: migration guide from ghc-6.6 to ghc-6.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, I could use a list of things to watch out for when converting Haskell sources written for ghc-6.6 for compilation with ghc-6.8. Of course I'll try write down some items while I find them but I'd hope not to start at zero... Is there an easy way to get a library API diff (automatically, say, from full 6.6 and 6.8 installations)? Best regards, Johannes Waldmann. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9hn73ZnXZuOVyMIRAk1nAKDEteU/FHMHz4yDgL936r/rRfLy5gCfTTFz 0fv7U+nP4ELZ9xZT/qicODc= =B50t -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wanted: migration guide from ghc-6.6 to ghc-6.8
Hi Johanes, You could look at the following wiki page: http://haskell.org/haskellwiki/Upgrading_packages It lists most of the issues you may face when upgrading to GHC-6.8 and Cabal 1.2. Hope this helps, Olivier. On Fri, Apr 4, 2008 at 1:07 PM, Johannes Waldmann [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, I could use a list of things to watch out for when converting Haskell sources written for ghc-6.6 for compilation with ghc-6.8. Of course I'll try write down some items while I find them but I'd hope not to start at zero... Is there an easy way to get a library API diff (automatically, say, from full 6.6 and 6.8 installations)? Best regards, Johannes Waldmann. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9hn73ZnXZuOVyMIRAk1nAKDEteU/FHMHz4yDgL936r/rRfLy5gCfTTFz 0fv7U+nP4ELZ9xZT/qicODc= =B50t -END PGP SIGNATURE- ___ 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.6 Debian packages
Ian Lynagh schrieb: On Fri, Jul 06, 2007 at 09:46:39AM +0200, Christian Maeder wrote: Ian Lynagh schrieb: If you are using Debian etch then you can do apt-get install libghc6-.*-dev to install all GHC 6 libraries. There isn't such an easy way to install just those (somewhat arbitrarily) defined to be extralibs, though. Could someone list the available packages (and its versions)? In Debian Etch (stable)? http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libghc6searchon=namessubword=1version=stablerelease=all That's an impressive matrix of libraries and supported architectures. Loading all 46 libraries may be overkill for us. Furthermore we additionally need to install hxt, Shellac and Shellac-readline (and we use a slightly modified HTTP package that's used by hxt) Appart from the (somewhat arbitrarily) defined extralibs we need HaXml-1.13.2 and WashNGo (or wash). (We do not need all extralibs, though, i.e. OpenAL) Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 Debian packages
Ian Lynagh schrieb: If you are using Debian etch then you can do apt-get install libghc6-.*-dev to install all GHC 6 libraries. There isn't such an easy way to install just those (somewhat arbitrarily) defined to be extralibs, though. Could someone list the available packages (and its versions)? Are there plans to provide also ghc-6.6.1 debian packages? I think ghc-6.6.1 provides new time and filepath packages. Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 Debian packages
On Fri, Jul 06, 2007 at 09:46:39AM +0200, Christian Maeder wrote: Ian Lynagh schrieb: If you are using Debian etch then you can do apt-get install libghc6-.*-dev to install all GHC 6 libraries. There isn't such an easy way to install just those (somewhat arbitrarily) defined to be extralibs, though. Could someone list the available packages (and its versions)? In Debian Etch (stable)? http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libghc6searchon=namessubword=1version=stablerelease=all Are there plans to provide also ghc-6.6.1 debian packages? At some point, but there are more pressing things to do first. I think ghc-6.6.1 provides new time and filepath packages. time was a 6.6 extralib and is in stable. (I don't know off the top of my head what differences there were between the versions that came with 6.6 and 6.6.1). filepath wasn't an extralib, but is in stable nonetheless. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 Debian packages
On Thu, 2007-07-05 at 12:11 -0400, Matthew Danish wrote: On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: Is there no way to provide all the extra libs in one debian package for ghc? It may be possible to create a package which depends on all normal extras but that seems counter-productive. Au contraire - I think that is a great way to go about it, and it is how a lot of things get done. Meta-packages include desktop environments (e.g. KDE and Gnome) and the Linux kernel (e.g. linux-generic). -k ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 Debian packages
On Fri, 2007-07-06 at 08:36 +0200, Ketil Malde wrote: On Thu, 2007-07-05 at 12:11 -0400, Matthew Danish wrote: On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: Is there no way to provide all the extra libs in one debian package for ghc? It may be possible to create a package which depends on all normal extras but that seems counter-productive. Au contraire - I think that is a great way to go about it, and it is how a lot of things get done. Meta-packages include desktop environments (e.g. KDE and Gnome) and the Linux kernel (e.g. linux-generic). However those projects clearly define which components make up the whole. We do not. There are the core packages that come with ghc and then there are all the other packages you can find on hackage. The 'extra' packages is just a bunch that used to be distributed with ghc. They're not intended to be canonical as far as I know. My understanding is that that 'extra' tarball is just a transitional thing provided for convenience until hackage gets up to speed. If people want to go and define some standard distribution of packages then that's another matter, but that's something that should be driven centrally rather than each of the various distro maintainers picking some arbitrary set of packages. Duncan (wearing his Gentoo packager hat) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.6 Debian packages
Hi, our developers that have a debian system (i.e Ubuntu) and want to compile our sources with ghc complain that they have to install many extra library packages one after another. Compiling fails at various stages due to missing packages. Is there no way to provide all the extra libs in one debian package for ghc? Cheers Christian ii libghc6-fgl-dev 5.3-3 Haskell graph library for GHC ii libghc6-haskell-src-dev 1.0-3 Haskell module for manipulating Haskell sour ii libghc6-html-dev 1.0-3 Haskell html library for GHC ii libghc6-hunit-dev 1.1-3 Haskell unit testing framework for GHC ii libghc6-mtl-dev 1.0-3 Haskell monad transformer library for GHC ii libghc6-network-dev 2.0-3 Haskell network library for GHC ii libghc6-quickcheck-dev1.0-3 Haskell automatic testing library for GHC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 Debian packages
On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: Hi, our developers that have a debian system (i.e Ubuntu) and want to compile our sources with ghc complain that they have to install many extra library packages one after another. Compiling fails at various stages due to missing packages. Is there no way to provide all the extra libs in one debian package for ghc? It may be possible to create a package which depends on all normal extras but that seems counter-productive. As a Debian user who frequently operates disconnected from the network, I have to say I have found such 'extras' packages highly productive---the loss of disk space is more than compensated for by the ability to continue working during a long plane flight, because packages I didn't know I needed are already installed on my system. I would welcome a virtual package to pull in all things ghc-6.6. Norman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 Debian packages
On Thu, Jul 05, 2007 at 03:04:06PM -0400, Norman Ramsey wrote: As a Debian user who frequently operates disconnected from the network, I have to say I have found such 'extras' packages highly productive---the loss of disk space is more than compensated for by the ability to continue working during a long plane flight, because packages I didn't know I needed are already installed on my system. I would welcome a virtual package to pull in all things ghc-6.6. If you are using Debian etch then you can do apt-get install libghc6-.*-dev to install all GHC 6 libraries. There isn't such an easy way to install just those (somewhat arbitrarily) defined to be extralibs, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 panics when compiling HSet from collections package
Daniel McAllansmith wrote:
Hi.
I just got the collections package from
http://darcs.haskell.org/packages/collections-ghc6.6
When trying to build it with GHC 6.6 on an amd64 linux machine using Cabal I
got the following:
[12 of 57] Compiling Data.Tree.AVL.IntMap.Internals.HSet (
Data.Tree.AVL.IntMap/Data/Tree/AVL/IntMap/Internals/HSet.hs,
dist/build/Data/Tree/AVL/IntMap/Internals/HSet.o )
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for x86_64-unknown-linux):
cgPanic
tpl{v s2zg} [lid]
static binds for:
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.intersectionMaybeH{v
rji} [gid]
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.$Lr2jfforkL{v r2jf}
[gid]
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.$Lr2jhforkR{v r2jh}
[gid]
local binds for:
SRT label
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.intersectionWithH'{v
rjg}_srt
Anyone seen this before? A real GHC bug, a problem with my GHC installation,
or a problem with the collections package?
It's a known bug in in ghc 6.6, you need to upgrade to ghc 6.6.1.
BTW, beware of using some of the stuff that I've written for this :-)
The Data.Tree.AVL part (including Data.Map.AVL and Data.Set.AVL)
should be fairly safe as it's been heavily tested.
But the Data.Trie.General part is still under active development,
volatile, unfinished and completely untested.
Also, don't use the Data.Tree.AVL.IntMap stuff either if you can
avoid it. I believe it works fine, but I've decided it would be
best to obsolete this and subsume it within Data.Trie.General
as Data.Trie.General.IntGT
Regards
--
Adrian Hey
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6 panics when compiling HSet from collections package
Hi.
I just got the collections package from
http://darcs.haskell.org/packages/collections-ghc6.6
When trying to build it with GHC 6.6 on an amd64 linux machine using Cabal I
got the following:
[12 of 57] Compiling Data.Tree.AVL.IntMap.Internals.HSet (
Data.Tree.AVL.IntMap/Data/Tree/AVL/IntMap/Internals/HSet.hs,
dist/build/Data/Tree/AVL/IntMap/Internals/HSet.o )
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for x86_64-unknown-linux):
cgPanic
tpl{v s2zg} [lid]
static binds for:
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.intersectionMaybeH{v
rji} [gid]
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.$Lr2jfforkL{v r2jf}
[gid]
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.$Lr2jhforkR{v r2jh}
[gid]
local binds for:
SRT label
collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.intersectionWithH'{v
rjg}_srt
Anyone seen this before? A real GHC bug, a problem with my GHC installation,
or a problem with the collections package?
Cheers
Daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re : HDirect and GHC-6.6
Hi all, It's been a long time since I had the time to work with haskell, but I have some news about HDirect. I now succeed in compiling ihc.exe with the typelib support (see my previous posts on the subject), but I had to bypass the packages. That is, the second compilation stage is made using the object files from the comlib rather than the com package. I understand that it is rather ugly but I still hope that it may be useful to anyone needing COM support with ghc. If anyone is interested in the source files, feel free to ask me. Sincerely yours, sL ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 for mac os x (intel)
Hi Ian, Thanks so much for trying to help out. You are right, that readline file is not there so I installed it from MacPorts and made a symbolic link to the installed location. Now everything is fine. Thanks again! Ariel Ian Lynagh wrote: Hi Ariel, Sorry for the delayed response. On Tue, Feb 06, 2007 at 12:07:46PM -0600, Ariel Apostoli wrote: Are you using http://haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 ? Yes. I've just downloaded it, and it looks like the Makefile should run post-install-script to put readline/* in the right place. Can you check if that is happening correctly? the post-install script is not exactly happy; here is what i get when it starts running: [snipped] I'm not sure what output is expected, but your earlier message http://www.haskell.org/pipermail/glasgow-haskell-users/2007-February/011962.html suggested that there is no file /opt/local/lib/libreadline.5.1.dylib whereas post-install-script certainly looks like it will put something there. Can you confirm whether or not the file is there, and whether you are still getting the same error please? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem exporting Haskell to C via a DLL in GHC 6.6
Simon Peyton-Jones wrote: I don't think there is any reason in principle why GHC can't generate DLLs that just work, but plainly it's deficient at the moment. The fundamental reason is that the DLL mechanism itself doesn't allow initialization/ shutdown do be hidden from the user of a DLL, because the order of loading/unloading DLLs is unspecified by the MS Windows operating system. Therefore it's not a GHC problem - it's just a fact of life with DLLs... The other thing is that we could do with more how to documentation about GHC and DLLs. We have a bit here: http://haskell.org/haskellwiki/GHC/Using_the_FFI Could you expand it in the light of your experience? I've added a section http://haskell.org/haskellwiki/GHC/Using_the_FFI#Beware_of_DllMain.28.29.21 which attempts to explain why init/exit code can't be put in DllMain, as well as an *untested* example to show what I meant by putting init/exit code in Begin/End functions instead. I've put a note next to the example to say that it's untested, and to appeal to anyone with more knowledge of static linking between Haskell and C to fix anything I've missed or replace with a better example. (Apologies for not testing it but static linking to stubs generated by GHC seems to require the DLL to be compiled by gcc and use of gcc on Windows seems to require Cygwin since gcc doesn't seem to understand Windows paths and I don't have Cygwin installed - unfortunately at the moment I don't have time to pursue this further.) Best regards, Brian. -- http://www.metamilk.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 for mac os x (intel)
Hello Ian, Ian Lynagh wrote: Are you using http://haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 ? Yes. I've just downloaded it, and it looks like the Makefile should run post-install-script to put readline/* in the right place. Can you check if that is happening correctly? the post-install script is not exactly happy; here is what i get when it starts running: Running project-specific post-install script ... == Regenerating library archive headers... ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Types_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Atom_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Event_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Font_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Misc_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Types_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Types_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Atom_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Event_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Font_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Misc_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Types_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase.a(CPUTime_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase.a(Time_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase_cbits.a(timeUtils.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase_p.a(CPUTime_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase_p.a(Time_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork.a(BSD_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork.a(Socket_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork_p.a(BSD_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork_p.a(Socket_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSreadline.a(Readline_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSreadline_p.a(Readline_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSregex-posix.a(Wrap_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSregex-posix_p.a(Wrap_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Disassembler.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(FrontPanel.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(LdvProfile.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ProfHeap.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Profiling.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Proftimer.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(RetainerProfile.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(RetainerSet.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Sanity.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ThreadLabels.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Ticky.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(InitEachPE.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ShutdownEachPEHook.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(0Hash.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(0Unpack.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Dist.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Global.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(GranSim.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(HLComms.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(LLComms.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Pack.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ParInit.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ParTicky.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Parallel.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ParallelDebug.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(RBH.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Disassembler.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(FrontPanel.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Sanity.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(ThreadLabels.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Ticky.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(InitEachPE.p_o) has no symbols ranlib: file: /usr/local/lib
Re: Problem exporting Haskell to C via a DLL in GHC 6.6
SevenThunders wrote:
Brian Hulley wrote:
SevenThunders wrote:
DllMain
if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
return TRUE;
}
The above *may* be the problem: it is unsafe to do anything in
DllMain that...
Instead of trying to start/shutdown Haskell from DllMain, I'd export
a Begin() and End() function from the DLL and explicitly call these
from your application's main().
So in your scheme the Begin() would call the startupHaskell function
and the End() call the shutdown Haskell?
Yes.
Or would the Begin initiate
the linking to the specific DLL using LoadLibrary?
Since Begin would be a function exported by the DLL, Windows would ensure
that the DLL was loaded when it is first called from your application if it
was not already loaded so there would be no need for an explicit call to
LoadLibrary.
and then End
specifically unload the library; or both?
I wouldn't bother explicitly unloading the library - I'd leave this up to
Windows. The importance of using an End function is that you can ensure that
the call to shutdown Haskell happens at a time when all DLLs needed by
Haskell are still available, whereas using DllMain to do the shutdown call
is dangerous because DllMain may be invoked when some DLL necessary for
Haskell to shutdown has already been unloaded by Windows.
Ideally there would also be some way to call Begin/End when using the DLL
from Matlab but I don't know anything about Matlab so can't help with this.
A quick hack to enable you to use the DLL safely from your application
(using Begin/End) as well as unsafely from Matlab (relying on DllMain to
shutdown Haskell), would just be to have a flag in the DLL to keep track of
whether you've already shut Haskell down. Then in the case for
process_detach you could just check this so that shutdown would only be
called from DllMain as a last resort.
Another question I have is, is it possible to create a statically
linked Haskell library that can be linked using MS VC tools? Also I
must say I am a bit confused about the use of the routine
__stginit_Bad. Suppose I had multiple Haskell modules each with
their own functions to export. Which __stginit_??? routine do I use?
I don't know - hopefully someone else may be able to answer this question.
Best regards, Brian.
--
http://www.metamilk.com
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 for mac os x (intel)
I installed the darwin ports readline and created the following soft link: /usr/local/lib/libreadline.5.1.dylib - /opt/local/lib/libreadline. 5.1.dylib Alternatively, you could install the darwin ports readline and set the DYLD_LIBRARY_PATH variable. I prefer not to use DYLD_LIBRARY_PATH. -reilly On Feb 6, 2007, at 7:15 AM, Ariel Apostoli wrote: but when I try installing ghc from that page it seems to install fine but when I invoke /usr/local/bin/ghc i get: dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 Reason: image not found Trace/BPT trap My version of mac os x is 10.4.8 Again thanks for your time and help so far! Ariel Kirsten Chevalier wrote: [redirecting to the list] On 2/5/07, Ariel Apostoli [EMAIL PROTECTED] wrote: Hello Kirsten, Thanks so much for your time and help so far. However, I am still stuck on the issue when I try to do this: ./configure --with-readline-includes=/usr/local \ --with-readline-libraries=/usr/local I get: checking build system type... i686-apple-darwin8.8.1 checking host system type... i686-apple-darwin8.8.1 checking target system type... i686-apple-darwin8.8.1 Canonicalised to: i386-apple-darwin checking for path to top of build tree... /Users/ariel/work/ghc/ ghc-6.6 checking for ghc... no checking for ghc-pkg matching ... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no configure: error: GHC is required unless bootstrapping from .hc files. Do you know what should I do to avoid this? Do you already have a binary version of GHC installed? If you want to build GHC from source, you need a binary of GHC installed already, like the error message suggests. (Unless you want to bootstrap from .hc files, but I've never done that, so I don't know.) See: http://haskell.org/ghc/download_ghc_66.html#macosxintel You didn't say what version of Mac OS X you were using; if it's anything older than 10.3, you're probably SOL. Cheers, Kirsten ___ 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: Problem exporting Haskell to C via a DLL in GHC 6.6
Brian Hulley wrote: Since Begin would be a function exported by the DLL, Windows would ensure that the DLL was loaded when it is first called from your application if it was not already loaded so there would be no need for an explicit call to LoadLibrary. and then End specifically unload the library; or both? I wouldn't bother explicitly unloading the library - I'd leave this up to Windows. The importance of using an End function is that you can ensure that the call to shutdown Haskell happens at a time when all DLLs needed by Haskell are still available, whereas using DllMain to do the shutdown call is dangerous because DllMain may be invoked when some DLL necessary for Haskell to shutdown has already been unloaded by Windows. Ideally there would also be some way to call Begin/End when using the DLL from Matlab but I don't know anything about Matlab so can't help with this. A quick hack to enable you to use the DLL safely from your application (using Begin/End) as well as unsafely from Matlab (relying on DllMain to shutdown Haskell), would just be to have a flag in the DLL to keep track of whether you've already shut Haskell down. Then in the case for process_detach you could just check this so that shutdown would only be called from DllMain as a last resort. Another question I have is, is it possible to create a statically linked Haskell library that can be linked using MS VC tools? Also I must say I am a bit confused about the use of the routine __stginit_Bad. Suppose I had multiple Haskell modules each with their own functions to export. Which __stginit_??? routine do I use? I don't know - hopefully someone else may be able to answer this question. Best regards, Brian. -- http://www.metamilk.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users In the final analysis this seems to work fairly well. I export an End() function to Matlab that calls shutdownHaskell(). I then create a Matlab script that calls End() prior to clearing the DLL out of the namespace. Since it appears that shutdownHaskell() can be called again, even after it's already shut down without incident (at least from a few simple experiments) it works fairly robustly. All that needs to be done is to remember to use the Matlab script as needed. Meanwhile, it also appears I can call the same routines from inside C, letting windows do the DLL linkage, provided that shutdownHaskell() is NOT called when the DLL unloads as you indicated earlier. Thanks again for the help. -- View this message in context: http://www.nabble.com/Problem-exporting-Haskell-to-C-via-a-DLL-in-GHC-6.6-tf3179123.html#a8839209 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.6 for mac os x (intel)
Hello, I tried to install ghc 6.6 but apparently I have done something wrong since whenever I type ghc I obtain: $ /usr/local/bin/ghc dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 Reason: image not found Trace/BPT trap can anyone help please? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 for mac os x (intel)
On 2/4/07, Ariel Apostoli [EMAIL PROTECTED] wrote: Hello, I tried to install ghc 6.6 but apparently I have done something wrong since whenever I type ghc I obtain: $ /usr/local/bin/ghc dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 Reason: image not found Trace/BPT trap Hi, Ariel-- Have you seen the page on building GHC on Mac OS X? http://cvs.haskell.org/trac/ghc/wiki/Building/MacOSX In particular, it explains how to set up the readline library so that GHC can find it. If you try the instructions there and something still doesn't work, feel free to post here again. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt The astonishment of life is the absence of any appearance of reconciliation between the theory and practice of life.--Emerson ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re : HDirect and GHC-6.6
Hi,
Here are some details on my building of HDirect with ghc-6.6, and where I am
stuck.
Skipping details about deprecated libs (such as IOExts) and some name conflicts
(NativeInfo), I succeeded in building the ihc.exe, the hdirect and com
libs.
I installed the com lib as a package on my system:
$ ghc-pkg.exe list
c:/ghc/ghc-6.6\package.conf:
[...] com-0.22, fgl-5.2, (ghc-6.6), [...]
$ ghc-pkg.exe describe com
name: com
version: 0.22
[...]
exposed: True
exposed-modules: AutoPrim Automation ClassFactory Com ComDll
ComException ComPrim ComServ Connection ConnectionPoint
EnumInterface ExeServer HDirect Pointer PointerPrim SafeArray
StdDispatch StdTypes TypeLib WideString
[...]
extra-libraries: kernel32 user32 ole32 oleaut32 advapi32
From here, I tried to bootstrap the ihc compiler with the support for typelibs.
$ cd ../src
$ rm -f *.o
$ make depend SUPPORT_TYPELIBS=YES
$ make SUPPORT_TYPELIBS=YES
But the make depend fails :
$ make depend SUPPORT_TYPELIBS=YES
ghc -M -optdep-f -optdep.depend -optdep-o -optdepo -cpp -DBEGIN_SUPPORT_TYPELIB
S='-}' -DEND_SUPPORT_TYPELIBS='{-' -DBEGIN_NOT_SUPPORT_TYPELIBS='{-' -DEND_NOT_S
UPPORT_TYPELIBS='-}' -package com -fglasgow-exts -static -fvia-C -Rghc-timing
-Wall -package com AbsHUtils.lhs AbstractH.lhs Attribute.lhs Bag.lhs BasicT
ypes.lhs CStubGen.lhs CgMonad.lhs CodeGen.lhs CoreIDL.lhs CoreUtils.lhs DefGen.l
hs Desugar.lhs DsMonad.lhs Env.lhs FiniteMap.lhs GetOpt.lhs HugsCodeGen.lhs IDLS
yn.lhs IDLToken.lhs IDLUtils.lhs ImportLib.lhs JavaProxy.lhs Lex.lhs LexM.lhs Li
bUtils.lhs Literal.lhs Main.lhs MarshallAbstract.lhs MarshallAuto.lhs MarshallCo
re.lhs MarshallDep.lhs MarshallEnum.lhs MarshallFun.lhs MarshallJNI.lhs Marshall
JServ.lhs MarshallMethod.lhs MarshallMonad.lhs MarshallServ.lhs MarshallStruct.l
hs MarshallType.lhs MarshallUnion.lhs MarshallUtils.lhs MkImport.lhs NameSupply.
lhs NormaliseType.lhs Opts.lhs PP.lhs PpAbstractH.lhs PpCore.lhs PpIDLSyn.lhs Pr
eProc.lhs Pretty.lhs Rename.lhs RnMonad.lhs Skeleton.lhs SrcLoc.lhs SymbolTable.
lhs TLBWriter.lhs TypeInfo.lhs Utils.lhs Validate.lhs CustomAttributes.hs Parser
.hs Version.hs OmgParser.hs NativeInfo.hs
ImportLib.lhs:39:7:
Could not find module `TypeLib':
I do not understand why TypeLib is not found, as it is included in the com
package.
This may be a newbie's question, excuse me if it has been answered millions of
time.
Sincerely yours,
Samuel
PS : if I use the option in the src/Makefile, which consists in using
-i../comlib and other flags instead of -package com, the make depend
works, but the following make fails as follows :
ghc -fglasgow-exts -static -fvia-C -Rghc-timing -Wall -i../lib -L../lib
-I../lib -i../comlib -lole32 -loleaut32 -ladvapi32-c ../comlib/AutoPrim.hs
-o ../comlib/AutoPrim.o -osuf o
../comlib/AutoPrim.hs:69:0: Invalid type signature
Hope this helps.
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDirect and GHC-6.6
Some time ago I even started to design my own comlib. It is quite different from HDirect's comlib but is more closer in spirit to Haskell's FFI lib. It isn't completed yet but if someone is interested in I would upload it in darcs next week. It is living in Foreign.COM namespace. Cheers, Krasimir On 1/12/07, shelarcy [EMAIL PROTECTED] wrote: Hi Sigbjorn, Is there any plan to transition from CVS to darcs? HDirect is removed from darcs'ing fptools, and left cvs long ago. Because HDirect is not active. http://www.haskell.org/pipermail/cvs-ghc/2005-October/026817.html But HDirect is updated sometime. (We can see HDirect moves 'comlib' into a hierarchic setting, System.Win32.Com.* two month ago.) And Visual Haskell project changes comlib. http://www.haskell.org/pipermail/haskell/2006-September/018445.html http://www.haskell.org/pipermail/haskell-cafe/2006-September/018037.html Unfortunately these changes are independent. It forks comlib now. So I want to know what is common change both repository and what is useful change both version, easily. I think darcs'ing HDirect and two comlib branch realise it. And that helps to revive Visual Haskell's HDirect that can generate it's comlib source code. Best Regards, On Fri, 12 Jan 2007 00:53:59 +0900, Sigbjorn Finne [EMAIL PROTECTED] wrote: you may want to check out the CVS version of HDirect, which does have a version of the compiler which is reasonably up-to-date wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' libraries. foo$ export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs foo$ cvs login (Logging in to [EMAIL PROTECTED]) CVS password: cvs foo$ cvs co fptools/hdirect (Derived from CVS setup instructions at http://cvs.haskell.org/ ) I apologize for not having the time to work on or support that code. -- shelarcy shelarcycapella.freemail.ne.jp http://page.freett.com/shelarcy/ ___ Libraries mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDirect and GHC-6.6
Krasimir Angelov wrote: Some time ago I even started to design my own comlib. It is quite different from HDirect's comlib but is more closer in spirit to Haskell's FFI lib. It isn't completed yet but if someone is interested in I would upload it in darcs next week. It is living in Foreign.COM namespace. I'm very interested in such a library. I've also developed my own com (client) library, but as for now it is too raw to be published. Cheers, Kyra ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDirect and GHC-6.6
On Wed, Jan 10, 2007 at 09:24:40PM +, Fernand Lacas wrote: Hello, This is my first post on this mailing list and I hope it will not be too off-topic. My point is that I have worked a little on the porting of the last (0.21) version of HDirect ([1]http://www.haskell.org/hdirect/) to ghc 6.6. I succeeded in compiling the ihc.exe (idl compiler) but I'm now stuck on the boot-strapping of the COM library (which is required to have support for Automation). This seems to come from a new feature of the package management system, which includes the package's name in the interface files (.hi). Alas, on the beginning of this new year (happy new year to you all), I lack time to understand the cabal system to solve this. I've written to the people mentioned in the README (and others), which are supposed to support the library, but got no answer. I assume they are no longer supporting it. Thus, I simply wanted to know if someone on this list, more involved with ghc or haskell's community, would be interested to have the sources files so that, may be in the near future, hdirect could be up to date with ghc, and also that other people could benefit from that small contribution without re-inventing the wheel (my changes are not complex, but rather tedious because I had to track all deprecated libraries, correct a GHC-specific bug). I also think that hdirect build process should be translated to Cabal's setup (it currently uses Makefiles, but the build process is not straightforward, so the adaptation requires a knowledge I do not have of Cabal). Sincerely yours, Samuel P.-S. I do not check this mail on a daily basis, so it is possible I won't answer immediately, but within one or two days. Excuse my french, it is my mother tongue. Hi Samuel. I know. If you want to use hdirect with com support you need some kind of 2 stage build. I've tried to compile it some time ago and I failed (lack of knowledge and understanding haskell at that time).. So you did succeed? similar to ghc its using a 2 stage build. I will post a link to this message on cabal-devel@haskell.org avoiding cross-posting, too So we have by now 4 packagers having problems with the current cabal system? wxwidgets, gtk2hs, hdirect and ghc itself? Greetings Marc ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDirect and GHC-6.6
Hi Samuel, you may want to check out the CVS version of HDirect, which does have a version of the compiler which is reasonably up-to-date wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' libraries. foo$ export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs foo$ cvs login (Logging in to [EMAIL PROTECTED]) CVS password: cvs foo$ cvs co fptools/hdirect (Derived from CVS setup instructions at http://cvs.haskell.org/ ) I apologize for not having the time to work on or support that code. hth --sigbjorn On 1/10/2007 13:24, Fernand Lacas wrote: Hello, This is my first post on this mailing list and I hope it will not be too off-topic. My point is that I have worked a little on the porting of the last (0.21) version of HDirect (http://www.haskell.org/hdirect/) to ghc 6.6. I succeeded in compiling the ihc.exe (idl compiler) but I'm now stuck on the boot-strapping of the COM library (which is required to have support for Automation). This seems to come from a new feature of the package management system, which includes the package's name in the interface files (.hi). Alas, on the beginning of this new year (happy new year to you all), I lack time to understand the cabal system to solve this. I've written to the people mentioned in the README (and others), which are supposed to support the library, but got no answer. I assume they are no longer supporting it. Thus, I simply wanted to know if someone on this list, more involved with ghc or haskell's community, would be interested to have the sources files so that, may be in the near future, hdirect could be up to date with ghc, and also that other people could benefit from that small contribution without re-inventing the wheel (my changes are not complex, but rather tedious because I had to track all deprecated libraries, correct a GHC-specific bug). I also think that hdirect build process should be translated to Cabal's setup (it currently uses Makefiles, but the build process is not straightforward, so the adaptation requires a knowledge I do not have of Cabal). Sincerely yours, Samuel P.-S. I do not check this mail on a daily basis, so it is possible I won't answer immediately, but within one or two days. Excuse my french, it is my mother tongue. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re : HDirect and GHC-6.6
Hi, Yes, my point was indeed about the second compilation stage : once you have build the libs (comlib, the ihc tool and hdirect), you have to install them (com and hdirect) as packages in order to rebuild the ihc tool with the support for type libraries. At this point, the makefile-based build process fails, and I did not succeed in building the ihc tool with the support for typelibs without the packages because of my lack of knowledge with Cabal. Note that Sigbjorn Finne also kindly answered my post, so I will have look at the cvs version of hdirect. Sincerely yours, Samuel - Message d'origine De : Marc Weber [EMAIL PROTECTED] À : glasgow-haskell-users@haskell.org Envoyé le : Jeudi, 11 Janvier 2007, 13h44mn 35s Objet : Re: HDirect and GHC-6.6 Hi Samuel. I know. If you want to use hdirect with com support you need some kind of 2 stage build. I've tried to compile it some time ago and I failed (lack of knowledge and understanding haskell at that time).. So you did succeed? similar to ghc its using a 2 stage build. I will post a link to this message on cabal-devel@haskell.org avoiding cross-posting, too So we have by now 4 packagers having problems with the current cabal system? wxwidgets, gtk2hs, hdirect and ghc itself? Greetings Marc ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDirect and GHC-6.6
Hi Sigbjorn, Is there any plan to transition from CVS to darcs? HDirect is removed from darcs'ing fptools, and left cvs long ago. Because HDirect is not active. http://www.haskell.org/pipermail/cvs-ghc/2005-October/026817.html But HDirect is updated sometime. (We can see HDirect moves 'comlib' into a hierarchic setting, System.Win32.Com.* two month ago.) And Visual Haskell project changes comlib. http://www.haskell.org/pipermail/haskell/2006-September/018445.html http://www.haskell.org/pipermail/haskell-cafe/2006-September/018037.html Unfortunately these changes are independent. It forks comlib now. So I want to know what is common change both repository and what is useful change both version, easily. I think darcs'ing HDirect and two comlib branch realise it. And that helps to revive Visual Haskell's HDirect that can generate it's comlib source code. Best Regards, On Fri, 12 Jan 2007 00:53:59 +0900, Sigbjorn Finne [EMAIL PROTECTED] wrote: you may want to check out the CVS version of HDirect, which does have a version of the compiler which is reasonably up-to-date wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' libraries. foo$ export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs foo$ cvs login (Logging in to [EMAIL PROTECTED]) CVS password: cvs foo$ cvs co fptools/hdirect (Derived from CVS setup instructions at http://cvs.haskell.org/ ) I apologize for not having the time to work on or support that code. -- shelarcy shelarcycapella.freemail.ne.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HDirect and GHC-6.6
Hello, This is my first post on this mailing list and I hope it will not be too off-topic. My point is that I have worked a little on the porting of the last (0.21) version of HDirect (http://www.haskell.org/hdirect/) to ghc 6.6. I succeeded in compiling the ihc.exe (idl compiler) but I'm now stuck on the boot-strapping of the COM library (which is required to have support for Automation). This seems to come from a new feature of the package management system, which includes the package's name in the interface files (.hi). Alas, on the beginning of this new year (happy new year to you all), I lack time to understand the cabal system to solve this. I've written to the people mentioned in the README (and others), which are supposed to support the library, but got no answer. I assume they are no longer supporting it. Thus, I simply wanted to know if someone on this list, more involved with ghc or haskell's community, would be interested to have the sources files so that, may be in the near future, hdirect could be up to date with ghc, and also that other people could benefit from that small contribution without re-inventing the wheel (my changes are not complex, but rather tedious because I had to track all deprecated libraries, correct a GHC-specific bug). I also think that hdirect build process should be translated to Cabal's setup (it currently uses Makefiles, but the build process is not straightforward, so the adaptation requires a knowledge I do not have of Cabal). Sincerely yours, Samuel P.-S. I do not check this mail on a daily basis, so it is possible I won't answer immediately, but within one or two days. Excuse my french, it is my mother tongue. __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Fundep broken in GHC 6.6
Simon Peyton-Jones wrote: I just applied this rule http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#id3170412 In this case the type of newBoard is newBoard :: (Game b mv e, MonadStaet b m) = m () Following the rules in that manual section, this type sig is (now) ok. Does that answer your qn Yes, I think it does. I guess I'll only really know when I can either get my hands on 6.6.1, or successfully compile GHC from darcs. Thanks! -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Fundep broken in GHC 6.6
I just applied this rule http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#id3170412 In this case the type of newBoard is newBoard :: (Game b mv e, MonadStaet b m) = m () Following the rules in that manual section, this type sig is (now) ok. Does that answer your qn Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yitzchak Gale | Sent: 03 January 2007 22:26 | To: Simon Peyton-Jones | Cc: GHC users | Subject: Re: [Haskell] Fundep broken in GHC 6.6 | | On 12 November 2006 I wrote (on the haskell list): | class Error e = Game b mv e | b - mv e where | newBoard :: MonadState b m = m () | ... | Since MonadState has the fundep m - b, the type | of newBoard fully specifies all of the class parameters | But GHC 6.6 complains... | | Simon Peyton-Jones wrote: | I have committed a fix to the HEAD that relaxes the | condition, and allows this program. | It should appear in 6.6.1 also. | | Thank you! | | Am I correct to assume that this fix only applies to the | specific case of unspecified class parameters in | method declarations? And not any of the other cases | where fundeps on class constraints resolve type ambiguity | but are ignored by GHC, such as instance declarations? | | Does the fix actually look at the fundeps in the class | constraint on the method, or just relax the | requirement that all class parameters be specified in | every method? If it is the latter, as I suspect, then is | the requirement always relaxed, or only when there is | a class constraint on the method? | | Thanks, | Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Fundep broken in GHC 6.6
[redirecting to ghc users] Actually this didn't work in 6.4.2 either! (Though it did in 6.4, for reasons I have not investigated.) Indeed I think your reasoning is correct. GHC tries to be pretty relaxed about reporting ambiguous types, which is what this amounts to really. I have committed a fix to the HEAD that relaxes the condition, and allows this program. It should appear in 6.6.1 also. Thanks for the report Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of dpus | Sent: 12 November 2006 19:36 | To: haskell@haskell.org | Subject: [Haskell] Fundep broken in GHC 6.6 | | Hi, | | The following class declaration worked in GHC 6.4. | I recently upgraded to 6.6 (following Debian), and | now it is broken. | | class Error e = Game b mv e | b - mv e where | newBoard :: MonadState b m = m () | ... | | Since MonadState has the fundep m - b, the type | of newBoard fully specifies all of the class parameters. | And this worked fine in GHC 6.4. But GHC 6.6 | complains: | | The class method `newBoard' | mentions none of the type variables of the class Game b mv e | When checking the class method: newBoard :: m () | In the class declaration for `Game' | | Any ideas? | | Thanks, | Yitz | ___ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Fundep broken in GHC 6.6
On 12 November 2006 I wrote (on the haskell list): class Error e = Game b mv e | b - mv e where newBoard :: MonadState b m = m () ... Since MonadState has the fundep m - b, the type of newBoard fully specifies all of the class parameters But GHC 6.6 complains... Simon Peyton-Jones wrote: I have committed a fix to the HEAD that relaxes the condition, and allows this program. It should appear in 6.6.1 also. Thank you! Am I correct to assume that this fix only applies to the specific case of unspecified class parameters in method declarations? And not any of the other cases where fundeps on class constraints resolve type ambiguity but are ignored by GHC, such as instance declarations? Does the fix actually look at the fundeps in the class constraint on the method, or just relax the requirement that all class parameters be specified in every method? If it is the latter, as I suspect, then is the requirement always relaxed, or only when there is a class constraint on the method? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6-src-extralibs.tar.bz2
Am Freitag, 8. Dezember 2006 21:08 schrieb Ian Lynagh: This will probably have been made with whatever OpenGL was in darcs when the build was done (the binary distributions come from the nightly builds). [...] OK, so in a nutshell: Everything is fine with the binary releases, it can just be the case that different platforms might see different package versions of non-core packages. No big deal to upgrade/downgrade later, given our package system/Cabal. We should possibly do something like having only odd second components (e.g. version 2.3 but not version 2.4) in darcs repos so we can at least spot these unstable version numbers. Then to do a release you'd push the three patches Version=2.4; tag 2.4; Version=2.5 all at once. This makes sense, and it would be good if all packages in darcs.haskell.org/packages agreed on this numbering scheme. One minor question: Who will actually push those three patches and when? Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6-src-extralibs.tar.bz2
On Fri, Dec 08, 2006 at 08:55:28AM +0100, Sven Panne wrote: Am Donnerstag, 7. Dezember 2006 11:37 schrieb Christian Maeder: The archive http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2 does not contain the files ControlPoint.hs and Domain.hs from directory libraries/OpenGL/Graphics/Rendering/OpenGL/GL/ If I see things correctly, the 6.6 extralibs contain the version 2.1 of the OpenGL package, i.e. the stuff currently in http://hackage.haskell.org/packages/unstable/OpenGL/, at least I hope so. :-/ These files are listed by the binary distribution http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2 This will probably have been made with whatever OpenGL was in darcs when the build was done (the binary distributions come from the nightly builds). The extralibs are not part of the GHC release, they are just sometimes bundled to make users' lives easier, so the GHC release is not tied to any particular version of the extralibs. To be honest, I don't fully understand the workflow for building the official GHC distributions currently. In former times, the whole tree, including libraries, had a CVS tag, so things were crystal-clear. GHC and the core libraries all have a 6.6 release tag. One problem we do have is that if you get a library (core, extralibs or otherwise) from darcs on two different days then you might get two different libraries with the same version number. We should possibly do something like having only odd second components (e.g. version 2.3 but not version 2.4) in darcs repos so we can at least spot these unstable version numbers. Then to do a release you'd push the three patches Version=2.4; tag 2.4; Version=2.5 all at once. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6-src-extralibs.tar.bz2
The archive http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2 does not contain the files ControlPoint.hs and Domain.hs from directory libraries/OpenGL/Graphics/Rendering/OpenGL/GL/ These files are listed by the binary distribution http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2 Personally I don't miss these files, but they are of course missing from distributions I (and possibly others) made. How imported are these files? They are also not listed in libraries/OpenGL/openGL.cabal. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6-src-extralibs.tar.bz2
Am Donnerstag, 7. Dezember 2006 11:37 schrieb Christian Maeder: The archive http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2 does not contain the files ControlPoint.hs and Domain.hs from directory libraries/OpenGL/Graphics/Rendering/OpenGL/GL/ If I see things correctly, the 6.6 extralibs contain the version 2.1 of the OpenGL package, i.e. the stuff currently in http://hackage.haskell.org/packages/unstable/OpenGL/, at least I hope so. :-/ These files are listed by the binary distribution http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2 Personally I don't miss these files, but they are of course missing from distributions I (and possibly others) made. How imported are these files? They are also not listed in libraries/OpenGL/openGL.cabal. The current HEAD (i.e. http://darcs.haskell.org/packages/OpenGL/) contains the bleeding edge version of the OpenGL package, and the version number has already been bumped to 2.2 there (although the version is not yet finished) to avoid confusion. Due to some refactorings, this version has the modules you've mentioned, and they are in the .cabal file, too. So if there is something wrong, it must be the packaging of the 6.6 distributions, but not the OpenGL package itself. To be honest, I don't fully understand the workflow for building the official GHC distributions currently. In former times, the whole tree, including libraries, had a CVS tag, so things were crystal-clear. But due to the new flexibility of making packages independent, we suffer from versionits now, it seems... Some comments/explanations from the packagers are highly welcome. Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re: OpengGL lockup using GHC 6.6 on Intel Mac
Yep, that works well. Thanx! On 12/1/06, Deborah Goldsmith [EMAIL PROTECTED] wrote: I can get this to work if I compile it with ghc, rather than try to run it with ghci or hugs. ghc --make Alpha3D.hs ./Alpha3D works fine with no hangs. Deborah On Dec 1, 2006, at 6:49 PM, Deborah Goldsmith wrote: It fails on PowerPC too, using the standard PPC distribution. Deborah On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote: This also fails in Hugs (crashes rather than hangs), so it looks like it's a problem with the GLUT binding on Mac OS X Intel rather than something specific to GHC. I'll see if I can find a PPC machine to try it on also. Deborah On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: I can reproduce this with ghc-6.6 built from source as well. I sampled ghc while it was stuck like this, and it looks like it's trying to open a GUI event loop (not surprising if it's opening a window). It looks like something about that is not working. Unfortunately, the Intel binary distribution on the downloads page is missing some of the OpenGL C headers, and so won't work properly either. Deborah On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: Well, it doesn't lock the whole machine but loading Alpha3D.hs int GHCi and typing main causes a window to be displayed with no content and ghc 6.6 locked up, requiring a hard kill. On 12/1/06, Sven Panne [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. ___ 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 ___ 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 ___ 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: OpengGL lockup using GHC 6.6 on Intel Mac
Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OpengGL lockup using GHC 6.6 on Intel Mac
The NeHe tutorials work for me with both GHC 6.6 and HEAD on my Intel Mac; however, I'm not using MacPorts. Is anyone else here who uses MacPorts on an Intel Mac, to confirm or deny the bug? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re: OpengGL lockup using GHC 6.6 on Intel Mac
Well, it doesn't lock the whole machine but loading Alpha3D.hs int GHCi and typing main causes a window to be displayed with no content and ghc 6.6 locked up, requiring a hard kill. On 12/1/06, Sven Panne [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OpengGL lockup using GHC 6.6 on Intel Mac
I can reproduce this with ghc-6.6 built from source as well. I sampled ghc while it was stuck like this, and it looks like it's trying to open a GUI event loop (not surprising if it's opening a window). It looks like something about that is not working. Unfortunately, the Intel binary distribution on the downloads page is missing some of the OpenGL C headers, and so won't work properly either. Deborah On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: Well, it doesn't lock the whole machine but loading Alpha3D.hs int GHCi and typing main causes a window to be displayed with no content and ghc 6.6 locked up, requiring a hard kill. On 12/1/06, Sven Panne [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. ___ 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: OpengGL lockup using GHC 6.6 on Intel Mac
This also fails in Hugs (crashes rather than hangs), so it looks like it's a problem with the GLUT binding on Mac OS X Intel rather than something specific to GHC. I'll see if I can find a PPC machine to try it on also. Deborah On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: I can reproduce this with ghc-6.6 built from source as well. I sampled ghc while it was stuck like this, and it looks like it's trying to open a GUI event loop (not surprising if it's opening a window). It looks like something about that is not working. Unfortunately, the Intel binary distribution on the downloads page is missing some of the OpenGL C headers, and so won't work properly either. Deborah On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: Well, it doesn't lock the whole machine but loading Alpha3D.hs int GHCi and typing main causes a window to be displayed with no content and ghc 6.6 locked up, requiring a hard kill. On 12/1/06, Sven Panne [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OpengGL lockup using GHC 6.6 on Intel Mac
It fails on PowerPC too, using the standard PPC distribution. Deborah On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote: This also fails in Hugs (crashes rather than hangs), so it looks like it's a problem with the GLUT binding on Mac OS X Intel rather than something specific to GHC. I'll see if I can find a PPC machine to try it on also. Deborah On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: I can reproduce this with ghc-6.6 built from source as well. I sampled ghc while it was stuck like this, and it looks like it's trying to open a GUI event loop (not surprising if it's opening a window). It looks like something about that is not working. Unfortunately, the Intel binary distribution on the downloads page is missing some of the OpenGL C headers, and so won't work properly either. Deborah On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: Well, it doesn't lock the whole machine but loading Alpha3D.hs int GHCi and typing main causes a window to be displayed with no content and ghc 6.6 locked up, requiring a hard kill. On 12/1/06, Sven Panne [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. ___ 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 ___ 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: OpengGL lockup using GHC 6.6 on Intel Mac
I can get this to work if I compile it with ghc, rather than try to run it with ghci or hugs. ghc --make Alpha3D.hs ./Alpha3D works fine with no hangs. Deborah On Dec 1, 2006, at 6:49 PM, Deborah Goldsmith wrote: It fails on PowerPC too, using the standard PPC distribution. Deborah On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote: This also fails in Hugs (crashes rather than hangs), so it looks like it's a problem with the GLUT binding on Mac OS X Intel rather than something specific to GHC. I'll see if I can find a PPC machine to try it on also. Deborah On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: I can reproduce this with ghc-6.6 built from source as well. I sampled ghc while it was stuck like this, and it looks like it's trying to open a GUI event loop (not surprising if it's opening a window). It looks like something about that is not working. Unfortunately, the Intel binary distribution on the downloads page is missing some of the OpenGL C headers, and so won't work properly either. Deborah On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: Well, it doesn't lock the whole machine but loading Alpha3D.hs int GHCi and typing main causes a window to be displayed with no content and ghc 6.6 locked up, requiring a hard kill. On 12/1/06, Sven Panne [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. ___ 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 ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
OpengGL lockup using GHC 6.6 on Intel Mac
I just installed ghc 6.6 from MacPorts and am trying to use the Haskell ported NeHe OpenGL lessons to play with OpenGL. Unfortunately, when I load the lesson in ghci and then run main the screen turns to garbage and I am forced to power cycle the machine to get back to my desktop. It's not a complete lockup as I an Alt-Tab between apps and the selector UI appears. Selecting an app, though, does nothing and I have no access to the desktop. Anyone know of any issues with the current HOpenGL on Intel? The code comes from this link: http://www.codersbase.com/index.php/Nehe-tuts Don't worry about darcs. You can select the URL for the repo and get the code directly form there. Thanx, joe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 on Ubuntu
On Fri, Nov 17, 2006 at 07:48:41AM -0800, Chad Scherrer wrote: Is there a preferred way of getting this going? I tried the GHC instructions for Debian, but this seems to depend on 6.6 already being in the repository, which it's not, in Ubuntu (why?). I like Debian/Ubuntu's install system, and I assume that 6.6 will eventually make it into Ubuntu. I want to be sure whatever I do now doesn't later confuse the system. I assume you're sending this to me as I'm listed as maintainer on the ubuntu packages, but I am not involved with ubuntu. You'd have to speak with the Ubuntu people for info about their plans for GHC 6.6 etc. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6 on Ubuntu
Is there a preferred way of getting this going? I tried the GHC instructions for Debian, but this seems to depend on 6.6 already being in the repository, which it's not, in Ubuntu (why?). I like Debian/Ubuntu's install system, and I assume that 6.6 will eventually make it into Ubuntu. I want to be sure whatever I do now doesn't later confuse the system. Thanks, Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Memory leak in FFI callback: GHC 6.6
Matthew Thanks for submitting the Trac bug. I don't know what the answer to your qn below is, but maybe someone else on ghc-users does. Meanwhile, I added the qn to the bug report. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of SevenThunders | Sent: 03 November 2006 19:04 | To: glasgow-haskell-users@haskell.org | Subject: RE: Memory leak in FFI callback: GHC 6.6 | | | | Simon Peyton-Jones wrote: | | Dear SevenThunders (if that is how you like to addressed) | | Thanks for extracting a small program that exhibits the leak; that is | really helpful. We'll look into it. Would you like to create a Trac bug | and attach your files? | | Simon | | | | | You can call me Matthew. The bug, if that's what it is, is now ticket | number 985. By the way, why can't I get the callback to actually work in | this example? If I for example uncomment the line | -- pd - cfunc pcf | | and say print out the value of pd, I get garbage values. | | Should I have used CDouble? I think for windows HsDouble = double in C | land. | -- | View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6- | tf2565446.html#a7165550 | Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. | | ___ | 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: Memory leak in FFI callback: GHC 6.6
Dear SevenThunders (if that is how you like to addressed)
Thanks for extracting a small program that exhibits the leak; that is
really helpful. We'll look into it. Would you like to create a Trac bug
and attach your files?
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| On Behalf Of SevenThunders
| Sent: 03 November 2006 02:54
| To: glasgow-haskell-users@haskell.org
| Subject: Memory leak in FFI callback: GHC 6.6
|
|
| I'm not sure if this is a bug, but it sure seems that way to me. When
using
| the wrapper technique for creating a Haskell callback function it
seems
| that freeHaskellFunPtr is not properly freeing the resource.
|
| Here is an example program
| leaky.hs
| module Main where
| import Foreign
| import Foreign.Ptr
| import Foreign.Storable
|
| -- | A convenient type synonym for storable arrays
| type Darr = Ptr (Double)
| -- | Function type for mapping doubles to doubles
| type Dfunc = Double - Double
| -- | A convenient type synonym for monad containing storable arrays
| type IODarr = IO (Darr)
|
|
| foreign import ccall wrapper mkDfunc :: Dfunc - IO (FunPtr Dfunc)
| foreign import ccall cleaky.h cfunc cfunc :: (FunPtr Dfunc) - IO (
Double
| )
|
|
| dadd :: Dfunc
| dadd x = x + 1.0
|
| getleaky :: Dfunc - IO ()
| getleaky cf = do
| pcf - mkDfunc cf
| -- pd - cfunc pcf
| print pcf
| freeHaskellFunPtr pcf
|
|
| main = sequence_ [getleaky dadd | q - [1..50]]
|
|
| It's compiled with
| ghc -fglasgow-exts -fffi -prof -auto -I. --make leaky.hs cleaky.o
|
| A possible cleaky.c and cleaky.h are
| #include math.h
| #include stdio.h
| #include cleaky.h
|
|
| double state = 1.0 ;
|
| double cfunc(DFptr fptr)
| {
| // printf(In cfunc, fptr: %p\n, fptr) ;
| state = (*fptr) (state) ;
| // printf(state: %g\n, state) ;
| return(state) ;
| }
|
| typedef double (*DFptr) (double) ;
| double cfunc(DFptr) ;
|
| though they are not used.
|
| leaky.exe grows the heap linearly without bound on windows XP 64. The
| profiler never reports this correctly either.
| calling
| leaky +RTS -hc -RTS
| does not show the increase in the memory usage.
|
| --
| View this message in context:
http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6-
| tf2565446.html#a7150757
| Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
|
| ___
| 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.6 under sparc-sun-solaris
Duncan Coutts schrieb: On Tue, 2006-10-17 at 12:15 +0200, Christian Maeder wrote: P.S. building under solaris requires over 2GB memory (and takes a day) It's only have half of this. I've mixed up du -s (showing Blocks) and du -sh. My tree also included a binary-dist. -bash-3.00$ du -s 2266972 . -bash-3.00$ du -sh 1.1G . -bash-3.00$ cd ghc-6.6/#this is the binary-dist only -bash-3.00$ du -sh 331M . It takes 12 hours on my old 500Mhz sparc with 1GB ram. I know split-objs takes lots of memory when building the archive, but 2GB seems excessive. Judging from the first and last created files (below) it took 9 hours on my machine: Model: Sun Fire 280R Memory Size (MB): 3072 Processor Speed (MHz): 900 -bash-3.00$ ll utils/mkdependC/mkdependC -rwxr-xr-x 1 maeder wimi6057 Oct 20 16:54 utils/mkdependC/mkdependC -bash-3.00$ ll compiler/stage2/ghc-6.6 -rwxr-xr-x 1 maeder wimi 21069118 Oct 21 01:52 compiler/stage2/ghc-6.6 Cheers Christian fast 3:30 hours took: Hardware Architecture: pc Operating System: solaris10 Model: AMD Athlon-64 Memory Size (MB): 1024 Processor Speed (MHz): 2000 -bash-3.1$ ll utils/mkdependC/mkdependC -rwxr-xr-x 1 maeder wimi6054 Nov 2 13:21 utils/mkdependC/mkdependC -bash-3.1$ ll compiler/stage2/ghc-6.6 -rwxr-xr-x 1 maeder wimi 20629720 Nov 2 16:49 compiler/stage2/ghc-6.6 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Memory leak in FFI callback: GHC 6.6
Simon Peyton-Jones wrote: Dear SevenThunders (if that is how you like to addressed) Thanks for extracting a small program that exhibits the leak; that is really helpful. We'll look into it. Would you like to create a Trac bug and attach your files? Simon You can call me Matthew. The bug, if that's what it is, is now ticket number 985. By the way, why can't I get the callback to actually work in this example? If I for example uncomment the line -- pd - cfunc pcf and say print out the value of pd, I get garbage values. Should I have used CDouble? I think for windows HsDouble = double in C land. -- View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6-tf2565446.html#a7165550 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Memory leak in FFI callback: GHC 6.6
I'm not sure if this is a bug, but it sure seems that way to me. When using
the wrapper technique for creating a Haskell callback function it seems
that freeHaskellFunPtr is not properly freeing the resource.
Here is an example program
leaky.hs
module Main where
import Foreign
import Foreign.Ptr
import Foreign.Storable
-- | A convenient type synonym for storable arrays
type Darr = Ptr (Double)
-- | Function type for mapping doubles to doubles
type Dfunc = Double - Double
-- | A convenient type synonym for monad containing storable arrays
type IODarr = IO (Darr)
foreign import ccall wrapper mkDfunc :: Dfunc - IO (FunPtr Dfunc)
foreign import ccall cleaky.h cfunc cfunc :: (FunPtr Dfunc) - IO ( Double
)
dadd :: Dfunc
dadd x = x + 1.0
getleaky :: Dfunc - IO ()
getleaky cf = do
pcf - mkDfunc cf
-- pd - cfunc pcf
print pcf
freeHaskellFunPtr pcf
main = sequence_ [getleaky dadd | q - [1..50]]
It's compiled with
ghc -fglasgow-exts -fffi -prof -auto -I. --make leaky.hs cleaky.o
A possible cleaky.c and cleaky.h are
#include math.h
#include stdio.h
#include cleaky.h
double state = 1.0 ;
double cfunc(DFptr fptr)
{
// printf(In cfunc, fptr: %p\n, fptr) ;
state = (*fptr) (state) ;
// printf(state: %g\n, state) ;
return(state) ;
}
typedef double (*DFptr) (double) ;
double cfunc(DFptr) ;
though they are not used.
leaky.exe grows the heap linearly without bound on windows XP 64. The
profiler never reports this correctly either.
calling
leaky +RTS -hc -RTS
does not show the increase in the memory usage.
--
View this message in context:
http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6-tf2565446.html#a7150757
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 for OS X using MacPorts
Hi Aaron, On Oct 27, 2006, at 12:42 PM, Aaron Tomb wrote: Hello, The Portfile has made it to the servers, but installation doesn't complete successfully for me (on Intel/10.4.8). The first issue is that something happens to the dynamic library lookup path so the configure check for a working C compiler fails with a dyld error. I managed to fix this with the following: cd /usr mkdir i686-apple-darwin8 cd i686-apple-darwin8 ln -s ../lib This allows configure to complete, but then it seems to have trouble finding the bootstrap compiler. I've attached the entire output, since I think context is important. If it seems more appropriate for this discussion to continue on the MacPorts mailing list, let me know. Can you tell me which version of Xcode you are running? Do open /Developer/Applications/Xcode.app then under the Xcode menu look at About Xcode . It should give the version number, as well as the component version number. Send those to me. Everything seems to work fine for some installation on Intel, and others have seen the problem you describe. Look very much like some Xcode version issue. Best WIshes, Greg Aaron ghc-macports.log On Oct 27, 2006, at 6:59 AM, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 for OS X using MacPorts
Aaron, On Oct 27, 2006, at 12:42 PM, Aaron Tomb wrote: Hello, The Portfile has made it to the servers, but installation doesn't complete successfully for me (on Intel/10.4.8). The first issue is that something happens to the dynamic library lookup path so the configure check for a working C compiler fails with a dyld error. I managed to fix this with the following: cd /usr mkdir i686-apple-darwin8 cd i686-apple-darwin8 ln -s ../lib This allows configure to complete, but then it seems to have trouble finding the bootstrap compiler. I've attached the entire output, since I think context is important. If it seems more appropriate for this discussion to continue on the MacPorts mailing list, let me know. One more thing: After adding the symlink, you must do sudo port clean ghc to clean up the failed build before trying again. Macports is not smart enough to do that yet, but if you don't, you will have all kinds of unpredictable problems. -Greg Aaron ghc-macports.log On Oct 27, 2006, at 6:59 AM, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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.6 for OS X using MacPorts
On Oct 28, 2006, at 10:30 AM, Gregory Wright wrote: One more thing: After adding the symlink, you must do sudo port clean ghc to clean up the failed build before trying again. Macports is not smart enough to do that yet, but if you don't, you will have all kinds of unpredictable problems. This turned out to be the key. With the symlinks and Xcode 2.2.1, it works fine if I do 'sudo port clean ghc' first. I should have thought to try it before reporting the problem. Aaron ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6 for OS X using MacPorts
Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 for OS X using MacPorts
Hi Greg, I have just been trying to install ghc 6.6 using Darwin Ports, but the search facility can't find ghc-6.6. : sudo port selfupdate DarwinPorts base version 1.320 installed Downloaded MacPorts base version 1.320 The MacPorts installation is not outdated and so was not updated selfupdate done! dhcp2940:~ cmb21$ port search ghc ghclang/ghc 6.4.2The Glorious Glasgow Haskell Compilation System ghc-devel lang/ghc-devel 6.5 The Glorious Glasgow Haskell Compilation System (development version) dhcp2940:~ cmb21$ Am I doing something wrong? Kind regards, Chris Brown, On Fri, 27 Oct 2006, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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.6 for OS X using MacPorts
On Oct 27, 2006, at 10:25 AM, C.M.Brown wrote: Hi Greg, I have just been trying to install ghc 6.6 using Darwin Ports, but the search facility can't find ghc-6.6. : sudo port selfupdate DarwinPorts base version 1.320 installed Downloaded MacPorts base version 1.320 The MacPorts installation is not outdated and so was not updated selfupdate done! dhcp2940:~ cmb21$ port search ghc ghclang/ghc 6.4.2The Glorious Glasgow Haskell Compilation System ghc-devel lang/ghc-devel 6.5 The Glorious Glasgow Haskell Compilation System (development version) dhcp2940:~ cmb21$ Am I doing something wrong? No, just give the servers a few hours to run their update scripts. Then the new portfiles will be available by selfupdate. (I confess I do not know how often these days the scripts run, but it is at least a couple of times per day, IIRC.) If by, say, UTC 28 Oct 2006 you don't see the new portfiles, let me know. Something might be wacky with the server. Sorry for the delay. Best Wishes, Greg Kind regards, Chris Brown, On Fri, 27 Oct 2006, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 for OS X using MacPorts
Hello, The Portfile has made it to the servers, but installation doesn't complete successfully for me (on Intel/10.4.8). The first issue is that something happens to the dynamic library lookup path so the configure check for a working C compiler fails with a dyld error. I managed to fix this with the following: cd /usr mkdir i686-apple-darwin8 cd i686-apple-darwin8 ln -s ../lib This allows configure to complete, but then it seems to have trouble finding the bootstrap compiler. I've attached the entire output, since I think context is important. If it seems more appropriate for this discussion to continue on the MacPorts mailing list, let me know. Aaron ghc-macports.log Description: Binary data On Oct 27, 2006, at 6:59 AM, Gregory Wright wrote: Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC [EMAIL PROTECTED] ___ 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
OS X - Haskell to Objective-C Binding on GHC 6.6
Is anyone out there running OS X and using HOC and GHC 6.6? I took the latest from cvs and got some way toward getting it to compile by changing the code to: 1. reflect changes regarding packages, i.e. adding -package-name to the pertinent makefiles, and accommodating the changed signature of Language.Haskell.TH.Syntax mkNameG_v and mkNameG_tc 2. replacing the obsolete names used from Data.Set which have been removed from GHC 6.6. At that point HOC was able to get to the point where it parses the ObjC headers, but it then choked on compiling the generated .hs files, some of which seem to have invalid constructions like: -- enum definitions $(declareAnonymousCEnum [(NSFileNoSuchFileError, 4),(NSFileLockingError, 255),(NSFileReadUnknownError, 256),(NSFileReadNoPermissionError, 257),(NSFileReadInvalidFileNameError, 25,(NSFileReadCorruptFileError, 259),(NSFileReadNoSuchFileError, 260),(NSFileReadInapplicableStringEncodingError, 261),(NSFileReadUnsupportedSchemeError, 262),(NSFileWriteUnknownError, 512),(NSFileWriteNoPermissionError, 513),(NSFileWriteInvalidFileNameError, 514),(NSFileWriteInapplicableStringEncodingError, 517),(NSFileWriteUnsupportedSchemeError, 51,(NSFileWriteOutOfSpaceError, 640),(NSKeyValueValidationError, 1024),(NSFormattingError, 204,(NSUserCancelledError, 3072),(NSFileErrorMinimum, 0),(NSFileErrorMaximum, 1023),(NSValidationErrorMinimum, 1024),(NSValidationErrorMaximum, 2047),(NSFormattingErrorMinimum, 204,(NSFormattingErrorMaximum, 2559)]) I'm a complete beginner to Hasell, and at this point I'm a bit stuck. Any help would be much appreciated! Cheers, - Charlie ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OS X - Haskell to Objective-C Binding on GHC 6.6
Mathew, Would you be willing to send me a cvs diff as well? Thanks, -Rod On Oct 26, 2006, at 2:08 PM, Mathew Mills wrote: I just succeeded in building HOC from CVS HEAD against ghc-6.6 on x86 Mac OS X last night. I didn't encounter that specific problem, though. I can send you a cvs diff if that would help. On Oct 26, 2006, at 10:15 AM, Charlie Conklin wrote: Is anyone out there running OS X and using HOC and GHC 6.6? I took the latest from cvs and got some way toward getting it to compile by changing the code to: 1. reflect changes regarding packages, i.e. adding -package-name to the pertinent makefiles, and accommodating the changed signature of Language.Haskell.TH.Syntax mkNameG_v and mkNameG_tc 2. replacing the obsolete names used from Data.Set which have been removed from GHC 6.6. At that point HOC was able to get to the point where it parses the ObjC headers, but it then choked on compiling the generated .hs files, some of which seem to have invalid constructions like: -- enum definitions $(declareAnonymousCEnum [(NSFileNoSuchFileError, 4), (NSFileLockingError, 255),(NSFileReadUnknownError, 256),(NSFileReadNoPermissionError, 257),(NSFileReadInvalidFileNameError, 25, (NSFileReadCorruptFileError, 259),(NSFileReadNoSuchFileError, 260),(NSFileReadInapplicableStringEncodingError, 261),(NSFileReadUnsupportedSchemeError, 262), (NSFileWriteUnknownError, 512),(NSFileWriteNoPermissionError, 513), (NSFileWriteInvalidFileNameError, 514),(NSFileWriteInapplicableStringEncodingError, 517),(NSFileWriteUnsupportedSchemeError, 51, (NSFileWriteOutOfSpaceError, 640),(NSKeyValueValidationError, 1024),(NSFormattingError, 204,(NSUserCancelledError, 3072),(NSFileErrorMinimum, 0),(NSFileErrorMaximum, 1023),(NSValidationErrorMinimum, 1024),(NSValidationErrorMaximum, 2047),(NSFormattingErrorMinimum, 204,(NSFormattingErrorMaximum, 2559)]) I'm a complete beginner to Hasell, and at this point I'm a bit stuck. Any help would be much appreciated! Cheers, - Charlie ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OS X - Haskell to Objective-C Binding on GHC 6.6
My diff can be found here: http://mathewmills.com/HOC/cvsdiff.patch Several of the changes were naive and not required, particularly in the Samples directories. IANAHE ( I am not a Haskell expert ), so who knows what I broke... On Oct 26, 2006, at 1:19 PM, Rodney D Price wrote: Mathew, Would you be willing to send me a cvs diff as well? Thanks, -Rod On Oct 26, 2006, at 2:08 PM, Mathew Mills wrote: I just succeeded in building HOC from CVS HEAD against ghc-6.6 on x86 Mac OS X last night. I didn't encounter that specific problem, though. I can send you a cvs diff if that would help. On Oct 26, 2006, at 10:15 AM, Charlie Conklin wrote: Is anyone out there running OS X and using HOC and GHC 6.6? I took the latest from cvs and got some way toward getting it to compile by changing the code to: 1. reflect changes regarding packages, i.e. adding -package-name to the pertinent makefiles, and accommodating the changed signature of Language.Haskell.TH.Syntax mkNameG_v and mkNameG_tc 2. replacing the obsolete names used from Data.Set which have been removed from GHC 6.6. At that point HOC was able to get to the point where it parses the ObjC headers, but it then choked on compiling the generated .hs files, some of which seem to have invalid constructions like: -- enum definitions $(declareAnonymousCEnum [(NSFileNoSuchFileError, 4), (NSFileLockingError, 255),(NSFileReadUnknownError, 256),(NSFileReadNoPermissionError, 257),(NSFileReadInvalidFileNameError, 25, (NSFileReadCorruptFileError, 259),(NSFileReadNoSuchFileError, 260),(NSFileReadInapplicableStringEncodingError, 261),(NSFileReadUnsupportedSchemeError, 262), (NSFileWriteUnknownError, 512),(NSFileWriteNoPermissionError, 513), (NSFileWriteInvalidFileNameError, 514),(NSFileWriteInapplicableStringEncodingError, 517),(NSFileWriteUnsupportedSchemeError, 51, (NSFileWriteOutOfSpaceError, 640),(NSKeyValueValidationError, 1024),(NSFormattingError, 204,(NSUserCancelledError, 3072),(NSFileErrorMinimum, 0),(NSFileErrorMaximum, 1023),(NSValidationErrorMinimum, 1024),(NSValidationErrorMaximum, 2047), (NSFormattingErrorMinimum, 204,(NSFormattingErrorMaximum, 2559)]) I'm a complete beginner to Hasell, and at this point I'm a bit stuck. Any help would be much appreciated! Cheers, - Charlie ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 using stale stub.c files
Juan Carlos Arevalo Baeza wrote: I tried recompiling a little (big?) Win32 binding library I had made, when the official one wasn't working for me. It had a bunch of generated stubs files in it (I'm not 100% sure what they are for). The problem is that, not even with -fforce-recomp (much better name, thanx!) will GHC regenerate those files (I think that's normal), but still it tries to use them if they are there. I get errors like these: Win32Test_stub.c: In function `Main_d4n0': Win32Test_stub.c:14:0: error: too few arguments to function `rts_mkPtr' Win32Test_stub.c:14:0: warning: passing arg 1 of `rts_apply' from incompatible pointer type Win32Test_stub.c:14:0: error: too few arguments to function `rts_apply' Win32Test_stub.c:14:0: warning: passing arg 1 of `rts_mkWord32' makes pointer from integer without a cast (etc, etc... lots of them). The stub file is old: C:\Documents and Settings\JCAB\My Documents\Haskelldir Win32Test_stub.c Volume in drive C has no label. Volume Serial Number is A0CD-B8F4 I think you are encountering this bug: http://hackage.haskell.org/trac/ghc/ticket/706 workaround: delete the old stub files. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
moving to ghc-6.6
Hello. I just move a larger project to ghc-6.6 (from 6.4) http://dfa.imn.htwk-leipzig.de/auto/ (ca. 1000 modules) I had to modify my sources in several places. Perhaps the following list of observations is useful. tools: cabal/ghc work nicely, including building for profiling and haddockumentation. (I'm still missing cabal support for building docs that I want to access not via the file system but via a web server.) when ghc --make finds a source file that starts wrongly (e. g. modul Foo instead of module Foo) (might occur from unobserved CVS merge conflicts) it just says no location info: file name does not match module name `Main' and it is quite impossible to find out which file is to blame (even ghc -v does not give any information?) type system: In some places I found it convenient to write type decls like foo ( x :: a ) ( y :: [ b ] ) = ... because this gave me at least some kind of documentation while I was too lazy to figure out all the type class requirements that I would need for a full signature. This is now impossible (a and b can no longer be declared by the line above?). But on the other hand this is more a question of coding style, not of compilation. Still the above method gave me the easiest way of getting some programs to compile. I cannot just remove all type sigs because then parts of the program might be ambiguous. To disambiguate, I am now forced to be more verbose. (Which may be a good thing.) Sometimes the type class restrictions in my code are larger than the actual program ... Yes, I introduce constraint collection classes, e.g. http://141.57.11.163/cgi-bin/cvsweb/box/src/Rewriting/Approximation/Genet.hs?rev=1.22 I guess I have too much overlapping instances in my code already, and now ghc seems to enforce that this be declared earlier (at the class definition, not usage)? the coverage condition not satisfied error message (with functional dependencies) should include a hint that -fallow-undecidable-instances might help. library changes: Network.CGI is new, but we have Network.CGI.Compat. Which however refers to Text.XHtml, not Text.Html, so I had to change these imports as well. source encoding: it is annoying that ghc only accepts UTF-8 now. sure I can use iconv but I rather not touch my sources at all. with javac, I can just say -encoding latin1. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 using stale stub.c files
Simon Marlow wrote: Juan Carlos Arevalo Baeza wrote: I tried recompiling a little (big?) Win32 binding library I had made, when the official one wasn't working for me. It had a bunch of generated stubs files in it (I'm not 100% sure what they are for). The problem is that, not even with -fforce-recomp (much better name, thanx!) will GHC regenerate those files (I think that's normal), but still it tries to use them if they are there. I get errors like these: I think you are encountering this bug: http://hackage.haskell.org/trac/ghc/ticket/706 workaround: delete the old stub files. Yes, as I said, that workaround works. However, the description of the bug is incorrect. It picks up the _stub.c files, not the _stub.o files, and it picks them up even if the file is recompiled (and didn't re-generate the _stub.c file). Bug updated. Thanx! JCAB ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: moving to ghc-6.6
Another one: library change: the HasBounds class is gone. JCAB Johannes Waldmann wrote: Hello. I just move a larger project to ghc-6.6 (from 6.4) http://dfa.imn.htwk-leipzig.de/auto/ (ca. 1000 modules) I had to modify my sources in several places. Perhaps the following list of observations is useful. tools: cabal/ghc work nicely, including building for profiling and haddockumentation. (I'm still missing cabal support for building docs that I want to access not via the file system but via a web server.) when ghc --make finds a source file that starts wrongly (e. g. modul Foo instead of module Foo) (might occur from unobserved CVS merge conflicts) it just says no location info: file name does not match module name `Main' and it is quite impossible to find out which file is to blame (even ghc -v does not give any information?) type system: In some places I found it convenient to write type decls like foo ( x :: a ) ( y :: [ b ] ) = ... because this gave me at least some kind of documentation while I was too lazy to figure out all the type class requirements that I would need for a full signature. This is now impossible (a and b can no longer be declared by the line above?). But on the other hand this is more a question of coding style, not of compilation. Still the above method gave me the easiest way of getting some programs to compile. I cannot just remove all type sigs because then parts of the program might be ambiguous. To disambiguate, I am now forced to be more verbose. (Which may be a good thing.) Sometimes the type class restrictions in my code are larger than the actual program ... Yes, I introduce constraint collection classes, e.g. http://141.57.11.163/cgi-bin/cvsweb/box/src/Rewriting/Approximation/Genet.hs?rev=1.22 I guess I have too much overlapping instances in my code already, and now ghc seems to enforce that this be declared earlier (at the class definition, not usage)? the coverage condition not satisfied error message (with functional dependencies) should include a hint that -fallow-undecidable-instances might help. library changes: Network.CGI is new, but we have Network.CGI.Compat. Which however refers to Text.XHtml, not Text.Html, so I had to change these imports as well. source encoding: it is annoying that ghc only accepts UTF-8 now. sure I can use iconv but I rather not touch my sources at all. with javac, I can just say -encoding latin1. Best regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 using stale stub.c files
Juan Carlos Arevalo Baeza wrote: Simon Marlow wrote: Juan Carlos Arevalo Baeza wrote: I tried recompiling a little (big?) Win32 binding library I had made, when the official one wasn't working for me. It had a bunch of generated stubs files in it (I'm not 100% sure what they are for). The problem is that, not even with -fforce-recomp (much better name, thanx!) will GHC regenerate those files (I think that's normal), but still it tries to use them if they are there. I get errors like these: I think you are encountering this bug: http://hackage.haskell.org/trac/ghc/ticket/706 workaround: delete the old stub files. Yes, as I said, that workaround works. However, the description of the bug is incorrect. It picks up the _stub.c files, not the _stub.o files, and it picks them up even if the file is recompiled (and didn't re-generate the _stub.c file). Bug updated. Thanx! Now I'm surprised. I understood bug #706 as it was, I understand the cause and how to fix it. But I don't know how GHC could be recompiling the _stub.c files. There could be two bugs here. If you could supply us with a repro case, that would be very helpful (please attach it to the ticket). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under sparc-sun-solaris
Duncan Coutts schrieb: Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Yes! I get exactly the same under sparc linux for ghc-6.6. I've tried the same on a different machine (with another gcc) and now it works! It works with gcc_4.0.3_s10 on SunOS leo 5.10 Generic_118833-20 sun4u sparc SUNW,Sun-Fire-280R -bash-3.00$ compiler/stage2/ghc-6.6 ghc-6.6: missing -Bdir option -bash-3.00$ ldd compiler/stage2/ghc-6.6 librt.so.1 =/lib/librt.so.1 libdl.so.1 =/lib/libdl.so.1 libreadline.so.5 = /usr/local/lib/libreadline.so.5 libncurses.so.5 = /usr/local/lib/libncurses.so.5 libm.so.2 = /usr/local/lib/libm.so.2 libgmp.so.3 = /usr/local/lib/libgmp.so.3 libpthread.so.1 = /lib/libpthread.so.1 libc.so.1 = /lib/libc.so.1 libaio.so.1 = /lib/libaio.so.1 libmd5.so.1 = /lib/libmd5.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-280R/lib/libmd5_psr.so.1 It crashes as above on SunOS cni 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-V240 with gcc_3.4.4_s10. -bash-3.00$ compiler/stage2/ghc-6.6 ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? -bash-3.00$ ldd compiler/stage2/ghc-6.6 librt.so.1 =/lib/librt.so.1 libdl.so.1 =/lib/libdl.so.1 libreadline.so.5 = /usr/local/lib/libreadline.so.5 libncurses.so.5 = /usr/local/lib/libncurses.so.5 libm.so.2 = /usr/local/lib/libm.so.2 libgmp.so.3 = /usr/local/lib/libgmp.so.3 libpthread.so.1 = /lib/libpthread.so.1 libc.so.1 = /lib/libc.so.1 libaio.so.1 = /lib/libaio.so.1 libmd5.so.1 = /lib/libmd5.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under sparc-sun-solaris
Christian, I've reported this bug here: http://hackage.haskell.org/trac/ghc/ticket/951 Please add any further info you think necessary. Duncan On Wed, 2006-10-18 at 11:21 +0200, Christian Maeder wrote: Duncan Coutts schrieb: Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Yes! I get exactly the same under sparc linux for ghc-6.6. I've tried the same on a different machine (with another gcc) and now it works! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under sparc-sun-solaris
Duncan Coutts schrieb: 1. Without SplitObjs=NO in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line? Not as if, the build system really does add -split-objs and does some other magic when SplitObjs=NO is not in mk/build.mk. My stage2 compiler (created without SplitObjs=NO) works without any further options. But as soon as I add -split-objs I also have to add -opta-mcpu=ultrasparc. I wonder when -split-objs is in effect? Only during building? Or never under solaris if not supplied explicitely? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under sparc-sun-solaris
Duncan Coutts schrieb: So ghc -split-objs works now with either -optc-mcpu=v8 or -opta-mcpu=v9 (or even -opta-mcpu=ultrasparc). Where should I place what so that my stage1 inplace-compiler works without SplitObjs=NO in mk/build.mk? Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Two further questions: 1. Without SplitObjs=NO in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line? 2. Will the options given in SRC_HC_OPTS be burned into the final stage2 compiler or will I have to supply these options explicitely again? Thanks Christian P.S. building under solaris requires over 2GB memory (and takes a day) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 mac intel binary bundle
Here's what worked for me: bunzip2 ghc-6.6-i386-apple-darwin.tar.bz2 tar -xvf ghc-6.6-i386-apple-darwin.tar cd ghc-6.6 ./configure sudo make show-install-setup sudo make install ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 I'm on a MacBook Pro running OS X 10.4.8. The make show- install-setup step doesn't do anything but show you where the files will go when you do make install, but make install worked fine on my machine. -Rod On Oct 13, 2006, at 7:23 PM, Adam Megacz wrote: Hi, I'm grateful to whoever prepared the binary bundle for ghc-6.6 on MacOS/Intel, but the instructions for installing it are missing/wrong. In particular, make install doesn't do much, and the only binary in the bundle called ghc appears to need additional configuration options (-B), so it seems to need some sort of installation procedure. The INSTALL file is not useful. Overall, I'm kind of uncertain exactly what this tarball contains. It looks like a built copy of the source code, but most of the source code is missing. It's not an installer (.mpkg) nor does it (apparently) contain any install scripts. Could you perhaps update this webpage with an example of the shell commands you might use to get it installed to the point where typing ghc Foo.hs works? http://www.haskell.org/ghc/download_ghc_66.html#macosxintel Thanks, - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 ___ 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.6 mac intel binary bundle
On Oct 16, 2006, at 9:16 AM, Rodney D Price wrote: bunzip2 ghc-6.6-i386-apple-darwin.tar.bz2 tar -xvf ghc-6.6-i386-apple-darwin.tar These can be combined in one step: tar -xfvj ghc-6.6-i386-apple-darwin.tar.bz2 Deborah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 for Windows crashes my program on exit
Brian Hulley wrote: Hi, Has anyone else come across this crash with ghc 6.6 on Windows? The thread 'Win32 Thread' (0x5c8) has exited with code 0 (0x0). First-chance exception at 0x7c90eb74 in main.exe: 0xC008: An invalid HANDLE was specified. Unhandled exception at 0x7c90eb74 in main.exe: 0xC008: An invalid HANDLE was specified. Actually this behaviour happens even with the trivial program main = return () so I've submitted a bug report at http://hackage.haskell.org/trac/ghc/ticket/942 Best regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 mac intel binary bundle
On Oct 13, 2006, at 6:23 PM, Adam Megacz wrote: I'm grateful to whoever prepared the binary bundle for ghc-6.6 on MacOS/Intel, but the instructions for installing it are missing/wrong. In particular, make install doesn't do much, and the only binary in the bundle called ghc appears to need additional configuration options (-B), so it seems to need some sort of installation procedure. The INSTALL file is not useful. make install won't do much by itself because the target directories (/usr/local/*) are writable only by root; you need to use sudo. The following worked fine for me: ./configure make sudo make install I also edited the post-install-script to leave the system libreadline library (really libedit) alone, and only install GNU readline in /usr/ local/*. GHC still works fine with that configuration, and the original Mac OS X libreadline is left around. That way you can still build software that runs on a stock Mac OS X installation (instead of unintentionally introducing a dependency on GNU readline). You can do the same thing by commenting out the three lines in post- install-script that touch /usr/lib/libreadline and /usr/include/ readline/*. As far as I can tell they're not needed. However, if you're not concerned about this issue (e.g. you always require GNU readline for any software you build) you can leave the post-install- script as is, and GHC will work fine. Deborah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 mac intel binary bundle
Deborah Goldsmith [EMAIL PROTECTED] writes: ./configure make sudo make install Ok, sorry. When I noticed that there was no source code in the bundle, I didn't see the need for running configure/make. I have to admit, I still find it a bit strange... perhaps standard unix-style binary package ought to be precompiled source tree with the source code removed. Thanks for the help! - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 candidate Win32 installer
On 14.10 10:20, Ross Paterson wrote: On Fri, Oct 13, 2006 at 04:05:49PM -0700, Sigbjorn Finne wrote: Afraid I have to disappoint you (again :-( ) wrt OpenAL/ALUT. A bit too late, but _if_ there's a wider agreement that including a package such as this would be generally useful, I'd be happy to do something about it the next time around. cabal-get + hackage.haskell.org really ought to be the distribution channel for not-quite(-yet?)-mainstream packages though. That would be fine for pure Haskell packages (when hackage is ready), but Cabal can't handle packages that require non-trivial configuration (like OpenAL and ALUT) on Windows without MSYS. If people are interested I have NSIS scripts that make it trivial to create windows binary installers for many Haskell packages (for GHC). I would be interested in creating a repository of windows binary packages but I lack the space for hosting such a thing. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.6 for Windows crashes my program on exit
Hi, Has anyone else come across this crash with ghc 6.6 on Windows? The thread 'Win32 Thread' (0x5c8) has exited with code 0 (0x0). First-chance exception at 0x7c90eb74 in main.exe: 0xC008: An invalid HANDLE was specified. Unhandled exception at 0x7c90eb74 in main.exe: 0xC008: An invalid HANDLE was specified. The program has this form: main = do display_graphics_window_and_run_message_loop -- window has now been closed putStrLn Finished\n getChar and has been working perfectly with ghc 6.4.2. The only changes I had to make to compile it with ghc 6.6 were minor tweaks to deal with the changes to the ByteString api. When I run the ghc 6.6 compiled version, the window is displayed and works as usual, then when I dismiss the window, Finished is written to the console. It is only when I press return in the console that the program crashes on exit with that error message. I'm running the program from within MS Visual Studio (the graphics window is written as a C DLL that's called from Haskell). If I just run the program directly from the desktop the program exits silently . If I run the program from a command shell nothing unusual happens either: no error is printed out but the crash-on-exit is presumably still happening. From just looking at the error message, it looks to me like it might be that the rts exit code has somehow held onto the handle of the window's thread after this thread no longer exists, but of course this is only a wild guess. Alternatively, which file(s) in the ghc source distro would be the place to start looking to see what happens between the time the thread for the window has exited and the thread for main.exe exits? Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 candidate Win32 installer
Hi Einar, If people are interested I have NSIS scripts that make it trivial to create windows binary installers for many Haskell packages (for GHC). I am working on such a project myself for Haskell programs (haddock/alex etc) but not libraries. Can you give more details about your proposal, so I don't end up doing something already solved? My plan is to reuse the WinHugs installer for Yhc, WinHugs, Hat and Cabal generated programs (Haddock, Alex, Happy). I would be interested in creating a repository of windows binary packages but I lack the space for hosting such a thing. This is exactly the thing that haskell.org should be used for! Perhaps you might want to look at hackage as well, and see if you can integrate with that. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
Christian Maeder schrieb: I've created ghc-6.6 under solaris. This did only work with SplitObj=No in mk/build.mk. (There was an early split error, that I could reproduce.) Here is the output of that split error: ../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include Hs Base.h -funbox-strict-fields -package-name base-2.0 -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /tmp/ghc27221_0/ghc27221_0.split__1.s: Assembler messages: /tmp/ghc27221_0/ghc27221_0.split__1.s:22:0: Error: Architecture mismatch on blu,pt %icc,.LL7. /tmp/ghc27221_0/ghc27221_0.split__1.s:22:0: (Requires v9|v9a|v9b; requested architecture is v8.) /tmp/ghc27221_0/ghc27221_0.split__1.s:37:0: Error: Architecture mismatch on return. /tmp/ghc27221_0/ghc27221_0.split__1.s:37:0: (Requires v9|v9a|v9b; requested architecture is v8.) /tmp/ghc27221_0/ghc27221_0.split__1.s:52:0: Error: Architecture mismatch on return. /tmp/ghc27221_0/ghc27221_0.split__1.s:52:0: (Requires v9|v9a|v9b; requested architecture is v8.) ghc: 142018736 bytes, 17 GCs, 526892/1428536 avg/max bytes residency (3 samples), 19M in use, 0.00 INIT (0.00 elapsed), 1.94 MUT (8.03 elapsed), 0.23 GC (0.25 elapsed) :ghc gmake[2]: *** [GHC/Base.o] Error 1 gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/local/home/maeder/haskell/ghc-6.6/libraries' gmake: *** [stage1] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
On Fri, 2006-10-13 at 09:30 +0200, Christian Maeder wrote: Christian Maeder schrieb: I've created ghc-6.6 under solaris. This did only work with SplitObj=No in mk/build.mk. (There was an early split error, that I could reproduce.) Here is the output of that split error: ../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include Hs Base.h -funbox-strict-fields -package-name base-2.0 -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /tmp/ghc27221_0/ghc27221_0.split__1.s: Assembler messages: /tmp/ghc27221_0/ghc27221_0.split__1.s:22:0: Error: Architecture mismatch on blu,pt %icc,.LL7. /tmp/ghc27221_0/ghc27221_0.split__1.s:22:0: (Requires v9|v9a|v9b; requested architecture is v8.) When I've had similar error messages in the past on sparc linux it was because of a mismatch between the requested architecture when compiling and when assembling. For example if I were to do: ghc --make HelloWorld.hs -optc-mcpu=ultrasparc then ghc would call gcc to compile .c - .s with -mcpu=ultrasparc and so generate sparc V9 instructions. But when it came to assembling the .s file, we've not passed the abi flag via -opta so it defaults to the minimum abi. Then of course the assembler bumps into sparc V9 instructions but it had only been told to expect sparc V8 and so it complains. So I'd suggest building a test file with -split-objs and -v and see exactly what flags ghc is passing to gcc at the compilation and assembly stages. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
Duncan Coutts schrieb: ghc --make HelloWorld.hs -optc-mcpu=ultrasparc then ghc would call gcc to compile .c - .s with -mcpu=ultrasparc and so generate sparc V9 instructions. But when it came to assembling the .s file, we've not passed the abi flag via -opta so it defaults to the minimum abi. Then of course the assembler bumps into sparc V9 instructions but it had only been told to expect sparc V8 and so it complains. So I'd suggest building a test file with -split-objs and -v and see exactly what flags ghc is passing to gcc at the compilation and assembly stages. ok, my gcc is called with mcpu=v9. So ghc -split-objs works now with either -optc-mcpu=v8 or -opta-mcpu=v9 (or even -opta-mcpu=ultrasparc). Where should I place what so that my stage1 inplace-compiler works without SplitObjs=NO in mk/build.mk? Thanks Christian Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: /usr/local/pub-bkb/ghc/ghc-6.6/lib/ghc-6.6/package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: hello.hs Created temporary directory: /tmp/ghc25062_0 *** Haskell pre-processor: convert.sh hello.hs hello.hs /tmp/ghc25062_0/ghc25062_0.hspp Stable obj: [] Stable BCO: [] compile: input file /tmp/ghc25062_0/ghc25062_0.hspp *** Checking old interface for main:Main: [1 of 1] Compiling Main ( hello.hs, hello.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 10 *** Simplify: Result size = 8 *** Tidy Core: Result size = 8 *** CorePrep: Result size = 10 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** C Compiler: gcc -x c /tmp/ghc25062_0/ghc25062_0.hc -o /tmp/ghc25062_0/ghc25062_0.raw_s -mcpu=v9 -w -fno-strict-aliasing -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=606 -DUSE_SPLIT_MARKERS -I . -I /usr/local/pub-bkb/ghc/ghc-6.6/lib/ghc-6.6/include Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.0.3/configure --prefix=/usr/local/lang -program-suffix=_4.0.3_s10 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: posix gcc version 4.0.3 /export/local/mirror/sparc-solaris/lang/bin/../libexec/gcc/sparc-sun-solaris2.10/4.0.3/cc1 -quiet -v -I . -I /usr/local/pub-bkb/ghc/ghc-6.6/lib/ghc-6.6/include -iprefix /export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.10/4.0.3/ -D__sparcv8 -D__GLASGOW_HASKELL__=606 -DUSE_SPLIT_MARKERS /tmp/ghc25062_0/ghc25062_0.hc -quiet -dumpbase ghc25062_0.hc -mcpu=v9 -auxbase-strip /tmp/ghc25062_0/ghc25062_0.raw_s -O -Wimplicit -w -version -fno-strict-aliasing -o /tmp/ghc25062_0/ghc25062_0.raw_s ignoring nonexistent directory /export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.10/4.0.3/../../../../sparc-sun-solaris2.10/include ignoring duplicate directory /usr/local/lang/lib/gcc/sparc-sun-solaris2.10/4.0.3/include ignoring nonexistent directory /usr/local/lang/lib/gcc/sparc-sun-solaris2.10/4.0.3/../../../../sparc-sun-solaris2.10/include #include ... search starts here: #include ... search starts here: . /usr/local/pub-bkb/ghc/ghc-6.6/lib/ghc-6.6/include /export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.10/4.0.3/include /usr/local/include /usr/local/lang/include /usr/include End of search list. GNU C version 4.0.3 (sparc-sun-solaris2.10) compiled by GNU C version 4.0.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 *** Mangler: /usr/local/pub-bkb/ghc/ghc-6.6/lib/ghc-6.6/ghc-asm /tmp/ghc25062_0/ghc25062_0.raw_s /tmp/ghc25062_0/ghc25062_0.split_s *** Splitter: /usr/local/pub-bkb/ghc/ghc-6.6/lib/ghc-6.6/ghc-split /tmp/ghc25062_0/ghc25062_0.split_s /tmp/ghc25062_0/ghc25062_0.split /tmp/ghc25062_0/ghc25062_0.split *** Assembler: gcc -c -o hello_split/hello__1.o /tmp/ghc25062_0/ghc25062_0.split__1.s /tmp/ghc25062_0/ghc25062_0.split__1.s: Assembler messages: /tmp/ghc25062_0/ghc25062_0.split__1.s:30:0: Error: Architecture mismatch on blu,pn %icc,.LL2. /tmp/ghc25062_0/ghc25062_0.split__1.s:30:0: (Requires v9|v9a|v9b; requested architecture is v8.) /tmp/ghc25062_0/ghc25062_0.split__1.s:34:0: Error: Architecture mismatch on bgu,pt %icc,.LL2. /tmp/ghc25062_0/ghc25062_0.split__1.s:34:0: (Requires v9|v9a|v9b; requested architecture is v8.) /tmp/ghc25062_0/ghc25062_0.split__1.s:63:0: Error: Architecture mismatch on return. /tmp/ghc25062_0/ghc25062_0.split__1.s:63:0: (Requires v9|v9a|v9b; requested architecture is v8.) *** Deleting temp files: Deleting: /tmp/ghc25062_0/ghc25062_0.split__4.s /tmp/ghc25062_0/ghc25062_0.split__3.s /tmp/ghc25062_0/ghc25062_0.split__2.s /tmp/ghc25062_0/ghc25062_0
Re: ghc-6.6 candidate Win32 installer
Hi Sigjorn, On Thu, 12 Oct 2006 08:37:11 +0900, Sigbjorn Finne [EMAIL PROTECTED] wrote: for Win32 users wanting the latest GHC goodness, a candidate 6.6 installer is now available, http://haskell.org/ghc/dist/6.6/ghc-6-6.msi If anyone's willing to download it and kick the tires a bit, that'd be great. If nothing too egregious shows up, I'm planning to publish sometime tomorrow. Why this build doen't include some packages? It lacks some packages that were included 6.4.2. It doen't include GLUT and readline. I think you forgot copying header and library files to mingw directory. These filed are included in GHC 6.4.2's directory. And you can include OpenAL and ALUT package by these steps. 1. Download reealut Source ZIP, unpack it. 2. Copy AL header file directory that is under include direcoty. (Copy AL direcoty to mingw's include direcoty, doen't copy AL direcoty header file. Because packages' configure.ac search header files in AL/* or OpenAL/*.) 3. Generate libalut.a from alut.dll in lib direcoty, and copy libalut.a to mingw's lib directory. 4. Download OpenAL 1.1 SDK and install it. (OpenAL SDK installer says that you want to install runtime? You must click to answer Yes.) 5. Copy header files directory to mingw's AL direcotry. It is made by 1.. Header files is in OpenAL SDK's directory. (Default is C:\\Program Files\\OpenAL 1.1 SDK\\include .) 6. Generate lib*.a files from OpenAL32.dll and wrap_oal.dll. Then copy mingw's lib direcoty. DLL files are in WINNT\\system files directory. 4-6' Altanative option to use OpenAL library is building OpenAL library by source. And then copy your lib*.a and header files. I usually generate lib*.a from a.dll by pexport and dlltool following this document way. http://sebsauvage.net/python/mingw.html Now GHC 6.6 is released. So this is the good time to include OpenAL and ALUT packages in complete installer packages. (Other name is sumo/omnibus/ ... and so on.) http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg10655.html If there is no option to use minimal and complete installer, people expect that package is complete one. And some people want to use complete package exactly. (And caball-install doesn't available now, too.) So I think these tack are very recommended. -- shelarcy shelarcycapella.freemail.ne.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 candidate Win32 installer
Hi, I forgot to link OpenAL's site. http://www.openal.org/ On Thu, 12 Oct 2006 15:40:07 +0900, shelarcy [EMAIL PROTECTED] wrote: And you can include OpenAL and ALUT package by these steps. 1. Download reealut Source ZIP, unpack it. Not reealut. I want to write freealut. 2. Copy AL header file directory that is under include direcoty. (Copy AL direcoty to mingw's include direcoty, doen't copy AL direcoty header file. Because packages' configure.ac search header files in AL/* or OpenAL/*.) 3. Generate libalut.a from alut.dll in lib direcoty, and copy libalut.a to mingw's lib directory. 4. Download OpenAL 1.1 SDK and install it. (OpenAL SDK installer says that you want to install runtime? You must click to answer Yes.) 5. Copy header files directory to mingw's AL direcotry. It is made by 1.. Header files is in OpenAL SDK's directory. (Default is C:\\Program Files\\OpenAL 1.1 SDK\\include .) 6. Generate lib*.a files from OpenAL32.dll and wrap_oal.dll. Then copy mingw's lib direcoty. DLL files are in WINNT\\system files directory. 4-6' Altanative option to use OpenAL library is building OpenAL library by source. And then copy your lib*.a and header files. I usually generate lib*.a from a.dll by pexport and dlltool following this document way. http://sebsauvage.net/python/mingw.html Best Regards, -- shelarcy shelarcycapella.freemail.ne.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6 under solaris
I've created ghc-6.6 under solaris. This did only work with SplitObj=No
in mk/build.mk. (There was an early split error, that I could reproduce.)
When trying out this compiler, I got the following error (that I only
post for the record):
Cheers Christian
[410 of 642] Compiling Proofs.HideTheoremShift (
Proofs/HideTheoremShift.hs, Proofs/HideTheoremShift.o )
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for sparc-sun-solaris2):
lookupDeprec main:GUI.ConsoleUtils.listBox{v r36Wf}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
gmake: *** [hets] Error 1
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
On Thu, 2006-10-12 at 15:28 +0200, Christian Maeder wrote:
I've created ghc-6.6 under solaris. This did only work with SplitObj=No
in mk/build.mk. (There was an early split error, that I could reproduce.)
When trying out this compiler, I got the following error (that I only
post for the record):
Cheers Christian
[410 of 642] Compiling Proofs.HideTheoremShift (
Proofs/HideTheoremShift.hs, Proofs/HideTheoremShift.o )
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for sparc-sun-solaris2):
lookupDeprec main:GUI.ConsoleUtils.listBox{v r36Wf}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Are you using sparc solaris or x86 solaris?
I've so far been unable to get ghc-6.5 working on sparc linux, at least
not a registerised build. The build works fine but then the resulting
ghc fails on startup with an error about the scheduler being re-entered
unsafely. I don't have the exact error message to hand right now.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
Duncan Coutts schrieb:
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for sparc-sun-solaris2):
lookupDeprec main:GUI.ConsoleUtils.listBox{v r36Wf}
Are you using sparc solaris or x86 solaris?
sparc
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
On Thu, Oct 12, 2006 at 03:28:37PM +0200, Christian Maeder wrote:
I've created ghc-6.6 under solaris.
[410 of 642] Compiling Proofs.HideTheoremShift (
Proofs/HideTheoremShift.hs, Proofs/HideTheoremShift.o )
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for sparc-sun-solaris2):
lookupDeprec main:GUI.ConsoleUtils.listBox{v r36Wf}
Do you know whether or not this compiles OK on other platforms with GHC
6.6?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
Ian Lynagh schrieb:
On Thu, Oct 12, 2006 at 03:28:37PM +0200, Christian Maeder wrote:
I've created ghc-6.6 under solaris.
[410 of 642] Compiling Proofs.HideTheoremShift (
Proofs/HideTheoremShift.hs, Proofs/HideTheoremShift.o )
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for sparc-sun-solaris2):
lookupDeprec main:GUI.ConsoleUtils.listBox{v r36Wf}
Do you know whether or not this compiles OK on other platforms with GHC
6.6?
The above error must be a recompilation problem that I could not
reproduce. After compiling all 642 sources from scratch this error
disappeared. However under linux and mac OS this error did not turn up
so far.
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6 candidate Win32 installer
Hi, for Win32 users wanting the latest GHC goodness, a candidate 6.6 installer is now available, http://haskell.org/ghc/dist/6.6/ghc-6-6.msi If anyone's willing to download it and kick the tires a bit, that'd be great. If nothing too egregious shows up, I'm planning to publish sometime tomorrow. thx --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
