Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)
On Fri, Oct 22, 2010 at 9:35 AM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Bit Connor wrote: On Sat, Oct 16, 2010 at 10:29 AM, Claus Reinke claus.rei...@talk21.com wrote: After it catches this error, the function returns (line 376): return (fail (show e)) The fail is running in the Either monad (The Result type = Either). This calls the default Monad implementation of fail, which is just a call to plain old error. This basically causes the entire program to crash. Actually, it appears that simpleHTTP isn't actually supposed to throw an IOException, and it is instead supposed to return a ConnError result. So the real fix is to fix the code to make this happen. But Sounds like a victim of http://hackage.haskell.org/trac/ghc/ticket/4159 For mtl clients, 'fail' for 'Either' used to call 'Left'. That was changed, though the ticket does not indicate the library versions affected. This looks like the problem. Any idea how to get the HTTP package fixed? I could try making a patch myself, but I would prefer hearing from the HTTP maintainer first, who doesn't seem to be around. I've tried contacting him a few times about getting the base dependencies in HTTP bumped and an upload made, without success. This is a widely used package that's in the platform and that won't work with GHC 7.0 with the current dependencies, so it really needs to get fixed soon. libraries@, what's the right way to proceed? Can I make a Debian-style non-maintainer upload with minimal changes to fix urgent issues like these? I'd be much obliged if you could, and I do apologise for leaving all of this just hanging. No time available for Haskell projects these days unfortunately, Opera engine development taking up most of my waking hours. Getting someone to take over HTTP would be best, or maybe rewrite it altogether..it is not the prettiest thing around :) --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] memory management
Hi, staying in the realm of the explicit and pragmatic, various libraries in Haskell do provide safeexplicit region/alloca/stack allocation actions, e.g., Foreign.Marshal.Alloc.allocaBytes :: Int - (Ptr a - IO b) - IO b with the promise that the pointer doesn't escape here (you could constrain this using the type system, if you so wish..) I don't know if the GHC RTS still(?) provides hooks for allocating alloca objects specially. There's been some work on monadic regions too; worth looking at. hth --sigbjorn On 8/4/2009 15:49, Simon Marlow wrote: On 04/08/2009 13:33, Sam Martin wrote: Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) Thanks, yes, that's exactly what I had in mind. Is anything like this is done in GHC? Not at the moment, no. Bear in mind that with generational GC, allocating memory that quickly becomes garbage is quite cheap. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] GHCI Curl under Windows
On Wed, 03 Jun 2009 05:27:53 -0700, Martin Huschenbett hus...@gmx.org wrote: Hi Haskellers, I've installed the newest Haskell Platform under Vista and downloaded a pre compiled version of curl-7.19.4 for MinGW. After changing the build type in curl.cabal to Simple and supplying the needed paths I could even build and install curl for haskell. If I write a program using curl and compile it with GHC everything works fine. But if I try to execute the main function of my program in GHCI I always get the following error message: Loading package curl-1.3.5 ... linking ... interactive: C:\Devel\Haskell\curl-1.3.5\ghc-6.10.3\HScurl-1.3.5.o: unknown symbol `__imp__curl_easy_getinfo': unable to load package `curl-1.3.5' Did anybody have the same problem and knows how to fix it? Hi Martin, perhaps you already have, but did you go through this writeup http://haskell.forkio.com/Home/curl-win32 and see if there are useful pointers there that might help? --sigbjorn -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Simon Marlow wrote: On 29/04/2009 01:23, Sigbjorn Finne wrote: Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit -lgcc -lc trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. I've now done exactly that. This seems like a good fix to try to get into 6.10.4 - can you think of any unexpected consequences? Cool, given that the RTS already has those two DLLs loaded repeated addDLL()s is fine (i.e., if other packages contain e.g., kernel32 uses), I can't think of any...other than possibly more contribs from people building on Windows ;-) If you feel the risk is not worth taking for 6.10.4, I'm totally fine with pushing it out. thanks, --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit -lgcc -lc trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. --sigbjorn On 4/27/2009 04:58, Simon Marlow wrote: On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code with some further poking around I've been able to determine that it is the explicit presence of -l options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was don't do that (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect gcc foo.c -lmsvcrt to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Compiling on windows - again
-optl-mwindows is the magic incantation to use. --sigbjorn On 4/28/2009 17:37, Gü?nther Schmidt wrote: Hi guys, I'm sorry, I asked this before ... What is the flag you have to pass during ghc --make in order to produce an exe on Windows that doesn't open a DOS window. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: 6.10.3 plans
Simon Marlow wrote: On 27/04/2009 01:28, Sigbjorn Finne wrote: ... As a compromise, how about expanding the runtime error message to make it clear that this is a change in 6.10.2? finalizer: error: a C finalizer called back into Haskell. This was previously allowed, but is disallowed in GHC 6.10.2 and later. To create finalizers that may call back into Haskll, use Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr. That's definitely helpful; I'm all for it. Hope there's time available to put it in. cheers --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10.3 plans
On 4/25/2009 07:16, Ian Lynagh wrote:
On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:
We do have a WARNING pragma, incedentally:
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma
I don't think that using it for this would be a good idea, though. It
would mean that people who really do want
Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer}
would not be able to write warning-free code.
Repeating myself, I suppose :) , but I would be happy to take that hit
for 6.10.3 if it avoids other GHC users from spending unproductive
time getting on top of this change. ymmv.
--sigbjorn
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ANN: Bamse-0.9.4, a Windows Installer generator
Hi, various people have over the years suggested and tried using WiX from Haskell, so I'll leave it to them to comment possibly compare the two. I'm sure it blows Bamse out of the water as far as functionality goes. --sigbjorn On 4/26/2009 11:00, Justin Bailey wrote: How does this compare to WiX? I haven't looked at the docs yet ... On Sat, Apr 25, 2009 at 4:59 PM, Sigbjorn Finne sigbjorn.fi...@gmail.com wrote: Hi, a new version of Bamse has been uploaded to hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse Bamse is a package and application for letting you quickly put together Windows Installers for your software projects/products from within the comforts of Haskell. New in this release is the support for generating MSIs from your Cabal projects, having them either be built from source or just have them be installed and registered at install-time. i.e., one-click installation of Cabal packages. See examples/Cabal.hs for a worked example of how to bundle up Cabal packages. I've found this functionality a bit useful, hope others do too. The new version also adds support for handling .NET assemblies. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 4/25/2009 05:37, Ian Lynagh wrote: Hi Sigbjorn, On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. By new build system do you mean http://darcs.haskell.org/ghc-new-build-system/ ? Hi Ian, young and old. The above one + ones using the older (git darcs versions) The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. Do you mean that building GHC fails, or that building other things using the built GHC fails? If the latter, can you give a testcase please? Right, when building the repo contents. Any .hsc that's in the tree elicits a hard crash (i.e., dialog box pops up reporting the failure of any *_hsc_make.exe ) This is when building with 6.10.1, but that's not the real cause here. If I don't take the evasive action (as outlined in the original e-mail), the resulting stage1/stage2 ghc installs will fail also (provided I've manually guided the build process past these crashes to reach completion first, of course.) hth --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Oh, and a simple test case:
foo$ cat a.c
int main() { return 0; }
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32 -lmsvcrt
foo$ ./a ; echo $?
crash-reporting dialog box shows up
5
foo$
--sigbjorn
On 4/25/2009 11:38, Sigbjorn Finne wrote:
On 4/25/2009 05:37, Ian Lynagh wrote:
Hi Sigbjorn,
On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote:
I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system.
By new build system do you mean
http://darcs.haskell.org/ghc-new-build-system/
?
Hi Ian,
young and old. The above one + ones using the older (git darcs
versions)
The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when
compiled and linked via the 'ghc' that's configured against, will
produce
.exe's that crashes right out of the gates.
Do you mean that building GHC fails, or that building other things using
the built GHC fails? If the latter, can you give a testcase please?
Right, when building the repo contents. Any .hsc that's in the tree
elicits a hard crash (i.e.,
dialog box pops up reporting the failure of any *_hsc_make.exe ) This
is when building with
6.10.1, but that's not the real cause here.
If I don't take the evasive action (as outlined in the original
e-mail), the resulting stage1/stage2
ghc installs will fail also (provided I've manually guided the build
process past these crashes
to reach completion first, of course.)
hth
--sigbjorn
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] ANN: Bamse-0.9.4, a Windows Installer generator
Hi, a new version of Bamse has been uploaded to hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse Bamse is a package and application for letting you quickly put together Windows Installers for your software projects/products from within the comforts of Haskell. New in this release is the support for generating MSIs from your Cabal projects, having them either be built from source or just have them be installed and registered at install-time. i.e., one-click installation of Cabal packages. See examples/Cabal.hs for a worked example of how to bundle up Cabal packages. I've found this functionality a bit useful, hope others do too. The new version also adds support for handling .NET assemblies. enjoy --sigbjorn ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANN: Bamse-0.9.4, a Windows Installer generator
Hi, a new version of Bamse has been uploaded to hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse Bamse is a package and application for letting you quickly put together Windows Installers for your software projects/products from within the comforts of Haskell. New in this release is the support for generating MSIs from your Cabal projects, having them either be built from source or just have them be installed and registered at install-time. i.e., one-click installation of Cabal packages. See examples/Cabal.hs for a worked example of how to bundle up Cabal packages. I've found this functionality a bit useful, hope others do too. The new version also adds support for handling .NET assemblies. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Hi, I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code with some further poking around I've been able to determine that it is the explicit presence of -l options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. thanks --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.10.3 plans
On 4/23/2009 02:05, Duncan Coutts wrote:
On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote:
Hi Ian,
thanks for the update on plans and the willingness to jump in and do another
release cycle so soon after 6.10.2. The suggested fixes seem agreeable to
me, but I have one _minor_ additional request for 6.10.3 if you end having
to rebuild 'base' -- add a DEPRECATED (or some such) to
Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate
that the operational behaviour of these have changed.
Small change, but could be helpful to package usersauthors when migrating
beyond 6.10.1
I agree that it's a little unfortunate that this change is in a minor
release.
I'm not sure what can be done as far as automatic messages go however.
The notice about the change is in the release notes. The functions are
not deprecated (they're part of the FFI spec).
Sorry, didn't mean to imply that they were. Just offered it as a
pragmatic solution to deliver
extra help to folks without spending the dev. time to implement a more
appropriate pragma
like WARNING/INFO. If such a thing already existed...
--sigbjorn
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10.3 plans
Hi Ian,
thanks for the update on plans and the willingness to jump in and do another
release cycle so soon after 6.10.2. The suggested fixes seem agreeable to
me, but I have one _minor_ additional request for 6.10.3 if you end having
to rebuild 'base' -- add a DEPRECATED (or some such) to
Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate
that the operational behaviour of these have changed.
Small change, but could be helpful to package usersauthors when migrating
beyond 6.10.1
thanks
--sigbjorn
On 4/22/2009 16:56, Ian Lynagh wrote:
Hi all,
Due to some problems with the handling of ^C in ghci, we are planning to
do a 6.10.3 release.
The idea is that, rather than being a full-blown release process,
including all the various fixes that have been made since 6.10.2, we
will only do what is necessary to resolve the ^C issue. By keeping the
changes to a minimum, we will minimise the amount of testing,
release-note writing, etc that is necessary.
An exception to this rule is that we will probably also rebundle time in
the bindists, as that has little chance of breaking anything else.
There are actually two problems with ^C. One is due to the changes in
the signal handling in ghci, and we will fix that. The other is that, on
some platforms (including x86/Linux), the interaction between editline
and GHC means that pressing ^C causes a segfault. Given all the other
issues that people have had with editline, we plan to use haskeline in
6.10.3 instead. We already planned to do this for 6.12, but we think
that it makes sense to do it sooner rather than later. The plan is:
* Add haskeline and deps as boot packages
* Move the interactive modules from the ghc package to the ghc-bin
package. This means that the ghc package will not depend on the new
boot packages, so there will not be any problems with upgrading them.
Any comments?
Thanks
Ian
___
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: [Haskell-cafe] haxr build failure from cabal
Hi Jeff, I have an updated and _seemingly_ working version of the haxr codebase, but haven't had a chance to test it more than a gentle poke at the tires. Will see if I can upload commit the bits. --sigbjorn On 4/22/2009 07:37, Jeff Heard wrote: haxr will no longer compile from cabal because of the dependency marked HTTP 1.0. The current version of the library requires HTTP 4000.0.0 as it stands. Can it be updated real quick in hackage? -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haxr build failure from cabal
OK, new release of haxr available via hackage; compilable with ghc-6.10.1 (but may very well have bootstrap issues with 6.10.2 due to 'time' dependency) http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haxr enjoy --sigbjorn Sigbjorn Finne wrote: Hi Jeff, I have an updated and _seemingly_ working version of the haxr codebase, but haven't had a chance to test it more than a gentle poke at the tires. Will see if I can upload commit the bits. --sigbjorn On 4/22/2009 07:37, Jeff Heard wrote: haxr will no longer compile from cabal because of the dependency marked HTTP 1.0. The current version of the library requires HTTP 4000.0.0 as it stands. Can it be updated real quick in hackage? -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Using FFI for .NET
Hi Guilherme,
the support for 'dotnet' FFI declarations isn't really there any longer,
having bitrotted badly and hasn't been in use for a number of years.
(I'd suggest removing the final vestiges of them from the codebase,
actually.)
You may want to have a look at http://haskell.forkIO.com/dotnet/
instead.
--sigbjorn
On 4/21/2009 18:56, Guilherme Oliveira wrote:
Hi guys,
I'm new to haskell and I'm trying to make some calls to static methods
of the Microsoft .NET framework with GHC 6.10.2 but I'm getting the
follwoing error:
GHC error in desugarer lookup in main:Main:
Failed to load interface for `GHC.Dotnet':
There are files missing in the `base' package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-unknown-mingw32):
initDs IOEnv failure
My haskell code is this:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Prelude
import Foreign
foreign import dotnet static foo foo :: Int - Int
main = do print (foo 5)
To build the code above I'm doing like this: ghc -fvia-C Main.hs
Am I forgeting something? Does this version of GHC supports FFI for .NET?
Regards,
Guilherme Oliveira
MSc Student, UFPE - Brazil
___
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
[Haskell-cafe] ANN: HTTP-4000.0.6
Hi, a refresh release of the HTTP package has been uploaded to Hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP Robust handling of ill-formed cookies + squash a bug in normalization of certain proxy-bound requests would be the (minor) headlines of this release. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: curl-1.3.5
Hi, a refresh release of the Haskell (lib)curl package has been uploaded to Hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl It enables 6.10.2 use, taking into account the updated story on how to register Haskell-based finalizers. Thanks to Carl Howells for reporting this problem. Bug reports / feature requests etc. most welcome, btw. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Announce: A pragmatic Haskell .NET interop layer, 0.4.0
A new version of a Haskell .NET interop layer, hs-dotnet, has just been released and is now available for download, http://haskell.forkIO.com/dotnet It lets you access .NET functionality from Haskell and vice versa. Tool support is included in this release to aid such interop. The new version includes development done since the start of the year. Apart from rewriting the internals completely to put it all on a sounder footing, this release includes proper support for .NET generic types (classes and interfaces), mapping them naturally on to Haskell parameterized types. The support for generics enables for instance mixed Haskell-.NET LINQ programming; see the distribution for examples of this along with some other interesting applications of the hs-dotnet interop layer. enjoy --sigbjorn ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Announce: A pragmatic Haskell .NET interop layer, 0.4.0
A new version of a Haskell .NET interop layer, hs-dotnet, has just been released and is now available for download, http://haskell.forkIO.com/dotnet It lets you access .NET functionality from Haskell and vice versa. Tool support is included in this release to aid such interop. The new version includes development done since the start of the year. Apart from rewriting the internals completely to put it all on a sounder footing, this release includes proper support for .NET generic types (classes and interfaces), mapping them naturally on to Haskell parameterized types. The support for generics enables for instance mixed Haskell-.NET LINQ programming; see the distribution for examples of this along with some other interesting applications of the hs-dotnet interop layer. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: new release of HTTP, version 4000.0.5
Hi, a new version of the HTTP package - 4000.0.5 has been uploaded, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP Includes a bunch of fixes and cleanups (thanks to all that have reportedcontributed), along with some (shock, horror) API documentation. Let me know if it appears to be well behaved and dependable. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haxr doesn't compile from cabal (HTTP 4000 breaks it)
On 3/12/2009 07:51, Jeff Heard wrote: The haxr cabal library dependencies seem to be off. I wonder, since haxr would benefit highly from the HTTP 4k series of performance improvements, is it trivial to make it compatible with the latest library? Hi Jeff, the required changes shouldn't be pervasive nor hard, but if it turns out non-trivial or unappealing in any way, please get in touch. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help on using System.Win32.Com.Automation
Hi Wilkes,
you may want to have a look at a simple example of how to
interop with Windows WMI using the COM package at --
http://haskell.forkio.com/com-examples
Hope it is of some help to you.
--sigbjorn
On 3/19/2009 16:49, Wilkes Joiner wrote:
I'm playing around with the com package, but I'm having a hard time
understanding how to map a COM call to the appropriate methodN or
functionN call. Does anyone have any example code that uses the
method1 or higher. Any help or pointers would be appreciated.
Here's the code I have so far:
import System.Win32.Com
import System.Win32.Com.Automation
dsn = Provider=vfpoledb.1;Data Source=C:\\SomeDirectory\\
main = coInitialize
openConnection = \con -
closeConnection con
openDSN :: String - IDispatch a - IO ()
openDSN dsn con = method0 Open [inString dsn] con
openConnection :: IO (IDispatch a)
openConnection = createObject ADODB.Connection = \con - openDSN
dsn con return con
closeConnection :: IDispatch a - IO ()
closeConnection = method0 Close []
{-
Wraps ADO Connection.Execute
http://msdn.microsoft.com/en-us/library/ms675023(VS.85).aspx
Set recordset = connection.Execute (CommandText, RecordsAffected, Options)
execute :: String - IDispatch a - IO a
execute cmd con = method1 Execute [inString cmd] (inEmpty,resWord64) con
-}
Thank You,
Wilkes
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help on using System.Win32.Com.Automation
Alexandr N. Zamaraev wrote: Sigbjorn Finne wrote: Hi Wilkes, you may want to have a look at a simple example of how to interop with Windows WMI using the COM package at -- http://haskell.forkio.com/com-examples I try compile WMIDemo.hs but recive error: [code] c:\htestghc --make WMIDemo.hs [2 of 2] Compiling WMIDemo ( WMIDemo.hs, WMIDemo.o ) WMIDemo.hs:24:2: Couldn't match expected type `[a]' against inferred type `(a1, b)' ... Hi, please upgrade to the latest version - 1.2.2 - of the com package for this example, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/com There's been some improvements to the lib, esp. the handling of enumerations (which is where that type error is coming from.) hth --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] curl w/ ghc-win32
Hi, there's a steady stream of people reporting that getting started with curl on Windows is cumbersome and tricky to get right. A legitimate complaint! :-) To hopefully help out a bit in that regard, I've put together some notes covering the steps reqd + made available a pre-packaged curl binary dist -- http://haskell.forkio.com/Home/curl-win32 enjoy.. :) --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Building GHC on Windows
Simon Marlow wrote: Felix Martini wrote: . All this is likely trivial to fix but at the same time these little roadblocks may also explain why few developers on Windows contribute code to GHC and Haskell. I haven't tried sync-all on Windows - can anyone help out here? It works fine, but be mindful of how 'git' handles crlf translations on Windows. Having run into this a couple of times, it certainly looks the likely cause. Felix may want to try cloning as follows: foo$ git config --global core.autocrlf false foo$ git clone http://darcs.haskell.org/ghc.git hth --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building GHC on Windows
Felix Martini wrote: Sigbjorn Finne: It works fine, but be mindful of how 'git' handles crlf translations on Windows. Having run into this a couple of times, it certainly looks the likely cause. Felix may want to try cloning as follows: foo$ git config --global core.autocrlf false foo$ git clone http://darcs.haskell.org/ghc.git Unfortunately i cannot change the global autocrlf flag because of other projects. I edited the sync-all script to fix the problem, but is good to know that line conversions may be the cause. It would be nice if sync-all (and other scripts) were written in portable Perl. Perl runs well on Windows whereas msys is brittle. ok. Surely you could just temporarily set it as such, followed by config'ing it for that repo only rather than have it be global? I suspect tweaking that one file instead will just be the first of many such tweaks.. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and HsFFI.h
Hi Ian, it may encompass some of your suggested approaches below, but have you considered either: - add --print-hsc-options to the GHC driver, which is akin to --print-libdir. A ghc-installed hsc2hs shell wrapper or as you suggest have 'hsc2hs' probe the compiler it is using would then build on this. - have the GHC driver handle .hsc input by invoking 'hsc2hs' with the necessary local context. I can see the value of not doing the latter (it already handles too many kinds of input files) and would add to GHC's workload. But thought I'd put it on the table at least.. Q: is the information that --print-libdir returns available programmatically to Haskell code? --sigbjorn Ian Lynagh wrote: Hi all, Currently, hsc2hs (as shipped with GHC) cannot be used with just hsc2hs Foo.hsc as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897). To make it work you need to run something like hsc2hs -I /usr/lib/ghc-6.10.1/include Foo.hsc (it also works when called by Cabal, as Cabal passes it this flag automatically). However, we would like to have it work without needing to use any special flags, and without having to use it from within a Cabal package. The obvious solution to this problem would seem to be to put HsFFI.h in /usr/lib/hsc2hs/include and have hsc2hs automatically add that to the include path. However, hsc2hs is supposed to be a compiler-independent tool, and HsFFI.h isn't a compiler-independent header file; for example, GHC's implementation defines HsInt to be a 64-bit integer type on amd64, whereas hugs's implementation defines it to be a 32-bit type. We therefore need a different HsFFI.h depending on which compiler we are using. One option would be to have hsc2hs (when installed with GHC) append -I /usr/lib/ghc-6.10.1/include to the commandline. If the user gives a -I /usr/lib/hugs/include flag then this path will be looked at first, and the hugs HsFFI.h will be used. Another option would be for the user to tell hsc2hs which compiler they're using, e.g. hsc2hs --compiler=/usr/bin/ghc Foo.hsc (this compiler is distinct from the C compiler that hsc2hs will use). hsc2hs will then pass the appropriate -I flag, depending on what sort of compiler it is told to use. The hsc2hs that comes with GHC would probably default to using the GHC that it is installed with, but standalone hsc2hs would probably default to searching for /usr/bin/ghc, /usr/bin/hugs, etc. This last approach would also make it possible for hsc2hs to take -package foo flags, and add the include paths for the requested packages too. The downside is that it's pushing a lot more knowledge into hsc2hs, which means there is one more thing to keep in sync. Has anyone got any other alternatives to consider? Or opinions on which solution is best? Thanks Ian ___ 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: [Haskell-cafe] Error in HTTP 4.004 + CouchDB?
Thanks Alex,
contacting the maintainer of a package rather than author is probably
the best course of action in general. They may both be out of date,
but the former maybe less so. :)
As verified offline, you issue this request via sendHTTP when experiencing
this misbehavior.
A couple of suggestions on what to do:
* Use Network.Browser instead and send it via (browse $ request req),
which will normalize the path and Host: headers as you expect for
(non-proxy)
use.
* pull down the latest bits from the repository and normalize your request
prior to calling sendHTTP by using
(Network.HTTP.Base.normalizeRequest False{-no proxy-} req)
(we're in a tight spot wrt. backwards compatibility for sendHTTP, so
having
it perform this normalization step by default would break code that
now interacts
with proxies via sendHTTP.)
The repository version also has support for custom request verbs, which
might be
of interestuse to some.
Let me know how it goes -- git repository URL available via
http://projects.haskell.org/http/
hth
--sigbjorn
On 1/22/2009 11:32, Alex Ott wrote:
Hello
(i sent this message to the mail of author, specified at hackage, but it
returned to me, so i decided to resend it here)
I found strange thing during work with latest versions of CouchDB HTTP
module on my Mac OS X 10.4. The problem is, that when i send document to
the couchdb server, it name was cut to the 2 characters.
After some investigation i found, that this is problem in combination of
the CouchDB + HTTP usage. CouchDB module fills out the Request structure,
and specify scheme authority fields. This lead that i see (in network
dumps) following data:
I tried to fix this problem myself, but I'm novice in the industrial
Haskell programming ;-)
P.S. this code from (CouchDB/HTTP.hs) will restore proper behaviour of the
code, but break Host header
makeURL path query = CouchMonad $ \conn - do
return ( (ccURI conn) { uriPath = '/':path
, uriQuery = if null query then else
'?':(urlEncodeVars query)
, uriScheme =
, uriAuthority = Nothing
}
,conn )
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available
On 1/17/2009 08:21, Tim Newsham wrote: There's however still no framework which supports both HTTP client and server functions using the same Request and Response data type, right? I don't know whether I am the only one who needs this (e.g. for the Real Monad Transformer). E.g. a proxy would need this, too. I've wanted this for a while now. Me Too. Tim Newsham http://www.thenewsh.com/~newsham/ There's the basic receiveHTTP and respondHTTP that Network.HTTP.Stream Network.HTTP.HandleStream exports. But that is probably not enough for your uses, I suspect. To ensure that this feature request isn't dropped or forgotten about, please add a ticket for it via the (new-homed) HTTP web pages -- http://projects.haskell.org/http/ Or, better still :-), contribute the code...to HTTP or some existing web server framework. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: HTTP-4000.0.4 released
Hi, a new release of HTTP, version 4000.0.4, is now available http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP It is also pointed at via the updated HTTP web page -- http://projects.haskell.org/http/ The main change is the addition of registering a Browser event handler for capturing state changes to the request-response processing pipeline. An experimental change, see Network.Browser.setEventHandler (Feature suggested by Yuval Kogman in order to accommodate load testing.) enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANN: curl-1.3.4
Hi, a new version 'curl', a complete Haskell binding to the libcurl API, is now available and have been uploaded to Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl Git repo at git://code.galois.com/curl.git Appended is the list of changes since the previous release. Most notable is the overloading of representation of response buffers (and headers), allowing for the use of ByteStrings. Speedups might be had as a result... enjoy --sigbjorn Version 1.3.4: released 2009-01-18; changes from 1.3.3 * Overloaded Network.Curl operations over response representation of payloads and headers. Controlled via CurlBuffer and CurlHeader classes. New actions: - curlGetString_, curlGetResponse_, perform_with_response_, do_curl_, curlHead_ * Provided ByteString instances (strict and lazy) * No modification in calling interface to existing exports, so backwards compatible. * Added Show instance for Network.Curl.Opts.CurlOption * curl_version_string, curl_version_number now gives you access to version info of underlying lib you _compiled_ the package with. * Sync'ed wrt libcurl-7.19.2, so bunch of new options added to Network.Curl.Opts. Use version functions to determine if they are supported though. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Slow Text.JSON parser
Maybe. Handling the common cases reasonably well is probably worth doing first (+profiling) before opting for a heartlung transplant.. To wit, I've trivially improved the handling of string and integer lits in version 0.4.3 (just released.) It cuts down the running times by a factor of 2-3 on larger inputs -- http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json Not saying that there aren't additional wins to be had :) hth --sigbjorn On 1/17/2009 14:50, Don Stewart wrote: It occurs to me you could also use attoparsec, which is specifically optimised for bytestring processing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available
Thanks Jeff, regarding having to use both HTTP and cURL -- or perhaps only the latter for code simplicitly -- that will probably remain the case for quite a while still. To help with that situation, I put together an over-arching 'webclient' library that abstracts over the transport layers (HTTP, curl, curl-shell) giving you an API that's consistent across backends. I could release that at some point if there's sufficient interest.. It also adds WebDAV support. Re: curl - as an author of the 'curl' package, I'm also keen on finding ways of making that better -- both in terms of using the underlying lib functionality and API on the Haskell side. Suggestions/contribs most welcome. Ditto for HTTP too, of course :) --sigbjorn On 1/16/2009 05:47, Jeff Heard wrote: Just as a reported speedup, downloading a 5MB file from my own local machine (via http) went from 1.05 secs to 0.053 secs. Yes, it's really an order of magnitude better. Performance now is on par or slightly better than cURL (however to get more protocols than HTTP, you'll still need the ubiquitous cURL library) On Fri, Jan 16, 2009 at 1:36 AM, Sigbjorn Finne sigbjorn.fi...@gmail.com wrote: Hi, I guess it's time to publish more widely the availability of a modernization of the venerable and trusted HTTP package, which I've been working on offon for a while. Bunch of changes, but the headline new feature of this new version is the parameterization of the representation of payloads in both HTTP requests and responses. Two new representations are supported, strict and lazy ByteStrings. Some people have reported quietly pleasing speedups as a result of this change. (If they want to report numbers, please do..) Another change/fix in this release is the _alleged_ fix to the long-standing bug in the use of absolute URIs vs absolute paths in requests (for non-proxied and proxied use.) Give it a go.. Notice that the HTTP-4000.x version will require you to make some modifications to your existing HTTP-using code -- I've tried to keep the API backwards compatible minimal despite the change in functionality and underlying types. If you do not want to deal with this right away, please introduce a 4000 dependency on the HTTP package in your .cabal files. I've also taken on the maintainership of the package, with the highly esteemed Bjorn Bingert no longer having the usual abundance of cycles to look after it (hope I'm not misrepresenting facts here, Bjorn!) However, I've yet to gain access to www.haskell.org and update http://www.haskell.org/http, so for now you may pick up a new version the lib via http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP GIT repo for HTTP-4000 / HTTPbis is here git://code.galois.com/HTTPbis.git enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available
Hi Levi, I'm guessing that you are reading something different into that than what's intended - it's client-side in the sense that it can only issue web requests and handle their responses. i.e., it doesn't handle incoming HTTP requests and issue suitable responses. Web server implementation is an interesting problem in its own right, and many packages/frameworks do an admirable job of that already, so no plans (by me) to tackle that via the HTTP package. But, utilizing the HTTP package as part of any web app you expose on a web server is very much on and not out of bounds. Go for it! :-) Does that answer your Q? (my apologies if I'm stating the obvious above.) cheers --sigbjorn Levi Greenspan wrote: Sounds very good to me. However I would like to as one question regarding the HTTP lib. On hackage I read: HTTP: A library for client-side HTTP. Maybe you or someone on this list can tell me what the restrictions of the HTTP library are that restrict it to client side. What would be required to enable it for server-side use as well? Is it planed to complete HTTP this way? Many thanks, Levi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
On 1/15/2009 06:19, John Goerzen wrote: Sigbjorn Finne wrote: ... Nice! Has there been any effort to support Mono? Only in spirit so far. I'm keen to find the time to do it and if it would directly help people having Mono as a deployment target, even better. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Thanks Yitzchak, I'm thinking and acting on having that available in your quiver have prototyped the ability to do so a couple of times in the past (stand-alone Haskell code as fully fledged .NET classes/assemblies, both the dynamic and static kind.) I didn't want to hold up the initial release to do this right now _and_ would really like to get a better gauge at how important having that piece would be to users looking to use Haskell in a .NET context. There's only so much time it seems, but no shortage of interesting projects to hack on :-) cheers --sigbjorn On 1/15/2009 03:14, Yitzchak Gale wrote: Sigbjorn Finne wrote: the first public release of hs-dotnet is now available Fantastic accomplishment! I can only repeat dons' comment - this could be game-changing. Some obvious questions that come to mind: We see that it is already possible to expose a Haskell function to .NET as a callback. That's exciting! Can we go to the next step and register it as part of an assembly? Is it be possible for a running .NET app to fire up the GHC runtime and call into compiled Haskell? Is it possible at all for a .NET function not to have any side effects? If so, is there any way to label it as such and then call it from Haskell outside of the IO monad? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available
Hi, I guess it's time to publish more widely the availability of a modernization of the venerable and trusted HTTP package, which I've been working on offon for a while. Bunch of changes, but the headline new feature of this new version is the parameterization of the representation of payloads in both HTTP requests and responses. Two new representations are supported, strict and lazy ByteStrings. Some people have reported quietly pleasing speedups as a result of this change. (If they want to report numbers, please do..) Another change/fix in this release is the _alleged_ fix to the long-standing bug in the use of absolute URIs vs absolute paths in requests (for non-proxied and proxied use.) Give it a go.. Notice that the HTTP-4000.x version will require you to make some modifications to your existing HTTP-using code -- I've tried to keep the API backwards compatible minimal despite the change in functionality and underlying types. If you do not want to deal with this right away, please introduce a 4000 dependency on the HTTP package in your .cabal files. I've also taken on the maintainership of the package, with the highly esteemed Bjorn Bingert no longer having the usual abundance of cycles to look after it (hope I'm not misrepresenting facts here, Bjorn!) However, I've yet to gain access to www.haskell.org and update http://www.haskell.org/http, so for now you may pick up a new version the lib via http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP GIT repo for HTTP-4000 / HTTPbis is here git://code.galois.com/HTTPbis.git enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2
Thanks Simon, great stuff; I like the introduction of these 'native code finalizers', they've been sorely missed at times. You don't say, but will there be a dynamic check to catch such re-entries? --sigbjorn On 1/14/2009 04:14, Simon Marlow wrote: By popular demand, GHC 6.10.2 will support finalizers that are actually guaranteed to run, and run promptly. There aren't any API changes: this happens for finalizers created using newForeignPtr as normal. However, there's a catch. Previously it was possible to call back into Haskell from a finalizer (finalizers are C functions), by using foreign import wrapper or foreign export. According to the FFI spec, whether this is allowed or not is system dependent. In GHC 6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not. The reason being that C finalizers are now executed directly by the GC, when the runtime is not in a position to handle callbacks. You can still have fully-fledged Haskell finalizers if you want: we have Foreign.Concurrent.newForeignPtr for that purpose. But those finalizers are not subject to the same promptness guarantees that you get with C finalizers - they run in a separate thread, and are not guaranteed to be run at program exit. We'll make sure this is documented prominently in the 6.10.2 release notes, but I thought a heads-up would be a good idea right now as it turns out that there are existing libraries (e.g. LLVM) that will be affected. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Hi, the first public release of hs-dotnet is now available - a pragmatic take on interoperating between Haskell (via GHC) and .NET. For downloads and (some) info, see: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hs-dotnet http://haskell.forkIO.com/dotnet Feedback most welcome, both on what's there and what you would like to see better handled/supported next. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: json-0.4.1
Hi, a new release of the 'json' package is now available via hackage, version 0.4.1 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json [no claims that it represents rocket science, but a number of downstream codebases depend on this package for their operation, hence the announcement here.] New in this release is a generic JSON encoder contributed by Lennart Augustsson (Text.JSON.Generic ; thanks Lennart!) along with a number of other, smaller changes (including changes to the default encoding for constructors and prelude types - no longer down-cased; see release notes for more.) Enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Linking in GMP as a Windows DLL w/ GHC
Hi, a number of folks have been asking/looking for ways to avoid statically linking in GMP into GHC binaries under Windows. I've written up some notes on how to go about doing this, which are now available from http://haskell.forkio.com/gmpwindows Let me know if it is useful (or works ;-) ) enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: length of module name affecting performance??
Ditto. Can I claim the [A-Z].* hierarchies as belonging to me? :-) --sigbjorn putting them up on eBay afterwards...maybe On 12/15/2008 18:00, Lennart Augustsson wrote: That's a truly awesome feature! I'll shorten all my module names to single letters tomorrow. -- Lennart On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart d...@galois.com wrote: dons: Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? Given this, could you open a bug ticket for it, with all the info we have, http://hackage.haskell.org/trac/ghc/newticket?type=bug E.g. the graph, the code, the asm diff. Cheers, Don ___ 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: Control.Exception
On 11/3/2008 07:34, Jason Dagit wrote: Ah, but I had one more question that I don't think anyone has answered yet. That is, how to deal with multiple types of exceptions. Suppose, as a concrete example, that I was looking out for both ExitCode and PatternMatchFail exceptions. Maybe I'm being naive, but it seems like I'm in that situation again where I have to catch all and then check if fromException succeeds on either PatternMatchFile or ExitCode types. And then throw if it both give Nothing? One way to do this now is to use Control.Exception.catches: catches :: IO a - [Handler a] - IO a data Handler a where Handler :: forall a e. (Exception e) = (e - IO a) - Handler a --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Control.Exception
(+1) to that request - what is the best practices for portable exception handling code that straddles version 6.10, i.e. that compiles with compilers at either side with minimal fuss? I can imagine a couple of alternatives, but would like to hear what others are doing here. thanks --sigbjorn likes backward code compatibility On 11/1/2008 18:15, Jason Dagit wrote: On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow [EMAIL PROTECTED] wrote: Johannes Waldmann wrote: with 6.10, the following does not typecheck: foo `Control.Exception.catch` \ _ - return bar Ambiguous type variable `e' in the constraint: `Control.Exception.Exception e' It is probably bad programming style anyway but what is the workaround? As long as you're aware that it is bad programming style. We deliberately didn't include an easy way to do this, because we want people to think about why they need to catch *all* exceptions (most of the time it's a bug). Since the above is bad form, what should I be doing? Could someone please provide some examples or point me at the list of exceptions that I can catch? What about catching multiple types of exceptions? Thanks, Jason ___ 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: -optl doesn't seem to pass to ld (on Windows)
There's another level of indirection to punch through (the gcc driver); try -optl-Wl,--enable-stdcall-fixup --sigbjorn Alistair Bayley wrote: -optl--enable-stdcall-fixup With ghc-6.6.1 on WinXP, I want to pass --enable-stdcall-fixup (or --disable-stdcall-fixup, depending on my mood) to ld, but either the -optl option doesn't seem to work, or I've misunderstood what it's meant to do. ghc -v indicates that it is not in the parameters passed to ld.exe. Alistair ___ 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
ANNOUNCE: Bamse 1.0
Galois is pleased to announce the first public release of Bamse, a Windows Installer creator framework written in Haskell. Using Bamse, you can easily create applications that let you build Windows Installer (MSIs) for your project's product deliverables. The tool was written quite a while ago (4-5 years) as an internal tool at Galois to help the automated building of shippable bundles for Windows platforms, but has also been used for GHC installers since version 5.0.x (and other Haskell-related tools, interpreters and packages.) The source code + support package is available from http://galois.com/~sof/bamse/ Remarks/notes: - the source code is covered by a BSD license. - questions, bug reports to [EMAIL PROTECTED] / [EMAIL PROTECTED] (*) - If someone would like to adopt and extend the code to make it even more useful, feel free to dive in and hack. (Integrate it into the building of Cabal source and binary dists, perhaps..?) - If there's genuine interest, the code could be made available via a repo ( (*) being the main reason not to right now.) Enjoy --sigbjorn (*) - I'm in the middle of moving to another tectonic plate, so e-mail responses might be slower than usual for the next couple of weeks. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 win32 msi available
[My apologies for the long'ish e-mail, for Win9x users mostly..] Someone sent an e-mail querying about Win9x compatibility, which is something I forgot to take into account when building the 6.6.1 installer. To remedy, I've refreshed the installer to include a new version that ought to work across a wider spectrum of MS OS versions releases -- http://galois.com/~sof/msi/ghc-6-6-1.msi Notice that since the GHC binary is now being linked with a 'threaded' RTS, some non-Win9x compatible portions of the Win32 API is being used depended upon, causing DLL resolution at startup to miserably fail. To counter and workaround this, I've included bin/ghc-u.exe with the refreshed installer, which is an unthreaded (and faster..) version of the compiler (= GHCi.) So, to get a working system under Win9x, you'll need to either use ghc-u directly, or rename it as ghc.exe (and, as a result, enable 'ghci.exe' usage.) Also, as with ghc-6.6, if you intend to distribute your 6.6.1-compiled code that uses the Win32 package, and have it work on Win9x platforms, you'll need to include the Unicode API layer DLL, which you'll find in bin/ as unicows.dll hth --sigbjorn On 5/8/2007 15:25, Sigbjorn Finne wrote: In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; most (all?) libraries/ are in there; no C++ bits (sorry.) enjoy --sigbjorn [And, if it's your preference, a ghc-6-6-1.zip is also available from that same dir.] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 win32 msi available
In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; most (all?) libraries/ are in there; no C++ bits (sorry.) enjoy --sigbjorn [And, if it's your preference, a ghc-6-6-1.zip is also available from that same dir.] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs
I added support for generating .bat files (to HEAD, I believe) for these
in-place
wrappers some time ago just to address this issue, so you may want to
look into
dragging those Makefile mods over.
--sigbjorn
On 3/5/2007 08:58, GHC wrote:
#1196: Cabal on Windows doesn't like the in-place GHCs
-+--
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal| Milestone: _|_
Component: Compiler | Version: 6.6
Severity: normal|Keywords:
Difficulty: Unknown |Testcase: cabal01
Architecture: Unknown | Os: Windows
-+--
From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
{{{
C:\C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is
not recognized as an internal or external command, operable program or
batch file.
C:\cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
inplace
#!/bin/sh
exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
-BC:cygwinhomeianghc6.6-branchbuild $@
}}}
which means the cabal01 test fails thus:
{{{
$ ./setup configure --prefix=`pwd`/install --with-
compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
--enable-library-profiling
setup.exe: Warning: Package is copyright All Rights Reserved
setup.exe: Warning: No license-file field.
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is
not recognized as an internal or external command,
operable program or batch file.
Configuring test-1.0...
}}}
(the odd output order is due to buffering)
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs
If you're referring to ghc-pkg-inplace invocations from Cabal, the
same hack was applied in utils/ghc-pkg also.
--sigbjorn
On 3/6/2007 08:46, Simon Marlow wrote:
Ah, so you did, thanks for reminding me. We still need to do
something about ghc-pkg, though.
Cheers,
Simon
Sigbjorn Finne wrote:
I added support for generating .bat files (to HEAD, I believe) for
these in-place
wrappers some time ago just to address this issue, so you may want to
look into
dragging those Makefile mods over.
--sigbjorn
On 3/5/2007 08:58, GHC wrote:
#1196: Cabal on Windows doesn't like the in-place GHCs
-+--
Reporter: igloo | Owner: Type:
bug | Status: newPriority: normal|
Milestone: _|_ Component: Compiler | Version:
6.6Severity: normal|Keywords:
Difficulty: Unknown |Testcase: cabal01
Architecture: Unknown | Os: Windows
-+--
From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
{{{
C:\C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace'
is
not recognized as an internal or external command, operable program or
batch file.
C:\cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
inplace
#!/bin/sh
exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
-BC:cygwinhomeianghc6.6-branchbuild $@
}}}
which means the cabal01 test fails thus:
{{{
$ ./setup configure --prefix=`pwd`/install --with-
compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
--enable-library-profiling
setup.exe: Warning: Package is copyright All Rights Reserved
setup.exe: Warning: No license-file field.
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace'
is
not recognized as an internal or external command,
operable program or batch file.
Configuring test-1.0...
}}}
(the odd output order is due to buffering)
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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: Network.Socket endian problem?
Hi,
as you've time-consumingly discovered, Network.Socket.HostAddress
is represented in network byte order (something that's not well
documented, and a potential trap.)
You may want to consider using Network.Socket.inet_addr as
a constructor.
--sigbjorn
Rich Neswold wrote:
Hello,
I've written a program that uses UDP as its communication with other
processes. It was built with GHC 6.4.1 on MacOS 10.4 (PowerPC) and
works fine. When I moved the code to a Linux box (i386) and built it
with GHC 6.6, it didn't work. The problems turns out to be,
apparently, an endian problem. The socket is created with the
following snippet:
allocSocket :: IO Socket
allocSocket =
do { s - socket AF_INET Datagram 0
; handle (\e - sClose s throwIO e) $
do { connect s (SockAddrInet 6802 0x7f01)
; return s
}
}
On the Macintosh, the socket only receives packets from
127.0.0.1:6802, which is correct (and works). On the Linux machine,
the socket only accepts packets from 1.0.0.127:6802. The data
constructor SockAddrInet doesn't swap the bytes of the address
(although it correctly swaps the bytes of the port number!)
Changing the data constructor call to (SockAddrInet 6802 0x017f)
makes it work on Linux, but not on MacOS 10.4. (You can see what the
socket is bound to, on Linux, with netstat -aun.)
I don't have access to GHC 6.4.1 on a Linux box to determine whether
this is a regression in 6.6 or simply an overlooked detail. Should I
file a PR? Am I doing something wrong?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit
[Due to a somewhat inconvenient HD meltdown some weeks ago, I lost a bunch of data/user settings amongst other things, including the password to GHC's Trac, hence this lame response directly to the mailing list] I fixed this one a week or two ago on the 6.6 branch -- http://www.haskell.org/pipermail/cvs-ghc/2006-October/032154.html Have not had the timespace to drag it over to HEAD since then. hth --sigbjorn GHC wrote: #942: Windows programs throw uncaught Invalid HANDLE exception on exit +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: major | Resolution: Keywords: uncaught exception HANDLE exit | Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: Windows | +--- Changes (by [EMAIL PROTECTED]): * severity: normal = major Comment: I've changed the severity to major because I feel this bug prevents me distributing any binaries compiled under ghc6.6 for Windows, since whether or not the bug is visible (ie if you choose to run the binary under a debugger), obviously something is very wrong indeed with the runtime or else it wouldn't be trying to use an invalid handle (or cause one of the windows DLLs to do so) at program exit. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit
Ought to (but don't sue me if it doesn't.) --sigbjorn Bulat Ziganshin wrote: Hello Sigbjorn, Tuesday, October 31, 2006, 10:04:52 PM, you wrote: is that means that current 6.6 precompiled snapshots like http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20061031-i386-unknown-mingw32.tar.gz should work fine? this problem is very important for me too ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.6 on Windows Vista: cannot exec as
Thank you, something's changed wrt path handling it seems. A temporary fix/workaround (as reported by other Vista users) is to add the ghc-6.6\gcc-lib directory to your PATH. If you have the time, here's a couple of things to try out to diagnose the problem further: c:\foo echo int x = 22; foo.c c:\foo c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib/ -c foo.c ... # expected to fail (same as ghc's invoc of gcc below) c:\foo c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib -c foo.c ... # what happens here? c:\foo c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib\ -c foo.c ... # what happens here? --sigbjorn Satnam Singh wrote: The -v output below. I shall try it with Vista RC2 and see if that make a difference. The same installer file on Windows XP and Windows Server seems to work fine. Cheers, Satnam C:\sd\satnams\haskell\helloghc Hello.hs gcc: installation problem, cannot exec `as': No such file or directory C:\sd\satnams\haskell\helloghc -v Hello.hs Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: c:\ghc\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 Created temporary directory: C:/Users/satnams/AppData/Local/Temp/ghc5440_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 10 *** Simplify: Result size = 8 *** Tidy Core: Result size = 8 *** CorePrep: Result size = 10 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib/ -I. -c C:\Users\satnams\AppData\Local\Temp\ghc5440_0\ghc5440_0.s -o Hello.o gcc: installation problem, cannot exec `as': No such file or directory *** Deleting temp files: Deleting: C:/Users/satnams/AppData/Local/Temp/ghc5440_0/ghc5440_0.s *** Deleting temp dirs: Deleting: C:/Users/satnams/AppData/Local/Temp/ghc5440_0 C:\sd\satnams\haskell\hello -Original Message- From: Sigbjorn Finne [mailto:[EMAIL PROTECTED] Sent: 18 October 2006 14:03 To: Satnam Singh Cc: GHC-bugs list Subject: Re: ghc-6.6 on Windows Vista: cannot exec as Thanks; for people that don't have access to Vista, the output resulting from 'ghc -v Hello.hs' would help narrowing this down a bit...I hope. --sigbjorn Satnam Singh wrote: I just installed GHC-6.6. on Windows Vista RC1 (using the MSI installer) but when I compile I get the error: c:\sd\satnams\haskell\helloghc Hello.hs gcc: installation problem, cannot exec `as': No such file or directory Has anyone else noticed this? And before anyone tells me to: no, I can't use Linux! Cheers, Satnam ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.6 on Windows Vista: cannot exec as
Thanks; for people that don't have access to Vista, the output resulting from 'ghc -v Hello.hs' would help narrowing this down a bit...I hope. --sigbjorn Satnam Singh wrote: I just installed GHC-6.6. on Windows Vista RC1 (using the MSI installer) but when I compile I get the error: c:\sd\satnams\haskell\helloghc Hello.hs gcc: installation problem, cannot exec `as': No such file or directory Has anyone else noticed this? And before anyone tells me to: no, I can’t use Linux! Cheers, Satnam Satnam Singh Microsoft 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] UK tel: +44 1223 479905 US tel: +1 206 219 9024 Fax: +44 1223 479 999 UK cell: +44 7979 648412 URL: http://research.microsoft.com/~satnams http://research.microsoft.com/%7Esatnams MSN IM: [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Some potentially useful installers..
Hi, I've bundled up a bunch of Win32 installers for various tools that come in handy when developing withfor GHC: Alex, Happy, and Haddock (aka The Marlow Collection) http://galois.com/~sof/msi/alex-2-0-1.msi http://galois.com/~sof/msi/happy-1-15.msi http://galois.com/~sof/msi/haddock-0-7.msi enjoy, --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some potentially useful installers..
Hi, some day (soon) --sigbjorn Neil Mitchell wrote: Hi Sigbjorn, I've bundled up a bunch of Win32 installers for various tools that come in handy when developing withfor GHC: Alex, Happy, and Haddock (aka The Marlow Collection) Are the tools used to build these installers available? Thanks Neil ___ 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
Re: [GHC] #891: hsc2hs tries to remove an open file
This is a long standing, irksome Win32 timing issue, and is not GC related (AFAICR, it was reproducible in straight C code). A better workaround, which was experimented with in STABLE at some point, is to simply delay the clean up of the files until the end of hsc2hs's run --sigbjorn GHC wrote: #891: hsc2hs tries to remove an open file -+-- Reporter: eivuokko |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.4.2 Severity: normal| Keywords: Os: Windows | Difficulty: Unknown Architecture: Unknown | -+-- hsc2hs sometimes fails with error Permission denied in Windows. This is because it tries to remove a file it has open handle to. The error usually repeats per-machine and file, but what file and machine it shows up with, is random. As a workaround, calls to removeFile can be removed, or exceptions catched. From a mail by Brian Smith: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031186.html ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #882: Overflow bug in System.Time
The fix is trivial though (and have been applied to HEAD) --
http://hackage.haskell.org/trac/ghc/ticket/588
--sigbjorn
GHC wrote:
#882: Overflow bug in System.Time
---+
Reporter: simonpj |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: libraries/base | Version: 6.4.2
Severity: normal | Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
---+
Frederik Eaton reports: The Glorious Glasgow Haskell Compilation System,
version 6.4.3.20060816
{{{
now - getClockTime
addToClockTime (TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour =
0, tdMin = 0, tdSec = 0, tdPicosec = }) now
*** Exception: Time.toClockTime: picoseconds out of range
}}}
This is clearly a bug. Simon Marlow comments: System.Time is kind-of
deprecated: the new time package is intended to supercede it, but I have
been reluctant to really deprecate System.Time because it comes from
Haskell98, and also because we don't have much experience with its
replacement.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Efficiency of using field labels vs pattern matching
If you let the Simplifier have a crack at your code (i.e., compile with -O
or better), the same code should be generated for the two defns of
'foo'. Try compiling with -ddump-simpl to verify.
The first version is stricter, so it'll be preferable in -Onot mode.
--sigbjorn
Brian Hulley wrote:
Hi,
I'm wondering if it is more efficient to pattern match against the
components of a record instead of using the field functions, though
I'd prefer to just use the field functions.
For example, if I write:
data R = R {_xRef :: !(IORef Int)}
foo :: Int - R - IO ()
foo i R{_xRef = xRef} = writeIORef xRef i
is the above more efficient than:
foo i r = writeIORef (_xRef r) i
I know this is probably a bit silly to worry about the overhead of an
extra function call etc but I've at the moment got a lot of code using
the first version and I think it would look much neater just using
field labels but I don't want to modify it if it will be less
efficient since speed is quite critical here.
Thanks, Brian.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #840: GHC on loosing its handles takes 100% CPU
But as long as it's Haskell code consuming all those CPU cycles, it can't be all bad? :) If any of you are running into this while invoking ghci.exe, you may want to play with using ghc.exe --interactive instead to see if that improves matters. Not using ghci.exe avoids a layer of sub-process'ery and console event handling nonsense; a culprit, perhaps? --sigbjorn - Original Message - From: Lennart Augustsson [EMAIL PROTECTED] To: Bulat Ziganshin [EMAIL PROTECTED] Cc: GHC [EMAIL PROTECTED]; glasgow-haskell-bugs@haskell.org Sent: Friday, August 04, 2006 05:46 Subject: Re: [GHC] #840: GHC on loosing its handles takes 100% CPU It happens all the time to me that GHC doesn't die properly on windows. Every so often I have to kill a few straggling ghc processes. They all spin consuming 100% CPU when this happens. -- Lennart On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote: Hello GHC, Wednesday, August 2, 2006, 4:33:09 PM, you wrote: #840: GHC on loosing its handles takes 100% CPU import System.Process main = runInteractiveCommand ghc When run terminates immediately, as expected, but leaves an instance of ghc running. The ghc process takes up 100% of the CPU time, and seemingly does nothing. well, i have similar problem: there are only 256 megs on my machine and sometimes when ghc compilation uses more than 200 megs and starts trashing memory, i tries to stop it by hitting Ctrl-C. in this situation it's rather typical that i got back my console (and rerun ghc) but old GHC process don't killed and continue to compile program. i can investigate it further but don't know what to do. at least it seems that memory trashing is required to uncover this problem. i also should note that i run ghc --make from the .cmd file so there is a whole stack of processes runned. may be i just kill higher-level ghc (or even cmd) and lower-level ghc still continue to do it's job? i'm not sure.. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Where is HsTimeConfig.h?
HsnameConfig.h is a by-product of a package's build config script, so if you've got access to a full source tree for the package in Q, perhaps you haven't run the autoconf script? --sigbjorn - Original Message - From: Alistair Bayley [EMAIL PROTECTED] To: glasgow-haskell-users@haskell.org Sent: Friday, July 14, 2006 04:55 Subject: Where is HsTimeConfig.h? I'm trying to build Ashley's time package with GHC6.4 on Windows XP, and there are a few things it uses which seem to be in GHC6.6 only. Some of them I can find in the GHC sources, but I am unable to locate HsTimeConfig.h. When GHC is installed I'd expect to find it under C:\ghc\ghc-6.4.1\include, but I can't tell where this maps to in the ghc source tree. Thanks, Alistair ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Strange behaviour with classes (both Hugs and GHC)
Hi,
if you desugar the definition that's causing the type error,
perhaps it becomes a little bit clearer what's going on, i.e.,
from
problematic :: MyAnnotatedType Int
problematic = defaultVal{theInt=42,theAnnotation=10}
you expand this to
problematic' = case defaultVal of { MAT a b c - MAT 42 b 10 }
Clearly, the type of 'c' is ambiguous here. Interestingly, if Haskell 98
had defined record update expr e{fields} as having the same type
as e, this wouldn't have been an issue:
no_probs =
case defaultVal of { m@(MAT a b c) - (MAT 42 b 10) `asTypeOf` m}
hth
--sigbjorn
- Original Message -
From: Magnus Björk [EMAIL PROTECTED]
To: glasgow-haskell-bugs@haskell.org; hugs-bugs@haskell.org
Sent: Monday, May 29, 2006 03:34
Subject: Strange behaviour with classes (both Hugs and GHC)
I just ran into a strange behaviour of both Hugs and GHC. I discussed it
with John Hughes who managed to find a workaround, and suggested that I
ask you whether this is really expected behaviour.
The attached file contains a small example that exhibits the problem.
--
/MpB
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANNOUNCE: GHC vesrion 6.4.2
A candidate 6.4.2 installer for Windows is now available, http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-2-20060421.msi Unless any major issues show up over the weekend, I'll move it into its proper directory early next week. thx --sigbjorn Note: someone requested including the OpenAL package with the 6.4.2 installer a while back. Afraid I didn't get around to doing this...sorry. - Original Message - From: Brian Hulley [EMAIL PROTECTED] To: Simon Marlow [EMAIL PROTECTED]; glasgow-haskell-users@haskell.org Sent: Thursday, April 20, 2006 08:26 Subject: Re: ANNOUNCE: GHC vesrion 6.4.2 Simon Marlow wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.4.2 = I notice that everything except the standalone Windows port is now available for download. How soon will this be avaliable? (No great rush, just interested :-) ) (The Visual Haskell port, while looking great, unfortunately has a restrictive Microsoft component of the license that prohibits use for commercial development so I can't use it unfortunately (unless someone can persuade Microsoft to delete their license component(!)) Looking forward to trying out 6.4.2, Regards, Brian. ___ 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: Bug in cvs head ghci
Yep, reproducible with last night's HEAD build on mingw (but not STABLE.) --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: wld [EMAIL PROTECTED]; glasgow-haskell-bugs@haskell.org Sent: Friday, December 16, 2005 08:13 Subject: RE: Bug in cvs head ghci Strange. This does not happen for me on Linux or Windows (GHc 6.4.1). Has anyone else seen it? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of wld | Sent: 08 December 2005 13:25 | To: glasgow-haskell-bugs@haskell.org | Subject: Bug in cvs head ghci | | HI, | | Typing |Prelude :b GHC.Base | | I get | [snip] | data Addr# | data Array# a | data Bool = False | True | data ByteArray# | data Char# | data Char = C# Char# | data Double# | data Float#*** Exception: No match in record selector TyCon.tyConTyVars | Prelude | | ghc built on Linux with | - ghc 6.4.1 | - gcc 4.0.2 | | -- | V.Rudenko ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Checking for WHNF (a horrible naughty thing)
The appended snippet might help..
--sigbjorn
-- whnf.hs
import Foreign.StablePtr
import System.IO.Unsafe
isWHNF :: a - Bool
isWHNF a = unsafePerformIO $ do
stl - newStablePtr a
rc - isWhnf stl
freeStablePtr stl
return (rc /= 0)
foreign import ccall safe isWhnf isWhnf :: StablePtr a - IO Int
/* whnf.c */
#include Rts.h
int
isWhnf(StgStablePtr st)
{
StgClosure* c = (StgClosure*)(stable_ptr_table[(StgWord)st].addr);
return !(closure_THUNK(c));
}
- Original Message -
From: Jan-Willem Maessen [EMAIL PROTECTED]
To: glasgow-haskell-users glasgow-haskell-users@haskell.org
Sent: Wednesday, November 23, 2005 08:10
Subject: Checking for WHNF (a horrible naughty thing)
I would like to do a horrible naughty thing (which I promise never to
expose to the world). I would like to tell whether a term is in
WHNF, without forcing evaluation of that term. Something like:
isWHNF :: a - Bool
Is there a way of doing this? I can fake it with an IORef and much
unsafeness, but I'm wondering if there's a safe-but-ugly way of doing
the test in GHC.
If you're curious, I'm trying to compact exactly the evaluated spine
of a list without changing the list's laziness in any way. It
remains to be seen whether this is even vaguely a good idea. :-)
-Jan-Willem Maessen
___
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: [Haskell-cafe] Re: getServiceEntry: does not exist on Windows
I don't really have the time, but here's some debugging code that'll maybe help diagnosing why/if WinSock is failing to start up: - compile the attached initws.c via ghc, foo$ ghc -c initws.c - run some tests foo$ ghc -package net IWS.hs initws.o -e initWS 1 1 = print foo$ ghc -package net IWS.hs initws.o -e initWS 2 2 = print foo$ ghc -package net IWS.hs initws.o -e initWS 1 1 Network.BSD.getProtocolByName \tcp\ = print foo$ ghc -package net IWS.hs initws.o -e initWS 2 2 Network.BSD.getProtocolByName \tcp\ = print initWS returns 0 on success. The GHC networking support is ultra-conservative wrt WinSock versioning, sticking with 1.1 for max portability. Perhaps that's working against us here? Needless to say, this is working for me (on a pair of XP boxes.) --sigbjorn - Original Message - From: Joel Reymont [EMAIL PROTECTED] To: Simon Marlow [EMAIL PROTECTED] Cc: Haskell Cafe haskell-cafe@haskell.org; [EMAIL PROTECTED] Sent: Friday, October 21, 2005 06:31 Subject: Re: [Haskell-cafe] Re: getServiceEntry: does not exist on Windows It stopped happening for me on WinXP but it's still happening for my customer on Win2K. On Oct 21, 2005, at 1:45 PM, Simon Marlow wrote: Nope, actually it also happens for me with the updated installer. Sigbjorn - any ideas? It doesn't happen with my local STABLE build, but I'm still using gcc 3.2.x. initws.c Description: Binary data IWS.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
New 6.4.1 windows installer
A test installer for a patched version of ghc-6.4.1 for Windows is now available, http://haskell.org/ghc/dist/6.4.1/ghc-6-4-1-bld1.msi Unless I'll hear of any packaging snafus, it'll be hooked up to the GHC web pages tomorrow. Notice that by default this installer will deposit bits in the same directory as the original 6.4.1 installer, so if you treasure the original bits The installer includes all 6.4.1 fixes committed as of 2005-10-20T01:00:00+. In particular, usage of Cabal from a GHCi-like setting should now work OK. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cc1plus.exe not included in Win32 distro
It was intentionally removed (the intention being to remove heft from the installer) after it had been unintentionally included for quite a while. The rule has always been that only tools that GHC depends upon to operate are bundled with it on the mingw side -- the only exception to that rule has been the recent inclusion of 'ar'. Should GHC binary dists include a C++ compiler? I'd say no, but if there are practical and compelling reasons to do so, it's no big deal to re-include the binary. --sigbjorn - Original Message - From: Bulat Ziganshin [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Friday, October 14, 2005 10:49 Subject: cc1plus.exe not included in Win32 distro Hello all, the official Win32 distro (http://www.haskell.org/ghc/dist/6.4.1/ghc-6-4-1.msi) does not contain cc1plus.exe, needed to compile CPP files: C:\FreeArchiver ghc a.cpp gcc: installation problem, cannot exec `cc1plus': No such file or directory is this a packaging bug or intentional change? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Network Exception
Just to be clear -- this is with ghc-6.4.1 as distributed via the GHC web pages and not some local build..? I can't explain this -- the example code you give will have successfully started up WinSock (version 1.1) prior to calling getHostName, so that error condition doesn't make much sense. Given the two networking issues you've already come across, I wouldn't discount the option that this might be due to a local problem with your networking setup (WinSock proxy config..?) --sigbjorn - Original Message - From: Arias [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED] Cc: glasgow-haskell-bugs@haskell.org Sent: Friday, October 14, 2005 14:01 Subject: Re: Network Exception Thanks for the reply. I don't know if the problem is the same, but when I try to run this code: main = withSocketsDo $ do host - getHostName putStrLn host the getHostName throws this exception: getHostName: failed (Successful WSAStartup not yet performed (WSANOTINITIALISED)) :( I'm using Windows XP Professional Sigbjorn Finne escribió: Hi, that error message is a bit confusing, to say the least: getProtocolByName identifies itself as getServiceEntry when failing. In this case, I'm quite sure, your snippet fails because (getProtocolByName tcp) isn't successful. I've no idea why your /etc/protocols doesn't contain an entry for 'tcp'. The error message in said function has now been fixed; thanks for the report. --sigbjorn - Original Message - From: Arias [EMAIL PROTECTED] To: glasgow-haskell-users@haskell.org Sent: Friday, October 14, 2005 06:47 Subject: Network Exception Hi, I've a problem, I'm using this code on GHC compiler version 6.4.1: --- BEGIN --- module Main where import System.IO import Network main = withSocketsDo $ do handle - connectTo localhost ( PortNumber 8080 ) hSetBuffering handle LineBuffering hClose handle --- END --- The problems is that it throws an exception at connectTo, the exception is: getServiceEntry: does not exist (no such service entry) The server and the port is correct, I have apache listening on port 8080 and if I put http://localhost:8080/ on browser it loads a web page. Do somebody knows what it happens and how to fix it? thanks. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANNOUNCE: GHC version 6.4.1
Just uploaded hooked up to the downloads page, http://haskell.org/ghc/download_ghc_641.html --sigbjorn - Original Message - From: David Nick Main [EMAIL PROTECTED] To: glasgow-haskell-users@haskell.org Sent: Tuesday, September 20, 2005 16:01 Subject: Re: ANNOUNCE: GHC version 6.4.1 Great news ! Any word on the Windows binary ? Simon Marlow wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.4.1 = ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fw: 6.4.1 win32 candidate installer
FYI - widening the (testing) audience a bit. --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 22, 2005 13:59 Subject: 6.4.1 win32 candidate installer With 6.4.1 being close to done, I've rolled an MSI test installer of the bits -- available as http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-1-20050822.msi Reports of installer snafus or any other problems using it are most welcome. thanks --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Undefined symbols on new install of ghc 6.2.2
Can't think of a reasonable explanation for the behaviour you're seeing, I'm afraid. If you look at the undefined symbols from the link, _ZCMain_main_closure isn't being found -- it should be in Build.o, which is included on the command line. The weird thing is that the linker does report undefined symbols from that closure's entry point, _ZCMain_main_entry (in Build.o), but fails to see the (.data) symbol for the closure itself. On the off-chance you haven't tried this already, could you try to delete the object files and re-do the --make? Add -fvia-C while you're at it. If you want to examine what the linker actually slurps in, try -optl-Wl,--verbose GHC binary installs on Windows are islands as far as tools needed to compilelink Haskell code goes. You may run into trouble if you compile a .c file with a local installation of gcc and then try to link the object file with ghc, but I don't think that's the case here. --sigbjorn - Original Message - From: Alastair Reid [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED] Cc: glasgow-haskell-bugs@haskell.org Sent: Monday, August 22, 2005 06:16 Subject: RE: Undefined symbols on new install of ghc 6.2.2 Thanks Sigbjorn, Chris gave these a shot and everything looks right. (i.e., the symbols exist, tmpdir is big and changing it doesn't help and invoking ghc on the .o files directly doesn't help.) Also, building with the latest release of ghc works fine. (This is slightly tedious because we need both 6.2.2 and 6.4 at the moment but we'll probably update our code to work with 6.4 sometime soon anyway.) One interesting detail was that the .a file has names with triple-underscore prefixes but the linker error messages have single-underscore prefixes. Is this just the linker deleting _'s when displaying error messages or is this the real problem? I'm not sure what Chris has installed on his machine but is it possible that if he had cygwin (say) installed the gcc from that install would be used instead of the one that comes in the ghc package? -- Alastair Reid, Principal Engineer, RD ARM Ltd, 110 Fulbourn Rd, Cambridge, CB1 9NJ. T: +44 1223 406 109 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Undefined symbols on new install of ghc 6.2.2
Puzzling; couple of things to check for: - nm -o c:/ghc/ghc-6.2.2/libHSbase.a | grep 'T ___stginit_Prelude' is successful. - the TMPDIR setting appears to be w:/tmp -- make sure that actually exists isn't clogged up. Does changing it to . (or somesuch) alter the behaviour? - does an invocation of the form ghc -o build.exe MakeUtils.o Build.o whatever else succeed? --sigbjorn - Original Message - From: Alastair Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 05:59 Subject: Undefined symbols on new install of ghc 6.2.2 One of my colleagues just installed ghc 6.2.2 on their Windows machine. GHC compiles fine but ghc --make fails at the linking stage with a bunch of undefined symbols that ought to have been part of the ghc install like: ./MakeUtils.o(.text+0x43): In function `_stginit_MakeUtils_': : undefined reference to `_stginit_IO_' ./MakeUtils.o(.text+0x4d): In function `_stginit_MakeUtils_': : undefined reference to `_stginit_Prelude_' ./MakeUtils.o(.text+0x5c): In function `r1pU_srt': : undefined reference to `GHCziBase_zdfEqZMZN_closure' (see attached file for complete list of undefined symbols). We've checked that the lib files exist and confirmed that he installed ghc in the normal place (see message at end of this message). ghc-6.2.2 works just fine on my machine. Does this ring any bells for anyone? -- Alastair Reid, Principal Engineer, RD ARM Ltd, 110 Fulbourn Rd, Cambridge, CB1 9NJ. T: +44 1223 406 109 yadda yadda -Original Message- Alastair Reid wrote: Can you try: ghc -v this will produce a few hundred lines of output amongst which there's a bunch of filenames like c:/ghc/ghc-6.2.2 c:/ghc/ghc-6.2.2/imports c:/ghc/ghc-6.2.2/hslibs-imports/util The first should have a bunch of files with names like libHS*.a and is the most important The latter should have a bunch of *.hi files (and seem to be fine since you got as far as linking). Assuming you mean that these directories should have the files you name (not the output of ghc -v), then, yes, they are present. Check you're not really low on diskspace in case the install silently failed (e.g., the 100s of Mbytes of libHS*.a files weren't all installed). Plenty of disc space. If that looks plausible, try adding the -v flag to the ghc --make command line to see if you get any useful info about the failure. If still nothing, try -v4 and -v5 to get extra verbosity. I tried this but learnt nothing new (see attached). Is it possible that I need to set some environment variables other than PATH (e.g. LD_LIBRARY_PATH)? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stdin set to nonblocking mode
Simon Marlow [EMAIL PROTECTED] writes: ... No - read() can always return less than the requested amount of data, even when not in O_NONBLOCK mode. Hmm, care to give some details as to why you equate can with always will on all platforms? --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stdin set to nonblocking mode
Simon Marlow [EMAIL PROTECTED] writes: On 11 August 2005 01:18, John Meacham wrote: Why do we set file descriptors to nonblocking mode anyway if they are waited on by a select. there shouldn't be a need to use both It avoids an extra system call per read(), i.e. a single read() instead of select() + read(). And there's a slight chance of a race between the select() and read() calls, if some other thread or process is reading from the same descriptor. With non-blocking read(), this isn't an issue. The overhead of the extra syscall is probably a non-issue, but the race is mildly worrying. The main reason for using non-blocking descriptors is that select() only tells you that I/O is possible over a descriptor, not the amount. Hence block read()s and writes() run the real risk of blocking the whole system. Insisting on single byte read()/write()s is not an option ;-) --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: getDirectoryContents fails in GHC 6.5 snapshots, works in GHC 6.4.1 snapshots
Mystery now solved (*), nightly builds should now behave a bit better
when it comes to directory handling.
--sigbjorn
* - gcc-3.4.* mingw builds hard-codes default include search paths
referring to /mingw/. My local box happened to contain an older mingw
dist in that location, leading to confusion about the layout of 'struct
dirent'.
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: glasgow-haskell-bugs@haskell.org
Sent: Monday, August 08, 2005 10:38
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC
6.4.1 snapshots
I can repro it too. Looks as if the dirent.h implementation of the
mingw snapshot that the nightlies are using is spongled. Simple
stuff like
#include stdio.h
#include errno.h
#include dirent.h
int main()
{
DIR* dp;
struct dirent* de;
dp = opendir(c:\\);
while (de = readdir(dp)) {
printf(%s\n,de-d_name);
}
closedir(dp);
return 0;
}
fails. I'll upgrade and see if that improves matters.
--sigbjorn
- Original Message -
From: Brian Smith [EMAIL PROTECTED]
To: glasgow-haskell-bugs@haskell.org
Sent: Monday, August 08, 2005 10:31
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC
6.4.1 snapshots
On 8/8/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 29 July 2005 23:53, Brian Smith wrote:
On 7/20/05, Brian Smith [EMAIL PROTECTED] wrote:
This bug breaks Cabal 1.0 and Cabal 1.1.1.
Expected results: passed
Actual results: *** Exception: c:\: getDirectoryContents: failed (No
error)
I tried various versions and couldn't reproduce the error. I tried:
Yes, it fails for every directory. I actually noticed the problem by
when using Cabal, which uses getDirectoryContents. But, I did some
more testing. This works:
ghc --make Main.lhs -o main
main
passed
But, this fails:
ghci Main.lhs
Prelude Main main
*** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)
and this fails:
runghc Main.lhs
*** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)
This indicates to me that there is not any problem with my filesystem.
Instead, it seems like it is likely a problem with the linker. Now, I
see what the cause of the problem is:
http://www.haskell.org//pipermail/cvs-ghc/2005-June/025579.html
Sigbjorn Finne sof at galois.com wrote on Mon Jun 20 12:29:24 EDT 2005:
I'll switch over to using gcc-3.4.2 for the nightly builds to see where
takes us.
And, in my previous message I wrote:
Build 20050620 works fine, but Build 20050622 fails.
I noticed that on 2005-06-21 the build failed. I also noticed that
before 2005-06-21, the tar.gz's are ~1 larger than the ones after
2005-06-21.
- Brian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Feature request: Windows ZIP Distribution
Bulat Ziganshin [EMAIL PROTECTED] writes: SF That's an impressive reduction in size; compressing the SF CAB file inside the MSI using the LZW-based compressor SF that Microsoft provides with their 'makecab' utility didn't LZX (very different from LZW, born long ago, in 1984) btw, while writing this letter i compressed GHC 6.4 installation with cabarc. it results in 33 megs only (!). may be when you creating your installation, you are using MSZIP compression instead of LZX? or you compress with LZX:15, i.e. with minimal 32 kb dictionary instead of LZX:21? Cool, thanks for trying this out, Bulat. When fixing on MSZIP as the compressor for the tool that creates these MSIs sometime ago, I did play with different memory sizes for LZX, but the resulting installers didn't reduce space usage by all that much, so I opted to just go with the cheapcheerful MSZIP. This wasn't with GHC installers though, and as your experience shows that fixing on always using MSZIP wasn't such a good idea. I'll go with LZX for the next GHC release, as I'm able to reproduce what you're seeing. ... Re: lzma, 7-zip: I'm not questioning the improvements possible going this route, just that I won't be doing it for now. Others are free to offer up other distribution forms, of course. However, as an end-user on a Windows platform, I do prefer using non-executable installers. --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Feature request: Windows ZIP Distribution
That's an impressive reduction in size; compressing the CAB file inside the MSI using the LZW-based compressor that Microsoft provides with their 'makecab' utility didn't make much of a difference in size (but increased compression time quite a bit.) I'm idly speculating that LZMA's larger dictionaries is what's paying off here. Thanks for the pointer, I'll definitely play with it. I'm not planning on switching to 7-Zip in the near future though. However, I think Brian Smith's suggestion of offering up a .zip'ed up version of the GHC distribution tree is a good one plan to do that for the next release. It can then be used to derive other distribution/installer formats. --sigbjorn - Original Message - From: Bulat Ziganshin [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED] Cc: glasgow-haskell-bugs@haskell.org Sent: Wednesday, May 18, 2005 23:09 Subject: Re[2]: Feature request: Windows ZIP Distribution Hello Sigbjorn, Wednesday, May 18, 2005, 8:38:55 PM, you wrote: SF The 6.4 installer has a UI bug that may prevent you from using SF it on a box where you don't have admin privs. Try starting up the installer, SF hit Next, followed by Back. That should bring up a dialog letting you choose SF whether to perform a user or machine wide installation. Select the former nice bug! :) you can cut installer size in 1.5-2 times by repacking it with another compressor - LZMA. i tried this on the your 6.4 distribution and whole installed directory was packed down to 26 megs to get this work you can either switch to Nullsoft installer, which has support for LZMA, or create self-extracting module with help of 7-zip (www.7-zip.org) anf include this self-extractor in your installer in order to test lzma compression, download abovementioned 7-zip and try it on some directory with the following cmdline: 7z a archive -r -mx9 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Feature request: Windows ZIP Distribution
One e-mail regarding this would do.. :) The 6.4 installer has a UI bug that may prevent you from using it on a box where you don't have admin privs. Try starting up the installer, hit Next, followed by Back. That should bring up a dialog letting you choose whether to perform a user or machine wide installation. Select the former and proceed as before. Hopefully that does it. Distributing a .zip wouldn't be a big deal, just want to make sure it is solving a real problem. --sigbjorn - Original Message - From: Brian Smith To: glasgow-haskell-bugs@haskell.org Sent: Wednesday, May 18, 2005 08:57 Subject: Feature request: Windows ZIP Distribution Hi, I think it would be convenient for some users (including me at this particular moment) if the Windows binary distribution of GHC was available as a ZIP file. My laptop died and I am using a shared computer with the Windows Installer disabled, thus I cannot use the MSI distribution. Maybe other people have similar situations. Note that ZIP files (unlike TAR.GZ files) can be unzipped in Windows XP without any third-party tools. Thanks, Brian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linker errors when using FFI on Windows
Adding the -Lc:\windows\system32 option when linking upsets the resolution of misc standard libraries, causing 'ld' to use the DLLs rather than the mingw link libraries, including msvcrt.dll. Try just using c:/windows/system32/ntwdblib.dll on the link line instead. If ld's DLL auto-import support doesn't quite work, attempting to link with the import library 'ntwdblib' (ntwdblib.lib ?) instead is worth a shot. The SQL Server SDK ought to include that somewhere. hth --sigbjorn - Original Message - From: Bayley, Alistair [EMAIL PROTECTED] To: glasgow-haskell-users@haskell.org Sent: Wednesday, April 27, 2005 08:10 Subject: Linker errors when using FFI on Windows I'm trying to link an FFI program against a Windows (XP) DLL (c:\windows\system32\ntwdblib - this is the MS Sql Server client library). The output from ghc6.4 -v is below; the errors start in the Linker section. Comments: - Where do these objects dxx.o come from? (They're not in my source...) d13.o(.text+0x0): multiple definition of `_onexit' c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x2a0):crt1.c: first defined here d18.o(.text+0x0): multiple definition of `atexit' c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x280):crt1.c: first defined here - Have I omitted some important linker flag? There are tons of these undefined references from crt2.o, like this: c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x238):crt1.c: undefined reference to [EMAIL PROTECTED]' Thanks, Alistair. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Build problem from CVS ...?
Did you do a 'cvs up' with the -d option to have it create new directories? ghc/lib/compat/include contains directory.h, and is a fairly new addition. --sigbjorn - Original Message - From: David Duke [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Tuesday, April 26, 2005 06:59 Subject: Build problem from CVS ...? I've been running ghc6.5, downloaded and built along with the other tools in the fptools cvs repository (I have no pressing need for cutting edge code, but using the fptools repository is convenient in providing everything in the one place!). This morning I updated my repository and tried to rebuild; that failed, so I ran update again, made distclean, and tried again (autoreconf, ./configure, make) ... Compilation is failing in ghc with the following error: ===fptools== Recursively making `boot' in compat ... PWD = /home/djd/builds/fptools/ghc/lib ==fptools== make boot - --no-print-directory -r; in /home/djd/builds/fptools/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I. -Iinclude -I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c cbits/directory.c:11:23: directory.h: No such file or directory cbits/directory.c:11:23: directory.h: No such file or directory Indeed, there is no file directory.h under the source tree. Should this have been created during configuration - either way, any suggestions on why it is missing? thanks, David ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86
Ditto w/ HEAD -- the compilation error refers to 'stderr'. For that to work, 'stderr' has to be an lvalue, which is an unsound assumption (mingw defines it as (_iob[STDERR_FILENO]).) --sigbjorn - Original Message - From: Conal Elliott [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Tuesday, April 26, 2005 09:46 Subject: FW: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86 I am getting this same barfage on WinXP (invalid lvalue in unary `' while compiling raisezh_fast in Exception.cmm). From cvs-ghc mail, it looks like this one has been coming up for a few days now. - Conal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Donald Bruce Stewart Sent: Tuesday, April 26, 2005 2:25 AM To: [EMAIL PROTECTED] Subject: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86 Build description = HEAD on OpenBSD/x86 Build location= /home/dons/head-gcc3 Build config file = /home/dons/head-gcc3/nightly/site/pls/conf-HEAD-manzano Nightly build started on manzano at Tue Apr 26 19:00:17 EST 2005. using existing source tree... ok. (GHC Version 6.5) Updating source tree ... ok. Building stage 1 compiler... failed; relevant barfage is below. Building Haddock ... ok. Building Alex... ok. Building Happy ... ok. No successfully built compilers to test; aborting. The last 30 lines of /home/dons/head-gcc3/logs/i386-unknown-openbsd-stage1 are ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Weak.c -o Weak.p_o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c hooks/FlagDefaults.c -o hooks/FlagDefaults.p_o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c hooks/InitEachPE.c -o hooks/InitEachPE.p_o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c hooks/MallocFail.c -o hooks/MallocFail.p_o
Re: win98, ctrl-c System.system (was: Updated 6.4 Windows installer RC)
Simon Marlow [EMAIL PROTECTED] writes: ... Prelude System.system ls = print *** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi le or directory) Prelude System.Cmd.rawSystem ls [] = print _viminfo getname.pl index.html ExitSuccess Prelude System.system false = print *** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi le or directory) Prelude System.Cmd.rawSystem false [] = print ExitFailure 1 Works for me! Remember that System.system is executing CMD.EXE, not Cygwin bash, so it'll probably have a different PATH and might not be able to find your Cygwin binaries. Both System.system dir, and System.system c:/cygwin/bin/ls work for me. There's no such thing as cmd.exe on Win9x, it's COMMAND.EXE/COM. Some System.Process.* code ought to be looking at the COMSPEC env variable and not hard-code the name of the command processor. However, I don't think COMMAND.EXE supports the /c switch...why the switch away from just using libc/msvcrt's system() for System.system? --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Updated 6.4 Windows installer RC
Yet another 6.4 installer, this time fixing issues regarding GHC use on Win9x / NT4 installations: http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld2.msi http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld2.msi.md5 Unless some _really bad_ platform-specific bugs are reported against this one soon, that's the final 6.4 installer. The caveats/remarks below for the 'bld1' version also applies to this one. --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: GHC users glasgow-haskell-users@haskell.org Sent: Thursday, March 17, 2005 16:59 Subject: Updated 6.4 Windows installer RC An updated version of the Windows installer for ghc-6.4 is now available for testing, http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld1.msi md5 checksum: 4a55a5614587cef07a19d7f7728f3a83 It hopefully sorts out the showstopping profiling problems that people have reported; let me know if it doesn't and/or there are other packaging snafus. If nothing major pops up, I'll consider the bits blessed and hook the installer up to the GHC downloads page. Note: - the installer re-uses the product GUIDs of the original 6.4 installer, so if you've already got it installed, it'll remove that install the first time you run it. - the HGL and Win32 packages have been removed from the installer at the suggestion of the package author(s); deemed not quite yet ready for primetime, I believe. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem starting GHC 6.4 on windows 98
Thanks, this issue was fixed a couple of hours ago in the CVS repository based on similar feedback from other Win9x users. Expect to see an updated installer sometime early next week. --sigbjorn - Original Message - From: J L Russell [EMAIL PROTECTED] To: glasgow-haskell-users@haskell.org Sent: Friday, March 18, 2005 20:26 Subject: Problem starting GHC 6.4 on windows 98 When trying to run GHC 6.4 (from the installer) on Windows 98, I get the following error message: The GHC.EXE file is linked to missing export SHELL32.DLL:SHGetFolderPathA From what I've been able to determine, on Windows version prior to Windows 2000, this function was instead exported from shfolder.dll, which is retained in later versions of Windows for backward compatibility, and on newer version of Windows, simply calls the version in shell32.dll. So it looks to me like GHC 6.4 from the installer won't be able to run on Windows 98 unless the executable in the installer is updated to link this function from shfolder.dll instead. -James ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Updated 6.4 Windows installer RC
An updated version of the Windows installer for ghc-6.4 is now available for testing, http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld1.msi md5 checksum: 4a55a5614587cef07a19d7f7728f3a83 It hopefully sorts out the showstopping profiling problems that people have reported; let me know if it doesn't and/or there are other packaging snafus. If nothing major pops up, I'll consider the bits blessed and hook the installer up to the GHC downloads page. Note: - the installer re-uses the product GUIDs of the original 6.4 installer, so if you've already got it installed, it'll remove that install the first time you run it. - the HGL and Win32 packages have been removed from the installer at the suggestion of the package author(s); deemed not quite yet ready for primetime, I believe. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4 snapshot installer available
New installer available that includes all STABLE changes up until 20:00 UTC today: http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050304.msi ( md5.sig: 022bfcaae335b718bdc59014d58b39a0 ) --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: GHC users glasgow-haskell-users@haskell.org Sent: Tuesday, March 01, 2005 15:37 Subject: 6.4 snapshot installer available http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050301.msi (md5.sig: 0f3be1a0c211194415b2cb8ee579f6e1 ; size: 46M) the only known omission from the bits intended to be included in the release proper is the PDF version of the user's guide. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.4 snapshot installer available
http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050301.msi (md5.sig: 0f3be1a0c211194415b2cb8ee579f6e1 ; size: 46M) the only known omission from the bits intended to be included in the release proper is the PDF version of the user's guide. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: misaligned block returned
Hi, 8 == ERROR_NOT_ENOUGH_MEMORY, which sounds reasonable (albeit cryptic) since Win32 has a default user process size limit of 2Gb. --sigbjorn - Original Message - From: Andreas Marth [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Thursday, January 13, 2005 07:41 Subject: misaligned block returned Hi! I tried to pass a big heap to a program and get the following error: getMBlocks: VirtualAlloc failed with: 8 main: internal error: getMBlocks: misaligned block returned Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ That happens even for a Hello world program. The border is 1956M. So +RTS -M1956M -RTS is fine. +RTS -M1957M -RTS yields the error above. PS: I know that is a big heap and I could probably do with less when I track the space leak down, but at the moment it is not worth the effort. I only need a single run that passes. (With probably 2.5 - 3 GB memory usage.) PPS: Please cc any answers to me because I am not subscribed to haskell-glasgow-bugs. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: threadDelay space leak under win32
Fixed now on the STABLE branch, but 6.2.2 and, at least, all previous 6.x releases suffer from this embarrassing mem leak. Thanks for reporting the problem. --sigbjorn - Original Message - From: Simon Marlow [EMAIL PROTECTED] To: Philippa Cowderoy [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 08, 2004 07:54 Subject: RE: threadDelay space leak under win32 On 07 November 2004 22:47, Philippa Cowderoy wrote: Using the binary distros of GHC 6.2.1 and 6.2.2 under Win2K, this leaks 12K of memory per second on my machine (as do larger programs using threadDelay in the idle event of a wxHaskell app): module Main where import Control.Concurrent main = (threadDelay 1000) main I've no idea if it also happens on *nix platforms, or with a win32/cygwin build. Yes, that looks like a memory leak somewhere in the Async IO subsystem on Windows. The leak goes away using the threaded RTS on the latest CVS version of GHC, because there we're using plain sleep() calls to implement threadDelay and bypassing AsyncIO. Sigbjorn: you're the owner of the Windows AsyncIO implementation, care to look into this leak? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHCI and readline package
The instructions below refer to a slightly older version of mingw -- to have it work with the one that's bundled with 6.2.2, substitute strcasecmp.o strncasecmp.o for string_old.o. --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: Wassell, Mark P (GE Energy) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 01, 2004 20:30 Subject: Re: GHCI and readline package You can make 'readline' load with GHCi 6.2.2 with just a little bit of effort -- try the following: # any old temporary working directory will do bash$ mkdir c:/tmp/hack bash$ cd c:/tmp/hack # assuming you've install 6.2.2 in c:/ghc/ghc-6.2.2 bash$ c:/ghc/ghc-6.2.2/bin/ar x \ c:/ghc/ghc-6.2.2/gcc-lib/libmoldname.a string_old.o bash$ c:/ghc/ghc-6.2.2/gcc-lib/ld --whole-archive \ -r -x -o readline.o c:/ghc/ghc-6.2.2/gcc-lib/libreadline.a \ string_old.o bash$ cp readline.o c:/ghc/ghc-6.2.2/ # you may now delete the temp dir. Next, manually edit your c:/ghc/ghc-6.2.2/package.conf, editing the readline package's extra_libraries field to: extra_libraries = [readline, advapi32], Save the changes you should be ready to go. --sigbjorn - Original Message - From: Wassell, Mark P (GE Energy) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 01, 2004 19:34 Subject: GHCI and readline package Hi, I'm having a problem running ghci and loading the readline package on WindowsXP. C:\Software\haskell\ghc622\binghci -package readline ghci -package readline ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package readline ... linking ... C:/Software/haskell/ghc622/HSreadline.o: unknown symbol `_rl_redisplay_function' ghc.exe: unable to load package `readline' I have seen the follow in the user guide: For some reason, Mingw ships with the readline library, but not with the readline headers. As a result, GHC (like Hugs) does not use readline for interactive input on Windows. You can get a close simulation by using an emacs shell buffer! but I assume I need readline as util needs it and util is needed by data which is needed by wxcore. Cheers Mark ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI and readline package
You can make 'readline' load with GHCi 6.2.2 with just a little bit of effort -- try the following: # any old temporary working directory will do bash$ mkdir c:/tmp/hack bash$ cd c:/tmp/hack # assuming you've install 6.2.2 in c:/ghc/ghc-6.2.2 bash$ c:/ghc/ghc-6.2.2/bin/ar x \ c:/ghc/ghc-6.2.2/lib/libmoldname.a string_old.o bash$ c:/ghc/ghc-6.2.2/gcc-lib/ld --whole-archive \ -r -x -o readline.o c:/ghc/ghc-6.2.2/gcc-lib/libreadline.a \ string_old.o bash$ cp readline.o c:/ghc/ghc-6.2.2/ # you may now delete the temp dir. Next, manually edit your c:/ghc/ghc-6.2.2/package.conf, editing the readline package's extra_libraries field to: extra_libraries = [readline, advapi32], Save the changes you should be ready to go. --sigbjorn - Original Message - From: Wassell, Mark P (GE Energy) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 01, 2004 19:34 Subject: GHCI and readline package Hi, I'm having a problem running ghci and loading the readline package on WindowsXP. C:\Software\haskell\ghc622\binghci -package readline ghci -package readline ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package readline ... linking ... C:/Software/haskell/ghc622/HSreadline.o: unknown symbol `_rl_redisplay_function' ghc.exe: unable to load package `readline' I have seen the follow in the user guide: For some reason, Mingw ships with the readline library, but not with the readline headers. As a result, GHC (like Hugs) does not use readline for interactive input on Windows. You can get a close simulation by using an emacs shell buffer! but I assume I need readline as util needs it and util is needed by data which is needed by wxcore. Cheers Mark ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] hugs segmentation fault
Jon Fairbairn [EMAIL PROTECTED] writes: On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote: Jon Fairbairn wrote: Well, here's a sample session I recorded just now: C:\\ghc\ghc-6.2.1\bin\ghci Prelude let p = 1 : [2 * x | x - p, x 1] in p [1*** Exception: loop Prelude 123 Fail: thread blocked indefinitely C:\ Does this only happen to me? I'm using Linux, you Windows. I suspect there's a hint there. Has this been reported to Glasgow Haskell bugs? (cc'd) Plenty of times, but maybe not that particular manifestation of the problem. Fixed in 6.2.2 --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
