Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)

2010-10-22 Thread Sigbjorn Finne
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

2009-08-04 Thread Sigbjorn Finne

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

2009-06-03 Thread Sigbjorn Finne
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..?

2009-05-21 Thread Sigbjorn Finne

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..?

2009-04-28 Thread Sigbjorn Finne

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

2009-04-28 Thread Sigbjorn Finne

-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

2009-04-27 Thread Sigbjorn Finne


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

2009-04-26 Thread Sigbjorn Finne

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

2009-04-26 Thread Sigbjorn Finne

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..?

2009-04-25 Thread Sigbjorn Finne

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..?

2009-04-25 Thread Sigbjorn Finne

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

2009-04-25 Thread Sigbjorn Finne

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

2009-04-25 Thread Sigbjorn Finne

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..?

2009-04-24 Thread Sigbjorn Finne

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

2009-04-23 Thread Sigbjorn Finne

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

2009-04-22 Thread Sigbjorn Finne

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

2009-04-22 Thread Sigbjorn Finne

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

2009-04-22 Thread Sigbjorn Finne

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

2009-04-21 Thread Sigbjorn Finne

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

2009-04-21 Thread Sigbjorn Finne

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

2009-04-20 Thread Sigbjorn Finne

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

2009-04-18 Thread Sigbjorn Finne


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

2009-04-18 Thread Sigbjorn Finne


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

2009-03-30 Thread Sigbjorn Finne

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)

2009-03-28 Thread Sigbjorn Finne

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

2009-03-23 Thread Sigbjorn Finne

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

2009-03-23 Thread Sigbjorn Finne

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

2009-03-19 Thread Sigbjorn Finne

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

2009-02-21 Thread Sigbjorn Finne

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

2009-02-21 Thread Sigbjorn Finne

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

2009-02-10 Thread Sigbjorn Finne

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?

2009-01-22 Thread Sigbjorn Finne

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

2009-01-20 Thread Sigbjorn Finne

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

2009-01-20 Thread Sigbjorn Finne

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

2009-01-18 Thread Sigbjorn Finne

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

2009-01-17 Thread Sigbjorn Finne


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

2009-01-16 Thread Sigbjorn Finne

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

2009-01-16 Thread Sigbjorn Finne

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

2009-01-15 Thread Sigbjorn Finne

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

2009-01-15 Thread Sigbjorn Finne


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

2009-01-15 Thread Sigbjorn Finne

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

2009-01-14 Thread Sigbjorn Finne

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

2009-01-14 Thread Sigbjorn Finne

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

2009-01-12 Thread Sigbjorn Finne

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

2009-01-07 Thread Sigbjorn Finne

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??

2008-12-15 Thread Sigbjorn Finne

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

2008-11-03 Thread Sigbjorn Finne

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

2008-11-01 Thread Sigbjorn Finne

(+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)

2007-08-16 Thread Sigbjorn Finne

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

2007-08-16 Thread Sigbjorn Finne


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

2007-05-09 Thread Sigbjorn Finne


[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

2007-05-08 Thread Sigbjorn Finne

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

2007-03-06 Thread Sigbjorn Finne
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

2007-03-06 Thread Sigbjorn Finne

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

2007-01-11 Thread Sigbjorn Finne

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?

2006-12-13 Thread Sigbjorn Finne

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

2006-10-31 Thread Sigbjorn Finne

[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

2006-10-31 Thread Sigbjorn Finne

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

2006-10-19 Thread Sigbjorn Finne

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

2006-10-18 Thread Sigbjorn Finne


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..

2006-10-17 Thread Sigbjorn Finne

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..

2006-10-17 Thread Sigbjorn Finne

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

2006-10-11 Thread Sigbjorn Finne

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

2006-09-07 Thread Sigbjorn Finne

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

2006-08-31 Thread Sigbjorn Finne


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

2006-08-20 Thread Sigbjorn Finne


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

2006-08-04 Thread Sigbjorn Finne

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?

2006-07-14 Thread Sigbjorn Finne

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)

2006-05-31 Thread Sigbjorn Finne

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

2006-04-21 Thread Sigbjorn Finne

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

2005-12-16 Thread Sigbjorn Finne

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)

2005-11-23 Thread Sigbjorn Finne

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

2005-10-21 Thread Sigbjorn Finne

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

2005-10-19 Thread Sigbjorn Finne

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

2005-10-17 Thread Sigbjorn Finne

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

2005-10-17 Thread Sigbjorn Finne

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

2005-09-20 Thread Sigbjorn Finne

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

2005-08-25 Thread Sigbjorn Finne

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

2005-08-22 Thread Sigbjorn Finne

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

2005-08-21 Thread Sigbjorn Finne

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

2005-08-12 Thread Sigbjorn Finne


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

2005-08-11 Thread Sigbjorn Finne

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

2005-08-09 Thread Sigbjorn Finne

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

2005-05-25 Thread Sigbjorn Finne

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

2005-05-19 Thread Sigbjorn Finne
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

2005-05-18 Thread Sigbjorn Finne
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

2005-04-27 Thread Sigbjorn Finne
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 ...?

2005-04-26 Thread Sigbjorn Finne
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

2005-04-26 Thread Sigbjorn Finne
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)

2005-03-23 Thread Sigbjorn Finne
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

2005-03-21 Thread Sigbjorn Finne
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

2005-03-18 Thread Sigbjorn Finne
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

2005-03-17 Thread Sigbjorn Finne
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

2005-03-04 Thread Sigbjorn Finne
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

2005-03-01 Thread Sigbjorn Finne
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

2005-01-13 Thread Sigbjorn Finne
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

2004-11-08 Thread Sigbjorn Finne
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

2004-11-02 Thread Sigbjorn Finne
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

2004-11-01 Thread Sigbjorn Finne
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

2004-10-29 Thread Sigbjorn Finne
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


  1   2   3   4   5   6   7   >