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

...

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/

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

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

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.

Miguel Mitrofanov wrote:

I'm constantly amused by those who manage to use Windows without installing Cygwin.

I'm constantly puzzled by those who think that Cygwin is a mandatory part of Windows. ;-)

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.

Miguel Mitrofanov wrote:

Try Mac.

</commercial>

You're not the first to suggest this either. ;-) 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...

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/. :-(

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 :

...

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/

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

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

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. ;-)

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/

2009/12/9 Andrew Coppin :

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

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

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 wrote: From: Stephen Tetley 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

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

--- On Sat, 12/5/09, Daniel Fischer 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

--- On Sat, 12/5/09, Daniel Fischer 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.

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/

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 wrote: From: john lask 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