Re: Lazy computation being repeated?
Tyson Whitehead wrote: I have a program that seems to me to be exhibiting strange behaviour. Basically, it looks like something somewhere is not being updated, and this is resulting in (very expensive) computation being repeated. Just a hunch - try recompiling your modules with -fno-state-hack. q.v. http://hackage.haskell.org/trac/ghc/ticket/2284 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Lazy computation being repeated?
I have a program that seems to me to be exhibiting strange behaviour. Basically, it looks like something somewhere is not being updated, and this is resulting in (very expensive) computation being repeated. The program in question goes like so. The results from the expensive calculation are stored in this structure data Cache = Cache { cacheBits0 :: UArr Float, cacheBits1 :: UArr Float } and computed by this function (which takes several gigs of RAM) cacheIndex :: ... -> Cache cacheIndex ... = ... The main program is main = catch prog error where prog = do ... let !cache = cacheIndex ... ... run cache ... ... The run function reads an input line from stdin and calls effectChange to performs the indicated calculation run cache ... = loop where loop = do ... case effectChange ... cache of ... ... loop The effectChange function is calculates the change in an auto correlation. It is made much cheaper (order too fast to notice) through the use of a the one time computations stored in cacheBits0 and cacheBits1 (order several seconds). Whether cacheBits1 is used or not depends on the input, while cacheBits0 is always used because I used lengthU cacheBits0 [the fast one from UArr] to get the length of both of them. The first line of input causes a several second delay and lots of memory to be allocated (the cacheBits are being computed). Repeated lines of input respond very quickly and the memory stays mostly constant, unless cacheBits1 is used, in which case there is always a delay of several seconds and big jumps in memory allocation. The only thing I can think of that each time effectsChange is being run and it is uses cacheBits1, it causes it value to be recomputed. Indeed, the delay and big memory jumps go away if I change all references of cacheBits1 to cacheBits0 in effectsChange or make the data fields strict like so data Cache = Cache { cacheBits0 :: !(UArr Float), cacheBits1 :: !(UArr Float) } Does this make sense? Am I missing some reason why this should be the expected behaviour for this program? Thanks! -Tyson ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mtl and network packages in GHC 6.10.3.*
On Wed, May 27, 2009 at 9:53 PM, Johan Tibell wrote: > On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell wrote: > >> In addition, I can't install network under Cygwin, Mingw, or the >> Windows command line. Here are the errors from Cygwin: >> > > I've filed a bug: http://trac.haskell.org/network/ticket/14 > > In the meantime try 2.2.1.1 > The latest HEAD from darcs works fine for me on Windows XP. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haddock-2.3.0 literate comments discarded from .lhs input
On Wed, 2009-05-27 at 19:47 +0100, Claus Reinke wrote: > > We need a clear spec on what variables tools are expected to handle and > > how they are to be interpreted. > > Currently, there seem to be $topdir and $httptopdir. And I can't see a justification for there being two. > Given the split between GHC and HP, it might be useful to have an > additional $hptopdir, or just a general mechanism for variables in > ghc-pkg's database (I recall being disappointed when what looked like > environment variables were unaffected by environment settings..). I'd rather not create ad-hoc vars which everyone needs to know about for things like the platform. > > Supporting relocatable sets of packages is a good idea. We should aim to > > have something that is usable by each compiler, not just ghc, so > > interpreting paths relative to ghc's libdir doesn't seem ideal. > > GHC makes no reference to libdir, it simply talks about a $topdir > (where it would like to store things it needs) and $httptopdir (where > haddocks might be found). Yes ok, on windows the topdir is the parent of dir containing ghc.exe. > > How about this: a way to specify paths in the package registration info that > > are relative to the location of the package db they are in. > > ahem. That sounds like a backwards step, being dependent on two > locations instead of one. I don't follow this. Which two? > Before the HP, windows GHCs could be relocated without needing to > update the ghc-pkg database, even if some packages were installed > outside GHCs $topdir. I don't see how this is related to what the Windows installer for the HP is doing. Sure, since it's installing packages relative to ghc and we'd like the whole thing to be relocatable then it should use relative paths. I don't think anyone disputes that, the question is how to implement relative paths. > With your variant, just about any change would need updating. I must be missing something. If you move package.conf and the packages in one go, then nothing needs changing as far as I can see. > Assuming that the parts are independently located by whatever the OS > packaging conventions say, and can be independently relocated > otherwise, it seems simpler to continue with the variable scheme, but > with improved support and documentation for it. My suggestion seems very simple! I'm clearly missing some problem which you can see. To be clear, here's what I'm imagining: blah/package.conf blah/lib/foo-1.0/libfoo-1.0.a and package.conf would contain foo-1.0 with paths looking like "$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name we agree on) as being "blah/" because that's the dir containing the db. So crucially, it doesn't really matter where ghc.exe is. Assuming ghc can find the package conf then it can find all the files. So it'd let you create multiple relocatable package collections. If the primary package db is kept relative to ghc (eg in ghc's topdir) then the whole ghc installation including libs is relocatable Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mtl and network packages in GHC 6.10.3.*
On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell wrote: > In addition, I can't install network under Cygwin, Mingw, or the > Windows command line. Here are the errors from Cygwin: > I've filed a bug: http://trac.haskell.org/network/ticket/14 In the meantime try 2.2.1.1 Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types
Folks Quite a few people have asked for splices in Template Haskell *types*, and I have finally gotten around to implementing them. So now you can write things like instance Binary $(blah blah) where ... or f :: $(wubble bubble) -> Int as requested, for example, in the message below. Give it a whirl. You need the HEAD; in a day or two you should find binary snapshots if you don't want to build from source. Simon PS: Note that you (still) cannot write a splice in a *binding* position. Thus you can't write f $(blah blah) = e or data T $(blah blah) = MkT Int I don't intend to change this; see the commentary at http://hackage.haskell.org/trac/ghc/ticket/1476 | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Ross Mellgren | Sent: 25 January 2009 19:55 | To: Haskell Cafe | Subject: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types | | Hi all, | | I'm writing a small module that exposes a template haskell splice that | takes a (very simplified) C struct definition and builds: | | - A data type definition, | - an instance for Data.Binary.Binary, | - and optionally a pretty print function for it | | However, it seems to do this I have to write a bunch of really ugly | code that builds up the TH data structures "by hand" because quoting | only works with splices for expressions, or so it seems. | | For example, to generate the binary instance I have this code: | | import qualified Language.Haskell.TH as TH | | -- tyname is the name of the data type I've already created, as a | TH.Name | -- tempnames is a list of temporary variable names that are used in | lambda patterns | -- fields is a list of tuples describing each field | -- makeGetExp recursively builds a monadic computation consisting | mostly of Binary.getWord32be >>= \ tempvar -> ... | | binaryInstDec <- liftM (TH.InstanceD [] (TH.AppT (TH.ConT $ | TH.mkName "Data.Binary.Binary") (TH.ConT tyname))) | [d| get = $(makeGetExp (reverse $ zip | fields tempnames) returnExp) | put = undefined |] | | I'd really rather write: | | binaryInstDec <- [d| | instance Binary.Binary $(tyname) where | get = $(makeGetExp (reverse $ zip fields tempnames) | returnExp) | put = undefined |] | | But GHC gives me a syntax error on the tyname splice. The docs seem to | indicate this is the way it is -- that splices in type locations is | plain not implemented. | | My question is whether or not this is just the way it is, and people | writing TH declaration splices tend to have to start manually | assembling a bunch of it, or is there some trick I've missed? Perhaps | even better are there some tricks that people tend to use to make this | less painful? | | I did try using some of the lowercased monadic constructors in | Language.Haskell.TH.Lib but I didn't seem to get anything more succint | out of it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haddock-2.3.0 literate comments discarded from .lhs input
> It turns out that those variables are there to allow relocation, in > fact $topdir is expanded by > Distribution.Simple.GHC.getInstalledPackages, it seems that > $httptopdir has been overlooked. > I'd be tempted to say that it's ghc-pkg dump/describe responsibility > to expand those vars instead, like it does for ghc-pkg field. Agreed on ghc-pkg doing the translation. Via commandline options, or via environment vars (one might be tempted to manage the bindings in ghc-pkg's database itself, even). The lack of support for this hampers the useability of ghc-pkg and the database it is responsible for. We need a clear spec on what variables tools are expected to handle and how they are to be interpreted. Currently, there seem to be $topdir and $httptopdir. Given the split between GHC and HP, it might be useful to have an additional $hptopdir, or just a general mechanism for variables in ghc-pkg's database (I recall being disappointed when what looked like environment variables were unaffected by environment settings..). The info is somewhat distributed: http://darcs.haskell.org/ghc/utils/ghc-pkg/Main.hs http://darcs.haskell.org/ghc/compiler/main/Packages.lhs http://darcs.haskell.org/ghc/compiler/main/SysTools.lhs [Note topdir] Supporting relocatable sets of packages is a good idea. We should aim to have something that is usable by each compiler, not just ghc, so interpreting paths relative to ghc's libdir doesn't seem ideal. GHC makes no reference to libdir, it simply talks about a $topdir (where it would like to store things it needs) and $httptopdir (where haddocks might be found). How about this: a way to specify paths in the package registration info that are relative to the location of the package db they are in. ahem. That sounds like a backwards step, being dependent on two locations instead of one. Before the HP, windows GHCs could be relocated without needing to update the ghc-pkg database, even if some packages were installed outside GHCs $topdir. With your variant, just about any change would need updating. Assuming that the parts are independently located by whatever the OS packaging conventions say, and can be independently relocated otherwise, it seems simpler to continue with the variable scheme, but with improved support and documentation for it. Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haddock-2.3.0 literate comments discarded from .lhs input
On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote: > Andrea, > > 2009/3/19 Andrea Vezzosi : > > It turns out that those variables are there to allow relocation, in > > fact $topdir is expanded by > > Distribution.Simple.GHC.getInstalledPackages, it seems that > > $httptopdir has been overlooked. > > I'd be tempted to say that it's ghc-pkg dump/describe responsibility > > to expand those vars instead, like it does for ghc-pkg field. > > Do you (or anyone else) intend to work on this? If not, I'd like to > fix it, but I'll need some guidance. Like, is > Distribution.Simple.GHC.getInstalledPackages where the variable > expansion code should go, or should it be somewhere else? I don't think we should be hacking around this in Cabal without any discussion with the ghc folks on what is supposed to be there, what variables are allowed. We need a clear spec on what variables tools are expected to handle and how they are to be interpreted. The output of ghc-pkg describe/dump is not just for ghc to define and play around with. It's supposed to be defined by the Cabal spec. Supporting relocatable sets of packages is a good idea. We should aim to have something that is usable by each compiler, not just ghc, so interpreting paths relative to ghc's libdir doesn't seem ideal. How about this: a way to specify paths in the package registration info that are relative to the location of the package db they are in. That makes sense beyond just ghc and even with would allow other sets of relocatable packages, not just those installed with ghc. Then perhaps as a compat hack we should get Cabal to handle older ghc versions that do use these funny vars. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mtl and network packages in GHC 6.10.3.*
On Wed, May 27, 2009 at 02:33:45AM +0100, Neil Mitchell wrote: > > I just downloaded the Windows snapshot of 6.10.3.20090526, and found > that mtl and network don't seem to be included. Ooops, the extralibs were accidentally not being built by the buildbots. Should be fixed now. Thanks for pointing it out. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mtl and network packages in GHC 6.10.3.*
6.10.4 is a bug fix release. A bug fix release cannot remove packages no matter what state the platform is in, that's just seriously broken. On Wed, May 27, 2009 at 7:44 AM, Don Stewart wrote: > Not part of the core libs, so these are slowly disappearing from the > extralibs bundled shipped with GHC (in favour of the platform bundle). > > The 6.10.3 windows installer is due out June 1. > > -- Don > > ndmitchell: >> Hi, >> >> I just downloaded the Windows snapshot of 6.10.3.20090526, and found >> that mtl and network don't seem to be included. >> >> $ ghc-pkg list >> c:/ghc/ghc-6.10.3.20090526\package.conf: >> Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, >> base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, >> directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, >> (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, >> haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, >> old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, >> pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, >> syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 >> >> In addition, I can't install network under Cygwin, Mingw, or the >> Windows command line. Here are the errors from Cygwin: >> >> Preprocessing library network-2.2.1.2... >> In file included from Network\BSD.hsc:17: >> include/HsNet.h:78:22: sys/uio.h: No such file or directory >> include/HsNet.h:81:25: sys/socket.h: No such file or directory >> include/HsNet.h:84:26: netinet/tcp.h: No such file or directory >> include/HsNet.h:87:25: netinet/in.h: No such file or directory >> include/HsNet.h:90:21: sys/un.h: No such file or directory >> include/HsNet.h:93:24: arpa/inet.h: No such file or directory >> include/HsNet.h:96:19: netdb.h: No such file or directory >> In file included from Network\BSD.hsc:17: >> include/HsNet.h:138: error: syntax error before "addr" >> include/HsNet.h: In function `my_inet_ntoa': >> include/HsNet.h:146: error: storage size of 'a' isn't known >> include/HsNet.h:147: error: `addr' undeclared (first use in this function) >> include/HsNet.h:147: error: (Each undeclared identifier is reported only once >> include/HsNet.h:147: error: for each function it appears in.) >> include/HsNet.h:148: warning: return makes pointer from integer without a >> cast >> Network\BSD.hsc: In function `main': >> Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete >> type ` >> servent' >> >> And Mingw: >> >> * Missing header file: HsNet.h >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the library is >> already installed but in a non-standard location then you can use the flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. >> cabal.exe: Error: some packages failed to install: >> network-2.2.1.2 failed during the configure step. The exception was: >> exit: ExitFailure 1 >> >> And Windows command line: >> >> Resolving dependencies... >> Configuring network-2.2.1.2... >> cabal: Error: some packages failed to install: >> network-2.2.1.2 failed during the configure step. The exception was: >> sh: runProcess: does not exist (No such file or directory) >> >> Was removal of these packages on the stable branch was an oversight? >> Could network at the very least be reinstated soon? I'd love to report >> back whether the GHC 6.10.4 fixes work or not in practice. >> >> Thanks >> >> Neil >> ___ >> 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
reallocating buildbots? (Re: mtl and network packages in GHC 6.10.3.*)
Not part of the core libs, so these are slowly disappearing from the extralibs bundled shipped with GHC (in favour of the platform bundle). As the stable/head buildbots (as opposed to stable fast/head fast) are becoming less and less useful and cared for in the context of GHC, could they perhaps be reallocated to the Haskell Platform effort? It seems a shame to see these formerly useful donated build slots lie unused when the HP has no equivalent. The 6.10.3 windows installer is due out June 1. Given that fact, I'm surprised about the lack of activity on the HP list. But automated nightly snapshots from the buildbots would take some pressure off platform packagers, would get bugfixes out as they are done (which was why the buildbots started uploading them when GHC still came with libraries), and would allow for HP releases to use tested snapshots (as well as seeing immediately if GHC patches are going to affect their release process, allowing them to react early). Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mtl and network packages in GHC 6.10.3.*
Hi The GHC 6.10.3 installer is 100% useless to me (and my colleagues) - GHC 6.10.4 has two critical fixes in, for fatal problems which we're hitting on an at least an hourly basis. The Haskell platform can be a convenient way to get a standardised set of packages, but if cabal install doesn't work for Core libraries I'm in deep trouble. > I'll look into it later today when I have access to a Windows install. Thanks Johan. My personal feeling is if Core packages can't be installed with "cabal install foo" on the standard command line with a standard Windows+GHC install then they MUST be shipped in with GHC. If the platform effort wants to fix up the packages then that's great, but if the platform becomes the only way to get critical libraries with a massive lag, then I'm in serious trouble. Given this is a minor bug fix release, and that removing time in a minor bug fix release seems like it was a massive mistake, shouldn't these packages be reinstated at least until GHC 6.12? Thanks Neil On Wed, May 27, 2009 at 8:57 AM, Johan Tibell wrote: > > On May 27, 2009 3:33 AM, "Neil Mitchell" wrote: > > Hi, > > I just downloaded the Windows snapshot of 6.10.3.20090526, and found > that mtl and network don't seem to be included. > > $ ghc-pkg list > c:/ghc/ghc-6.10.3.20090526\package.conf: > Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, > base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, > directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, > (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, > haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, > old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, > pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, > syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 > > In addition, I can't install network under Cygwin, Mingw, or the > Windows command line. Here are the errors from Cygwin: > > Preprocessing library network-2.2.1.2... > In file included from Network\BSD.hsc:17: > include/HsNet.h:78:22: sys/uio.h: No such file or directory > include/HsNet.h:81:25: sys/socket.h: No such file or directory > include/HsNet.h:84:26: netinet/tcp.h: No such file or directory > include/HsNet.h:87:25: netinet/in.h: No such file or directory > include/HsNet.h:90:21: sys/un.h: No such file or directory > include/HsNet.h:93:24: arpa/inet.h: No such file or directory > include/HsNet.h:96:19: netdb.h: No such file or directory > In file included from Network\BSD.hsc:17: > include/HsNet.h:138: error: syntax error before "addr" > include/HsNet.h: In function `my_inet_ntoa': > include/HsNet.h:146: error: storage size of 'a' isn't known > include/HsNet.h:147: error: `addr' undeclared (first use in this function) > include/HsNet.h:147: error: (Each undeclared identifier is reported only > once > include/HsNet.h:147: error: for each function it appears in.) > include/HsNet.h:148: warning: return makes pointer from integer without a > cast > Network\BSD.hsc: In function `main': > Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete > type ` > servent' > > And Mingw: > > * Missing header file: HsNet.h > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > cabal.exe: Error: some packages failed to install: > network-2.2.1.2 failed during the configure step. The exception was: > exit: ExitFailure 1 > > And Windows command line: > > Resolving dependencies... > Configuring network-2.2.1.2... > cabal: Error: some packages failed to install: > network-2.2.1.2 failed during the configure step. The exception was: > sh: runProcess: does not exist (No such file or directory) > > Was removal of these packages on the stable branch was an oversight? > Could network at the very least be reinstated soon? I'd love to report > back whether the GHC 6.10.4 fixes work or not in practice. > > Thanks > > Neil > ___ > 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: mtl and network packages in GHC 6.10.3.*
I'll look into it later today when I have access to a Windows install. On May 27, 2009 3:33 AM, "Neil Mitchell" wrote: Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil ___ 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