ghci, -O

2001-05-02 Thread S.D.Mechveliani

I fear there is certain misunderstanding about  -O  usage with
ghc-5.00 interactive.

Simon Marlow  and  User's Guide (Section 4.4)  say that  

 -O does not work with  ghci.
 For technical reason, the bytecode compiler doesn't interact 
 well with one of the optimization passes
 [..]

What is a bytecode compiler? 
The one that prepares a lightly compiled code for the interpreter?

What I meant is something like this: 
to compile   ghc -c -O Foo.hs
in the batch mode and then run   ghci 
 ...
 Preude :load Foo 
 ...
 Foo sm [1..000]

I tried this with certain small function  Foo.sm,  and it works,
and runs better than when compied with -Onot.

Now, as I see that  ghci  can load and run the code made by  -O,
I wonder what the User's Guide means by saying 
-O does not work with  GHCi. Maybe   ghci -O  ?
could be meaningful?

-
Serge Mechveliani
[EMAIL PROTECTED]










___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



catchAllIO

2001-05-02 Thread Johannes Waldmann

Dear all, I keep getting problems with expections. In the example

catchAllIO ( action ) $ \ any - return foo

is it guaranteed that *no* exception that is raised in `action' 
propagates to the outside?

(This is with ghc-4.08. Should I upgrade? Well, I will upgrade
sometime anyway, but would it help with respect to this problem?)

Regards,
-- 
-- Johannes Waldmann  http://www.informatik.uni-leipzig.de/~joe/ --
-- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 --

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



Exceptions and sockets

2001-05-02 Thread Johannes Waldmann

OK now I upgraded to ghc-5.00 but the situation didn't change.
My suspicion is that it's not the fault of `catch'.

I think what happens is this:
I `Socket.accept' a connection and get a handle.
Now, if the connections dies, but I still write to the handle,
the whole thing crashes - without throwing an exception.
(I checked that the RTS thinks  `hIsWritable h'
even if `h' does no longer exist in reality.)

How could I work around this? SocketPrim?
-- 
-- Johannes Waldmann  http://www.informatik.uni-leipzig.de/~joe/ --
-- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 --

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



Re: Exceptions and sockets

2001-05-02 Thread Volker Stolz

In local.glasgow-haskell-users, you wrote:
I `Socket.accept' a connection and get a handle.
Now, if the connections dies, but I still write to the handle,
the whole thing crashes - without throwing an exception.
(I checked that the RTS thinks  `hIsWritable h'
even if `h' does no longer exist in reality.)

Looks to me like you're forgetting that the OS will give you a
sigPIPE on (semi-)closed sockets, which translates to a segfault
unless you install a signal handler:

 - http://www.haskell.org/ghc/docs/latest/set/socket.html#AEN13989
 - socket(2)
-- 
Abstrakte Syntaxträume.
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



RE: ghci, -O

2001-05-02 Thread Simon Marlow

 Now, as I see that  ghci  can load and run the code made by  -O,
 I wonder what the User's Guide means by saying 
 -O does not work with  GHCi. Maybe   ghci -O  ?
 could be meaningful?

ghci -O is exactly the combination that doesn't work.

Cheers,
Simon

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



Re: GHC and the Lazy Functional State Threads Paper

2001-05-02 Thread Thomas Pasch

 So you can fix it for example by using a specialized version of
 freezeArr inside accumArray, of type
 (Ix i, IArray a e) = STArray s i e - ST s (a i e)
 This will give quite general type of accumArray: arbitrary immutable
 array from the IArray class.

freezeArr2:: (Ix i, IArray.IArray a e) = STArray s i e - ST s (a i e)
freezeArr2 = MArray.freeze

 If the immutable array type used was particularly UArray, it would
 be more efficient to use the corresponding STUArray instead of
 STArray, so freezing could just copy a memory block (there are magic
 specializations in ghc's libraries for such case). But if the element
 type was to remain generic, the type would have to be constrained
 over STUArray

freezeArr3:: 
  (Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e) 
  = (MArray.STUArray s i e) - ST s (a i e)
freezeArr3 = MArray.freeze

Is this the way to do it? I wonder a bit if this triggers the 
optimization if 'a' is of type STUArray. (By the way I still have 
problems to see where unboxed values are a good thing and were 
you should better avoid them.)

In addition I wonder why there are so many array types. Are both
STArray and IOArray really necessary and what's the difference 
between them? What about DiffArray? I'm still surprised by operations
like 'unsafeFreezeArray' and 'freezeArray'. Shouldn't the 
garbage collector juge if there are still other references
to a distinct object?

Regards,

Thomas

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users