Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Hi Mark, Thank you for the clarification. I think, then, that we should indeed provide a link to a notice about native libraries - like, if you're using native libraries, make sure their architecture is 32-bit or universal as well; in case of MacPorts you can achieve this by doing port install libfoo +universal; in case of brew by brew install libfoo --universal. On Mon, Oct 8, 2012 at 9:52 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: I'm the source of the 32-bit recommendation, and the HP Mac distribution builder To summarize what I read in this thread: 32-bit GHC/HP didn't work with 64-bit Cario libs Some libs available via brew were 64-bit, and 32-bit ones would have to be compiled There is still some bug with 64-bit ghci and some graphics libs There is a ghc bug with 64-bit on mac (bug #7040), which isn't fixed until 7.6 There seemed to be the implication that a 64-bit ghc would work with 32-bit libs, but I don't think that's true. Mac doesn't (generally) support mixed modes in the same executable. All system libs are shipped dual-architecture. I don't think there are any pre-installed libs that are shipped 64-bit only. The problem seen with Cairo would cut both ways: If one had installed the 32-bit version of Cairo, one would see the same problem with the 64-bit HP: wrong architecture. Since code compiled with the 32-bit system is both faster, and uses less memory, and it has been the case that all libs are either shipped dual-arch, or easily available as 32-bit, and there were known problems with the 64-bit version for some use cases, it seemed to me to be best to suggest the 32-bit version by default. The major source of the problems in the OP, seem to be that MacPorts and/or brew don't appear to follow the Mac OS X lib standard of installing libs dual arch. A brief look at the MacPorts page indicated that there were various rules (OS version and processor version) that determined which arch. it built by default. Perhaps we should tell people to install the HP architecture that matches the architecture that they use for MacPorts or brew. However, I bet most people don't know, so we'd need a pointer to where they could find out the defaults for those systems, or how to establish what their system is using. Finally, I note that HP 2012.4.0.0 (out in a month) will ship with GHC 7.4.2, and so will still have the above bugs. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov We're hiring! http://tinyurl.com/mirantis-openstack-engineer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
I've filed a bug report: http://hackage.haskell.org/trac/ghc/ticket/7314 My only problem is that I don't have OS X 10.8 installed on my machine. I'm running OS X 10.6, and am not inclined to upgrade. So providing feedback on the questions related to the bug report will be hard and/or take some time. -- Christiaan On Oct 8, 2012, at 4:25 PM, Johan Tibell wrote: Could you please file a bug report at: http://hackage.haskell.org/trac/ghc/ Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Cheers, Christiaan On Sep 28, 2012, at 1:16 PM, Christiaan Baaij wrote: The GLUT-backend calls system.exit when the window is closed, because 'exitMainLoop' is only defined within freeglut, which is not by default installed on non-linux platforms. There is hence no real point in running gloss applications with the GLUT-backend from GHCi. I'll try to find a mountain lion install, and test if there's a difference between GLUT and GLFW On Sep 28, 2012, at 7:56 AM, Carter Schonwald wrote: do these problems also happen if your'e using the glut backend? (because if its only glfw that has problems, then its something wrong in the ffi code, but if its both, that suggests there may be some sort of systematic problem?) @Lyndon, that sounds like a bug... especially since scotty seems to have no C code in package... have you filed a bug report with the maintainers thats reproducible? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
On Monday, 8 October 2012 at 06:28, Christiaan Baaij wrote: ghci: segfault ghci from gdb: everything works This makes me suspect something that gets disabled when debugging, such as address space randomization and the like. I did not think ML handled that any differently from Lion, though. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net Sent with Sparrow (http://www.sparrowmailapp.com/?sig) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Could you please file a bug report at: http://hackage.haskell.org/trac/ghc/ Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Johan, should I also file the bugreport remove the suggestion to install 32-bit platform there, or is there a different place for bugs of the platform website? On Mon, Oct 8, 2012 at 7:25 AM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Could you please file a bug report at: http://hackage.haskell.org/trac/ghc/ Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov We're hiring! http://tinyurl.com/mirantis-openstack-engineer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Eugene: I think thats a bug / ticket for the haskell platform trac, rather than ghc's trac. look forward to seeing how to reproduce those problems / helping fix em! On Mon, Oct 8, 2012 at 3:08 PM, Eugene Kirpichov ekirpic...@gmail.comwrote: Johan, should I also file the bugreport remove the suggestion to install 32-bit platform there, or is there a different place for bugs of the platform website? On Mon, Oct 8, 2012 at 7:25 AM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Hi, I finally found another OS X mountain lion install and can confirm the behaviour I described earlier: 32-bit: compiled code works, interpreted code works 64-bit: compiled code works, interpreted code fails Here's the test case: - cabal install gloss --flags-GLUT GLFW - cabal unpack gloss-examples - cd gloss-examples-1.7.6.2/picture/GameEvent - ghci -fno-ghci-sandbox Main.hs - main I get the following crash report: http://pastebin.com/jZjfFtm7 The weird thing is the following: When I run 'ghci' from inside 'gdb' (to find the origin for the segfault), everything works fine: ghci: segfault ghci from gdb: everything works I have no idea what's going on, so if anyone has any pointers on how to make sure ghci behaves the same in gdb please let me know. Could you please file a bug report at: http://hackage.haskell.org/trac/ghc/ Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov We're hiring! http://tinyurl.com/mirantis-openstack-engineer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
I'm the source of the 32-bit recommendation, and the HP Mac distribution builder To summarize what I read in this thread: 1. 32-bit GHC/HP didn't work with 64-bit Cario libs 2. Some libs available via brew were 64-bit, and 32-bit ones would have to be compiled 3. There is still some bug with 64-bit ghci and some graphics libs 4. There is a ghc bug with 64-bit on mac (bug #7040), which isn't fixed until 7.6 There seemed to be the implication that a 64-bit ghc would work with 32-bit libs, but I don't think that's true. Mac doesn't (generally) support mixed modes in the same executable. All system libs are shipped dual-architecture. I don't think there are any pre-installed libs that are shipped 64-bit only. The problem seen with Cairo would cut both ways: If one had installed the 32-bit version of Cairo, one would see the same problem with the 64-bit HP: wrong architecture. Since code compiled with the 32-bit system is both faster, and uses less memory, and it has been the case that all libs are either shipped dual-arch, or easily available as 32-bit, and there were known problems with the 64-bit version for some use cases, it seemed to me to be best to suggest the 32-bit version by default. The major source of the problems in the OP, seem to be that MacPorts and/or brew don't appear to follow the Mac OS X lib standard of installing libs dual arch. A brief look at the MacPorts page indicated that there were various rules (OS version and processor version) that determined which arch. it built by default. Perhaps we should tell people to install the HP architecture that matches the architecture that they use for MacPorts or brew. However, I bet most people don't know, so we'd need a pointer to where they could find out the defaults for those systems, or how to establish what their system is using. Finally, I note that HP 2012.4.0.0 (out in a month) will ship with GHC 7.4.2, and so will still have the above bugs. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Carter: Not yet. I'll get round to it once I'm done with with an Agda presentation I'm working on. Until then I can't afford to break my environment. On Fri, Sep 28, 2012 at 1:56 PM, Carter Schonwald carter.schonw...@gmail.com wrote: do these problems also happen if your'e using the glut backend? (because if its only glfw that has problems, then its something wrong in the ffi code, but if its both, that suggests there may be some sort of systematic problem?) @Lyndon, that sounds like a bug... especially since scotty seems to have no C code in package... have you filed a bug report with the maintainers thats reproducible? On Thu, Sep 27, 2012 at 3:49 AM, Lyndon Maydwell maydw...@gmail.com wrote: I'm experiencing the same issues with compiled 64 bit working correctly, but interpreted causing all sorts of issues with Scotty. On Thu, Sep 27, 2012 at 3:45 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: The behaviour seems to differ between versions of OS X. A student has OS X 10.8 installed and is observing the described behaviour: 32-bit: interpreted and compiled work correctly 64-bit: only compiled code works correctly However, I have OS X 10.6, and I'm observing the following behaviour: 32-bit: interpreted and compiled code work correctly 64-bit: interpreted and compiled code work correctly To test: cabal install gloss --flags=-GLUT GLFW cabal unpack gloss-examples cd unpacked-folder/picture/GameEvent ghci -fno-ghci-sandbox Main.hs main I'll try to find another OS X 10.8 install (I don't want to upgrade) and see if the behaviour still emerges. On Sep 26, 2012, at 11:03 PM, Carter Schonwald wrote: really? does the 64 bit code work correctly when compiled? if the compiled version works correctly, could you post a repo of some example codlets that *should work* on ghc 7.6 so i can sort out if its fixable. There were some similar problems with gtk / cairo for a while on OS X, and i was able to sort out reproducible instructions for getting things to work in that case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
The GLUT-backend calls system.exit when the window is closed, because 'exitMainLoop' is only defined within freeglut, which is not by default installed on non-linux platforms. There is hence no real point in running gloss applications with the GLUT-backend from GHCi. I'll try to find a mountain lion install, and test if there's a difference between GLUT and GLFW On Sep 28, 2012, at 7:56 AM, Carter Schonwald wrote: do these problems also happen if your'e using the glut backend? (because if its only glfw that has problems, then its something wrong in the ffi code, but if its both, that suggests there may be some sort of systematic problem?) @Lyndon, that sounds like a bug... especially since scotty seems to have no C code in package... have you filed a bug report with the maintainers thats reproducible? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
The behaviour seems to differ between versions of OS X. A student has OS X 10.8 installed and is observing the described behaviour: 32-bit: interpreted and compiled work correctly 64-bit: only compiled code works correctly However, I have OS X 10.6, and I'm observing the following behaviour: 32-bit: interpreted and compiled code work correctly 64-bit: interpreted and compiled code work correctly To test: cabal install gloss --flags=-GLUT GLFW cabal unpack gloss-examples cd unpacked-folder/picture/GameEvent ghci -fno-ghci-sandbox Main.hs main I'll try to find another OS X 10.8 install (I don't want to upgrade) and see if the behaviour still emerges. On Sep 26, 2012, at 11:03 PM, Carter Schonwald wrote: really? does the 64 bit code work correctly when compiled? if the compiled version works correctly, could you post a repo of some example codlets that *should work* on ghc 7.6 so i can sort out if its fixable. There were some similar problems with gtk / cairo for a while on OS X, and i was able to sort out reproducible instructions for getting things to work in that case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
I'm experiencing the same issues with compiled 64 bit working correctly, but interpreted causing all sorts of issues with Scotty. On Thu, Sep 27, 2012 at 3:45 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: The behaviour seems to differ between versions of OS X. A student has OS X 10.8 installed and is observing the described behaviour: 32-bit: interpreted and compiled work correctly 64-bit: only compiled code works correctly However, I have OS X 10.6, and I'm observing the following behaviour: 32-bit: interpreted and compiled code work correctly 64-bit: interpreted and compiled code work correctly To test: cabal install gloss --flags=-GLUT GLFW cabal unpack gloss-examples cd unpacked-folder/picture/GameEvent ghci -fno-ghci-sandbox Main.hs main I'll try to find another OS X 10.8 install (I don't want to upgrade) and see if the behaviour still emerges. On Sep 26, 2012, at 11:03 PM, Carter Schonwald wrote: really? does the 64 bit code work correctly when compiled? if the compiled version works correctly, could you post a repo of some example codlets that *should work* on ghc 7.6 so i can sort out if its fixable. There were some similar problems with gtk / cairo for a while on OS X, and i was able to sort out reproducible instructions for getting things to work in that case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
do these problems also happen if your'e using the glut backend? (because if its only glfw that has problems, then its something wrong in the ffi code, but if its both, that suggests there may be some sort of systematic problem?) @Lyndon, that sounds like a bug... especially since scotty seems to have no C code in package... have you filed a bug report with the maintainers thats reproducible? On Thu, Sep 27, 2012 at 3:49 AM, Lyndon Maydwell maydw...@gmail.com wrote: I'm experiencing the same issues with compiled 64 bit working correctly, but interpreted causing all sorts of issues with Scotty. On Thu, Sep 27, 2012 at 3:45 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: The behaviour seems to differ between versions of OS X. A student has OS X 10.8 installed and is observing the described behaviour: 32-bit: interpreted and compiled work correctly 64-bit: only compiled code works correctly However, I have OS X 10.6, and I'm observing the following behaviour: 32-bit: interpreted and compiled code work correctly 64-bit: interpreted and compiled code work correctly To test: cabal install gloss --flags=-GLUT GLFW cabal unpack gloss-examples cd unpacked-folder/picture/GameEvent ghci -fno-ghci-sandbox Main.hs main I'll try to find another OS X 10.8 install (I don't want to upgrade) and see if the behaviour still emerges. On Sep 26, 2012, at 11:03 PM, Carter Schonwald wrote: really? does the 64 bit code work correctly when compiled? if the compiled version works correctly, could you post a repo of some example codlets that *should work* on ghc 7.6 so i can sort out if its fixable. There were some similar problems with gtk / cairo for a while on OS X, and i was able to sort out reproducible instructions for getting things to work in that case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Hi, On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote: To the best of my knowledge there is absolutely no reason to use the 32bit haskell on OS X (aside from memory usage optimization cases which likely do not matter to the *typical* user), and the community should probably update the recommendation to reflect this. The source of the recommendation are the benchmark results presented here: http://mtnviewmark.wordpress.com/2011/12/07/32-bits-less-is-more/ Note that it's very common to run other GC:ed languages, such as Java and Python, in 32-bit mode whenever possible. 32-bit almost halves the memory footprint and thus shortens GC pauses, in particular major ones, which are O(n) in the size of the heap. The problem of missing 32-bit C libraries might be a good reason for us to recommend 64-bit though and leave the 32-bit recommendation to people who know what they are doing. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
On Wed, Sep 26, 2012 at 10:58 AM, Johan Tibell johan.tib...@gmail.com wrote: On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote: To the best of my knowledge there is absolutely no reason to use the 32bit haskell on OS X (aside from memory usage optimization cases which likely do not matter to the *typical* user), and the community should probably update the recommendation to reflect this. The source of the recommendation are the benchmark results presented here: http://mtnviewmark.wordpress.com/2011/12/07/32-bits-less-is-more/ The problem of missing 32-bit C libraries might be a good reason for us to recommend 64-bit though and leave the 32-bit recommendation to people who know what they are doing. We switched to a 64bit GHC recently for this exact reason. The 64bit libraries are either already installed, or can easily be installed through e.g. brew. For 32bit libraries, we sometimes had to compile from source, passing all kinds of flags. The downside for us is doubling the memory usage, but that's more easily solved (with more memory). I haven't noticed the performance reduction. So in short, I think the 64bit version should be the default recommendation on OS X. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
On 2012-09-26, at 1:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote: what can we (the community ) do to address the fact that the haskell platform installer suggestions for os x are sadly completely backwards? (or am I completely wrong in my personal stance on this matter) I'd much prefer the 64 bit myself, unfortunately http://hackage.haskell.org/trac/ghc/ticket/7040 affects the current version of the Haskell Platform. It's fixed in 7.6.x. This bug prevents me from using Yesod with the 64 bit version of 7.4.2, and it's not just Yesod affected… Cheers, Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Adding Mark who's the release manager for the platform (and also the maintainer of the OS X builds). On Wed, Sep 26, 2012 at 11:57 AM, Erik Hesselink hessel...@gmail.com wrote: On Wed, Sep 26, 2012 at 10:58 AM, Johan Tibell johan.tib...@gmail.com wrote: On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote: To the best of my knowledge there is absolutely no reason to use the 32bit haskell on OS X (aside from memory usage optimization cases which likely do not matter to the *typical* user), and the community should probably update the recommendation to reflect this. The source of the recommendation are the benchmark results presented here: http://mtnviewmark.wordpress.com/2011/12/07/32-bits-less-is-more/ The problem of missing 32-bit C libraries might be a good reason for us to recommend 64-bit though and leave the 32-bit recommendation to people who know what they are doing. We switched to a 64bit GHC recently for this exact reason. The 64bit libraries are either already installed, or can easily be installed through e.g. brew. For 32bit libraries, we sometimes had to compile from source, passing all kinds of flags. The downside for us is doubling the memory usage, but that's more easily solved (with more memory). I haven't noticed the performance reduction. So in short, I think the 64bit version should be the default recommendation on OS X. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Running gloss [1] programs from GHCi only works with the 32bit version of the latest Haskell Platform. The 64-bit version just shows a black window and GHCi becomes unresponsive. I use gloss to display trees and graphs in the functional programming course given at our university. The ability to work within the interpreter, and able to depict the graphs/trees, really enhances the student's understanding of their programs. I am hence glad that there is still the 32-bit recommendation for OS X. Cheers, Christiaan [1] http://hackage.haskell.org/package/gloss - install with: cabal install gloss --flags=-GLUT GLFW On Sep 26, 2012, at 1:16 PM, Bob Hutchison wrote: On 2012-09-26, at 1:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote: what can we (the community ) do to address the fact that the haskell platform installer suggestions for os x are sadly completely backwards? (or am I completely wrong in my personal stance on this matter) I'd much prefer the 64 bit myself, unfortunately http://hackage.haskell.org/trac/ghc/ticket/7040 affects the current version of the Haskell Platform. It's fixed in 7.6.x. This bug prevents me from using Yesod with the 64 bit version of 7.4.2, and it's not just Yesod affected… Cheers, Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
really? does the 64 bit code work correctly when compiled? if the compiled version works correctly, could you post a repo of some example codlets that *should work* on ghc 7.6 so i can sort out if its fixable. There were some similar problems with gtk / cairo for a while on OS X, and i was able to sort out reproducible instructions for getting things to work in that case. On Wed, Sep 26, 2012 at 10:43 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Running gloss [1] programs from GHCi only works with the 32bit version of the latest Haskell Platform. The 64-bit version just shows a black window and GHCi becomes unresponsive. I use gloss to display trees and graphs in the functional programming course given at our university. The ability to work within the interpreter, and able to depict the graphs/trees, really enhances the student's understanding of their programs. I am hence glad that there is still the 32-bit recommendation for OS X. Cheers, Christiaan [1] http://hackage.haskell.org/package/gloss - install with: cabal install gloss --flags=-GLUT GLFW On Sep 26, 2012, at 1:16 PM, Bob Hutchison wrote: On 2012-09-26, at 1:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote: what can we (the community ) do to address the fact that the haskell platform installer suggestions for os x are sadly completely backwards? (or am I completely wrong in my personal stance on this matter) I'd much prefer the 64 bit myself, unfortunately http://hackage.haskell.org/trac/ghc/ticket/7040 affects the current version of the Haskell Platform. It's fixed in 7.6.x. This bug prevents me from using Yesod with the 64 bit version of 7.4.2, and it's not just Yesod affected… Cheers, Bob ___ 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] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Hi, I installed Haskell Platform 32-bit on a fresh 64-bit mac, because the page http://www.haskell.org/platform/mac.html says: Pick the 32-bit vesion, unless you have a specific reason to use the 64-bit version. The 32-bit one is slightly faster for most programs. Then, during the installation of a package, the following happeed: Loading package cairo-0.12.3.1 ... command line: can't load .so/.DLL for: /opt/local/lib/libz.dylib (dlopen(/opt/local/lib/libz.dylib, 9): no suitable image found. Did find: /opt/local/lib/libz.dylib: mach-o, but wrong architecture) That libz.dylib is a 64-bit library and it can't be used by 32-bit Haskell platform. QUESTION: It seems to me that most people, at least most who care about slightly faster programs, are likely to run into something like this - using native 64-bit libraries. Compatibility exists only in the opposite direction. Wouldn't it be appropriate to remove this notice and ask people to use the 64-bit version unless they have a specific reason not to? -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov We're hiring! http://tinyurl.com/mirantis-openstack-engineer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Hi Eugene, To the best of my knowledge there is absolutely no reason to use the 32bit haskell on OS X (aside from memory usage optimization cases which likely do not matter to the *typical* user), and the community should probably update the recommendation to reflect this. I can certainly attest to having to baby sit new haskellers when installing and repeatedly say yes, do the 64 bit version, please, no, ignore the recommendation for 32bit, no one knows why its there, but its wrong what can we (the community ) do to address the fact that the haskell platform installer suggestions for os x are sadly completely backwards? (or am I completely wrong in my personal stance on this matter) cheers -Carter On Tue, Sep 25, 2012 at 7:52 PM, Eugene Kirpichov ekirpic...@gmail.comwrote: Hi, I installed Haskell Platform 32-bit on a fresh 64-bit mac, because the page http://www.haskell.org/platform/mac.html says: Pick the 32-bit vesion, unless you have a specific reason to use the 64-bit version. The 32-bit one is slightly faster for most programs. Then, during the installation of a package, the following happeed: Loading package cairo-0.12.3.1 ... command line: can't load .so/.DLL for: /opt/local/lib/libz.dylib (dlopen(/opt/local/lib/libz.dylib, 9): no suitable image found. Did find: /opt/local/lib/libz.dylib: mach-o, but wrong architecture) That libz.dylib is a 64-bit library and it can't be used by 32-bit Haskell platform. QUESTION: It seems to me that most people, at least most who care about slightly faster programs, are likely to run into something like this - using native 64-bit libraries. Compatibility exists only in the opposite direction. Wouldn't it be appropriate to remove this notice and ask people to use the 64-bit version unless they have a specific reason not to? -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov We're hiring! http://tinyurl.com/mirantis-openstack-engineer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
