Re: [Haskell-cafe] ANNOUNCE: TKYProf
On Wed, Aug 17, 2011 at 00:31, Sebastian Fischer fisc...@nii.ac.jp wrote: Additionally, I linked /usr/lib/libstdc++.so.6 to /usr/lib/libstdc++.so before I could successfully install tkyprof. Not sure about the consequences.. This means you didn't install your distribution's libstdc++-dev (or whatever it is called in yours package. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: TKYProf
On 17 August 2011 07:16, Michael Snoyman mich...@snoyman.com wrote: There's a bug in GHC that prevents C++ code from working correctly with Template Haskell For reference this is the bug Michael is talking about: http://hackage.haskell.org/trac/ghc/ticket/5289 As explained by Sebastian and the ticket, to work around this you need to perform the following steps: $ sudo ln -vs $(gcc --print-file-name=libstdc++.so) /usr/local/lib/ $ sudo ldconfig Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why is Random in System?
Brandon Allbery allber...@gmail.com wrote: I've noticed there's a convention to put modules having to deal with randomness into System.Random. I thought System was for OS interaction? Granted getting a random seed usually means going to the OS, but isn't the rest of it, like generating random sequences, distributions, selecting based on probability, shuffling, etc. all non-OS related algorithms? System definitely does seem like an odd choice. In most cases the only interaction any PRNG, even when accessed via the FFI, has with the system is - as you say - to get an initial seed value for a global instance. I'd be tempted to guess that the whole reason it's under System is the IO component. That's not really valid, is it? After all the new 'time' package is also stationed under the Data tree, and it has a similarly large IO component. I have to say, it seems very intuitive to me to look for it under Data, even though I'm not sure why. Probably I'm just used to it. Time has a strong connection to the operating system and the hardware, so it could just as well go into the System tree. For (non-cryptographic) randomness however we are dealing with numerical data, for which the connection to the system is mere convenience, so I wouldn't mind finding it under Data at all. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] broken on install encoding 0.6.6
hi, cafe: I go through to the encoding package installation problem again. cabal install encoding Resolving dependencies... /tmp/encoding-0.6.68093/encoding-0.6.6/dist/setup/setup: 4: Syntax error: ; unexpected when I have a check on the this issue, I get: file ~/.cabal/packages/ hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup /home/gang/.cabal/packages/ hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, not stripped My machine is: gang@gang-laptop:~$ uname -a Linux gang-laptop 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux is this related? How can I manually install the package from scratch? Any helps or directs will be appreciated Thanks Gang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell transformation of C code
Hello all I am trying implement this algorithm [ http://stackoverflow.com/questions/1621364/how-to-find-largest-triangle-in-convex-hull-aside-from-brute-force-search ] in Haskell but i am getting wrong answer for some test cases. A c++ implementation which is accepted for this problem [ http://www.spoj.pl/problems/MTRIAREA ] and i rewrote the C++ code in Haskell . Running both programs on some random test cases produce different result . For Haskell implementation , convex hull part is correct . Both codes [ c++ and Haskell ] produced same convex hull so i am skeptical about looPing :: ( Num a , Ord a , Eq a , Floating a ) = Int - Int - Int - Int - a - Array Int ( Point a ) - a and calArea :: ( Num a , Ord a , Floating a ) = Int - Int - Int - Int - a - Array Int ( Point a ) - ( Int , Int , Int , a ) function . Could some one please tell me what is wrong with these functions. I have posted both code on ideone . Haskell code [ http://ideone.com/IlwBv ] and accepted c++ for SPOJ problem [ http://ideone.com/vgNnt ] . For test case 20 886 9383 6915 2777 8335 7793 492 5386 1421 6649 27 2362 59 8690 3926 7763 3426 540 5736 9172 5368 5211 6429 2567 1530 5782 5123 2862 3135 4067 9802 3929 3058 4022 8167 3069 8456 1393 8042 5011 -1 Haskell produced the convex hull [P 27.0 2362.0,P 3426.0 540.0,P 8456.0 1393.0,P 9802.0 3929.0,P 8335.0 7793.0,P 5736.0 9172.0,P 886.0 9383.0,P 59.0 8690.0] and maximum triangle area 31466755.50 while C++ code produced the convex hull 27 2362 3426 540 8456 1393 9802 3929 8335 7793 5736 9172 886 9383 59 8690 and maximum area 33642111.00 . Based on these observation , I think my convex hull part is correct and I am stuck with looPing and calArea function . I tried to write Haskell code many ways but no success so it would be great if some one can tell me what is wrong with these two functions . Thank you ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] broken on install encoding 0.6.6
Solved. Under my ghc6.12.3 environment, I manually downloaded and installed the encoding-0.6.3 package together with mtl-1.1.0.2, and pin HaXml to 1.19 , Modify the dependence rules of mtl to mtl 2 HaXml=1.19 to HaXml=1.19 Then runhaskell Setup configure --flags=splitBase --flags=newGHC --user --ghc runhaskell Setup build runhaskell Setup install works, sorry to bother Regards Gang On 08/17/2011 04:59 PM, Gang Yu wrote: hi, cafe: I go through to the encoding package installation problem again. cabal install encoding Resolving dependencies... /tmp/encoding-0.6.68093/encoding-0.6.6/dist/setup/setup: 4: Syntax error: ; unexpected when I have a check on the this issue, I get: file ~/.cabal/packages/hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup http://hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup /home/gang/.cabal/packages/hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup http://hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, not stripped My machine is: gang@gang-laptop:~$ uname -a Linux gang-laptop 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux is this related? How can I manually install the package from scratch? Any helps or directs will be appreciated Thanks Gang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] writing a good Setup.hs is *hard* (was: broken on install encoding 0.6.6)
On Wed, Aug 17, 2011 at 6:29 AM, Gang yugang...@gmail.com wrote: sorry to bother Not in the least! I was trying to figure out what problem you were encountering, and I learned a lot. I never did recreate your problem, but in the process I ran into a whole host of other annoyances and strange situations relating to slightly broken cabal files and cabal build intricacies that confound our existing tools. I don't mean to pick on encoding or HaXml - I've seen the same kinds of issues in many, many Haskell packages (including most of the packages I've written myself) these are just the ones I ran into today. (and I am quite serious when I say that writing a good Setup.hs is very, very, difficult). My objective is just to motivate a minor change to cabal that would help to make this easier. On to the build problems: encoding-0.6.6 uses it's own source during the build process! It actually has to be partially compiled before the build tool can build encoding (!). I'm *amazed* that this actually works at all (impressed, too), and indeed, it doesn't work with cabal-dev, which is unfortunate: cabal-dev would have identified one of the dependency issues in HaXml 1.19 (pretty is an undocumented dependency, although I am unsure if that was true at the time 1.19 and encoding-0.6.6 were released. I haven't tracked the pretty dependency down to the exact source - it could be a transitive dep introduced by a recent version of something HaXml 1.19 needs. Per my subject line - this is amazingly difficult - keep in mind that we're not talking about building *packages*, this is just to build the *build tool*, and none of this is documented. How long before it is effectively impossible to recreate the circumstances that result in a successful encoding-0.6.6 build?). cabal-dev can't build encoding-0.6.6 because the encoding source that is referenced from encoding's Setup.hs depends on (at least) HaXml = 1.19 1.22.5; this is OK with cabal, since cabal-install installs a necessary HaXml into your user package db prior to building encoding's Setup.hs (modulo the missing upper version bound). Therefore HaXml just happens to be visible when cabal builds Setup.hs -- a build step that cabal-dev isn't capable of controlling (and probably never will be -- we could intercept system calls, but that's difficult when only supporting one OS, much less three). You can, of course, manually install HaXml to your local package db and then cabal-dev install encodings, but that's somewhat of a hack (and you'll find that the current HaXml won't work for the current encodings release, as Gang Yu did). Adding a section to the cabal file that specifies build dependencies for Setup.hs would make some very important parts of this process obvious - and it would *greatly* assist in debugging failing builds, not to mention allowing us to make use of the extensive libraries on hackage to write more expressive build systems. (We could actually use openshake in Setup.hs, once it's released, for example!) I've floated the idea past a number of Haskell programmers with positive responses, and there is a GSOC ticket that provides some more details (the project was not selected - no students proposed to work on it): http://hackage.haskell.org/trac/summer-of-code/ticket/1602 --Rogan Regards Gang On 08/17/2011 04:59 PM, Gang Yu wrote: hi, cafe: I go through to the encoding package installation problem again. cabal install encoding Resolving dependencies... /tmp/encoding-0.6.68093/encoding-0.6.6/dist/setup/setup: 4: Syntax error: ; unexpected when I have a check on the this issue, I get: file ~/.cabal/packages/hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup /home/gang/.cabal/packages/hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, not stripped My machine is: gang@gang-laptop:~$ uname -a Linux gang-laptop 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux is this related? How can I manually install the package from scratch? Any helps or directs will be appreciated Thanks Gang ___ 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 transformation of C code
I had to stare at this for a while to see the difference. In the C++ version the comparison's in loop B and loop C are always between areas of triangles that are off by one in a single index. In the haskell calArea though, comparisons are between the passed area and triangles off by one from the passed coordinates. Recursive calls under calArea hold the invariant found in the C++ code, but in looPing area' is the area of a' b' c', but the recursive call is to looPing a'' b'' c'' with area' so calArea is passed the indexes for a different triangle then the area it is given. We can solve this by explicitly passing around the best result so far: looPing :: ( Num a , Ord a , Eq a , Floating a ) = Int - Int - Int - Int - a - a - Array Int ( Point a ) - a looPing a b c n area best arr | a == n = max best area | otherwise = looPing a'' b'' c'' n area'' (max area' best) arr where ( a' , b' , c' , area' ) = calArea a b c n area arr a'' = a' + 1 b'' = if a'' == b' then mod ( b' + 1 ) n else b' c'' = if b'' == c' then mod ( c' + 1 ) n else c' area'' = caltmp (a'' `mod` n) b'' c'' arr and solve now applies area twice: looPing 0 1 2 n area area arr' This now matches the result from C++ for me. On Wed, Aug 17, 2011 at 8:09 AM, mukesh tiwari mukeshtiwari.ii...@gmail.com wrote: Hello all I am trying implement this algorithm [ http://stackoverflow.com/questions/1621364/how-to-find-largest-triangle-in-convex-hull-aside-from-brute-force-search ] in Haskell but i am getting wrong answer for some test cases. A c++ implementation which is accepted for this problem [ http://www.spoj.pl/problems/MTRIAREA ] and i rewrote the C++ code in Haskell . Running both programs on some random test cases produce different result . For Haskell implementation , convex hull part is correct . Both codes [ c++ and Haskell ] produced same convex hull so i am skeptical about looPing :: ( Num a , Ord a , Eq a , Floating a ) = Int - Int - Int - Int - a - Array Int ( Point a ) - a and calArea :: ( Num a , Ord a , Floating a ) = Int - Int - Int - Int - a - Array Int ( Point a ) - ( Int , Int , Int , a ) function . Could some one please tell me what is wrong with these functions. I have posted both code on ideone . Haskell code [ http://ideone.com/IlwBv ] and accepted c++ for SPOJ problem [ http://ideone.com/vgNnt ] . For test case 20 886 9383 6915 2777 8335 7793 492 5386 1421 6649 27 2362 59 8690 3926 7763 3426 540 5736 9172 5368 5211 6429 2567 1530 5782 5123 2862 3135 4067 9802 3929 3058 4022 8167 3069 8456 1393 8042 5011 -1 Haskell produced the convex hull [P 27.0 2362.0,P 3426.0 540.0,P 8456.0 1393.0,P 9802.0 3929.0,P 8335.0 7793.0,P 5736.0 9172.0,P 886.0 9383.0,P 59.0 8690.0] and maximum triangle area 31466755.50 while C++ code produced the convex hull 27 2362 3426 540 8456 1393 9802 3929 8335 7793 5736 9172 886 9383 59 8690 and maximum area 33642111.00 . Based on these observation , I think my convex hull part is correct and I am stuck with looPing and calArea function . I tried to write Haskell code many ways but no success so it would be great if some one can tell me what is wrong with these two functions . Thank you ___ 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] ICFP Hotel Roommate
Hi, I'll be heading to ICFP in September, and I'm hoping to find someone to share a room with to save on hotel costs. Are there any other students looking for a roommate? Cheers, Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell transformation of C code
Thank you for your reply. On Aug 17, 7:48 pm, Ryan Yates fryguy...@gmail.com wrote: I had to stare at this for a while to see the difference. In the C++ version the comparison's in loop B and loop C are always between areas of triangles that are off by one in a single index. In the haskell calArea though, comparisons are between the passed area and triangles off by one from the passed coordinates. Recursive calls under calArea hold the invariant found in the C++ code, but in looPing area' is the area of a' b' c', but the recursive call is to looPing a'' b'' c'' with area' so calArea is passed the indexes for a different triangle then the area it is given. We can solve this by explicitly passing around the best result so far: looPing :: ( Num a , Ord a , Eq a , Floating a ) = Int - Int - Int - Int - a - a - Array Int ( Point a ) - a looPing a b c n area best arr | a == n = max best area | otherwise = looPing a'' b'' c'' n area'' (max area' best) arr where ( a' , b' , c' , area' ) = calArea a b c n area arr a'' = a' + 1 b'' = if a'' == b' then mod ( b' + 1 ) n else b' c'' = if b'' == c' then mod ( c' + 1 ) n else c' area'' = caltmp (a'' `mod` n) b'' c'' arr and solve now applies area twice: looPing 0 1 2 n area area arr' This now matches the result from C++ for me. On Wed, Aug 17, 2011 at 8:09 AM, mukesh tiwari mukeshtiwari.ii...@gmail.com wrote: Hello all I am trying implement this algorithm [ http://stackoverflow.com/questions/1621364/how-to-find-largest-triang... ] in Haskell but i am getting wrong answer for some test cases. A c++ implementation which is accepted for this problem [http://www.spoj.pl/problems/MTRIAREA ] and i rewrote the C++ code in Haskell . Running both programs on some random test cases produce different result . For Haskell implementation , convex hull part is correct . Both codes [ c++ and Haskell ] produced same convex hull so i am skeptical about looPing :: ( Num a , Ord a , Eq a , Floating a ) = Int - Int - Int - Int - a - Array Int ( Point a ) - a and calArea :: ( Num a , Ord a , Floating a ) = Int - Int - Int - Int - a - Array Int ( Point a ) - ( Int , Int , Int , a ) function . Could some one please tell me what is wrong with these functions. I have posted both code on ideone . Haskell code [http://ideone.com/IlwBv] and accepted c++ for SPOJ problem [http://ideone.com/vgNnt] . For test case 20 886 9383 6915 2777 8335 7793 492 5386 1421 6649 27 2362 59 8690 3926 7763 3426 540 5736 9172 5368 5211 6429 2567 1530 5782 5123 2862 3135 4067 9802 3929 3058 4022 8167 3069 8456 1393 8042 5011 -1 Haskell produced the convex hull [P 27.0 2362.0,P 3426.0 540.0,P 8456.0 1393.0,P 9802.0 3929.0,P 8335.0 7793.0,P 5736.0 9172.0,P 886.0 9383.0,P 59.0 8690.0] and maximum triangle area 31466755.50 while C++ code produced the convex hull 27 2362 3426 540 8456 1393 9802 3929 8335 7793 5736 9172 886 9383 59 8690 and maximum area 33642111.00 . Based on these observation , I think my convex hull part is correct and I am stuck with looPing and calArea function . I tried to write Haskell code many ways but no success so it would be great if some one can tell me what is wrong with these two functions . Thank you ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://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] why is Random in System?
Hi all, I'm the maintainer of random. If people could decide on what the alternative name would be we could put it through the library proposal process. It seems that one problem at this moment is the lack of a single, clear right answer. Replacing one debatable not-quite-right choice with another may not be satisfying ;-). Also, what Thomas says is right. The current implementation is SLOW and WEAK, which would not seem to make a good default implementation. The goal is to replace it with something better so that the default random package is strong in at least one dimension. I think this is important because I imagine many people use the default package, for example because they don't want to scour hackage and try all the alternatives. My proposal for this has been to use AES based crypto-prng. I think that is fast enough (i.e. faster than what's currently there), very strong, and splittable. New Intel and AMD hardware has hardware support for AES which makes it even faster. The intel-aes package provides this functionality, with and without hardware support. But there's work left to do in terms of testing, making sure its cross platform, etc. Anyone who's interested in helping (especially with Windows support) would be warmly welcomed! Cheers, -Ryan On Wed, Aug 17, 2011 at 4:46 AM, Ertugrul Soeylemez e...@ertes.de wrote: Brandon Allbery allber...@gmail.com wrote: I've noticed there's a convention to put modules having to deal with randomness into System.Random. I thought System was for OS interaction? Granted getting a random seed usually means going to the OS, but isn't the rest of it, like generating random sequences, distributions, selecting based on probability, shuffling, etc. all non-OS related algorithms? System definitely does seem like an odd choice. In most cases the only interaction any PRNG, even when accessed via the FFI, has with the system is - as you say - to get an initial seed value for a global instance. I'd be tempted to guess that the whole reason it's under System is the IO component. That's not really valid, is it? After all the new 'time' package is also stationed under the Data tree, and it has a similarly large IO component. I have to say, it seems very intuitive to me to look for it under Data, even though I'm not sure why. Probably I'm just used to it. Time has a strong connection to the operating system and the hardware, so it could just as well go into the System tree. For (non-cryptographic) randomness however we are dealing with numerical data, for which the connection to the system is mere convenience, so I wouldn't mind finding it under Data at all. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ 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] Overloading in a sub-class
Hi, Below are two questions concerning overloading in a sub-class. Thanks, Pat class Numb0 a where (+) :: a - a - a negate :: a - a instance Numb0 Int where x + y = y negate x = x -- Are + and negate part of the signature of Numb1? class Numb0 a = Numb1 a where -- Is it possible to override these operations in instances of Numb1? -- Something like: -- instance Numb1 Float where --x + y = y --negate x = x -- Or even using Int as in the super class instance: -- instance Numb1 Int where --x + y = y --negate x = x This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why is Random in System?
Ryan Newton rrnew...@gmail.com wrote: I'm the maintainer of random. If people could decide on what the alternative name would be we could put it through the library proposal process. It seems that one problem at this moment is the lack of a single, clear right answer. Replacing one debatable not-quite-right choice with another may not be satisfying ;-). Also, what Thomas says is right. The current implementation is SLOW and WEAK, which would not seem to make a good default implementation. The goal is to replace it with something better so that the default random package is strong in at least one dimension. I think this is important because I imagine many people use the default package, for example because they don't want to scour hackage and try all the alternatives. My proposal for this has been to use AES based crypto-prng. I think that is fast enough (i.e. faster than what's currently there), very strong, and splittable. New Intel and AMD hardware has hardware support for AES which makes it even faster. The intel-aes package provides this functionality, with and without hardware support. But there's work left to do in terms of testing, making sure its cross platform, etc. Anyone who's interested in helping (especially with Windows support) would be warmly welcomed! Using a cryptographically strong random number generator here is probably a very bad idea. Two reasons: Firstly while being faster than the current implementation an AES-based implementation will still be considerably slower than the Mersenne Twister algorithm. This may or may not be true, if hardware AES support is there, but don't just assume that everybody has AES instructions now. For example I don't have them. Secondly there is no standard requiring that the default random number generator is cryptographically safe. Changing this particular implementation, which is the one most people use, to a CSPRNG will make people take for granted that System.Random is safe to use in security-related products, because it would be very convenient. This will render strong security products trivially weak, when compiled with the wrong Haskell distribution, and you will find packages with statements like: We assume that you use Ryan Newton's distribution of the random package. I would rather propose the Mersenne Twister as the default random number generator. You could add AES as a secondary generator for people requiring cryptographic strength, but then do it properly, i.e. impure, because most people, when reading about a PRNG with AES anywhere in its name, will just assume that it's a CSPRNG. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why is Random in System?
On Wed, Aug 17, 2011 at 8:56 AM, Ryan Newton rrnew...@gmail.com wrote: I'm the maintainer of random. If people could decide on what the alternative name would be we could put it through the library proposal process. It seems that one problem at this moment is the lack of a single, clear right answer. Replacing one debatable not-quite-right choice with another may not be satisfying ;-). The entire premise of that discussion seems quite ridiculous. All that renaming the modules will achieve is the breakage of several hundred packages. The roots of the module naming hierarchy - Control, Data, System, and so on - are so muddled and inconsistently used that the best advice you could give to people who raise this topic is to pretend those roots are simply not there. My proposal for this has been to use AES based crypto-prng. We'd be better off if you could seek consensus from PRNG maintainers on a fixed-up Random class before attacking this problem, so that we'd have a better chance of achieving cross-package compatibility. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: TKYProf
I'm not sure I understand the comments there. Does this solve the issue for GHC 7.2 only, or for 7.* as well? Yesod is still officially supporting 6.12 and 7.0. On Wed, Aug 17, 2011 at 11:17 AM, Bas van Dijk v.dijk@gmail.com wrote: On 17 August 2011 07:16, Michael Snoyman mich...@snoyman.com wrote: There's a bug in GHC that prevents C++ code from working correctly with Template Haskell For reference this is the bug Michael is talking about: http://hackage.haskell.org/trac/ghc/ticket/5289 As explained by Sebastian and the ticket, to work around this you need to perform the following steps: $ sudo ln -vs $(gcc --print-file-name=libstdc++.so) /usr/local/lib/ $ sudo ldconfig Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why is Random in System?
The problem with Mersenne twister is that it doesn't split well. The main reason for crypto prng in this package would not be to advertise to people that System.Random can be used for security-related apps *but to make splitting reasonably safe*. It's not good enough to have a known-bad generator under splitting provided as the default. And I think we need splitting, especially as more Haskell programs become parallel. Would it address your concerns to not mention the crypto nature of the standard implementation in the System.Random documentation? I think there's also a reasonable argument to lean towards *correctness* over performance in Haskell's defaults. For example, unconstrained Num bindings default to Integer and likewise random numbers could be as strong as possible by default, and those looking for raw rands/sec throughput could make other informed choices. I had thought that maybe we could bifurcate the stdgen concept into a fast and a strong version, which could be say Mersenne Twister and AES respectively. But, again, the problem comes if the fast version is expected to be splittable as well. With SplittableGen factored out from RandomGen I suppose it would be possible for the fast version to NOT offer splitting. However, Mersenne Twister is best used with an imperative interface, you can see the tension in the pure version of the mersenne package on hackage: http://hackage.haskell.org/package/mersenne-random-pure64-0.2.0.3 Please also see Burton Smith's comments below in response to my proposal to offer a MT + AES combination. Best, -Ryan -- Forwarded message -- From: Burton Smith burt...@microsoft.com Date: Tue, Jun 28, 2011 at 1:28 PM Subject: RE: AESNI-based splittable random number generation for Haskell To: Newton, Ryan R ryan.r.new...@intel.com Mersenne Twister (MT)is a poor choice in my opinion. First, the generator state is large (2496 bytes) and it must be copied on each call to next. Split is worse; it will generate twice as many bytes per call as next will. Second, I see no good way to guarantee independence of the two generators emanating from a split. MT is hard to initialize anyway, and giant-stepping it to define the newly split generator (as we did back in the 80's paper) is not only hard for an LFSR like MT but, worse yet, it doesn't work for Haskell or other fine-grain concurrent languages because split and next will commute. Other tree RNGs, e.g. SPRNG, have the same commutativity issue. Block ciphers address this issue head-on by reducing the split independence problem to a crypto problem. A better choice might be some block cipher other than AES. Two possibilities are XTEA and RC4. Both are in Wikipedia. RC4 has 256 bytes of key state, still bigger than I would like. Another scheme is to make the number of rounds an option. With AESNI, this could scream. Burton On Wed, Aug 17, 2011 at 12:26 PM, Ertugrul Soeylemez e...@ertes.de wrote: Ryan Newton rrnew...@gmail.com wrote: Using a cryptographically strong random number generator here is probably a very bad idea. Two reasons: Firstly while being faster than the current implementation an AES-based implementation will still be considerably slower than the Mersenne Twister algorithm. This may or may not be true, if hardware AES support is there, but don't just assume that everybody has AES instructions now. For example I don't have them. Secondly there is no standard requiring that the default random number generator is cryptographically safe. Changing this particular implementation, which is the one most people use, to a CSPRNG will make people take for granted that System.Random is safe to use in security-related products, because it would be very convenient. This will render strong security products trivially weak, when compiled with the wrong Haskell distribution, and you will find packages with statements like: We assume that you use Ryan Newton's distribution of the random package. I would rather propose the Mersenne Twister as the default random number generator. You could add AES as a secondary generator for people requiring cryptographic strength, but then do it properly, i.e. impure, because most people, when reading about a PRNG with AES anywhere in its name, will just assume that it's a CSPRNG. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ 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] why is Random in System?
On Wed, Aug 17, 2011 at 11:10 AM, Ryan Newton rrnew...@gmail.com wrote: The problem with Mersenne twister is that it doesn't split well. The main reason for crypto prng in this package would not be to advertise to people that System.Random can be used for security-related apps *but to make splitting reasonably safe*. The more fundamental problem is that splitting is neither well understood nor generally safe, and as such it should not be in the basic Random class. A more sensible API would have a Random class that lacks a split operation, and a SplittableRandom class that permits it, as you mention later in your message. Most current PRNGs could then be instances of Random, but not SplittableRandom. And I think we need splitting, especially as more Haskell programs become parallel. I do not agree here, I'm afraid. By the way, my mwc-random package is at least as fast as mersenne-twister, has smaller state, and is pure Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overloading in a sub-class
On 11-08-17 12:10 PM, Patrick Browne wrote: -- Are + and negate part of the signature of Numb1? class Numb0 a = Numb1 a where No. -- Is it possible to override these operations in instances of Numb1? -- Something like: -- instance Numb1 Float where --x + y = y --negate x = x No. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] writing a good Setup.hs is *hard* (was: broken on install encoding 0.6.6)
Ccing cabal-dev. On Aug 17, 2011 9:12 AM, Rogan Creswick cresw...@gmail.com wrote: On Wed, Aug 17, 2011 at 6:29 AM, Gang yugang...@gmail.com wrote: sorry to bother Not in the least! I was trying to figure out what problem you were encountering, and I learned a lot. I never did recreate your problem, but in the process I ran into a whole host of other annoyances and strange situations relating to slightly broken cabal files and cabal build intricacies that confound our existing tools. I don't mean to pick on encoding or HaXml - I've seen the same kinds of issues in many, many Haskell packages (including most of the packages I've written myself) these are just the ones I ran into today. (and I am quite serious when I say that writing a good Setup.hs is very, very, difficult). My objective is just to motivate a minor change to cabal that would help to make this easier. On to the build problems: encoding-0.6.6 uses it's own source during the build process! It actually has to be partially compiled before the build tool can build encoding (!). I'm *amazed* that this actually works at all (impressed, too), and indeed, it doesn't work with cabal-dev, which is unfortunate: cabal-dev would have identified one of the dependency issues in HaXml 1.19 (pretty is an undocumented dependency, although I am unsure if that was true at the time 1.19 and encoding-0.6.6 were released. I haven't tracked the pretty dependency down to the exact source - it could be a transitive dep introduced by a recent version of something HaXml 1.19 needs. Per my subject line - this is amazingly difficult - keep in mind that we're not talking about building *packages*, this is just to build the *build tool*, and none of this is documented. How long before it is effectively impossible to recreate the circumstances that result in a successful encoding-0.6.6 build?). cabal-dev can't build encoding-0.6.6 because the encoding source that is referenced from encoding's Setup.hs depends on (at least) HaXml = 1.19 1.22.5; this is OK with cabal, since cabal-install installs a necessary HaXml into your user package db prior to building encoding's Setup.hs (modulo the missing upper version bound). Therefore HaXml just happens to be visible when cabal builds Setup.hs -- a build step that cabal-dev isn't capable of controlling (and probably never will be -- we could intercept system calls, but that's difficult when only supporting one OS, much less three). You can, of course, manually install HaXml to your local package db and then cabal-dev install encodings, but that's somewhat of a hack (and you'll find that the current HaXml won't work for the current encodings release, as Gang Yu did). Adding a section to the cabal file that specifies build dependencies for Setup.hs would make some very important parts of this process obvious - and it would *greatly* assist in debugging failing builds, not to mention allowing us to make use of the extensive libraries on hackage to write more expressive build systems. (We could actually use openshake in Setup.hs, once it's released, for example!) I've floated the idea past a number of Haskell programmers with positive responses, and there is a GSOC ticket that provides some more details (the project was not selected - no students proposed to work on it): http://hackage.haskell.org/trac/summer-of-code/ticket/1602 --Rogan Regards Gang On 08/17/2011 04:59 PM, Gang Yu wrote: hi, cafe: I go through to the encoding package installation problem again. cabal install encoding Resolving dependencies... /tmp/encoding-0.6.68093/encoding-0.6.6/dist/setup/setup: 4: Syntax error: ; unexpected when I have a check on the this issue, I get: file ~/.cabal/packages/ hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup /home/gang/.cabal/packages/ hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, not stripped My machine is: gang@gang-laptop:~$ uname -a Linux gang-laptop 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux is this related? How can I manually install the package from scratch? Any helps or directs will be appreciated Thanks Gang ___ 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
Re: [Haskell-cafe] why is Random in System?
The more fundamental problem is that splitting is neither well understood nor generally safe, and as such it should not be in the basic Random class. Would you mind elaborating? Splitting was not well-understood by the original authors of System.Random; that much is in the comments. Nor is it well understood by me. But I am under the impression that it is well understood by Burton Smith and others who have worked on the topic, and that they assure us that using AES, RNG's under any series of splits are as strong as those generated in a linear sequence. (And if you show otherwise, you have a crypto paper and quite a name for yourself.) And I think we need splitting, especially as more Haskell programs become parallel. I do not agree here, I'm afraid. Could you expound on this also? The people I know in the parallelism community seem to care a lot about deterministic PRNG in parallel programs. For example, the Cilk folks at MIT and Intel who I work with are *modifying their runtime system *just to get deterministic parallel PRNG. For example our in our Monad Par package splittable RNG will allow us to add a variant of the monad that provides randomness and transparently routes the state through the forks in the parallel computation, retaining the model's determinism. -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why is Random in System?
On Wed, Aug 17, 2011 at 12:27 PM, Ryan Newton rrnew...@gmail.com wrote: The more fundamental problem is that splitting is neither well understood nor generally safe, and as such it should not be in the basic Random class. Would you mind elaborating? Certainly. The purpose of splitting a PRNG is to create two new PRNGs, with the following properties: - Long periods - The streams generated by each PRNG must be independent - Splitting must be fast, while preserving the above two properties It's very easy to write a split function that gets at least one of these considerations wrong. But I am under the impression that it is well understood by Burton Smith and others who have worked on the topic, and that they assure us that using AES, RNG's under any series of splits are as strong as those generated in a linear sequence. The trouble is that very few people have worked on this topic - there's almost no published literature on it. And Burton and his colleagues readily admit that the technique they suggest is a matter of folk wisdom in the crypto community. A typical technical application of a PRNG is for Monte Carlo processes, where you want to (a) have a very fast PRNG and (b) understand its properties. Burton's off-the-cuff suggestion is all very well, but we don't know important things like what the performance or period of that PRNG would be. For instance, if we don't know a PRNG's period, we don't know when we're going to start seeing autocorrelations in its output, or if it supports splitting, how many splits are safe to perform before we start seeing *cross *-stream correlation. This in turn means that we don't know whether, when, or why the consumers of our pseudo-random numbers are going to themselves start producing garbage results, and that's troubling to me. Could you expound on this also? The people I know in the parallelism community seem to care a lot about deterministic PRNG in parallel programs. Yep, but don't conflate determinism with splitting. In the imperative world, you normally know how many CPUs you have, so you initialize one PRNG per CPU, and simply go from there; there's no need for splitting. In the parallel community, people are going out of their way to *avoid* splitting. The only good treatments of this subject that I know are published by the SPRNG authors at FSU. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] writing a good Setup.hs is *hard* (was: broken on install encoding 0.6.6)
On Wed, Aug 17, 2011 at 9:11 AM, Rogan Creswick cresw...@gmail.com wrote: On Wed, Aug 17, 2011 at 6:29 AM, Gang yugang...@gmail.com wrote: sorry to bother Not in the least! I was trying to figure out what problem you were encountering, and I learned a lot. I never did recreate your problem, but in the process I ran into a whole host of other annoyances and strange situations relating to slightly broken cabal files and cabal build intricacies that confound our existing tools. I think the only way to do this sort of thing today is to take the complexity in the Setup.hs and put it in its own executable. Then you can package up the executable with Cabal and specify proper dependencies, and then in the original package require the new executable as a build tool. (You might be able to perform a magic trick to get the build-tool treated as a proper dependency that Cabal will install for you, but that is only implied by http://hackage.haskell.org/trac/hackage/ticket/227 ). I swear this discussion has come up before, but I can't find anything in the mail-list archives for cabal-dev, or on Trac. The downside, of course, is that you have to be able to thread your install logic through a command-line tool, which may not work well in this case. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Existential question
{-# LANGUAGE ExistentialQuantification #-}
-- Dear Cafe, this one works.
data Kl' s i o = Kl' (i - s - (s, o))
iso' :: (i - Kl' s () o) - Kl' s i o
iso' f = Kl' $ \i s - (\(Kl' kl') - kl' () s) (f i)
-- Is there a way to make this one work also?
data Kl i o = forall s. Kl (i - s - (s, o))
iso :: (i - Kl () o) - Kl i o
iso f = Kl $ \i s - (\(Kl kl) - kl () s) (f i)
{-
Couldn't match type `s0' with `s'
because type variable `s' would escape its scope
This (rigid, skolem) type variable is bound by
a pattern with constructor
Kl :: forall i o s. (i - s - (s, o)) - Kl i o,
in a lambda abstraction
The following variables have types that mention s0
s :: s0 (bound at /home/tom/meta/haskell/iso.hs:11:17)
In the pattern: Kl kl
In the expression: \ (Kl kl) - kl () s
In the expression: (\ (Kl kl) - kl () s) (f i)
-}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 195
Welcome to issue 195 of the HWN, a newsletter covering developments in the Haskell community. This release covers the week of August 7 to 13, 2011. [1] http://goo.gl/8hDku You can find a HTML rendition of this newsletter at: http://contemplatecode.blogspot.com/2011/08/haskell-weekly-news-issue-195.html Announcements Luite Stegeman created a nifty tool called hdiff, which shows code changes between different versions of hackage packages. [2] http://goo.gl/uqh97 New and Updated Projects * Netwire (New - Ertugrul Soeylemez) Arrowised FRP library. [3] http://goo.gl/tVlsH * Snap Riak Extensions (New - Edward Tate). [4] http://goo.gl/O0C2A * time (Update - Ashley Yakeley) Adds instance RealFrac DiffTime. [5] http://goo.gl/Wm3UY * file-location (Update - Greg Weber) Error and debug information for haskell that gives file locations. [6] http://goo.gl/fTG4P * HTTP (Update - Ganesh Sittampalam) Bumps base dependency to work with GHC 4.2.1 [7] http://goo.gl/bydXi * hslogger, convertible, HDBC, HDBC-odbc, HDBC-postgresql, HDBC-sqlite3 (Update - John Goerzen) Update license to BSD3. [8] http://goo.gl/sD0Qg * taffybar (New - Tristian Ravitch) Slightly fancier status bar for xmonad. [9] http://goo.gl/SlNgi Quotes of the Week * Brend: Whoever chose the title A Gentle Introduction to Haskell is obviously accustomed to wrestling bears in piranha pits or something. * kmc: compare trifecta parsec -- GT * elliott: ... demonstrating C++ templates' wide range of expressivity in applications from stupid compile-time hacks to _really_ stupid compile-time hacks * solrize: The last good thing written in C was Schubert's Ninth Symphony. * cmccann: [I] learned Haskell mostly by typing a lot of really dumb things into an editor window, then feeding them to GHC Top Reddit Stories * Simon Marlow: “[…] I think I finally understand how to track call stacks properly in a lazy functional language. If this pans out, we'll get backtraces in GHCi and more accurate profiling” Domain: plus.google.com, Score: 121, Comments: 15 On Reddit: [10] http://goo.gl/0DTba Original: [11] http://goo.gl/yIhnI * A Very General Method of Computing Shortest Paths (the Gauss-Jordan-Floyd-Warshall- McNaughton-Yamada algorithm) Domain: r6.ca, Score: 41, Comments: 8 On Reddit: [12] http://goo.gl/dgW4s Original: [13] http://goo.gl/e8ZBF * I'm reading http://www.cs.ru.nl/~wouters/Publications/ThePowerOfPi.pdf What is this syntax called and where can I learn it? Domain: imgur.com, Score: 36, Comments: 15 On Reddit: [14] http://goo.gl/FpFIu Original: [15] http://goo.gl/CE9Dz * Simon Marlow: If you're using GHC 7.2.1 and find a performance loss relative to an earlier GHC, trying playing around with the new stack option Domain: plus.google.com, Score: 25, Comments: 8 On Reddit: [16] http://goo.gl/2FTsH Original: [17] http://goo.gl/CJZsR * In your haskell-dreams, how does a shell look? Domain: self.haskell, Score: 23, Comments: 43 On Reddit: [18] http://goo.gl/jGyqH Original: [19] http://goo.gl/jGyqH * SO: Converting floating point between Word and Float/Double (my poor, unanswered question!) Domain: stackoverflow.com, Score: 21, Comments: 3 On Reddit: [20] http://goo.gl/csKRb Original: [21] http://goo.gl/JFDn2 * Current status of gtk2hs? Domain: self.haskell, Score: 18, Comments: 10 On Reddit: [22] http://goo.gl/HFwCR Original: [23] http://goo.gl/HFwCR * (Live from CamHac) ANN: fclabels-1.0: First class accessor labels. Domain: hackage.haskell.org, Score: 13, Comments: 19 On Reddit: [24] http://goo.gl/FXdY6 Original: [25] http://goo.gl/Ijl4H * PhD Position availalble at Strathclyde Domain: lists.seas.upenn.edu, Score: 12, Comments: 2 On Reddit: [26] http://goo.gl/FbdNs Original: [27] http://goo.gl/0R8Vi * [GSoC] Text/UTF-8: Studying memory usage of a simple web server Domain: jaspervdj.be, Score: 9, Comments: 1 On Reddit: [28] http://goo.gl/HkcJL Original: [29] http://goo.gl/EQn9h * Arrow = Category + Applicative? (Part IIa) Domain: cdsmith.wordpress.com, Score: 9, Comments: 21 On Reddit: [30] http://goo.gl/hB6YY Original: [31] http://goo.gl/dBSuA Top StackOverflow Questions * Lazy Evaluation vs Macros votes: 19, answers: 5 Read on SO: [32] http://goo.gl/28jcJ * Comparison of Priority Queue implementations in Haskell votes: 16, answers: 1 Read on SO: [33] http://goo.gl/MyMp4 * Converting IEEE 754 floating point in Haskell Word32/64 to and from Haskell Float/Double votes: 16, answers: 4 Read on SO: [34] http://goo.gl/2YaVC * Applicatives compose, monads don't votes: 15, answers: 5 Read on SO: [35] http://goo.gl/Ncdij
[Haskell-cafe] FFI question - FunPtrs to top-level functions
Hi Haskell, I have a question about the Haskell FFI and creating FunPtrs to Haskell functions. Does anyone have any recommendations for when I have a top-level function that I would like to pass to a C function as a function pointer (that is called via a foreign import)? I know that the FFI provides the wrapper foreign import I can use to wrap Haskell functions, but then I would need to jump through hoops to manage the liefetime of of the FunPtr wrapper. If I were closing over interesting state I would want this - but the function (side-effectfully) operates only on its arguments (and the Haskell RTS, of course). Is it okay to place an unsafePerformIO $ mkWrapper myFunc as a top-level declaration, or am I journeying into uncharted lands? Is there something clever I can do with foreign exports and foreign imports, or is this just making things too complex? Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existential question
-- Is there a way to make this one work also? data Kl i o = forall s. Kl (i - s - (s, o)) iso :: (i - Kl () o) - Kl i o iso f = Kl $ \i s - (\(Kl kl) - kl () s) (f i) Yes, if you move the quantifier: type Kl i o = i - Kl1 o data Kl1 o = forall s. Kl1 (s - (s,o)) iso :: (i - Kl () o) - Kl i o iso f = \i - f i () iso1 :: Kl i o - (i - Kl () o) iso1 f = \i - (\() - f i) I'm not sure if it helps in the long run: the original Kl and mine Kl1 are useless. Suppose we have the value kl1 :: Kl Int Bool with the original declaration of Kl: data Kl i o = forall s. Kl (i - s - (s, o)) Now, what we can do with kl1? We can feed it an integer, say 1, and obtain function f of the type s - (s,Bool) for an _unknown_ type s. Informally, that type is different from any concrete type. We can never find the Bool result produced by that function since we can never have any concrete value s. The only applications of f that will type check are \s - f s f undefined both of which are useless to obtain f's result. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
