Re: Concurrency and interactive input
Hi,
I suspect you're using ghc on a win32 platform. ghc-win32 doesn't
presently support non-blocking I/O, hence the behaviour you're
seeing.
--sigbjorn
- Original Message -
From: Walker Duhon
To: [EMAIL PROTECTED]
Sent: Wednesday, October 30, 2002 18:02
Subject: Concurrency and interactive input
Hello,
I am playing around with concurrency using ghc 5.02.2. What I'd
like to do is have a bunch of threads do something indefinitely, while one
thread monitors stdin for user input (the user input affects the behavior of
the other threads in some way). From the documentation I had assumed that
standard Haskell I/O functions (like getline) would not block other running
threads, but this doesn't seem to be the case as illustrated here:
conTry3 = forkIO (loop 'a') >> quitYet
where
loop ch = hPutChar stdout ch >> loop ch
quitYet = do
x <- getLine
if x == "quit" then return ()
else quitYet
Output: (stuff in between {} is a comment, and not part of the output)
rere
ttt
fff
dfsd
fgfg
fgfg
aa { and on and on }
dfdf
dfd
fdfd
fgfg
fgf
{ and on and on }
quit
aaa { and on and on }
{program ends}
The behavior I wanted was for 'a' to be printed (almost) continuously, echo
the relatively infrequent input, and quit upon receiving "quit".
I am aware (through a web search) that there was a mail thread
addressing a similar issue a while back (1999) entitled:
I thought concurrent haskell was _preemptive_!
That thread made it seem like the issue would be cleared up
soon.
In any case, I would still like to be able to have an interactive input
thread that doesn't block everything in my program.
Is there any way to do this?
Thanks in advance,
Walker
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Concurrency and interactive input
Hello,
I
am playing around with concurrency using ghc 5.02.2. What I’d like
to do is have a bunch of threads do something indefinitely, while one thread
monitors stdin for user input (the user input affects the behavior of the other
threads in some way). From the documentation I had assumed that standard Haskell
I/O functions (like getline) would not block other running threads, but this
doesn’t seem to be the case as illustrated here:
conTry3 = forkIO (loop 'a') >> quitYet
where
loop ch = hPutChar stdout ch >> loop ch
quitYet = do
x <- getLine
if x == "quit" then return ()
else quitYet
Output: (stuff in between {} is a comment, and not part of
the output)
rere
ttt
fff
dfsd
fgfg
fgfg
aa { and on and on }
dfdf
dfd
fdfd
fgfg
fgf
{ and on and on }
quit
aaa { and on and on }
{program ends}
The behavior I wanted was for ‘a’ to be printed
(almost) continuously, echo the relatively infrequent input, and quit upon
receiving “quit”.
I
am aware (through a web search) that there was a mail thread addressing a
similar issue a while back (1999) entitled:
I thought concurrent haskell
was _preemptive_!
That
thread made it seem like the issue would be cleared up soon.
In any case, I would still like to be able to have an interactive input
thread that doesn’t block everything in my program.
Is there any way to do this?
Thanks in advance,
Walker
Re: FFI & C++
Wolfgang, On Solaris, you can build GNU C++ either way; that is, to use shared libraries or linked libraries. (In fact you can also build it to enable both, and select one or the other at link time.) So, this is certainly worth checking. The easiest way to check it is to run "ldd -r" on the executable. On Wed, 2002-10-30 at 15:53, Wolfgang Thaller wrote: > Many platforms have the C++ runtime and the C++ standard library as a > static library (probably because the C++ ABI is not as stable as it > should be...). I think this applies to both Mac OS and to Windows > [mingw32], perhaps it's the same with Solaris. > If that is the case, it would explain the problem, I think. > > GHCi can't load static libraries [yet - the ar format shouldn't be too > difficult to implement], so everything that's needed from static > libraries has to be linked into the ghc binary and probably also listed > in Linker.c (who else doesn't like those hard-coded symbol references?) > > Just my EUR 0.02 :-) > > Cheers, > Wolfgang > > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI & C++
Many platforms have the C++ runtime and the C++ standard library as a static library (probably because the C++ ABI is not as stable as it should be...). I think this applies to both Mac OS and to Windows [mingw32], perhaps it's the same with Solaris. If that is the case, it would explain the problem, I think. GHCi can't load static libraries [yet - the ar format shouldn't be too difficult to implement], so everything that's needed from static libraries has to be linked into the ghc binary and probably also listed in Linker.c (who else doesn't like those hard-coded symbol references?) Just my EUR 0.02 :-) Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI & C++
On 30 Oct 2002, Seth Kurtzberg wrote: > What is the O/S and compiler? That the C++ new operator is not found is > very strange. Throw is another story, as throw doesn't appear in the > compiled code with some compilers. We run Solaris + gcc 2.95.3. The exact error message looks like this: Prelude> :set -package satnik Loading package satnik ... linking ... /.../chalmers.se/fs/cab/cs/work/proj/formal-methods/home/src/fm/HSatnik/Satnik.o: unknown symbol `__builtin_new' ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): can't load package `satnik' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. ... which to me seems like it cannot find new. /Niklas ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI & C++
What is the O/S and compiler? That the C++ new operator is not found is very strange. Throw is another story, as throw doesn't appear in the compiled code with some compilers. On Wed, 2002-10-30 at 04:18, Simon Marlow wrote: > > I am currently trying to create a Haskell interface to a C++ > > library and > > cannot get it to work completely. The problem seems to be > > that the linker > > must be able to find the code for basic C++ constructs like > > new and throw. > > Apparently it is able to do so when compiling an executable, > > but when I > > try to do the same with ghci it fails. Anybody have an idea why this > > happens and what to do about it? > > I don't know the gory details, but it might be that we would have to link GHCi with >the C++ linker for this to work. Would anyone with a clue about C++ linking like to >comment? > > > The feature to install local packages is currently a bit > > awkward. I would > > like to be able to simply use a local package the same way I > > use a normal > > package, and my first try was to set the package-conf file in my .ghci > > file. But this doesn't work very well for two reasons: (1) it > > only works > > for the interpreter, but not for the compiler (2) it isn't read until > > *after* the command line is read, so any packages given there is not > > recognized. Is it possible to have a common (.ghc) file that > > is used for > > both the compiler and the interpreter, and that is read *before* the > > command line is interpreted? > > Hmm, I must admit I'm a bit averse to adding features like this unless they are >really necessary. One problem is that when someone submits a bug report, we'll have >to start asking "do you have a .ghc file? what does it contain?". The current >situation has the advantage of being simple. > > Can't you just alias ghc to 'ghc -package-conf ...'? > > Cheers, > Simon > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: compiling big files?
> I have occasional problems getting ghc-5.04.1 to compile a very large > source file with -O switched on. The source file is generated by > another tool, and is rather large at 25762 lines (2776340 bytes). > > Without -O, the compilation goes normally, taking about 10 > minutes or so. > > With -O, the compiler uses >280Mb of memory, which causes my machine > with only 256Mb to swap like crazy, but that is OK, because > after about > half an hour, ghc produces its output in a .hc file. The C compiler > (gcc-2.95.3) then produces a .raw_s file: > > $ wc /tmp/ghc* > 759338 837040 18321347 /tmp/ghc3992.hc > 1711905 3174489 32014101 /tmp/ghc3992.raw_s eek! :-S > It's the next stage, when (I presume) the ghc-mangler converts the > .raw_s file to a simpler .s file, that doesn't run to completion. > It simply reports > > Killed > make: *** [targets/ix86-Linux/hat-lib-ghc] Error 2 > > It seems that if I re-run ghc on the intermediate .hc file that > was left behind in the /tmp directory, then the mangler is ok, > and assembly proceeds right up to the .o file. > > So is there any (fixable) reason why the one-step invocation fails, > but the two-step invocation succeeds? I have no idea what might cause this. If you put the .hc up for download somewhere, I'll take a look. In the meantime, you might want to try using the native code generator instead. Just add -fasm to the command line. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
compiling big files?
I have occasional problems getting ghc-5.04.1 to compile a very large source file with -O switched on. The source file is generated by another tool, and is rather large at 25762 lines (2776340 bytes). Without -O, the compilation goes normally, taking about 10 minutes or so. With -O, the compiler uses >280Mb of memory, which causes my machine with only 256Mb to swap like crazy, but that is OK, because after about half an hour, ghc produces its output in a .hc file. The C compiler (gcc-2.95.3) then produces a .raw_s file: $ wc /tmp/ghc* 759338 837040 18321347 /tmp/ghc3992.hc 1711905 3174489 32014101 /tmp/ghc3992.raw_s It's the next stage, when (I presume) the ghc-mangler converts the .raw_s file to a simpler .s file, that doesn't run to completion. It simply reports Killed make: *** [targets/ix86-Linux/hat-lib-ghc] Error 2 It seems that if I re-run ghc on the intermediate .hc file that was left behind in the /tmp directory, then the mangler is ok, and assembly proceeds right up to the .o file. So is there any (fixable) reason why the one-step invocation fails, but the two-step invocation succeeds? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI & C++
> I am currently trying to create a Haskell interface to a C++ > library and > cannot get it to work completely. The problem seems to be > that the linker > must be able to find the code for basic C++ constructs like > new and throw. > Apparently it is able to do so when compiling an executable, > but when I > try to do the same with ghci it fails. Anybody have an idea why this > happens and what to do about it? I don't know the gory details, but it might be that we would have to link GHCi with the C++ linker for this to work. Would anyone with a clue about C++ linking like to comment? > The feature to install local packages is currently a bit > awkward. I would > like to be able to simply use a local package the same way I > use a normal > package, and my first try was to set the package-conf file in my .ghci > file. But this doesn't work very well for two reasons: (1) it > only works > for the interpreter, but not for the compiler (2) it isn't read until > *after* the command line is read, so any packages given there is not > recognized. Is it possible to have a common (.ghc) file that > is used for > both the compiler and the interpreter, and that is read *before* the > command line is interpreted? Hmm, I must admit I'm a bit averse to adding features like this unless they are really necessary. One problem is that when someone submits a bug report, we'll have to start asking "do you have a .ghc file? what does it contain?". The current situation has the advantage of being simple. Can't you just alias ghc to 'ghc -package-conf ...'? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: crash in profiling mode
> Another question: The profiling mode of GHC-4.08.2 did also output (in > mode +RTS -p) the time spent on garbage collection (as an additional > percentage of overall running time). > With the programs I tested so far under GHC-5.04.1, I never > saw such an > indication in a.out.prof, although for the same programs under > GHC-4.08.2 considerable garbage collection times were measured. > > Does this mean that: > > a) the indication of garbage collection times has been dropped from > profiling reports (can I obtain them in another way?), > > or > > b) the newer GHC is so smart that it optimised away the need for > garbage collection in the particular (few) programs I tested, but > otherwise the GC times will show up in profiling reports, > > or > > c) something else? The inclusion of GC time in the report was wrong, since GC time wasn't included in the figure for total time, so you could get GC times of > 100%. You can get a measure of GC time vs. mutator time by adding '+RTS -sstderr' to the command line. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimisation and unsafePerformIO
- Original Message -
From: "Albert Lai" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 30, 2002 7:35 AM
Subject: Re: Optimisation and unsafePerformIO
> "David Sabel" <[EMAIL PROTECTED]> writes:
>
> > {-# NOINLINE b #-}
> >
> > b x = if even x then unsafePerformIO getChar else bot
> >
> > bot = bot
> >
> > main = do
> > putChar (b 4)
> > putChar (b 6)
>
> I am not a compiler implementer (or lawyer, for that matter :)
> But I propose this guess. First, both even 4 and even 6 get
> constant-folded to True; so b 4 and b 6 both become unsafePerformIO
> getChar. Then there is a common subexpression elimination.
No! I used the option -fno-cse, what means that common supexpression
elimination is turned off.
> ___
> Glasgow-haskell-users mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: crash in profiling mode
Simon Marlow wrote: > > > I have a problem with profiling using a freshly installed GHC > > 5.04 under Solaris. With the following program crash.lhs: > > Please install 5.04.1 instead, I believe this bug was fixed. Thanks, that indeed solved the problem. Another question: The profiling mode of GHC-4.08.2 did also output (in mode +RTS -p) the time spent on garbage collection (as an additional percentage of overall running time). With the programs I tested so far under GHC-5.04.1, I never saw such an indication in a.out.prof, although for the same programs under GHC-4.08.2 considerable garbage collection times were measured. Does this mean that: a) the indication of garbage collection times has been dropped from profiling reports (can I obtain them in another way?), or b) the newer GHC is so smart that it optimised away the need for garbage collection in the particular (few) programs I tested, but otherwise the GC times will show up in profiling reports, or c) something else? Regards, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@;tcs.inf.tu-dresden.de ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
