- Haskell-Cafe - Haskell.org

Re: Looking for pointfree version (Kim-Ee Yeoh) (02/12)
by Gene Arthur 20 Feb '09

20 Feb '09

>Kim-Ee Yeoh said: >On the same note, does anyone have ideas >for the following snippet? Tried the pointfree >package but the output was useless. >pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) First sorry for the delay in getting to this.. been behind on projects so had some days of mail piled up. Here is what I came up with, using one arrow operator, so you would have to import: Control.Arrow ((***)) at minimum to use this solution: pointfree :: forall t t1 c. (t -> t1 -> c) -> (t, t1) -> (t, t1) -> (c, c) pointfree op = curry $ (\(a,b) -> a `op` b) *** (\(a,b) -> a `op` b) examples of use, that were executed using: ghci -fglasgow-exts -farrows Control.Arrow *>pointfree (*) (3,5) (12,12) (15,144) *> pointfree (++) ("This ","That") ("Old"," Man") ("This That","Old Man") Hope that helps. -- gene ============================== website: http://haskblog.cloud.prohosting.com ============================== If Helen Keller is alone in a forest and falls, does she make a sound? ____________________________________________________________ Receive Notifications of Incoming Messages Easily monitor multiple email accounts & access them with a click. Visit http://www.inbox.com/notifier and check it out!

3 2

Re: [Haskell-cafe] Re: [darcs-users] darcs and Google Summer of Code
by Wolfgang Jeltsch 20 Feb '09

20 Feb '09

Am Donnerstag, 19. Februar 2009 05:10 schrieben Sie: > Wolfgang Jeltsch wrote: > > I’ve put myself as a potential mentor on the old Haskell SoC ticket > > (<http://hackage.haskell.org/trac/summer-of-code/ticket/17>). However, > > one or two years ago I was told that mentoring is a very time-consuming > > thing (and to my knowledge, you don’t get any payments for that, at least > > for Haskell projects). So if some other person wants to mentor a > > Grapefruit-based GUI or patch viewer project, I’d be very happy and would > > support this person the best I can. > > Unless Google's changed things, the organization gets 500$ for each > project. What the Darcs organization does with that, who knows. Yes, who knows. The “Haskell orgainization” didn’t give a cent to the mentors, as far as I know. Am I wrong here? > It'd be a piddling amount as a stipend for the mentor, but... …it would be much better than nothing. :-) Best wishes, Wolfgang

2 3

unresolved Liskell installation problems
by Benjamin L.Russell 20 Feb '09

20 Feb '09

I have been trying to install Liskell on top of GHC 6.10.1 on Windows XP Professional, Service Pack 2, since last month, but despite changes to the included Main.hs file and repeated exchanges on a related Weblog (see "CFruhwirth's Weblog: Liskell standalone" at http://blog.clemens.endorphin.org/2009/01/liskell-standalone.html) the problem is still unsolved. My last question was posted there on January 27, but there have been no further responses since then. In summary, here is a transcription of the related correspondence there: Posted by Clemens Fruhwirth on 9 January 2009 at 14:17: >[...] > >You can grab it with the usual > >darcs get http://code.haskell.org/liskell/ > > >This version has been tested with ghc 6.10.1 and should install like > >./Setup.lhs configure >./Setup.lhs build >./Setup.lhs install >cd LskPrelude >make install-inplace > >Optionally you can run make tests in the testsuite subdirectory. Posted by Benjamin Russell on 21 January 2009 at 23:27: >I just downloaded Darcs 2.2 and Liskell for Windows XP, Service Pack 2, but the following error message appeared when I ran: > >./Setup.lhs configure > >in Cygwin: > >Configuring liskell-0.1... >Setup.lhs: At least the following dependencies are missing: >ghc-paths -any > >How should I resolve this issue? Posted by ctnd on 23 January 2009 at 23:48: >[...] > >Perhaps install this package: >http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths Posted by ctnd on 24 January 2009 at 00:04: > Okay, I got Liskell running and compiling here with a couple of changes: > >In Main.hs, change: > >-- GHC.runGhc (Just "/home/clemens/deploy/ghc-6.10.1/lib/ghc-6.10.1/") $ do >GHC.runGhc (Just "/home/chris/.GHC/lib/ghc-6.10.1/") $ do > >To the appropriate value as I have. > >./Setup.lhs configure --user >./Setup.lhs build >./Setup.lhs install > >$ cd LskPrelude/ >$ make >$ make install-inplace > >Couldn't really get the tests working but I don't much care about that right now, just want to play with Liskell. > >Hope you guys figure it out! Posted by Benjamin Russell on 25 January 2009 at 20:51: >[...] > >Thanks for the advice, but: > >> In Main.hs, change: >> >> -- GHC.runGhc (Just "/home/clemens/deploy/ghc-6.10.1/lib/ghc-6.10.1/") $ do >> GHC.runGhc (Just "/home/chris/.GHC/lib/ghc-6.10.1/") $ do > >Done. However, the building step still fails: > >> $ ./Setup.lhs build >> Preprocessing library liskell-0.1... >> Setup.lhs: The program happy is required but it could not be found > >But "happy" is installed and listed in the PATH! > >> $ which happy >> /cygdrive/c/Program Files/Haskell/bin/happy > >> Perhaps install this package: >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths > >Already installed; _viz_: > >> $ cabal install ghc-paths >> Resolving dependencies... >> No packages to be installed. All the requested packages are already installed. >> If you want to reinstall anyway then use the --reinstall flag. > >How should I resolve this issue? Posted by ctnd on 27 January 2009 at 07:28: >[...] > >I had the same problem: > >Configuring liskell-0.1... >Setup.lhs: At least the following dependencies are missing: >ghc-paths -any > >I solved it by configuring as --user. I should've done this from the start as my GHC and cabal packages are all --user installed anyway. > >./Setup.lhs configure --user >./Setup.lhs build >./Setup.lhs install > >Hopefully it's the same for you. > >RE the `happy` problem, no idea. > [...] > >P.S. I saw your question on the mailing list but I'm unable to post to the list (despite asking for help from the admins) so I'll have to respond here. Posted by Benjamin Russell on 27 January 2009 at 21:59: >[...] > >Thanks again for the response. > >This time, a parse error occurs in the building phase: > >> Main.hs:218:0: parse error (possibly incorrect indentation) > >These are lines 218-19 of my Main.hs file: > >> partition_args :: [String] -> [(String, Maybe Phase)] -> [String] >> -> ([(String, Maybe Phase)], [String]) > >I tried merging line 219 into line 218, but the same error recurs. > >In addition, the following error occurs during the install phase: > >>Setup.lhs: dist\build\liskell\liskell.exe: copyFile: does not exist (No such file or directory) > >Sorry for the repeated questions, but would you happen to know how to resolve these issues? Does anybody know how to install Liskell successfully? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

1 0

Overloading functions based on arguments?
by Daniel Kraft 20 Feb '09

20 Feb '09

Hi, I just came across a problem like this: Suppose I've got two related functions that do similar things, and I want to call them the same... Like in: foobar :: String -> Int -> Int foobar :: Int -> String -> Int (Bad example, but I hope you got the point.) Is this kind of overloading (instead of the polymorphism based overloading) possible in Haskell? Namely to have two functions with the same name but different signatures so they could be distinguished by a call's parameters? I fear not... So I guess I have to name the functions differently, right? Thanks, Daniel

21 48

garbage collector woes
by Chris Waterson 20 Feb '09

20 Feb '09

I'm at wits end with respect to GHC's garbage collector and would very much appreciate a code review of my MySQL driver for HDBC, which is here: <http://www.maubi.net/~waterson/REPO/HDBC-mysql/Database/HDBC/MySQL/Connecti… > In particular, the problem that I'm having is that my "statements" (really, just iterators over a SQL query result set) are getting garbage collected prematurely. I've included the source for the relevant functions below. The first is newStatement, which creates a new HDBC Statement record (an elided version, below): > newStatement :: ForeignPtr MYSQL -> String -> IO Types.Statement > newStatement mysql__ query = withForeignPtr mysql__ $ \mysql_ -> do > stmt_ <- mysql_stmt_init mysql_ > ... > stmt__ <- newForeignPtr mysql_stmt_close stmt_ > ... > return $ Types.Statement > { > , Types.fetchRow = fetchRow mysql__ stmt__ results > } The mysql_stmt_init function is the MySQL C API that creates a new statement record. Its result must be freed by mysql_stmt_close, and therefore is wrapped with a ForeignPtr appropriately. The fetchRow function is part of the HDBC Statement API, and its signature is: > fetchRow :: IO (Maybe [SqlValue]) I.e., it retrieves the next row from the result set and returns the column values as a list. The "results" parameter is not relevant to this discussion: it maintains the buffers used for storage of the column values. The next function of interest is my implementation of fetchRow, copied in its entirety, below: > fetchRow :: ForeignPtr MYSQL -> ForeignPtr MYSQL_STMT -> [MYSQL_BIND] > -> IO (Maybe [Types.SqlValue]) > fetchRow mysql__ stmt__ results = > withForeignPtr mysql__ $ \_ -> > withForeignPtr stmt__ $ \stmt_ -> do > rv <- mysql_stmt_fetch stmt_ > case rv of > 0 -> row > #{const MYSQL_DATA_TRUNCATED} -> row > #{const MYSQL_NO_DATA} -> return Nothing > _ -> statementError stmt_ > where row = mapM cellValue results >>= \cells -> return $ Just cells It unwraps the ForeignPtrs and invokes the mysql_stmt_fetch C API with the native MYSQL_STMT structure, causing the column values for the next row to get bound into storage areas that we can convert to Haskell values. Typically, this code gets invoked in the generic HDBC layer by the fetchAllRows routine, which looks like this: > fetchAllRows :: Statement -> IO [[SqlValue]] > fetchAllRows sth = unsafeInterleaveIO $ > do row <- fetchRow sth > case row of > Nothing -> return [] > Just x -> do remainder <- fetchAllRows sth > return (x : remainder) The sth argument is simply an instance of the Statement record that I've returned from low-level MySQL driver. This all works, except... The behavior that I'm seeing is that the ForeignPtr to the native MYSQL_STMT struct has become unreachable after some number of iterations of the above loop. This causes mysql_stmt_close to be invoked, and subsequent calls to mysql_stmt_fetch fail with an error. Curiously, if I replace > stmt__ <- newForeignPtr mysql_stmt_close stmt_ with > stmt__ <- newForeignPtr_ stmt_ in my newStatement routine (i.e., so that mysql_stmt_close is never called), then fetchAllRows will merrily fetch all the rows from my statement handle. The down side, of course, being that I'll leak statement handles. So, I'm completely puzzled as to how I can continue to extract values from the apparently unreachable pointer! Using System.Mem.Weak, I've verified that: * The Statement record that I return from newStatement becomes unreachable. * The applied value of fetchRow becomes unreachable; e.g.: let r = fetchRow mysql__ stmt__ results addFinalizer r $ putStrLn "r is unreachable!" I'm not sure how this can be, given that fetchAllRows appears to be explicitly maintaining a reference to sth, which in turn ought to reference my fetchRow application. I've created a test program that directly invokes my driver code the same way that the generic HDBC layer does, and have verified that the lack of "-fno-cse" with unsafeInterleaveIO in the generic HDBC module is not relevant. I was similarly able to verify that this problem occurs with "-O0", so it's not due to any particular GHC optimization. Any thoughts on how to debug this would be greatly appreciated! Thanks in advance, chris

2 3

Re: [Haskell-cafe] How to create an online poll
by gregg reynolds 19 Feb '09

19 Feb '09

See also www.surveymonkey.com Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: >Hello haskell-cafe, > >http://zohopolls.com/ > >-- >Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe

10 10

ANNOUNCE: Cabal-1.6.0.2 and cabal-install-0.6.2
by Duncan Coutts 19 Feb '09

19 Feb '09

I'm pleased to announce point-releases of the Cabal library and the cabal-install command line tool. If you are already using cabal-install then you can upgrade both using: $ cabal update $ cabal install Cabal cabal-install New users you can get it from: http://haskell.org/cabal/download.html For users on unix systems there is a source tarball with a bootstrap script. For users on Windows systems there is a pre-compiled cabal.exe. Release notes ============= Cabal-1.6.0.2 ------------- This is a point-release in the stable 1.6.x series. It is expected that this release will be included with ghc-6.10.2. It has a number of fixes and minor improvements. The most noticeable change is that Cabal now checks at configure time that C libraries and header files are available. This is known to break a small number of packages. The maintainers of these packages have been notified. Changes since 1.6.0.1: * New configure-time check for C headers and libraries * Added language extensions present in ghc-6.10 * Added support for NamedFieldPuns extension in ghc-6.8 * Fix in configure step for ghc-6.6 on Windows * Fix warnings in Path_pkgname.hs module on Windows * Fix for exotic flags in ld-options field * Fix for using pkg-config in a package with a lib and an executable * Fix for building haddock docs for exes that use the Paths module * Fix for installing header files in subdirectories * Fix for the case of building profiling libs but not ordinary libs * Fix read-only attribute of installed files on Windows * Ignore ghc -threaded flag when profiling in ghc-6.8 and older cabal-install-0.6.2 ------------------- This release contains a number of incremental improvements, including some new features. We expect to do another 0.6.x release in the not too distant future focusing on improvements in the way package dependencies are selected. Changes since 0.6.0: * The upgrade command has been disabled in this release * The configure and install commands now have consistent behaviour * Reduce the tendency to re-install already existing packages * The --constraint= flag now works for the install command * New --preference= flag for soft constraints / version preferences * Improved bootstrap.sh script, smarter and better error checking * New cabal info command to display detailed info on packages * New cabal unpack command to download and untar a package * HTTP-4000 package required, should fix bugs with http proxies * Now works with authenticated proxies. * On Windows can now override the proxy setting using an env var * Fix compatibility with config files generated by older versions * Warn if the hackage package list is very old * More helpful --help output, mention config file and examples * Better documentation in ~/.cabal/config file * Improved command line interface for logging and build reporting * Minor improvements to some messages Changes since 0.5.2: * Constraint solver can now cope with base 3 and base 4 * Allow use of package version preferences from hackage index * More detailed output from cabal install --dry-run -v * Improved bootstrap.sh Bugs and feature requests ========================= This is an excellent opportunity to make sure your favourite bug or feature request is properly described in our bug tracker: http://hackage.haskell.org/trac/hackage/ To help us guide development priorities please add yourself to the ticket's cc list and describe why that bug or feature is important to you. Credits ======= On behalf of the Cabal hackers and the community generally I'd like to thank the people who have contributed patches for these releases: * Gleb Alexeyev * Samuel Bronson * Thomas Schilling * Ganesh Sittampalam * Andrea Vezzosi Get involved ============ There's still a lot to do! We have big plans for Cabal-2.0, cabal-install and the Hackage website. So if you're interested in helping out with this core infrastructure project then: * subscribe to the cabal-devel mailing list: http://www.haskell.org/mailman/listinfo/cabal-devel * grab the source: http://haskell.org/cabal/code.html * read the guide to the source code: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide * take a look at our list of bugs and feature requests: http://hackage.haskell.org/trac/hackage/report/12 especially the easy tickets: http://hackage.haskell.org/trac/hackage/report/13 Duncan

1 0

Uses of `fix' combinator
by Khudyakov Alexey 19 Feb '09

19 Feb '09

Hello, While browsing documentation I've found following function > -- | @'fix' f@ is the least fixed point of the function @f@, > -- i.e. the least defined @x@ such that @f x = x@. > fix :: (a -> a) -> a > fix f = let x = f x in x I have two questions. How could this function be used? I'm unable to imagine any. Naive approach lead to nothing (no surprise): Prelude Data.Function> fix (^^2) <interactive>: out of memory (requested 2097152 bytes) Second question what does word `least' mean?`a' isn't an Ord instance. -- Khudyakov Alexey

5 5

Re[2]: Ready for testing: Unicode support for Handle I/O
by Bulat Ziganshin 19 Feb '09

19 Feb '09

Hello Khudyakov, Thursday, February 19, 2009, 4:06:06 PM, you wrote: >> i think that FilePath=String is ok, we just need to use utf8 string >> encoding on unix/macs and utf-16 encoding with *W functions on >> Windows. i have implemented such support inside my own application, and >> would be happy to mentor appropriate gsoc project > It won't _always_ work. current solution works never :) > And there are still 8-bit locales lurking somewhere in bush. UTF8 isn't > appropriate for them at all. i think that SetFilenameEncoding whould solve this, among with access to lower-level openFileUsingCStringPath -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Ready for testing: Unicode support for Handle I/O
by Simon Marlow 19 Feb '09

19 Feb '09

I've been working on adding proper Unicode support to Handle I/O in GHC, and I finally have something that's ready for testing. I've put a patchset here: http://www.haskell.org/~simonmar/base-unicode.tar.gz That is a set of patches against a GHC repo tree: unpack the tarball, and say 'sh apply /path/to/ghc/repo' to apply all the patches. Then clean your tree and build it from scratch (or if you're using the new GHC build system, just say 'make' ;-). It should validate, bar one or two minor failures. Oh, it doesn't work on Windows yet. That's the major thing left to do. If anyone else felt like tackling this I'd be delighted: all you have to do is implement a Win32 equivalent of the module GHC.IO.Encoding.Iconv (see below), everything else should work unchanged. Depending on whether any further changes are required, I may amend-record some of these patches, so treat them as temporary patches for testing only. Below is what will be the patch description in the patch for libraries/base. Comments/discussion please! Cheers, Simon Unicode-aware Handles ~~~~~~~~~~~~~~~~~~~~~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing encoding of the system. Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: hSetEncoding :: Handle -> TextEncoding -> IO () and various encodings: latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). Currently hSetEncoding is availble from GHC.IO.Handle, and the encodings are available from GHC.IO.Encoding. We may want to export these from somewhere more permanent; that's something for a library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance is about 30% slower on "hGetContents >>= putStr" than before. I've profiled it, and about 25% of this is in doing the actual encoding/decoding, the rest is accounted for by the fact that we're shuffling around 32-bit chars rather than bytes in the Handle buffer, so there's not much we can do to improve this. IO library restructuring ~~~~~~~~~~~~~~~~~~~~~~~~ The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) => dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' -> FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. -> IOMode -- ^ The mode in which the 'Handle' is to be used -> Maybe TextEncoding -- ^ text encoding to use, if any -> IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated warnings. I split modules into smaller parts in many places. For example, we now have GHC.IORef, GHC.MVar and GHC.IOArray containing the implementations of IORef, MVar and IOArray respectively. This was necessary for untangling dependencies, but it also makes things easier to follow. The new module structurue for the IO-relatied parts of the base package is: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc.

7 15