Re: [Haskell-cafe] Link errors in Gtk2Hs are more general than I thought.
> "Jeff" == Jeff Wheeler writes: Jeff> I installed Gtk2Hs on a similar machine earlier tonight, Jeff> with much success, even with Yi. Jeff> I did not use MacPorts, and instead followed the Jeff> instructions on the HaskellWiki [1] under "Using the GTK+ OS Jeff> X Framework" (including compiling pkg-config from src). I'm Jeff> not sure how having attempted the installation through Jeff> MacPorts may have littered your system, unfortunately. A lot I think (I tried the Framework install once, and spent a LOT of time cleaning up, and the same when I reverted macports). -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trying to download "leksah" ....
Vasili I. Galchin wrote: > vigalc...@ubuntu:~/FTP$ darcs get http://code.haskell.org/leksah > Invalid repository: http://code.haskell.org/leksah > > darcs failed: Failed to download URL > http://code.haskell.org/leksah/_darcs/inventory : HTTP error (404?) > > I did a google on "HTTP 404" => not found why? It's a darcs 2 repository, so you'll need to install darcs 2. See http://code.haskell.org/leksah/_darcs/format Admittedly, the error message is horrible. HTH, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Link errors in Gtk2Hs are more general than I thought.
On Sun, 2009-04-05 at 07:12 +0200, Bertram Felgenhauer wrote: > This looks like the quartz backend was disabled in the cairo C library, > not like a gtk2hs problem. I don't know how ports work, but > > http://trac.macports.org/browser/trunk/dports/graphics/cairo/Portfile > > defines a 'quartz' variant that enables that backend. Another idea is > to reinstall pango. I installed Gtk2Hs on a similar machine earlier tonight, with much success, even with Yi. I did not use MacPorts, and instead followed the instructions on the HaskellWiki [1] under "Using the GTK+ OS X Framework" (including compiling pkg-config from src). I'm not sure how having attempted the installation through MacPorts may have littered your system, unfortunately. After that installation has succeeded, compiling Yi normally and running `yi -fpango` to launch the GTK UI should work. Earlier tonight, though, I reported an issue that causes only the first line of any buffer in the Pango Yi UI to be visible [2], which makes this much less useful. Jeff Wheeler [1] http://www.haskell.org/haskellwiki/Gtk2Hs [2] http://code.google.com/p/yi-editor/issues/detail?id=261 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] trying to download "leksah" ....
vigalc...@ubuntu:~/FTP$ darcs get http://code.haskell.org/leksah Invalid repository: http://code.haskell.org/leksah darcs failed: Failed to download URL http://code.haskell.org/leksah/_darcs/inventory : HTTP error (404?) I did a google on "HTTP 404" => not found why? Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Link errors in Gtk2Hs are more general than I thought.
Jeff Heard wrote: > I tried to get yi to run on my Mac earlier and I get the following errors: > > dyld: lazy symbol binding failed: Symbol not found: > _cairo_quartz_font_face_create_for_atsu_font_id > Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib > Expected in: /opt/local/lib/libcairo.2.dylib > > dyld: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id > Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib > Expected in: /opt/local/lib/libcairo.2.dylib This looks like the quartz backend was disabled in the cairo C library, not like a gtk2hs problem. I don't know how ports work, but http://trac.macports.org/browser/trunk/dports/graphics/cairo/Portfile defines a 'quartz' variant that enables that backend. Another idea is to reinstall pango. HTH, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 112 - April 5, 2009
--- Haskell Weekly News http://sequence.complete.org/hwn/20090405 Issue 112 - April 05, 2009 --- Welcome to issue 112 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements hgettext-0.1.5 - GetText based internationalization of Haskell programs. Vasyl Pasternak [2]announced a new release of the [3]hgettext package for internationalization of Haskell programs, which now supports distribution and installation of PO files. Buster 0.99.1, a library for application orchestration that is not FRP. Jeff Heard [4]announced the release of [5]Buster, an FRP-like framework for constructing reactive programs with a bus model. Call for Contributions - Haskell Communities and Activities Report, May 2009 edition. Janis Voigtlaender [6]issued a call for contributions to the 16th edition of the [7]Haskell Communities & Activities Report. The submission deadline is 1 May 2009. If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! fad 1.0 -- Forward Automatic Differentiation library. Bjorn Buckwalter [8]announced the initial release of the Haskell [9]fad library, developed by Barak A. Pearlmutter and Jeffrey Mark Siskind. Fad provides Forward Automatic Differentiation (AD) for functions polymorphic over instances of 'Num'. hledger 0.4 released. Simon Michael [10]announced the release of [11]hledger 0.4, a text-mode double-entry accounting tool. It reads a plain text journal file describing your transactions and generates precise activity and balance reports. Changes include the ability to serve reports in a web browser, and many other fixes and improvements. GHC version 6.10.2. Ian Lynagh [12]announced a new patchlevel release of [13]GHC. This release contains a number of bugfixes relative to 6.10.1, including some performance fixes; see the [14]release notes. Beta of Leksah IDE available. Jürgen Nicklisch-Franken [15]announced release 0.4.4 of [16]Leksah, the Haskell IDE written in Haskell. Current features include on the fly error reporting with location of compilation errors, completion , import helper for constructing import statements, module browser with navigation to definition, project management support based on Cabal with a visual editor, "source candy", and more. satchmo: monadic SAT encoding library. Johannes Waldmann [17]announced a preliminary version of [18]satchmo, a monadic library for encoding boolean and integral number constraints to CNF-SAT. It uses [19]minisat as a backend solver. vacuum-cairo: a cairo frontend to vacuum for live Haskell data visualization. Don Stewart [20]announced the release of [21]vacuum-cairo, a Haskell library for interactive rendering and display of values on the GHC heap using Matt Morrow's vacuum library. This library takes vacuum's output, generates dot graph format from it, renders it to SVG with graphviz, and displays the resulting structure using the gtk2hs Cairo vector graphics bindings ... all at the GHCi command line. Watch some [22]screencasts! vacuum: extract graph representations of ghc heap values.. Matt Morrow [23]announced the release of [24]vacuum, a library for extracting graph representations of values from the GHC heap, which may then be further processed and/or translated to Graphviz dot format to be visualized. new release of HTTP, version 4000.0.5. Sigbjorn Finne [25]announced a [26]new version of the HTTP package, which includes a bunch of fixes and cleanups along with some API documentation. type-level programming support library. spoon [27]asked for feedback on a [28]support library for type level programming. cmonad 0.1.1. Lennart Augustsson [29]announced the [30]CMonad package, which allows one to write Haskell code in a C style. Marketing Haskell. Ketil "Simon Peyton-Jones" Malde [31]announced the new [32]official Haskell mascot. Haskell Platform: status update and call for volunteers. Duncan Coutts gave an [33]update on the status of the [34]Haskell Platform. There are no more policy questions to resolve for the first release. It is a matter of getting things done. The first platform release will contain ghc-6.10.2, the "extra libs", haddock, happy and alex, and the cabal command line tool and it's dependencies. We are calling for volunteers for an action group. We need volunteers to take charge of various platforms and to manage the overall release. See Duncan's email for a list of what is needed, and volunteer! Blog noise [35]Haskell news from the [36]b
Re: [Haskell-cafe] Combining sequences
Thanks, guys! This one works perfectly. I was monkeying with similar logic but wasn't sure about syntax. Michael --- On Sat, 4/4/09, Andrew Wagner wrote: From: Andrew Wagner Subject: Re: [Haskell-cafe] Combining sequences To: "michael rice" Cc: haskell-cafe@haskell.org Date: Saturday, April 4, 2009, 8:56 PM Here's a pretty straightforward approach: combine [] ys = ys combine xs [] = xs combine (x:xs) (y:ys) | x <= y = x : combine xs (y:ys) | otherwise = y : combine (x:xs) ys On Sat, Apr 4, 2009 at 8:40 PM, michael rice wrote: Is there a simple way to combine two sequences that are in ascending order into a single sequence that's also in ascending order? An example would be the squares [1,4,9,16,25..] combined with the cubes [1,8,27,64,125..] to form [1,1,4,8,9,16,25,27..]. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Reverting to any old version using Darcs
Henning Thielemann writes: > On Wed, 1 Apr 2009, Don Stewart wrote: > >> bugfact: >>> Rumor goes that this is very difficult to do with Darcs. Is this correct? >> >>darcs unpull > > Be careful - you cannot revert this! If you want to unpull patches, > that were not distributed so far, you should better call 'darcs get' > to get a copy of the repository and then run 'darcs unpull' in this > copy. For the record, unpull is now called "obliterate", and "unpull" is an alias for it. This new name is meant to instill caution in the user :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Combining sequences
Here's a pretty straightforward approach: combine [] ys = ys combine xs [] = xs combine (x:xs) (y:ys) | x <= y = x : combine xs (y:ys) | otherwise = y : combine (x:xs) ys On Sat, Apr 4, 2009 at 8:40 PM, michael rice wrote: > Is there a simple way to combine two sequences that are in ascending order > into a single sequence that's also in ascending order? An example would be > the squares [1,4,9,16,25..] combined with the cubes [1,8,27,64,125..] to > form [1,1,4,8,9,16,25,27..]. > > Michael > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Combining sequences
Is there a simple way to combine two sequences that are in ascending order into a single sequence that's also in ascending order? An example would be the squares [1,4,9,16,25..] combined with the cubes [1,8,27,64,125..] to form [1,1,4,8,9,16,25,27..]. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: fad 1.0 -- Forward Automatic Differentiation library
On Thu, 2 Apr 2009, Bjorn Buckwalter wrote: I'm pleased to announce the initial release of the Haskell fad library, developed by Barak A. Pearlmutter and Jeffrey Mark Siskind. Fad provides Forward Automatic Differentiation (AD) for functions polymorphic over instances of 'Num'. There have been many Haskell implementations of forward AD, with varying levels of completeness, published in papers and blog posts[1], but alarmingly few of these have made it into hackage -- to date Conal Elliot's vector-spaces[2] package is the only one I am aware of. Do you count computations with power series also as Automatic Differentiation? I mean, arithmetic on power series is just working with all derivatives simultaneously. with Haskell 98 type classes: http://darcs.haskell.org/htam/src/PowerSeries/Taylor.hs with advanced type classes: http://hackage.haskell.org/packages/archive/numeric-prelude/0.0.5/doc/html/MathObj-PowerSeries.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement: Beta of Leksah IDE available
On Fri, 3 Apr 2009, Jeff Heard wrote: Jurgen... I have one more question, or rather request... I'm running under Ubuntu, and I get inconsistencies with packages that I build and install via Leksah not showing up when I configure other packages that depend on them. Then I notice that you're using runhaskell Setup.lhs ... to configure build and install. I wonder if you could change all that from "runhaskell Setup.lhs" to "cabal" wherever you run it? I think 'cabal' has more dependencies (zlib, HTTP) and is thus more difficult to port than Setup.lhs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reverting to any old version using Darcs
On Wed, 1 Apr 2009, Don Stewart wrote: bugfact: Rumor goes that this is very difficult to do with Darcs. Is this correct? darcs unpull Be careful - you cannot revert this! If you want to unpull patches, that were not distributed so far, you should better call 'darcs get' to get a copy of the repository and then run 'darcs unpull' in this copy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: .editrc
brad clawsie wrote: > does anyone have a .editrc they can provide that allows ghci to be used > on freebsd? > > i'm not looking for anything fancy, just backspace not being broken etc You could try to cabal install ghci-haskeline and see if that works better. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System.Process.Posix
cristiano.paris: > On Sat, Apr 4, 2009 at 10:21 PM, Bulat Ziganshin > wrote: > > Hello Cristiano, > > ... > > there was a large thread a few months ago and many peoples voted for > > excluding any OS-specific packages at all since this decreases > > portability of code developed by Hoogle users :))) > > Nice shot :D > > So how do I fork a new system process ? Thank you folks. Isn't this the goal of the process package? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/process -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System.Process.Posix
On Sat, Apr 4, 2009 at 10:21 PM, Bulat Ziganshin wrote: > Hello Cristiano, > ... > there was a large thread a few months ago and many peoples voted for > excluding any OS-specific packages at all since this decreases > portability of code developed by Hoogle users :))) Nice shot :D So how do I fork a new system process ? Thank you folks. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System.Process.Posix
Hello Cristiano, Sunday, April 5, 2009, 12:05:02 AM, you wrote: > Is it me or the above package is not included in Hoogle? afair, Neil, being windows user, includes only packages available for his own system there was a large thread a few months ago and many peoples voted for excluding any OS-specific packages at all since this decreases portability of code developed by Hoogle users :))) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Link errors in Gtk2Hs are more general than I thought.
I tried to get yi to run on my Mac earlier and I get the following errors: dyld: lazy symbol binding failed: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib Expected in: /opt/local/lib/libcairo.2.dylib dyld: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib Expected in: /opt/local/lib/libcairo.2.dylib Trace/BPT trap The commands I used to install gtk2hs (which gave me no errors were) $ sudo port selfupdate $ sudo port install gtk2 cairo librsvg libglade2 gtksourceview2 gtkglext $ sudo port install gtk-chtheme gtk2-clearlooks && sudo port -k install ghc gtk2hs hs-cabal $ cabal install yi Running OS X 10.5.6 (Leopard) on a MacBook 2.4 gHz Core 2 Duo -- Jeff -- Forwarded message -- From: Jeff Heard Date: Sat, Apr 4, 2009 at 2:01 PM Subject: Leksah+Gtk2Hs link error on Mac OS X Leopard To: Haskell Cafe I tried installing leskah on OS X using the x11 version of gtk2hs (because I use gtkglext a lot in my work, and need it, therefore the quartz build won't work for me) I get these errors. Is this leksah specific or is this a more general problem with gtk2hs? Linking dist/build/leksah/leksah ... ld warning: atom sorting error for _ghczm6zi10zi1_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1_LibFFI_Czuffizucif_closure_tbl in /opt/local/lib/ghc-6.10.1/ghc-6.10.1/libHSghc-6.10.1.a(LibFFI.o) ld warning: atom sorting error for _ghczm6zi10zi1_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1_LibFFI_Czuffizucif_closure_tbl in /opt/local/lib/ghc-6.10.1/ghc-6.10.1/libHSghc-6.10.1.a(LibFFI.o) $ ~/.cabal/bin/leksah dyld: lazy symbol binding failed: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib Expected in: /opt/local/lib/libcairo.2.dylib dyld: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib Expected in: /opt/local/lib/libcairo.2.dylib Trace/BPT trap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System.Process.Posix
Is it me or the above package is not included in Hoogle? Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First time I've gotten gtk2hs to install from ports on Mac OS X from scratch
On Sat, Apr 4, 2009 at 12:15 PM, Jason Dagit wrote: > I think people might be able to help you, but I think we need the > exact error message. Unfortunately, "won't link" is a bit too vague > to make any suggestions. Nevermind my message. I see you sent the error in a different thread. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First time I've gotten gtk2hs to install from ports on Mac OS X from scratch
Hi Jeff, On Sat, Apr 4, 2009 at 10:57 AM, Jeff Heard wrote: > The instructions in the leksah manuals seem to work for doing a > straight-up ports install of gtk2hs. I've never managed to get it to > install without compiling manually, but this worked > > $ sudo port install gtk2 cairo librsvg libglade2 gtksourceview2 > gtkglext gtk-chtheme gtk2-clearlooks > $ sudo port -k install ghc gtk2hs hs-cabal > > Unfortunately leksah itself won't link... I think people might be able to help you, but I think we need the exact error message. Unfortunately, "won't link" is a bit too vague to make any suggestions. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Leksah+Gtk2Hs link error on Mac OS X Leopard
I tried installing leskah on OS X using the x11 version of gtk2hs (because I use gtkglext a lot in my work, and need it, therefore the quartz build won't work for me) I get these errors. Is this leksah specific or is this a more general problem with gtk2hs? Linking dist/build/leksah/leksah ... ld warning: atom sorting error for _ghczm6zi10zi1_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1_LibFFI_Czuffizucif_closure_tbl in /opt/local/lib/ghc-6.10.1/ghc-6.10.1/libHSghc-6.10.1.a(LibFFI.o) ld warning: atom sorting error for _ghczm6zi10zi1_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1_LibFFI_Czuffizucif_closure_tbl in /opt/local/lib/ghc-6.10.1/ghc-6.10.1/libHSghc-6.10.1.a(LibFFI.o) $ ~/.cabal/bin/leksah dyld: lazy symbol binding failed: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib Expected in: /opt/local/lib/libcairo.2.dylib dyld: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib Expected in: /opt/local/lib/libcairo.2.dylib Trace/BPT trap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] First time I've gotten gtk2hs to install from ports on Mac OS X from scratch
The instructions in the leksah manuals seem to work for doing a straight-up ports install of gtk2hs. I've never managed to get it to install without compiling manually, but this worked $ sudo port install gtk2 cairo librsvg libglade2 gtksourceview2 gtkglext gtk-chtheme gtk2-clearlooks $ sudo port -k install ghc gtk2hs hs-cabal Unfortunately leksah itself won't link... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be "too smart"
Thanks Claus, Indeed the problem was that I was using the Strict state monad, with lazy state it does the right thing when run through testP. I will try and get back to this thread if I manage the derivation which "proves" (or at least supports) that the two versions are equivalent. 2009/4/4 Claus Reinke : >> takeListSt' = evalState . foldr k (return []) . map (State . splitAt) >> where k m m' = cutNull $ do x<-m; xs<-m'; return (x:xs) >> cutNull m = do s<-get; if null s then return [] else m > > |Not only is ths not that elegant anymore, > As I was saying, sequence/mapM with early cutout is common > enough that one might want it in the libraries, which would return > this variant into readability again. > > |I think it *still* has a bug, stack overflow against > > That would really surprise me. Not that it is impossible - as I was > also saying, I haven't replayed the derivation for the modified code. > However, the modification was arrived at by taking the original > derivation, seeing where its result deviated from the explicitly > recursive specification, and spotting the aspect of the implicitly > recursive version that was responsible for the deviation. > Of course, the derivation itself could have an error, but equating the > functions themselves gives me rather more confidence/coverage than any > finite number of tests could. If I were to enter the derivation > into a proof checking tool and be successful, that would further raise > the level of confidence/coverage (leaving bugs in the proof checker). > > Note that I'm not asking whether the original spec did the "right" > thing, only whether or not the variations "correctly" do the same > thing as the original spec. > > |testP pf = mapM_ putStrLn [ > | show $ take 5 $ pf (repeat 0) [1,2,3] > | , show $ pf ( take 1000 [3,7..] ) [1..100] > | , show . pf [3,7,11,15] $ ( take (10^6) [1..]) > | , show . head . last $ pf (take 1000 $ [3,3..]) [1..10^6] > | ] > | > |where the first test (with take 5) is new. > |whereas the version with explicit recursion and pattern matching > |doesn't suffer from this problem > > I get identical results for 'takeListSt'' and the original 'takeList1' > (code repeated below). > It took me a couple of moments to remember that you had been playing with > Control.Monad.State.Strict instead of the default > Control.Monad.State(.Lazy). That would invalidate the original derivation > (different definition of '>>=', therefore a different end result after > unfolding '>>='), let alone the modified code based on it. > If you replay the derivation, taking the strictness variations into account, > you should arrive at an explicitly recursive version that > differs from the spec. Which might make it easier to see what > the difference is. > > |partitions [] xs = [] > |partitions (n:parts) xs = > | let (beg,end) = splitAt n xs > | in beg : ( case end of > | [] -> [] > | xs -> partitions parts xs) > > That version cannot be transformed into the original spec, because > it doesn't define the same function. As I mentioned: > >> (btw, both 'takeListSt'' and 'takeListSc'' pass Thomas' 'testP', as does >> his 'partitions', but 'partitions' is not the same function as 'takeList': >> consider 'null $ takeList [1] undefined' and 'takeList [0] []' ;-) > > With the original spec > > takeList1 [] _ = [] > takeList1 _ [] = [] > takeList1 (n : ns) xs = h : takeList1 ns t > where (h, t) = splitAt n xs > > and 'takeList4' being your 'partitions', we get: > > *Main> null $ takeList1 [1] undefined > *** Exception: Prelude.undefined > *Main> null $ takeList4 [1] undefined > False > *Main> takeList1 [0] [] > [] > *Main> takeList4 [0] [] > [[]] > >> I am starting to think that the tricky part in all these functions is >> that by using higher order functions from the prelude, you sweep the >> failure case under the rug. > > Yes, the reason that more abstract functions are useful is that they > hide irrelevant details, allowing us to spend our limited capacity on > relevant details. If all abstract functions happen to hide details that > matter, more concrete functions that expose those details can be more > helpful. > But even that has to be qualified: for instance, at first I found it easier > to see the issues with the original 'State' variant in its transformed, > explicitly recursive version, but after the derivation had convinced me that > there was no magic going on, I realized that it was just the old 'mapM' > doesn't stop early issue. So I could have seen the issue in the abstract > form, but my mind (and apparently other minds, too;-) refused to think about > the cornercases there until prompted. > If not for this tendency to ignore details that might be relevant, the > abstract code would provide an abstract treatment of the failure case as > well: instead of working out the details by trying to find useful tests for > the explic
Re: [Haskell-cafe] happstack example code wanted
Copied there. On Sat, Apr 4, 2009 at 1:30 PM, Thomas Hartman wrote: > Johannes, > > You'll have a better response if you post to the happs list. > > Have you had a look at tutorial.happstack.com? > > Thomas. > > 2009/4/4 Johannes Waldmann : > > Hi, I'm thinking of using happstack for a simple > > online registration system. [ Customer gives > > Name and Address and registers for certain workshops. > > Then the app server should just produce a bill. > > (Payment is handled through a different channel.) > > The "store owner" needs to get some overview of > > registrations. ] According to happs(tack) marketing > > department, this should be an easy exercise? > > Any code that I could use as a starting point? > > ( Or, if you do the coding, I can link to you from > > the workshop site. But I don't have a serious budget :-) > > Thanks - J.W. > > > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] happstack example code wanted
Johannes, You'll have a better response if you post to the happs list. Have you had a look at tutorial.happstack.com? Thomas. 2009/4/4 Johannes Waldmann : > Hi, I'm thinking of using happstack for a simple > online registration system. [ Customer gives > Name and Address and registers for certain workshops. > Then the app server should just produce a bill. > (Payment is handled through a different channel.) > The "store owner" needs to get some overview of > registrations. ] According to happs(tack) marketing > department, this should be an easy exercise? > Any code that I could use as a starting point? > ( Or, if you do the coding, I can link to you from > the workshop site. But I don't have a serious budget :-) > Thanks - J.W. > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: logfloat 0.12.0.1
Indeed. I recommend upgrading to GHC 6.10.2, all the weird floating point FFI bugs I encountered with GHC 6.10.1 seem to be resolved now. On Sat, Apr 4, 2009 at 12:10 PM, Bulat Ziganshin wrote: > Hello wren, > > Saturday, April 4, 2009, 2:51:39 AM, you wrote: > > > On GHC 6.10 the use of -fvia-C had to be disabled because it conflicts > > with the FFI (version 0.12.0.0 still used it, which is fine on GHC 6.8). > > I'm still investigating the use of -fasm and getting proper benchmarking > > numbers. Contact me if you notice significant performance degradation. > > isn't this the same bug as in recent thread "[Haskell-cafe] Possible > floating point bug in GHC?" ? > > > -- > Best regards, > Bulatmailto:bulat.zigans...@gmail.com > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: logfloat 0.12.0.1
Indeed. I recommend upgrading to GHC 6.10.2, all the weird floating point FFI bugs I encountered with GHC 6.10.1 seem to be resolved now. On Sat, Apr 4, 2009 at 12:10 PM, Bulat Ziganshin wrote: > Hello wren, > > Saturday, April 4, 2009, 2:51:39 AM, you wrote: > > > On GHC 6.10 the use of -fvia-C had to be disabled because it conflicts > > with the FFI (version 0.12.0.0 still used it, which is fine on GHC 6.8). > > I'm still investigating the use of -fasm and getting proper benchmarking > > numbers. Contact me if you notice significant performance degradation. > > isn't this the same bug as in recent thread "[Haskell-cafe] Possible > floating point bug in GHC?" ? > > > -- > Best regards, > Bulatmailto:bulat.zigans...@gmail.com > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: logfloat 0.12.0.1
Indeed. I recommend upgrading to GHC 6.10.2, all the weird floating point FFI bugs I encountered with GHC 6.10.1 seem to be resolved now. On Sat, Apr 4, 2009 at 12:10 PM, Bulat Ziganshin wrote: > Hello wren, > > Saturday, April 4, 2009, 2:51:39 AM, you wrote: > > > On GHC 6.10 the use of -fvia-C had to be disabled because it conflicts > > with the FFI (version 0.12.0.0 still used it, which is fine on GHC 6.8). > > I'm still investigating the use of -fasm and getting proper benchmarking > > numbers. Contact me if you notice significant performance degradation. > > isn't this the same bug as in recent thread "[Haskell-cafe] Possible > floating point bug in GHC?" ? > > > -- > Best regards, > Bulatmailto:bulat.zigans...@gmail.com > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about import alias
Hi
> You can always do
>
> {-# INLINE short #-}
> short =
> C.veryLongFunctionNameThatIReallyDoNotWantToTypeOutEveryTimeIUseIt
The INLINE pragma is not necessary, if an optimising compiler fails to
inline that then it's not very good.
However, you might want to consider the (evil) monomorphism
restriction which will make that pattern fail for any functions with
type classes.
Thanks
Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about import alias
Am Samstag 04 April 2009 17:33:55 schrieb Manlio Perillo:
> Hi.
>
> Haskell 98 allows import alias:
> import qualified VeryLongModuleName as C
>
> however it does not allow aliasing for imported names
> import NormalModule (veryLongFunctionName as C)
>
>
> what is the rational?
> IMHO this can be very useful in some cases.
>
You can always do
{-# INLINE short #-}
short =
C.veryLongFunctionNameThatIReallyDoNotWantToTypeOutEveryTimeIUseIt
so it's not necessary.
>
>
> Thanks Manlio
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about import alias
On Saturday 04 April 2009, Manlio Perillo wrote: > Hi. > > Haskell 98 allows import alias: > import qualified VeryLongModuleName as C > > however it does not allow aliasing for imported names > import NormalModule (veryLongFunctionName as C) > > > what is the rational? > IMHO this can be very useful in some cases. While I do agree with the argument that it could be useful in some cases, misuse of this feature would cause a lot of confusion, consider: from System.IO.Unsafe import (unsafePerformIO as safe) I think that the alias feature is OK, when the namespace is long, longfunctionnameswhichareapaintoreadandespeciallywrite are a bug and should be treated and fixed by the owner of that code, not by the user. If very function names are that much of a problem to you consider a wrapper library. -- Cheers! Marcin Kosiba signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] about import alias
Hi. Haskell 98 allows import alias: import qualified VeryLongModuleName as C however it does not allow aliasing for imported names import NormalModule (veryLongFunctionName as C) what is the rational? IMHO this can be very useful in some cases. Thanks Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get glyph outline from ttf font.
Dmitry V'yal schrieb: Greetings. I'm trying to render some glyphs from ttf font to svg image using gtk2hs cairo binding. Since I can find nothing appropriate in gtk2hs API, I decided to draw outlines with bezier curves myself. But how to get them out of font? As far as I know, freetype library is capable of extracting outlines, but is there any haskell binding for it which supports this functionality? Here [1] one such lib was mentioned, but it wasn't availible online that time. Have situation changed today? Thanks in advance [1] http://www.nabble.com/Re%3A-Rendering-TTF-fonts-in-Haskell-and-OpenGL-p15635659.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi Dmitry, I cannot help you directly with freetype. But I have developped a library that parses the svg-font format (this is not svg). Since svg-font is XML it is much easier to parse than ttf. There is also a program called fontforge that can be used to convert nearly every format into svg-font. The only problem is that currently triangulation has some bugs and is only O(n^2), the algorithm for deleting holes is not finished, and memoization isn't implemented. Should I upload the work although it is not finished? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] happstack example code wanted
Hi, I'm thinking of using happstack for a simple online registration system. [ Customer gives Name and Address and registers for certain workshops. Then the app server should just produce a bill. (Payment is handled through a different channel.) The "store owner" needs to get some overview of registrations. ] According to happs(tack) marketing department, this should be an easy exercise? Any code that I could use as a starting point? ( Or, if you do the coding, I can link to you from the workshop site. But I don't have a serious budget :-) Thanks - J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get glyph outline from ttf font.
A Haskell binding to Freetype2 is indeed missing. Would be nice to have. On Sat, Apr 4, 2009 at 4:08 PM, Jeff Heard wrote: > Yes, the FTGL library, but it uses FTGL on the backend and not > freetype directly. You might be able to get the flyph shapes from > Pango... > > On Sat, Apr 4, 2009 at 12:59 PM, Dmitry V'yal wrote: > >Greetings. I'm trying to render some glyphs from ttf font to svg > > image using gtk2hs cairo binding. Since I can find nothing appropriate in > > gtk2hs API, I decided to draw outlines with bezier curves myself. But > how > > to get them out of font? As far as I know, freetype library is capable of > > extracting outlines, but is there any haskell binding for it which > supports > > this functionality? > > > >Here [1] one such lib was mentioned, but it wasn't availible > online > > that time. Have situation changed today? > > > > Thanks in advance > > > > [1] > > > http://www.nabble.com/Re%3A-Rendering-TTF-fonts-in-Haskell-and-OpenGL-p15635659.html > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get glyph outline from ttf font.
Yes, the FTGL library, but it uses FTGL on the backend and not freetype directly. You might be able to get the flyph shapes from Pango... On Sat, Apr 4, 2009 at 12:59 PM, Dmitry V'yal wrote: > Greetings. I'm trying to render some glyphs from ttf font to svg > image using gtk2hs cairo binding. Since I can find nothing appropriate in > gtk2hs API, I decided to draw outlines with bezier curves myself. But how > to get them out of font? As far as I know, freetype library is capable of > extracting outlines, but is there any haskell binding for it which supports > this functionality? > > Here [1] one such lib was mentioned, but it wasn't availible online > that time. Have situation changed today? > > Thanks in advance > > [1] > http://www.nabble.com/Re%3A-Rendering-TTF-fonts-in-Haskell-and-OpenGL-p15635659.html > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell EDSL to generate SQL?
Hi Jeremy, thanks for that. I had come across it before but I think I'd prefer a more light-weight approach. Günther Jeremy Shaw schrieb: > At Sat, 04 Apr 2009 15:40:56 +0200, > Günther Schmidt wrote: > >> But I hope to be able to use an DSL from which I can automatically >> generate SQL-Strings instead of writing the SQL statements literally. >> >> Has anyone else taken a similar approach? > > HaskellDB has an DSL for generating SQL strings. Though, it is not a > straightforward mapping. The haskellDB DSL provides you with > relational algebra operators that you use to build your query. > > - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] g++ std:map vs GHC IntMap
On Saturday 04 April 2009 14:02:48 Peter Verswyvelen wrote: > > On Sat, Apr 4, 2009 at 12:42 PM, Jon Harrop wrote: > >> For comparison: > >> > >> Haskell hash table: 44s > >> Haskell map: 7s > >> F# hash table: 0.7s > > So how does F# IntMap version compares to Haskell's IntMap? F# map: 43.5s -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to get glyph outline from ttf font.
Greetings. I'm trying to render some glyphs from ttf font to svg image using gtk2hs cairo binding. Since I can find nothing appropriate in gtk2hs API, I decided to draw outlines with bezier curves myself. But how to get them out of font? As far as I know, freetype library is capable of extracting outlines, but is there any haskell binding for it which supports this functionality? Here [1] one such lib was mentioned, but it wasn't availible online that time. Have situation changed today? Thanks in advance [1] http://www.nabble.com/Re%3A-Rendering-TTF-fonts-in-Haskell-and-OpenGL-p15635659.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell EDSL to generate SQL?
At Sat, 04 Apr 2009 15:40:56 +0200, Günther Schmidt wrote: > But I hope to be able to use an DSL from which I can automatically > generate SQL-Strings instead of writing the SQL statements literally. > > Has anyone else taken a similar approach? HaskellDB has an DSL for generating SQL strings. Though, it is not a straightforward mapping. The haskellDB DSL provides you with relational algebra operators that you use to build your query. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell EDSL to generate SQL?
Hi, I tried to solve some large data processing solely in Haskell so I could avoid lots of eventually very long and complex SQL statements. Unfortunately, as was to be expected, that approach doesn't scale. So I do need an SQL backend. But I hope to be able to use an DSL from which I can automatically generate SQL-Strings instead of writing the SQL statements literally. Has anyone else taken a similar approach? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] g++ std:map vs GHC IntMap
So how does F# IntMap version compares to Haskell's IntMap? On Sat, Apr 4, 2009 at 2:58 PM, Peter Verswyvelen wrote: > On Sat, Apr 4, 2009 at 12:42 PM, Jon Harrop wrote: > >> For comparison: >> >> Haskell hash table: 44s >> Haskell map: 7s >> F# hash table: 0.7s > > > Ouch! That's pretty insane. > > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] g++ std:map vs GHC IntMap
On Sat, Apr 4, 2009 at 12:42 PM, Jon Harrop wrote: > For comparison: > > Haskell hash table: 44s > Haskell map: 7s > F# hash table: 0.7s Ouch! That's pretty insane. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] g++ std:map vs GHC IntMap
On Thursday 26 March 2009 15:39:12 Manlio Perillo wrote: > I also tried with Data.HashTable: > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2902 > > but memory usage is 703 MB, and execution time is about 4.5 times slower! This is due to a perf bug in GHC's GC implementation that causes it to traverse entire arrays when a single element has been changed. Hence the Haskell is over an order of magnitude slower than most languages and even slower than Python (!). The purely functional trees that you also used are apparently the idiomatic Haskell workaround but, of course, they are extremely inefficient and still over an order of magnitude slower than any decent hash table. For comparison: Haskell hash table: 44s Haskell map: 7s F# hash table: 0.7s -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be "too smart"
takeListSt' = evalState . foldr k (return []) . map (State . splitAt) where k m m'= cutNull $ do x<-m; xs<-m'; return (x:xs) cutNull m = do s<-get; if null s then return [] else m |Not only is ths not that elegant anymore, As I was saying, sequence/mapM with early cutout is common enough that one might want it in the libraries, which would return this variant into readability again. |I think it *still* has a bug, stack overflow against That would really surprise me. Not that it is impossible - as I was also saying, I haven't replayed the derivation for the modified code. However, the modification was arrived at by taking the original derivation, seeing where its result deviated from the explicitly recursive specification, and spotting the aspect of the implicitly recursive version that was responsible for the deviation. Of course, the derivation itself could have an error, but equating the functions themselves gives me rather more confidence/coverage than any finite number of tests could. If I were to enter the derivation into a proof checking tool and be successful, that would further raise the level of confidence/coverage (leaving bugs in the proof checker). Note that I'm not asking whether the original spec did the "right" thing, only whether or not the variations "correctly" do the same thing as the original spec. |testP pf = mapM_ putStrLn [ | show $ take 5 $ pf (repeat 0) [1,2,3] | , show $ pf ( take 1000 [3,7..] ) [1..100] | , show . pf [3,7,11,15] $ ( take (10^6) [1..]) | , show . head . last $ pf (take 1000 $ [3,3..]) [1..10^6] |] | |where the first test (with take 5) is new. |whereas the version with explicit recursion and pattern matching |doesn't suffer from this problem I get identical results for 'takeListSt'' and the original 'takeList1' (code repeated below). It took me a couple of moments to remember that you had been playing with Control.Monad.State.Strict instead of the default Control.Monad.State(.Lazy). That would invalidate the original derivation (different definition of '>>=', therefore a different end result after unfolding '>>='), let alone the modified code based on it. If you replay the derivation, taking the strictness variations into account, you should arrive at an explicitly recursive version that differs from the spec. Which might make it easier to see what the difference is. |partitions [] xs = [] |partitions (n:parts) xs = | let (beg,end) = splitAt n xs | in beg : ( case end of | [] -> [] | xs -> partitions parts xs) That version cannot be transformed into the original spec, because it doesn't define the same function. As I mentioned: (btw, both 'takeListSt'' and 'takeListSc'' pass Thomas' 'testP', as does his 'partitions', but 'partitions' is not the same function as 'takeList': consider 'null $ takeList [1] undefined' and 'takeList [0] []' ;-) With the original spec takeList1 [] _ = [] takeList1 _ [] = [] takeList1 (n : ns) xs = h : takeList1 ns t where (h, t) = splitAt n xs and 'takeList4' being your 'partitions', we get: *Main> null $ takeList1 [1] undefined *** Exception: Prelude.undefined *Main> null $ takeList4 [1] undefined False *Main> takeList1 [0] [] [] *Main> takeList4 [0] [] [[]] I am starting to think that the tricky part in all these functions is that by using higher order functions from the prelude, you sweep the failure case under the rug. Yes, the reason that more abstract functions are useful is that they hide irrelevant details, allowing us to spend our limited capacity on relevant details. If all abstract functions happen to hide details that matter, more concrete functions that expose those details can be more helpful. But even that has to be qualified: for instance, at first I found it easier to see the issues with the original 'State' variant in its transformed, explicitly recursive version, but after the derivation had convinced me that there was no magic going on, I realized that it was just the old 'mapM' doesn't stop early issue. So I could have seen the issue in the abstract form, but my mind (and apparently other minds, too;-) refused to think about the cornercases there until prompted. If not for this tendency to ignore details that might be relevant, the abstract code would provide an abstract treatment of the failure case as well: instead of working out the details by trying to find useful tests for the explicit pattern matches, we can just look at wether the definition uses 'mapM' or 'mapMWithCut', or whether it uses 'Control.Monad.State' or 'Control.Monad.State.Strict'. Just exposing all the details all the time isn't going to help, as the 'partition' example demonstrates: we might still ignore the relevant details, this time not because they are hidden in abstractions, but because they are hidden in other irrelevant details. There really isn't a single view of sof
Re: [Haskell-cafe] ANN: logfloat 0.12.0.1
Hello wren, Saturday, April 4, 2009, 2:51:39 AM, you wrote: > On GHC 6.10 the use of -fvia-C had to be disabled because it conflicts > with the FFI (version 0.12.0.0 still used it, which is fine on GHC 6.8). > I'm still investigating the use of -fasm and getting proper benchmarking > numbers. Contact me if you notice significant performance degradation. isn't this the same bug as in recent thread "[Haskell-cafe] Possible floating point bug in GHC?" ? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optional EOF in Parsec.
Kannan Goundan wrote:
> I'm writing a parser with Parsec. In the input language, elements of a
> sequence
> are separated by commas:
>
>[1, 2, 3]
>
> However, instead of a comma, you can also use an EOL:
>
> [1, 2
> 3]
>
> Anywhere else, EOL is considered ignorable whitespace. So it's not as simple
> as
> just making EOL a token and looking for (comma | eol).
Hi Kannan,
let's construct the parser top-down. On the top level, you have opening
and closing characters, '[' and ']'. Parsec has a function for that:
between (char '[') (char '])
And what's in between? A list of elements separated by something. Parsec
provides a sepBy function for that:
element `sepBy` separator
which parses a list of elements separated by separator. What's your
separator? Well it's either ',' or a new line and spaces before and
after that:
mySpaces >> (newline <|> char ',') >> mySpaces -- [1]
Let's combine what we've got:
myListOf :: (Parsec String () a) -> Parsec String () [a]
myListOf elem = between
(char '[')
(char ']')
(elem `sepBy` (mySpaces >> (newline <|> char ',') >> mySpaces))
where
mySpaces = many (oneOf (" \t"))
And test it in ghci:
*Main> parseTest (myListOf anyChar) "[a , b, d ,d\np]"
"abddp"
Hope this helps!
Stephan
PS: The important thing is that there are a lot solutions for tricky
situations (like yours) in Text.Parsec.Combinator (especially the sepBy
and many families). Knowing them can save a lot of work :)
[1] I don't use parsec's spaces function because it also accepts newline
characters.
>
> I've implemented this functionality in a hand-written parser (basically a hack
> that keeps track of whether the last read token was preceded by an EOL,
> without making EOL itself a token). Does anybody have ideas about how to
> do this with Parsec?
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
--
Früher hieß es ja: Ich denke, also bin ich.
Heute weiß man: Es geht auch so.
- Dieter Nuhr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optional EOF in Parsec.
Kannan Goundan wrote: I've implemented this functionality in a hand-written parser (basically a hack that keeps track of whether the last read token was preceded by an EOL, without making EOL itself a token). Does anybody have ideas about how to do this with Parsec? You can do exactly the same with Parsec: * create a lexer that yields a [Token], including EOL tokens; * write a function of type [Token] -> [(Token, Bool)] that discards EOLs and tells for each token whether it was preceded by a (now discarded) EOL; * write your pToken :: Token -> Parsec Token function (I omitted some type variables there) that recognises one (Token, Bool)-tuple from the input stream. Or, perhaps easier: * create a lexer that yields a [Token], including EOL tokens; * write a function of type [Token] -> [Token] that discards only those EOL tokens that aren't needed -- for example, those EOL tokens that occur when there are no open ['s, then parse those EOL's explicitly in your parser. Hope this helps, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be "too smart"
> takeListSt' = evalState . foldr k (return []) . map (State . splitAt) > where k m m'= cutNull $ do x<-m; xs<-m'; return (x:xs) > cutNull m = do s<-get; if null s then return [] else m Not only is ths not that elegant anymore, I think it *still* has a bug, stack overflow against testP pf = mapM_ putStrLn [ show $ take 5 $ pf (repeat 0) [1,2,3] , show $ pf ( take 1000 [3,7..] ) [1..100] , show . pf [3,7,11,15] $ ( take (10^6) [1..]) , show . head . last $ pf (take 1000 $ [3,3..]) [1..10^6] ] where the first test (with take 5) is new. whereas the version with explicit recursion and pattern matching doesn't suffer from this problem partitions [] xs = [] partitions (n:parts) xs = let (beg,end) = splitAt n xs in beg : ( case end of [] -> [] xs -> partitions parts xs) I am starting to think that the tricky part in all these functions is that by using higher order functions from the prelude, you sweep the failure case under the rug. Specifically, what happens when splitAt n doesn't have a list of length n? The answer isn't in fact obvious at all. I can think of three things that could hapen. You coud return (list,[]) where list is however many elements there are left. (Which is what all the partitions functions do so far, and the default behavior of splitAt. Or, you could print an error message. Or, you could return ([],[]) My tentative conclusion is that good haskell style makes error modalities explicit when error behavior isn't obvious, or when there is arguably more than one right way to fail. So: partitionsE = partitionsE' error partitionsE2 = partitionsE' ( \e n xs -> []) partitionsE3 = partitionsE' (\e n xs -> [take n xs]) -- corresponds to the behavior of partitions partitionsE' err [] xs = [] partitionsE' err (n:parts) xs = case splitAtE n xs of Left e -> err e n xs Right (beg,end) -> beg : ( case end of [] -> [] xs -> partitionsE' err parts xs ) where splitAtE n as@(x:xs) | n <= length as = Right $ splitAt n as splitAtE n ys = Left $ "can't split at " ++ (show n) ++ ": " ++ (show ys) 2009/3/26 Claus Reinke : > Continuing our adventures into stylistic and semantic differences:-) > > Comparing the 'State' and explicit recursion versions > > takeListSt = evalState . mapM (State . splitAt) > > -- ..with a derivation leading to.. > > takeListSt [] s = [] > takeListSt (h:t) s = x : takeListSt t s' > where (x,s') = splitAt h s > > instead of > > takeList [] _ = [] > takeList _ [] = [] > takeList (n : ns) xs = head : takeList ns tail > where (head, tail) = splitAt n xs > > we can see some differences, leading to different functions: > > *Main> null $ takeListSt [1] undefined > False > *Main> null $ takeList [1] undefined > *** Exception: Prelude.undefined > *Main> takeList [0] [] > [] > *Main> takeListSt [0] [] > [[]] > > and similarly for the 'scanl' version > > takeListSc ns xs = zipWith take ns $ init $ scanl (flip drop) xs ns > > Depending on usage, these differences might not matter, but what if > we want these different styles to lead to the same function, with only > stylistic and no semantic differences, taking the explicit recursion as > our spec? > > In the 'State' version, the issue is that 'mapM' does not terminate > early, while the specification requires an empty list whenever 'xs' > (the state) is empty. Following the derivation at > > http://www.haskell.org/pipermail/haskell-cafe/2009-March/058603.html > > the first step where we have a handle on that is after unfolding > 'sequence': > > takeListSt = evalState . foldr k (return []) . map (State . splitAt) > where k m m' = do x<-m; xs<-m'; return (x:xs) > > If we change that to > > takeListSt' = evalState . foldr k (return []) . map (State . splitAt) > where k m m' = cutNull $ do x<-m; xs<-m'; return (x:xs) > cutNull m = do s<-get; if null s then return [] else m > > and continue with the modified derivation, we should end up with > the right spec (I haven't done this, so you should check!-). This > isn't all that elegant any more, but support for 'mapM' with early > exit isn't all that uncommon a need, either, so one might expect > a 'mapM' variant that takes a 'cut' parameter to make it into the > libraries. > > For the 'scanl' version, we have a more direct handle on the issue: > we can simply drop the offending extras from the 'scanl' result, > replacing 'init' with 'takeWhile (not.null)': > > takeListSc' ns xs = zipWith take ns $ takeWhile (not.null) $ scanl (flip > drop) xs ns > > A somewhat abbreviated derivation at the end of this message > seems to confirm that this matches the spec (as usual with proofs, > writing them down doesn't mean that they are correct, but that > readers can check whether they are). > > (btw, both 'takeListSt'' and 'takeListSc'' pass Thomas' 'testP', as does > his
[Haskell-cafe] Re: Monad transformer, liftIO
Michael Roth wrote: Hello list, maybe I'm just stupid, I'm trying to do something like this: Ciao Michael, As an alternative solution to Creighton's: import Control.Monad.List foobar :: ListT IO Int foobar = do a <- ListT . return $ [1,2,3] b <- ListT . return $ [4,5,6] liftIO $ putStrLn $ (show a) ++ " " ++ (show b) return (a+b) main = do sums <- runListT foobar print sums For the expression ListT . return $ [1,2,3] of type ListT IO Int, the return inferred is: return: a -> IO a return [1,2,3] = IO [1,2,3] and then you wrap the IO [] with the ListT newtype constructor. Paolo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
