Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)
Daniel Fischer daniel.is.fisc...@web.de writes: However, I wanted to know what the etc stood for, with taking care of dependencies and uninstalling already mentioned. Upgrading, yes, but what else? Keeping the system consistent with other systems? If I use the system packages, I can have a higher confidence that what works for me will also work for users of the same distro. And converse, so there'll be more eyeballs per problem. Reducing the load on system admins? Although I might know the pros and cons of upgrading to GHC 6.12.y from .x, my IT department are not likely to. And they have to support a dozen different languages for several dozen users. They are also more likely to trust things they get from apt or yum repos, than tarballs off some random web site. Centrally managed bug reporting system? Not that Launchpad is awsomely responsive, but at least there's *something*. Support, in the sense that somebody is actually responsible for the package? (Unlike Hackage, where some packages have a closed-for-nonsubscribers mailing list as 'maintainer'.) (Probably 'etc.', but I can't think of more points at the moment.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)
On 8 April 2010 16:29, Ketil Malde ke...@malde.org wrote: Support, in the sense that somebody is actually responsible for the package? (Unlike Hackage, where some packages have a closed-for-nonsubscribers mailing list as 'maintainer'.) Which packages are these? I don't recall seeing any with this kind of maintainer address... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
It's amazing! But I'm surprised no one else has this problem, as I assume using network + lazy bytestrings is quite frequent when you want to do network programming in Haskell. BTW, you may not have the same libraries versions as me. Maybe this problems doesn't occur in older versions of bytestring or network. I have the last versions : - network-2.2.1.7 - bytestring-0.9.1.6 (and binary-0.5.0.2, but the simple example showed that the problem came from deeper than it) Daniel Fischer-4 wrote: Am Mittwoch 07 April 2010 21:53:20 schrieb Daniel Fischer: Am Mittwoch 07 April 2010 20:43:24 schrieb Yves Parès: Yes, from what I read, I assumed it had this behavior. But, then, I don't see why the server holds... I've posted a mail on Haskell-Cafe called Network: buffering troubles, in which I put a smaller example which reproduces this problem. I know :) I have now tested it, with both (simple) servers and I can't reproduce the problem (ghc-6.12.1 and ghc-6.10.3). Installed binary-protocol and tried the original (no hSetBuffering), that also works flawlessly (ghc-6.12.1 on openSuSE 11.1). Server: $ ../BeginnersTesting/Server I wait for a client... Result: Just 1.6190478 I wait for a client... Result: Just 12.0 I wait for a client... Result: Nothing ^C Client: $ ./Client localhost Operation? Operation 3.4 Div 2.1 Operation sent. 1.6190478 Operation? Operation 17 Minus 5 Operation sent. 12.0 Operation? Stop Operation sent. Seems to be something with Ubuntu. Maybe somebody else on Ubuntu could test it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28174807.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] Confusions about the Haskell Platform (for Mac)
On Apr 8, 2010, at 02:47 , Ivan Miljenovic wrote: On 8 April 2010 16:29, Ketil Malde ke...@malde.org wrote: Support, in the sense that somebody is actually responsible for the package? (Unlike Hackage, where some packages have a closed-for-nonsubscribers mailing list as 'maintainer'.) Which packages are these? I don't recall seeing any with this kind of maintainer address... -cafe is closed for posting by nonmembers, as a spam limiter. I'm pretty sure that's what he meant. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)
Ivan Miljenovic ivan.miljeno...@gmail.com writes: Which packages are these? I don't recall seeing any with this kind of maintainer address... http://www.google.no/search?q=site%3Ahackage.haskell.org+maintainer+libraries%40haskell.org -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-ODBC and SqlValues
Jason: Thanks for the reply. I suspect the solution is to correctly tell Haskell what type you expect and then hopefully HDBC will do the conversion. For example, using fromSql: http://software.complete.org/static/hdbc/doc/Database-HDBC.html#v% 3AfromSql Yes. I can use fromSql to convert the result back to an appropriate numerical type. But internally the numeric data has still been converted to an intermediate string representation. I'm wondering if this is intentional, and whether it matters. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Problem tracked! It comes from the last version of bytestring package. I tried with bytestring-0.9.1.5, and it works perfectly. Do you know where I should submit this bug? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28175020.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] Re: Asynchronous exception wormholes kill modularity
On 07/04/2010 18:54, Isaac Dupree wrote: On 04/07/10 11:12, Simon Marlow wrote: It's possible to mis-use the API, e.g. getUnmask = mask return ...incidentally, unmask a = mask (\restore - return restore) = (\restore - restore a) That doesn't work, as in it can't be used to unmask exceptions when they are masked. The 'restore' you get just restores the state to its current, i.e. masked, state. mask :: ((IO a - IO a) - IO b) - IO b It needs to be :: ((forall a. IO a - IO a) - IO b) - IO b so that you can use 'restore' on two different pieces of IO if you need to. (alas, this requires not just Rank2Types but RankNTypes. Also, it doesn't cure the loophole. But I think it's still essential.) Sigh, yes I suppose that's true, but I've never encountered a case where I needed to call unmask more than once, let alone at different types, within the scope of a mask. Anyone else? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
Hi Carter
The proposal is interesting - but maybe there is not a great community
benefit to a 'covers everything' library considering Henning
Thielemann and others 'numeric prelude' already exists:
http://hackage.haskell.org/package/numeric-prelude
As a not especially mathematically inclined Haskell programmer who
delves into geometry at least, the current Num class is certainly a
problem even for me. I'd certainly welcome a small but more 'sound'
set of numeric classes - Jerzy Karczmarczuk has presented such a
library in various papers - this one (in French) lists the full code:
http://users.info.unicaen.fr/~karczma/arpap/pareseq.pdf
At the moment I use the normal Num class (ho-hum) plus Conal Elliott's
VectorSpace package to get similar.
Sectioning the Prelude would be useful (perhaps boring) work to add
onto a GSoC project that replaces some of its machinery. Currently if
one wants to avoid the Prelude's Num, one then has to import say the
monad stuff by hand. Similarly, if one wants to hide the monads, if
they have parameterized monads instead, they lose all the Num codes.
Some suitably defined import modules would be very handy e.g.:
{-# LANGUAGE NoImplicitPrelude #-}
module XYZ where
import PreludeWithoutNum
...
Best wishes
Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suitable structure to represents lots of similar lists
Dan Piponi wrote: I have a situation where I have a bunch of lists and I'll frequently be making new lists from the old ones by applying map and filter. The map will be applying a function that's effectively the identity on most elements of the list, and filter will be using a function that usually gives True. This means that there is potential for a large amount of sharing between these lists that could be exploited, something that ordinary lists would do badly. Does anyone have a recommendation for a pure functional data structure for this case? (It reminds me a bit of my own antidiagonal type, but that's not well adapted to the highly dynamic situation I'm describing.) I'm not sure whether these general properties of your maps and filters can actually be exploited. The thing is that you still have to touch every element anyway, so you can as well allocate a new cons cell and garbage collect the old one while you're at it. But if you can skip large contiguous parts of the lists, then sharing may be worth thinking about. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Nested unsafePerformIO?
Hi, I am having difficulty debugging a troublesome stack overflow, which I think might be related to calling unsafePerformIO from within the IO monad. So I have the following code: import System.Random import System.IO.Unsafe import Data.Time.Clock timedIterateIO :: Int - (a - a) - a - IO a timedIterateIO durationSecs f x = do t0 - getCurrentTime timedIterateIO' t0 x where duration' = fromIntegral durationSecs timedIterateIO' t0 x = do let y = f x t - getCurrentTime let d = diffUTCTime t t0 if d = duration' then return y else timedIterateIO' t0 y f x = unsafePerformIO $ do m - randomRIO (1,2) return (m+x) The idea of the timedIterateIO function is that it should repeatedly apply f to x until a specified duration is up. The use case is for game search, where I want to keep searching until time is up, and then play the best move I've found at that point. So the following works: *Main timedIterateIO 1 (+1) 0 45580 (1.01 secs, 360357840 bytes) The following also seems to work: *Main unsafePerformIO $ timedIterateIO 1 f 0 67866 (1.25 secs, 394938540 bytes) Now, in the real use case, I have another function, g let's say. It is similar to f, in that it uses unsafePerformIO internally to get random numbers. It's proven to work under normal circumstances, for example: *Main (!! 100) $ iterate g x works, and completes in around a second. However, the following doesn't work, failing with a stack overflow: *Main unsafePerformIO $ timedIterateIO 1 g x Any ideas? Thanks, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] multi-ghc: Managing Multiple GHC Distributions
I created a few tools to help me manage multiple GHC distributions in a Bash shell environment. Perhaps it's useful to others. http://github.com/spl/multi-ghc Feedback welcome. I'd also like to know if something similar exists. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Traypoweroff questions
Hi, I just put an application into hackage http://hackage.haskell.org/package/traypoweroff. I made this application to allow a tray icon in xmonad to poweroff and reboot my computer. But I dislike two things I made. The first one is the use of */sbin/poweroff* and */sbin/reboot* with system call. I feel than i should be a better way to do the poweroff or the reboot. err - system sudo /sbin/reboot The second issue is, the user need to put into sudoers the permission to execute reboot and poweroff. The use of *sudo* seems a little awkward. I'll like a cleaner installation without force user touch configuration files. myuser ALL=(ALL) NOPASSWD: /sbin/poweroff Thanks for the help, Luis Cabellos p.d: I'll add suspend with pm-suspend command in the next version BTW ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Nested unsafePerformIO?
It looks like your timedIterateIO is too lazy. When you pass it a function like (+1) what will happen is that a large chunk of the form ...+1+1+1+1+1 is build up on your heap. When you finally need its value the large chunk will be evaluated causing it to push the '1' arguments on the stack. When there are too much '1's your stack will eventually overflow. Try evaluating the 'y' before calling timedIterateIO' again as in: let y = f x ... y `seq` timedIterateIO' t0 y I think the normal 'iterate' function also has this behaviour: iterate (+1) 0 !! 1000 will cause your heap to be filled with lots of +1s and will finally cause a stack overflow when it tries to evaluate the final value (I haven't tried it so I may be wrong here). regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] multi-ghc: Managing Multiple GHC Distributions
On Thu, Apr 8, 2010 at 11:00 AM, Sean Leather leat...@cs.uu.nl wrote: I created a few tools to help me manage multiple GHC distributions in a Bash shell environment. Perhaps it's useful to others. http://github.com/spl/multi-ghc Feedback welcome. I'd also like to know if something similar exists. Does this also work with a system installed ghc? These are usually installed in /usr (I'm using Gentoo Linux): $ ls -l /usr/bin/ghc* lrwxrwxrwx 1 root root 10 dec 22 00:22 /usr/bin/ghc - ghc-6.12.1 -rwxr-xr-x 1 root root 279 dec 22 00:20 /usr/bin/ghc-6.12.1 lrwxrwxrwx 1 root root 11 dec 22 00:22 /usr/bin/ghci - ghci-6.12.1 -rwxr-xr-x 1 root root 61 dec 22 00:20 /usr/bin/ghci-6.12.1 lrwxrwxrwx 1 root root 14 dec 22 00:22 /usr/bin/ghc-pkg - ghc-pkg-6.12.1 -rwxr-xr-x 1 root root 262 dec 22 00:20 /usr/bin/ghc-pkg-6.12.1 If so, I think I'm going to use this tools since I occasionally like to try out ghc-HEAD. regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] multi-ghc: Managing Multiple GHC Distributions
On 8 April 2010 19:00, Sean Leather leat...@cs.uu.nl wrote: I created a few tools to help me manage multiple GHC distributions in a Bash shell environment. Perhaps it's useful to others. http://github.com/spl/multi-ghc Feedback welcome. I'd also like to know if something similar exists. Hi Sean, I wonder if you could achieve the desired result with the Modules Project: http://modules.sourceforge.net/ We use it at work for managing multiple versions of lots of different programs on a shared machine. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] multi-ghc: Managing Multiple GHC Distributions
On Thu, Apr 8, 2010 at 13:49, Bas van Dijk v.dijk@gmail.com wrote: On Thu, Apr 8, 2010 at 11:00 AM, Sean Leather leat...@cs.uu.nl wrote: I created a few tools to help me manage multiple GHC distributions in a Bash shell environment. Perhaps it's useful to others. http://github.com/spl/multi-ghc Feedback welcome. I'd also like to know if something similar exists. Does this also work with a system installed ghc? These are usually installed in /usr (I'm using Gentoo Linux): $ ls -l /usr/bin/ghc* lrwxrwxrwx 1 root root 10 dec 22 00:22 /usr/bin/ghc - ghc-6.12.1 -rwxr-xr-x 1 root root 279 dec 22 00:20 /usr/bin/ghc-6.12.1 lrwxrwxrwx 1 root root 11 dec 22 00:22 /usr/bin/ghci - ghci-6.12.1 -rwxr-xr-x 1 root root 61 dec 22 00:20 /usr/bin/ghci-6.12.1 lrwxrwxrwx 1 root root 14 dec 22 00:22 /usr/bin/ghc-pkg - ghc-pkg-6.12.1 -rwxr-xr-x 1 root root 262 dec 22 00:20 /usr/bin/ghc-pkg-6.12.1 The ghc-config Bash script in multi-ghc uses symlinks to determine which is the current version to use. The instructions on the GitHub page explain it in detail, but here's how my setup works. * I create /opt/ghc for storing GHC, clone the multi-ghc repository (or copy the files) here. * I create /opt/ghc/6.10.4/src, download http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown-linux-n.tar.bz2, and untar it here. * cd ..; ln -s ../Makefile; make install ghc-config creates a $HOME/.ghc-config directory for tracking the current version and symlinks. Now, the key for your situation (I think) is your $PATH. If you append $HOME/.ghc-config/ghc/bin to your $PATH after /usr/bin, then you can use ghc-6.10.4 to call this specific version. Unfortunately, there is still a problem. ghc-config also manages $HOME/.cabal as a symlink for the current version. So, that would most likely conflict with your setup. There may be a way to fix that, though I haven't looked into it, or I could separate the cabal configuration from the ghc configuration. If so, I think I'm going to use this tools since I occasionally like to try out ghc-HEAD. multi-ghc should also work for doing this. As long as you install it as /opt/ghc/6.13.blah (or whichever directory you want to use instead of /opt/ghc). This was one of the goals of the design. There's more documentation in the README.md and scripts. I'm happy to improve upon it if something doesn't work. Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] multi-ghc: Managing Multiple GHC Distributions
On Thu, Apr 8, 2010 at 14:00, Bernie Pope florbit...@gmail.com wrote: On 8 April 2010 19:00, Sean Leather leat...@cs.uu.nl wrote: I created a few tools to help me manage multiple GHC distributions in a Bash shell environment. Perhaps it's useful to others. http://github.com/spl/multi-ghc Feedback welcome. I'd also like to know if something similar exists. I wonder if you could achieve the desired result with the Modules Project: http://modules.sourceforge.net/ We use it at work for managing multiple versions of lots of different programs on a shared machine. It looks interesting! Thanks. It makes me sad to see it written in Tcl. I spent way too much time with the language at my last job and did not enjoy it. But I grant that that is not a reason to avoid using it. I actually started out doing as they do, changing the PATH, but I decided that was not a great solution for two reasons: (1) It's inflexible and precludes the ability to set my PATH as I like. (2) It requires sourcing a script instead of executing it. I didn't like having no separation between my environment and the script's environment. It was too easy to introduce spurious environment variables. It would be nice if such a tool can potentially be written to work on Windows as well. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Hac phi 2010
Hi Jason, If you don't run out of space, what is the registration deadline? There's no official deadline to register with us, though we'll probably need the names a few days ahead of time to get wifi keys for everyone. We did get a hotel discount for people coming in from out of town (see the hac phi wiki page), and it's only available until April 23. I hope you can join us! --Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Wed, 2010-04-07 at 16:09 -0400, Thomas Tuegel wrote: On Wed, Apr 7, 2010 at 3:33 PM, Duncan Coutts duncan.cou...@googlemail.com wrote: The importance of this is that it lets us develop improved testsuite interfaces in future. At the moment there are two test interfaces we want to support. One is the simple unix style exit code + stdout interface. This is good because it is a lowest common denominator that all existing testsuites can fit into. Of course that test interface does not provide any detailed machine-readable information (though you do get human-readable test logs). So that's why we want a second interface. That one should let the testing agent (for example cabal test but could be other agents) get much more detail about what tests can be run and then what the results are of various tests. For the purpose of differentiating between these two, would a field in the test section such as interface: stdout (in the first case) or interface: detailed (in the second) suffice? Yep. The details of such an interface are up for discussion. I do not mind if that is a command line executable interface or a library interface. That's something I've been thinking about. The former seems more portable. Maybe cabal could call the test program with test_program --list to produce a list of tests and test_program test1,test2,test3 to run some tests. Having some ideas is good. The details of the interface can be worked out during the project. I also want to ask how strictly this is within the scope of the SoC project, i.e. how well will my proposal be received if it focuses primarily on the first part of the problem (getting everything working for the stdout interface)? I ask because the detailed interface seems like a much larger mandate given that cabal doesn't really support any of the syntax/features for the simple stdout interface. Certainly we want to get the first part working first. My guess is that there is time within the 3-month GSoC period to complete the basic bits and to at least have a go at a prototype of a more detailed interface. That part doesn't need to be final, especially given that it will be possible to create new interfaces in future. Handling of Test Executables by Cabal The changes proposed here will make it possible to build, test, and install a Cabal package with the usual sequence of commands: That all sounds reasonable. I'd like to add that the interface between the testsuite and a testing agent such as the cabal program should be clearly documented and specified. There will likely be dedicated test agents that want to run the tests too and send reports to other systems (e.g. dedicated hackage test agents) and convert to other formats (e.g. integration in companies in-house systems). Rogan mentioned possible upcoming support in test-framework for JUnit XML as an output format for test results. That certainly seems to be widely supported; do you think it is suitable? I think it's important to be able to convert into standard or custom formats. I've no idea if JUnit XML would make sense as the native format. It's plausible. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: True Random Numbers
Is there a way to get multiple random numbers without having to replicateM? While comparing the random-fu interface with Control.Monad.Random (both using StdGen), I noticed that while performance is comparable, using getRandomRs to get a list of random numbers is a lot faster than replicating uniform (or getRandomR for that matter). I don't know if this kind of speed gain makes sense for random-fu though. I have been attempting to replicate this. What sort of a performance difference are you seeing, and are you using the hackage-released version of random-fu or the darcs one? The darcs release is, overall, a fair bit faster than the current hackage release. Depending on the particular way that I sample my RVars (eg, replicateM n (sample ...) vs sample (replicateM n ...)), I am seeing the random-fu version of my little benchmark run anywhere from 30% faster to 25% slower than Control.Monad.Random.getRandomRs (for 64000 uniform Double samples). The same benchmark using random-fu-0.0.3.2 shows it consistently about 33% slower than getRandomRs. In case you're interested, this is the (criterion) benchmark I used (with count = 64000, and in the first bgroup 'src' is an IORef StdGen): [ bgroup replicateM [ bench randomRIO $ do xs - replicateM count (randomRIO (10,50) :: IO Double) sum xs `seq` return () , bench uniform A $ do xs - replicateM count (sampleFrom src (uniform 10 50) :: IO Double) sum xs `seq` return () , bench uniform B $ do xs - sampleFrom src (replicateM count (uniform 10 50)) :: IO [Double] sum xs `seq` return () ] , bgroup pure StdGen [ bench getRandomRs $ do src - newStdGen let (xs, _) = CMR.runRand (CMR.getRandomRs (10,50)) src sum (take count xs :: [Double]) `seq` return () , bench RVarT, State - sample replicateM $ do src - newStdGen let (xs, _) = runState (sample (replicateM count (uniform 10 50))) src sum (xs :: [Double]) `seq` return () , bench RVarT, State - replicateM sample $ do src - newStdGen let (xs, _) = runState (replicateM count (sample (uniform 10 50))) src sum (xs :: [Double]) `seq` return () ] If the problem is worse than this benchmark indicates, or if this benchmark shows radically different results on a different platform (I'm running on Mac OS 10.6 with GHC 6.12.1), I'd love to hear about it. I could certainly imagine cases where the choice of monad in which to sample makes things quite slow. In the above case, I was using IO in the first bgroup and State StdGen in the second. As for whether an optimization like getRandomRs would benefit the random-fu library: I have tried a few different times to implement list or vector primitives and the corresponding high-level interfaces for sampling many variables at once, but have not yet come up with a version that actually made anything faster. I'm more than happy to accept patches if someone comes up with one, though! ;) -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)
Jason Dagit da...@codersbase.com writes: If I understand correctly, the issue at hand is that the uninstaller step is removing previous libraries and ghc? Not GHC; the HP installer removes old copies of the platform libraries. That's likely to break your old GHC setup though. What should it do instead? G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suitable structure to represents lots of similar lists
Id doesn´t have to create a copy of the original object ( I infer this from referential transparency) so the new list must store the same original reference. Any pure structure would conserve references after id. filter as far as I know. Am I wrong? 2010/4/8 Dan Piponi dpip...@gmail.com I have a situation where I have a bunch of lists and I'll frequently be making new lists from the old ones by applying map and filter. The map will be applying a function that's effectively the identity on most elements of the list, and filter will be using a function that usually gives True. This means that there is potential for a large amount of sharing between these lists that could be exploited, something that ordinary lists would do badly. Does anyone have a recommendation for a pure functional data structure for this case? (It reminds me a bit of my own antidiagonal type, but that's not well adapted to the highly dynamic situation I'm describing.) -- Dan ___ 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] Suitable structure to represents lots of similar lists
I think Dan is talking about sharing the spine of the lists...
How about representing the lists using something along the lines of:
data List a = Nil | Leaf a | Cat (List a) (List a)
data Transformed a = Changed a | Unchanged a
extract :: Transformed a - a
extract (Unchanged a) = a
extract (Changed a') = a'
-- If the first argument returns Nothing, that means 'identity'
mapShared :: (a - Transformed a) - List a - List a
mapShared f xs = extract (mapShared' f xs)
cat :: List a - Transformed (List a) - Transformed (List a) -
Transformed (List a)
cat xs (Unchanged _) (Unchanged _) = Unchanged xs
cat xs (Changed ys') (Unchanged zs) = Changed (Cat ys' zs)
cat xs (Unchanged ys) (Changed zs') = Changed (Cat ys zs')
cat xs (Changed ys') (Changed zs') = Changed (Cat ys' zs')
mapShared' :: (a - Transformed a) - List a - Transformed (List a)
mapShared' f x...@nil = Unchanged xs
mapShared' f xs@(Leaf a) = case f a of { Unchanged _ - Unchanged xs ;
Changed a' - Changed (Leaf a') }
mapShared' f xs@(Cat ys zs) = cat xs (mapShared' f ys) (mapShared' f zs)
filterShared :: (a - Bool) - List a - List a
filterShared p xs = original xs (filterShared' p xs)
filterShared' :: (a - Bool) - List a - Transformed (List a)
filterShared' p x...@nil = Unchanged xs
filterShared' p xs@(Leaf x) = if p x then Unchanged xs else Changed Nil
filterShared' p xs@(Cat ys zs) = cat xs (filterShared' p ys)
(filterShared' p zs)
Perhaps this can be made into a monad or something like that, but I am
not sure... Perhaps rebalancing (or generally using a finger tree)
would also do well.
So, looks like we preserve whole 'subtrees' shared if they were not
'changed' by map or filter.
2010/4/8 Alberto G. Corona agocor...@gmail.com:
Id doesn´t have to create a copy of the original object ( I infer this from
referential transparency) so the new list must store the same original
reference. Any pure structure would conserve references after id. filter as
far as I know. Am I wrong?
2010/4/8 Dan Piponi dpip...@gmail.com
I have a situation where I have a bunch of lists and I'll frequently
be making new lists from the old ones by applying map and filter. The
map will be applying a function that's effectively the identity on
most elements of the list, and filter will be using a function that
usually gives True. This means that there is potential for a large
amount of sharing between these lists that could be exploited,
something that ordinary lists would do badly. Does anyone have a
recommendation for a pure functional data structure for this case?
(It reminds me a bit of my own antidiagonal type, but that's not well
adapted to the highly dynamic situation I'm describing.)
--
Dan
___
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
--
Eugene Kirpichov
Senior Developer, JetBrains
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suitable structure to represents lots of similar lists
2010/4/8 Eugene Kirpichov ekirpic...@gmail.com:
I think Dan is talking about sharing the spine of the lists...
How about representing the lists using something along the lines of:
data List a = Nil | Leaf a | Cat (List a) (List a)
data Transformed a = Changed a | Unchanged a
extract :: Transformed a - a
extract (Unchanged a) = a
extract (Changed a') = a'
-- If the first argument returns Nothing, that means 'identity'
Whoops, this is an artifact of my brief thought to use Maybe instead
of Transformed...
mapShared :: (a - Transformed a) - List a - List a
mapShared f xs = extract (mapShared' f xs)
cat :: List a - Transformed (List a) - Transformed (List a) -
Transformed (List a)
cat xs (Unchanged _) (Unchanged _) = Unchanged xs
cat xs (Changed ys') (Unchanged zs) = Changed (Cat ys' zs)
cat xs (Unchanged ys) (Changed zs') = Changed (Cat ys zs')
cat xs (Changed ys') (Changed zs') = Changed (Cat ys' zs')
mapShared' :: (a - Transformed a) - List a - Transformed (List a)
mapShared' f x...@nil = Unchanged xs
mapShared' f xs@(Leaf a) = case f a of { Unchanged _ - Unchanged xs ;
Changed a' - Changed (Leaf a') }
mapShared' f xs@(Cat ys zs) = cat xs (mapShared' f ys) (mapShared' f zs)
filterShared :: (a - Bool) - List a - List a
filterShared p xs = original xs (filterShared' p xs)
filterShared' :: (a - Bool) - List a - Transformed (List a)
filterShared' p x...@nil = Unchanged xs
filterShared' p xs@(Leaf x) = if p x then Unchanged xs else Changed Nil
filterShared' p xs@(Cat ys zs) = cat xs (filterShared' p ys)
(filterShared' p zs)
Perhaps this can be made into a monad or something like that, but I am
not sure... Perhaps rebalancing (or generally using a finger tree)
would also do well.
So, looks like we preserve whole 'subtrees' shared if they were not
'changed' by map or filter.
2010/4/8 Alberto G. Corona agocor...@gmail.com:
Id doesn´t have to create a copy of the original object ( I infer this from
referential transparency) so the new list must store the same original
reference. Any pure structure would conserve references after id. filter as
far as I know. Am I wrong?
2010/4/8 Dan Piponi dpip...@gmail.com
I have a situation where I have a bunch of lists and I'll frequently
be making new lists from the old ones by applying map and filter. The
map will be applying a function that's effectively the identity on
most elements of the list, and filter will be using a function that
usually gives True. This means that there is potential for a large
amount of sharing between these lists that could be exploited,
something that ordinary lists would do badly. Does anyone have a
recommendation for a pure functional data structure for this case?
(It reminds me a bit of my own antidiagonal type, but that's not well
adapted to the highly dynamic situation I'm describing.)
--
Dan
___
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
--
Eugene Kirpichov
Senior Developer, JetBrains
--
Eugene Kirpichov
Senior Developer, JetBrains
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suitable structure to represents lots of similar lists
2010/4/8 Eugene Kirpichov ekirpic...@gmail.com:
I think Dan is talking about sharing the spine of the lists...
How about representing the lists using something along the lines of:
data List a = Nil | Leaf a | Cat (List a) (List a)
data Transformed a = Changed a | Unchanged a
extract :: Transformed a - a
extract (Unchanged a) = a
extract (Changed a') = a'
-- If the first argument returns Nothing, that means 'identity'
mapShared :: (a - Transformed a) - List a - List a
mapShared f xs = extract (mapShared' f xs)
cat :: List a - Transformed (List a) - Transformed (List a) -
Transformed (List a)
cat xs (Unchanged _) (Unchanged _) = Unchanged xs
cat xs (Changed ys') (Unchanged zs) = Changed (Cat ys' zs)
cat xs (Unchanged ys) (Changed zs') = Changed (Cat ys zs')
cat xs (Changed ys') (Changed zs') = Changed (Cat ys' zs')
mapShared' :: (a - Transformed a) - List a - Transformed (List a)
mapShared' f x...@nil = Unchanged xs
mapShared' f xs@(Leaf a) = case f a of { Unchanged _ - Unchanged xs ;
Changed a' - Changed (Leaf a') }
mapShared' f xs@(Cat ys zs) = cat xs (mapShared' f ys) (mapShared' f zs)
filterShared :: (a - Bool) - List a - List a
filterShared p xs = original xs (filterShared' p xs)
Aargh. I meant:
filterShared p xs = extract (filterShared' p xs)
filterShared' :: (a - Bool) - List a - Transformed (List a)
filterShared' p x...@nil = Unchanged xs
filterShared' p xs@(Leaf x) = if p x then Unchanged xs else Changed Nil
filterShared' p xs@(Cat ys zs) = cat xs (filterShared' p ys)
(filterShared' p zs)
Perhaps this can be made into a monad or something like that, but I am
not sure... Perhaps rebalancing (or generally using a finger tree)
would also do well.
So, looks like we preserve whole 'subtrees' shared if they were not
'changed' by map or filter.
2010/4/8 Alberto G. Corona agocor...@gmail.com:
Id doesn´t have to create a copy of the original object ( I infer this from
referential transparency) so the new list must store the same original
reference. Any pure structure would conserve references after id. filter as
far as I know. Am I wrong?
2010/4/8 Dan Piponi dpip...@gmail.com
I have a situation where I have a bunch of lists and I'll frequently
be making new lists from the old ones by applying map and filter. The
map will be applying a function that's effectively the identity on
most elements of the list, and filter will be using a function that
usually gives True. This means that there is potential for a large
amount of sharing between these lists that could be exploited,
something that ordinary lists would do badly. Does anyone have a
recommendation for a pure functional data structure for this case?
(It reminds me a bit of my own antidiagonal type, but that's not well
adapted to the highly dynamic situation I'm describing.)
--
Dan
___
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
--
Eugene Kirpichov
Senior Developer, JetBrains
--
Eugene Kirpichov
Senior Developer, JetBrains
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)
greg: Jason Dagit da...@codersbase.com writes: If I understand correctly, the issue at hand is that the uninstaller step is removing previous libraries and ghc? Not GHC; the HP installer removes old copies of the platform libraries. That's likely to break your old GHC setup though. What should it do instead? Can we install these in parallel somehow? A la lib/ghc-6.8.2 lib/ghc-6.6.1 lib/ghc-6.10.2 lib/ghc-6.12.1 ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Correct way to record state in OpenGL?
I sort of understand what people are getting at. My basic question is now, given that I have a bunch of parameters that represent state should I bundle up ALL of these parameters in one data type (DemoState, say) and have ONE IORef variable that references the lot, or have an IORef for each piece of state, separately. What are the disadvantages of each approach? Also, is reading and writing to an IORef expensive computationally? Thanks, Mark On 05/04/2010, at 2:25 AM, Tobias Brandt wrote: HOpenGL uses Data.StateVar. One can define the following function: newStateVar :: a - IO (StateVar a) newStateVar val = do ref - newIORef val let readAction = readIORef ref let writeAction = \newVal - writeIORef ref newVal return (makeStateVar readAction writeAction) Now one can use StateVar consistent with HOpenGL: create: foo - newStateVar bar read: get foo write foo $= baz On 4 April 2010 11:03, Mark Spezzano mark.spezz...@chariot.net.au wrote: Hi What is the correct way to record custom state when using OpenGL? By this, I refer to, say, properties of a square--say it's x,y coordinates as it moves across the screen. This requires that the program keep track of the object's state as it moves. These coordinates are _not_ part of the OpenGL state machine, so is the correct way to use the State monad? If so--or if not so--how would I proceed to keep track of the state of my objects as they move about the screen? Maybe the HOpenGL implementation comes with such state-tracking devices? Please post code snippets if necessary. Thanks in advance, Mark Spezzano ___ 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] Suitable structure to represents lots of similar lists
Dan Piponi dpip...@gmail.com writes: I have a situation where I have a bunch of lists and I'll frequently be making new lists from the old ones by applying map and filter. (While keeping the old ones around, I presume?) One option (or source of inspiration) might be lazy bytestrings, which are stored as lists of chunks, each chunk being a strict bytesting. A strict bytestring is a pointer to an array, an offset and a length. Thus, your initial lists could be contigous arrays, derivied list would be a sequence of chunks, each chunk either containing substrings of the original list or modified elements. So if f is id for positions 0..3 and 9..10, you could have: orig = Chunk (PS v 0 10) Empty map' f orig = Chunk (PS v 0 3) (Chunk (PS w 0 4) (Chunk (PS v 9 10) Empty)) Possibly vector generalizes this to datatypes beyond Word8, I haven't looked. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Seeking advice about monadic traversal functions
On 4/6/10 15:31, Heinrich Apfelmus wrote: In fact, it doesn't actually work for monads, I think you have to wrap it in a newtype. :D The same effect can be achieved with `ap` , though: Fortunately, by now most (standard) monads are also applicatives. :-) Besides generalizing to an arbitrary number of arguments, it uses infix operators which saves you some parentheses. Groetjes, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
By the way, Gregory, concerning the package binary-protocol, I was wondering if it was possible to turn the BinaryProtocol monad from type BinaryProtocol = StateT (Handle, Handle, ByteString) IO to: type BinaryProtocol = StateT (Handle, Handle, ByteString) And then the functions, like runProtocol, would become: runProtocol :: (MonadIO m) = BinaryProtocol m a - Handle - Handle - m a I mean that BinaryProtocol could run within any MonadIO, not only IO. This would turn the BinaryProtocol into a monad trans, which would be more generic (we could for instance stack two BinaryProtocols). Yves Parès wrote: Problem tracked! It comes from the last version of bytestring package. I tried with bytestring-0.9.1.5, and it works perfectly. Do you know where I should submit this bug? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28180773.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] Correct way to record state in OpenGL?
Maybe I should ask: If I have many state variables encapsulated in one IO (StateVar DemoState) how do I go about referencing and updating _one_ without having to enumerate all of them? What is the syntax? Mark On 09/04/2010, at 12:13 AM, Mark Spezzano wrote: I sort of understand what people are getting at. My basic question is now, given that I have a bunch of parameters that represent state should I bundle up ALL of these parameters in one data type (DemoState, say) and have ONE IORef variable that references the lot, or have an IORef for each piece of state, separately. What are the disadvantages of each approach? Also, is reading and writing to an IORef expensive computationally? Thanks, Mark On 05/04/2010, at 2:25 AM, Tobias Brandt wrote: HOpenGL uses Data.StateVar. One can define the following function: newStateVar :: a - IO (StateVar a) newStateVar val = do ref - newIORef val let readAction = readIORef ref let writeAction = \newVal - writeIORef ref newVal return (makeStateVar readAction writeAction) Now one can use StateVar consistent with HOpenGL: create: foo - newStateVar bar read: get foo write foo $= baz On 4 April 2010 11:03, Mark Spezzano mark.spezz...@chariot.net.au wrote: Hi What is the correct way to record custom state when using OpenGL? By this, I refer to, say, properties of a square--say it's x,y coordinates as it moves across the screen. This requires that the program keep track of the object's state as it moves. These coordinates are _not_ part of the OpenGL state machine, so is the correct way to use the State monad? If so--or if not so--how would I proceed to keep track of the state of my objects as they move about the screen? Maybe the HOpenGL implementation comes with such state-tracking devices? Please post code snippets if necessary. Thanks in advance, Mark Spezzano ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Asynchronous exception wormholes kill modularity
On 04/08/10 04:23, Simon Marlow wrote: On 07/04/2010 18:54, Isaac Dupree wrote: On 04/07/10 11:12, Simon Marlow wrote: It's possible to mis-use the API, e.g. getUnmask = mask return ...incidentally, unmask a = mask (\restore - return restore) = (\restore - restore a) That doesn't work, as in it can't be used to unmask exceptions when they are masked. The 'restore' you get just restores the state to its current, i.e. masked, state. oh good point. Then you're right, anyone who was trying to work around it would be doing something obviously wrong. mask :: ((IO a - IO a) - IO b) - IO b It needs to be :: ((forall a. IO a - IO a) - IO b) - IO b so that you can use 'restore' on two different pieces of IO if you need to. (alas, this requires not just Rank2Types but RankNTypes. Also, it doesn't cure the loophole. But I think it's still essential.) Sigh, yes I suppose that's true, but I've never encountered a case where I needed to call unmask more than once, let alone at different types, within the scope of a mask. Anyone else? FWIW, the function I made up to test my theory was as below; I haven't thought of any actual uses yet: finally2 :: IO a1 - IO a2 - IO b - IO (a1, a2) finally2 a1 a2 b = mask $ \restore - do r - (liftM2 (,) (restore a1) (restore a2)) `onException` b b return r -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] mapM for vectors
Hello I found that there is no monadic map for vector. It's possible to define to define such map using conversion to list, but I suppose it's not efficient. I didn't make any measurements. mapM' :: Monad m = (a - m b) - V.Vector a - m (V.Vector b) mapM' f = return . V.fromList = mapM f . V.toList Any suggestions about implementation of such function? Specifically I want to use Random monad. -- Khudyakov Alexey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
Hi Carter, You might be interested in the 'monoids' package on hackage, which I constructed for my own research. http://hackage.haskell.org/package/monoids-0.1.36 This package largely covers the first half of your proposal, and provides machinery for automatic differentiation of monoids over bimodules, which starts to cover some of the scope you describe in the second half of your proposal. Later revisions drastically reduce scope, in part due to the considerations below. I'd like to point out a few things about why you might not want to do this. A rigorous numerical prelude is a tedious thing in Haskell to extend or to use in practice. I think many people would agree that Num did not strike the right balance between generality and power. There are many perfectly good numerical types that don't fit into the strange 'self-semi-measured ring-like thing with equality and an available textual representation' that makes up a Haskell Num. However, in the absence of the ability to declare class aliases, define default members for your superclasses, and retoactively define superclasses, a deeper numeric prelude is an exercise in frustration. You can view the standard mathematical hierarchy as a lattice defined by the laws associated with the structure in question. You can start with magma, add associativity and get semigroup, or just add a unit and get a unital magma, but mixing the two gives you a monoid, so on and so forth. So many of the points on this lattice have names, others are just adjectival modifications of other more primitive concepts. However, if you ever skip a level, and say, omit 'Quasigroup' on the way to defining 'Loop', you'll find that the nature of Haskell makes it hard to retrofit such a level into your hierarchy. Afterall, any users who had defined their own 'Loop' instances before, would now have to split their definition in half. So, on one front, these deep hierarchies are brittle. Another problem is the drastic increase in boilerplate to instantiate anything deep within the hierarchy. When every Field is a Magma, SemiGroup, Monoid, QuasiGroup, Loop, Group, UnitalMagma, MultiplicativeMagma, MultiplicativeSemiGroup, MultiplicativeMonoid, MultiplicativeQuasiGroup, MultiplicativeLoop, MultiplicativeGroup, Ringoid, LeftSemiNearRing, RightSemiNearRing, SemiNearRing, Rng, SemiRing, Ring, and Field with the attendant instances to form a vector space (and hence module, etc.) over itself and the canonical modules over the naturals (as a monoid) and integers (as a group), the amount of boilerplate reaches a level of patent absurdity. You have to instantiate each of those classes and provide default definitions for properties that are clearly inferrable. Yes the MultiplicativeQuasiGroup's notion of left and right division are uniquely the same, but you still have to write the lines that say it, for every instance. Template Haskell can help dull the pain, but the result seems hardly idiomatic. The amount of code to define a new Field-like object can baloon to well over a hundred lines, and in the above I didn't even address how to work with near-field-like concepts like Fields and Doubles, which don't support all of the laws but which have the same feel. Finally, there is the issue of adoption. Incompatibility with the Prelude is a major concern. Ultimately your code has to talk to other people's code, and the impedence mismatch can be high. -Edward Kmett On Thu, Apr 8, 2010 at 1:23 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hello All, I would like to know if there is enough community interest in following gsoc project proposal of mine for me to write up a proper haskell gsoc app for it . (and accordingly if there is a person who'd be up for having the mentoring role) Project: Alternate numerical prelude with a typeclass hierarchy that follows that found in abstract algebra, along with associated generic algorithms for various computations can be done on datastructures satisfying these type clases. In particular, the motivating idea is the following: yes it'd be useful (for more mathematically inclined haskellers) to have a numerical prelude whose hierarchy means something, but for even that subset of the haskell user population, such an alternate prelude is only useful if users get extra functionality out of that more detailed infrastructure (and I believe that some of the infrastructure that becomes feasible would be worthwhile to the larger haskell community). the basic plan is as follows 1) define a typeclass hierarchy that covers everything such as monoids - groups - rings - fields, and various points in between. After some experimenting, it has become pretty clear to me that all of these need to be defined indirectly with the help of template haskell so that the names of the various operators can be suitably parameterized (so that * and + etc aren't the only choices people have). This part itself isn't terribly difficult, though
Re: [Haskell-cafe] HDBC-ODBC and SqlValues
Tim Docker wrote: Jason: Thanks for the reply. I suspect the solution is to correctly tell Haskell what type you expect and then hopefully HDBC will do the conversion. For example, using fromSql: http://software.complete.org/static/hdbc/doc/Database-HDBC.html#v% 3AfromSql Yes. I can use fromSql to convert the result back to an appropriate numerical type. But internally the numeric data has still been converted to an intermediate string representation. I'm wondering if this is intentional, and whether it matters. Yes and no, in that order. A ByteString is a pretty universal holder for various types of data. As someone else pointed out, at query time, we don't really have access to what type you will eventually want to use it as, and supporting the vast number of different ways to get things out of databases -- with the corresponding complexities of how a database driver can convert between them -- was just not worth it. It is generally assumed that the end user will be using fromSql anyhow, so it is not particularly relevant if it's a SqlByteString or a SqlInteger internally. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Nested unsafePerformIO?
Bas van Dijk v.dijk.bas at gmail.com writes: It looks like your timedIterateIO is too lazy. Try evaluating the 'y' before calling timedIterateIO' again as in: let y = f x ... y `seq` timedIterateIO' t0 y Thank you, that appears to do the trick. I'm still a bit puzzled about why the problem only manifested in this case - it didn't manifest when I used iterate, for example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: darcsum.el 1.2 released
With Christian's blessing, I have taken over maintenance of darcsum and would like to announce the 1.2 release: darcs get http://joyful.com/repos/darcsum -t 1.2 darcsum is an occasionally fragile but tremendously useful emacs ui for darcs. There is also vc-darcs.el, but I am quite productive with this one. For a long time it has been hanging with certain of my repos, due to unrecognised output from darcs; this release fixes all hangs I know about. There's plenty more in TODO so please send patches. Or, if there is a more serious emacs hacker out there willing to be maintainer for at least the next release, that would be great. Thanks to Christian and the other committers for keeping this useful tool alive. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Asynchronous exception wormholes kill modularity
On 04/07/10 17:50, Simon Marlow wrote: On 07/04/10 21:23, Bas van Dijk wrote: On Wed, Apr 7, 2010 at 5:12 PM, Simon Marlowmarlo...@gmail.com wrote: Comments? I really like this design. One question, are you planning to write the MVar utility functions using 'mask' or using 'nonInterruptibleMask'? As in: withMVar :: MVar a - (a - IO b) - IO b withMVar m f = whichMask? $ \restore - do a- takeMVar m b- restore (f a) `onException` putMVar m a putMVar m a return b Definitely the ordinary interruptible mask. It is the intention that the new nonInterruptibleMask is only used in exceptional circumstances where dealing with asynchronous exceptions emerging from blocking operations would be impossible to deal with. The more unwieldy name was chosen deliberately for this reason. The danger with nonInterruptibleMask is that it is all too easy to write a program that will be unresponsive to Ctrl-C, for example. It should be used with great care - for example when there is reason to believe that any blocking operations that would otherwise be interruptible will only block for short bounded periods. it could be called unsafeNonInterruptibleMask (unsafeUninterruptibleMask?)... after all, 'mask' is uninterruptible for most/many operations, that's its point, but if we put 'mask' and 'nonInterruptibleMask' next to each other, I think people are likely to be confused (..less so if there's good Haddock documentation. But i'm fearing the 'forkOS' debacle where people still wrongly recommend that because the name sounds good...) I still would like to see examples of where it's needed, because I slightly suspect that wrapping possibly-blocking operations in an exception handler that does something appropriate, along with ordinary 'mask', might be sufficient... But I expect to be proved wrong; I just haven't figured out how to prove myself wrong. -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
On Thu, Apr 8, 2010 at 2:09 PM, Edward Kmett ekm...@gmail.com wrote: Template Haskell can help dull the pain, but the result seems hardly idiomatic. Well, since this is dealing with types and type classes, much of the required boilerplate could also be straightforwardly derived in full generality using type-level metaprogramming techniques rather than TH, but the outcome of that would likely be even less tasteful, in the sense of so many UndecidableInstances that you won't be able to scratch your nose without running into the Halting Problem. With a bit of finesse, though, I suspect the result could allow users of the library to avoid both boilerplate and unnerving GHC extensions. Compatibility with Prelude classes could probably also be solved this way. Still, probably not terribly appealing to most folks. The amount of code to define a new Field-like object can baloon to well over a hundred lines, and in the above I didn't even address how to work with near-field-like concepts like Fields and Doubles, which don't support all of the laws but which have the same feel. I'm somewhat uncomfortable as it is with equivocating between true mathematical objects and hand-wavy approximations that have hardware support. Seriously, floating point so-called numbers don't even have reflexive equality! If anything, it seems like there might be value in chopping the numeric types apart into fast number-crunchy types and types with nice algebraic properties, and then enhancing each with relevant functionality. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapM for vectors
alexey.skladnoy: Hello I found that there is no monadic map for vector. It's possible to define to define such map using conversion to list, but I suppose it's not efficient. I didn't make any measurements. mapM' :: Monad m = (a - m b) - V.Vector a - m (V.Vector b) mapM' f = return . V.fromList = mapM f . V.toList Any suggestions about implementation of such function? Specifically I want to use Random monad. There's a tutorial here on usving vectors, http://haskell.org/haskellwiki/Numeric_Haskell:_A_Vector_Tutorial#Random_numbers mapM is available via Fusion.Stream.Monadic.mapM -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
On Thu, Apr 8, 2010 at 3:25 PM, Casey McCann syntaxgli...@gmail.com wrote: On Thu, Apr 8, 2010 at 2:09 PM, Edward Kmett ekm...@gmail.com wrote: Template Haskell can help dull the pain, but the result seems hardly idiomatic. Well, since this is dealing with types and type classes, much of the required boilerplate could also be straightforwardly derived in full generality using type-level metaprogramming techniques rather than TH, but the outcome of that would likely be even less tasteful, in the sense of so many UndecidableInstances that you won't be able to scratch your nose without running into the Halting Problem. With a bit of finesse, though, I suspect the result could allow users of the library to avoid both boilerplate and unnerving GHC extensions. Compatibility with Prelude classes could probably also be solved this way. Still, probably not terribly appealing to most folks. Unfortunately the type level metaprogramming approach doesn't really yield something that has an idiomatic usage pattern and would still rely on extensions, since you'd need Type Families and/or MPTCs/Fundeps/UndecidableInstances/IncoherentInstances. A TH solution needn't be that bad with template haskell and quasiquotation: [$field ''MyField| (+) = ... (*) = ... negate = .. |] You just construct the tower of instances needed and bake in a bunch of machinery to precalculate the appropriate defaults and derived members. This has the advantage that if the numerical tower is refactored to add another level, then the client side code doesn't break. The amount of code to define a new Field-like object can baloon to well over a hundred lines, and in the above I didn't even address how to work with near-field-like concepts like Fields and Doubles, which don't support all of the laws but which have the same feel. I'm somewhat uncomfortable as it is with equivocating between true mathematical objects and hand-wavy approximations that have hardware support. Seriously, floating point so-called numbers don't even have reflexive equality! If anything, it seems like there might be value in chopping the numeric types apart into fast number-crunchy types and types with nice algebraic properties, and then enhancing each with relevant functionality. I agree they should be separated. In my previous implementation of these I had built up a Pseudo- prefixed numerical tower for when you couldn't rely on the laws to apply, and a newtype wrapper that let you coerce then into something for which you claim the laws locally apply. What I meant was that I hadn't bothered to include the Pseudo-prefixed variants on each of the classes, which bloats the example even further. -Edward Kmett ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Simple game: a monad for each player
Hello Cafe,
I have a question about program design.
Let's say I have a simple sequential game (a TicTacToe for instance, but
with more than 2 players).
I have a Player datatype which is like:
data Player m = Player {
plName :: String, -- unique for each player
plTurn :: GameGrid - m Move -- called whenever the player must play
}
As you may guess, the 'm' type variable is intended to be a Monad.
The goal is that every player has his own monad. For instance :
- a human player needs to interact with the program, so its monad would be
IO, or an instance of MonadIO.
- a network player, which transparently sends the game state and receives
moves through network, must also have access to IO to play.
- an AI doesn't need to interact with the outside of the program, so its
monad can be the one we want (e.g. Identity).
First, do you think it is a good way to design the program?
I want the game to be totally independent of the players who are currently
playing. They can be humans, AIs, AIs and network players and humans, and so
on.
But when running the game, the program cannot switch from a player's monad
to another.
If we want every player to run in his own monad, I think we have to stack
every players' monad, and lift their actions each time they have to play.
This is not a problem, the sole condition now is that every player has type:
(Monad m, MonadTrans m) = Player m.
But I think it's a little bit of overkill, and it may be a little bit
complicated to implement such a thing.
What I try to avoid is having every player running in IO monad.
Do you have any suggestion?
-
Yves Parès
Live long and prosper
--
View this message in context:
http://old.nabble.com/Simple-game%3A-a-monad-for-each-player-tp28183930p28183930.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] GSOC Haskell Project
I have submitted my proposal to the gsoc site taking care to include all the feedback that was given either publicly or privately both from people on haskell-cafe, on #haskell or from my country. This is the last call for feedback before the submission period is ended. One last chance to improve the application. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Am Donnerstag 08 April 2010 09:17:04 schrieb Yves Parès: Problem tracked! It comes from the last version of bytestring package. Alas, it's maybe not so simple. I tried with bytestring-0.9.1.5, and it works perfectly. I just tried with bytestring-0.9.1.6 and it worked perfectly for sending and receiving operations. For the simpler client which just encodes (3,4,5) and sends it to the server, however, the server does nothing until the client exits (then it prints and exits), I suppose that's what you encountered. So the change from hGetContentsN :: Int - Handle - IO ByteString hGetContentsN k h = lazyRead -- TODO close on exceptions where lazyRead = unsafeInterleaveIO loop loop = do c - S.hGetNonBlocking h k to loop = do c - S.hGet h k seems to be the cause, but for me it doesn't break the first example. Do you know where I should submit this bug? Maintainer: d...@galois.com, dun...@haskell.org - Yves Parès Live long and prosper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
That sounds like a reasonable modification; if you want, free to fork it at http://github.com/gcross/binary-protocol and push me your proposed changes. Cheers, Greg On Apr 8, 2010, at 9:12 AM, Yves Parès wrote: By the way, Gregory, concerning the package binary-protocol, I was wondering if it was possible to turn the BinaryProtocol monad from type BinaryProtocol = StateT (Handle, Handle, ByteString) IO to: type BinaryProtocol = StateT (Handle, Handle, ByteString) And then the functions, like runProtocol, would become: runProtocol :: (MonadIO m) = BinaryProtocol m a - Handle - Handle - m a I mean that BinaryProtocol could run within any MonadIO, not only IO. This would turn the BinaryProtocol into a monad trans, which would be more generic (we could for instance stack two BinaryProtocols). Yves Parès wrote: Problem tracked! It comes from the last version of bytestring package. I tried with bytestring-0.9.1.5, and it works perfectly. Do you know where I should submit this bug? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28180773.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: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
On Apr 8, 2010, at 12:25 PM, Casey McCann wrote: Seriously, floating point so-called numbers don't even have reflexive equality! They don't? I am pretty sure that a floating point number is always equal to itself, with possibly a strange corner case for things like +/- 0 and NaN. Cheers, Greg___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Okay, Guess I will have to learn how to use git. I used darcs so far... Concerning the bug in bytestring, I sent a mail to dons. I just still have no answer. Gregory Crosswhite-2 wrote: That sounds like a reasonable modification; if you want, free to fork it at http://github.com/gcross/binary-protocol and push me your proposed changes. Cheers, Greg On Apr 8, 2010, at 9:12 AM, Yves Parès wrote: By the way, Gregory, concerning the package binary-protocol, I was wondering if it was possible to turn the BinaryProtocol monad from type BinaryProtocol = StateT (Handle, Handle, ByteString) IO to: type BinaryProtocol = StateT (Handle, Handle, ByteString) And then the functions, like runProtocol, would become: runProtocol :: (MonadIO m) = BinaryProtocol m a - Handle - Handle - m a I mean that BinaryProtocol could run within any MonadIO, not only IO. This would turn the BinaryProtocol into a monad trans, which would be more generic (we could for instance stack two BinaryProtocols). Yves Parès wrote: Problem tracked! It comes from the last version of bytestring package. I tried with bytestring-0.9.1.5, and it works perfectly. Do you know where I should submit this bug? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28180773.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 - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28184890.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] Simple game: a monad for each player
On Thu, Apr 8, 2010 at 4:08 PM, Yves Parès limestr...@gmail.com wrote:
Hello Cafe,
I have a question about program design.
Let's say I have a simple sequential game (a TicTacToe for instance, but
with more than 2 players).
I have a Player datatype which is like:
data Player m = Player {
plName :: String, -- unique for each player
plTurn :: GameGrid - m Move -- called whenever the player must play
}
As you may guess, the 'm' type variable is intended to be a Monad.
The goal is that every player has his own monad. For instance :
- a human player needs to interact with the program, so its monad would be
IO, or an instance of MonadIO.
- a network player, which transparently sends the game state and receives
moves through network, must also have access to IO to play.
- an AI doesn't need to interact with the outside of the program, so its
monad can be the one we want (e.g. Identity).
First, do you think it is a good way to design the program?
I want the game to be totally independent of the players who are currently
playing. They can be humans, AIs, AIs and network players and humans, and so
on.
But when running the game, the program cannot switch from a player's monad
to another.
If we want every player to run in his own monad, I think we have to stack
every players' monad, and lift their actions each time they have to play.
This is not a problem, the sole condition now is that every player has type:
(Monad m, MonadTrans m) = Player m.
But I think it's a little bit of overkill, and it may be a little bit
complicated to implement such a thing.
What I try to avoid is having every player running in IO monad.
Do you have any suggestion?
-
Yves Parès
Your desires remind me of the MonadPrompt package
http://hackage.haskell.org/package/MonadPrompt, which IIRC, has been
used in some game demos to provide abstraction from IO/test
harness/pure AI etc.
--
gwern
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity
On Thu, Apr 8, 2010 at 9:15 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: I still would like to see examples of where it's needed, because I slightly suspect that wrapping possibly-blocking operations in an exception handler that does something appropriate, along with ordinary 'mask', might be sufficient... But I expect to be proved wrong; I just haven't figured out how to prove myself wrong. Take my threads package, I uploaded to hackage yesterday, as an example. In Control.Concurrent.Thread.Group.fork I first increment numThreads before forking. When the fork thread terminates it should decrement numThreads and release the lock when it reaches zero so that potential waiters are woken up: http://hackage.haskell.org/packages/archive/threads/0.1/doc/html/src/Control-Concurrent-Thread-Group.html#fork Now if an asynchronous exception is thrown during the takeMVar in decrement there's no way I can prevent not releasing the lock causing the waiters to deadlock. This could be solved by wrapping decrement in nonInterruptibleMask. regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell.org re-design
Ivan Lazar Miljenovic wrote: Thomas Schilling nomin...@googlemail.com writes: http://i.imgur.com/kFqP3.png Didn't know about CSS's rgba to describe transparency. Very useful. It's a vely nice!! (in a Borat voice) +1. Both for the design, and for the content. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Hackage 2.0
On Wed, Apr 7, 2010 at 9:02 AM, Maciej Piechotka uzytkown...@gmail.com wrote: I guess 'works also with B in version X.Y.Z' is also. Most of the above changes should not be IMHO in cabal (sorry for answering PS here). Especially 'not maintained anymore' and 'does not build on recent GHC' ;) quote As we are with Haddock - 'rebuild' button if package failed to build? For some reasons some packages fails to build on hackage (as yi). I'm not sure if it will work however. At least uploading docs should be possible. Regards More flexibility for building times is a good thing, but people shouldn't able to DDOS the server by compiling, since it's a rather CPU-intensive thing, or by building documentation. Now, it looks like yi fails because data-accessor-template fails because of TH versioning issues (seemingly). I like the ideas of docs you can upload to get around these sorts of problems, and the ability to add links to other docs and tutorials. People could edit Hackage to reference haskellwiki, community.haskell.org, and other sites/services. I see what you mean about the changes being segregated from cabal, and I agree here. There's a set of information that's useful both for the web interface and for cabal-install (which is what Hackage currently displays, although perhaps not enough of it), and that should stay in the .cabal files. But, other information that's user-editable on Hackage is a plus. /Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
Gregory Crosswhite wrote: On Apr 8, 2010, at 12:25 PM, Casey McCann wrote: Seriously, floating point so-called numbers don't even have reflexive equality! They don't? I am pretty sure that a floating point number is always equal to itself, with possibly a strange corner case for things like +/- 0 and NaN. Exactly. NaN /= NaN. Other than that, I believe that let x = ... in x == x is true (because they are the same bitfield by definition), however it is easy to have 'the same number' without it having the same bitfield representation due to loss of precision and the like. To say nothing of failures of other laws leading to overflow, underflow, etc. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity
On Thu, Apr 8, 2010 at 11:45 PM, Bas van Dijk v.dijk@gmail.com wrote: On Thu, Apr 8, 2010 at 9:15 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: I still would like to see examples of where it's needed, because I slightly suspect that wrapping possibly-blocking operations in an exception handler that does something appropriate, along with ordinary 'mask', might be sufficient... But I expect to be proved wrong; I just haven't figured out how to prove myself wrong. Take my threads package, I uploaded to hackage yesterday, as an example. In Control.Concurrent.Thread.Group.fork... Control.Concurrent.Thread.fork is a similar and simpler example of why nonInterruptibleMask is needed: http://hackage.haskell.org/packages/archive/threads/0.1/doc/html/src/Control-Concurrent-Thread.html#fork If an asynchronous exception is thrown during the 'putMVar res' any waiters on the thread will never be woken up. regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-ODBC and SqlValues
John Goerzen wrote: Tim Docker wrote: Yes. I can use fromSql to convert the result back to an appropriate numerical type. But internally the numeric data has still been converted to an intermediate string representation. I'm wondering if this is intentional, and whether it matters. Yes and no, in that order. A ByteString is a pretty universal holder for various types of data. As someone else pointed out, at query time, we don't really have access to what type you will eventually want to use it as, and supporting the vast number of different ways to get things out of databases -- with the corresponding complexities of how a database driver can convert between them -- was just not worth it. It is generally assumed that the end user will be using fromSql anyhow, so it is not particularly relevant if it's a SqlByteString or a SqlInteger internally. I was wondering whether going via an intermediate string might cause issues relating to loss of precision in floating point values, or possible date conversion problems if locales were not set correctly. I'm seeing problems with date conversion, and wonder if this is related. Depending on my intended result type, I see conversion errors, in particular the 3rd example below seem to be related to formatting of the intermediate string: *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO Data.Time.Clock.UTCTime 2010-04-09 09:59:20.67 UTC *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO Data.Time.LocalTime 2010-04-09 09:59:26.313 *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO System.Time.CalendarTime *** Exception: Convertible: error converting source data SqlString 2010-04-09 09:59:37.460 of type SqlValue to type Data.Time.LocalTime.LocalTime.ZonedTime: Cannot parse using default format string %Y-%m-%d %T%Q %z *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO System.Time.ClockTime *** Exception: Convertible: error converting source data SqlString 2010-04-09 09:59:49.940 of type SqlValue to type Integer: Cannot read source value as dest type Thanks, Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: darcsum.el 1.2 released
On Thu, Apr 8, 2010 at 8:41 PM, Simon Michael si...@joyful.com wrote: With Christian's blessing, I have taken over maintenance of darcsum and would like to announce the 1.2 release: Nice! I'm a power user of darcsum and I'm definitely going to try out this release. Thanks for maintaining this tool, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
On Thu, Apr 8, 2010 at 7:58 PM, wren ng thornton w...@freegeek.org wrote: They don't? I am pretty sure that a floating point number is always equal to itself, with possibly a strange corner case for things like +/- 0 and NaN. Exactly. NaN /= NaN. Other than that, I believe that let x = ... in x == x is true (because they are the same bitfield by definition), however it is easy to have 'the same number' without it having the same bitfield representation due to loss of precision and the like. To say nothing of failures of other laws leading to overflow, underflow, etc. Indeed. NaN means that equality is not reflexive for floats in general, only a subset of them. Likewise, addition and multiplication are not associative and the distributive law doesn't hold. I think commutativity is retained, though. That's something, right? - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
On Apr 8, 2010, at 5:30 PM, Casey McCann wrote: On Thu, Apr 8, 2010 at 7:58 PM, wren ng thornton w...@freegeek.org wrote: Exactly. NaN /= NaN [...] Indeed. NaN means that equality is not reflexive for floats in general, only a subset of them. First of all, it isn't clear to me that NaN /= NaN, since in ghci the expression 1.0/0.0 == 1.0/0.0 evaluates to True. But even if that were the case, I would call that more of a technicality then meaning that equality is not reflexive for floats, since NaN is roughly the floating-point equivalent of _|_, and using the same argument one could also say that reflexivity does not hold in general for equating values of *any* Haskell type since (_|_ == _|_) does not return true but rather _|_. (Don't get me wrong, I agree with your point that multiplication and addition are neither associative nor distributive and other such nasty things occur when dealing with floating point numbers, it's just that I think that saying they are so messed up that even equality is not reflexive is a little harsher than they actually deserve. ;-) ) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-ODBC and SqlValues
Tim Docker wrote: *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO Data.Time.Clock.UTCTime 2010-04-09 09:59:20.67 UTC *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO Data.Time.LocalTime 2010-04-09 09:59:26.313 *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO System.Time.CalendarTime *** Exception: Convertible: error converting source data SqlString 2010-04-09 09:59:37.460 of type SqlValue to type That is to be expected. You are converting data from the underlying database that does not contain timezone information. Thus it is not possible to populate ctTZ in CalendarTime. Data.Time.LocalTime.LocalTime.ZonedTime: Cannot parse using default format string %Y-%m-%d %T%Q %z *Main fmap (fromSql.head.head) $ quickQuery c select getdate() [] :: IO System.Time.ClockTime *** Exception: Convertible: error converting source data SqlString 2010-04-09 09:59:49.940 of type SqlValue to type Integer: Cannot read source value as dest type And here you don't have something in seconds-since-epoch format. What you have is an unzoned date and time. Therefore it makes sense that you can convert it to a LocalTime. It does not have enough information to make it into a CalendarTime because it lacks a zone. It also isn't in seconds-since-epoch format, which is what a ClockTime is. The conversions to UTCTime and LocalTime work because they do not require a timezone to be present in the input data. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity
On 04/08/10 19:56, Bas van Dijk wrote: Control.Concurrent.Thread.fork is a similar and simpler example of why nonInterruptibleMask is needed: http://hackage.haskell.org/packages/archive/threads/0.1/doc/html/src/Control-Concurrent-Thread.html#fork If an asynchronous exception is thrown during the 'putMVar res' any waiters on the thread will never be woken up. OK, thanks for the link! In fact, [tell me if my reasoning is wrong...], in that fork-definition, the 'putMVar' will never block, because there is only putMVar one for each created MVar. I seem to remember that any execution of putMVar that does not *actually* block is guaranteed not be interrupted by asynchronous exceptions (if within a Control.Exception.block) -- which would be sufficient. Is my memory right or wrong? -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
Am Freitag 09 April 2010 02:51:23 schrieb Gregory Crosswhite: On Apr 8, 2010, at 5:30 PM, Casey McCann wrote: On Thu, Apr 8, 2010 at 7:58 PM, wren ng thornton w...@freegeek.org wrote: Exactly. NaN /= NaN [...] Indeed. NaN means that equality is not reflexive for floats in general, only a subset of them. First of all, it isn't clear to me that NaN /= NaN, Specified by IEEE 754, IIRC. since in ghci the expression 1.0/0.0 == 1.0/0.0 evaluates to True. Yes, but 1/0 isn't a NaN: Prelude isNaN (1.0/0.0) False Prelude isNaN (0.0/0.0) True Prelude 1.0/0.0 Infinity Prelude 0.0/0.0 NaN Prelude (0.0/0.0) == (0.0/0.0) False But even if that were the case, I would call that more of a technicality then meaning that equality is not reflexive for floats, since NaN is roughly the floating-point equivalent of _|_, and using the same argument one could also say that reflexivity does not hold in general for equating values of *any* Haskell type since (_|_ == _|_) does not return true but rather _|_. Very roughly. But I agree with your point, though x == x returning False isn't quite the same as x == x returning _|_ (repeat 1 == repeat 1). (Don't get me wrong, I agree with your point that multiplication and addition are neither associative nor distributive and other such nasty things occur when dealing with floating point numbers, it's just that I think that saying they are so messed up that even equality is not reflexive is a little harsher than they actually deserve. ;-) ) Yup. But using (==) on floating point numbers is dangerous even without NaNs. Warning against that can be beneficial. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSoC Project: A Haddock + Pandoc documentation tool
Hello, I just finished writing my GSoC proposal and I want to have some feedback from the community. I'll try to be brief (this is not the proposal). The project is about creating a new documentation tool for Haskell projects, like Sphinx[1] for Python or Scribble[2] for Scheme. We have Haddock, which is a great tool. It can take the sources of a project and generate a useful API reference. But the reference is just a fragment of the whole project documentation. So, Haddock can only do a part of what Sphinx can do. But we have another tool, Pandoc, that takes files of whatever markup language and transform it to another format. And this is the more general-purposed part of Sphinx that is missing in Haddock. So we have the tools for creating documentation as useful as other systems, we just need the glue and several improvements. To achieve this project, first I'll have to use Haddock as an API. Currently, the Haddock API is rudimentary and highly experimental, so I would have to extend and test it. Then I would have to write a Haddock backend which would generate the reference in an internal independent pandoc format [3]. Finally I would have to write a new command-line program that would manage the projects or I would have to add Pandoc support in Haddock command-line program or Haddock support in Pandoc. IMHO, I think that will be better a new command-line program, everyone with its own purpose. I created an example of what would be a library documented with this system [4]. The file contains a configuration file a la cabal, a reST file (It could be markdown) and the html output. I tried to represent that the html output for the reference have to be almost the same that generates Haddock (css may differ). Note that all the entries of the Haddock reference are first-citizens entities in the documentation, so you can refer to the entries, render one entry, all or by groups (there are examples in the reST file). I am looking forward your impressions and suggestions. Thanks to Simon Marlow, David Waern and Conal Elliott for their suggestions and help. Thanks you all. [1] http://sphinx.pocoo.org/ [2] http://docs.plt-scheme.org/scribble/ [3] http://hackage.haskell.org/packages/archive/pandoc/1.5.1.1/doc/html/Text-Pandoc-Definition.html#t%3APandoc [4] http://bitbucket.org/viator/doc-example/get/tip.zip ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
On Apr 8, 2010, at 6:53 PM, Daniel Fischer wrote: Am Freitag 09 April 2010 02:51:23 schrieb Gregory Crosswhite: Yes, but 1/0 isn't a NaN: Prelude isNaN (1.0/0.0) False Prelude isNaN (0.0/0.0) True Prelude 1.0/0.0 Infinity Prelude 0.0/0.0 NaN Prelude (0.0/0.0) == (0.0/0.0) False Curse you for employing the dirty trick of employing easily verifiable facts to prove me wrong! :-) Yup. But using (==) on floating point numbers is dangerous even without NaNs. Warning against that can be beneficial. Fair enough. On a tangental note, I've considered coding up a package with an AlmostEq typeclass that allows one to test for approximate equality. The problem is that different situations call for different tolerances so there is no standard approximate equal operator that would work for everyone, but there might be a tolerance that is good enough for most situations where it would be needed (such as using QuickCheck to test that two different floating-point functions that are supposed to return the same answer actually do so) to make it worthwhile to have a standard package for this around for the sake of convenience. Anyone have any thoughts on this? Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSoC proposal: Extend Cabal Preprocessors.
Hi! I finish writing my proposal (maybe a bit too late). I would be glad to read any feedback. http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/diegoeche/t127067573658 Best Regards, Diego Echeverri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms
On Thu, Apr 8, 2010 at 8:51 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: First of all, it isn't clear to me that NaN /= NaN, since in ghci the expression 1.0/0.0 == 1.0/0.0 evaluates to True. But even if that were the case, I would call that more of a technicality then meaning that equality is not reflexive for floats, since NaN is roughly the floating-point equivalent of _|_, and using the same argument one could also say that reflexivity does not hold in general for equating values of *any* Haskell type since (_|_ == _|_) does not return true but rather _|_. The difference there is that _|_ generally means the entire program has shuffled off this mortal coil, whilst a (non-signalling) NaN is, by specification, silently and automatically propagated, turning everything it touches into more NaNs. The very sensible purpose of this is to allow computations on floats to be written in a straightforward manner without worrying about intermediate errors, rather than having NaN checks everywhere, or having to worry about exceptions all the time. In that regard, it's more analogous to all floating point operations occurring in an implicit Maybe monad, except with Nothing treated as False by conditionals. (==) $ Nothing * Nothing indeed does not evaluate to Just True, so in a sense equality is also not reflexive for types such as Maybe Integer. Although I like to make fun of floats as being sorry excuses for numbers, the way they work is actually quite sensible from the perspective of doing low-level computations with fractional numbers. Now, if only certain... other... programming languages were as well-designed, and could silently and safely propagate values like Not a Reference or Not a Pointer. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] floating-point comparison (was haskell gsoc proposal for richer numerical type classes and supporting algorithms)
--- On Thu, 4/8/10, Gregory Crosswhite gcr...@phys.washington.edu wrote: From: Gregory Crosswhite gcr...@phys.washington.edu On a tangental note, I've considered coding up a package with an AlmostEq typeclass that allows one to test for approximate equality. The problem is that different situations call for different tolerances so there is no standard approximate equal operator that would work for everyone, but there might be a tolerance that is good enough for most situations where it would be needed (such as using QuickCheck to test that two different floating-point functions that are supposed to return the same answer actually do so) to make it worthwhile to have a standard package for this around for the sake of convenience. Anyone have any thoughts on this? It's always worth pointing out http://docs.sun.com/source/806-3568/ncg_goldberg.html at this point (not that it really helps you out in this case) Doug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Thu, Apr 8, 2010 at 5:53 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: I think it's important to be able to convert into standard or custom formats. I've no idea if JUnit XML would make sense as the native format. It's plausible. I hadn't really thought about cabal, itself, being a consumer for test results -- but I like your (Duncan's) points about defining a testing interface, and keeping it extensible. For the record: I don't think junit xml is a good choice for a native format :), but I do think it's a good format to start with simply because there are many tools that can consume it already. --Rogan 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] GSoC Project: A Haddock + Pandoc documentation tool
On Apr 8, 2010, at 6:55 PM, ViaToR (Alvaro V.) wrote: I just finished writing my GSoC proposal ... The project is about creating a new documentation tool for Haskell projects,... I've taken a brief look and this looks lovely. I'm currently deep at work on re-coding the Haddock backend to produce semantic XHTML rather than table-nested HTML. I'm pretty familiar now with the internals of the backends of Haddock and would be happy to help you. General GSoC question: Would this be good time to offer to be a mentor? Do we have too many mentors or would it be useful for me to help out here? If so, do I need to register on the GSoC site today or tomorrow? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
My thanks to all of you for your help! I've submitted my proposal as of this afternoon. I've done my best to ensure that the fruits of this discussion are represented there. As an aside, the Google's form has seriously mangled my formatting; if anyone here has past experience and/or pointers, I'd love to hear them! Thanks! -- Thomas Tuegel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Hackage 2.0
On Thu, Apr 8, 2010 at 6:38 PM, Matthew Gruen wikigraceno...@gmail.com wrote: On Wed, Apr 7, 2010 at 9:02 AM, Maciej Piechotka uzytkown...@gmail.com wrote: I guess 'works also with B in version X.Y.Z' is also. Most of the above changes should not be IMHO in cabal (sorry for answering PS here). Especially 'not maintained anymore' and 'does not build on recent GHC' ;) quote As we are with Haddock - 'rebuild' button if package failed to build? For some reasons some packages fails to build on hackage (as yi). I'm not sure if it will work however. At least uploading docs should be possible. Regards More flexibility for building times is a good thing, but people shouldn't able to DDOS the server by compiling, since it's a rather CPU-intensive thing, or by building documentation. Now, it looks like yi fails because data-accessor-template fails because of TH versioning issues (seemingly). I like the ideas of docs you can upload to get around these sorts of problems, and the ability to add links to other docs and tutorials. People could edit Hackage to reference haskellwiki, community.haskell.org, and other sites/services. I see what you mean about the changes being segregated from cabal, and I agree here. There's a set of information that's useful both for the web interface and for cabal-install (which is what Hackage currently displays, although perhaps not enough of it), and that should stay in the .cabal files. But, other information that's user-editable on Hackage is a plus. One thing in the branch over in http://code.haskell.org/hackage-server is the ability for package maintainers to upload documentation to the server. This way we're not tying the ability of the server doing a build-check to the ability to host documentation for a package. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Hackage 2.0
On Thu, Apr 8, 2010 at 10:58 PM, Antoine Latter aslat...@gmail.com wrote: One thing in the branch over in http://code.haskell.org/hackage-server is the ability for package maintainers to upload documentation to the server. This way we're not tying the ability of the server doing a build-check to the ability to host documentation for a package. Antoine Antoine, hi, I'm still absorbing the great things that have been done in hackage-server so far. I saw some documentation replacement logic in the code, but don't see a web interface for it. Is there one I'm missing? —Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LLVM study SoC proposal
Hi. I wrote a(nother) SoC proposal for studying LLVM performance, compared with the Native Code Generator back-end. It's available at: http://www2.dcc.ufmg.br/laboratorios/llp/wiki/doku.php?id=marco_soc2 I know the deadline is now near, but I'd be happy to hear comments about it and update it before 19:00 UTC. Thanks. -- marcot http://wiki.debian.org/MarcoSilva ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Nested unsafePerformIO?
DavidA polyom...@f2s.com wrote: I am having difficulty debugging a troublesome stack overflow, which I think might be related to calling unsafePerformIO from within the IO monad. [...] f x = unsafePerformIO $ do m - randomRIO (1,2) return (m+x) As a side note you don't need unsafePerformIO here. Instead you should implement something like iterateM: iterateM :: Monad m = (a - m a) - a - m [a] or change the type of your timedIterateIO to: timedIterateIO :: Int - (a - IO a) - a - IO a Also to do the actual timing you can use concurrency with SampleVar, which is cleaner and probably also faster: timedIterateIO :: Int - (a - IO a) - a - IO a timedIterateIO time f x0 = do resultVar - newSampleVar x0 tid - forkIO $ iterateFunc resultVar x0 threadDelay time readSampleVar resultVar * killThread tid where iterateFunc resultVar x0 = x0 `seq` do x1 - f x0 writeSampleVar resultVar x1 iterateFunc resultVar x1 Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://blog.ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project: A Haddock + Pandoc documentation tool
On Fri, Apr 9, 2010 at 4:35 AM, Mark Lentczner ma...@glyphic.com wrote: On Apr 8, 2010, at 6:55 PM, ViaToR (Alvaro V.) wrote: I just finished writing my GSoC proposal ... The project is about creating a new documentation tool for Haskell projects,... I've taken a brief look and this looks lovely. I'm currently deep at work on re-coding the Haddock backend to produce semantic XHTML rather than table-nested HTML. I'm pretty familiar now with the internals of the backends of Haddock and would be happy to help you. General GSoC question: Would this be good time to offer to be a mentor? Do we have too many mentors or would it be useful for me to help out here? If so, do I need to register on the GSoC site today or tomorrow? Yes. Since you know Haddock well and care about the project you should definitely sign up. The student application deadline is today at 19:00 UTC. I think mentors can still join after that deadline (if I read the SoC timeline correctly) but I suggest signing up as a mentor today. During the next few weeks the mentors will decide which projects will get accepted and who will mentor them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
