Low Level Audio - Writing bytes to the sound card?
What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using?
I think the portaudio library is the only contender but when I try to install it I get:
>cabal install portaudio
Resolving dependencies...
Downloading portaudio-0.0.1...
Configuring portaudio-0.0.1...
cabal: Missing dependency on a foreign library:
* Missing C library: portaudio
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Error: some packages failed to install:
portaudio-0.0.1 failed during the configure step. The exception was:
exit: ExitFailure 1
Hi, portaudio is my embarrassing fault, but it does work most of the time. (Community, some one remind me to revisit this package after Christmas.) Are you running in Windows? Linux? If Linux, which flavor? /jve On Fri, Dec 4, 2009 at 1:51 PM, M Xyz <functionallyharmonious@yahoo.com>wrote: > > What is the most minimal (preferably platform independent) library > available for writing bytes to the sound card? I see 60 wonderful libraries > on Hackage, but I really just need the Haskell equivalent of an > audio.write(byte[]) method. What sound api are these 60 libraries using? > > I think the portaudio library is the only contender but when I try to > install it I get: > > >cabal install portaudio > Resolving dependencies... > Downloading portaudio-0.0.1... > Configuring portaudio-0.0.1... > cabal: Missing dependency on a foreign library: > * Missing C library: portaudio > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > cabal: Error: some packages failed to install: > portaudio-0.0.1 failed during the configure step. The exception was: > exit: ExitFailure 1 > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
Hi, portaudio is my embarrassing fault, but it does work most of the time. (Community, some one remind me to revisit this package after Christmas.) Are you running in Windows? Linux? If Linux, which flavor? /jve I'm using Haskell on XP but I dual boot with Ubuntu 9 and I'd prefer not to break compatibility. I'm new to this, was I supposed to install portaudio for my OS before downloading the Haskell package? Are there other similar simple sound apis? On Fri, Dec 4, 2009 at 1:51 PM, M Xyz <functionallyharmonious@yahoo.com> wrote: What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using? I think the portaudio library is the only contender but when I try to install it I get:
cabal install portaudio Resolving dependencies... Downloading portaudio-0.0.1... Configuring portaudio-0.0.1...
cabal: Missing dependency on a foreign library: * Missing C library: portaudio This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the configure step. The exception was: exit: ExitFailure 1 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
You'll have to install the portaudio C libraries and header files before continuing. I never actually tested the package on XP, if you get it to work, I'd love to hear your experience. /jve On Fri, Dec 4, 2009 at 2:20 PM, M Xyz <functionallyharmonious@yahoo.com>wrote: > > > Hi, > > portaudio is my embarrassing fault, but it does work most of the time. > (Community, some one remind me to revisit this package after Christmas.) > > Are you running in Windows? Linux? If Linux, which flavor? > > /jve > > > I'm using Haskell on XP but I dual boot with Ubuntu 9 and I'd prefer not to > break compatibility. I'm new to this, was I supposed to install portaudio > for my OS before downloading the Haskell package? Are there other similar > simple sound apis? > > > > > On Fri, Dec 4, 2009 at 1:51 PM, M Xyz <functionallyharmonious@yahoo.com<http://mc/compose?to=functionallyharmonious@yahoo.com> > > wrote: > >> >> What is the most minimal (preferably platform independent) library >> available for writing bytes to the sound card? I see 60 wonderful libraries >> on Hackage, but I really just need the Haskell equivalent of an >> audio.write(byte[]) method. What sound api are these 60 libraries using? >> >> I think the portaudio library is the only contender but when I try to >> install it I get: >> >> >cabal install portaudio >> Resolving dependencies... >> Downloading portaudio-0.0.1... >> Configuring portaudio-0.0.1... >> cabal: Missing dependency on a foreign library: >> * Missing C library: portaudio >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the library is >> already installed but in a non-standard location then you can use the >> flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. >> cabal: Error: some packages failed to install: >> portaudio-0.0.1 failed during the configure step. The exception was: >> exit: ExitFailure 1 >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org <http://mc/compose?to=Haskell-Cafe@haskell.org> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > >
if you get it to work
As a spoiled Java programmer, this new role as pioneer is a bit intimidating, but I will give it a shot. :) I downloaded the portaudio v19 source and I'm attempting to build it. Apparently I have to register my Visual Studio Express with Microsoft. Deeper down the rabbit hole... (Interesting aside, on the registration form under "What programming language topics are you interested in?" neither F# or Haskell are listed) I wish there was a multimedia standard library for beginners like me. Writing audio to the speakers shouldn't be such a journey. You'll have to install the portaudio C libraries and header files before continuing. I never actually tested the package on XP, if you get it to work, I'd love to hear your experience. /jve On Fri, Dec 4, 2009 at 2:20 PM, M Xyz <functionallyharmonious@yahoo.com> wrote: Hi, portaudio is my embarrassing fault, but it does work most of the time. (Community, some one remind me to revisit this package after Christmas.) Are you running in Windows? Linux? If Linux, which flavor? /jve I'm using Haskell on XP but I dual boot with Ubuntu 9 and I'd prefer not to break compatibility. I'm new to this, was I supposed to install portaudio for my OS before downloading the Haskell package? Are there other similar simple sound apis? On Fri, Dec 4, 2009 at 1:51 PM, M Xyz <functionallyharmonious@yahoo.com> wrote: What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using? I think the portaudio library is the only contender but when I try to install it I get:
cabal install portaudio Resolving dependencies... Downloading portaudio-0.0.1... Configuring portaudio-0.0.1...
cabal: Missing dependency on a foreign library: * Missing C library: portaudio This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the configure step. The exception was: exit: ExitFailure 1 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
2009/12/4 M Xyz <functionallyharmonious@yahoo.com>
if you get it to work
As a spoiled Java programmer, this new role as pioneer is a bit intimidating, but I will give it a shot. :)
I downloaded the portaudio v19 source and I'm attempting to build it. Apparently I have to register my Visual Studio Express with Microsoft. Deeper down the rabbit hole... (Interesting aside, on the registration form under "What programming language topics are you interested in?" neither F# or Haskell are listed)
I wish there was a multimedia standard library for beginners like me. Writing audio to the speakers shouldn't be such a journey.
Hi, Did you look at synthesizer ? There is a short introductory file [1]. Be sure to look at the source (there is a link next to each function definition). Outputting list of values is easy, for instance Play.monoToInt16 (44100::Double) (map sin [0::Double,0.1..]) It uses SoX [2], which should be installed. Cheers, Thu [1] http://hackage.haskell.org/packages/archive/synthesizer-core/0.2.1/doc/html/... [2] http://sox.sourceforge.net/
Did you look at synthesizer ? There is a short introductory file [1]. Cheers, Thu [1] http://hackage.haskell.org/packages/archive/synthesizer-core/0.2.1/doc/html/... Thanks for the tutorial link. As I'm new to Haskell, these 2 lines got me thinking: "Using plain lists is not very fast" and "Getting real-time performance is mostly an issue of the right signal data structure." What do you use as an efficient byte buffer in a value-oriented language? The array tutorial says "Obviously, a naive implementation of such an array semantics would be intolerably inefficient, either requiring a new copy of an array for each incremental redefinition, or taking linear time for array lookup; thus, serious attempts at using this approach employ sophisticated static analysis and clever run-time devices to avoid excessive copying."
M Xyz schrieb:
Did you look at synthesizer ? There is a short introductory file [1]. Cheers, Thu
[1] http://hackage.haskell.org/packages/archive/synthesizer-core/0.2.1/doc/html/...
Thanks for the tutorial link. As I'm new to Haskell, these 2 lines got me thinking: "Using plain lists is not very fast" and "Getting real-time performance is mostly an issue of the right signal data structure." What do you use as an efficient byte buffer in a value-oriented language?
I have written some more details on it: http://hackage.haskell.org/packages/archive/synthesizer/0.2.0.1/doc/html/Syn... But I think that's not something one should start with ... http://www.haskell.org/haskellwiki/Sound_data_structures
M Xyz wrote:
if you get it to work
As a spoiled Java programmer, this new role as pioneer is a bit intimidating, but I will give it a shot. :)
I wish there was a multimedia standard library for beginners like me. Writing audio to the speakers shouldn't be such a journey.
Unfortunately, I've yet to find a single Haskell package that binds to C which will actually compile on Windows. :-( (It still makes me chuckle that even the COM bindings - which, by definition, can *only* work on Windows - also don't compile. One wonders how the author managed to test it...) Fortunately, for GUI work we have Gtk2hs, which works just fine on Windows. (Although obviously, Windows boxes don't usually have GTK+ installed.) But most of the really interesting stuff on Hackage is just unusable on Windows, sadly. If you ever do manage to get audio working, I'd be interested to know how.
Unfortunately, I've yet to find a single Haskell package that binds to C which will actually compile on Windows. :-(
Do you know how can we check dependencies to C libraries in Windows? Is pkg-config available? What about packages with no pkg-config configuration? Thanks, Maurício
Hello Andrew Plenty compile on Windows: Some OpenVG, OpenGL[1] (still? - I'm a bit behind the times) only compile with MinGW. Others are fine with Cygwin provided you have the dev packages installed (readline, pcre-light...). Yet others - no chance... If you can get the raw C library to work in either Cygwin or MinGW, you should have a good chance. The only sound software I've had working on Cygwin has been ChucK though I haven't tried many - ChucK uses RtAudio to talk to the soundcard which probably isn't easy to write a binding for as its C++. I had ChucK working two years ago, maybe things have improved in the Cygwin world regarding sound since then and other systems now work. http://www.music.mcgill.ca/~gary/rtaudio/ Best wishes Stephen [1] OpenGL worked fine when it was bundled with GHC, when it got unbundled things seemed to go amiss, plus it seemed to be the thing to use freeglut - hence the complicated instructions here: http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/
Stephen Tetley wrote:
Hello Andrew
Plenty compile on Windows:
Some OpenVG, OpenGL[1] (still? - I'm a bit behind the times) only compile with MinGW.
Others are fine with Cygwin provided you have the dev packages installed (readline, pcre-light...).
You're talking about MinGW and Cygwin. So... Unix emulators, basically. I don't think it should be necessary to install a Unix emulator just so that I can write Windows programs. Maybe others disagree.
If you can get the raw C library to work in either Cygwin or MinGW, you should have a good chance.
I'm by no means an expert here, but isn't it usual for C libraries on Windows to be supplied as a compiled DLL and a header file for using it? I don't quite understand why you need a C compiler.
[1] OpenGL worked fine when it was bundled with GHC, when it got unbundled things seemed to go amiss.
Apparently there is some talk of removing OpenGL from the Haskell Platform. And if this happens, it'll be one more thing I can't use on Windows. :-( Personally, I'd like to see *more* C bindings in HP, so that I can start doing cool stuff on Windows.
I'm constantly amused by those who manage to use Windows without installing Cygwin. On 5 Dec 2009, at 23:33, Andrew Coppin wrote:
Stephen Tetley wrote:
Hello Andrew
Plenty compile on Windows:
Some OpenVG, OpenGL[1] (still? - I'm a bit behind the times) only compile with MinGW.
Others are fine with Cygwin provided you have the dev packages installed (readline, pcre-light...).
You're talking about MinGW and Cygwin. So... Unix emulators, basically.
I don't think it should be necessary to install a Unix emulator just so that I can write Windows programs. Maybe others disagree.
If you can get the raw C library to work in either Cygwin or MinGW, you should have a good chance.
I'm by no means an expert here, but isn't it usual for C libraries on Windows to be supplied as a compiled DLL and a header file for using it? I don't quite understand why you need a C compiler.
[1] OpenGL worked fine when it was bundled with GHC, when it got unbundled things seemed to go amiss.
Apparently there is some talk of removing OpenGL from the Haskell Platform. And if this happens, it'll be one more thing I can't use on Windows. :-(
Personally, I'd like to see *more* C bindings in HP, so that I can start doing cool stuff on Windows.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Am Samstag 05 Dezember 2009 21:43:13 schrieb Miguel Mitrofanov:
I'm constantly amused by those who manage to use Windows without installing Cygwin.
I'm constantly amazed by those who manage to use Windows. (In case you want to misunderstand, it's not a Windows bashing, I just never managed to work with it)
Daniel Fischer wrote:
I'm constantly amazed by those who manage to use Windows.
(In case you want to misunderstand, it's not a Windows bashing, I just never managed to work with it
I've not had a lot of luck with Linux. I imagine this is merely due to having a lot more experience with Windows. FWIW, I used to hate Windows too - AmigaOS is far nicer. ;-) But now we're drifting wildly off-topic. For better or worse, Windows is the most popular desktop OS currently.
Try Mac. </commercial> On 6 Dec 2009, at 01:00, Andrew Coppin wrote:
Daniel Fischer wrote:
I'm constantly amazed by those who manage to use Windows.
(In case you want to misunderstand, it's not a Windows bashing, I just never managed to work with it
I've not had a lot of luck with Linux. I imagine this is merely due to having a lot more experience with Windows.
FWIW, I used to hate Windows too - AmigaOS is far nicer. ;-)
But now we're drifting wildly off-topic. For better or worse, Windows is the most popular desktop OS currently.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello Andrew, Sunday, December 6, 2009, 1:09:18 AM, you wrote:
Maybe once I get hired by some financial modelling consultants and get paid shedloads of money to write Haskell all day, I'll be able to afford a Mac. But until then...
with such attitude you will never be hired by financial sector. try instead: mac? great! windows? i love it! unix? i've used it since 60's -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Andrew,
Sunday, December 6, 2009, 1:09:18 AM, you wrote:
Maybe once I get hired by some financial modelling consultants and get paid shedloads of money to write Haskell all day, I'll be able to afford a Mac. But until then...
with such attitude you will never be hired by financial sector. try instead:
mac? great! windows? i love it! unix? i've used it since 60's
That's OK. I'm reasonably sure I will never get hired by the financial sector /anyway/. :-(
Hi Andrew 2009/12/5 Andrew Coppin <andrewcoppin@btinternet.com>:
I don't think it should be necessary to install a Unix emulator just so that I can write Windows programs. Maybe others disagree.
...
I'm by no means an expert here, but isn't it usual for C libraries on Windows to be supplied as a compiled DLL and a header file for using it? I don't quite understand why you need a C compiler.
The thing is, all the bindings on Hackage (or at least something most likely above 95%) are to "Unix" C libraries so you need a C compiler and a Unix emulator to use them. I do have have some sympathy with your point though - it is possible to get things to compile once you have Cygwin, but deployment on any other machine Windows thereafter is 'challenging' to say the least.
Apparently there is some talk of removing OpenGL from the Haskell Platform. And if this happens, it'll be one more thing I can't use on Windows. :-(
I didn't realise until I looked today that OpenGL was in the Haskell Platform. If the proposal to remove it is from Sven Panne then fair enough, otherwise it would be a bit disappointing - it always "just worked" when it was part of GHCs extralibs... Best wishes Stephen
I think there are some misapprehensions here:- many haskell packages binding to c libraries will compile with ghc without problems on windows - without cygwin, without mingw/msys system. Some such packages build "out of the box" on windows, like the zlib package which contains the c source for the c zlib library. GHC is able to compile and build this packages without any other c compiler/libraries/unix emulators etc because ghc itself contains part of the gcc c compiler tool chain and comes with all c standard headers, c++ headers and c/c++ runtime libraries. Other packages such as SDL package are relatively straightforward to build on windows - all that is required is to have an import library corresponding to your dll (or static lib) and the headers. You then update the library path field in the cabal file and include path. There is only one gotch-ya - you need to have a import library for the gcc tool chain (thats what ghc uses) i.e. a ".a" library and not the native windows ".LIB" import library. If you don't have ".a" import library but have the dll then the '.a' import library be built for any dll relativley easily. The correct '.a' import libraries and the libraries themselves for many standard unix/gnu packages can be found under the gnuwin32 project. Many unix libraries provide a windows build based on the mingw port of the gcc tool chain which will contain the correct import library. the bigest problem hamperring cleaner builds of haskell packages on windows is the lack of any standardised scheme for the installation of c-libraries and header files (and of course the availability of a suitable build of the library) Another problem hampering the install of haskell packages on windows is the use of the unix autoconf build system (./configure) , for which there is no substitute on windows other than cygwin and to lesser extent msys/mingw, this problem could be obviated by the provision of a standard win32 conf (forgetting about win64 for the moment) - package writters note!
Date: Sat, 5 Dec 2009 20:58:14 +0000 Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? From: stephen.tetley@gmail.com To: Haskell-Cafe@haskell.org CC:
Hi Andrew
2009/12/5 Andrew Coppin <andrewcoppin@btinternet.com>:
I don't think it should be necessary to install a Unix emulator just so that I can write Windows programs. Maybe others disagree.
...
I'm by no means an expert here, but isn't it usual for C libraries on Windows to be supplied as a compiled DLL and a header file for using it? I don't quite understand why you need a C compiler.
The thing is, all the bindings on Hackage (or at least something most likely above 95%) are to "Unix" C libraries so you need a C compiler and a Unix emulator to use them. I do have have some sympathy with your point though - it is possible to get things to compile once you have Cygwin, but deployment on any other machine Windows thereafter is 'challenging' to say the least.
Apparently there is some talk of removing OpenGL from the Haskell Platform. And if this happens, it'll be one more thing I can't use on Windows. :-(
I didn't realise until I looked today that OpenGL was in the Haskell Platform. If the proposal to remove it is from Sven Panne then fair enough, otherwise it would be a bit disappointing - it always "just worked" when it was part of GHCs extralibs...
Best wishes
Stephen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_________________________________________________________________ If It Exists, You'll Find it on SEEK Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/
Hi John Fair points - but aren't you always going to 'need' at least MinGW? (for some degree of 'need' of course, I use it quite a bit though prefer Cygwin, I suppose Andrew C. would care not to use either). GHC brings with it gcc and ld, ar ... but not much else, so when a C library isn't all but self-contained, you would have to use MinGW to get the .a file - SDL for instance just distributes the .dll in the runtime library package. Also gnuwin32 is a wee bit spartan by my consideration [1], but perhaps you could knock my 95% guess for Hackage bindings libraries needing Unix emulation down to 60%, or 50%. Likely I was wrong with my guestimate in the first place by thinking mainly about 'multimedia' libraries. Best wishes Stephen [1] Presumably you mean here? http://gnuwin32.sourceforge.net/ http://gnuwin32.sourceforge.net/packages.html
Stephen Tetley wrote:
Hi John
Fair points - but aren't you always going to 'need' at least MinGW? (for some degree of 'need' of course, I use it quite a bit though prefer Cygwin, I suppose Andrew C. would care not to use either).
I guess there's a difference in culture here. On Unix, it is usual to distribute programs as source, and build from source. (I guess in part because each one of the 12,657,234 different Unix variants is slightly different, and the program needs to work differently.) On Windows, it is usual to distribute everything as compiled binaries. (Indeed, for most commercial software, the sources simply aren't available at all.) And users get a binary program and binary DLLs or whatever. Developers get a binary DLL and whatever header files or import libraries are necessary to use it.
GHC brings with it gcc and ld, ar ... but not much else.
If I'm understanding this correctly, John is saying that GCC requires a different form of import library before you can access a DLL. For binary-only DLLs, this presumably won't be available. Hence the (abnormal) requirement to build the whole library from source, rather than just drop in a DLL and be done with it. Unix *expects* you to build everything from source, and so there are standard toolchains which are almost always available, and standard installation locations and so on and so forth. Windows does *not* expect you to be building things from source, and so is less-well set up in that regard. I don't suppose there's any danger of GHC ever switching to a native Win32 toolchain? (I don't actually know if one even exists with a sufficiently liberal license...)
Hi Andrew 2009/12/6 Andrew Coppin <andrewcoppin@btinternet.com>:
On Windows, it is usual to distribute everything as compiled binaries. (Indeed, for most commercial software, the sources simply aren't available at all.) And users get a binary program and binary DLLs or whatever. Developers get a binary DLL and whatever header files or import libraries are necessary to use it.
Indeed, but the Haskell libraries you want to use are in source form, no? Being a Haskell developer you're at least one step out of the usual, and most of the libraries are coming from developers on Unix so they can't be expected to package things for Windows.
If I'm understanding this correctly, John is saying that GCC requires a different form of import library before you can access a DLL. For binary-only DLLs, this presumably won't be available. Hence the (abnormal) requirement to build the whole library from source, rather than just drop in a DLL and be done with it.
John mentioned pexports in another message. I'd never come across it before - it would seem to improve the situation significantly, certainly for libraries that are more easily compilable with MSVCC like PortAudio, Shiva OpenVG, or where you have a reasonable DLL distributed like SDL. Best wishes Stephen
I guess there's a difference in culture here.
On Unix, it is usual to distribute programs as source, and build from source.
I see more than a cultural issue here. Suppose you write bindings to somelib-1.0.2, and release it with somelib-1.0.2. Then, somelib-1.0.3 is released to solve a serious security issue with 1.0.2. Linux or unix distributions will update their repositories, but users of your bindings will blindly keep using 1.0.2. Best, Maurício
Andrew Coppin <andrewcoppin@btinternet.com> writes:
I guess there's a difference in culture here.
On Unix, it is usual to distribute programs as source, and build from source. (I guess in part because each one of the 12,657,234 different Unix variants is slightly different, and the program needs to work differently.)
On Windows, it is usual to distribute everything as compiled binaries.
I think the real cultural difference is that you aren't a user, you're a prospective Haskell developer, as others have said. Developers pretty much have to install tools (like compilers and preprocessors) and have to work with source code. Traditionally, Unix *comes with* thousands of tools that are useful to developers. Windows traditionally came with none, at least none that I was ever able to find. Since many of the traditional Unix tools are available free, it makes sense that somebody would want to port them to Windows *for doing development*. It's not so much a Unix emulation as a solution to the lack of native Windows tools. Of course this makes sense especially to somebody who has gotten used to the Unix tools (such as myself). I would never try to *develop* seriously under Windows using just what comes preinstalled. Users of Unix (not developers) are just as used to getting compiled binaries as users of Windows. A good example of this in today's world is Mac OS X (or the iPhone, which is a small Unix system in essence). In earlier times, I assure you that users of Solaris (say) didn't expect to get a source release of Oracle and compile it up from scratch. There were indeed a few different supported versions of Solaris (different releases and hardware platforms), but this was Sun's and/or Oracle's problem. The open source movement has complicated this picture (mostly for the good, from the user's standpoint), but this just makes more people into developers in essence. This is the price you pay for getting stuff for free. It seems to me it doesn't make a lot of sense to complain about this. If you don't want to be a developer you can usually find something to buy that will be precompiled for you, or you can hire somebody. This is not to say that on a given day it isn't frustrating when you can't get something to compile, especially if it's just a tool you need to compile something else. But this is why developers are so wealthy, they have the fortitude to work through these problems. (Ha ha.) Regards, Jeff Scofield Seattle
Jeffrey Scofield wrote:
I think the real cultural difference is that you aren't a user, you're a prospective Haskell developer, as others have said. Developers pretty much have to install tools (like compilers and preprocessors) and have to work with source code.
And I have no problem with needing to install a Haskell compiler. If I had to install a seperate C compiler to make FFI to C work, that wouldn't seem unreasonable either. (As it happens, GHC has a C backend, so the C compiler just happens to be there already.) What does seem very weird is having to turn my Windows box into a psuedo-Unix system in order to write native Windows programs.
Traditionally, Unix *comes with* thousands of tools that are useful to developers. Windows traditionally came with none, at least none that I was ever able to find.
True. By default, Windows assumes you are a clueless user, not an expert developer.
Since many of the traditional Unix tools are available free, it makes sense that somebody would want to port them to Windows *for doing development*. It's not so much a Unix emulation as a solution to the lack of native Windows tools. Of course this makes sense especially to somebody who has gotten used to the Unix tools (such as myself). I would never try to *develop* seriously under Windows using just what comes preinstalled.
You can't develop anything with just what's preinstalled. (Well, unless you could writing batch scripts...) Generally, if you want to develop C or C++ applications on Windows, you install MS Visual Studio. It gives you the compiler, linker, dependency management, and a whole bunch of other stuff. You typically wouldn't install gcc, ld and Automake. (Unless of course you were specifically trying to port existing Unix code, obviously.) The thing is, if you're a C programmer on Windows, and you want to write (say) a program that talks to an Oracle database, typically what you'd do is install Visual Studio, download the Net8 client DLLs and header files, compile your application against the Net8 client header files, link everything, and when your program runs, it dynamically loads the Net8 DLLs and does its work. But it seems that if I want to talk to Oracle from Haskell, I'm expected to find the *source code* to the Net8 client and *compile it from source*. This is highly unusual for Windows. (I wouldn't be surprised if Oracle haven't even released the source code for their Net8 libraries...) It just isn't the way Windows usually works. Even without VS, if I'm working in C, all I really need is a compiler and a linker, and I can build an executable program that talks to Oracle. But with Haskell, it seems I need to be able to actually build the Net8 client from source - which, depending on how those sources are written, is likely to require an entire build system (Automake, a VS project, whatever). It's a much bigger undertaking than just compiling the few source file I personally wrote and linking a few bits together.
This is not to say that on a given day it isn't frustrating when you can't get something to compile, especially if it's just a tool you need to compile something else.
Oh, hey, I understand why things are like this. You make something work properly on Linux, and with not that much effort you can make it also work for BSD, Mac OS, Solaris, HP UX... even certain embedded devices can potentially run it. You want to make something work on Windows? You have to do everything totally differently. (No wonder people thought that things like Cygwin and MinGW were a good idea.) One of the things that has impressed me about GHC is that it takes Windows seriously. The compiler and interpretter both work flawlessly on Windows. They don't try to teraform Windows into just another Unix, they actually try to do things The Windows Way. I like that. And it's not like all of Hackage is useless to me; anything that's 100% Haskell compiles and installs first time, almost every time. It's just frastrating that all the cool multimedia stuff I'd like to be doing requires access to C, and that's still currently very difficult. I understand not many Haskell people use Windows, so it's not so easy for people to test, and not so many people have a detailed knowledge of Windows. And with this latest discussion, I'm beginning to understand why binding to C is so hard. But, yeah, it *is* still frustrating. ;-) And, unfortunately, I lack the knowledge or skill to be able to improve the situation...
But this is why developers are so wealthy, they have the fortitude to work through these problems. (Ha ha.)
Heh, good one. ;-)
On Mon, Dec 7, 2009 at 4:37 PM, Andrew Coppin <andrewcoppin@btinternet.com>wrote:
And I have no problem with needing to install a Haskell compiler. If I had to install a seperate C compiler to make FFI to C work, that wouldn't seem unreasonable either. (As it happens, GHC has a C backend, so the C compiler just happens to be there already.) What does seem very weird is having to turn my Windows box into a psuedo-Unix system in order to write native Windows programs.
<snip>
You can't develop anything with just what's preinstalled. (Well, unless you could writing batch scripts...)
Generally, if you want to develop C or C++ applications on Windows, you install MS Visual Studio. It gives you the compiler, linker, dependency management, and a whole bunch of other stuff. You typically wouldn't install gcc, ld and Automake. (Unless of course you were specifically trying to port existing Unix code, obviously.)
It helps, I believe, if you stop thinking of MinGW with MSYS as 'a
pseudo-Unix system'. They're billed as the minimal toolset required on windows to use the GNU compilers and build system (and, as everybody knows, Gnu's not Unix). The great thing about these compilers is that they're cross-platform and freely available, unlike MS Visual Studio. I think that it makes sense that open source software developers targeting multiple platforms would want to pick a tool suite that works across all those platforms, and the GNU tools fit that description. Cygwin truly is a Unix emulation, but MinGW/MSYS is just a packaging of useful open source (GNU) tools for Windows (including a shell). Many programs that work well as native Windows apps, such as the GIMP, are built with them.
Robert Greayer wrote:
It helps, I believe, if you stop thinking of MinGW with MSYS as 'a pseudo-Unix system'. They're billed as the minimal toolset required on windows to use the GNU compilers and build system (and, as everybody knows, Gnu's not Unix). The great thing about these compilers is that they're cross-platform and freely available, unlike MS Visual Studio.
These compilers are mostly C99 compliant, also unlike MS Visual Studio. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Robert Greayer wrote:
It helps, I believe, if you stop thinking of MinGW with MSYS as 'a pseudo-Unix system'. They're billed as the minimal toolset required on windows to use the GNU compilers and build system (and, as everybody knows, Gnu's not Unix). The great thing about these compilers is that they're cross-platform and freely available, unlike MS Visual Studio. I think that it makes sense that open source software developers targeting multiple platforms would want to pick a tool suite that works across all those platforms, and the GNU tools fit that description. Cygwin truly is a Unix emulation, but MinGW/MSYS is just a packaging of useful open source (GNU) tools for Windows (including a shell). Many programs that work well as native Windows apps, such as the GIMP, are built with them.
I see. So you're saying that while Cygwin is a Unix emulator, MinGW is just a set of Unix-style tools which run natively on Windows?
2009/12/9 Andrew Coppin <andrewcoppin@btinternet.com>:
I see. So you're saying that while Cygwin is a Unix emulator, MinGW is just a set of Unix-style tools which run natively on Windows?
Yes, in a nutshell MinGW executables are native. Executables in Cygwin may or may not have dependencies on cygwin.dll the Unix emulation library (depending whether or not they actually use Unix calls of course).
john lask wrote:
I think there are some misapprehensions here:-
Many haskell packages binding to c libraries will compile with ghc without problems on windows - without cygwin, without mingw/msys system.
OK, well I haven't tried building every C binding on all of Hackage, just a few of them. So far none of them have worked. (Including wxHaskell, SDL, one of the database packages, etc.) It's got to the point where I've simply given up trying. Most such packages just don't seem to work on Windows, and nobody on the mailing lists or on IRC has any clue why. (I guess because few people in the Haskell community use Windows and understand how it's supposed to work.)
Some such packages build "out of the box" on windows, like the zlib package which contains the c source for the c zlib library. GHC is able to compile and build this packages without any other c compiler/libraries/unix emulators etc because ghc itself contains part of the gcc c compiler tool chain and comes with all c standard headers, c++ headers and c/c++ runtime libraries.
Yes, I realised long ago that GHC uses GCC and other GNU build tools. (Presumably this makes porting to Windows far easier.) More recently I realised that it also includes a surprisingly large set of header files, seemingly including the entire Win32 API, which is interesting.
There is only one gotch-ya - you need to have a import library for the gcc tool chain (thats what ghc uses) i.e. a ".a" library and not the native windows ".LIB" import library.
They're different?? o_O Oh. Suddenly several things seem clearer...
If you don't have ".a" import library but have the dll then the '.a' import library be built for any dll relativley easily.
Any idea how?
the bigest problem hamperring cleaner builds of haskell packages on windows is the lack of any standardised scheme for the installation of c-libraries and header files (and of course the availability of a suitable build of the library).
Isn't one of Cabal's jobs to figure out where stuff is? Can't we get Cabal on Windows to say "hey, I need to find foo.h, you know where that is?" Or something like that?
Another problem hampering the install of haskell packages on windows is the use of the unix autoconf build system (./configure) - package writters note!
Heh. I found one Wiki page once describing how to set up a Cabal package. When it started talking about how to integrate Automake, I hung my head is dispair. (I believe the page in question is fixed now. But a lot of package authors seem to assume that everybody just uses Unix of some kind...)
Andrew Coppin wrote:
Unfortunately, I've yet to find a single Haskell package that binds to C which will actually compile on Windows. :-(
Take a look at logfloat[1], it builds cleanly on Windows XP using GHC 6.10.1 without needing Cygwin nor Mingw/Msys (however GHCi has some DLL errors[2]). Not that that has anything to do with audio ;) [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat [2] If you know how to resolve these, I'd be much obliged. I don't have a Windows machine to test on but I've been much irked that there's still this outstanding portability bug. -- Live well, ~wren
Compiling the C PortAudio library for either Cygwin or MinGW will be challenging at the moment. The current release doesn't compile as is, and although there should be patch for the configure script as an attachment to this message it seems to have gone amiss: http://music.columbia.edu/pipermail/portaudio/2009-May/009116.html I'd look for a different library to talk to the sound card... Best wishes Stephen 2009/12/4 M Xyz <functionallyharmonious@yahoo.com>
What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using?
I think the portaudio library is the only contender but when I try to install it I get:
Stephen, I had no problem compiling the portaudio binaries on Windows. It came with a msvc project that worked. The problem I'm getting currently is that when I "cabal install portaudio etc etc" I get a "c2hs.exe does not exist error" when c2hs.exe clearly exists and is in my system path. Just like this post from months ago: http://www.mail-archive.com/haskell-art@lurk.org/msg00101.html --- On Sat, 12/5/09, Stephen Tetley <stephen.tetley@gmail.com> wrote: From: Stephen Tetley <stephen.tetley@gmail.com> Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? To: haskell-cafe@haskell.org Date: Saturday, December 5, 2009, 5:00 PM Compiling the C PortAudio library for either Cygwin or MinGW will be challenging at the moment. The current release doesn't compile as is, and although there should be patch for the configure script as an attachment to this message it seems to have gone amiss: http://music.columbia.edu/pipermail/portaudio/2009-May/009116.html I'd look for a different library to talk to the sound card... Best wishes Stephen 2009/12/4 M Xyz <functionallyharmonious@yahoo.com>
What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using?
I think the portaudio library is the only contender but when I try to install it I get:
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Am Sonntag 06 Dezember 2009 00:10:05 schrieb M Xyz:
Stephen, I had no problem compiling the portaudio binaries on Windows. It came with a msvc project that worked. The problem I'm getting currently is that when I "cabal install portaudio etc etc" I get a "c2hs.exe does not exist error" when c2hs.exe clearly exists and is in my system path. Just like this post from months ago: http://www.mail-archive.com/haskell-art@lurk.org/msg00101.html
Try cabal install --with-c2hs="C:\path\to\c2hs.exe" portaudio maybe that'll work. If not, run cabal --verbose=3 install portaudio, perhaps that gives more information about what went wrong.
--- On Sat, 12/5/09, Daniel Fischer <daniel.is.fischer@web.de> wrote: Try cabal install --with-c2hs="C:\path\to\c2hs.exe" portaudio maybe that'll work. If not, run cabal --verbose=3 install portaudio, perhaps that gives more information about what went wrong. Daniel, Thank you for your thoughtful reply. I didn't know about those flags. The log is fairly long, and as I'm new to Haskell and Cabal it is mostly meaningless to me. I see very many incidences of "searching for ___ in path. Cannot find ___ on the path" so maybe this is all as simple as me not setting my environment correctly. Log: cabal install portaudio --verbose=3 --with-c2hs="C:\Program Files\Haskell\bin\c2hs.exe" --extra-include-dirs="C:\A\install\programming\portaudio\portaudio\include" --extra-lib-dirs="C:\A\install\programming\portaudio\portaudio\build\msvc\Win32\Release" >log.txt searching for ghc in path. found ghc at C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--numeric-version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe is version 6.10.4 looking for package tool: ghc-pkg near compiler in C:\Program Files\Haskell Platform\2009.2.0.2\bin found package tool in C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe is version 6.10.4 ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["dump","--global"]) Reading available packages... Resolving dependencies... selecting portaudio-0.0.1 (hackage) and discarding mtl-1.0 selecting mtl-1.1.0.2 (installed or hackage) and discarding mtl-1.1.0.0 and 1.1.0.1 selecting haskell98-1.0.1.0 (installed or hackage) and discarding haskell98-1.0 selecting random-1.0.0.1 (installed or hackage) and discarding random-1.0.0.0 selecting process-1.0.1.1 (installed or hackage) and discarding filepath-1.0 and process-1.0.0.0 selecting directory-1.0.0.3 (installed or hackage) and discarding directory-1.0.0.0 selecting old-time-1.0.0.2 (installed or hackage) and discarding old-time-1.0.0.0 selecting old-locale-1.0.0.1 (installed or hackage) and discarding old-locale-1.0.0.0 selecting filepath-1.1.0.2 (installed or hackage) and discarding filepath-1.1.0.0 and 1.1.0.1 selecting Win32-2.2.0.0 (installed or hackage) and discarding Win32-2.1 and 2.1.0.0 selecting bytestring-0.9.1.4 (installed or hackage) and discarding bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3 and 0.9.1.5 selecting ghc-prim-0.1.0.0 (installed) selecting rts-1.0 (installed) selecting array-0.2.0.0 (installed or hackage) and discarding array-0.1.0.0 selecting base-3.0.3.1 (installed) and 4.1.0.0 (installed) and discarding syb-0.1.0.0 and 0.1.0.1 selecting integer-0.1.0.1 (installed) selecting syb-0.1.0.1 (installed) In order, the following would be installed: portaudio-0.0.1 (new package) portaudio-0.0.1 has already been downloaded. Extracting C:\Documents and Settings\M\Application Data\cabal\packages\hackage.haskell.org\portaudio\0.0.1\portaudio-0.0.1.tar.gz to C:\DOCUME~1\M\LOCALS~1\Temp\portaudio-0.0.13824... Using internal setup method with build-type Simple and args: ["configure","--verbose=3","--ghc","--global","--extra-include-dirs=C:\\A\\install\\programming\\portaudio\\portaudio\\include","--extra-lib-dirs=C:\\A\\install\\programming\\portaudio\\portaudio\\build\\msvc\\Win32\\Release","--constraint=base ==3.0.3.1","--constraint=haskell98 ==1.0.1.0","--constraint=mtl ==1.1.0.2","--with-c2hs=C:\\Program Files\\Haskell\\bin\\c2hs.exe"] Configuring portaudio-0.0.1... Creating dist (and its parents) searching for ghc in path. found ghc at C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--numeric-version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe is version 6.10.4 looking for package tool: ghc-pkg near compiler in C:\Program Files\Haskell Platform\2009.2.0.2\bin found package tool in C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe is version 6.10.4 ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["dump","--global"]) Dependency base >3 && ==3.0.3.1: using base-3.0.3.1 Dependency haskell98 -any && ==1.0.1.0: using haskell98-1.0.1.0 Dependency mtl >=1.1.0.0 && ==1.1.0.2: using mtl-1.1.0.2 searching for alex in path. found alex at C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\alex.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\extralibs\\bin\\alex.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\alex.exe is version 2.3.1 searching for ar in path. found ar at C:\Program Files\Haskell Platform\2009.2.0.2\bin\ar.exe ("C:\\Program Files\\Haskell\\bin\\c2hs.exe",["--numeric-version"]) C:\Program Files\Haskell\bin\c2hs.exe is version 0.16.0 searching for cpphs in path. Cannot find cpphs on the path searching for ffihugs in path. Cannot find ffihugs on the path ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc.exe",["-dumpversion"]) C:\Program Files\Haskell Platform\2009.2.0.2\gcc.exe is version 3.4.5 searching for greencard in path. Cannot find greencard on the path searching for haddock in path. found haddock at C:\Program Files\Haskell Platform\2009.2.0.2\bin\haddock.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\haddock.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\haddock.exe is version 2.4.2 searching for happy in path. found happy at C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\happy.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\extralibs\\bin\\happy.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\happy.exe is version 1.18.4 searching for hmake in path. Cannot find hmake on the path searching for hsc2hs in path. found hsc2hs at C:\Program Files\Haskell Platform\2009.2.0.2\bin\hsc2hs.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\hsc2hs.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\hsc2hs.exe is version 0.67 searching for HsColour in path. Cannot find HsColour on the path searching for hugs in path. Cannot find hugs on the path searching for jhc in path. Cannot find jhc on the path ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["-c","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.c","-o","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.o"]) ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc-lib\\ld.exe",["-x","-r","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.o","-o","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3825.o"]) searching for nhc98 in path. Cannot find nhc98 on the path searching for pkg-config in path. Cannot find pkg-config on the path searching for ranlib in path. Cannot find ranlib on the path searching for strip in path. Cannot find strip on the path searching for tar in path. Cannot find tar on the path Using Cabal-1.6.0.3 compiled by ghc-6.10 Using compiler: ghc-6.10.4 Using install prefix: C:\Program Files\Haskell Binaries installed in: C:\Program Files\Haskell\bin Libraries installed in: C:\Program Files\Haskell\portaudio-0.0.1\ghc-6.10.4 Private binaries installed in: C:\Program Files\Haskell\portaudio-0.0.1 Data files installed in: C:\Program Files\Haskell\portaudio-0.0.1 Documentation installed in: C:\Program Files\Haskell\doc\portaudio-0.0.1 Using alex version 2.3.1 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\alex.exe Using ar found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\ar.exe Using c2hs version 0.16.0 given by user at: C:\Program Files\Haskell\bin\c2hs.exe No cpphs found No ffihugs found Using gcc version 3.4.5 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\gcc.exe Using ghc version 6.10.4 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe Using ghc-pkg version 6.10.4 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe No greencard found Using haddock version 2.4.2 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\haddock.exe Using happy version 1.18.4 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\happy.exe No hmake found Using hsc2hs version 0.67 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\hsc2hs.exe No hscolour found No hugs found No jhc found Using ld found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\gcc-lib\ld.exe No nhc98 found No pkg-config found No ranlib found No strip found No tar found ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc.exe",["-BC:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc-lib","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\include\\mingw","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.c","-o","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824","-BC:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc-lib","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\include\\mingw","-D__GLASGOW_HASKELL__=610","-IC:\\A\\install\\programming\\portaudio\\portaudio\\include","-I.","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\process-1.0.1.1\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\directory-1.0.0.3\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\old-time-1.0.0.2\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\Win32-2.2.0.0\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\bytestring-0.9.1.4\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\base-4.1.0.0\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2/include","-lportaudio","-LC:\\A\\install\\programming\\portaudio\\portaudio\\build\\msvc\\Win32\\Release"]) Using internal setup method with build-type Simple and args: ["build","--verbose=3"] Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library portaudio-0.0.1... Creating dist\build\Sound\PortAudio (and its parents) ("C:\\Program Files\\Haskell\\bin\\c2hs.exe",["--include=dist\\build","--cppopts=-D__GLASGOW_HASKELL__=610","--cppopts=-IC:\\A\\install\\programming\\portaudio\\portaudio\\include","--output-dir=dist\\build","--output=Sound\\PortAudio\\Base.hs",".\\Sound\\PortAudio\\Base.chs"]) c2hs.exe: does not exist C:\Program Files\Haskell\bin\c2hs.exe returned ExitFailure 1
Am Sonntag 06 Dezember 2009 00:47:38 schrieb M Xyz:
Daniel, Thank you for your thoughtful reply. I didn't know about those flags. The log is fairly long, and as I'm new to Haskell and Cabal it is mostly meaningless to me. I see very many incidences of "searching for ___ in path. Cannot find ___ on the path" so maybe this is all as simple as me not setting my environment correctly.
If you have cpphs, hugs, jhc, greencard etc., it is probably something about your environment. If you don't have them, it's clear that they aren't found. On the other hand, that doesn't explain Using c2hs version 0.16.0 given by user at: C:\Program Files\Haskell\bin\c2hs.exe -- so it finds c2hs, and can apparently run c2hs --version ("C:\\Program Files\\Haskell\\bin\\c2hs.exe",["--include=dist\\build","--cppopts=- D__GLASGOW_HASKELL__=610","--cppopts=-IC: \\A\\install\\programming\\portaudio\\portaudio\\include","--output-dir=dist\\build","-- output=Sound\\PortAudio\\Base.hs",".\\Sound\\PortAudio\\Base.chs"]) c2hs.exe: does not exist C:\Program Files\Haskell\bin\c2hs.exe returned ExitFailure 1 -- bang To ascertain whether c2hs works at all, can you try to run it manually? (cd to an appropriate directory, cabal unpack portaudio cd portaudio (or whatever, so that Base.chs is found via .\Sound\PortAudio\Base.chs md dist\build c2hs.exe --include=dist\build --cppopts=-D__GLASGOW_HASKELL__=610 --cppopts=-IC: \A\install\programming\portaudio\portaudio\include --output-dir=dist\build -- output=Sound\PortAudio\Base.hs .\Sound\PortAudio\Base.chs ) If that works, the problem is somewhere in cabal, otherwise in c2hs, either way, we'll know more.
--- On Sat, 12/5/09, Daniel Fischer <daniel.is.fischer@web.de> wrote: If you have cpphs, hugs, jhc, greencard etc., it is probably something about your environment. If you don't have them, it's clear that they aren't found. I don't know what those things are. I have nothing but what came with HP other than installing c2hs today. If that works, the problem is somewhere in cabal, otherwise in c2hs, either way, we'll know more. Alright, I followed the instructions and everything was as you said. I still get "c2hs.exe does not exist". C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>"C:\Program Files\Has kell\bin\c2hs.exe" --include=dist\build --cppopts=-D__GLASGOW_HASKELL__=610 --cp popts=-IC:\A\install\programming\portaudio\portaudio\include --output-dir=dist\b uild --output=Sound\PortAudio\Base.hs .\Sound\PortAudio\Base.chs c2hs.exe: does not exist C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>pause Press any key to continue . . . By the way, I have posted this problem to the c2hs mailing list in case they have some insight.
Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: I just had another idea. dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs c2hs: does not exist it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! Try installing from the unpacked sources (cd portaudio; cabal install) or the old- fashioned way: cd portaudio-0.0.1 ghc --make Setup ./Setup configure --help (choose your options, prefix, profiling, ...) ./Setup configure $OPTIONS ./Setup build if all's well, ./Setup haddock ./Setup install (dies for me with dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder Verzeichnisnicht gefunden c2hs: Error during preprocessing custom header file cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the building phase. The exception was: exit: ExitFailure 1 because I don't have portaudio installed)
I don't know whether this will help you but I just downloaded an built the haskell portaudio package ... (I had a windows msvc build of portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 make an import lib for ghc from dll: pexports libpa19.dll > libpa19.def dlltool --input-def libpa19.def --output-lib libpa19.a edit the .cabal file or use command line flags extra-Libraries: pa19 extra-lib-dirs: c:\portaudio19\lib include-dirs: c:\portaudio19\include runghc setup configure make sure you have cpp i.e. the c-preprocessor on your exe path, otherwise you will get 'cpp' is not recognized as an internal or external command, operable program or batch file. c2hs.exe: Error during preprocessing custom header file runghc setup build builds ok ...??
From: daniel.is.fischer@web.de To: functionallyharmonious@yahoo.com Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? Date: Sun, 6 Dec 2009 02:34:17 +0100 CC: haskell-cafe@haskell.org
Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz:
I just had another idea.
dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs c2hs: does not exist
it's not that c2hs isn't found or something, c2hs doesn't find Base.chs!
Try installing from the unpacked sources (cd portaudio; cabal install) or the old- fashioned way:
cd portaudio-0.0.1
ghc --make Setup
./Setup configure --help (choose your options, prefix, profiling, ...)
./Setup configure $OPTIONS ./Setup build
if all's well,
./Setup haddock ./Setup install
(dies for me with dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder Verzeichnisnicht gefunden c2hs: Error during preprocessing custom header file cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the building phase. The exception was: exit: ExitFailure 1 because I don't have portaudio installed) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_________________________________________________________________ If It Exists, You'll Find it on SEEK Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/
I am going to give this a try. Thanks. Where can I get the pexports and dlltool utilities? Google yields: http://www.emmestech.com/software/pexports-0.43/download_pexports.html http://sourceware.org/binutils/ Are those correct? --- On Sat, 12/5/09, john lask <jvlask@hotmail.com> wrote: From: john lask <jvlask@hotmail.com> Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? To: daniel.is.fischer@web.de, functionallyharmonious@yahoo.com Cc: haskell-cafe@haskell.org Date: Saturday, December 5, 2009, 9:03 PM I don't know whether this will help you but I just downloaded an built the haskell portaudio package ... (I had a windows msvc build of portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 make an import lib for ghc from dll: pexports libpa19.dll > libpa19.def dlltool --input-def libpa19.def --output-lib libpa19.a edit the .cabal file or use command line flags extra-Libraries: pa19 extra-lib-dirs: c:\portaudio19\lib include-dirs: c:\portaudio19\include runghc setup configure make sure you have cpp i.e. the c-preprocessor on your exe path, otherwise you will get 'cpp' is not recognized as an internal or external command, operable program or batch file. c2hs.exe: Error during preprocessing custom header file runghc setup build builds ok ...??
From: daniel.is.fischer@web.de To: functionallyharmonious@yahoo.com Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? Date: Sun, 6 Dec 2009 02:34:17 +0100 CC: haskell-cafe@haskell.org
Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz:
I just had another idea.
dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs c2hs: does not exist
it's not that c2hs isn't found or something, c2hs doesn't find Base.chs!
Try installing from the unpacked sources (cd portaudio; cabal install) or the old- fashioned way:
cd portaudio-0.0.1
ghc --make Setup
./Setup configure --help (choose your options, prefix, profiling, ...)
./Setup configure $OPTIONS ./Setup build
if all's well,
./Setup haddock ./Setup install
(dies for me with dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder Verzeichnisnicht gefunden c2hs: Error during preprocessing custom header file cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the building phase. The exception was: exit: ExitFailure 1 because I don't have portaudio installed) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Australia's #1 job site If It Exists, You'll Find it on SEEK
John Lask, The steps you enumerated below successfully built portaudio for me! Thank you! I wonder though, you said to rename the dll to libpa19.dll from portaudio_x86.dll and to change the .cabal entry from "extra-Libraries: portaudio" to "extra-Libraries: pa19". Since my .dll name and .cabal file entry were mismatched, was that what could have been wrong all along? Was the creation of a .a file necessary? I would delete the .a file and retry with libportaudio.dll but I won't push my luck. Now if I could just get Gtk2hs working now, I could be happy *and* productive. :) --- On Sat, 12/5/09, john lask <jvlask@hotmail.com> wrote: From: john lask <jvlask@hotmail.com> Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? To: daniel.is.fischer@web.de, functionallyharmonious@yahoo.com Cc: haskell-cafe@haskell.org Date: Saturday, December 5, 2009, 9:03 PM I don't know whether this will help you but I just downloaded an built the haskell portaudio package ... (I had a windows msvc build of portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 make an import lib for ghc from dll: pexports libpa19.dll > libpa19.def dlltool --input-def libpa19.def --output-lib libpa19.a edit the .cabal file or use command line flags extra-Libraries: pa19 extra-lib-dirs: c:\portaudio19\lib include-dirs: c:\portaudio19\include runghc setup configure make sure you have cpp i.e. the c-preprocessor on your exe path, otherwise you will get 'cpp' is not recognized as an internal or external command, operable program or batch file. c2hs.exe: Error during preprocessing custom header file runghc setup build builds ok ...??
From: daniel.is.fischer@web.de To: functionallyharmonious@yahoo.com Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? Date: Sun, 6 Dec 2009 02:34:17 +0100 CC: haskell-cafe@haskell.org
Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz:
I just had another idea.
dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs c2hs: does not exist
it's not that c2hs isn't found or something, c2hs doesn't find Base.chs!
Try installing from the unpacked sources (cd portaudio; cabal install) or the old- fashioned way:
cd portaudio-0.0.1
ghc --make Setup
./Setup configure --help (choose your options, prefix, profiling, ...)
./Setup configure $OPTIONS ./Setup build
if all's well,
./Setup haddock ./Setup install
(dies for me with dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder Verzeichnisnicht gefunden c2hs: Error during preprocessing custom header file cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the building phase. The exception was: exit: ExitFailure 1 because I don't have portaudio installed) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Australia's #1 job site If It Exists, You'll Find it on SEEK
--- On Sat, 12/5/09, Daniel Fischer <daniel.is.fischer@web.de> wrote: cd portaudio-0.0.1 ghc --make Setup ../Setup configure --help (choose your options, prefix, profiling, ...) ../Setup configure $OPTIONS ../Setup build Everything went well until "Setup build" which yielded our friend "c2hs.exe does not exist". C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>ghc --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup.exe ... C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup configure --hel p Usage: Setup configure [FLAGS] Flags for configure: .......(edited out)................ C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup configure --ext ra-include-dirs="C:\A\install\programming\portaudio\portaudio\include" --extra-l ib-dirs="C:\A\install\programming\portaudio\portaudio\build\msvc\Win32\Release" Configuring portaudio-0.0.1... C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup build Preprocessing library portaudio-0.0.1... c2hs.exe: does not exist
participants (15)
-
Andrew Coppin -
Bulat Ziganshin -
Daniel Fischer -
Erik de Castro Lopo -
Henning Thielemann -
Jeffrey Scofield -
john lask -
John Van Enk -
M Xyz -
Maurício CA -
Miguel Mitrofanov -
minh thu -
Robert Greayer -
Stephen Tetley -
wren ng thornton