Re: ANN: ghc 6.8.2 from MacPorts
Thank you! But ghc has disappeared from MacPorts SW list. Only ghc-devel can be seen. Please look into it. jinwoo On Tue, Mar 4, 2008 at 11:13 PM, Gregory Wright [EMAIL PROTECTED] wrote: After what many would consider an unconscionable delay, I am happy to announce that ghc 6.8.2 is available from MacPorts. The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ intel. Users with Leopard/ppc are out of luck until for now, for reason discussed earlier on this list. In partial recompense for their patience, users will get a ghc with more patches than any previous MacPorts ghc. A few notes: The file locking bugs #1992 and #2134 are fixed. Bug #1992 was a simple lock logic error and should be killed dead. Bug #2134 was the result of a lazy readFile holding a lock for an unpredictable time. There may be more cases like this one, and I would appreciate a note from anyone who come across a lock error during building. Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug which under unusual circumstances would repeatably (and mysteriously) crash the build. This was first noticed running the building in an eshell under Aquamacs. Archives were built without tables of contents because ranlib wasn't being run or wasn't running to completion. Builds in the usual Terminal.app didn't trip over this bug. OpenGL support is built by default. It can be turned off using the no_opengl variant. OpenAL support is disabled. Apple's OpenAL framework lacks ALUT support (needed for the ghc binding) but has name clashes with the freealut library from the OpenAL.org website. Fixing this is probably straightforward. If someone is interested, I can give them some pointers on getting started. MacPort's ghc ought to always link with the correct libgmp (the one provided by the gmp port). The latest versions of alex, happy, haddock and hs-Edison are also available. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Jinwoo Lee Always remember that you are unique. Just like everyone else. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: ghc 6.8.2 from MacPorts
On Mar 5, 2008, at 4:21 AM, Jinwoo Lee wrote: Thank you! But ghc has disappeared from MacPorts SW list. Only ghc-devel can be seen. Please look into it. ghc vanished from the distribution server for a few hours yesterday because of a unanticipated corner case in the indexing script. (The server runs Leopard/ppc, and incorrectly rejected ports that correctly reported that they do not run on Leopard/ppc.) A workaround was implemented and it is now available. MacPorts helps debug ghc and ghc helps debug MacPorts! -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
scope of header files
I was under the impression that with ghc, ffi import declarations like this do not escape the module: foreign import ccall unsafe foo.h foo foo :: IO () However it seems that this one does: foreign import ccall unsafe curses.h stdscr stdscrp :: Ptr WINDOWptr from: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mage-1.0 perhapsPbecause it's a pointer import it gets treated differently? Is this correct and expected behaviour? It's hard to tell what header files need to be used globally and inherited by client packages and which can safely be used privately. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: STM and fairness
Tim, Simon, Thanks for your detailed descriptions. Much of my understanding was confirmed. I'll see if I can send you a patch with my suggested fix as soon as my teaching is over. Thanks, Josef On Mon, Mar 3, 2008 at 2:03 PM, Tim Harris (RESEARCH) [EMAIL PROTECTED] wrote: Hi, At the moment we don't make any particular effort to make threads runnable in some specific order when they are unblocked. The current implementation is simply what was easiest to write. If I remember rightly threads blocked on TVars will initially be half-woken, putting them on the same run-queue as their waker and leaving the STM data structures intact. When scheduled they will check whether or not the TVars' contents differ from the values that caused them to block: if the values are unchanged then a thread can block again without needing to build up wait queue structures. In Simon's example of 100 threads blocked on a single-cell TVar buffer, this would mean 99 of them are validated and block again without needing to re-execute the rest of the transaction containing the TVar access. This will probably happen within a single OS thread so these are lightweight thread switches within the GHC run time rather than 99 OS thread switches. At some point it might be nice to look at using run-time feedback about how individual TVars are used. I suspect that, looking at it dynamically, there are a few simple policies that would apply to most TVars (wake-all / wake-one) with the caveat that anything other than wake-all must eventually fall back to wake-all to preserve the intended semantics for retry. NB -- when thinking about a shared buffer built over TVars there's also the possibility that a non-blocked thread will consume the resource ahead of a blocked thread that has been woken. As with programming with locks/condition-variables, avoiding this case would need an explicit queue of consumers to be maintained by the application (and symmetrically for producers). In any case, running threads in something approximating the same order they blocked sounds sensible to me. The lists of threads blocked on a TVar are doubly-linked (right?) so wouldn't need to be explicitly reversed. Tim -Original Message- From: Simon Peyton-Jones Sent: 29 February 2008 20:06 To: Josef Svenningsson; glasgow-haskell-users@haskell.org Cc: Tim Harris (RESEARCH) Subject: RE: STM and fairness | I'd like to know a bit about the STM implementation in GHC, | specifically about how it tries to achieve fairness. I've been reading | Composable Memory Transactions but it does not contain that much | details on this specific matter. What I want to know boils down to | this: what order are processes run which have been woken up from a | call to retry? Tim is the one who implemented this stuff, so I'm ccing him. If threads queue up on a single MVar, it's obvious how to achieve fairness of a sort. Furthremore, if 100 threads are blocked on one MVar, the scheduler can wake up exactly one when the MVar is filled. With STM it's much less obvious. First, a thread may block on a whole bunch of TVars; if any of them are changed, the thread should re-run. So there is no single list of threads to reverse or not reverse. Second, if 100 threads are blocked on a TVar, t, waking up just one of them may not suffice -- it may read some more TVars and then retry again, re-blocking itself on t (plus some more). The only simple thing to do is to wake all of them up. In common situations (e.g. a buffer), we may wake up all 100 threads, only for 99 of them to lose the race and block again. This arises from the fact that transactions do a wonderful thing, by letting you perform multiple operations atomically -- but that makes it harder to optimize. All that said, you may well be right that one could do a better job of scheduling. For example, even though there may be lots of threads blocked on a TVar, and all must be made runnable, they could perhaps be run in the same order that they blocked, so the longest-blocked got to run first. I don't think we try to do that, but Tim would know. By all means suggest a patch! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Wed, Mar 05, 2008 at 11:16:14PM +, Duncan Coutts wrote: I was under the impression that with ghc, ffi import declarations like this do not escape the module: foreign import ccall unsafe foo.h foo foo :: IO () GHC can inline the stub across module (and thus package) boundaries, so the #include can escape. It's hard to tell what header files need to be used globally and inherited by client packages and which can safely be used privately. No, it's easy: they're all potentially inherited. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Wed, 2008-03-05 at 23:46 +, Ross Paterson wrote: On Wed, Mar 05, 2008 at 11:16:14PM +, Duncan Coutts wrote: I was under the impression that with ghc, ffi import declarations like this do not escape the module: foreign import ccall unsafe foo.h foo foo :: IO () GHC can inline the stub across module (and thus package) boundaries, so the #include can escape. I've been informed before that: foreign import ccall unsafe foo foo :: IO () can escape and needs -#include on the command line and for all client code. However for ghc: foreign import ccall unsafe foo.h foo foo :: IO () does not escape because ghc does not track which .h file should be #included later. It's not that it couldn't escape according to the FFI spec but that ghc currently does not do cross-module inlining for such declarations. That's what I've been told and it's the behaviour I've observed, except for the case I noted. Quite a few packages rely on ghc's behaviour on this, or just rely on the fact that in practise things do not get inlined that aggressively. If we started looking carefully I think we'd find most hackage packages that use FFI get this wrong. It's hard to tell what header files need to be used globally and inherited by client packages and which can safely be used privately. No, it's easy: they're all potentially inherited. Which is really annoying :-) I'd like greater control over it, in particular a way to limit headers to package scope so that dependent code does not need the headers. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Thu, Mar 06, 2008 at 12:23:35AM +, Duncan Coutts wrote: However for ghc: foreign import ccall unsafe foo.h foo foo :: IO () does not escape because ghc does not track which .h file should be #included later. It's not that it couldn't escape according to the FFI spec but that ghc currently does not do cross-module inlining for such declarations. That's what I've been told and it's the behaviour I've observed, except for the case I noted. Ah yes, I remember that now. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Thu, Mar 06, 2008 at 12:23:35AM +, Duncan Coutts wrote: Which is really annoying :-) I'd like greater control over it, in particular a way to limit headers to package scope so that dependent code does not need the headers. Ideally there would be no need for headers at all. Everything needed is inherently in the foreign declaration. If anything, the headers should just be used as a sanity check, not actually to affect the generated code. It would be nice if ghc just stopped relying on them and ignored them altogether. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Wed, 2008-03-05 at 17:37 -0800, John Meacham wrote:
On Thu, Mar 06, 2008 at 12:23:35AM +, Duncan Coutts wrote:
Which is really annoying :-) I'd like greater control over it, in
particular a way to limit headers to package scope so that dependent
code does not need the headers.
Ideally there would be no need for headers at all. Everything needed is
inherently in the foreign declaration. If anything, the headers should
just be used as a sanity check, not actually to affect the generated
code. It would be nice if ghc just stopped relying on them and ignored
them altogether.
We're going to have to figure out what to do with crazy header files
that use lots of macros. For example the mage-1.1.0 package does not
compile without -fvia-C. This is because of the curses.h interface.
For example:
foreign import ccall unsafe curses.h ACS_UARROW
acs_uarrow :: Ptr ChType
And what is ACS_UARROW? We might hope it's a pointer with a
corresponding linker symbol.
Sadly not:
#define ACS_UARROW NCURSES_ACS('-') /* arrow pointing up */
where:
#define NCURSES_ACS(c) (acs_map[NCURSES_CAST(unsigned char,c)])
extern NCURSES_EXPORT_VAR(chtype) acs_map[];
Yay, it's an index into an array. So that obviously does not work. If we
compile without going via C we get a linker error because there is no
ACS_UARROW linker symbol. If we compile via C then through a bit of luck
it seems to compile.
There are rather too many of these C libs that define their public
interfaces as macros. I had to adjust the zlib binding the other day to
allow it to compile without -fvia-C. It now implements a couple macros
in the Haskell code. I hope zlib don't change their macro in the next
version.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Thu, Mar 06, 2008 at 02:18:08AM +, Duncan Coutts wrote:
foreign import ccall unsafe curses.h ACS_UARROW
acs_uarrow :: Ptr ChType
#define ACS_UARROW NCURSES_ACS('-') /* arrow pointing up */
You ought to use a C wrapper around these sorts of things. If you're
lucky, the API docs will tell you which values and functions might be
macros, e.g.
http://www.opengroup.org/onlinepubs/007908799/xcurses/curses.h.html
is clear about what is (or might be) what.
I can't remember if it's been discussed before, but I think it might be
a good idea for the FFI to be able to create these C stubs itself, if
you give a certain keyword - or perhaps even by default as it's the
safe thing to do, at the expense of performance.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Thu, Mar 06, 2008 at 02:18:08AM +, Duncan Coutts wrote:
There are rather too many of these C libs that define their public
interfaces as macros. I had to adjust the zlib binding the other day to
allow it to compile without -fvia-C. It now implements a couple macros
in the Haskell code. I hope zlib don't change their macro in the next
version.
Yeah, I ran into the exact same issue with my curses binding. the
solution was to use hsc2hs to create wrappers when needed.
something like this:
foreign import ccall get_COLOR_PAIRS colorPairsPtr :: Ptr CInt
#def inline int * get_COLOR_PAIRS (void) {return COLOR_PAIRS;}
hsc2hs is needed anyway for portable C bindings so it isn't too onerous
of a requirement.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope of header files
On Thu, Mar 06, 2008 at 02:39:35AM +, Ian Lynagh wrote: I can't remember if it's been discussed before, but I think it might be a good idea for the FFI to be able to create these C stubs itself, if you give a certain keyword - or perhaps even by default as it's the safe thing to do, at the expense of performance. The FFI defines an ABI spec, not an API one. As in, a C compiler is never inherently involved, (hence the ability to have Haskell compilers with a pure assembly back end). Tools like hsc2hs are there to bridge the gap to a particular language when needed. Some libraries guarantee an ABI, others just an API. Hopefully it is documented. :). In general, in order to support dynamic linking, the ABI must remain stable so tools like 'hsc2hs' often aren't needed when interfacing to C code. In any case, it is not the FFI's job, though of course, specific Haskell compilers are free to provide extensions. But I'd rather see GHC get further away from C idiosyncrasies instead of closer. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: ghc 6.8.2 from MacPorts
Gregory Wright wrote: After what many would consider an unconscionable delay, I am happy to announce that ghc 6.8.2 is available from MacPorts. thank you for all the hard work, port installing now as we speak. Good job. Mac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
monomorphic or not?
http://www.cse.unsw.edu.au/~dons/code/nobench/real/compress/compress.hs if you notice this program has the line compress = map toEnum . codes_to_ascii . encode It seems to me this should run afoul of the monomorphism restriction due to the unknown ambiguous type in Enum, but ghc 6.8.2 happily accepts it. Jhc thinks it is illegal according to my reading of the specification. Any ideas about what is going on here? John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
