Glynn Clements | 1 Apr 2003 02:04
Favicon

RE: Patches for NetBSD port and automatic .hc bootstrap (long)


Simon Marlow wrote:

> Incidentally, why are the -Wl,-R<dir> options needed?  I've never come
> across that before, usually the runtime linker just finds the libraries
> in the place they were originally linked from.

The runtime linker will use the first matching library it finds, which
isn't necessarily the same one that was used in the linking step. The
-R switch will cause the runtime linker to search specified directory
before the "normal" library directories (e.g. /usr/lib).

--

-- 
Glynn Clements <glynn.clements <at> virgin.net>
Urban Boquist | 1 Apr 2003 08:55
Picon

RE: Patches for NetBSD port and automatic .hc bootstrap (long)

>>>>> Simon Marlow writes:

Simon> I've committed most of your patches...

Great, thanks for the quick response!

>> -L/usr/pkg/lib -Wl,-R/usr/pkg/lib

Simon> Incidentally, why are the -Wl,-R<dir> options needed?

Ah, yes, I guess I should have commented on that. In its continuous
quest to do things The Right Way (TM), NetBSD has decided to not do
what many other systems do, i.e., automatically add linker run path
flags for each -L flag. Instead you must give explicit run path flags
for each runtime library location. Really, this makes a lot of sense
if you think about it. There is no reason that a library should be
located at the same place during both build time and run time (think
cross compiling and such).

The NetBSD runtime linker can also use things like /etc/ld.so.conf and
LD_LIBRARY_PATH, for executables that don't have correct rpaths in
them, but you can't trust /usr/pkg/lib to be found that way for all
NetBSD systems.

Simon> Note that HC files can also be platform dependent, since they
Simon> depend in some cases on the values of symbols from config.h.
Simon> We used to try to keep .hc files completely
Simon> platform-independent, but I've come around to the conclusion
Simon> that this isn't a realistic goal.

(Continue reading)

Simon Peyton-Jones | 1 Apr 2003 18:42
Picon
Favicon
Gravatar

RE: GHC's readLitChar does not conform to 98

Excellent point, thank you.  A bogon. Fixed in the HEAD, and a
regression test added

Simon

| -----Original Message-----
| From: Akim Demaille [mailto:akim <at> epita.fr]
| Sent: 05 March 2003 13:50
| To: glasgow-haskell-users <at> haskell.org
| 
| Hi!
| 
| I believe the implementation of readLitChar (and lexLitChar) does not
| conform to the documentation, and this results in GHC and Hugs
| disagreeing on the following code:
| 
| ----------------------------------------
| module Main (main)
| where
| 
| import IO (stderr, hPutStrLn)
| import Char (digitToInt, lexLitChar, readLitChar)
| 
| main :: IO ()
| main =
|     do hPutStrLn stderr (show $ readLitChar "A")
|        hPutStrLn stderr (show $ readLitChar "'A'")
| ----------------------------------------
| 
| ghc says:
(Continue reading)

Simon Marlow | 2 Apr 2003 11:52
Picon
Favicon

RE: ptrace for profiling?


> this may be a totally absurd request, but would it be possible to use
> ptrace or some other mechanism for poking a running program to cause a
> program to start generating profiling data or change what type of
> profiling data it is producing? 
> 
> I tend to view the profiling graph in real-time as I run my Haskell
> program interactively. every now and again I notice my program is
> behaving oddly but I am unable to reproduce the events that led to the
> odd behavior. It would be nice to be able to poke the program 
> in such a
> way to cause it to start writing profiling frames to the stack for a
> bit. 

Hmmm.  It might be possible to turn on profiling (time or space) for a
running program, but that would doubtless require quite a few changes to
the runtime.  The program has to be compiled for profiling to begin
with, of course.

There are certain changes that it isn't possible to make in the middle
of a run (e.g. changing from retainer to biographical profiling sounds
highly implausible, if not impossible).

You can run the program in gdb, stop at a certain point (eg. before a
GC) and change the profiling flags (RtsFlags.ProfFlags.*) and see what
happens...  you'll need to compile up an RTS with debugging info (see
config.mk for details) and link to it (-L should do the trick).

Cheers,
	Simon
(Continue reading)

David Sabel | 2 Apr 2003 14:31
Picon
Picon

Modifying the simplifier

Is there an easy way to turn off some of the local transformations in
the simplifier?

The background:
I'm writing my master thesis about compiling the unsafePerformIO in a "safe"
way
in the ghc. For that I used a nondeterministic semantics which simulates the
IO.
After a lot of theoretical work it has pointed out, that some of the local
transformations
of the ghc are no longer correct (from my point of view). Now I want to
implement a prototype by
modifying the ghc. Especially the eta-expansion, case-elimination must be
turned off,
inling in general is'nt correct too, so I would like to turn it off for now
and
later modify the implementation for this transformation.

David Sabel
-----------
JWGU Frankfurt
zeynep | 3 Apr 2003 05:02
Picon
Favicon

slm

merhaba tatlim bana bi iyilik yap buraya gir

zeynep | 3 Apr 2003 05:03
Picon
Favicon

slm

merhaba tatlim bana bi iyilik yap buraya gir

Ahn Ki-yung | 3 Apr 2003 18:25

How is non-blocking IO working ?

Document says GHC uses non-blocking IO to be
thread friendly. But if it continues to poll on the
non blocking file descriptor. It should cost much
CPU load, but actually it doesn't :
for example if a server is wating an input from
a connected client, say using hGetLine, until
input comes in from the network it should
continue to poll until it succeeds to get some
messages. But this does not seem to happen,
if I look at the prcessor activity using 'top'.
It does not consume CPU same as a blocked
processed by blocked IO.

How is non-blocking and thread working ?
I can't understand.
Alastair Reid | 3 Apr 2003 19:05
Picon

Re: How is non-blocking IO working ?


Ahn Ki-yung <kyagrd <at> hitel.net> writes:

> Document says GHC uses non-blocking IO to be thread friendly. 
> [...]
> How is non-blocking and thread working ?  I can't understand.

This is usually implemented using 'select' (see attached man page).

In a multithreaded program where you have user-level threads (which
is, effectively, what GHC's threads provide), you typically maintain a
global set of all file descriptors that a thread is trying to read
from.  There are then two cases:

1) If there are no runnable threads, call 'select' on all threads
   using a NULL timeout.

2) If there are runnable threads, you can use 'select' with a timeout
   of 0 to poll for readable file descriptors every N seconds.  The
   number N should be chosen low enough to have low latency and high
   enough to have low overhead.

An alternative that works on some operating systems is to use
asynchronous I/O calls.  The problem is that this isn't as portable as
using select.

Hope this helps.

--
Alastair Reid                 alastair <at> reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/

SELECT(2)                  Linux Programmer's Manual                 SELECT(2)

NAME
       select,  pselect,  FD_CLR,  FD_ISSET, FD_SET, FD_ZERO - synchronous I/O
       multiplexing

SYNOPSIS
       /* According to POSIX 1003.1-2001 */
       #include <sys/select.h>

       /* According to earlier standards */
       #include <sys/time.h>
       #include <sys/types.h>
       #include <unistd.h>

       int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
       struct timeval *timeout);

       int   pselect(int   n,   fd_set   *readfds,  fd_set  *writefds,  fd_set
       *exceptfds, const struct timespec *timeout, const sigset_t *sigmask);

       FD_CLR(int fd, fd_set *set);
       FD_ISSET(int fd, fd_set *set);
       FD_SET(int fd, fd_set *set);
       FD_ZERO(fd_set *set);

DESCRIPTION
       The functions select and pselect wait for a number of file  descriptors
       to change status.

       Their function is identical, with three differences:

       (i)    The  select  function  uses  a  timeout that is a struct timeval
              (with seconds and microseconds), while  pselect  uses  a  struct
              timespec (with seconds and nanoseconds).

       (ii)   The select function may update the timeout parameter to indicate
              how much time was left. The pselect  function  does  not  change
              this parameter.

       (iii)  The  select  function  has  no sigmask parameter, and behaves as
              pselect called with NULL sigmask.

       Three independent sets of descriptors are  watched.   Those  listed  in
       readfds will be watched to see if characters become available for read-
       ing (more precisely, to see if a read will not block - in particular, a
       file  descriptor  is also ready on end-of-file), those in writefds will
       be watched to see if a write will not block,  and  those  in  exceptfds
       will  be  watched  for  exceptions.   On exit, the sets are modified in
       place to indicate which descriptors actually changed status.

       Four macros are provided to manipulate the sets.  FD_ZERO will clear  a
       set.   FD_SET  and  FD_CLR add or remove a given descriptor from a set.
       FD_ISSET tests to see if a descriptor is part of the set; this is  use-
       ful after select returns.

       n  is the highest-numbered descriptor in any of the three sets, plus 1.

       timeout is an upper bound on the amount of time elapsed  before  select
       returns. It may be zero, causing select to return immediately. (This is
       useful for polling.) If timeout is NULL (no timeout), select can  block
       indefinitely.

       sigmask  is  a  pointer to a signal mask (see sigprocmask(2)); if it is
       not NULL, then pselect first replaces the current signal  mask  by  the
       one  pointed  to  by sigmask, then does the `select' function, and then
       restores the original signal mask again.

       The idea of pselect is that if one wants to wait for an event, either a
       signal  or  something on a file descriptor, an atomic test is needed to
       prevent race conditions. (Suppose the signal handler sets a global flag
       and  returns.  Then  a  test  of this global flag followed by a call of
       select() could hang indefinitely if the signal arrived just  after  the
       test but just before the call. On the other hand, pselect allows one to
       first block signals, handle the signals that have come  in,  then  call
       pselect()  with  the  desired sigmask, avoiding the race.)  Since Linux
       today does not have a pselect() system call, the current glibc2 routine
       still contains this race.

   The timeout
       The time structures involved are defined in <sys/time.h> and look like

              struct timeval {
                  long    tv_sec;         /* seconds */
                  long    tv_usec;        /* microseconds */
              };

       and

              struct timespec {
                  long    tv_sec;         /* seconds */
                  long    tv_nsec;        /* nanoseconds */
              };

       Some  code  calls  select with all three sets empty, n zero, and a non-
       null timeout as a fairly portable way to sleep  with  subsecond  preci-
       sion.

       On Linux, the function select modifies timeout to reflect the amount of
       time not slept; most other implementations do not do this.  This causes
       problems  both  when  Linux code which reads timeout is ported to other
       operating systems, and when code is  ported  to  Linux  that  reuses  a
       struct  timeval  for  multiple selects in a loop without reinitializing
       it.  Consider timeout to be undefined after select returns.

RETURN VALUE
       On success, select and pselect return the number  of  descriptors  con-
       tained in the descriptor sets, which may be zero if the timeout expires
       before anything interesting happens.  On error,  -1  is  returned,  and
       errno  is  set appropriately; the sets and timeout become undefined, so
       do not rely on their contents after an error.

ERRORS
       EBADF  An invalid file descriptor was given in one of the sets.

       EINTR  A non blocked signal was caught.

       EINVAL n is negative.

       ENOMEM select was unable to allocate memory for internal tables.

EXAMPLE
       #include <stdio.h>
       #include <sys/time.h>
       #include <sys/types.h>
       #include <unistd.h>

       int
       main(void) {
           fd_set rfds;
           struct timeval tv;
           int retval;

           /* Watch stdin (fd 0) to see when it has input. */
           FD_ZERO(&rfds);
           FD_SET(0, &rfds);
           /* Wait up to five seconds. */
           tv.tv_sec = 5;
           tv.tv_usec = 0;

           retval = select(1, &rfds, NULL, NULL, &tv);
           /* Don't rely on the value of tv now! */

           if (retval)
               printf("Data is available now.\n");
               /* FD_ISSET(0, &rfds) will be true. */
           else
               printf("No data within five seconds.\n");

           return 0;
       }

CONFORMING TO
       4.4BSD (the select  function  first  appeared  in  4.2BSD).   Generally
       portable  to/from  non-BSD  systems supporting clones of the BSD socket
       layer (including System V variants).  However, note that the  System  V
       variant  typically  sets  the timeout variable before exit, but the BSD
       variant does not.

       The pselect function is defined in IEEE  Std  1003.1g-2000  (POSIX.1g),
       and  part  of  POSIX  1003.1-2001.   It is found in glibc2.1 and later.
       Glibc2.0 has a function with this name, that however does  not  take  a
       sigmask parameter.

NOTES
       Concerning  prototypes,  the  classical  situation  is  that one should
       include <time.h> for select.  The POSIX 1003.1-2001 situation  is  that
       one  should  include  <sys/select.h> for select and pselect.  Libc4 and
       libc5 do not have a <sys/select.h> header; under glibc  2.0  and  later
       this header exists.  Under glibc 2.0 it unconditionally gives the wrong
       prototype for pselect, under glibc  2.1-2.2.1  it  gives  pselect  when
       _GNU_SOURCE  is  defined,  under  glibc  2.2.2-2.2.4  it  gives it when
       _XOPEN_SOURCE is defined and has a value of 600 or larger.   No  doubt,
       since POSIX 1003.1-2001, it should give the prototype by default.

SEE ALSO
       For a tutorial with discussion and examples, see select_tut(2).

       For vaguely related stuff, see accept(2), connect(2), poll(2), read(2),
       recv(2), send(2), sigprocmask(2), write(2)

Linux 2.4                         2001-02-09                         SELECT(2)
Ahn Ki-yung | 4 Apr 2003 07:56

FFI and Concurrency

C call blocks the whole process, and Concurret
module become meaningless. Isn't there any
library or wrapper that can avoid ccall from
blocking entire process ?

--

-- 
Ahn Ki-yung

Gmane