January 2005 - Glasgow-haskell-users

RE: debian ghci on sparc64
by Simon Marlow 19 Jan '05

19 Jan '05

On 18 January 2005 21:01, William Lee Irwin III wrote: > On 15 December 2004 14:46, William Lee Irwin III wrote: >>> There seems to be some trouble with the debian ghci on sparc64. I >>> can dredge up more information if given an idea of what to look for. > > On Tue, Jan 18, 2005 at 04:41:02PM -0000, Simon Marlow wrote: >> This turned out to be relatively straightforward. Two fixes: >> ghc-asm.lprl needs slight modifications for new versions of gcc on >> sparc-*-linux, and the dynamic linker also needs to have USE_MMAP >> enabled due to needing to execute dynamically allocated memory. >> I've made these fixes in the HEAD, and also merged them into the 6.2 >> branch. William: there's a fixed tree in >> /mnt/dm0/simonmar/ghc-6.2.2 on your sparc64 box. > > Great, thanks for fixing it up! I can make similar arrangements for > the alpha issue, if desired. Are you referring to this bug? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232727 If so, that's quite a bit of work - not 6.4 material I'm afraid. Cheers, Simon

2 1

RE: self-import
by Simon Peyton-Jones 19 Jan '05

19 Jan '05

Good point, thank you! I'd forgotten that the OGI modules paper, which I read carefully at the time, covered recursion (Section 5.4). But my real point wasn't that it's impossible to define a meaning, only that the meaning might be a bit unexpected to a programmer, and involves a fixpoint calculation (which the paper indeed performs). It does also require the scope-resolver to process the whole of a strongly-connnected component of modules at a time, which GHC isn't set up to do. That's an engineering issue, not a semantic one, though. Simon | -----Original Message----- | From: Thomas Hallgren [mailto:hallgren@cse.ogi.edu] | Sent: 18 January 2005 22:12 | To: Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Cc: john(a)repetae.net | Subject: Re: self-import | | Simon Peyton-Jones wrote: | | >I quite liked this idea until I thought of this: | > | > module Doc.Pretty.Long( M.f, f ) where | > import qualified M( f ) | > import Doc.Pretty.Long as M | > | > f x = x | > | >The second import decl imports all the things exported by | >Doc.Pretty.Long. But what does it export? Well, M.f. But what is M.f. | >Well, it could be the f coming from 'import M.f'. But wait! | >Doc.Pretty.Long exports the locally-defined f too... and the second | >import decl will make that be called M.f too. | > | > | Our module system paper has answers to this type of questions, since it | deals with the meaning of recursive modules: | | http://www.cse.ogi.edu/~diatchki/hsmod/ | | It is implemented in the Programatica Haskell front-end, which thus | supports modules importing themselves in particular, and mutually | recursive modules in general, without the need for boot .hi files. I | wonder when other Haskell implementations are going to catch up? :-) | | -- | Thomas H

1 0

RE: [Haskell] [ANNOUNCE] New version of unicode CWString library withextras
by Simon Marlow 19 Jan '05

19 Jan '05

On 19 January 2005 05:31, John Meacham wrote: > A while ago I wrote a glibc specific implementation of the CWString > library. I have since made several improvements: > > * No longer glibc specific, should compile and work on any system with > iconv (which is unix standard) (but there are still glibc specific > optimizations) > * general iconv library for conversion to any other supported > character sets > * LocaleIO, a plug in replacement for many of the standard prelude and > IO calls which transparently handle locale encoding. > > and best of all, it now has a darcs repository. > > http://repetae.net/john/recent/out/HsLocale.html > > It could still using some fleshing out, LocaleIO is still incomplete, > I add to it as I need a function, but I figure I should make it > available in case the CWString stuff came in handy for implementing > the FFI spec for ghc. I'd like to get a correct CString implementation into GHC's libraries. I think the CWString implementation we have now is good enough, but CString should be doing locale encoding/decoding (as you know). At the same time, we should check all the withCString calls to see whether they should really be withCAString (since withCString is about to get quite a bit slower). Would you be interested in helping with this, or even putting together a patch? It's probably too late for 6.4, though. > PS. is there a way to replace the top level error handler in ghc? > (from a haskell library) I'd like to be able to print the error > messages with the LocaleIO library as it is the only place where the > wrong encoding still can leak out. There's no way to replace the handler, I'm afraid. Cheers, Simon

1 0

RE: self-import
by Simon Peyton-Jones 18 Jan '05

18 Jan '05

| It would be useful to be able to do a | | module Doc.Pretty.Long.Name where | | import Doc.Pretty.Long.Name as This | | so within the module we can refer to itself as 'This' without having to | write out the full name, however ghc complains that the hi file for the | module it is trying to compile is not available. It would be nice if ghc | could recognize the self-import case and handle it directly. I quite liked this idea until I thought of this: module Doc.Pretty.Long( M.f, f ) where import qualified M( f ) import Doc.Pretty.Long as M f x = x The second import decl imports all the things exported by Doc.Pretty.Long. But what does it export? Well, M.f. But what is M.f. Well, it could be the f coming from 'import M.f'. But wait! Doc.Pretty.Long exports the locally-defined f too... and the second import decl will make that be called M.f too. It seems that we may need a fixpoint loop to sort all this out. Seems scary. I think what you want is actually more directly stated thus: module Doc.Pretty.Long( ... ) as M where ... The 'as M' in the module header gives an alias for Doc.Pretty.Long just as it does for an import statement. Simple. Your scheme had the advantage of no new syntax. I'd be interested to know whether lots of people would like 'as M' in the module header, as new syntax. A bit more complexity, but perhaps useful. Simon

3 2

RE: debian ghci on sparc64
by Simon Marlow 18 Jan '05

18 Jan '05

On 15 December 2004 14:46, William Lee Irwin III wrote: > There seems to be some trouble with the debian ghci on sparc64. I can > dredge up more information if given an idea of what to look for. > > $ ghci > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for > Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package base ... linking ... done. > zsh: 7796 segmentation fault ghci This turned out to be relatively straightforward. Two fixes: ghc-asm.lprl needs slight modifications for new versions of gcc on sparc-*-linux, and the dynamic linker also needs to have USE_MMAP enabled due to needing to execute dynamically allocated memory. I've made these fixes in the HEAD, and also merged them into the 6.2 branch. William: there's a fixed tree in /mnt/dm0/simonmar/ghc-6.2.2 on your sparc64 box. Cheers, Simon

2 1

RE: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
by Simon Marlow 18 Jan '05

18 Jan '05

On 18 January 2005 14:52, Duncan Coutts wrote: > While we're thinking about it, could a link to Gtk2Hs be added: > http://gtk2hs.sourceforge.net/ . Our web page has been updated to be > rather more current. Done. Simon

1 0

Re: Contents of Glasgow-haskell-users Digest, Vol 17, Issue 8
by Jost Berthold 18 Jan '05

18 Jan '05

Hi Bill, In order to force the *complete* evaluation of your result, you could use Evaluation Strategies. Strategies are a concept introduced for increasing parallelism in Glasgow parallel Haskell. Parallelism and lazy evaluation are in a way contrary aims, since you want your parallel evaluation to start ASAP, even if there is no actual demand on its result. Check the following paper for more information: http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html A strategy module should be included in the libraries in GHC... Formerly just module "Strategies" in package concurrent, now in package base, module "Control.Parallel.Strategies" Concretely, I suggest to apply the strategy "rnf" (reduce to normal form) to "junk" instead of just checking the first node in the graph. What null does is to look at the list and yields true if the top constructor is "[]" and not "(:)". Your version below is what you get with just "junk `seq` runNReps f x (todo-1)" - weak head normal form evaluation. runNReps f x todo | todo > 0 = do let junk = f x rnf junk `seq` runNReps f x (todo-1) HTH Jost glasgow-haskell-users-request(a)haskell.org wrote: Message: 7 Date: Mon, 17 Jan 2005 14:21:00 -0600 From: "jekwtw" <jeaniek7(a)comcast.net> Subject: Re: Timing Functions To: <glasgow-haskell-users(a)haskell.org> Message-ID: <003401c4fcd2$1009b5a0$94a92942@WOOD2441FMASZ8> Content-Type: text/plain; charset="iso-8859-1" Many thanks to both Georg and Lemmih. Actually, I had considered laziness, but I didn't pursue it enough. I tried one version of runNReps in which I passed (f x) as an additional arg; when that didn't work, a little thought convinced me that laziness was doing me in. I also tried another approach, which was to "use" the function evaluation, but that didn't work either (note: I know (f x) can not be the empty list for values of x I'm interested in, but I don't think Haskell does, unless it's *really* smart :-) : >> runNReps :: (Int -> [a]) -> Int -> Int -> IO () >> runNReps f x todo >> | todo > 0 = do let junk = (f x) >> if null junk then return (()) else runNReps f x (todo - 1) >> | otherwise = return (()) Ideas? Again, many thanks, -- Bill Wood bill.wood(a)acm.org

2 3

[ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
by SourceForge.net 18 Jan '05

18 Jan '05

Feature Requests item #1104381, was opened at 2005-01-18 11:27 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_… Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add wxHaskell link to homepage Initial Comment: Hi, I am a user of wxHaskell, a wxWidgets binding for haskell. The product is very useful to me. Adding it to the homepage will ensure that more contribution is added to it though. Haskell community has to stay tight. Sorry for not knowing where to post this issue though ---------------------------------------------------------------------- >Comment By: Simon Marlow (simonmar) Date: 2005-01-18 14:09 Message: Logged In: YES user_id=48280 Done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_…

3 2

Timing Functions
by jekwtw 18 Jan '05

18 Jan '05

I'm putting together a script to gather run-time stats for some functions I'm working with, and I'm having a terrible time. My strategy is to evaluate a function a number of times and compute the difference between the elapsed CPU time before and after the repeated calls. > timeNReps :: (a -> b) -> a -> Int -> FilePath -> IO () > timeNReps func arg reps fileName = > do t0 <- System.CPUTime.getCPUTime > runNReps func arg reps > t1 <- System.CPUTime.getCPUTime > appendFile fileName ((showMS (t1 - t0)) ++ "\n") > where > showMS n = show (n `quot` 1000000000) showMS just converts the pico-second result into milli-seconds and stringifies it. runNReps is an IO program (do sequence) that is intended to call the function and tail-call itself a given number of times: > runNReps :: (Int -> a) -> Int -> Int -> IO () > runNReps f x todo > | todo > 0 = do let junk = (f x) > runNReps f x (todo - 1) > | otherwise = return (()) Apparently runNReps doesn't apply f to x at all! I've called my test function with a suitable argument from top level (within ghci) and it takes ~20 sec. wall time to return; when I evaluate "runNReps test arg 1" it returns immediately. When I use this within my timing script I get timing output that indicates that calls for all args between 1 and 50 take about the same (very small) amount of time, but I know, both from theory and experiments in Scheme versions, that my test function's complexity is exponential in its arg. I'm using GHC 6.0.1 under Mandrake 9.1 on a 1.8 GHz Pentium box with 256MB RAM. Any idea where I'm going wrong? -- Bill Wood bill.wood(a)acm.org

3 4

[ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
by SourceForge.net 18 Jan '05

18 Jan '05

Feature Requests item #1104381, was opened at 2005-01-18 03:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add wxHaskell link to homepage Initial Comment: Hi, I am a user of wxHaskell, a wxWidgets binding for haskell. The product is very useful to me. Adding it to the homepage will ensure that more contribution is added to it though. Haskell community has to stay tight. Sorry for not knowing where to post this issue though ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_…

1 0