- Haskell-Cafe - Haskell.org

pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card?
by Stephen Tetley 09 Dec '09

09 Dec '09

Hi All, Would a pure Haskell version of pexports be useful to the Haskell community? For a Sunday afternoon hack that turned out to take a bit more effort (its now Wednesday), I thought I'd code up a tool that extracts function symbols from .dll's (also when I first looked at the C pexports it seemed somewhat unadopted, though checking today it appears to in MinGW, so my local MinGW must be out-of-date). If there are compelling uses that aren't covered by pexports and would ease Haskell C binding problems on Windows, I don't mind polishing up my tool, but otherwise I've exhausted my natural interest. Best wishes Stephen

3 3

Haskell job opportunity
by siki 09 Dec '09

09 Dec '09

I've posted this before but did not get a whole lot of responses, so here it is again: Principal investment firm based in Manhattan is looking for an outstanding software developer to develop and maintain the firm's proprietary valuation models as well as accounting and portfolio management systems. You should have at least a bachelor’s degree in computer science from a top university and impeccable coding style. This is a high-impact, high-visibility job opportunity where successful candidates will be entrusted with a lot of responsibility for products that have a direct effect on the P&L of the firm and influences our workflow. This is a very small hedge fund with me being the only developer right now. The next hire will have a very direct say into how this side of our business progresses from here. We are a growth oriented firm that values people who take a craftsman’s pride in their work. We always like to take a contrarian view of things, value experimenting and using often overlooked technologies. That is one of the main reasons why we currently started using Haskell in developing our quantitative models. We are looking for a candidate who shows strong analytical, organizational, and communication skills. Attention to detail is essential, i.e. we fully document everything we do and pay a lot of attention to coding style. The majority of our existing code was written in Java, so you should have at least some experience with Java and related technologies, in order to be able to maintain the existing code. But as I mentioned above, Haskell has now become my choice of language and eventually all of the existing code will have to be re-written in Haskell. Background in accounting is not necessary but is definitely a plus. Please send your CV and cover letter to recruitment at karamaan.com, or reply to this post if you have any questions. Thanks -- View this message in context: http://old.nabble.com/Haskell-job-opportunity-tp26697169p26697169.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

6 5

Re: binding to C libraries on Windoww
by John Lato 09 Dec '09

09 Dec '09

To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, such as C:\Program Files\, the user's home directory, the system directory, or directly off the drive root. Defaults are not common among different programs or even versions of programs, and install locations are frequently changed by users anyway. Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either. While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive. Even then, there's no guarantee the right version will be found (google "DLL Hell" for examples of the chaos that ensues). This is particularly true for developers, who frequently have multiple versions of libraries installed. The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers). On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on "configure". These packages will continue to require cygwin or mingw for the "configure" step. One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it. C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows. John

6 7

fgetc and fputc equivalents
by John D. Earle 09 Dec '09

09 Dec '09

Although much work has apparently gone into providing support for manipulation binary data I was unable to uncover a Haskell equivalent of the C fgetc and fputc functions. The Haskell equivalents work with Unicode character streams, not bytes words etcetera. I did find a library for handling arrays of bytes and such, but I did not find it to be convenient for the application I have in mind. I resolved myself to emitted Unicode 0s and 1s that are later converted to binary 0s and 1s by means of a C program. Is this functionality missing in Haskell? or did I miss something?

2 1

diff implementation in haskell
by Victor Nazarov 09 Dec '09

09 Dec '09

Are there pure haskell implementations of diff and diff3 algorithms. Like: > data Diff a = Deleted [a] | Common [a] | Added [a] > > diff :: Eq a => [a] -> [a] -> [Diff a] > > diff3 :: Eq a => [a] -> [a] -> [a] -> [a] or smth more general like: > class Diff a where > type Difference a > diff :: a -> a -> Difference a > patch :: a -> Difference a -> a > > prop_diffpatch a b = patch a (diff a b) == b ? If not, where can I start towards the implementation? What's the way to do it more functionally? -- Victor Nazarov

7 8

Re: fgetc and fputc equivalents
by John D. Earle 09 Dec '09

09 Dec '09

My interest isn't actually to push around characters. I do enough of that. What I really want to do is push bits and not bytes.

2 1

Low Level Audio - Writing bytes to the sound card?
by M Xyz 09 Dec '09

09 Dec '09

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

15 44

Re: A new form of newtype
by John Lato 09 Dec '09

09 Dec '09

> From: "Richard O'Keefe" <ok(a)cs.otago.ac.nz> > Subject: Re: [Haskell-cafe] A new form of newtype > > People are now writing EDSLs using Haskell to generate code for > all sorts of interesting things. What if you want to use Haskell > as a host for an EDSL targeted at a 24-bit DSP? *plug* for this specific case, I would use the word24 package, http://hackage.haskell.org/package/word24 which I wrote for a very similar problem. It was surprisingly difficult to get right (N.B. I have only tested the code, not proven it correct). I would have much preferred to let the compiler handle the details. > > There may not be MACHINES with 42-bit integers, > but that doesn't mean there aren't PROBLEMS that need them. > This whole idea of "let the machine dictate the sizes" is > precisely what I'm complaining of. > <snip> > > Sorry, but creating instances of Bounded is what a compiler is for. > If I don't write it, I won't wrong it. I'm pretty sure I don't understand the syntax of your proposal (which is my fault), but I definitely see the usefulness. I'll leave the syntax wrangling for the language lawyers, however. John

1 0

Checking dependencies from C packages in cabal
by Maurício CA 09 Dec '09

09 Dec '09

Hi, all, When pkg-config info is not available for a library (when I could use pkgconfig-depends), what should I use to check if needed libraries are installed and to give the compiler all needed info about include files and library location? Also, is it possible to do that without configure and make files? I have no experience with them. I also tried reading the Distribution module, but wasn't able to recognize what could be a natural way to handle this problem. Thanks, Maurício

2 2

ANNOUNCE: usb-0.3
by Bas van Dijk 09 Dec '09

09 Dec '09

Hello I made a new release of my usb library for high-level communication with usb devices from Haskell. See: http://hackage.haskell.org/package/usb-0.3 I made the following changes compared to the previous 0.2.0.1: - Moved the enumeration of usb devices in its own module: System.USB.Enumeration - Moved the device descriptor inside the device type so that you can retrieve it without doing IO, e.g: deviceDesc :: Device -> DeviceDesc - Moved the configuration descriptors inside the device descriptor so you can retrieve them without doing IO, e.g: deviceConfigs :: DeviceDesc -> [ConfigDesc] - Implemented standard device requests that are missing from libusb. - Made the timeout of I/O operations explicit. Now all I/O operations return an additional Bool that indicates if the operation has timed out. If an operation timed out does not mean there is no result, it just means that the result may be incomplete. - Added experimental (and still untested) support for iteratees for doing predictable, high-performance, safe, and elegant input processing using the iteratee package. See module: System.USB.IO.Synchronous.Enumerator - Fixed some asynchronous exception related bugs (put a needed bracket, block and unblock here and there). - Finally some functions, constructors and types got renamed, documentation got updated and extended and some refactoring has taken place. As always: questions, comments and patches are more than welcome. darcs get http://code.haskell.org/~basvandijk/code/usb regards, Bas

3 3