June 2010 - Haskell-Cafe

Re: [Haskell] Woes on MacOS 10.6 - linking issues
by Pepe Iborra 11 Jun '10

11 Jun '10

(moving to the cafe) There is an incompatibility between the version of iconv in Mac Os and the one included in MacPorts. As the RTS of the build of ghc in the Haskell Platform is linked against Mac Os iconv, you cannot use it with the build of gtk2hs from MacPorts. This is a known issue already commented elsewhere, in case you haven't found it already: http://www.mail-archive.com/haskell-cafe@haskell.org/msg69139.html http://stackoverflow.com/questions/2726248/ghc-6-12-and-macports Cheers, On Fri, Jun 11, 2010 at 4:53 AM, Brett Giles <brett.giles(a)ucalgary.ca> wrote: > Hi Folks > > I seem to have Gtk2HS 0.11 installed, but not quite working. Interestingly, I can run a demo, such as the hello/World.hs example, directly in ghci. However, when I try to do a ghc --make on any code containing gtk2hs I get a link error like this: > > Undefined symbols: > "_iconv_close", referenced from: > _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) > (maybe you meant: _hs_iconv_close) > "_iconv", referenced from: > _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) > (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) > "_iconv_open", referenced from: > _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) > (maybe you meant: _hs_iconv_open) > ld: symbol(s) not found > > > I do have libiconv installed as a universal library via macports. gtk, glade etc., are also universal installed via macports. > > I downloaded the OSX Haskell Platform package and am running ghc 6.12.1 > > Other programs seem to be having some issues as well though, For instance, a command line program seems to compile fine, but when it runs I get the message: > > $ emlqpl (<<<--- My "successfully" compiled program - batch only, no gtk items) > dyld: Library not loaded: /opt/local/lib/libgtk-quartz-2.0.0.dylib > Referenced from: /usr/local/bin/emlqpl > Reason: image not found > Trace/BPT trap > > > > Does anyone have any suggestions? > > Brett Giles > Grad Student, Formal Methods, Category Theory, > University of Calgary > brett.giles(a)ucalgary.ca > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- -- José Iborra http://www.dsic.upv.es/~jiborra -- UPV Valencia Telf. (+34) 96 387 00 00 (ext) 83529 -- Camino de Vera s/n. 46022 Valencia (Spain)

1 0

Re: package naming policy (was: Please check your dependencies on fgl)
by John Lato 11 Jun '10

11 Jun '10

> From: Don Stewart <dons(a)galois.com> > > ivan.miljenovic: >> Thomas Bereknyei are currently re-writing fgl (just about completely >> from scratch) and we plan to make an initial release to get feedback >> on the API in the next few weeks. >> >> However, I'm sending this email out now to warn people that I highly >> doubt any code that was written for the current version of fgl >> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the >> new version. > > How about you give the library a different name then -- so as not to > break all those programs? > > A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the "Which version of QuickCheck should I use?" problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. My 2 cents, anyway. John

5 8

Re: [Haskell-cafe] How to "Show" an Operation?
by Martin Drautzburg 11 Jun '10

11 Jun '10

On Monday, 7. June 2010 23:28:08 Evan Laforge wrote: > I just meant you could add instances: > > instance Functor (Named a) where fmap f named = named { val_of = f > (val_of named) } > instance Applicative (Named a) where ... likewise, but maybe not a > great fit unless you have a "no name" for 'pure' So far so good. However my "Named" things are all functions and I don't see I ever want to map over any of them. But what I'd like to do is use them like ordinary functions as in: f::Named (Int->Int) f x Is there a way to do this, other than writing apply::Named Int ->Int apply n x = (val_of n) x -- Martin

6 12

Help with Bird problem 3.3.3
by Peter Hilal 11 Jun '10

11 Jun '10

I'm working my way through Bird's _Introduction to Functional Programming Using Haskell_. I'd appreciate any help with problem 3.3.3, which is: "Division of natural numbers can be specified by the condition (n * m) / n = m for all positive n and all m. Construct a program for division and prove that it meets the specification." The required construction relies on the following definitions: data Nat = Zero| Succ Nat (+) :: Nat -> Nat m + Zero = m m + Succ n = Succ (m + n) (*) :: Nat -> Nat m * Zero = Zero m * Succ n = m * n + m Proceeding as Bird does in Sec. 3.2.2, where he derives the definition of "-" from the specification "(m + n) - n = m", I've so far gotten the first case, in which m matches the pattern "Zero", simply by (i) substituting Zero for m in the specification, (ii) substituting Succ n for n in the specification (solely because n is constrained to be positive), and (iii) reducing by applying the first equation of "*": Case Zero: (Succ n * Zero) / Succ n = Zero ≡ {first equation of "*"} Zero / Succ n = Zero Easy enough, and completely intuitive, since we expect Zero divided by any non-Zero finite number to be Zero. The next case, in which m matches the pattern "Succ m", is where I get stuck, and I really have no intuition about what the definition is supposed to be. My first step is to substitute "Succ m" for "m" in the given specification, and to substitute Succ n for n in the specification (for the same reason, as above, that n is constrained to be positive), and then to use the definition of "*" to reduce the equation: Case Succ m: Succ n * Succ m / Succ n = Succ m ≡ {second equation of "*"} (Succ n * m + Succ n) / Succ n = Succ m Where do I go from here? Thank you so much.

5 4

Thread scheduling
by Andrew Coppin 11 Jun '10

11 Jun '10

Control.Concurrent provides the threadDelay function, which allows you to make the current thread sleep until T=now+X. However, I can't find any way of making the current thread sleep until T=X. In other words, I want to specify an absolute wakeup time, not a relative one. What's even more frustrating is that, reading the source code, it appears that the internal RTS primitive *is* actually using an absolute time, but this isn't exposed anywhere that I can get at. Is there any danger that this could be fixed at some point? (I might also interject something about Data.Time, which seems to hardly let me do anything, but strictly that's a seperate topic...)

4 4

ANN: bytestring-trie 0.2.2 (major bugfix)
by wren ng thornton 10 Jun '10

10 Jun '10

-------------------------------------------- -- bytestring-trie 0.2.2 (major bugfix) -------------------------------------------- Another release for efficient finite maps from (byte)strings to values. This version corrects a major bug affecting all users who merge tries. -------------------------------------------- -- Changes (since 0.1.4) -------------------------------------------- * Corrected a major bug in mergeBy which caused conflicting values to be merged in the wrong order. Since this is a core function, all other merging-based functions are affected as well (e.g., unionR, unionL,...). The bug was filed by Gregory Crosswhite (thanks!). * added Data.Trie.Convenience.fromListWith --- A variant of 'fromListR' that takes a function for combining values on conflict. * generalized the type of toListBy * removed KeyString and KeyElem aliases * documentation tweaks -------------------------------------------- -- Future work -------------------------------------------- * Worked on explicit definitions for foldl and foldr, as opposed to the default definitions given by Foldable using Endo. The suggested definitions are around 3x faster than the old definitions, however the order of folding is different than foldrWithKey (which seems to have the correct order). These definitions are not currently being used, but perhaps the future will see faster folding functions for Tries. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-trie Darcs: http://community.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring… -- Live well, ~wren

1 0

QuickCheck 2
by wren ng thornton 10 Jun '10

10 Jun '10

Since GHC 6.12 ships with QC2 it looks like it's finally time to get around to converting some old testing scripts. Unfortunately, one of the things I couldn't figure out last time I looked (and hence why I haven't switched) is how to reconfigure the configuration parameters to the driver function. Is there a porting guide anywhere, or how else can I adjust the configuration parameters (in particular, the configMaxTest and configMaxFail parameters)? -- Live well, ~wren

2 3

Re: [Haskell-cafe] Problems with threading?
by Isaac Gouy 10 Jun '10

10 Jun '10

--- On Thu, 6/10/10, Louis Wasserman <wasserman.louis(a)gmail.com> wrote: > Date: Thursday, June 10, 2010, 1:32 AM > Yeah, Control.Parallel would be nice to have. Heck, ideally I could get > the whole Haskell Platform, which would be a reasonable comparison to > the huge Java and C++ libraries accessible to those languages. > Out of curiosity, though, Haskell's thread-ring implementation just > tumbled down the rankings http://shootout.alioth.debian.org > /u64q/program.php?test=threadring&lang=ghc&id=3. Previously, it'd been > doing most of its work on a single core, now it's spread out. Any ideas > for fixin' it? (I'm going to to try using forkOnIO.) There are 4 sets of "rankings" so - http://shootout.alioth.debian.org/u64/program.php?test=threadring&lang=ghc&… I have been wondering what approach is recommended when one part of a program would be a lot faster with -threaded but other parts of the program would be a lot faster without -threaded. I can see that the C++ and Fortran and ... programmers would just wrap part of their program source code with a pragma.

3 6

Re: [Haskell-cafe] Problems with threading?
by Isaac Gouy 10 Jun '10

10 Jun '10

--- On Thu, 6/10/10, Louis Wasserman <wasserman.louis(a)gmail.com> wrote: > Date: Thursday, June 10, 2010, 11:25 AM > > There are 4 sets of "rankings" so - > > http://shootout.alioth.debian.org/u64/program.php?test=threadring&lang=ghc&… > Yes, but Haskell used to be doing much better specifically on the u64q, > which was why I was surprised. I tend not to believe "used to be doing much better" comments until I'm shown the numbers ;-)

1 0

Haskell logo
by Andrew Coppin 10 Jun '10

10 Jun '10

I just visited haskell.org and noticed that the old logo is back. Anybody know when/why this happened?

2 1