Re: [Haskell-cafe] Ordering of BigFloats in numbers-3000.0.0.0
On 08/10/12 01:31, Michael Orlitzky wrote: http://hackage.haskell.org/package/variable-precision Mine may be unacceptably slow due to the dependent libraries. I gave it a try -- the speed isn't an issue for me, but I need the trig functions (which look like they pass through Double). These are basically homework problems and related experiments for which I'm trying to avoid MATLAB at all costs, so sin and cos show up a lot. Ah thanks for the reminder that its implementation is incomplete so far - I do plan to implement the remaining algorithms properly but lack time right now, sorry. Claude -- http://mathr.co.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Long pauses / idle time in a Haskell TCP server
Hello, I'm seeing long pauses in a server based on the 'scalable-server' package from Hackage, version 0.2.2 [1]. It normally performs very well, about 100-150 micro-secs client latency over the loopback interface, but a fair number of requests are much slower, 38-40 milli-secs, making the mean latency and throughput quite bad. The server is a simple version of a memory cache, with operations to put a key-value mapping, and to get the value for a key, using a data map. I've tried with the strict versions of 'unordered-containers' and the 'containers' package for the data map implementation, with similar results. I've tried it with ghc 7.4.1 and with 7.6.1 with similar results. Runtime info I got shows: - GC report: GC time is much less than the total time of the slow responses, so does not explain them. - CPU profile: Idle time is very high, and would explain the slow responses. By idle time I mean the part of wall time which is not included in the profile report's total time. For example, when running a test for 5 minutes, the profile report has total time = 0.05 secs. 'top' output is consistent - quite low CPU usage during such a test. Apart from this there is nothing notable in the profile, most time is spent in the network input and output processing (network-enumerator etc.). One observation is that the pauses seem correlated with overwriting entries in the data map. If I'm mostly adding new keys (as well as reading), the throughput is much better, and the idle time in the CPU profile is lower (though the time spent in GC increases a lot). I've removed all concurrency from the program (including my version of scalable-server) to eliminate that factor, but the problem persists. I tried it on two fairly different Linux machines, with similar results. The client I use to benchmark is a simple C program, so I don't suspect it of causing the pauses. Looking at the timestamps on the network traffic confirms that the pauses are at the server. Any idea what might be causing the idle time? The long pauses are consistently 38-40ms, maybe that points to some aspect of CPU scheduling, leaving the program idle for some time? I can put the code on github if it would help. Many thanks! Alex [1] http://hackage.haskell.org/package/scalable-server-0.2.2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
On Sun, Oct 07, 2012 at 09:09:07PM +0300, Roman Cheplyaka wrote: * Simon Hengel s...@typeful.net [2012-10-07 15:45:21+0200] On Fri, Oct 05, 2012 at 05:17:18PM +0300, Roman Cheplyaka wrote: I can do that indeed, and I guess I could reimplement everything I have at the moment on top of HUnit. However, an important part of functionality isn't there at the moment — golden file management. You should be able to say, for this test, take its current output and write it to the corresponding golden file. In order to do that, you need to have access to the list of golden tests in the suite. This is where implementation details of different test frameworks start to matter. Probably one can make an abstraction over test frameworks that would give the list of all golden tests. (Although when you start abstracting over test frameworks, which are abstractions themselves, it becomes somewhat funny.) Ok, makes sense. I'm looking forward to give it a try, and see how it compares to using operating system primitives (say `cp') for golden file management. 1. You often want to update not just one test, but all, or some of the tests (when you've made a change and verified that the changes in output are expected). Doing it in command line is certainly possible, but not trivial nor convenient. 2. For some tests (like goldenVsString) the output is not captured in a file, so using cp directly is not possible. Yes and yes. I have no fixed expectations nor any idea how an ideal interface would look like, but I guess there is room for improvement. So I'm really looking forward to try it ;) Speaking of such functionality, correct me if I'm wrong, but neither HUnit nor hspec won't be able to support it anyway, because they represent tests as opaque IO actions. It would be easy to extend Hspec to support this in the same way you extend test-framework to support this. It requires existentials; the only substantial difference that I can see is that test-framework already uses existentials, while Hspec does not. Well, if you are willing to make this change, then I'll try to do my part of the job and expose a useful abstraction. If it gives us something that is useful from a users perspective, I'm happy to make that change. I would hope that something like [1] works, e.g.: instance Example GoldenTest where evaluateExample c = evaluateExample c . goldenTestToHUnitAssetion exampleMetadata = Just . Metadata That way the Typeable instance is optional. Personally, I still think that it may be a good idea to first explore the design space with test-framework before trying to abstract over it. Cheers, Simon [1] https://github.com/sol/hspec/commit/6927f642aea44803b57c2b77548931f6865b0c38 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Long pauses / idle time in a Haskell TCP server
On Mon, Oct 8, 2012 at 10:10 AM, Alex Iliev alex.il...@gmail.com wrote: Hello, I'm seeing long pauses in a server based on the 'scalable-server' package from Hackage, version 0.2.2 [1]. It normally performs very well, about 100-150 micro-secs client latency over the loopback interface, but a fair number of requests are much slower, 38-40 milli-secs, making the mean latency and throughput quite bad. You might get more information from running threadscope on your program. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Cheers, Christiaan On Sep 28, 2012, at 1:16 PM, Christiaan Baaij wrote: The GLUT-backend calls system.exit when the window is closed, because 'exitMainLoop' is only defined within freeglut, which is not by default installed on non-linux platforms. There is hence no real point in running gloss applications with the GLUT-backend from GHCi. I'll try to find a mountain lion install, and test if there's a difference between GLUT and GLFW On Sep 28, 2012, at 7:56 AM, Carter Schonwald wrote: do these problems also happen if your'e using the glut backend? (because if its only glfw that has problems, then its something wrong in the ffi code, but if its both, that suggests there may be some sort of systematic problem?) @Lyndon, that sounds like a bug... especially since scotty seems to have no C code in package... have you filed a bug report with the maintainers thats reproducible? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Panic loading network on windows (GHC 7.6.1)
Thanks to all, it then looks there's not much I can do. I'm trying to build scion-browser that depends on persistent, that requires TH... Thanks JP On Sat, Oct 6, 2012 at 10:26 PM, Thomas Schilling nomin...@googlemail.com wrote: Just to explain what's going on. It looks like you are compiling a module that uses template haskell, which in turn relies on GHCi bits. In particular, GHCi has a custom linker for loading compiled code. This linker is very fragile and tends to break whenever the platform GCC/linker changes. Similar issues happen a lot on OS X, because Apple tends to change their library formats on most major releases. The only workaround I can think of is to avoid using GHCi or Template Haskell, but I understand that's usually very tricky (especially if one of the dependencies uses TH). On 6 October 2012 09:57, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Fri, 05 Oct 2012 17:31:49 +0200, JP Moresmau jpmores...@gmail.com wrote: Hello, I've installed Cabal and cabal-install 1.16 (which required network) on a new GHC 7.6.1 install and everything went well, except now when building a package requiring network I get: Loading package network-2.4.0.1 ... ghc.exe: Unknown PEi386 section name `.idata $4' (while processing: c:/ghc/ghc-7.6.1/mingw/lib\libws2_32.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.1 for i386-unknown-mingw32): loadArchive c:/ghc/ghc-7.6.1/mingw/lib\\libws2_32.a: failed It's a GHC bug and will be solved in GHC 7.6.2, according to: http://hackage.haskell.org/trac/ghc/ticket/7103 Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc-mtl, hint, mueval for ghc-7.6 ?
While porting some code to 7.6, I'm stuck here: Preprocessing library ghc-mtl-1.0.1.1... [1 of 1] Compiling Control.Monad.Ghc ( Control/Monad/Ghc.hs, dist/build/Control/Monad/Ghc.o ) Control/Monad/Ghc.hs:29:48: No instance for (DynFlags.HasDynFlags Ghc) this seems to block hint and mueval. Is there a known workaround for this problem, or a sugggested replacement package? Thanks - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
On Monday, 8 October 2012 at 06:28, Christiaan Baaij wrote: ghci: segfault ghci from gdb: everything works This makes me suspect something that gets disabled when debugging, such as address space randomization and the like. I did not think ML handled that any differently from Lion, though. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net Sent with Sparrow (http://www.sparrowmailapp.com/?sig) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Could you please file a bug report at: http://hackage.haskell.org/trac/ghc/ Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: cabal-install-1.16.0 (and Cabal-1.16.0.1)
Hi, I'll make a bugfix release for cabal-install and Cabal in a few days to include fixes to issues people found so far. If everyone who had some problem related to the latest release could please post it here so I can make sure that we include a fix for them. If you've already reported it elsewhere, please bring it up here anyway to make sure I don't miss it. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: cabal-install-1.16.0 (and Cabal-1.16.0.1)
Hi Johan, I reported issue 1058 on Github: https://github.com/haskell/cabal/issues/1058 Installing from separate folder with Custom build type fails Thanks, Michael On Mon, Oct 8, 2012 at 6:39 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi, I'll make a bugfix release for cabal-install and Cabal in a few days to include fixes to issues people found so far. If everyone who had some problem related to the latest release could please post it here so I can make sure that we include a fix for them. If you've already reported it elsewhere, please bring it up here anyway to make sure I don't miss it. -- Johan ___ 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: cabal-install-1.16.0 (and Cabal-1.16.0.1)
Hi Johan, On Mon, Oct 8, 2012 at 11:39 AM, Johan Tibell johan.tib...@gmail.com wrote: If you've already reported it elsewhere, please bring it up here anyway to make sure I don't miss it. Following your request, I wrote the pull request Fixed warnings on the generated Paths module against the cabal-1.16 branch: https://github.com/haskell/cabal/pull/1059 Best regards, -- Andrés ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Long pauses / idle time in a Haskell TCP server
I'm seeing long pauses in a server based on the 'scalable-server' package from Hackage, version 0.2.2 [1]. It normally performs very well, about 100-150 micro-secs client latency over the loopback interface, but a fair number of requests are much slower, 38-40 milli-secs, making the mean latency and throughput quite bad. Hi Alex--author of scalable-server here. 38ms sounds like Nagle's algorithm. (http://en.wikipedia.org/wiki/Nagle's_algorithm) In short, the socket is waiting on sending a small amount of data to see if the application wants to send more data. If so, the kernel can repack the data together so that it all can be switched in one TCP packet. You need to set NoDelay (TCP_NODELAY) if you want to disable this behavior; scalable-server doesn't currently have a flag to configure this, but I'm open to pull requests! (Also, are you using hackage scalable-server, or the new scalable server based on conduit on github? I'd recommend switching to the github version if not. A few key bugs exist in the older implementation.) - Jamie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Johan, should I also file the bugreport remove the suggestion to install 32-bit platform there, or is there a different place for bugs of the platform website? On Mon, Oct 8, 2012 at 7:25 AM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Could you please file a bug report at: http://hackage.haskell.org/trac/ghc/ Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov We're hiring! http://tinyurl.com/mirantis-openstack-engineer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Safe Haskell and instance coherence
Hello, It's a relatively well-known fact that GHC allows for multiple type class instances for the same type to coexist in a single program. This can be used, for example, to construct values of the type Data.Set.Set that violate the data structure invariant. I was mildly surprised to find out that this works even when Safe Haskell is turned on: https://gist.github.com/3854294 Note that the warnings tell us that both instances are [safe] which gives a false sense of security. I couldn't find anything on the interplay between orphan instances and Safe Haskell both in the Haskell'12 paper and online. Is this something that the authors of Safe Haskell are aware of/are intending to fix? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-mtl, hint, mueval for ghc-7.6 ?
Hi Johannes, The repository version of ghc-mtl already compiles with ghc 7.6.1. I'm working at the moment on making hint compile again as well (am I the only one on this list that doesn't get excited with every new release of ghc? :)), then I'll upload both to hackage. Thanks, Daniel On Oct 8, 2012, at 2:21 PM, Johannes Waldmann wrote: While porting some code to 7.6, I'm stuck here: Preprocessing library ghc-mtl-1.0.1.1... [1 of 1] Compiling Control.Monad.Ghc ( Control/Monad/Ghc.hs, dist/build/Control/Monad/Ghc.o ) Control/Monad/Ghc.hs:29:48: No instance for (DynFlags.HasDynFlags Ghc) this seems to block hint and mueval. Is there a known workaround for this problem, or a sugggested replacement package? Thanks - J.W. ___ 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] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Eugene: I think thats a bug / ticket for the haskell platform trac, rather than ghc's trac. look forward to seeing how to reproduce those problems / helping fix em! On Mon, Oct 8, 2012 at 3:08 PM, Eugene Kirpichov ekirpic...@gmail.comwrote: Johan, should I also file the bugreport remove the suggestion to install 32-bit platform there, or is there a different place for bugs of the platform website? On Mon, Oct 8, 2012 at 7:25 AM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Could you please file a bug report at: http://hackage.haskell.org/trac/ghc/ Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov We're hiring! http://tinyurl.com/mirantis-openstack-engineer ___ 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] object file cannot be loaded.
Could anyone help me on this? On Sun, Oct 7, 2012 at 10:34 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: There is none On Sun, Oct 7, 2012 at 4:27 AM, Thomas Schilling nomin...@googlemail.com wrote: Does `ghc-pkg check` report any issues? On 6 October 2012 15:24, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I am installing postgres hackage (cannot remember the exact name right now). When it compiling the template haskell part I got the following error message. I tried to clear all user space hackages. Not helping. Loading package text-0.11.2.3 ... linking ... ghc: /home/magicloud/.cabal/lib/text-0.11.2.3/ghc-7.6.1/HStext-0.11.2.3.o: unknown symbol `bytestringzm0zi10zi0zi1_DataziByteStringziInternal_PS_con_info' ghc: unable to load package `text-0.11.2.3' -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
I'm the source of the 32-bit recommendation, and the HP Mac distribution builder To summarize what I read in this thread: 1. 32-bit GHC/HP didn't work with 64-bit Cario libs 2. Some libs available via brew were 64-bit, and 32-bit ones would have to be compiled 3. There is still some bug with 64-bit ghci and some graphics libs 4. There is a ghc bug with 64-bit on mac (bug #7040), which isn't fixed until 7.6 There seemed to be the implication that a 64-bit ghc would work with 32-bit libs, but I don't think that's true. Mac doesn't (generally) support mixed modes in the same executable. All system libs are shipped dual-architecture. I don't think there are any pre-installed libs that are shipped 64-bit only. The problem seen with Cairo would cut both ways: If one had installed the 32-bit version of Cairo, one would see the same problem with the 64-bit HP: wrong architecture. Since code compiled with the 32-bit system is both faster, and uses less memory, and it has been the case that all libs are either shipped dual-arch, or easily available as 32-bit, and there were known problems with the 64-bit version for some use cases, it seemed to me to be best to suggest the 32-bit version by default. The major source of the problems in the OP, seem to be that MacPorts and/or brew don't appear to follow the Mac OS X lib standard of installing libs dual arch. A brief look at the MacPorts page indicated that there were various rules (OS version and processor version) that determined which arch. it built by default. Perhaps we should tell people to install the HP architecture that matches the architecture that they use for MacPorts or brew. However, I bet most people don't know, so we'd need a pointer to where they could find out the defaults for those systems, or how to establish what their system is using. Finally, I note that HP 2012.4.0.0 (out in a month) will ship with GHC 7.4.2, and so will still have the above bugs. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
