Hi,
I saw the same issue/crash on my machine using ghc 7.6.3.
I just build a perf build of GHC-head with
85a9e2468dc74b9e5ccde0dd61be86219fd323a2 as the latest commit.
Now running, I get:
1) cabal install bindings-glfw
2) ghci
3) ghci :m Bindings.GLFW
4) ghci Bindings.GLFW.c'glfwInit
5) ghci
Here's a binary dist of my build:
https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2
In case someone wants to confirm my findings.
Cheers,
Christiaan
On Sep 16, 2013, at 2:24 PM, Christiaan Baaij christiaan.ba...@gmail.com
wrote:
Hi,
I saw the same
What works best for me is to actually merge the type-nats branch into a local
checkout of master; as opposed to checking out the type-nats branch.
Though you will usually have to do some (minor) conflict resolution.
-- Christiaan
On May 17, 2013, at 11:13 PM, Takayuki Muranushi
Dear List,
The context of my problem is the following:
- ghc-HEAD uses shared-library _only_ on OS X
- A cabalized package that builds a shared/dynamic C-library (GLFW-b)
And my problem is:
A dynamically linked Haskell library gets the wrong install-name for a
C-library:
otool -L
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
: 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
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
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:
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
error message
was never implemented for GHC API users, only for building GHCi in
profiling mode.
-- Christiaan Baaij
[1] http://hackage.haskell.org/trac/ghc/ticket/3285
[2] http://hackage.haskell.org/trac/ghc/ticket/2197
___
Haskell-Cafe mailing list
Hi,
The 'Comp' type is an automata arrow. In version 0.1.2.5 it was called
'Stat' [1], and was actually a newtype.
The definition of Comp is:
data Comp i o = C {
domain :: Set.Set Clock
, exec :: Clock - i - (o, Comp i o)
}
If you don't care about clock domains you can use the
I now also fixed the examples on the website [1] to work with version 0.1.3.0
of CLaSH :-)
-- Christiaan
[1] http://clash.ewi.utwente.nl
On Mar 22, 2011, at 6:43 PM, Christiaan Baaij wrote:
Hello,
I am pleased to announce an incremental update to CLaSH, version 0.1.3.0.
CLaSH can
by the current version of CLaSH ;-)
-- Christiaan Baaij
[1] There is hard-coded support for a set of recursively defined higher-order
functions such as map, fold, zipWith, etc.
[2] http://clash.ewi.utwente.nl
[3] http://hackage.haskell.org/package/clash-0.1.3.0
[4] http://github.com/christiaanb/DE1
dictates that at the end of the day we will enjoy a dinner together
with those who wish join (at your own costs).
You can register for the event by sending an email to me, Christiaan Baaij
(c.p.r.ba...@utwente.nl). More information can be found at the website:
http://caes.ewi.utwente.nl/External/NLFP
14 matches
Mail list logo
