Re: [Haskell-cafe] Re: Monades - I've got it! (hopefully)
in F# they renamed Monad to Workflow, I don't think this is helpful, I didn't claim ... at least it's a funny attempt to introduce warm fuzzy thing terminology. it only really works for state-like monads. Workflow doesn't make sense at all for [a], for example. Well, it could be seen as a non-deterministic workflow (with none, one or several outcomes). Cf. Wadler: how to replace failure by a list of successes http://www.springerlink.com/content/y7450255v2670167/ Best regards, J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: data-spacepart - space partitioning data structure[s] (initial release)
No solid plans yet. Mostly I wanted to get some kind of start on a collection of space partitioning data structures. Some ideas - haddock documentation - automated tests - bounding volume hierarchies. - Extend into 3D My current use of the quadtree is for collision detection. Though also being able to effectively satisfy other types of requests would be great. -Corey O'Connor On Tue, Jan 27, 2009 at 7:52 PM, Artyom Shalkhakov artyom.shalkha...@gmail.com wrote: Hello, 2009/1/27 Corey O'Connor coreyocon...@gmail.com: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-spacepart The goal of this package is to be a collection of space partitioning data structures. Currently, however, there is only a simple quadtree implementation. Are you going to experiment with kd-trees, octrees and other spatial acceleration data structures? Is it for raytracing or for collision detection, or maybe for 3d graphics on consumer hardware? Cheers, Artyom Shalkhakov. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How outdated is Hugs?
Hi to mind), if Hugs is likely to continue to have compatibility problems with GHC, then is there any way an interface similar to that already available for WinHugs could be created for GHCi? If that gets underway, one additional improvement could be to improve the REPL at handling declared functions in the REPL itself, as opposed to in a separate file You seem to be asking for GuiHaskell: http://www-users.cs.york.ac.uk/~ndm/guihaskell/ I never managed to finish it, or even come close. But it was able to very basically execute some GHCi/Hugs commands. I'd love it if someone stole either the code, or the idea, and ran with it. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monades - I've got it! (hopefully)
On Wed, Dec 24, 2008 at 12:05 PM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: About the prestress, that's one of the motivations behind renaming them (warm fuzzy thing is the current tongue-in-cheek alternative). in F# they renamed Monad to Workflow, see e.g. Chapter 9 (p. 230) in the Expert F# book. http://www.expert-fsharp.com/default.aspx I thought it was called computation expressions,and workflow was just a special case (e.g. asynchronous work flows for the async monad)? See e.g. http://blogs.msdn.com/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspx -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hmatrix, Windows and GCC
Hi The INSTALL file in the hmatrix repository has some very clear instructions for installation on Windows. http://perception.inf.um.es/~aruiz/darcs/hmatrix/INSTALL However note this section at the bottom: Unfortunately the lapack dll supplied by the R system does not include zgels_, zgelss_, and zgees_, so the functions depending on them (linearSolveLS, linearSolveSVD, and schur for complex data) will produce a non supported in this OS runtime error. Of course linearSolve is exactly what you will be wanting so this won't work for you. I ran into exactly this problem myself. I actually didn't get as far as a run-time error as I got a linker error. I don't have any solution for you though, sorry. regards allan Rafael Gustavo da Cunha Pereira Pinto wrote: Hi all, I am writing a program that uses hmatrix for solving some linear systems. The hmatrix package depends on BLAS, which, in turn, depend on GCC 4.2 to be built (at least ATLAS does). GHC 6.10 for Windows is pre-packaged with GCC 3.4.5, and it leaves me with the impression that I would have incompatible ABIs. My questions: 1) Why GHC 6.10 still uses GCC 3.4.5 in Windows? I know mingw considers GCC 4.2 to be alpha, but, lets face it, 4.2 is almost obsolete! 2) Is it possible to rebuild GHC 6.10, using Windows and GCC 4.2? Is there any guide for doing this? 3) Has any of you tried hmatrix on Windows? How did you do it? Thanks, Rafael -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hmatrix, Windows and GCC
I was planning to recompile everything (ATLAS, LAPACK and GHC included) this weekend, so I can have a similar environment on Windows and Linux... Having to borrow libraries Since I am married, this means it will actually happen on some weekend till 2010. What I really would like to try is a (purely?) functional approach to create a (P)LU decomposition of a matrix. I am not too much worried (at first) with performance or memory constraints, since I only want to see how beautiful it gets (or not!). (This one might happen somewhere in this century...) Thanks anyway On Wed, Jan 28, 2009 at 07:57, allan a.d.cl...@ed.ac.uk wrote: Hi The INSTALL file in the hmatrix repository has some very clear instructions for installation on Windows. http://perception.inf.um.es/~aruiz/darcs/hmatrix/INSTALLhttp://perception.inf.um.es/%7Earuiz/darcs/hmatrix/INSTALL However note this section at the bottom: Unfortunately the lapack dll supplied by the R system does not include zgels_, zgelss_, and zgees_, so the functions depending on them (linearSolveLS, linearSolveSVD, and schur for complex data) will produce a non supported in this OS runtime error. Of course linearSolve is exactly what you will be wanting so this won't work for you. I ran into exactly this problem myself. I actually didn't get as far as a run-time error as I got a linker error. I don't have any solution for you though, sorry. regards allan Rafael Gustavo da Cunha Pereira Pinto wrote: Hi all, I am writing a program that uses hmatrix for solving some linear systems. The hmatrix package depends on BLAS, which, in turn, depend on GCC 4.2 to be built (at least ATLAS does). GHC 6.10 for Windows is pre-packaged with GCC 3.4.5, and it leaves me with the impression that I would have incompatible ABIs. My questions: 1) Why GHC 6.10 still uses GCC 3.4.5 in Windows? I know mingw considers GCC 4.2 to be alpha, but, lets face it, 4.2 is almost obsolete! 2) Is it possible to rebuild GHC 6.10, using Windows and GCC 4.2? Is there any guide for doing this? 3) Has any of you tried hmatrix on Windows? How did you do it? Thanks, Rafael -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How outdated is Hugs?
On Tue, 2009-01-27 at 21:41 -0600, John Goerzen wrote: I have tried to maintain Hugs compatibility in all my libraries, but I must admit I am dropping it for many, due to various problems. It is mainly that libraries I use from others haven't even been tried with Hugs or have weird issues: [..] Things would be a lot better if the libraries would just be maintained. It would be a lot easier if cabal-install worked for hugs then testing would be much simpler for most developers. However at the moment hugs does not provide the installed package information files that cabal-install needs to be able to track installed packages and plan new installations. Cabal does install these files for new packages, but the hugs distribution does not include them for the core packages that it ships. So a new hugs release with more up-to-date libraries and support for cabal-install would make it much easier for everyone else to check their packages with hugs. Also, the default per-user library path that hugs searches is not to everone's liking $HOME/lib/hugs/packages. Unfortunately if cabal does not put things there by default then hugs will not be able to find them. If anyone has suggestions that'd be great. Perhaps we could ask for hugs to read its default search path from ~/.hugs/some-config-file Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Achim Schneider wrote: So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. Does this mean you're volunteering to create a fieldtrip-based toolkit with widgets and layout? John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Changing type of 'when'
Hi, Sugestion: 'when' in Control.Monad is typed as :: Bool - IO () - IO (). Why not type it as: :: forall a. = Bool - IO a - IO () ? It is easy for 'when' to ignore the result of the first computation, and this would not break existing code, and also save a lot of return ()s. Best, Mauríco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Working with HLint from Emacs
Alex == Alex Ott alex...@gmail.com writes: Alex Hello For Emacs users it could be interesting - I wrote Alex small module for more comfortable work with HLint from Alex Emacs. It has same functionality as compilation-mode - Alex navigation between errors, etc. Alex To use it, just add following code to emacs init file: Alex (require 'hs-lint) (defun my-haskell-mode-hook () Alex (local-set-key \C-cl 'hs-lint)) (add-hook Alex 'haskell-mode-hook 'my-haskell-mode-hook) I've done that. Now how do you get it to do anything? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hmatrix, Windows and GCC
Well, I guess I am not the only one! This blog show exactly what I am looking for! http://quantile95.com/2008/10/31/ann-blas-bindings-for-haskell-version-06/ On Wed, Jan 28, 2009 at 08:21, Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com wrote: I was planning to recompile everything (ATLAS, LAPACK and GHC included) this weekend, so I can have a similar environment on Windows and Linux... Having to borrow libraries Since I am married, this means it will actually happen on some weekend till 2010. What I really would like to try is a (purely?) functional approach to create a (P)LU decomposition of a matrix. I am not too much worried (at first) with performance or memory constraints, since I only want to see how beautiful it gets (or not!). (This one might happen somewhere in this century...) Thanks anyway On Wed, Jan 28, 2009 at 07:57, allan a.d.cl...@ed.ac.uk wrote: Hi The INSTALL file in the hmatrix repository has some very clear instructions for installation on Windows. http://perception.inf.um.es/~aruiz/darcs/hmatrix/INSTALLhttp://perception.inf.um.es/%7Earuiz/darcs/hmatrix/INSTALL However note this section at the bottom: Unfortunately the lapack dll supplied by the R system does not include zgels_, zgelss_, and zgees_, so the functions depending on them (linearSolveLS, linearSolveSVD, and schur for complex data) will produce a non supported in this OS runtime error. Of course linearSolve is exactly what you will be wanting so this won't work for you. I ran into exactly this problem myself. I actually didn't get as far as a run-time error as I got a linker error. I don't have any solution for you though, sorry. regards allan Rafael Gustavo da Cunha Pereira Pinto wrote: Hi all, I am writing a program that uses hmatrix for solving some linear systems. The hmatrix package depends on BLAS, which, in turn, depend on GCC 4.2 to be built (at least ATLAS does). GHC 6.10 for Windows is pre-packaged with GCC 3.4.5, and it leaves me with the impression that I would have incompatible ABIs. My questions: 1) Why GHC 6.10 still uses GCC 3.4.5 in Windows? I know mingw considers GCC 4.2 to be alpha, but, lets face it, 4.2 is almost obsolete! 2) Is it possible to rebuild GHC 6.10, using Windows and GCC 4.2? Is there any guide for doing this? 3) Has any of you tried hmatrix on Windows? How did you do it? Thanks, Rafael -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Changing type of 'when'
Maurício wrote: ? It is easy for 'when' to ignore the result of the first computation, and this would not break existing code, and also save a lot of return ()s. As Neil Mitchell pointed out[1], ignoring results implicitly may indicate an error. Perhaps it's cleaner to define ignore m = m return () and use it like this: when condition $ ignore doSmth [1]http://neilmitchell.blogspot.com/2008/12/mapm-mapm-and-monadic-statements.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: WYSIWYG literate programming
G == Gour writes: Massimiliano == Massimiliano Gubinelli m.gubine...@gmail.com writes: Massimiliano As far as Haskell is concerned, a good interface, would Massimiliano allow to bypass programs like lhs2tex or in general allow Massimiliano for beautyful editing Of course not everyone has the Massimiliano same concerns... G Have you tried Emacs with Pretty Lambda for Haskell-mode? G http://haskell.org/haskellwiki/Emacs#Unicodifying_symbols_.28Pretty_Lambda_for_Haskell-mode.29 At http://xtalk.msk.su/~ott/common/emacs/rc/emacs-rc-pretty-lambda.el.html you can find slightly modified version of version of pretty lambda code from haskell wiki - i added several symbols, and fix regex to work properly with symbols like ===, etc. -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hmatrix, Windows and GCC
Hi, allan wrote: Hi The INSTALL file in the hmatrix repository has some very clear instructions for installation on Windows. http://perception.inf.um.es/~aruiz/darcs/hmatrix/INSTALL However note this section at the bottom: Unfortunately the lapack dll supplied by the R system does not include zgels_, zgelss_, and zgees_, so the functions depending on them (linearSolveLS, linearSolveSVD, and schur for complex data) will produce a non supported in this OS runtime error. Note also the next sentence: If you find an alternative free and complete lapack.dll which works well for this system please let me know. Perhaps some Windows expert can give advice on the required dll's for Haskell programs using LAPACK in Windows. Thanks, Alberto Of course linearSolve is exactly what you will be wanting so this won't work for you. I ran into exactly this problem myself. I actually didn't get as far as a run-time error as I got a linker error. I don't have any solution for you though, sorry. regards allan Rafael Gustavo da Cunha Pereira Pinto wrote: Hi all, I am writing a program that uses hmatrix for solving some linear systems. The hmatrix package depends on BLAS, which, in turn, depend on GCC 4.2 to be built (at least ATLAS does). GHC 6.10 for Windows is pre-packaged with GCC 3.4.5, and it leaves me with the impression that I would have incompatible ABIs. My questions: 1) Why GHC 6.10 still uses GCC 3.4.5 in Windows? I know mingw considers GCC 4.2 to be alpha, but, lets face it, 4.2 is almost obsolete! 2) Is it possible to rebuild GHC 6.10, using Windows and GCC 4.2? Is there any guide for doing this? 3) Has any of you tried hmatrix on Windows? How did you do it? Thanks, Rafael -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. ___ 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] Re: Changing type of 'when'
? It is easy for 'when' to ignore the result of the first computation, and this would not break existing code, and also save a lot of return ()s. As Neil Mitchell pointed out[1], ignoring results implicitly may indicate an error. Perhaps it's cleaner to define ignore m = m return () But isn't exactly that the behavior of ()? Anyway, I like the 'ignore' idea. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Changing type of 'when'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maurício wrote: | ignore m = m return () | | | But isn't exactly that the behavior of ()? ~ignore :: Monad m = m a - m () ~() :: Monad m = m a - m b - m b It may also be worth noting that ignore can be generalized to Functor: ~ignore :: Functor f = f a - f () ~ignore x = () $ x - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmAdr8ACgkQye5hVyvIUKn64ACeJ9MHwEgbTUUtnqJVuAe+z7bq 1MgAmwQKzvMOj+l/ih+SwrM1myxplLGB =oFVr -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Working with HLint from Emacs
On Wed, Jan 28, 2009 at 6:30 AM, Colin Paul Adams co...@colina.demon.co.uk wrote: Alex == Alex Ott alex...@gmail.com writes: Alex Hello For Emacs users it could be interesting - I wrote Alex small module for more comfortable work with HLint from Alex Emacs. It has same functionality as compilation-mode - Alex navigation between errors, etc. Alex To use it, just add following code to emacs init file: Alex (require 'hs-lint) (defun my-haskell-mode-hook () Alex (local-set-key \C-cl 'hs-lint)) (add-hook Alex 'haskell-mode-hook 'my-haskell-mode-hook) I've done that. Now how do you get it to do anything? -- Colin Adams Presumably now every time you use C-c l to load the current buffer into GHCi, it'll show hlint warnings about that file (in addition to whatever -Wall warnings you've enabled). It's a straightforward use of Emacs hooks. -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: WYSIWYG literate programming
http://haskell.org/haskellwiki/Emacs#Unicodifying_symbols_.28Pretty_Lambda_for_Haskell-mode.29 I'm pretty sure this text wasn't there last time I looked, yet last time I looked was already long after Haskell-mode integrated such a feature. In any case I've added a note to mention that all you need to do is (setq haskell-font-lock-symbols t). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A ghc-6.10.1 bug or a feature?
Hello people, I've recently tried this: $ uname -smpr Linux 2.6.28-ARCH x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude a - readFile /sys/devices/system/cpu/online Prelude length a `seq` a ^CInterrupted. Prelude writeFile /tmp/test.txt 12345\n Prelude b - readFile /tmp/test.txt Prelude length b `seq` b 12345\n Prelude The main problem is the C^Interrupted. above. The input doesn't get read out till the end of the file for some reason when dealing with files in /sys directory (tried also others: /sys/devices/plaform/coretemp.0/temp1_input or /sys/devices/system/cpu/cpu0/cpufreq/cpufreq_cur_freq). Sometimes, the string from file in /sys gets read (with a slow delay), but most of the times it didn't. Everything works fine for a file in /tmp. Cat-ing files from shell works perfectly in /sys and /tmp. I tried also other machine: % uname -smpr Linux 2.6.28-ARCH i686 Intel(R) Pentium(R) 4 CPU 2.00GHz with the same effect. I didn't have this problem with ghc-6.8.2. Any idea? -- Juraj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A ghc-6.10.1 bug or a feature?
On Wed, Jan 28, 2009 at 7:56 AM, Juraj Hercek juhe_hask...@hck.sk wrote: Hello people, I've recently tried this: $ uname -smpr Linux 2.6.28-ARCH x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude a - readFile /sys/devices/system/cpu/online Prelude length a `seq` a ^CInterrupted. Prelude writeFile /tmp/test.txt 12345\n Prelude b - readFile /tmp/test.txt Prelude length b `seq` b 12345\n Prelude The main problem is the C^Interrupted. above. The input doesn't get read out till the end of the file for some reason when dealing with files in /sys directory (tried also others: /sys/devices/plaform/coretemp.0/temp1_input or /sys/devices/system/cpu/cpu0/cpufreq/cpufreq_cur_freq). Sometimes, the string from file in /sys gets read (with a slow delay), but most of the times it didn't. Everything works fine for a file in /tmp. Cat-ing files from shell works perfectly in /sys and /tmp. I tried also other machine: % uname -smpr Linux 2.6.28-ARCH i686 Intel(R) Pentium(R) 4 CPU 2.00GHz with the same effect. I didn't have this problem with ghc-6.8.2. Any idea? Well readFile is a lazy getContents: The getContentshttp://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v%3AgetContents operation returns all user input as a single string, so per the documentation reading the whole file is the documented behavior. -- Juraj ___ 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] GHC's -fwarn-unused-imports ignores function signatures
I was writing code similar to the following and compiling with -Wall
-Werror. Clearly I *am* using Data.ByteString for the function signatures.
{-# OPTIONS_GHC -fwarn-unused-imports -Werror #-}
import qualified Data.ByteString as B
import qualified Data.ByteString.UTF8 as BU
toString :: B.ByteString - String
toString = BU.toString
fromString :: String - B.ByteString
fromString = BU.fromString
main :: IO ()
main = putStrLn $ toString $ fromString Hello World!
The warning I get is:
Unused.hs:2:0:
Warning: Module `Data.ByteString' is imported, but nothing from it is
used,
except perhaps instances visible in `Data.ByteString'
To suppress this warning, use: import Data.ByteString()
Am I doing something wrong or is this a bug in GHC?
Thanks,
Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Web Frameworks
On Jan 27, 2009, at 1:05 PM, Michaeljohn Clement wrote: +1 This is the conclusion I have come to in building collaborative Web applications. I agree that there seems to be a gap here in the Haskell Web frameworks people are building. Yes. It's a dead end and it seems a shame to waste effort on it. I do not believe compiling Haskell to ECMAScript/JavaScript is a productive avenue. There is too much pain in trying to abstract away the JavaScript model only to write everything in Haskell and end up with worse performance as a reward. I believe GWT, among other projects, has shown that you can create faster executing JavaScript by compiling from a statically-typed language than you can by hand-coding JavaScript (for one, you can do a multitude of inlining and simplification transformations that are not easy in a dynamic language). There is much room for research and development, of course, especially in the context of functional languages. There is very little wrong with ECMAScript if people would only learn it properly and play to its strengths instead of trying to turn it into things it is not. I like JavaScript, and I love ECMAScript 4 (which unfortunately won't see the light of day), but they are not functional languages. And for the foreseeable future, there is one and exactly one scripting language for the browser, and anyone who wants to use a different language will have to do so by compiling to JavaScript. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell on ARM (was Re: ANN: Topkata)
Dan Mead wrote: has there been any movement on this topic? i'm also interested in haskell on arm do you guys thing telling ghc to emit C and then compiling that for arm is a better route than getting direct compilation to work? If you look on the GHC-on-ARM page[1], you'll find my attempts to bootstrap GHC 6.6 (the last version where cross-compiling GHC actually worked) to ARM. The only success I had was in using jhc (not GHC) to generate portable C, which cross-compiled and ran fine (on my Nokia N810). GHC's C wouldn't compile out of the box, and I'm not sure what libraries or other hackery is required to make it do so. Details of the failed cross-compilation and success with jhc are on the wiki page[1]. I'd love to have this working, but I have no time at all this term. Braden Shepherdson shepheb [1] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc -dan On Fri, Jul 25, 2008 at 3:55 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: Joe Buehler wrote: Simon Marlow wrote: For the registerised port, you really need a native code generator (the mangler is on death row, yay). At a rough guess, I'd say porting the NCG would take a couple of weeks or so for someone unfamiliar with the code. Hopefully we'll improve that when we refactor the NCG as part of the backend overhaul. Is there any documentation on the NCG? I ported 6.6 to HPUX 11 some time ago and looked at the NCG but didn't do it for PA-RISC because it was going to take too much time to understand. I was leaning towards the approach of trying to translate the code generator for another processor into PA-RISC. There's some old documentation, some of it is still relevant but probably much of it is out of date now: http://darcs.haskell.org/ghc/docs/comm/the-beast/ncg.html the best doc is the code, I'm afraid (but it has lot of illuminating comments and you can get a long way with cut-and-paste). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC's -fwarn-unused-imports ignores function signatures
This is a bug in GHC. See:
http://hackage.haskell.org/trac/ghc/ticket/2267
I have the same problem in several of my source files. :-(
Michael Snoyman wrote:
I was writing code similar to the following and compiling with -Wall
-Werror. Clearly I *am* using Data.ByteString for the function signatures.
{-# OPTIONS_GHC -fwarn-unused-imports -Werror #-}
import qualified Data.ByteString as B
import qualified Data.ByteString.UTF8 as BU
toString :: B.ByteString - String
toString = BU.toString
fromString :: String - B.ByteString
fromString = BU.fromString
main :: IO ()
main = putStrLn $ toString $ fromString Hello World!
The warning I get is:
Unused.hs:2:0:
Warning: Module `Data.ByteString' is imported, but nothing from it
is used,
except perhaps instances visible in `Data.ByteString'
To suppress this warning, use: import Data.ByteString()
Am I doing something wrong or is this a bug in GHC?
Thanks,
Michael
___
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: convertible (first release)
wren ng thornton wrote: John Goerzen wrote: Hi folks, I have uploaded a new package to Haskell: convertible. At its heart, it's a very simple typeclass that's designed to enable a reasonable default conversion between two different types without having to remember a bunch of functions. I once again point out that realToFrac is *wrong* for converting from Float or Double. Yes, realToFrac is just broken, or at least the Real instances of Float and Double are. Of course, with the restriction to single parameter type classes in Haskell98, it's hard to come up with anything better - we'd end up with fooToBar for all Real / Fractional pairs. realToFrac (1/0::Float) ::Double 3.402823669209385e38 realToFrac (0/0::Float) ::Double -5.104235503814077e38 realToFrac (0/0::Double) ::Float -Infinity [snip] GHC makes the mess just a bit messier. The following program prints different answers when compiled with -O or without: main = do print (realToFrac (1/0::Float) :: Double) print (realToFrac (0/0::Float) :: Double) print (realToFrac (0/0::Double) :: Float) Without -O: 3.402823669209385e38 -5.104235503814077e38 -Infinity With -O: Infinity NaN NaN The reason for this behaviour are rules replacing realToFrac by direct conversions from Float to Double or vice versa, where applicable. These two evils -- realToFrac and changing the behaviour with -O -- amount to something good: proper treatment of NaNs and Infinities. Your RealToFrac class is a definitive improvement over this situation. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems running vectorised dph program
Hi Manuel,
thanks for your quick response.
Hi Fabian,
I've just begun to play with Data Parallel Haskell but instantly ran
into a
problem. My very stupid but very simple example ought to sum the
values of
all Nodes in a Tree. The non-vectorised code behaves like I
expected, the
vectorised code doesn't terminate. I compiled and ran it the same
way as the
example in the tutorial:
ghc -c -O -fdph-par Main.hs
ghc -c -Odph -fcpr-off -fdph-par MinimalParTree.hs
ghc -o MinimalParTree -fdph-par -threaded MinimalParTree.o Main.o
./MinimalParTree
My question is: Is this a bug or is something wrong with the program?
This appears to be a bug in the DPH libraries. Can you please file a
bug report at http://hackage.haskell.org/trac/ghc?
An bug report is filed.
For the time being, you can change sumTree as follows to get your
program working:
sumTree :: Tree Int - Int
sumTree (Node x ns)
| lengthP ns == 0 = x
| otherwise = x + sumP (mapP sumTree ns)
Unfortunately this workaround only leads to another problem. Instead of a non
terminating program I now get a vectorisation error:
ghc -c -fcpr-off -fdph-par MinimalParTree.hs
*** Vectorisation error ***
Variable not vectorised: Control.Exception.Base.patError
Is there another workaround for that one?
Thanks
Fabian
module Main where
import MinimalParTree
main = do
print $ sumTreeWrapper 20
{-# LANGUAGE PArr, ParallelListComp #-}
{-# OPTIONS -fvectorise #-}
module MinimalParTree (sumTreeWrapper) where
import qualified Prelude
import Data.Array.Parallel.Prelude
import Data.Array.Parallel.Prelude.Int
data Tree a = Node a [: Tree a :]
testTree :: Int - Tree Int
testTree elem = Node elem emptyP
sumTree :: Tree Int - Int
sumTree (Node x ns) = x + sumP (mapP sumTree ns)
{-# NOINLINE sumTreeWrapper #-}
sumTreeWrapper :: Int - Int
sumTreeWrapper elem =
sumTree (testTree elem)
___
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] Dependencies conflict
Hello, $ cabal install category-extras Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 What does this message mean? It makes little sense to me -- ghc-6.10.1 requires both process ==1.0.1.1 and process ==1.0.1.0? And, more importantly, how do I solve this? Below is my output of ghc-pkg list. Thanks much, Martijn. $ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf: Cabal-1.6.0.1, HUnit-1.2.0.3, QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), editline-0.2.1.0, filepath-1.1.0.1, (ghc-6.10.1), ghc-prim-0.1.0.0, haddock-2.3.0, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.2, integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.0, template-haskell-2.3.0.0, time-1.1.2.2, unix-2.3.1.0, xhtml-3000.2.0.1 /Users/Martijn/.ghc/i386-darwin-6.10.1/package.conf: HTTP-3001.1.5, binary-0.4.4, brainfuck-0.1, cpphs-1.6, data-accessor-0.1.4, data-accessor-template-0.1.4, extensible-exceptions-0.1.1.0, fgl-5.4.2.2, ghc-paths-0.1.0.5, haddock-2.4.1, haskeline-0.6.0.1, haskell-src-exts-0.3.12, haskell-src-exts-0.4.4, haskell-src-exts-0.4.6, haskell-src-exts-0.4.8, haskell98-1.0.1.0, hscurses-1.3.0.2, iconv-0.4.0.2, lambdabot-utils-4.2, oeis-0.2, parsec-3.0.0, process-1.0.1.1, readline-1.0.1.0, show-0.3.1, smallcheck-0.4, tagsoup-0.6, terminfo-0.3, uniplate-1.2.0.3, unlambda-0.1, utf8-string-0.3.3, zlib-0.5.0.0 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hmatrix, Windows and GCC
-- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090128/4b1ba353/attachment.htm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Dependencies conflict
Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Hello, $ cabal install category-extras Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 What does this message mean? It makes little sense to me -- ghc-6.10.1 requires both process ==1.0.1.1 and process ==1.0.1.0? And, more importantly, how do I solve this? ghc-pkg unregister process-1.0.1.1 . If that fails, rm -r .cabal .ghc . If that fails, fix cabal ;) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell on ARM (was Re: ANN: Topkata)
On Wednesday 28 January 2009 08:15:44 am Braden Shepherdson wrote: Dan Mead wrote: has there been any movement on this topic? i'm also interested in haskell on arm do you guys thing telling ghc to emit C and then compiling that for arm is a better route than getting direct compilation to work? If you look on the GHC-on-ARM page[1], you'll find my attempts to bootstrap GHC 6.6 (the last version where cross-compiling GHC actually worked) to ARM. The only success I had was in using jhc (not GHC) to generate portable C, which cross-compiled and ran fine (on my Nokia N810). GHC's C wouldn't compile out of the box, and I'm not sure what libraries or other hackery is required to make it do so. Details of the failed cross-compilation and success with jhc are on the wiki page[1]. I'd love to have this working, but I have no time at all this term. Braden Shepherdson shepheb Have you considered trying to bootstrap ghc with jhc? Regards, -- Conrad Meyer kon...@tylerc.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC's -fwarn-unused-imports ignores function signatures
Excerpts from Martijn van Steenbergen's message of Wed Jan 28 17:33:18 +0100
2009:
This is a bug in GHC. See:
http://hackage.haskell.org/trac/ghc/ticket/2267
I have the same problem in several of my source files. :-(
Sometimes swaping the import lists does hide this wrong warning.
Including in this example.
Michael Snoyman wrote:
I was writing code similar to the following and compiling with -Wall
-Werror. Clearly I *am* using Data.ByteString for the function signatures.
{-# OPTIONS_GHC -fwarn-unused-imports -Werror #-}
import qualified Data.ByteString as B
import qualified Data.ByteString.UTF8 as BU
toString :: B.ByteString - String
toString = BU.toString
fromString :: String - B.ByteString
fromString = BU.fromString
main :: IO ()
main = putStrLn $ toString $ fromString Hello World!
The warning I get is:
Unused.hs:2:0:
Warning: Module `Data.ByteString' is imported, but nothing from it
is used,
except perhaps instances visible in `Data.ByteString'
To suppress this warning, use: import Data.ByteString()
Am I doing something wrong or is this a bug in GHC?
Thanks,
Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Nicolas Pouillard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: incremental-sat-solver
Simple, Incremental SAT Solving as a Library This Haskell library provides an implementation of the Davis-Putnam- Logemann-Loveland algorithm (cf. http://en.wikipedia.org/wiki/DPLL_algorithm ) for the boolean satisfiability problem. It not only allows to solve boolean formulas in one go but also to add constraints and query bindings of variables incrementally. The implementation is not sophisticated at all but uses the basic DPLL algorithm with unit propagation. The package is available at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/incremental-sat-solver Unlike 'sat' and 'sat-micro-hs' it is a library, and unlike 'libsat' it provides an interface for incremental solving. On the other hand, the implementation is much simpler (and probably less efficient) than 'libsat's. You are invited to improve on that, if you like. The code is on github: http://github.com/sebfisch/incremental-sat-solver Cheers, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How outdated is Hugs?
On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version. I've been unable to figure out how to build Cabal with Hugs 2006.09.04: $ *runhugs -98 Setup configure --hugs --prefix=/usr* runhugs: Error occurred ERROR ./Distribution/Compat/ReadP.hs:70 - Syntax error in module definition (unexpected selector #if) The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John Lato jwl...@gmail.com wrote: Achim Schneider wrote: So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. Does this mean you're volunteering to create a fieldtrip-based toolkit with widgets and layout? Most likely, no. fieldtrip uses glut, which only supports one os-level window and is therefore borked for a considerable amount of stuff one wants a TK be able to do. It (currently) also doesn't support orthographic projection, which you need to properly position 2d. In the end, it's a small and great library for stuff you don't need for a TK, and is thus quite unsuited as a platform for one. Fieldtrip widgets are another thing, of course. I'm not volunteering for anything. I'm just hacking away on stuff and following some inspiration I had while I implemented a simplistic widget UI under J2ME, limited to what the game needed. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How outdated is Hugs?
Bryan O'Sullivan wrote: On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version. I've been unable to figure out how to build Cabal with Hugs 2006.09.04: $ *runhugs -98 Setup configure --hugs --prefix=/usr* runhugs: Error occurred ERROR ./Distribution/Compat/ReadP.hs:70 - Syntax error in module definition (unexpected selector #if) The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions? That looks like a standard CPP not enabled error message. Try passing -F$cpp where $cpp is the command for running cpp as a filter. If the FFI is used anywhere, you need to compile with ffihugs before using hugs (see the man page). -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How outdated is Hugs?
wren ng thornton wrote: Bryan O'Sullivan wrote: On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version. I've been unable to figure out how to build Cabal with Hugs 2006.09.04: $ *runhugs -98 Setup configure --hugs --prefix=/usr* runhugs: Error occurred ERROR ./Distribution/Compat/ReadP.hs:70 - Syntax error in module definition (unexpected selector #if) The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions? That looks like a standard CPP not enabled error message. Try passing -F$cpp where $cpp is the command for running cpp as a filter. If the FFI is used anywhere, you need to compile with ffihugs before using hugs (see the man page). That is, -Fcpp -P should work on most systems. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Bugs in Hugs
In testing some of my packages against Hugs, I've uncovered bugs[1]. Unfortunately the bug tracker at: http://hackage.haskell.org/trac/hugs/newticket?type=defect doesn't seem to allow normal users to submit tickets. Does anyone know how to submit bug reports to Hugs these days? [1] Namely, the Prelude.isNaN and Prelude.isInfinite functions don't work: Hugs (0/0::Float) nan Hugs isNaN (0/0::Float) False Hugs (0/0::Double) nan Hugs isNaN (0/0::Double) False Hugs (1/0::Float) inf Hugs isInfinite (1/0::Float) False Hugs (1/0::Double) inf Hugs isInfinite (1/0::Double) False -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: convertible (first release)
John Goerzen wrote: wren ng thornton wrote: I once again point out that realToFrac is *wrong* for converting from Float or Double. realToFrac (1/0::Float) ::Double 3.402823669209385e38 Yes, I understand what you are saying and agree with you. But there is nothing better in the standard library, and I did not feel it was worth adding another dependency to the package simply for the sake of this sort of thing. People that need it can get it for themselves and write their own instance of Convertible if they wish. Then add a wrapper that calls Prelude.isNaN and Prelude.isInfinite in order to guard against these values just like you do for conversion from unbounded types to bounded types. Avoiding a trivial dependency is no excuse for avoiding correctness. These exceptional values are not uncommon and should be dealt with correctly. The code to do this is already written in logfloat:Data.Number.Transfinite[1], simply use the realToFrac method of the RealToFrac class instead of the Prelude's version which is broken. I wonder if you would consider submitting a patch to base? It seems that this is a sore problem there, and ideally should be dealt with properly in base. As Bertram Felgenhauer says, it's not as easy as fixing base; the problem is an error in the Haskell98 specification. The Float and Double types contain exceptional values which cannot be represented in Rational (by definition). The only Haskell98 solution is to raise an error when attempting to convert those values into Rational, which isn't much of an improvement. At some point I may propose the logfloat solution for Haskell Prime. MPTCs have already been accepted, but the logfloat solution does necessitate additional non-insignificant changes. For example there should be a class for partially ordered types[1][2]. To reduce code bloat a PartialOrd instance should be available whenever an Ord instance is; which means opening the whole can of worms about changing the numeric class hierarchy and changes to the type-class mechanism in order to simplify defining all those different instances. So far I've held off on proposing the solution because I haven't worked out the best way to resolve these issues with minimal changes. [1] The Ord instance for Float and Double is also wrong, since NaN means there's no total ordering (and the existence of NaN is necessitated by the existence of Infinity). In addition to the fact that partial orderings are more common than total orderings, this means we should have a partial ordering class anyways. [2] There's also the issue of what type the partial and total comparison functions should return. Logfloat uses Maybe Ordering to make use of the various helper functions and type classes defined on those types, but for performance reasons we would much rather prefer a flat type. It's inelegant to have both Ordering and PartialOrdering types; and it's hackish to just have PartialOrdering and have Ord ensure that the NotComparable value is never generated. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: convertible (first release)
wren ng thornton wrote: John Goerzen wrote: wren ng thornton wrote: I once again point out that realToFrac is *wrong* for converting from Float or Double. realToFrac (1/0::Float) ::Double 3.402823669209385e38 Yes, I understand what you are saying and agree with you. But there is nothing better in the standard library, and I did not feel it was worth adding another dependency to the package simply for the sake of this sort of thing. People that need it can get it for themselves and write their own instance of Convertible if they wish. Then add a wrapper that calls Prelude.isNaN and Prelude.isInfinite in order to guard against these values just like you do for conversion from unbounded types to bounded types. Avoiding a trivial dependency is no excuse for avoiding correctness. trivial? logfloat doesn't appear to even try to work with Hugs. If I depend on logfloat, I break compatibility with Hugs. If I don't, I get behavior no worse than people are used to from base in the default instances. Moreover, it adds yet another dep that people have to resolve if they're not using cabal-install, and yet another library that could break upstream and wind up breaking my code. I do ship some helpful default instances with convertible, but the point of the package is more to provide a standard infrastructure for adding your own instances, as HDBC does. I think you are blowing this way out of proportion. As for calling isNaN, that may make some sense, though it appears it would not fix the problem on Hugs, as you recently pointed out. Though if isNaN works on a float or double, then we ought to be able to construct NaN on the other end rather than cause an error. That's probably reasonable. As Bertram Felgenhauer says, it's not as easy as fixing base; the problem is an error in the Haskell98 specification. The Float and Double That doesn't mean you can't add the LogFloat modules to base. Adding those modules shouldn't break what Haskell98 mandates, right? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: convertible (first release)
wren ng thornton wrote: [1] The Ord instance for Float and Double is also wrong, since NaN means there's no total ordering (and the existence of NaN is necessitated by the existence of Infinity). In addition to the fact that partial orderings are more common than total orderings, this means we should have a partial ordering class anyways. Putting aside whether or not we should have a partial ordering class, you may be technically correct but practically quite wrong. To say that we ought not to be able to use = on a Double or on a Float is crazy. To say that I can't detect, with = and the like, that 2.5 is between 2.0 and 5.0, just because I can't detect its relationship to NaN, strikes me as absurd. Let's not poison the well for 99% of uses because 1% of users have a leaky bucket. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell on ARM (was Re: ANN: Topkata)
Conrad Meyer wrote: On Wednesday 28 January 2009 08:15:44 am Braden Shepherdson wrote: Dan Mead wrote: has there been any movement on this topic? i'm also interested in haskell on arm do you guys thing telling ghc to emit C and then compiling that for arm is a better route than getting direct compilation to work? If you look on the GHC-on-ARM page[1], you'll find my attempts to bootstrap GHC 6.6 (the last version where cross-compiling GHC actually worked) to ARM. The only success I had was in using jhc (not GHC) to generate portable C, which cross-compiled and ran fine (on my Nokia N810). GHC's C wouldn't compile out of the box, and I'm not sure what libraries or other hackery is required to make it do so. Details of the failed cross-compilation and success with jhc are on the wiki page[1]. I'd love to have this working, but I have no time at all this term. Braden Shepherdson shepheb Have you considered trying to bootstrap ghc with jhc? Regards, Unfortunately this is not possible. The Haskell code in GHC relies on some GHC-only extensions. jhc can't compile GHC because it doesn't have those extensions. jhc can't even compile itself, since it too relies on those extensions. Braden Shepherdson shepheb ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: convertible (first release)
On Wed, Jan 28, 2009 at 5:28 PM, wren ng thornton w...@freegeek.org wrote: John Goerzen wrote: wren ng thornton wrote: I wonder if you would consider submitting a patch to base? It seems that this is a sore problem there, and ideally should be dealt with properly in base. As Bertram Felgenhauer says, it's not as easy as fixing base; the problem is an error in the Haskell98 specification. The Float and Double types contain exceptional values which cannot be represented in Rational (by definition). The only Haskell98 solution is to raise an error when attempting to convert those values into Rational, which isn't much of an improvement. Is there a good reason why Rational is defined in a way that it can not represent Nan, Inf and -Inf? (Any other exceptional values I forgot?) Would fixing the definition so that it can represent those values be sufficient to fix this entire problem? Michael D. Adams mdmko...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How outdated is Hugs?
On Wed, 2009-01-28 at 12:35 -0800, Bryan O'Sullivan wrote: On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version. I've been unable to figure out how to build Cabal with Hugs 2006.09.04: $ runhugs -98 Setup configure --hugs --prefix=/usr runhugs: Error occurred ERROR ./Distribution/Compat/ReadP.hs:70 - Syntax error in module definition (unexpected selector #if) The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions? I'm not sure how it was ever supposed to work, that is bootstrapping Cabal directly using runhugs on the Setup.hs script in the Cabal dir. Cabal has always had some cpp in it and (as far as I know) hugs does not have a -cpp flag. I presume the hugs build system has some workaround to cpp all the files first. The way I've tested it recently is to build the Setup.hs with ghc and use that to install Cabal for hugs. From then on one can use runhugs to run other Setup scripts. If you can get the search path right (ie to not look in the current dir) then I expect it would also be possible to bootstrap using a pre-existing Cabal library for hugs. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How outdated is Hugs?
On Wed, 2009-01-28 at 16:26 -0500, wren ng thornton wrote: wren ng thornton wrote: Bryan O'Sullivan wrote: On Tue, Jan 27, 2009 at 1:18 PM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: Not since then, no. However a lot of things work fine, especially if you use a newer Cabal version. I've been unable to figure out how to build Cabal with Hugs 2006.09.04: $ *runhugs -98 Setup configure --hugs --prefix=/usr* runhugs: Error occurred ERROR ./Distribution/Compat/ReadP.hs:70 - Syntax error in module definition (unexpected selector #if) The README file is GHC-centric, so I'm at a bit of a dead end. Do you have any suggestions? That looks like a standard CPP not enabled error message. Try passing -F$cpp where $cpp is the command for running cpp as a filter. If the FFI is used anywhere, you need to compile with ffihugs before using hugs (see the man page). That is, -Fcpp -P should work on most systems. Wow, it actually works! You need to add -traditional -D__HUGS__ too. Of course now I discover of course that Cabal HEAD doesn't compile with hugs... Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: convertible (first release)
On Wed, 2009-01-28 at 18:41 -0500, Michael D. Adams wrote: On Wed, Jan 28, 2009 at 5:28 PM, wren ng thornton w...@freegeek.org wrote: John Goerzen wrote: wren ng thornton wrote: I wonder if you would consider submitting a patch to base? It seems that this is a sore problem there, and ideally should be dealt with properly in base. As Bertram Felgenhauer says, it's not as easy as fixing base; the problem is an error in the Haskell98 specification. The Float and Double types contain exceptional values which cannot be represented in Rational (by definition). The only Haskell98 solution is to raise an error when attempting to convert those values into Rational, which isn't much of an improvement. Is there a good reason why Rational is defined in a way that it can not represent Nan, Inf and -Inf? (Any other exceptional values I forgot?) Would fixing the definition so that it can represent those values be sufficient to fix this entire problem? It may well help conversions of floating point numbers through Rational but the contrary argument is that Rational is a well defined concept and that values like those do not belong in it. The problem seems to be that the various real/float classes in the Prelude cannot provide a class that allows conversions directly between Double and Float without going via a universal type because the class would either have to be multi-parameter or mention one of the types in the class definition. For integral types it's no problem to go via Integer but floating point types are a good deal more tricky. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell on ARM (was Re: ANN: Topkata)
ghc llvm port would enable arm support as well. i know there were some issues with llvm when this was discusses a couple of years ago. has anyone checked if that's the case? On Wed, Jan 28, 2009 at 3:14 PM, Braden Shepherdson braden.shepherd...@gmail.com wrote: Conrad Meyer wrote: On Wednesday 28 January 2009 08:15:44 am Braden Shepherdson wrote: Dan Mead wrote: has there been any movement on this topic? i'm also interested in haskell on arm do you guys thing telling ghc to emit C and then compiling that for arm is a better route than getting direct compilation to work? If you look on the GHC-on-ARM page[1], you'll find my attempts to bootstrap GHC 6.6 (the last version where cross-compiling GHC actually worked) to ARM. The only success I had was in using jhc (not GHC) to generate portable C, which cross-compiled and ran fine (on my Nokia N810). GHC's C wouldn't compile out of the box, and I'm not sure what libraries or other hackery is required to make it do so. Details of the failed cross-compilation and success with jhc are on the wiki page[1]. I'd love to have this working, but I have no time at all this term. Braden Shepherdson shepheb Have you considered trying to bootstrap ghc with jhc? Regards, Unfortunately this is not possible. The Haskell code in GHC relies on some GHC-only extensions. jhc can't compile GHC because it doesn't have those extensions. jhc can't even compile itself, since it too relies on those extensions. Braden Shepherdson shepheb ___ 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] C-like Haskell
I'm trying to do a calculation for Gauss' circle problem, which counts the
integer lattice points with distance to the origin = r. It's sequence
A000328 on the ATT integer sequence database. I can't figure out a way to
do it quickly in Haskell for r around 10^9.
Here's my attempt, which takes about 75s for r=10^8.
circ2 r = (1+4*r) + 4 * (circ2' (rs+1) r 1 0)
where
rs = r^2
--circ2' :: Int64 - Int64 - Int64 - Int64 - Int64
circ2' rad x y sum
| xy = sum
| rad=rs = circ2' (rad+1+2*y) x (y+1) (sum+1+2*(x-y))
| otherwise = circ2' (rad+1-2*x) (x-1) y sum
The commented out line was to try to force it to use machine-size ints, but
instead it made it eat memory like mad. It overflows if everything is
forced to be ints, and isn't much faster. Making rad and sum Integers fixes
the overflow but still takes ~45 secs.
I do already have the number I wanted, but was wondering how this could be
made faster, or even why it's so slow. This is all on GHC 6.8.3 under OS X
Intel, using ghc -O2.
For comparison, the C code below runs in 1 second.
typedef unsigned long long bigint;
bigint gausscount(bigint r) {
bigint sum=0;
bigint x, y;
bigint rs=r*r;
bigint rad=rs+1;
x=r; y=1;
while (yx) {
while (radrs) {
rad-=2*x;
rad++;
x--;
}
sum+=1+2*(x-y);
rad+=2*y+1;
y++;
}
sum*=4;
sum++;
return sum;
}
--
View this message in context:
http://www.nabble.com/C-like-Haskell-tp21717584p21717584.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dependencies conflict
On Wed, 2009-01-28 at 18:22 +0100, Martijn van Steenbergen wrote: Hello, $ cabal install category-extras Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 What does this message mean? It makes little sense to me -- ghc-6.10.1 requires both process ==1.0.1.1 and process ==1.0.1.0? Yes, that's exactly what it looks like to Cabal which is why it is horribly confused. The reason is shadowing between the global and user package dbs. The way ghc package databses work is that the user one is just slapped on top of the global one. Like Data.Map.union. Suppose you've got these packages registered in the global package db: A-1 / | / | B-1 | \ | \ | C-1.0.1.0 Now, suppose you register B-1 in the user package db, then it masks the existing B-1 from the global db. But suppose that you build this instance against C-1.0.1.1... A-1 / \ / \ B-1 \ \ C-1.0.1.0 \ C-1.0.1.1 Oh no! Now A-1 appears to depend on two versions of C! The cabal-install dependency resolver is designed to look for solutions where this does not happen, but here it's already happened in the installed packages, so it cannot ever pick the A-1 package as part of an install plan. It's not just cabal-install that will get confused here. ghc --make will too. If you're lucky you'll get linker errors. If you're unlucky you'll get segfaults. The solution we've been discussing for the next major ghc release is to track package ABIs and possibly even to allow slotting packages in their ABI. That would make this problem disappear and generally allow safer and more flexible management of installed packages. In the mean time I'm thinking of making the representation of installed package databases record broken packages. Then when we overlay package databases we could mark clashes like the above as breaking A-1. We should also try and get the solver to help us find solutions that avoid getting into this situation in the first place. And, more importantly, how do I solve this? Look for packages where you have the same version registered in the user and global package db. Unreigister the user one. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A ghc-6.10.1 bug or a feature?
On Wed, 2009-01-28 at 16:56 +0100, Juraj Hercek wrote: Hello people, I've recently tried this: $ uname -smpr Linux 2.6.28-ARCH x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude a - readFile /sys/devices/system/cpu/online Prelude length a `seq` a ^CInterrupted. http://hackage.haskell.org/trac/ghc/ticket/2971 Files in /proc and /sys are not select()able which messes up ghc's IO system. It's not entirely clear what changed between 6.8 and 6.10 that means we hit this now. (I'd have expected it never to have worked given that ghc has always used non-blocking IO.) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C-like Haskell
On Wed, 2009-01-28 at 16:42 -0800, drblanco wrote: I do already have the number I wanted, but was wondering how this could be made faster, or even why it's so slow. This is all on GHC 6.8.3 under OS X Intel, using ghc -O2. I'm not exactly sure what's different, but for me it works pretty well. I put back in the Int64 type signature. For comparison, the C code below runs in 1 second. You've got a faster machine than me :-) I compiled both the Haskell and C versions to standalone executables with ghc/gcc -O2 and ran them with time. C version: $ time ./circ 3141592649589764829 real0m2.430s user0m2.428s sys 0m0.000s Haskell version: time ./circ2 3141592653589764829 real0m2.753s user0m2.756s sys 0m0.000s Not too bad I'd say! :-) I was using ghc-6.10 for this test. It would appear that ghc-6.8 is a bit slower, I get: 3141592653589764829 real0m5.767s user0m5.768s sys 0m0.000s Now the other difference is that I'm using a 64bit machine so perhaps ghc just produces terrible code for Int64 on 32bit machines. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C-like Haskell
Did you print it? I'm using same code with ghc --make -O2 and it takes forever to finish. On Wed, Jan 28, 2009 at 8:06 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Wed, 2009-01-28 at 16:42 -0800, drblanco wrote: I do already have the number I wanted, but was wondering how this could be made faster, or even why it's so slow. This is all on GHC 6.8.3 under OS X Intel, using ghc -O2. I'm not exactly sure what's different, but for me it works pretty well. I put back in the Int64 type signature. For comparison, the C code below runs in 1 second. You've got a faster machine than me :-) I compiled both the Haskell and C versions to standalone executables with ghc/gcc -O2 and ran them with time. C version: $ time ./circ 3141592649589764829 real0m2.430s user0m2.428s sys 0m0.000s Haskell version: time ./circ2 3141592653589764829 real0m2.753s user0m2.756s sys 0m0.000s Not too bad I'd say! :-) I was using ghc-6.10 for this test. It would appear that ghc-6.8 is a bit slower, I get: 3141592653589764829 real0m5.767s user0m5.768s sys 0m0.000s Now the other difference is that I'm using a 64bit machine so perhaps ghc just produces terrible code for Int64 on 32bit machines. Duncan ___ 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] C-like Haskell
On Wed, 2009-01-28 at 20:11 -0500, sam lee wrote: Did you print it? I'm using same code with ghc --make -O2 and it takes forever to finish. Yes, you can see in the output that it prints the same answer in each case. I was using r = 10^9 as you suggested. C version: $ time ./circ 3141592649589764829 Haskell version: time ./circ2 3141592653589764829 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C-like Haskell
Duncan, I think you must have some magics -- on my machine the
original code also takes forever.
Running with +RTS -S indicates it's allocating several gig of memory
or more.
Applying some bang patterns gives me ~8s for 10^8 and somewhat more
than a minute for 10^9:
{-# LANGUAGE BangPatterns #-}
module Main where
import Data.Int
main = putStrLn $ show $ circ2 (10^8)
circ2 :: Int64 - Int64
circ2 r = ((1+4*r) + 4 * (go (rs+1) r 1 0))
where
rs = r^2
go :: Int64 - Int64 - Int64 - Int64 - Int64
go !rad !x !y !sum
| x y = sum
| rad = rs = go (rad+1+2*y) x (y+1) (sum+1+2*(x-y))
| otherwise = go (rad+1-2*x) (x-1) y sum
10^8:
r...@hugo:~$ time ./circ-bangpatterns +RTS -t
./circ-bangpatterns +RTS -t
31415926535867961
ghc: 9120 bytes, 1 GCs, 2432/2432 avg/max bytes residency (1
samples), 1M in use, 0.00 INIT (0.00 elapsed), 8.15 MUT (8.31
elapsed), 0.00 GC (0.00 elapsed) :ghc
real0m8.315s
user0m8.154s
sys 0m0.050s
10^9:
r...@hugo:~$ time ./circ-bangpatterns +RTS -t
./circ-bangpatterns +RTS -t
3141592653589764829
ghc: 9336 bytes, 1 GCs, 2432/2432 avg/max bytes residency (1
samples), 1M in use, 0.00 INIT (0.00 elapsed), 80.49 MUT (82.68
elapsed), 0.00 GC (0.00 elapsed) :ghc
real1m22.684s
user1m20.490s
sys 0m0.473s
The C program is quite fast:
r...@hugo:~$ time ./circ-orig
1302219321
real0m1.073s
user0m1.039s
sys 0m0.006s
-Ross
On Jan 28, 2009, at 8:06 PM, Duncan Coutts wrote:
On Wed, 2009-01-28 at 16:42 -0800, drblanco wrote:
I do already have the number I wanted, but was wondering how this
could be
made faster, or even why it's so slow. This is all on GHC 6.8.3
under OS X
Intel, using ghc -O2.
I'm not exactly sure what's different, but for me it works pretty
well.
I put back in the Int64 type signature.
For comparison, the C code below runs in 1 second.
You've got a faster machine than me :-)
I compiled both the Haskell and C versions to standalone executables
with ghc/gcc -O2 and ran them with time.
C version:
$ time ./circ
3141592649589764829
real0m2.430s
user0m2.428s
sys 0m0.000s
Haskell version:
time ./circ2
3141592653589764829
real0m2.753s
user0m2.756s
sys 0m0.000s
Not too bad I'd say! :-)
I was using ghc-6.10 for this test. It would appear that ghc-6.8 is a
bit slower, I get:
3141592653589764829
real0m5.767s
user0m5.768s
sys 0m0.000s
Now the other difference is that I'm using a 64bit machine so perhaps
ghc just produces terrible code for Int64 on 32bit machines.
Duncan
___
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] Re: C-like Haskell
Ross Mellgren schrieb: Duncan, I think you must have some magics -- on my machine the original code also takes forever. Running with +RTS -S indicates it's allocating several gig of memory or more. Applying some bang patterns gives me ~8s for 10^8 and somewhat more than a minute for 10^9: Hi, same here, with bang patterns ~100s / 1Mb but The C program is quite fast: r...@hugo:~$ time ./circ-orig 1302219321 looks wrong to me real0m1.073s cafe(0) $ time ./gauss 3141592649589764829 real0m17.894s So my 32-bit machine is really slow ... benedikt On Wed, 2009-01-28 at 16:42 -0800, drblanco wrote: I do already have the number I wanted, but was wondering how this could be made faster, or even why it's so slow. This is all on GHC 6.8.3 under OS X Intel, using ghc -O2. I'm not exactly sure what's different, but for me it works pretty well. I put back in the Int64 type signature. For comparison, the C code below runs in 1 second. You've got a faster machine than me :-) I compiled both the Haskell and C versions to standalone executables with ghc/gcc -O2 and ran them with time. C version: $ time ./circ 3141592649589764829 real0m2.430s user0m2.428s sys0m0.000s Haskell version: time ./circ2 3141592653589764829 real0m2.753s user0m2.756s sys0m0.000s Not too bad I'd say! :-) I was using ghc-6.10 for this test. It would appear that ghc-6.8 is a bit slower, I get: 3141592653589764829 real0m5.767s user0m5.768s sys0m0.000s Now the other difference is that I'm using a 64bit machine so perhaps ghc just produces terrible code for Int64 on 32bit machines. Duncan ___ 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] Re: C-like Haskell
Yeah, you know after sending the email (never a better time) I noticed that the C version wasn't spitting out the right answer. I'm not really sure why, I just replaced bigint with int64_t from stdint.h. -Ross On Jan 28, 2009, at 8:32 PM, Benedikt Huber wrote: Ross Mellgren schrieb: Duncan, I think you must have some magics -- on my machine the original code also takes forever. Running with +RTS -S indicates it's allocating several gig of memory or more. Applying some bang patterns gives me ~8s for 10^8 and somewhat more than a minute for 10^9: Hi, same here, with bang patterns ~100s / 1Mb but The C program is quite fast: r...@hugo:~$ time ./circ-orig 1302219321 looks wrong to me real0m1.073s cafe(0) $ time ./gauss 3141592649589764829 real0m17.894s So my 32-bit machine is really slow ... benedikt On Wed, 2009-01-28 at 16:42 -0800, drblanco wrote: I do already have the number I wanted, but was wondering how this could be made faster, or even why it's so slow. This is all on GHC 6.8.3 under OS X Intel, using ghc -O2. I'm not exactly sure what's different, but for me it works pretty well. I put back in the Int64 type signature. For comparison, the C code below runs in 1 second. You've got a faster machine than me :-) I compiled both the Haskell and C versions to standalone executables with ghc/gcc -O2 and ran them with time. C version: $ time ./circ 3141592649589764829 real0m2.430s user0m2.428s sys0m0.000s Haskell version: time ./circ2 3141592653589764829 real0m2.753s user0m2.756s sys0m0.000s Not too bad I'd say! :-) I was using ghc-6.10 for this test. It would appear that ghc-6.8 is a bit slower, I get: 3141592653589764829 real0m5.767s user0m5.768s sys0m0.000s Now the other difference is that I'm using a 64bit machine so perhaps ghc just produces terrible code for Int64 on 32bit machines. Duncan ___ 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] C-like Haskell
On Wed, 2009-01-28 at 20:23 -0500, Ross Mellgren wrote: Duncan, I think you must have some magics -- on my machine the original code also takes forever. Running with +RTS -S indicates it's allocating several gig of memory or more. It runs in a tiny heap for me: ./circ2 +RTS -A10k -M20k -RTS 3141592653589764829 +RTS -S indicates it allocated 8,512 bytes. Applying some bang patterns gives me ~8s for 10^8 and somewhat more than a minute for 10^9: I wonder if it is the 64 vs 32 bit machine difference. I recall some ghc ticket about Int64 having rather poor performance on 32bit x86 machines. I don't have a 32bit x86 machine to hand so I cannot easily test it. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C-like Haskell
Thanks for the help. It's clear in retrospect that it was being too lazy, but not why changing to Int64 did it. The bang patterns made the difference between runnable and not. GHC 6.10 didn't make much of a difference, but there's no 64-bit build for the Mac. If this seems to come up again I'll have to set up 64-bit Linux in a virtual machine, which seems a bit convoluted. David On Wed, Jan 28, 2009 at 7:37 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Wed, 2009-01-28 at 20:23 -0500, Ross Mellgren wrote: Duncan, I think you must have some magics -- on my machine the original code also takes forever. Running with +RTS -S indicates it's allocating several gig of memory or more. It runs in a tiny heap for me: ./circ2 +RTS -A10k -M20k -RTS 3141592653589764829 +RTS -S indicates it allocated 8,512 bytes. Applying some bang patterns gives me ~8s for 10^8 and somewhat more than a minute for 10^9: I wonder if it is the 64 vs 32 bit machine difference. I recall some ghc ticket about Int64 having rather poor performance on 32bit x86 machines. I don't have a 32bit x86 machine to hand so I cannot easily test it. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C-like Haskell
Ross Mellgren wrote: Duncan, I think you must have some magics -- on my machine the original code also takes forever. Running with +RTS -S indicates it's allocating several gig of memory or more. Applying some bang patterns gives me ~8s for 10^8 and somewhat more than a minute for 10^9 It works great for me. 64 bit, GHC 6.10.1, no bang patterns or other magic. Works about the same with both Int and Int64. % time ./ctest 3141592649589764829 real0m2.614s user0m2.610s sys 0m0.003s % time ./hstest 3141592653589764829 real0m3.878s user0m3.870s sys 0m0.003s % ./hstest +RTS -S ./hstest +RTS -S AllocCopied LiveGCGC TOT TOT Page Flts bytes bytes bytes user elapuserelap 3141592653589764829 8512 688 17136 0.00 0.003.943.9400 (Gen: 1) 0 0.00 0.00 8,512 bytes allocated in the heap 688 bytes copied during GC 17,136 bytes maximum residency (1 sample(s)) 19,728 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 0 collections, 0 parallel, 0.00s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time0.00s ( 0.00s elapsed) MUT time3.94s ( 3.94s elapsed) GCtime0.00s ( 0.00s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time3.94s ( 3.94s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate2,158 bytes per MUT second Productivity 99.9% of total user, 100.0% of total elapsed ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C-like Haskell
Apparently 64-bit GHC is sufficiently advanced to be indistinguishable from magic. Now, if only there was a 64-bit binary for Mac OS X :-/ -Ross On Jan 28, 2009, at 9:06 PM, Jake McArthur wrote: Ross Mellgren wrote: Duncan, I think you must have some magics -- on my machine the original code also takes forever. Running with +RTS -S indicates it's allocating several gig of memory or more. Applying some bang patterns gives me ~8s for 10^8 and somewhat more than a minute for 10^9 It works great for me. 64 bit, GHC 6.10.1, no bang patterns or other magic. Works about the same with both Int and Int64. % time ./ctest 3141592649589764829 real0m2.614s user0m2.610s sys 0m0.003s % time ./hstest 3141592653589764829 real0m3.878s user0m3.870s sys 0m0.003s % ./hstest +RTS -S ./hstest +RTS -S AllocCopied LiveGCGC TOT TOT Page Flts bytes bytes bytes user elapuserelap 3141592653589764829 8512 688 17136 0.00 0.003.943.9400 (Gen: 1) 0 0.00 0.00 8,512 bytes allocated in the heap 688 bytes copied during GC 17,136 bytes maximum residency (1 sample(s)) 19,728 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 0 collections, 0 parallel, 0.00s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time0.00s ( 0.00s elapsed) MUT time3.94s ( 3.94s elapsed) GCtime0.00s ( 0.00s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time3.94s ( 3.94s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate2,158 bytes per MUT second Productivity 99.9% of total user, 100.0% of total elapsed ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HDBC-ODBC, bindCol
Hi John, I've just been going through the HDBC-ODBC code wondering if I could find the spot that needs changing so that Doubles work properly with MS-Access. Could you please tell me, if I understand this correctly? The bindCol function does not actually look at the particular value type, ie. SqlDouble, SqlInteger ..., to determine the type but queries the database via sqlDescribeParam to get the type. Which might fail though and not leave a clue. In that case the SqlType still isn't used, but rather some default? If I was more literate in Haskell I would propably be able to answer this myself, sry, I'll catch up. And I had a hell of a time finding an SQL/ODBC for C Tutorial and never coded in C. Thanks upfront Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C-like Haskell
On Wed, 2009-01-28 at 20:42 -0500, Ross Mellgren wrote: Very possibly -- I'm on a mac so no prebuilt 64-bit binary. I'm not good enough at reading core to tell, but I can tell from the core that it's calling out to external C functions to do the 64-bit math. Right, that'll make it really slow but does not explain the allocations. It could be that it's crossing over from machine register size to managed heap object and so without additional help on 32-bit it wants to allocate thunks. If it's using Int64 then there's no transition, that only happens with Integer (which is always heap allocated anyway). The sum parameter in the inner loop is an accumulating parameter that is not inspected until the final value is returned. In the case of the simple direct Int64 implementation the strictness analyser does notice that it really is strict so can be evaluated as we go along. I bet that's the source of the problem, that for the indirect Int64 impl used on 32bit machines the strictness analyser does not discover the same property. So that would explain the allocations. It's worth investigating the indirect Int64 implementation to see if this could be improved. Does your core indicate that it's making a bunch of external __ccalls? No, it's all unboxed Int# types and primitive # operations. Lovely. In particular the inner loop is all unboxed types with no allocations. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Bugs in Hugs
On Wed, 28 Jan 2009 16:45:29 -0500, wren ng thornton w...@freegeek.org wrote: [...] Does anyone know how to submit bug reports to Hugs these days? Have you tried subscribing to the Hugs Bugs mailing list at http://www.haskell.org/mailman/listinfo/hugs-bugs ? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: HDBC-ODBC, bindCol
Hi, I guess the question is: what type of data does Access need in that situation? So, as an example: say you have an 8-bit Integer column in Access, and someone passes an SqlInt64 to the system. What do you do? Can you pass an Int64 to Access and have it convert? In general, the ODBC spec -- if memory serves -- implies that the database engines aren't smart enough to do so. Some database engines, like PostgreSQL, are extremely versatile here and we can just convert just about everything to a string and it will do the right thing. -- John On Thu, Jan 29, 2009 at 03:10:10AM +0100, G?uenther Schmidt wrote: Hi John, I've just been going through the HDBC-ODBC code wondering if I could find the spot that needs changing so that Doubles work properly with MS-Access. Could you please tell me, if I understand this correctly? The bindCol function does not actually look at the particular value type, ie. SqlDouble, SqlInteger ..., to determine the type but queries the database via sqlDescribeParam to get the type. Which might fail though and not leave a clue. In that case the SqlType still isn't used, but rather some default? If I was more literate in Haskell I would propably be able to answer this myself, sry, I'll catch up. And I had a hell of a time finding an SQL/ODBC for C Tutorial and never coded in C. Thanks upfront Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: convertible (first release)
John Goerzen wrote: wren ng thornton wrote: John Goerzen wrote: wren ng thornton wrote: I once again point out that realToFrac is *wrong* for converting from Float or Double. Yes, I understand what you are saying and agree with you. But there is nothing better in the standard library, and I did not feel it was worth adding another dependency to the package simply for the sake of this sort of thing. People that need it can get it for themselves and write their own instance of Convertible if they wish. Then add a wrapper that calls Prelude.isNaN and Prelude.isInfinite in order to guard against these values just like you do for conversion from unbounded types to bounded types. Avoiding a trivial dependency is no excuse for avoiding correctness. trivial? It only depends on base (the new smaller one even) and common language extensions which are supported by Hugs (CPP, FlexibleContexts, OverlappingInstances, FlexibleInstances, UndecidableInstances, MultiParamTypeClasses). Granted, Yhc and nhc98 are out of the running because of MPTCs. logfloat doesn't appear to even try to work with Hugs. Works fine for me... $ hugs -98 +o -F'cpp -P' Data/Number/LogFloat.hs __ __ __ __ ___ _ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2005 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Bugs: http://hackage.haskell.org/trac/hugs || || Version: September 2006 _ Hugs mode: Restart with command line option +98 for Haskell 98 mode Type :? for help Data.Number.LogFloat Granted, I just found some bugs due to bugs in Hugs regarding exceptional values. These will be fixed in the next release. I do ship some helpful default instances with convertible, but the point of the package is more to provide a standard infrastructure for adding your own instances, as HDBC does. I think you are blowing this way out of proportion. I think you undervalue the importance of correct code. Many programmers beside myself use Haskell because it guarantees more-correct code than other languages. Correctness is expecially important for standard infrastructure. Not providing instances is better than providing incorrect instances. Given all the other instances for Int, Integer, etc, it's not tenable to offer the advice that those who do care about correctness should avoid Data.Convertible.Instances.Num. That doesn't mean you can't add the LogFloat modules to base. Adding those modules shouldn't break what Haskell98 mandates, right? The LogFloat module relies on Transfinite which in turn relies on PartialOrd. In particular the corrected versions of log, realToFrac, isNaN, and isInfinite are all used to ensure correctness of LogFloat. The RealToFrac class in Transfinite uses MPTCs which are non-Haskell98 and therefore restricts it to GHC or Hugs. Since base is used by nhc98 and other Haskell compilers, that means RealToFrac and LogFloat are not an option. In theory I could replace the type class with a polymorphic function using the default instance's definition, and use rewrite rules to replace that function with the efficient versions at particular types. In some ways this would be nicer (no overlapping instances here, though PartialOrd still uses them). But in other ways it's less nice since it just moves the problem elsewhere; namely, there are other Real types which may have additional values that cannot be expressed in Rational. The type class allows resolving this by testing for these values or placing additional constraints on the types, whereas the polymorphic function ---though more correct than the Prelude's--- would still be incorrect since the library cannot know about all such types. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: incremental-sat-solver
On Wed, Jan 28, 2009 at 13:32, Sebastian Fischer s...@informatik.uni-kiel.de wrote: Simple, Incremental SAT Solving as a Library This Haskell library provides an implementation of the Davis-Putnam-Logemann-Loveland algorithm (cf. http://en.wikipedia.org/wiki/DPLL_algorithm) for the boolean satisfiability problem. It not only allows to solve boolean formulas in one go but also to add constraints and query bindings of variables incrementally. Nice! The implementation is not sophisticated at all but uses the basic DPLL algorithm with unit propagation. The package is available at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/incremental-sat-solver Unlike 'sat' and 'sat-micro-hs' it is a library, and unlike 'libsat' it provides an interface for incremental solving. Funsat is also a library. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/funsat The code is structured in a way that it would possibly be straightforward to do incremental solving, but it is not designed for it. (If interested, see the function `Funsat.Solver.solveStep'. It is not exported, but it could be.) If you're interested, my code is also on github, and includes some benchmark CNF problems in the bench/ subdirectory. http://github.com/dbueno/funsat/tree/master Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: convertible (first release)
Duncan Coutts wrote: Michael D. Adams wrote: Is there a good reason why Rational is defined in a way that it can not represent Nan, Inf and -Inf? (Any other exceptional values I forgot?) Would fixing the definition so that it can represent those values be sufficient to fix this entire problem? It may well help conversions of floating point numbers through Rational but the contrary argument is that Rational is a well defined concept and that values like those do not belong in it. The problem seems to be that the various real/float classes in the Prelude cannot provide a class that allows conversions directly between Double and Float without going via a universal type because the class would either have to be multi-parameter or mention one of the types in the class definition. For integral types it's no problem to go via Integer but floating point types are a good deal more tricky. Exactly. Floating numbers also have other issues because of these values, e.g. they aren't Ord[1] and may not be Eq[2]. If we added the exceptional values to Rational we'd re-introduce all the problems they cause. As Duncan says, Rational is a well-defined concept by itself--- it's just a different concept than floating numbers. For what it's worth, GHC.Real does provide literals for 1%0 and 0%0. However, since these values cannot be constructed by the smart constructor (%), functions on Ratios assume they cannot exist and therefore treat them incorrectly or raise errors. [1] For those who think this is trivial, consider what value the `compare` function should return when one of the arguments is NaN. We don't even have a consistent lie for this! In Hugs it always returns EQ, whereas in GHC it always returns GT. Thus, not only is NaN not handled properly, but programs will behave differently depending on the compiler. [2] Since NaN are defined to be unequal to everything including themselves. This isn't damning per se, but it does go against the law of the excluded middle, which people typically assume of Eq. Whether Eq must obey this law or not is unspecified. (Not to mention the fuzziness issues.) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[Haskell-cafe] cursive referencing
Hello!
I'm puzzled, if in Haskell it's possible to create a (pure) data structure,
consisting of 2 substructures referencing each other:
-
data AA = AA {
someData1 :: SomeData1
bb :: BB
}
data BB = BB {
someData2 :: SomeData2
aa :: AA
}
f :: SomeData1 - SomeData2 - AA
f somedata1 somedata2 = ??
-- Always True:
ghci f == aa $ bb f
True
-
Any ideas?
Belka
--
View this message in context:
http://www.nabble.com/Recursive-referencing-tp21722002p21722002.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] cursive referencing
Yes.
f somedata1 somedata2 = aa
where aa = AA somedata1 bb
bb = BB somedata2 aa
2009/1/29 Belka lambda-be...@yandex.ru:
Hello!
I'm puzzled, if in Haskell it's possible to create a (pure) data structure,
consisting of 2 substructures referencing each other:
-
data AA = AA {
someData1 :: SomeData1
bb :: BB
}
data BB = BB {
someData2 :: SomeData2
aa :: AA
}
f :: SomeData1 - SomeData2 - AA
f somedata1 somedata2 = ??
-- Always True:
ghci f == aa $ bb f
True
-
Any ideas?
Belka
--
View this message in context:
http://www.nabble.com/Recursive-referencing-tp21722002p21722002.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
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: Re[Haskell-cafe] cursive referencing
By the way, more advanced stuff of this kind is called Tying the
knot; you can do doubly linked lists with it and much more.
http://www.haskell.org/haskellwiki/Tying_the_Knot
2009/1/29 Belka lambda-be...@yandex.ru:
Hello!
I'm puzzled, if in Haskell it's possible to create a (pure) data structure,
consisting of 2 substructures referencing each other:
-
data AA = AA {
someData1 :: SomeData1
bb :: BB
}
data BB = BB {
someData2 :: SomeData2
aa :: AA
}
f :: SomeData1 - SomeData2 - AA
f somedata1 somedata2 = ??
-- Always True:
ghci f == aa $ bb f
True
-
Any ideas?
Belka
--
View this message in context:
http://www.nabble.com/Recursive-referencing-tp21722002p21722002.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
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
