Re: [Haskell-cafe] OS X ghci problem
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 1 And doing: 1.) cabal install GLFW-b 2.) ghci -package GLFW-b 3.) ghci import Graphics.UI.GLFW as GLFW 4.) ghci GLFW.init 5.) ghci True My platform: - OSX 10.8.4 - ghc(i) 7.7.20130915 - cabal 1.18.0.1 (using 1.18.0 of the Cabal library) - xcode cltools 4.6.2 So it seems that the new ghci linking infrastructure fixes things Cheers, Christiaan On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos maxda...@gmail.com wrote: What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish linker. The only wrinkle is figuring out where you want the dylib. I think homebrew will put one in /usr/local/lib, which works out nicely, but they don't have GLFW 3 yet. Another option is to build the dylib yourself from the GLFW source bundled with the GLFW-b package, then tell cabal where to find it. Hi, for me the problem relocates now to the bindings-glfw package, since the native bindings moved to this package and are wrapped up with glfw-b. My way to the same exception already mentioned by Brian Lewis: 1) cabal install bindings-glfw 2) ghci 3) ghci :m Bindings.GLFW 4) ghci Bindings.GLFW.c'glfwInit 5) ghci terminates with exception: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool init]: unrecognized selector sent to instance 0x7fc443c01b30' Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no clue how to do this. I built the according glfw version on my own as a dylib and loaded ghci with it explicitly, this didn't help. I guess the compiled bindings-glfw is already statically packed up. How can I get ghci to use the native glfw dylib in combination with bindings-glfw? If I have to compile bindings-glfw with different settings, which settings? I have some oversight over haskell but no really deep knowledge according to bindings and lib-loading of ghci, but I'm willing to learn it ;) My Platform: - OSX 10.8.5 - ghc(i) 7.6.3 - cabal 1.18.0.1 - xcode dev tools 4.6.3 Thanks and Greetings Jan ___ 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] OS X ghci problem
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 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 1 And doing: 1.) cabal install GLFW-b 2.) ghci -package GLFW-b 3.) ghci import Graphics.UI.GLFW as GLFW 4.) ghci GLFW.init 5.) ghci True My platform: - OSX 10.8.4 - ghc(i) 7.7.20130915 - cabal 1.18.0.1 (using 1.18.0 of the Cabal library) - xcode cltools 4.6.2 So it seems that the new ghci linking infrastructure fixes things Cheers, Christiaan On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos maxda...@gmail.com wrote: What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish linker. The only wrinkle is figuring out where you want the dylib. I think homebrew will put one in /usr/local/lib, which works out nicely, but they don't have GLFW 3 yet. Another option is to build the dylib yourself from the GLFW source bundled with the GLFW-b package, then tell cabal where to find it. Hi, for me the problem relocates now to the bindings-glfw package, since the native bindings moved to this package and are wrapped up with glfw-b. My way to the same exception already mentioned by Brian Lewis: 1) cabal install bindings-glfw 2) ghci 3) ghci :m Bindings.GLFW 4) ghci Bindings.GLFW.c'glfwInit 5) ghci terminates with exception: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool init]: unrecognized selector sent to instance 0x7fc443c01b30' Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no clue how to do this. I built the according glfw version on my own as a dylib and loaded ghci with it explicitly, this didn't help. I guess the compiled bindings-glfw is already statically packed up. How can I get ghci to use the native glfw dylib in combination with bindings-glfw? If I have to compile bindings-glfw with different settings, which settings? I have some oversight over haskell but no really deep knowledge according to bindings and lib-loading of ghci, but I'm willing to learn it ;) My Platform: - OSX 10.8.5 - ghc(i) 7.6.3 - cabal 1.18.0.1 - xcode dev tools 4.6.3 Thanks and Greetings Jan ___ 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] type-level integers for GHC
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 muranu...@gmail.com wrote: Hey thanks Simon and Levor, I've reported the problem month ago, and I see today the commit-id for type-nats is still not changed. So I thought the problem remains. Let me first try the compile process again tonight, and report the compile process in more detail. 2013/5/17 Simon Peyton-Jones simo...@microsoft.com: I wonder why you can't compile type-nats? It should just work. You could email ghc-devs and Iavor (type-nats author, cc'd) explaining exactly what goes wrong. You may need the type-nats branch of some libraries, I'm not sure Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office 21 Station Road, Cambridge, CB1 2FB | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Takayuki Muranushi | Sent: 17 May 2013 07:18 | To: haskell | Subject: [Haskell-cafe] type-level integers for GHC | | What is your recommendation for type-level integers? | | I'd like to use it to improve the unittyped, | https://bitbucket.org/xnyhps/haskell-unittyped/ the library for physical | dimension. Therefore, I need negative numbers, additions, but | multiplications are not necessary. | | I've been looking forward for the type-nats extension of GHC, but I | haven't been able to compile the type-nats branch. Just learned that it | still takes a few month to merge the branch into the main. | http://hackage.haskell.org/trac/ghc/wiki/Status/May13 | | Thijs, the original author of unittyped, has commited a branch that uses | type-nats, but I can't try that out for the same reason. | | | Best, | -- | Takayuki MURANUSHI | The Hakubi Center for Advanced Research, Kyoto University | http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html ___ 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] Wrong install-name path for shared/dynamic C-library on OS X
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 ~/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.2012/libHSGLFW-b-0.1.0.5-ghc7.7.2012.dylib: /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.2012/libHSGLFW-b-0.1.0.5-ghc7.7.2012.dylib: build/libglfw.dylib (compatibility version 1.0.0, current version 1.0.0) All the other paths reported by 'otool -L' are absolute, while the C-library (libglfw.dylib) that was part of the Cabalized package is relative. The problem presents itself when I now want to use the GLFW-b package: Loading package GLFW-b-0.1.0.5 ... can't load .so/.DLL for: /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.2012/libHSGLFW-b-0.1.0.5-ghc7.7.2012.dylib (dlopen(/Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.2012/libHSGLFW-b-0.1.0.5-ghc7.7.2012.dylib, 9): Library not loaded: build/libglfw.dylib Referenced from: /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.2012/libHSGLFW-b-0.1.0.5-ghc7.7.2012.dylib Reason: image not found) I can update the install-name to the correct path using: install_name_tool -change build/libglfw.dylib @loader_path/libglfw.dylib libHSGLFW-b-0.1.0.5-ghc7.7.2012.dylib So my question are: - Where does the original install_name path (build/libglfw.dyli) come from? - What should be specified in the .cabal and/or Setup.hs file so that the haskell library is installed using the _correct_ relative path? Cheers, Christiaan ___ 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?
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?
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] GHC API question
Hi, This is what I've was referring to in my previous mail. Even though you're compiling to machine code, you are using the in-memory linker (i.e., the GHCi linker). It seems like that this is a fundamental limitation of the internal linker. You may be using it in a way that doesn't trigger the sanity check and end up causing a panic. I had similar problems when trying to profile an executable that was using certain parts of the GHC API [1]. If you are using parts of the GHC API that are related to the GHCi profiling API bug [2], then you will get errors/segfaults. AFAIK, a better 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: clash-0.1.3.0 (Functional Hardware Descriptions)
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 original lifting
function (^^^) to lift transition functions to arrows.
Below is an example that combines to multiply-accumulate circuits:
type Int8 = Signed D8
mac (State acc) (x,y) = (State (acc+x*y), acc)
dualMac :: Comp (Int8, Int8, Int8, Int8) Int8
dualMac = proc (a,b,c,d) - do
x - mac ^^^ 0 - (a,b)
y - mac ^^^ 0 - (c,d)
returnA - (x+y)
If you do care about the clockdomain a component belongs to you use
new multi-clock lifting function 'comp'.
Below is an example of a component, 'keyboard' working in the keyboard
clock domain, which is 20x slower than the system clock. Also it
responds to the 'falling' edge of the clock.
The component that generates a sine-tone 'tonegeneration' runs at the
system clock.
There is also a synchronizing component 'synchronize' that runs at the
system clock, using a dual flipflop, to synchronize the 'newKey'
control value.
kbclock = ClockDown 20
sysclock = ClockUp 1
synthesizer :: Comp Bit (Signed D16)
synthesizer = proc kbdata - do
(key,newKey) - comp keyboard initkb kbclock - kbdata
newKS - comp synchronize False sysclock - newKey
tone - comp tonegeneration initTone sysclock - (key,newKS)
returnA - tone
At the moment you shouldn't mix components created by the 'comp'
function and the (^^^) function.
The reason is that functions lifted with (^^^) would then basically
operate in all introduced clock-domains when used in a multi-clock
setting.
You can use the simulateM function to simulate descriptions that use
multiple clock domains.
Example use of the simulateM function can be found in
'Testbench/AudioConfTest.hs' of our DATE'11 demo [2].
Available simulation statements for a simulation session can be found
in 'CLasH/HardwareTypes.hs'. [3]
As you might have figured out by now: our simulation of a multi-clock
environment is not truely GALS.
The clocks are certainly linked. For example, if you define:
clk1 = ClockUp 1
clk5 = ClockUp 5
clk20 = ClockUp 20
You could/should interpret it that clk1 has a period of 1ns, clk5 a
period of 5 ns, etc.
So clk1 runs 5 times faster than clk5, and clk5 runs 4 times faster than clk20.
As we can't simulate the effects of meta-stability, there is no
incentive for us to also give the clocks some decimal offset at this
point in the development of CLaSH.
I hope you have a better understanding of the multiple clock domain
stuff now :-)
Cheers,
Christiaan
[1] Marco Gerards, a PhD student from our group who originally
introduced Arrows in CLaSH, called it 'Stat' for reasons I no longer
know. We recently agreed that 'Comp', an abbreviation for 'Component',
is a more sensible name.
[2]
http://github.com/christiaanb/DE1-Cyclone-II-FPGA-Board-Support-Package/blob/master/Testbench/AudioConfTest.hs
[3] http://github.com/christiaanb/clash/blob/master/clash/CLasH/HardwareTypes.hs
On Fri, Mar 25, 2011 at 12:19 PM, Bin Jin bjin1...@gmail.com wrote:
Hello,
Can you give some brief notes on the new introduced clock-related stuff like
Comp?
Thanks
--Bin Jin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: clash-0.1.3.0 (Functional Hardware Descriptions)
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 translate a (semantic) subset of Haskell to RTL-style VHDL. Instead of being an embedded DSL like Lava or ForSyDe, CLaSH takes are more 'traditional' approach to synthesis/compilation. It uses the GHC API as a front-end for parsing, type-checking and desugaring the Haskell source. It then exhaustively applies a list of meaning-preserving transformations to the intermediate GHC Core representation until it is in the desired normal form. The normalized Core/System Fc is then 'trivially' translated to RTL-style VHDL. The new version of CLaSH has the following updates: - Support for simulation and synthesis of multi-clock hardware [6] - Significant synthesis speed-up (4x to 10x) CLaSH already supported synthesis of: - User-defined Higher-Order functions [1] - User-defined ADTs (GADTs are not tested, but *might* work) - All of Haskell's choice constructs (Guards, Pattern Matching, etc.) - Lambda-abstraction / Anonymous Functions You can use CLaSH as a library, but the use of the adapted GHC interpreter (added the :vhdl command) is recommended. The interpreter can be found on the CLaSH website [2], where you will also find examples, papers, tutorials, etc. The library can be downloaded from Hackage [3]. I recently gave a demo of CLaSH at the DATE'11 conference in grenoble, this demo already made use of the multi-clock feature (and is actually the only reference if you want to experiment with multi-clock hardware yourself). The source for the demo (audio spectrum analyzer programmed on an Altera Cyclone II FPGA board) can be downloaded from my github page [4]. Do note that CLaSH only works when you have the 6.12.* branch of GHC installed! I am currently analyzing the impact of the GHC API changes made in the 7.0.* brach, and hope to make the transition to the new API within the next month. Although the compiler is already used by 2 other phd's in our group [5], it is not a thoroughly tested product, so your coding style might not be anticipated 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-Cyclone-II-FPGA-Board-Support-Package [5] http://caes.ewi.utwente.nl [6] Simulation does not show meta-stability, you will have to take care of synchronization (dual flipflop) yourself ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: clash-0.1.3.0 (Functional Hardware Descriptions)
Hello, I am pleased to announce an incremental update to CLaSH, version 0.1.3.0. CLaSH can translate a (semantic) subset of Haskell to RTL-style VHDL. Instead of being an embedded DSL like Lava or ForSyDe, CLaSH takes are more 'traditional' approach to synthesis/compilation. It uses the GHC API as a front-end for parsing, type-checking and desugaring the Haskell source. It then exhaustively applies a list of meaning-preserving transformations to the intermediate GHC Core representation until it is in the desired normal form. The normalized Core/System Fc is then 'trivially' translated to RTL-style VHDL. The new version of CLaSH has the following updates: - Support for simulation and synthesis of multi-clock hardware [6] - Significant synthesis speed-up (4x to 10x) CLaSH already supported synthesis of: - User-defined Higher-Order functions [1] - User-defined ADTs (GADTs are not tested, but *might* work) - All of Haskell's choice constructs (Guards, Pattern Matching, etc.) - Lambda-abstraction / Anonymous Functions You can use CLaSH as a library, but the use of the adapted GHC interpreter (added the :vhdl command) is recommended. The interpreter can be found on the CLaSH website [2], where you will also find examples, papers, tutorials, etc. The library can be downloaded from Hackage [3]. I recently gave a demo of CLaSH at the DATE'11 conference in grenoble, this demo already made use of the multi-clock feature (and is actually the only reference if you want to experiment with multi-clock hardware yourself). The source for the demo (audio spectrum analyzer programmed on an Altera Cyclone II FPGA board) can be downloaded from my github page [4]. Do note that CLaSH only works when you have the 6.12.* branch of GHC installed! I am currently analyzing the impact of the GHC API changes made in the 7.0.* brach, and hope to make the transition to the new API within the next month. Although the compiler is already used by 2 other phd's in our group [5], it is not a thoroughly tested product, so your coding style might not be anticipated 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-Cyclone-II-FPGA-Board-Support-Package [5] http://caes.ewi.utwente.nl [6] Simulation does not show meta-stability, you will have to take care of synchronization (dual flipflop) yourself ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Annual dutch functional programming day, january 7 2011
The annual Dutch functional programming day will take place soon: Date: Friday, January 7th, 2011 Location: University of Twente, Enschede During the day there will be several presentation related to FP-oriented research results, the use of FP concepts in industry, and the use of FP in education. Of course there is also plenty of opportunity to talk, exchange information, give demo's, and to meet old friends. Most participants are 'advanced' functional programmers; but those who recently developed an interest in all that is FP are of course more than welcome to join. Tradition 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 Please indicate if you want to give presentation, and if you like to attend the dinner afterwards. Please also register if you only want to participate, as we have to know for how many people we should order lunch. There is of course NO participation fee. See you the 7th of January! Christiaan Baaij ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
