April 2005 - Glasgow-haskell-users

hi-boot and dependencies bug?
by Isaac Jones 15 Apr '05

15 Apr '05

Greetings. I haven't tested this with ghc 6.4 yet, and I don't know if this is a known problem. I noticed this while building support for cabal. I have two mutually recursive modules, prepared as described in the GHC 6.2 user's manual: A and B I create A.hi-boot in B, in import {-source-} A This works fine. But now I create C, which imports B (not A). When I compile with --make, A does not get built, and I get a link-time error. However, if C imports A directly, it builds everything just fine. I've attached a tarball with the example. Test it like this: % ghc --make C.hs Chasing modules from: C.hs Compiling B ( ./B.hs, ./B.o ) Compiling Main ( C.hs, C.o ) Linking ... ./B.o(.text+0x1b): In function `__stginit_B_': : undefined reference to `__stginit_A_' collect2: ld returned 1 exit status peace, isaac p.s. please CC me on replies; i'm not subscribed to this mailing list

1 0

Re: Bus Error with ghc 6.4 on Solaris
by Volker Stolz 15 Apr '05

15 Apr '05

In gmane.comp.lang.haskell.glasgow.bugs, you wrote: > Simon M is away today and Monday, but I do recall him saying something > about the Solaris port being broken. I'm sure he would welcome help > getting it fixed. Are there any of you who build GHC from source, and > know Solaris? I'm currently running a build on $slowhost, so I probably won't get to actual debugging until Monday. We're talking about the release, not -HEAD, right? Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME It's a million to one chance, but it just might work.

1 0

Do you use GHC?
by Simon Peyton-Jones 15 Apr '05

15 Apr '05

Dear Haskell folk, PLEASE READ THIS IF YOU USE THE Glasgow Haskell Compiler (GHC). I virtually never send messages to overlapping sets of lists, but I'm doing so this time, because I'd really like to get to everyone who uses GHC. Here at GHC HQ, we are often asked how many people use GHC, and what kind of folk they are. Since GHC is free software, we have no clue. Download stats tell us a bit, but not much, because GHC gets out through a variety of other routes too (e.g. Debian). We also have little idea about which aspects of GHC are most valued, nor of what enhancements would be most sought after, or which platforms are most important to you. We hear quite a bit from the bleeding-edge folk who push the limits, but much less from people who just want to get the job done. Thus motivated, Tomasz Zielonka kindly put together a (WASH-powered) survey for us, which asks you to tell us a bit yourself and how you use GHC. We've had about 230 responses so far; thank you to those 230 folk. But I'm pretty certain there are more than 230 people in the world who use GHC! THIS MESSAGE IS TO ASK YOU TO TAKE 5 MINS TO COMPLETE THE SURVEY http://www.haskell.org/ghc/survey/start.cgi We'd like to hear from *absolutely everyone* who uses GHC: whether you are a first-year undergraduate or a famous professor; whether you use GHC for industrial applications or recreation; whether you use higher-rank polymorphism or have only just learned what functional programming is. Everyone! We'll use the information to guide our future priorities, and we'll publish some kind of summary of what we learn in due course. It's all anonymous, of course, unless you choose to say who you are. If you think it's appropriate, please circulate this announcement locally, e.g. to your students who may not be on the Haskell mailing list Many thanks Simon PJ and Simon Marlow

1 0

RE: Re[2]: GHC 6.4/mingw32: files larger than 4 GBandhFileSize/hSetFileSize/c_stat
by Simon Peyton-Jones 15 Apr '05

15 Apr '05

I have no clue what the right thing here is. Simon M is away today and Monday, but he'll doubtless tell you on Tuesday. He is supreme being for this kind of stuff. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Bulat Ziganshin | Sent: 12 April 2005 15:22 | To: glasgow-haskell-users(a)haskell.org | Subject: Re[2]: GHC 6.4/mingw32: files larger than 4 GBandhFileSize/hSetFileSize/c_stat | | Hello Simon, | | mingw32 have 32-bit off_t type; access to large files are supported | with special functions and structures defined in msvcrrt.dll: | | _CRTIMP __int64 __cdecl _lseeki64(int, __int64, int); | _CRTIMP __int64 __cdecl _telli64(int); | _CRTIMP int __cdecl _fstati64(int, struct _stati64 *); | _CRTIMP int __cdecl _stati64(const char *, struct _stati64 *); | struct _stati64 { | .... | __int64 st_size; | .... | }; | | so, we need either | 1) define COff to __int64 instead of off_t and rewrite existing | functions to work with 64 bit filesizes | or | 2) define new set of low-level functions to work with 64 bit | filesizes. define high-level functions in terms of these 64-bit | functions on Win32 | | what solution will be better? in the first case COff no longer will be | equal to off_t, what some applications can imply. in the second case | we will add a lot of duplicating code | | is there any other (GHC-supported) environments supporting 64 bit | filesizes, but having only 32-bit off_t? | | (sorry for my bad English, i'm too far from native speaker) | | | | Friday, April 08, 2005, 3:33:36 PM, you wrote: | | SPJ> By all means. If someone cares to send us a patch, we'll incorporate | SPJ> it. | | SPJ> | While GHC I/O library on mingw32 platform perfectly reads and writes | SPJ> | files larger than 4 GB, functions hFileSize/c_fstat, | SPJ> | hSetFileSize/c_ftruncate and c_stat are still tied to C functions | SPJ> | returning 32 bit values and as a result truncate larger sizes to their | SPJ> | low 32 bits. Can this behaviour be fixed in the next bug-fix version? | | | -- | Best regards, | Bulat mailto:bulatz@HotPOP.com | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: deprecate a constructor?
by Simon Peyton-Jones 15 Apr '05

15 Apr '05

Apparently not at the moment but it should be. As in a 'hiding' list, deprecating "T" would deprecate the *type* T and the *data constructor* T. There'd be no way to deprecate one without the other, except by giving them different names. (That's a bit of a shortcoming in hiding lists already, so matters are no worse than before.) I'll look into this sometime I'm on an aeroplane... Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Johannes Waldmann | Sent: 14 April 2005 17:27 | To: glasgow-haskell-users(a)haskell.org | Subject: deprecate a constructor? | | is it possible to {-# DEPRECATE #-} a single constructor | (of a data declaration that is, as a whole, not deprecated)? | -- | -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- | ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

build error for ghc 6.4 on Solaris
by Martin Preen 15 Apr '05

15 Apr '05

Hello, I get the following error when building ghc 6.4 on Solaris 9. Any ideas how to solve this ? Thanks in advance. Martin ... grep -v '^#pragma GCC' | \ sed -e 's/""//g' -e 's/:[ ]*,/: /g' >package.conf.installed ../utils/ghc-pkg/ghc-pkg-inplace --force --update-package <package.conf.inplace Creating user package database in //.ghc/sparc-solaris2-6.4/package.conf Fail: already exists Action: createDirectory Reason: File exists make[2]: *** [../driver/stamp-pkg-conf-rts] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/scratch/ghc-6.4/ghc' make: *** [build] Error 1 ----------------------------------------------------------------- Martin Preen, Universitaet Freiburg, Institut fuer Informatik Georges-Koehler-Allee, Geb.52, Zi.00-006, 79110 Freiburg, Germany phone: ++49 761 203-8250 preen(a)informatik.uni-freiburg.de fax: ++49 761 203-8242 www.informatik.uni-freiburg.de

2 3

deprecate a constructor?
by Johannes Waldmann 14 Apr '05

14 Apr '05

is it possible to {-# DEPRECATE #-} a single constructor (of a data declaration that is, as a whole, not deprecated)? -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

1 0

Complexity bug in garbage collector?
by Josef Svenningsson 14 Apr '05

14 Apr '05

Hi all, I've had some fun chasing around a couple of space leaks lately. One of the graphs that I produced looked like this: www.cs.chalmers.se/~josefs/coresa.ps Notice the shape of the graph. It shows a perfect squareroot function. But my program should be allocating at a constant rate. From previous experience this suggests that there is a time complexity bug in the garbage collector. This makes it take time proportional to the square of the amount of allocated memory. Can someone confirm this? Cheers, /Josef

1 0

Call for Contributions -- HC&A Report (May 2005 edition)
by Andres Loeh 14 Apr '05

14 Apr '05

Dear Haskellers, it is nearly time for the eighth edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/communities/ Submission deadline: 03 May 2005 (please send your contributions to hcar at haskell.org, in plain ASCII or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, write a short entry and submit it to the me. * If you are interested any project related to Haskell that has not previously been mentioned in the HC&A Report, tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming 6 months. If you have only recently been exposed to Haskell, it might be a good idea to browse the November 2004 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the beginning of May. They will be compiled into a coherent report which will appear sometime during May. As always, this is a great opportunity to update your webpages, make new releases, announce of even start new projects, or to point at some developments you want every Haskeller to see! As the purpose of the report is to collect recent or current activities, we encourage you to update all existing summaries and reports. We will probably drop any topics that have not had any activity for the past year, i.e., since May 2004, but we would very much prefer you to present an updated description of the topic. Of course, new entries are more than welcome. Reports should generally be kept brief and informative, ranging from a few sentences to a few hundred words, to keep the whole report reasonably sized. Looking forward to your contributions, Andres (current editor) ----------------------------------- topics New suggestions for current hot topics, activities, projects, etc. are welcome - especially with names and addresses of potential contacts, but here is a non-exclusive list of likely topics (see also http://www.haskell.org/communities/topics.html ): General Haskell developments; Haskell implementations; Haskell extensions; Standardization and documentation; Haskell tutorials, howtos and wikis; Organisation of Haskell tool and library development; Haskell-related projects and publications; new research, fancy tools, long-awaited libraries, cool applications; Feedback from specialist mailing lists to the Haskell community as a whole; Haskell announcements; all (recent) things Haskell Announcements: if you've announced anything new on the Haskell list over the last six months, you'll want to make sure that is reflected in this edition! Project pings: if you're maintaining a Haskell tool or library or somesuch, you'll want to let everyone know that it is still alive and actively maintained, even if there have been no new additions, but all the more if there have been new developments. Tutorials: if you've fought with some previously undocumented corner of Haskell, and have been kind enough to write down how you did manage to build that graphical user interface, or if you've written a tutorial about some useful programming techniques, this is your opportunity to spread the word (short, topic-specific, and hands-on tutorials that only show how to achieve a certain practical task would do a lot to make things easier for new Haskellers - please write some!) Applications: if you've been working quietly, using Haskell for some interesting project or application (commercial or otherwise), you might want to let others know about what you're using Haskell for, and about your experiences using the existing tools and libraries; are you using Haskell on your job? An interesting thread about using Haskell and more generally functional programming for non-Haskell things seems to recur with reasonable frequency - why not write a sentence or two about your use of Haskell for our report? Feedback: if you're on one of the many specialist Haskell mailing lists, you'll want to report on whatever progress has been made there (GUI API discussions, library organisation, etc.) If you're unsure whether a contact for your area of work has come forward yet, have a look at the report's potential topics page, or get in touch with me. I have contacted last time's contributors, hoping they will volunteer to provide updates of their reports, and will update the contacts on the topics page fairly regularly. But where you don't yet see contacts listed for your own subject of interest, you are very welcome to volunteer, or to remind your local community/project team/mailing list/research group/etc. that they really ought to get their act together and let the Haskell community as a whole know about what they've been doing! :-) -------------------------- what should I write? That depends on your topic, but as a general rule, it shouldn't take you long. A simple sentence or two about your use of Haskell could go into the "Individual Haskellers and their projects" section. If you're a company, or if you're working on a project using Haskell as the implementation language, a paragraph on that could go into the "Commercial Applications" and "Non-Commercial Applications" sections. A typical summary report about a tool/library/project/application/... would be between 1 and 3 paragraphs of ASCII text (what's it about? major topics and results since the last report? current hot topics? major goals for the next six months?) plus pointers to material for further reading (typically to a home page, or to mailing list archives, specifications and drafts, implementations, meetings, minutes, ...). For those who prefer templates to fill in, the report is edited in LaTeX, and an entry template might look something like this: \begin{hcarentry}{<MYSTUFF>} \report{<MY NAME>} \status{<PROJECT STATUS IN ONE LINE>} \makeheader <WHAT IS IT?> <WHAT IS ITS STATUS? / WHAT HAS HAPPENED SINCE LAST TIME?> <CAN OTHERS GET IT?> <WHAT ARE THE IMMEDIATE PLANS?> \FurtherReading \url{<PROJECT URL>} \end{hcarentry} Browsing through previous editions should give you a good idea of the variety of possibilities, ranging from very brief to extensive.

1 0

IO and STM
by Robert van Herk 13 Apr '05

13 Apr '05

Hi all, I have a question about IO in a STM transaction. I want to make an atomic algorithm that does the following: 1. read an IORef 2. write some changes to the value you get from 1 3. save the IORef again Currently, I did this, roughly like this: doSomething :: IORef [s] -> s -> IO () doSomething ref s = atomically ( do { ss <- unsafeIOToSTM (readIORef s); do something with ss; unsafeIOToSTM (writeIORef s ss); return () } ) Since I read that STM uses a revertable log, I was wondering what happens with the IO actions, when a rerun on the atomic part is performed... I guess it will just redo them? Is this the unsafe-part of unsafeIOToSTM, or are there more caveats? Regards, Robert

2 2