December 2009 - Haskell-Cafe

Re: Nano-Languages
by John D. Earle 09 Dec '09

09 Dec '09

To help clarify my meaning Haskell would be used as an assembler language or put in another way an intermediate language for those constructs that are caught by the preprocessor for special processing. Since Haskell is a functional language I would imagine that this would be unproblematic.

1 0

OpenAL and Hsndfile
by Matthew 09 Dec '09

09 Dec '09

Yesterday, I set out to accomplish the challenge of loading and playing a sound from a file. So far, my attempts have resulted only in silence... rather disheartening after all the effort it took to get everything to build and run cleanly. I currently take the following steps: - Load samples from file into an IOCArray using hsndfile - Create an OpenAL buffer which points to the IOCArray - Play sound using OpenAL code is at: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13836 I'm wondering if anyone who is familiar with these libraries can tell me if I'm using them sanely or not. Alternatively, if anyone has a favorite sound library and can help me get started with that, I'd be very grateful. -Matt

2 1

Re: [Haskell-cafe] Re: ANN: hakyll-0.1
by Robert Greayer 09 Dec '09

09 Dec '09

sigh -- to the list this time. On Wed, Dec 9, 2009 at 9:16 AM, Tom Tobin <korpios(a)korpios.com> wrote: > On Wed, Dec 9, 2009 at 4:59 AM, Ketil Malde <ketil(a)malde.org> wrote: > > Tom Tobin <korpios(a)korpios.com> writes: > >> If it turns out that Hakyll *is* okay to be BSD3 licensed so > >> long as neither any binary nor the GPL'd work's source is distributed > >> under non-GPL terms, well ... I'll say that the meaning of "BSD > >> licensed" will have become much less reliable, since it means you > >> actually have to trace the genealogy of the libraries you use *all* > >> the way back in order to understand the situation for certain. > > > > How so? To me it's the exact converse: if the author of Hakyll may > > *not* distribute his work under the BSD license, just because it is > > intended to be linked with some GPL code, this complicates issues > > tremendously. > > For instance, it would mean that businesses which may be writing > proprietary software can't assume they can freely use a liberally > licensed (e.g., BSD3) library — which would *completely* go against > the prevailing understanding of liberally licensed software. Tainting > your software with a GPL dependency without realizing it is a > terrifying prospect (and certainly one of the questions I'd now like > to pose to the SFLC). > I don't think I follow your reasoning here: certainly, a business can use, freely, the Hakyll library (meaning that they can redistribute, in binary form, their executable built with it, without distributing the Hakyll source or their own source). They cannot freely use the Pandoc library in the same way, because it is GPL. Since the Hakyll library depends on the Pandoc library, they will of course have some trouble with *building* an executable that contains Hakyll but not Pandoc. Both there's no hidden dependency, no 'tainting' of Hakyll involved. There is a danger, of course, that when installing Hakyll (via cabal) the user won't realize they've also installed Pandoc, even though the dependency is clearly specified. The lesson here is that someone packaging an executable for distribution has to be aware of everything they are building into it. It's possible to make a mistake here, if one is not careful. But it doesn't require much diligence to get it right (if you use cabal to build your executable, you have to specify your dependencies. Check the licensing terms of each, and comply).

1 0

ANNOUNCE: ls-usb-0.1.0.2
by Roel van Dijk 09 Dec '09

09 Dec '09

Hello everyone, I have released a minor update of my ls-usb program: http://hackage.haskell.org/package/ls-usb This small utility lists USB devices connected to your system. It can also show you the device descriptors, interface descriptors, vendor and product identifiers and various other things. All in wonderful colours of course. The only major change is that it now depends on usb-0.3.* Regards, Roel van Dijk

1 0

ANNOUNCE: bindings-libusb-1.4.2
by Bas van Dijk 09 Dec '09

09 Dec '09

Hello, I just uploaded a new release of Maurício C. Antunes' bindings-libusb to hackage. See: http://hackage.haskell.org/package/bindings-libusb-1.4.2 bindings-libusb is a bindings-DSL based, low-level binding to libusb. This release adds support for the recent libusb-1.0.5. BTW, there is work being done to create a Windows port for libusb. This means that in the near future libusb and therefor bindings-libusb and my usb packages will work on all major platforms, hooray! regards, Bas

1 0

Re: Allowing hyphens in identifiers
by John D. Earle 09 Dec '09

09 Dec '09

Oh yes I forgot. You will also need to map not merely those places where hyphens are used by the language, but also those circumstances where, wondering how to state it abstractly, anyway in string literals and such where substitutions should not occur.

1 0

Re: Allowing hyphens in identifiers
by John D. Earle 09 Dec '09

09 Dec '09

A makeshift preprocessor written say in Perl could be used to replace the embedded hyphens with underscores thereby making them synonyms. A list of ways in which hyphens are used in the language will need to be developed so they may be distinguished. You don't want a single line comment sign being taken as containing an embedded hyphen. If done properly it shouldn't cause any problems. It will allow you to side step having to actually modify the language and may be portable across language implementations. I use the C language preprocessor to correct a number of features of the C language syntax that I find ugly.

1 0

A new form of newtype
by Richard O'Keefe 08 Dec '09

08 Dec '09

Haskell is very nearly a high level language. One rather unpleasant way in which it lets the the underlying machine show through is integral types. Aside from the unbounded Integer type, which is fine, there are integral types bounded by machine sizes: Int, size unspecified, Data.Int.Int{8,16,32,64}, and Data.Word.Word{8,16,32,64}. There are a number of problems with these. The principal one is that in order to figure out which size is needed, a programmer must do arithmetic. I still remember a student's bitter complaint about being required to find the base 2 logarithm of 32 in an examination where calculators were forbidden... I propose a small addition to 'newtype' syntax: 'newtype' id '=' '[' expr {',' expr}... ']' [deriving-part] The expressions are Integral expressions made from constants and suitable Prelude functions. Each Haskell implementation supports some sublist of the types [Int1,Word1,Int2,Word2,Int3,Word3,...,Int64,Word64, ...,Int256,Word256,...,Integral, _except (It's almost interesting that the Natural type missing from Haskell would go after Integral in this list, and so would never be used.) The effect of the declaration would be to make "id" a copy of the first type in the list of supported types that is big enough to include the value of every expression on the right hand side, except that minBound = the smallest value on the right hand side maxBound = the largest value on the right hand side rather than being the bounds for the underlying type. The instances that could be derived would include Bits, Bounded, Data, Enum, Eq, Integral, Ix, Num, Ord, PrintfArg, Read, Real, Show, Storable, Typable. I'd actually prefer that the default list of derived instances be short, but it's hard to draw an arbitrary line, so the default instances should be the same as the default instances for Int in the same Haskell system. Suppose I knew that I had a 2TB disc (I don't, and wish I did) and wanted to be able to hold not only any file size but the sums and differences of up to 10,000,000 file sizes. (There could be one giant file, and all the file sizes could be the size of that file.) newtype FileSize = [-10000000*2^41,10000000*2^41] I don't see any simple way to get named values into the expressions defining a new integral type, but the use of cpp with Haskell has been common practice for a long time, so #define Tera 2^40 #define Many 10000000 newtype FileSize = [-Many*2*Tera,Many*2*Tera] In this case, FileSize would be a copy of Integer.

2 2

ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
by John Millikin 08 Dec '09

08 Dec '09

This is the second public release of my D-Bus implementation. dbus-core is an implementation of the D-Bus protocol, and dbus-client is a set of wrappers and utility computations to simplify writing basic clients. Interesting changes to dbus-core ================================ * Performance improvements: sending and receiving large structures should now be significantly faster. My thanks and appreciation go to Bryan O'Sullivan, whose excellent Criterion library made benchmarking the serialisation code much easier than it had any right to be. * Better support for byte arrays: byte strings (strict and lazy) are now directly supported types, with special cases to avoid most conversion overhead. * Implemented the TCP/IP transport, though it's untested because I can't figure out how to make the server listen on a socket. If anybody cares about remote D-Bus, and this doesn't work, drop me a mail with your configuration and I'll find out why. * Added module to represent "match rules", required for full signal support. * Added module for name reservations -- this is really just moving the bulk of the code from dbus-client into dbus-core, where it belongs. * Fixed possible concurrency issue when receiving messages from a connection in multiple threads. This is still a really bad idea, and it will never work correctly, but at least now it won't corrupt the connection state. Interesting changes to dbus-client ================================== * Fixed dumb signature to mkClient (thanks, Max). Its purpose should now be more obvious. * Shifted around some of the method call APIs -- it's now possible to send method calls without a proxy. * Uses the new MatchRule work to fully support receiving signals. Documentation ============= PDFs of the source; these are the most useful and complete documentation currently available: https://dl.dropbox.com/u/1947532/dbus-core_0.6.pdf https://dl.dropbox.com/u/1947532/dbus-client_0.2.pdf An API listing is also available, good for a quick overview: https://dl.dropbox.com/u/1947532/dbus-core_0.6/index.html https://dl.dropbox.com/u/1947532/dbus-client_0.2/index.html Hackage is currently experiencing some dependency conflicts with the "bytestring" library[1], so it's not generating its own documentation. I'll keep the dropbox pages up until Hackage is in a more usable state. Downloads ========= Available from the usual places: http://hackage.haskell.org/packages/archive/dbus-core/0.6/dbus-core-0.6.tar… http://hackage.haskell.org/packages/archive/dbus-client/0.2/dbus-client-0.2… [1] "binary" uses bytestring-0.9.1.4, "text" uses bytestring-0.9.1.5, kaboom

2 3

How to understand such a `case` ?
by zaxis 08 Dec '09

08 Dec '09

findHelper (x:xs) = do -- not lazy, but that's not really important here filex <- fileExists (file x) filex' <- fileExists (file' x) case () of _ | filex -> return $ Just $ file x | filex' -> return $ Just $ file' x | otherwise -> findHelper xs file x = foldl1 joinFileName (x ++ [helper]) file' x = (file x) ++ (getConfig "exe_ext") Sincerely! ----- fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p2670… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 4