Success story (was: Re: Where are ghc-4.02 .hc files?)

1999-04-13 Thread Matthias Kilian

Thank you all for your tips.

I've compiled first ghc-3.02 using the .hc files and then ghc-4.02 which
required an additional -dcore-lint on the following files:

compiler/rename/ParseIface.lhs
lib/exts/Int.lhs
lib/exts/Word.lhs
lib/posix/PosixTTY.lhs +
lib/std/PrelArr.lhs
lib/std/PrelHandle.lhs
lib/std/Random.lhs

In addition to this, I also had to switch optimization off  (-Onot) for
lib/posix/PosixTTY.lhs.

Now I can say that ghc-4.02 seems to work on Linux 2.2.5 with glibc-2.1.1pre1
and egcs-1.1.2. I did a three-stage bootstrapping without any further problems.

Regards,
Kili



Mailing list (was: Re: Q: Threads in GHC's RTS)

1999-04-13 Thread Keith Wansbrough


Sven writes:

 P.S.: Something completely unrelated: Why is majordomo.haskell.org
   expanded to scarlet.cam.uk.eu.microsoft.com in the To:-field?
   IMHO this is a bad idea, e.g. when people cut-and-paste this
   into their address books and scarlet is renamed to e.g. rhett. :-)
 
 P.P.S.: Adding a prefix in the Subject:-field (e.g. [ghcu]) would make
 mail filters work more reliably. Lots of other mailing lists
 do something similar.

Ugh!  No!  The Return-Path: field has everything required for g-h-u.

I find for practically all the lists I subscribe to either the Return-Path: or the 
Sender: field are sufficient for the filter.  Adding noise to an in-band field like 
Subject: would be annoying and distracting; far better to keep it in a field normally 
hidden, as it is at present.

Certainly the real name of the mailer machine shouldn't be being transmitted, though, 
for exactly the reason you describe.

--KW 8-)

--KW 8-)


-- 
: Keith Wansbrough, MSc, BSc(Hons) (Auckland) :
: PhD Student, Computer Laboratory, University of Cambridge, England. :
:  (and recently of the University of Glasgow, Scotland. [] )   :
: Native of Antipodean Auckland, New Zealand: 174d47' E, 36d55' S.:
: http://www.cl.cam.ac.uk/users/kw217/  mailto:[EMAIL PROTECTED] :
:-:




RE: Q: Threads in GHC's RTS

1999-04-13 Thread Simon Peyton-Jones

I don't think it's so hard, unless I'm missing something.

foreign export dynamic 
mkFooCB :: (Int - Int - IO ()) - IO Addr

freeHaskellFunctionPtr :: Addr - IO ()

Now if you want the callback itself to free itself, you say

do {
a - fixIO (\a - mkFooCB (callBack a));
register a with the window system
}

callBack :: Addr - Int - Int - IO ()
callBack a x y = do {  unregister a with window system
... whatever .. }

Isn't that enough?

Simon

 -Original Message-
 From: Sven Panne [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, April 13, 1999 10:09 AM
 To: GHC Users
 Subject: Re: Q: Threads in GHC's RTS
 
 
 "Sigbjorn Finne (Intl Vendor)" wrote:
  [...]Good point, I've committed a fix for this.
 
 Adjustor.c gets more and more impressive.  :-)   BTW: What is the
 schedule for porting (i.e. completely rewriting) Adjustor.c to
 non-Intel platforms?
 
  If I understand your scenario right, that only leaves getting at
  the address of the old-Haskell-callback-to-be-nuked, but it's
  reachable without too much bother..?
 
 That heavily depends on the kind of API one is trying to interface
 with. In GLUT "global" callbacks (for keyboard/mouse/timer/...) are
 the easy part, because for any event there is at most one registered
 callback. In these cases, the IORef+unsafePerformIO hack suffices.
 Things get more complicated for per-window callbacks, and I think
 Manuel will have fun with the per-widget callbacks. Some kind of table
 mapping the callback to be unregistered to the Addr from f.e.d. will
 be necessary here. But this is all API-specific, so I fear it's hard
 to come up with a better general design for creating and destroying
 callbacks.
 
 If you are willing to make the memory management visible in the
 Haskell binding of an API, there's another possibility: Every callback
 is augmented by an additional parameter. To be more concrete, let's
 assume the API has "foo" callbacks, expecting two Ints:
 
foreign export ccall dynamic mkFooCB :: (Int - Int - IO 
 ()) - IO Addr
foreign import ccall registerFoo :: Addr - IO ()
 
 Then you simply extend your Haskell callback by the f.e.d.-generated
 Addr and tie a knot:
 
myCallback :: Addr - Int - Int - IO ()
myCallback self x y = do
   ...
   freeHaskellFunctionPtr self
   ...
 
main = do
   ...
   let addr = mkFooCB (myCallback addr)
   registerFoo addr
 
 Cheers,
Sven
 
 P.S.: Something completely unrelated: Why is majordomo.haskell.org
   expanded to scarlet.cam.uk.eu.microsoft.com in the To:-field?
   IMHO this is a bad idea, e.g. when people cut-and-paste this
   into their address books and scarlet is renamed to e.g. 
 rhett. :-)
 
 P.P.S.: Adding a prefix in the Subject:-field (e.g. [ghcu]) would make
 mail filters work more reliably. Lots of other mailing lists
 do something similar.
 -- 
 Sven PanneTel.: 
 +49/89/2178-2235
 LMU, Institut fuer Informatik FAX : 
 +49/89/2178-2211
 LFE Programmier- und Modellierungssprachen  
 Oettingenstr. 67
 mailto:[EMAIL PROTECTED]
 D-80538 Muenchen
 http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne