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). 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
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 ndmitch...@gmail.com 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.*
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 package 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 johan.tib...@gmail.com wrote: On May 27, 2009 3:33 AM, Neil Mitchell ndmitch...@gmail.com 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.*
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 d...@galois.com 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
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: 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 sanzhi...@gmail.com: 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: 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: [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: mtl and network packages in GHC 6.10.3.*
On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell ndmitch...@gmail.com 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: mtl and network packages in GHC 6.10.3.*
On Wed, May 27, 2009 at 9:53 PM, Johan Tibell johan.tib...@gmail.comwrote: On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell ndmitch...@gmail.comwrote: 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
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
