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

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)

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."

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?

Hi,
On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald
<carter.schonwald <at> 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

On Wed, Sep 26, 2012 at 10:58 AM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
> On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald
> <carter.schonwald <at> 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

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 <hesselink <at> gmail.com> wrote:
> On Wed, Sep 26, 2012 at 10:58 AM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
>> On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald
>> <carter.schonwald <at> 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.

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…

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.schonwald <at> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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.

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.

>
> On 2012-09-26, at 1:44 AM, Carter Schonwald <carter.schonwald <at> 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

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.

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.baaij <at> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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.baaij <at> 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.
>

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.schonwald <at> 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?)
>
> <at> 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 <maydwell <at> 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.baaij <at> 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 <at> haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

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?)
>
> <at> 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?

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?)
>>
>> <at> 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?
>

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.

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.lentczner <at> 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 <at> 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