[Haskell-cafe] Stack overflow in simple code with getStdRandom / randomR (GHC)
The following three-liner creates a stack overflow (on my machine, MacOS), and I'm a bit puzzled as to why: import System.Random main = do mapM (const (getStdRandom (randomR (0, 5::Int [0..1000] botanix:~ stolz$ ./a.out Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. Yes, the list is quite long, but somehow I'd expected mapM to chug slowly along...printing Hello World doesn't create a stack overflow either, after all. My Haskell-foo has become a bit rusty, but I was wondering where I am missing a point or two here (and I couldn't find the correct profiler incantation that would give me more than a big black blob for the main-CAF). GHC is 6.12.3 on MacOS. Cheers, Volker ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack overflow in simple code with getStdRandom / randomR (GHC)
Blimey, I didn't notice that Krzysztof came to the same conclusion a bit earlier today, so I guess the answer is somewhere in his remark One possible solution is to make cell holding std gen strict.. I'd still be interested in how to profile for this scenario, though. -Volker ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: threadDelay not ending
* Rich Fought [EMAIL PROTECTED]: I've got some unit test code that forks off test processes using the 'system' function and then delays using 'threadDelay' to synchronize with the test process. This has worked fine until I upgraded to 6.4.2, now some of the 'threadDelay' calls never return - it's like they are stuck in limbo. You could build an RTS with debugging support to see what is going on. Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FreeBSD [Re: 6.4.2 under solaris]
Oh great, I'm stuck when building ghc-6.4.2--but at least there's no space leak ;) [This is in the FreeBSD port after going stage2 from a bootstrap build, I think] PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 67244 stolz 1 137 10 40204K 37848K RUN687:59 79.83% ghc-6.4.2 At: rm -f Foreign/C/Types.p_o; if [ ! -d Foreign/C/Types_split ]; then mkdir Foreign/C/Types_split; else /usr/bin/find Foreign/C/Types_split -name '*.p_o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Foreign/C/Types.hs -o Foreign/C/Types.p_o -ohi Foreign/C/Types.p_hi Looks like again some libc internal problem related to threading: [EMAIL PROTECTED] [09:00:06] kdump | head 67244 ghc-6.4.2 CALL kse_release(0xbfbfbd80) 67244 ghc-6.4.2 RET kse_release -1 errno 22 Invalid argument 67244 ghc-6.4.2 CALL kse_release(0xbfbfbd80) 67244 ghc-6.4.2 RET kse_release -1 errno 22 Invalid argument 67244 ghc-6.4.2 CALL kse_release(0xbfbfbd80) 67244 ghc-6.4.2 RET kse_release -1 errno 22 Invalid argument (KSEs are 'kernel scheduling entities') Unfortunately, I didn't have any coffee yet, so I killed it instead of trying to get a core dump. After restarting the build, it works w/o problems. Volker -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.2 under solaris
* Christian Maeder [EMAIL PROTECTED]: P.S. the non-termination of the final stage2 compiler still needs further investigation (that I cannot do alone) How about throwing 'truss' at it? Maybe this reveals a blatant reason. Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME FIFA go home! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 under solaris
* Christian Maeder [EMAIL PROTECTED]: I also had to adapt again the call of ctime_r in ghc/rts/RtsUtils.c #if HAVE_CTIME_R - ctime_r(now, nowstr, 26); + ctime_r(now, nowstr); #else 26 is supposed to be the size of the buffer nowstr. Maybe 27 is also fine? According to the man pages ctime_r is different under linux and solaris. How should that be patched? Without the 3rd arg is according to POSIX (check your Solaris man page). 'buf' is required to be at least 26 bytes. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME All the excitement lies in pattern matching. (SPJ et al.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 under solaris
Am 20. Apr 2006 um 11:19 CEST schrieb Christian Maeder: Volker Stolz wrote: Without the 3rd arg is according to POSIX (check your Solaris man page). 'buf' is required to be at least 26 bytes. You're right, but it does not compile without the 3rd argument! Maybe this is due to gcc_4.0.3_s10 ? Should one simply rely on ctime? Now I'm confused...or is the patch reverted? It said: #if HAVE_CTIME_R - ctime_r(now, nowstr, 26); + ctime_r(now, nowstr); #else This has got nothing to do with GCC, it's only related to system headers. Quoth SunOS 5.9: SYNOPSIS #include time.h char *ctime_r(const time_t *clock, char *buf, int buflen); ... POSIX cc [ flag... ] file... -D_POSIX_PTHREAD_SEMANTICS [ library... ] char *ctime_r(const time_t *clock, char *buf); From my understanding of the patch above (*removing* the 3rd arg), I assumed that -D_POSIX_PTHREAD_SEMANTICS was set. It should probably be set like somewhere else (in libraries/bases/cbits/dirUtils.c), but I strongly suggest not doing this in the same (ie. through #define), but rather indeed setting it as a compiler flag. Otherwise, one of those days we'll get bitten by compiling something with skewed headers. Due to the plethora of variables in rts/Makefile, I'm a bit at a loss where to stick this in. -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2.20060411 under solaris
* Simon Marlow [EMAIL PROTECTED]: This bit of Makefile code is possibly going wrong for you: -include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/config.mk -include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/version.mk Try this instead: $ make Project=Ghc ProjectDirectory=ghc show VALUE=GhcBinDistDirs from the top level. Maybe that tr command doesn't work on Solaris? venus [14:45:44] echo foo | tr a-z A-Z foo venus [14:46:11] echo foo | tr [a-z] [A-Z] FOO From the man page: /usr/xpg4/bin/tr c-c /usr/bin/tr [c-c] Represents the range of collating elements between the Posix has this to say on the subject: On historical System V systems, a range expression requires enclosing square-brackets, such as: tr '[a-z]' '[A-Z]' However, BSD-based systems did not require the brackets, and this convention is used here to avoid breaking large numbers of BSD scripts: tr a-z A-Z The preceding System V script will continue to work because the brackets, treated as regular characters, are translated to themselves. However, any System V script that relied on a-z representing the three characters 'a' , '-' , and 'z' have to be rewritten as az- . Maybe it's safe to switch to the bracketed version these days... This also works fine on Linnix and FreeBSD. Finding the correct 'tr' on Solaris is probably more tedious. Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME All the excitement lies in pattern matching. (SPJ et al.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threaded runtime error
* Volker Stolz [EMAIL PROTECTED]: [EMAIL PROTECTED] [20:17:08] ./timeout 10 /usr/bin/true FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0) A workaround seems to use another threading library here. Both libthr and libc_r work at least for this small example. The error occurs on createOSThread(). I'm not sure where exactly (ie., for the child or the parent, but I guess the child). I'll keep on looking. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME All the excitement lies in pattern matching. (SPJ et al.) ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Allocating aligned memory?
* Li, Peng [EMAIL PROTECTED]: In GHC, how can I allocate a chunk of memory aligned to some block size (say, 512 or 1024 bytes)? I tried to specify it in the alignment method in the Storable typeclass, but that does not seem to work. Is Storable.alignment really used in GHC? If so, is there a code example that allocates aligned memory in this way? For the moment I am using the C function memalign() like this: From looking at the source, it looks like you may be right...allocation seems to only invoke plain malloc with just the size. However, as Claus already pointed out, you should be aware that memalign() isn't portable. Try using posix_memalign() if available, although even this function need not be provided on every platform... On the other hand, a system usually provides at least page-aligned memory if you request a chunk equal or larger to the page size, and page aligment should be sufficient for most of your needs. You could even build a small allocator on top for your favourite alignment :-D (I'm currently on a machine with page size=4k and no *memalign()). Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME All the excitement lies in pattern matching. (SPJ et al.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: error rebuilding ghc-6.4
* vadim [EMAIL PROTECTED]: when trying to rebuild ghc-6.4 from source, I fall into following error: gcc -o hp2ps -O -I../../includes -Wall AreaBelow.o AuxFile.o Axes.o Curves.o Deviation.o DimensiDeviation.o(.text+0x316): In function `Deviation': : undefined reference to `sqrt' For some reason you might be missing the LIBM=-lm in mk/config.mk. Keep an eye on configure's output and maybe start from a clean tree. (You should probably send follow-up to a more ghc-specific list). Cheers, Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME It's a million to one chance, but it just might work. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Bus Error with ghc 6.4 on Solaris
In gmane.comp.lang.haskell.glasgow.bugs, you wrote: Simon M is away today and Monday, but I do recall him saying something about the Solaris port being broken. I'm sure he would welcome help getting it fixed. Are there any of you who build GHC from source, and know Solaris? I'm currently running a build on $slowhost, so I probably won't get to actual debugging until Monday. We're talking about the release, not -HEAD, right? Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME It's a million to one chance, but it just might work. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new ghc under solaris
* Christian Maeder [EMAIL PROTECTED]: I used gcc_2.95.3 until I discovered the warning: LdvProfile.c:43: #error Please use gcc 3.0+ to compile this file with DEBUG; gcc 3.0 miscompiles it This usually happens if you use build.mk.sample. Simply remove the -DDEBUG from the options (unless of course you really want a debugging RTS which you usually don't). Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OpenAL builds despite --disable-openal
In gmane.comp.lang.haskell.glasgow.user, you wrote: Volker Stolz writes: Fix attached. Thank you! Is this patch gonna make it into CVS? Done. Sven is probably on vacations. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to NetBSD Alpha (alpha-unknown-netbsd)
In gmane.comp.lang.haskell.glasgow.user, you wrote: [missing ieee_fp_set_control] I've been staring at http://www.freebsd.org/cgi/man.cgi?query=ieee_set_fp_controlapropos=0sektion=0manpath=OSF1+V5.1%2Falphaformat=html to find out the correct fpset*()-function. fpsetmask() should do the trick, but I can't find the correct argument. Cheers, Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OpenAL builds despite --disable-openal (was: Error building GHC: can't locate import `Package')
In gmane.comp.lang.haskell.glasgow.user, you wrote:
It shouldn't even build OpenOL, however, because I ran
./configure with --disable-openal.
I see the flag in libraries/config.log, so it has been
passed through alright. But ${SUBDIRS} contains the OpenAL
directory nonetheless afterwards.
is neq to no, so the Makefile tries to build it. Fix attached.
Index: configure.ac
===
RCS file: /home/cvs/root/fptools/libraries/OpenAL/configure.ac,v
retrieving revision 1.8
diff -u -r1.8 configure.ac
--- configure.ac17 Dec 2004 00:09:08 - 1.8
+++ configure.ac20 Dec 2004 16:42:20 -
@@ -10,10 +10,10 @@
# Shall we build this package at all?
FP_ARG_OPENAL
-if test x$enable_openal = xyes; then
-
# We set this to yes later when we have found OpenAL libs and headers.
AL_BUILD_PACKAGE=no
+if test x$enable_openal = xyes; then
+
AC_SUBST([AL_BUILD_PACKAGE])
# The following test for the OpenAL library is a bit of a hack, but gives nice
--
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getUserEntryForName weirdness
In gmane.comp.lang.haskell.glasgow.user, you wrote: Is anyone else seeing this on his system? getUserEntryForName [] = print . userName wasabi Fixed in CVS -- I was only able to test this on SunOS where your example would segfault. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling from CVS on Sparc/Solaris
In gmane.comp.lang.haskell.glasgow.bugs, you wrote: Fair enough... The problem I'm having (which my proposed fix did in fact not solve) is that my readline libraries are in a non-standard location. Currently the final linking of stage1/ghc-6.2.2 (in this case) dies complaining about not finding -lreadline. What is the right way of letting ghc know where to look? Setting the environment variable LD_LIBRARY_PATH to the directory where libreadline lives should be sufficient. Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Preprocessors
The reason for this strange behaviour is that it's called *C*pp for a reason: There's even a remark on a cpp-info page: The interior of `#if 0' must consist of complete tokens; in particular, single-quote characters must balance. I'm still trying to find the apprioriate hint in the standard, though. If I'm reading this correctly, your incorrectly terminated C-string literal confuses cpp, so it won't do any macro expansion in the offending part (past the single quote). -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: linker errors
In gmane.comp.lang.haskell.glasgow.user, you wrote: When compiling using ghc, I get the following error: Parser.o(.text+0x10fc5): In function `r1fgN_entry': : undefined reference to `DataziTuple_Z77T_con_info' collect2: ld returned 1 exit status What platform and gcc? Could you please invoke ghc with -v and paste the output? Is this a ghc built from CVS or a binary version? Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Two more month. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: isEmptyChan, System.Posix.Signals
In local.glasgow-haskell-users, you wrote: 1. 'isEmptyChan x' blocks if x is empty and some other thread is waiting to read from x: Prelude Control.Concurrent x - newChan Prelude Control.Concurrent forkIO $ readChan x Prelude Control.Concurrent empty - isEmptyChan x *** Exception: thread blocked indefinitely Is that the intended behaviour? Is it possible to make a non-blocking version? This is a known limitation. Search the mailinglist-archives for a proposed fix. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME L-Attriwutgrammatik ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network, sClose
In local.glasgow-haskell-users, you wrote: Essentially, Network.recvFrom is only of use to simple, stupid programs; specifically, programs which only wish to accept a single connection. This has been noted (various?) times on the mailing-lists. You'd never want to use it in a real application. Since it's once again causing confusion, maybe it's about time to finally axe it? I don't know if you'd find letters large and friendly enough to use in the documentation to point out its deficiencies...They aren't documented at all atm, I'll see if I can whip up something. Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME L-Attriwutgrammatik ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can you block a thread in GHC by its threadID?
In local.glasgow-haskell-users, you wrote: On 22 June 2004 10:39, Bernard James POPE wrote: Supposing that such a thing is indeed possible is there any chance that it could be folded into GHC? (Then I wouldn't have to ship my own variant of the runtime with buddha.) Certainly, I don't see any reason why not. It looks like a bolt-on extension rather than a global change. A similar feature has been *removed* from Java recently for a good reason (rule of thumb: If you used it, you did something wrong). OTOH I see that it's handy for debuggers. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Neu! Ändern Sie den Anfangstag Ihrer Woche ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
In local.glasgow-haskell-users, you wrote: Christian Maeder wrote: What is ctype.h good for? A good question. Its only use seems to be in ghc/rts/RtsFlags.c where it is used for functions like isdigit and isspace for decoding the RTS flags. Maybe it should be retired altogether. I'm rather puzzled how this works if ctype.h isn't there at all, as it seems to. The functions are C89, so they should be present *somewhere* in libc anywhere. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Neu! Ändern Sie den Anfangstag Ihrer Woche ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: reaching Happy parser
In local.glasgow-haskell-users, you wrote: Please, who knows how to download and install in the easiest way the Happy parser Maybe, you now some mirrors ... http://www.mirror.ac.uk/sites/www.haskell.org/ -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Neu! Ändern Sie den Anfangstag Ihrer Woche ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [ ghc-Bugs-954378 ] getFileStatus does not include the file name in IO-Error
In local.glasgow-haskell-bugs, you wrote: Summary: getFileStatus does not include the file name in IO-Error Hm, it looks like none of the functions in there return a hint as to which argument caused the error. All of them should probably include filenames etc into exceptions. Volker -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.2/opengl
In local.glasgow-haskell-users, you wrote: we have compiled ghc-6.2 --enable-hopengl from source (with ghc-6.0) on SunOS userv2 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-60. Linking ... Undefined first referenced symbol in file glXGetProcAddressARB /usr/local/share/ghc/lib/ghc-6.2/libHSOpenGL_cbits.a(HsOpenGL.o) Can you check your header files? Here it's #ifdef'd inside of GLX_GLXEXT_LEGACY. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fail to compile ghc-6.2 on a Sun/Sparc
In local.glasgow-haskell-users, you wrote: Ok, that was definitely my fault. I´ve built the gnu-make and tried again. After an hour of compilation ghc ended with: ./../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I../../ghc/includes -I. GHC/Unicode.hsc Unicode.hsc: In function `main': Unicode.hsc:126: `wint_t' undeclared (first use in this function) Unicode.hsc:126: (Each undeclared identifier is reported only once Unicode.hsc:126: for each function it appears in.) Unicode.hsc:126: parse error before int make[2]: *** [GHC/Unicode.hs] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/mai99dnn/tmp/ghc-6.2/libraries' make: *** [build] Error 1 Just update if you use CVS are use the following patch (from O.Braun). Then, 'gmake clean' and restart the build (both just in 'libraries', the compiler built fine). --- libraries/base/GHC/Unicode.hsc.orig Mon Oct 20 12:12:20 2003 +++ libraries/base/GHC/Unicode.hsc Mon Jan 12 23:32:22 2004 @@ -112,7 +112,7 @@ -- - -- Win32 implementation -#if (defined(HAVE_WCTYPE_H) HAVE_ISWSPACE) || mingw32_TARGET_OS +#if (defined(HAVE_WCTYPE_H) HAVE_ISWSPACE defined(HTYPE_WINT_T)) || mingw32_TARGET_OS -- Use the wide-char classification functions if available. Glibc -- seems to implement these properly, even for chars 0x, as long -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Useful info from crash?
In local.glasgow-haskell-users, you wrote: I have a ghc program that appears to be causing a memory error (either segfaulting or tripping up X and killing my session). Are you sure it's segfaulting? You might simply run low on memory and your system starts killing processes to free up memory. Maybe you can find more details in the syslog. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: File permissions of /tmp files
In local.glasgow-haskell-users, you wrote: It might even be possible to create the file and then remove(3) it, right away. The file handle will continue to work, but there is never an entry in the file system. IIRC this is not possible because files are referenced in the different phases by name. If nothing goes wrong, temporary files should be deleted. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unknown symbol `__stginit_List_'
In local.glasgow-haskell-users, you wrote: (This is when invoking ghci -package yahu) Loading package base ... linking ... done. Loading package yahu ... linking ... /.../chalmers.se/fs/cab/cs/work/proj/multi/pub/lib/yahu/Yahu/YahuHaskell.o: unknown symbol `__stginit_List_' ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1): can't load package `yahu' You need to add -package haskell98. You can either do this on the commandline or, better, in package.conf. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci TclHaskell
ghci doesn't automatically pick up libtcl libtk, although they're in
package.conf. LD_PRELOADing them works fine [plain ghc works as well].
Is this a feature?
Tracing shows that libt{cl,k}83.so *are* opened. Changing the order in
extra_libraries or moving them to extra_ld_opts doesn't help, either.
ghci -package TclHaskell
...
Loading package TclHaskell ... linking ...
/usr/local/lib/ghc-6.0.1//HSTclHaskell_cbits.o: unknown symbol `Tcl_AppendResult'
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
can't load package `TclHaskell'
LD_PRELOAD=/usr/local/lib/libtcl83.so:/usr/local/lib/libtk83.so ghci -package
TclHaskell
...
Loading package TclHaskell ... linking ... done.
Prelude
[Not that that's any useful, but conclusion about the above might be relevant for
other packages.
Skipping Main ( philos.hs, ./philos.o )
Ok, modules loaded: Main, ConcurrentDebug, CHD_ConcurrentSampleVar, CHD_Label,
CHD_ConcurrentQSemN, CHD_ConcurrentQSem, CHD_ConcurrentCVar, CHD_ConcurrentMain,
CHD_ConcurrentChannel, CHD_ConcurrentMVar, CHD_DebugMsgChan, CHD_BaseTypes,
CHD_BaseFunctions, CHD_GuiConfigWindow, CHD_Enviroment, PriorDoubleChannel.
Prelude Main main
No compiled code for Tcl
]
Package.conf:
Package
{name = TclHaskell,
auto = False,
import_dirs = [/usr/local/lib/ghc-6.0.1/imports/tclhaskell/],
source_dirs = [],
library_dirs = [/usr/local/lib/ghc-6.0.1/],
hs_libraries = [HSTclHaskell],
extra_libraries = [tcl83, tk83, HSTclHaskell_cbits ],
include_dirs = [/usr/local/lib/ghc-6.0.1/include],
c_includes = [],
package_deps = [rts, lang, concurrent, data],
extra_ghc_opts = [-fglasgow-exts, -fvia-C],
extra_cc_opts = [],
extra_ld_opts = [-L/usr/local/lib, -lncurses],
framework_dirs = [],
extra_frameworks = []}]
--
Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getSignalMask ghc6.0.1
In local.glasgow-haskell-users, you wrote: I can't do much with the provided examples, because getSignalMask exits the program with: Fail: invalid argument Action: getSignalMask Reason: Invalid argument Looks like an actual bug in the library. Should be fixed in CVS now. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiler bug? sunos 5.8, ghci-6.0.1 -package unix
In local.glasgow-haskell-bugs, you wrote: and the some for the precompiled version, i getting the following error. Loading package unix ... linking ... /home/xxx/local/lib/HSunix.o: unknown symbol `sendfile' Hrmph. Sorry for the hassle. Please try adding sendfile to the list of extra_libraries in the file unix.conf in your installed ghc-tree. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Posix library ,Concurrent Haskell and Haskell IO sub-system
On Fri, Jul 11, 2003 at 08:39:54AM +0200, Rafael Martinez Torres wrote: (piper,pipew) - createPipe piperHandle - fdToHandle(piper) threadWaitRead ( fdToInt(handleToFd(piperHandle)) ) message - hGetLine piperHandle --or whatever. There's no need to call threadWaitRead, Haskell's RTS will take care of Non-Blocking IO for you. -- Gemischte Materialien // Früher: Restmüll Aufschrift auf einem Container, Informatik-Parkplatz http://lambda.foldr.org/~vs/ * PGP * S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: passing a Handle to a C function
In local.glasgow-haskell-users, you wrote: For Unix, use Posix.handleToFd to get a descriptor, then fdopen() (in C, or write a foreign import) to get a FILE*. Also, don't forget about synchronisation issues between the C and Haskell interfaces to the descriptor (e.g. buffering). After the 'handleToFd', there shouldn't be any issues of interference because the handle becomes unusable in Haskell-land. Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posix library ,Concurrent Haskell and Haskell IO sub-system
In local.glasgow-haskell-users, you wrote: I use the Posix library since I have to communicate via a pipe with another UNIX process. Therefore I have to use fdRead :: Fd - ByteCount - IO (String,ByteCount) Why do you have to use an Fd? A regular handle should be sufficient. Where do you get the Fd from? Did you consider lifting the Fd back to a Handle? If you really need to read exactly ByteCount bytes, you could go the hard way and set the handle to unbuffered IO and call hGetChar n times. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: isEmptyChan blocks?
Am 23. Jun 2003 um 12:05 CEST schrieb Simon Marlow: Could you explain how this works? writeChan doesn't update the count - it should, right? But if it does, won't there be race conditions when read write happen at the same time? I updated the file at http://www.foldr.org/~stolz/Chan2.hs with the promised documentation. Regarding 'correctness', I quote from the introduction: -- There's a small race when concurrently reading from a channel and obtaining -- the count: the item might be already read but the count hasn't been updated -- yet. But hey, this is Concurrent Haskell so the number of elements has rather -- informational value by the time you see it, anyway. There is no such race -- condition on writing: -- 1) write vs. getCount: The writer locks all count-MVars before writing and -- only releases them with the new value when the new item is in place -- == reported count will be correct w.r.t. the above readChan/count-race. -- 2) write vs. read: Because the writer holds the count-MVars until after the -- new item is in place, the reader has to wait for the updated count, -- although it immediately obtains the item from the stream. -- Overall conclusion: 'getCountChan' will report either the actual number of items -- in the channel or one additional item which is currently being consumed. [NB: I think that this could be fixed by introducing yet another lock. But it's probably not worth it because it will just mean that as soon 'getCountChan' turns its back on the channel, the item will still have disappeared.] [although I consider mapM_ (uncurry putMVar) (zip counts (map (+1) vs)) rather neat :)] Not as neat as zipWithM_ putMVar counts (map (+1) vs) Point taken. Volker -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sockets and handles in ghc
In local.glasgow-haskell-users, you wrote: I've been using sockets and handles with ghc-5.04.3. The strange thing is now that when I make a handle out of a socket and ask whether the handle is readable or writable, it returns True for the former and False for the latter, although sockets are bidirectional. And yes, Indeed a bug. Fixed in CVS, thanks! -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sockets and handles in ghc
[Moving to [EMAIL PROTECTED] In local.haskell, you wrote: I've been using sockets and handles with ghc-5.04.3. The strange thing is now that when I make a handle out of a socket and ask whether the handle is readable or writable, it returns True for the former and False for the latter, although sockets are bidirectional. And yes, Do you have a small sample program which shows this behaviour? Can you try ghc-6? There have been some updates, but I cannot tell if this was a particular bug that got fixed. Regards, Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GHC 6.0 Release: sparc-solaris2 binaries
In local.glasgow-haskell-users, you wrote: I am having trouble installing the package in a non-standard place. After downloading and unpacking I did: There have been some fixes to this particular package. Please check if there's a more recent package (t 1 day)! Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problem compiling OpenGL/.../Extensions.hs with GHC version 6.0
Could the parties involved with the quoting issue please test the
following patch? It doesn't use an additional shell for starting
sub-tasks and does no additional quoting so that quoting remains
unaffected, i.e. testing with OpenGL shows that the double quotes
are indeed passed through. Sven, do you have time to verify this?
*** C pre-processor
gcc -E -undef -traditional -v -I . -I include -I
/usr/tmp/fptools/libraries/base/include -I /usr/tmp/fptools/ghc/includes
-D__HASKELL1__=5 -D__GLASGOW_HASKELL__=601 -D__HASKELL98__ -D__CONCURRENT_HASKELL__
-DCALLCONV=ccall -DGET_PROC_ADDRESS=glXGetProcAddressARB
-DDONT_WANT_WIN32_DLL_SUPPORT -x c Graphics/Rendering/OpenGL/GL/BasicTypes.hs -o
/tmp/ghc70692.hscpp
It works successfully in all 3 stages and in the libraries, but I'm
not sure if I missed somebody sneaking in any
Option -foo -bar
along the more obscure paths!
Perhaps I should add a sanity check to 'showOpt' which will print
a warning if it encounters - anywhere in the string until 6.2?
'ghc -v' will show the arguments with interspersed spaces, so you
cannot really tell if there's a quote in the argument or not -- but
it means you can still cutpaste sub-tasks from -v. It might be
sensible to surround *only* the arguments in the debugging output
with single quotes, so that perpetrators can be spotted.
Mingw is unaffected, but it might be worth seeing if now both cases
boil down to one.
Volker
--
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
rage against the finite state machine
? autom4te.cache
? compiler/.depend-3
? compiler/stage3
? driver/stamp-pkg-conf-OpenGL
? driver/ghc/ghc-6.1
? driver/ghci/ghci-6.1
? rts/log
? rts/gmp/.deps
? rts/gmp/.libs
? rts/gmp/Makefile
? rts/gmp/config.cache
? rts/gmp/config.m4
? rts/gmp/config.status
? rts/gmp/gmp-mparam.h
? rts/gmp/libgmp.la
? rts/gmp/libtool
? rts/gmp/stamp-h
? rts/gmp/mpn/.libs
? rts/gmp/mpn/Makefile
? rts/gmp/mpn/add_n.asm
? rts/gmp/mpn/addmul_1.asm
? rts/gmp/mpn/bdivmod.c
? rts/gmp/mpn/bz_divrem_n.c
? rts/gmp/mpn/cmp.c
? rts/gmp/mpn/copyd.asm
? rts/gmp/mpn/copyi.asm
? rts/gmp/mpn/diveby3.asm
? rts/gmp/mpn/divrem.c
? rts/gmp/mpn/divrem_1.asm
? rts/gmp/mpn/divrem_2.c
? rts/gmp/mpn/dump.c
? rts/gmp/mpn/gcd.c
? rts/gmp/mpn/gcd_1.c
? rts/gmp/mpn/gcdext.c
? rts/gmp/mpn/get_str.c
? rts/gmp/mpn/hamdist.c
? rts/gmp/mpn/inlines.c
? rts/gmp/mpn/jacbase.c
? rts/gmp/mpn/libmpn.la
? rts/gmp/mpn/lshift.asm
? rts/gmp/mpn/mod_1.asm
? rts/gmp/mpn/mod_1_rs.c
? rts/gmp/mpn/mul.c
? rts/gmp/mpn/mul_1.asm
? rts/gmp/mpn/mul_basecase.asm
? rts/gmp/mpn/mul_fft.c
? rts/gmp/mpn/mul_n.c
? rts/gmp/mpn/perfsqr.c
? rts/gmp/mpn/popcount.c
? rts/gmp/mpn/pre_mod_1.c
? rts/gmp/mpn/random.c
? rts/gmp/mpn/random2.c
? rts/gmp/mpn/rshift.asm
? rts/gmp/mpn/sb_divrem_mn.c
? rts/gmp/mpn/scan0.c
? rts/gmp/mpn/scan1.c
? rts/gmp/mpn/set_str.c
? rts/gmp/mpn/sqr_basecase.c
? rts/gmp/mpn/sqrtrem.c
? rts/gmp/mpn/sub_n.asm
? rts/gmp/mpn/submul_1.asm
? rts/gmp/mpn/tdiv_qr.c
? rts/gmp/mpn/udiv.asm
? rts/gmp/mpn/umul.asm
? rts/gmp/mpz/.libs
? rts/gmp/mpz/Makefile
? rts/gmp/mpz/libmpz.la
? rts/gmp/mpz/mul_si.c
? rts/gmp/mpz/mul_ui.c
? utils/genapply/genapply
? utils/ghc-pkg/ghc-pkg-6.1
Index: compiler/main/SysTools.lhs
===
RCS file: /home/cvs/root/fptools/ghc/compiler/main/SysTools.lhs,v
retrieving revision 1.88
diff -u -r1.88 SysTools.lhs
--- compiler/main/SysTools.lhs 25 May 2003 20:54:18 - 1.88
+++ compiler/main/SysTools.lhs 3 Jun 2003 10:46:30 -
@@ -81,6 +81,7 @@
openFile, hPutChar, hPutStrLn, hPutStr, hClose, hFlush,
IOMode(..),
stderr )
import Directory ( doesFileExist, removeFile )
+import List ( intersperse )
#include ../includes/config.h
@@ -93,8 +94,12 @@
#ifndef mingw32_HOST_OS
#if __GLASGOW_HASKELL__ 504
import qualified System.Posix.Internals
+import System.Posix.Process ( executeFile, getProcessStatus, forkProcess,
ProcessStatus(..))
+import System.Posix.Signals ( installHandler, sigCHLD, Handler(..) )
#else
import qualified Posix
+import Posix ( executeFile, getProcessStatus, forkProcess, ProcessStatus(..),
installHandler,
+ sigCHLD, Handler(..) )
#endif
#else /* Must be Win32 */
import List( isPrefixOf )
@@ -190,7 +195,7 @@
\begin{code}
GLOBAL_VAR(v_Pgm_L,error pgm_L, String)-- unlit
-GLOBAL_VAR(v_Pgm_P,error pgm_P, String)-- cpp
+GLOBAL_VAR(v_Pgm_P,error pgm_P, (String,[Option])) -- cpp
GLOBAL_VAR(v_Pgm_F,error pgm_F, String)-- pp
GLOBAL_VAR(v_Pgm_c,error pgm_c, String)-- gcc
GLOBAL_VAR(v_Pgm_m,error pgm_m, String)-- asm code mangler
@@ -374,7 +379,9 @@
#endif
-- cpp is derived from gcc on all platforms
-; let cpp_path = gcc_path ++ -E ++ cRAWCPP_FLAGS
+-- HACK, see setPgmP below. We keep 'words' here to remember to fix
+-- Config.hs one day.
Re: lecture
In local.haskell, you wrote:
I am student of Computer Science and I have to write a lecture on ghc
network module. Where can I get some code samples of this module. I am
looking for short progrmas that show how to use network module.
There's nothing special about Haskell's/GHC's networking module. As a
rule of thumb you should be able to translate any regular C program
into Haskell. There isn't any sample code, but if you are familiar
with Haskell you could look at the low-level source-code of
- the Haskell Web Server (in the fptools repository)
- {Erlang-style, Port-based} Distributed Haskell
Occasionally, you might find useful snippets on the GHC mailing
lists, e.g.
http://www.haskell.org/pipermail/glasgow-haskell-users/2003-March/004915.html
You might want to comment on the use of non-blocking IO and using Concurrent
Haskell instead of calling the C function 'fork' to implement a single
server using lightweight threads to serve multiple clients. 'hGetContents'
can be used to read all current (and future!) data so you can completely
abstract from the underlying IO and instead focus on getting work done.
Volker
--
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
rage against the finite state machine
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Problems building ghc-current
In local.glasgow-haskell-users, you wrote: I'm trying to compile the latest version of GHC from CVS. I followed the instructions on GHC's web page and everything worked just fine. But when I updated the sources with cvs update -dP as instructed, CVS checked-out pretty much everything the CVS repository carries. (Is that supposed to happen? The CVS cheat sheet suggests that only ghc, libraries, and hslibs would be used/required.) Where did you find those instructions? The CVS Cheat Sheat is quite clear on the matter, in fact I couldn't find -dP in the entire page. -d (don't --want to ;)-- know what the P does) at least checks out any subdirectories, which, after getting fpconfig, is indeed the entire tree :) After getting fpconfig, 'cvs checkout ghc hslibs libraries' (if you have 'happy' installed, otherwise you need this as well, 'haddock' might be useful, too). [I guess we should really add those two to the list] So, when I tried to compile again -- now with _everything_ in the source tee --, the build fails here: You probably won't need greencard anyway, so maybe it's best to wipe it from the disk (and all the other unrelated stuff). Or simply enter the ghc-director 'make boot all', then go to fptools/libraries, 'make all', and do the same in fptools/hslibs. Regards, Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems building ghc-current
In local.glasgow-haskell-users, you wrote: | 2.4. Updating Your Source Tree | It can be tempting to cvs update just part of a source tree to bring in | some changes that someone else has made, or before committing your own | changes. This is NOT RECOMMENDED! [...] | | So, to avoid a lot of hassle, follow this recipe for updating your tree: | $ cd fptools | $ cvs update -Pd 21 | tee log The '-P' flag (prune) suppresses empty directories in the update. Hm, okay, probably -dP is the same as -Pd. You're right, this in fact pulls in all the stuff from the entire tree. There probably should be a warning attached to this line. You probably won't need greencard anyway, so maybe it's best to wipe it from the disk (and all the other unrelated stuff). I have no problem with that. I think this situation is unsatisfactory, though, I'll have to cvs-update my source repository in two, maybe three separate steps, to avoid checking everything out _again_. A safe bet is simply invoking 'cvs update' in fptools (w/o -d) and only checking for new directories if you need to. Reasoning: - If you just need one GHC from CVS, you've got a fresh checkout and only want to track minimal changes, e.g. to the STABLE branch where new directories probably won't be created (hmm, not quite true for the hierarcichal libraries now...) - You really track HEAD, in which case you know what you're doing anyway :) This is far from optimal, but hard to do any better. But as I said, that line in the building guide really ought to be fixed. Thanks for pointing this out! Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HEAD: the `impossible' happened, MacOS X
This is yesterdays HEAD:
../../ghc/compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches
-fwarn-unused-imports -L/sw/lib -fglasgow-exts -cpp -Iinclude -#include HsBase.h
-funbox-strict-fields -package-name base -dcore-lint -W -fno-warn-unused-matches
-fwarn-unused-imports -keep-hc-files -c System/Random.hs -o System/Random.o -ohi
System/Random.hi
System/Random.hs:15:
Warning: Module `GHC.IOBase' is imported, but nothing from it is used
(except perhaps instances visible in `GHC.IOBase')
ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
ASSERT failed! file stgSyn/CoreToStg.lhs line 188
randomIvalDouble1 {- v s2Im -}
--
Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: HEAD: the `impossible' happened, MacOS X
On Thu, Mar 20, 2003 at 12:08:22PM +, Simon Marlow wrote:
System/Random.hs:15:
Warning: Module `GHC.IOBase' is imported, but nothing
from it is used
(except perhaps instances visible in `GHC.IOBase')
ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
ASSERT failed! file stgSyn/CoreToStg.lhs line 188
randomIvalDouble1 {- v s2Im -}
Compiling the libraries without -O is not usually a good idea, but
nevertheless the compiler shouldn't crash. I'll take a look.
That's from the 'devl' template in build.mk. You're right, the problem
goes away when using -O!
--
Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: fun with sockets (ghc-5.04.1)
In local.glasgow-haskell-users, you wrote: After processing a random number of connections, the server dies with Fail: invalid argument Action: accept Reason: Invalid argument [...] I don't know what's wrong, I'm afraid. Any chance you could supply us with a working example that demonstrates the bug? I was on this for some time and even received an strace from Peter -- which DIDN'T show EINVAL at all on any accept! He keeps seeing 'Evacuated object entered' messages on other runs, so he might be experiencing a more severe problem. Reproducing this with a recent ghc would be better, I guess... BTW: There's a tracing primer at http://www-i2.informatik.rwth-aachen.de/~stolz/Haskell/networking.txt which explains some of the things you might find strange in traces (ioctl TCGETS anyone?). Not quite finished and open for suggestions... Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More problems compiling GHC on Mac OS X
Am 17. Mar 2003 um 02:04 CET schrieb Kirsten Chevalier: On Sun, Mar 16, 2003 at 04:09:31PM +0100, Volker Stolz wrote: In local.glasgow-haskell-users, you wrote: Sendfile.hsc:94: Couldn't match `IO ()' against `Fd - Fd - Int - Int - IO ()' Should be fixed in CVS now, thanks! *sigh*. I used fptools/mk/config.h for trying to test compilation of the fallback case. Unfortunately, there's anoher config.h around, so in fact the test run wasn't compiled with the correct #ifdefs. Apologies, Volker -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More problems compiling GHC on Mac OS X
In local.glasgow-haskell-users, you wrote: Sendfile.hsc:94: Couldn't match `IO ()' against `Fd - Fd - Int - Int - IO ()' Should be fixed in CVS now, thanks! -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sockets (ghc-5.04.1)
Am 06. Feb 2003 um 21:53 CET schrieb Peter Thiemann: and then duplicated part of my code. One thing that I found annoying was that the Protocol argument of Network.Socket.socket is not well specified. The type Protocol is abstract, but is a member of class Read. However, the Read syntax is nowhere specified. So I tried do sock - socket AF_UNIX Stream (read 0) which works, but I'm sure that more informative strings work, too. Hm, ghc-5.04.2 compiles sock - socket AF_UNIX Stream 0 just fine. Are you maybe looking for Network.BSD.getProtocolBy*? [ProtocolNumber is just a typdef for CInt] -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.' ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sockets (ghc-5.04.1)
In local.glasgow-haskell-users, you wrote: I have a program that uses INET sockets and I wanted to change it to use Unix domain sockets. Here is the relevant code: sock - listenOn portID (h, hostname, portnumber) - accept sock I get an error message when running it with portID = UnixSocket /home/thiemann/.socket Somebody decided that Unix sockets are Datagrams in Network.hs, which is wrong (thanks for finding this bug), they're Stream sockets. You might want to avoid Network for the time being and use Network.Sockets, because fixing this will trigger another bug: Network.accept is currently only designed for Inet-sockets, its type makes that clear without even resorting to The Source: you cannot get a host port from a Unix socket, so while Socket.accept will work, Network.accept won't and fail on getHostBy*. The getHostBy* would have to be moved away from accept into listenOn first (Thanks, #2). I'd vote for removing Unix sockets from Network.hs to avoid this. (Sockets are already quite well abstracted on Un*x, so that's what you get for trying to put another layer on top of it #) Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [ ghc-Bugs-643878 ] sortBy not stable
In local.glasgow-haskell-bugs, you wrote:
The library report requires that sortBy be stable. In
5.04.1 it isn't:
[Simon, I must have missed that ghc-bugs is subscribers-only]
There's an #ifdef'ed version in there which is stable, but the
newer mergesort is not:
#ifdef USE_REPORT_PRELUDE
sort = sortBy compare
sortBy cmp = foldr (insertBy cmp) []
#else
sortBy cmp l = mergesort cmp l
sort l = mergesort compare l
{-
Quicksort replaced by mergesort, 14/5/2002.
nhc98 has a stable mergesort, I'm told. Maybe we should ask Malcolm
nicely...
--
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [ ghc-Bugs-643878 ] sortBy not stable
In local.glasgow-haskell-bugs, you wrote: The library report requires that sortBy be stable. In 5.04.1 it isn't: It looks like the change to mergesort broke this property: #ifdef USE_REPORT_PRELUDE sort = sortBy compare sortBy cmp = foldr (insertBy cmp) [] #else sortBy cmp l = mergesort cmp l sort l = mergesort compare l The #ifdef'ed definition is stable. nhc98 has a stable mergesort, I'm told, so maybe we should ask Malcolm nicely... -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in unix/System/Posix/Files.hsc
In local.glasgow-haskell-users, you wrote: readSymbolicLink is broken, it assumes that readlink(2) null terminates its result when it doesn't. this causes all sorts of badness. This should fix it, although all my CVS trees are hosed right now (now how did I manage to break something in the backup tree?) and I can't actually test it: Index: Files.hsc === RCS file: /home/cvs/root/fptools/libraries/unix/System/Posix/Files.hsc,v retrieving revision 1.3 diff -u -r1.3 Files.hsc --- Files.hsc 2002/10/08 08:03:02 1.3 +++ Files.hsc 2002/11/15 09:02:03 @@ -352,10 +352,10 @@ readSymbolicLink :: FilePath - IO FilePath readSymbolicLink file = allocaArray0 (#const PATH_MAX) $ \buf - do -withCString file $ \s - - throwErrnoIfMinus1_ readSymbolicLink $ +withCString file $ \s - do + len - throwErrnoIfMinus1 readSymbolicLink $ c_readlink s buf (#const PATH_MAX) -peekCString buf + peekCStringLen (buf,fromIntegral len) foreign import ccall unsafe readlink c_readlink :: CString - CString - CInt - IO CInt -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: docs bug
In local.glasgow-haskell-bugs, you wrote: http://www.mirror.ac.uk/sites/www.haskell.org/ghc/docs/latest/html/base/Data.Bits.html The description of each method of the Bits class seems to be attached to the signature of a different method. The documentation generated by haddock 0.4 looks fine (the web pages were generated by 0.3). Could somebody please put up a fixed version of the file from their cvs? -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: select() failure
In local.glasgow-haskell-bugs, you wrote: It sure would simplify my program if I could fork a process and not have auxiliary threads persist in the child. Could this option be provided by GHC RTS in a semantically sound way? On a recent GHC you can try 'forkProcess[Prim]': http://www.haskell.org/ghc/docs/latest/html/base/GHC.Conc.html#forkProcessPrim -- plonk :: m a - m () http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: how to catch GHC no threads to run exception?
In local.haskell, you wrote: Since I have 3 threads waiting on takeMVar, do I have to wrap all of them with Exception.catch? Yes. Especially since ghc-5.04, you cannot be sure which of the blocked threads will get killed first: http://haskell.org/pipermail/glasgow-haskell-users/2002-July/003779.html -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME http://news.bbc.co.uk: The Israeli army destroyed the bomber's family's house afterwards, a military statement said. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: how to catch GHC no threads to run exception?
In local.haskell, you wrote: test: no threads to run: infinite loop or deadlock? My problem is that this behavior is actually desired, but how do I catch this exception and do some bookkeeping (closing external IO, etc.) and then a proper exit? You can wrap the `takeMVar' with Exception.catch. Note that Prelude.catch won't suffice. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME http://news.bbc.co.uk: The Israeli army destroyed the bomber's family's house afterwards, a military statement said. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Deadlock detection different in ghc-5.04?
Hi, for some concurrency abstractions I decided to use deadlock
detection by means of exceptions which didn't work out as expected.
Below is some simplifed source code showing the problem: My assumption
was since GHC should be able to detect that the child still has a
reference to mv_should_work -- although in an exception handler -- the
RTS would never decide to kill the other thread.
Unluckily, this assumption turned out to be false. Did I overestimate
GHC's capabilities or is this a bug? Especially as ghc-5.02.2 shows the
desired behaviour (you just need to drop the Control.)...
Instead of exiting silently, the program terminates in the exception handler
in the main thread with ghc-5.04.
\begin{code}
module Main where
import Concurrent
import qualified Control.Exception
main = do
mv_should_work - newEmptyMVar
mv_deadlock - newEmptyMVar
forkIO $ do
Control.Exception.catch (takeMVar mv_deadlock) -- deadlock
(\ e - putMVar mv_should_work ())
yield yield yield
Control.Exception.catch (takeMVar mv_should_work)
(\ e - putStrLn $ main caught: ++ (show e))
\end{code}
--
Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME
http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that
confine more than 700,000 people to their homes.'
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: System.system broken?
In local.glasgow-haskell-users, you wrote: is System.system broken in 5.04? i am using the rpm provided on the web site and this call appears to be broken. in particular, using strace i find that it is attempting the following call [pid 16975] execve(n/sh, [/bin/sh, -c, echo foo], [/* 67 vars */]) = -1 ENOENT (No such file or directory) note that it appears the first three characters are being droped from the first argument to execve. I don't know about that particular binary package, but my CVS copy works fine: execve(/bin/sh, [sh, -c, echo foo], [/* 79 vars */]) = 0 -- http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.' ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Document -optl-static
I think it would be a good idea to add -optl-static to the flags described in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#OPTIONS-LINKER perhaps in the vincinity of -static -dynamic. Although this could be considered redundant, it might save some time trying out how to build entirely static binaries. Opinions? -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.' ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Document -optl-static
In local.glasgow-haskell-users, you wrote: I think it would be a good idea to add -optl-static to the flags described in http://www.haskell.org/ghc/docs/latest/html/users_guide/option s-phases.html#OPTIONS-LINKER perhaps in the vincinity of -static -dynamic. Although this could be considered redundant, it might save some time trying out how to build entirely static binaries. Opinions? I think the -static flag probably ought to be passed to the linker, so you wouldn't need -optl-static. Is there any reason you might need -static but not -optl-static? My prefered solution would be to rename the current -static to e.g. -hsstatic and let the actual -static be equivalent to -hsstatic -optl-static. That way, you don't loose the current possibility, although I cannot thing of any useful application, either. -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.' ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sigCHLD signal handling (Was: Re: pipes? threadWaitRead?)
In local.glasgow-haskell-bugs, you wrote: Am 10. Jul 2002 um 22:21 CEST schrieb Dean Herington: The first issue I confronted is that the get*ProcessStatus routines return an error rather than nothing if there is no candidate child process. Yes, `waitpid' might return with EINTR which will cause an exception (I just checked, it did). I'll try to devise a fix for PosixProcPrim. That's ECHILD, not EINTR. The only nice way to figure this out might be keeping a global counter (in an MVar), increasing it on forkProcess() and counting it down for each awaited child. That way, you could safely loop on `waitpid' if you know there should still be a child around (and you'll get `Nothing' if it's not done yet). Volker -- http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.' ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: panic in ghc5.02.3
In local.glasgow-haskell-bugs, you wrote: (This is on sparc-solaris) # /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc --make resources/GUIValue.hs resources/Colour.hs -fglasgow-exts ghc-5.02.3: chasing modules from: resources/GUIValue.hs,resources/Colour.hs Compiling GUIValue ( resources/GUIValue.hs, resources/GUIValue.o ) Compiling Colour ( resources/Colour.hs, resources/Colour.o ) ghc-5.02.3: panic! (the `impossible' happened, GHC version 5.02.3): Maybe.fromJust: Nothing Is there a workaround, or am I going to have to go back to ghc5.02.2? [Everything on Linux-x86] Maybe you're heading in the wrong direction: stolz@kastor:~/test/resources $HC5 --make -fglasgow-exts *.hs ghc-5.03: chasing modules from: Colour.hs,GUIValue.hs Compiling GUIValue ( GUIValue.hs, ./GUIValue.o ) Compiling Colour ( Colour.hs, ./Colour.o ) Let's see: stolz@kastor:~/test/resources $HC --make -fglasgow-exts *.hs ghc-5.02.2: chasing modules from: Colour.hs,GUIValue.hs lexer: misplaced NUL? Compiling GUIValue ( GUIValue.hs, ./GUIValue.o ) lexer: misplaced NUL? Compiling Colour ( Colour.hs, ./Colour.o ) Huh? NUL? stolz@kastor:~/test/resources hexdump GUIValue.hs | tail 0002290 3a27 7473 2972 2020 203d 3b27 2027 203a 00022a0 7266 6d6f 6b54 7453 6972 676e 7320 7274 00022b0 660a 6f72 546d 536b 7274 6e69 2067 2728 00022c0 5c5c 3a27 5c27 2722 733a 7274 2029 203d 00022d0 5c27 2722 3a20 6620 6f72 546d 536b 7274 00022e0 6e69 2067 7473 0a72 7266 6d6f 6b54 7453 00022f0 6972 676e 2820 3a78 7473 2972 2020 2020 0002300 2020 2020 3d20 7820 3a20 6620 6f72 546d 0002310 536b 7274 6e69 2067 7473 0a72 000a 000231d Can you try stripping the offending bytes, e.g. just remove the last blank line in 'vi'. I won't judge if ghc-5.02.3 is wrong here, though. -- Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18 Volker Stolz * [EMAIL PROTECTED] Please use PGP or S/MIME for correspondence! ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Cannot build 5.02.2 on Solaris 2.7
In local.glasgow-haskell-bugs, you wrote: Well, the -x options are still there and now I dump core while compiling with the new ghc-inplace opbject. Below is the trace ... I remember throwing out -x from fptools/mk/*.mk by hand in a distant past. Maybe this helps. -- Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18 Volker Stolz * [EMAIL PROTECTED] Please use PGP or S/MIME for correspondence! ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in IO libraries when sending data through a pipe?
Am 18. Mar 2002 um 13:51 MET schrieb Simon Marlow: unevaluated until the child process needs to construct its argument list to pass to executeFile. Hence the child process pokes on the lazy stream, and when the parent process subsequently demands data from the lazy stream, there is a buffer's worth missing. Moral of this story: don't use lazy I/O. There's a warning in the documentation of executeFile to exactly the same end after all... -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in IO libraries when sending data through a pipe?
In local.glasgow-haskell-bugs, you wrote: I've stripped down my program to produce an example. In the process, the problem disappeard a few times. I hope it shows up on your machine. The attached files reproduce it on my machine, but the exact results vary from run to run. There's no bug in the libraries: The data is read lazily by 'getContents', then you invoke 'forkProcess'. From this moment on, you should have two (heavy-weight) processes competing for input from the same source (stdin). Further proof might be that in making 'getContents' strict by inserting a 'print' statement to force evaluation now returns correct results: .. qinh - getContents let pfade = zeilen qinh print pfade -- FORCE EVALUATION mapM_ (\pfad - run /bin/echo [pfad]) pfade .. Notice that a 'hSetBuffering stdin NoBuffering' before 'getContents' doesn't seem to be sufficient, either. Regards, Volker -- Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18 Volker Stolz * [EMAIL PROTECTED] Please use PGP or S/MIME for correspondence! ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in IO libraries when sending data through a pipe?
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk: - If instead the child's child (echo.c) closes stdin immediately after being executed, some data is lost. Where's the use in closing stdin when you're passing arguments as parameters? This is effectively a NOP and shouldn't influence the result, so I'd expect the same missing data as in your original case. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: socket question
In local.glasgow-haskell-users, you wrote: suppose i want to write a stupid ftp client, i want to connect to the ftp server, wait for it to give it's intro stuff (welcome to blah, username: ) and then it wants input. how do i do something like this? connect cfg = withSocketsDo $ do h - connectTo (remoteAddr cfg) (Service (remoteType cfg)) hWaitForInput h 1000 s - readWhileAvailable h return s Why don't you use hGetLine? FTP is line based, so you just have to loop until there's no dash in the response. -- Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18 Volker Stolz * [EMAIL PROTECTED] Please use PGP or S/MIME for correspondence! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hsc: Passing -1 as CString/Ptr a?
Hi, I want to invoke the C-function 'dlsym', which has three possible options for a parameter of type (void*): - NULL - void* to a string, i.e. CString in Haskell - RTLD_NEXT = (void *)(-1) The first two ones are no problem, I can use a CString and 'nullPtr'. For the last one, I have the problem that in the Next-case I cannot write pack :: Flag - CString pack Null = nullPtr pack Name str = str pack Next = #const RTLD_NEXT because there's no way to cast Int to a Ptr -- at least I didn't find any. Unluckily, the C-codes (void *)(-1) even gets expanded by hsc to the literal 4294967295 which can't be right either. So currently I'm facing two possible solutions: pack Next = nullPtr `plusPtr` 4294967295 (expanded from ... #const RTLD_NEXT) or pack Next = nullPtr `plusPtr` (-1) (which is not a good idea since it doesn't use the C-constant) Ptr is abstract so I cannot create this Ptr myself. Maybe the Ptr-module just lacks a 'minusOnePtr' similar to 'nullPtr'? -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Socket library ghc 5.02.1
In local.glasgow-haskell-users, you wrote: main = do d - connectTo localhost (PortNumber 80) hPutStr d GET / HTTP/1.0\n\n hFlush d c - hGetContents d putStr c whereas on Linux I get the following error: *** Exception: failed Action: connect Reason: Unknown error 142731264 Please run the program with 'strace', e.g. strace -o log ./a.out and post the log when it fails. Be aware that 'hGetContents' is broken on 5.02.1 if you use it extensively (the GC will close already-reused fds and cause your program to crash!), the patch was recently postet to -bugs by Simon Marlow and works. OTOH, this is not the bug you're seeing. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Socket library ghc 5.02.1
In local.glasgow-haskell-users, you wrote:
It seems that the Socket library does still not work
with ghc 5.02.1.
[ghci clarification]
There, it crashes for me even on the 2nd invocation:
connect(13, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(137.226.194.33)}}, 16) = -1 EINPROGRESS (Operation now in
progress)
gettimeofday({1006436761, 219035}, NULL) = 0
select(14, [], [13], NULL, {134, 217727}) = 1 (out [13], left {134, 22})
getsockopt(13, SOL_SOCKET, SO_ERROR, [1835091456], [1]) = 0
write(1, *, 1)= 1
whereas on the first, succeeding call to 'connect' it says;
select(14, [], [13], NULL, {134, 217727}) = 1 (out [13], left {134, 21})
getsockopt(13, SOL_SOCKET, SO_ERROR, [0], [1]) = 0
This looks like some on-the-fly bitrotting in ghci :-/
--
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
AbsCStixGen.gencode panic
Beware, to reproduce you need c2hs gtk+hs!
Luckily, I can use the -O switch (does that option mean turn errors OFF?)
to get a perfectly working binary!
ghc -c Get.lhs -o Get.o `c2hs-config --cflags` -fglasgow-exts -package lang
ghc-5.02.1: panic! (the `impossible' happened, GHC version 5.02.1):
AbsCStixGen.gencode
typedef void ( *_ccall_fun_tys1Cc) (StgAddr, I_);
\begin{code}
module Main where
import IO
import Maybe
import Monad
import Foreign
import CString
import GModule
type Fun = CString - Int - IO ()
foreign import dynamic unsafe iterator__ :: FunPtr Fun - Fun
main :: IO ()
main = do
withModule (Just .) simple ModuleBindOnLoad $ \ mod - do
funptr - moduleSymbol mod simple
when (isNothing funptr) $ error fo!
let res = iterator__ (castPtrToFunPtr (fromJust funptr))
withCString hello $ \ str - res str 1
return ()
\end{code}
--
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[5.02/5.02.1] hGetContents problem
A small program (which I haven't been able to strip down to a
minimal *failing* version ;) repeatedly opens sockets and does the
following (I tested with all permutations of hSetBuffering):
Socket.connectTo ...
hPutStrLn h Data
hPutStr h d
debug Io Reading..:
c - hGetContents h
debug Io .
print c
debug Io *
After several loops, the program fails with:
Io: Reading..:
Io: .
Fail: failed
Action: lazyRead
Handle: {loc=socket: 0,type=semi-closed,binary=True,buffering=none}
Reason: Bad file descriptor
File: socket: 0
Which isn't surprising if you take a look at the attached strace. If you
read the trace bottom up, you'll find that someone's calling 'close' on
fd 4 (and it's not me!) which has already been closed some time ago.
Maybe somehow the finalizer for an old handle gets run and the
safety precautions in PrelHandle/PrelIO fail for some reason.
write(1, Io: \*\\n, 8) = 8
open(/etc/protocols, O_RDONLY)= 0
fcntl(0, F_GETFD) = 0
fcntl(0, F_SETFD, FD_CLOEXEC) = 0
fstat(0, {st_mode=S_IFREG|0644, st_size=1339, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40014000
read(0, #\n# protocols\tThis file describe..., 4096) = 1339
close(0)= 0
munmap(0x40014000, 4096)= 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 0
fcntl(0, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(0, F_SETFL, O_RDWR|O_NONBLOCK)= 0
socket(PF_UNIX, SOCK_STREAM, 0) = 4
connect(4, {sin_family=AF_UNIX, path=
/var/run/.nscd_socket}, 110) = -1 ECONNREFUSED
(Connection refused)
close(4)= 0
open(/etc/hosts, O_RDONLY)= 4
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=699, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40014000
read(4, #\n# hosts This file desc..., 4096) = 699
close(4)= 0
munmap(0x40014000, 4096)= 0
***
close(4)= -1 EBADF (Bad file descriptor)
close(0)= 0
close(0)= -1 EBADF (Bad file descriptor)
***
connect(0, {sin_family=AF_INET, sin_port=htons(8481),
sin_addr=inet_addr(127.0.0.1)}}, 16) = -1 EBADF (Bad file descriptor)
fcntl(2, F_GETFL) = 0x2 (flags O_RDWR)
write(2, \nFail: , 7) = 7
write(2, failed\nAction: connect\nReason: B..., 51) = 51
write(2, \n, 1) = 1
_exit(1)= ?
--
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Changed behaviour when reading from FIFOs!
On Mon, Oct 29, 2001 at 02:52:25PM -, Simon Marlow wrote: The blocking is essential since I need to be able to use MVars between the threadWaitRead the hGetLine (remember the note I sent about fork()ing). Sorry, I can't remember that - could you remind me? The hGetLine already blocks if there's no data in the FIFO, the extra threadWaitRead will only work if the Handle is in NoBuffering mode, because otherwise there might be data in the handle buffer waiting to be read which threadWaitRead would be unable to detect. I'm using 'fork' (the real thing, not forkIO), in a Concurrent Haskell programm and I need a way to lock out multiple readers from the same file handle because of the sharing when forking. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Changed behaviour when reading from FIFOs!
Something broke when reading from FIFOs in the transition from
5.00 to 5.02. The following program behaves as it should in
5.00, but with 5.02 it fails after printing the last line
(strangely for varying numbers of last!) with
Fail: end of file
Action: hGetChar
Handle: {loc=foo,type=readable,binary=False,buffering=none}
File: foo
Another issue is that it won't work at all with LineBuffering:
It will just print one line and then sit around doing nothing.
The program will create a FIFO named foo and simply echo
everything back to you, so you'd probably want to try
./t
ls -1 foo
Sometimes, if you just pipe the 'head' of something, it will
work without terminating, so you can try repeated invocations
of 'ls'. Looks like somethings wrong in the IO/buffering code.
ghc -package posix -package concurrent -o t t.lhs
\begin{code}
module Main where
import IO
import Posix
import Monad
import Maybe
import Concurrent
import System
main :: IO ()
main = do
let fifoname = foo
h - openFIFO fifoname
hSetBuffering h NoBuffering
dummy - openFile fifoname WriteMode
fifoReadLoop h
where
fifoReadLoop h = do
fd - handleToFd h
threadWaitRead (fdToInt fd)
msg - hGetLine h
print msg
fifoReadLoop h
openFIFO :: String - IO Handle
openFIFO fifoname = do
catch (openFile fifoname ReadMode)
(\e - if (isDoesNotExistError e)
then do
putStrLn $ Creating FIFO ++ fifoname
system $ /usr/bin/mkfifo ++ fifoname
openFile fifoname ReadMode
else error $ Can´t create FIFO ++ fifoname
)
\end{code}
--
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Changed behaviour when reading from FIFOs!
On Mon, Oct 29, 2001 at 02:08:23PM -, Simon Marlow wrote: This appears to be because the dummy Handle opened in WriteMode is being garbage collected and closed, which leaves the FIFO with no writers so you get EOF. 5.02 is behaving correctly here. You can add an extra 'hClose dummy' at the end of 'main' to prevent the EOF exception. Argh, that was exactly what I feared when I read the file-handles discussion on the list. Only I didn't realize that the feature got indeed introduced into ghc-5.02. You have some extra blocking in there: just comment out the first two lines of fifoReadLoop, and everything should be fine. This also fixes the other problem you mentioned above (varying numbers of last). The blocking is essential since I need to be able to use MVars between the threadWaitRead the hGetLine (remember the note I sent about fork()ing). -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC modules and packages
In local.haskell, you wrote:
is there some documentation about which modules reside in which packages in
GHC?
You can take a look at http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html.
The top-level chapters ('category') are the packages.
--
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Socket library
In local.glasgow-haskell-users, you wrote: Unfortunately, I am currently working on WinNT and would not like to go back and install ghc4.08. Is there an easy way to patch this problem in my 5.02 installation. Maybe you're just lacking the Wintendo equivalent of /etc/protocols, but I don't know how Windows/cygwin handle these things. You could modify SocketPrim to use the number 6 instead of trying to do the getprotobyname lookup, but that's not a real remedy. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Blocking IO in module Socket
Am 22. Oct 2001 um 12:56 MET DST schrieb Simon Marlow: The call doesn't block, because the socket is set to non-blocking mode. Or have you perhaps observed different behaviour? It works here. Okay, I'm stupid. I can clearly see the 'threadWaitRead' statement now. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[5.02] Bug with existentially-quantified constructors
The following program can be compiled using
ghc-5.02 --make test.lhs -fglasgow-exts
but segfaults.
./a.out
foo
Segmentation fault
\begin{code}
module Main where
import IO
data DS = forall a. C (a - IO ())
main = do
let (li:st:[]) = [C (print :: String - IO ()), C (print :: Int - IO ())]
call li foo
call st 3
call (C f) arg = do
f arg
\end{code}
--
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Posix.runProcess
In local.glasgow-haskell-users, you wrote: I think Posix.runProcess should give access to the eventual exit state of the process, if any. Two possible ways: (1) Change its result to IO (IO ExitCode), the inner action being something that waits for the process to complete (without blocking all other threads!) and returns the ExitCode. (Even better would be to make the result just IO ExitCode but this might be too incompatible for people who rely on runProcess returning at once.) It seems kind of hard to get the exitcode without calling wait() and thus blocking all threads. A solution I'm currently using is to install a SIGCHLD handler which grabs the exit-code of the/a forked process with Posix.getAnyProcessStatus. You could store these results in a mutable global object (MVar, or MVar (FiniteMap ..)) and then retrieve the result. It would be possible to have runProcess to return (MVar ExitCode) *immediately* (so it doesn't break things), and only when you read the MVar you get (lightweight) suspended until the process exits. Of course another solution would be to implement all this inside of runProcess, so you *would* block until runProcess returns, unless you use forkIO. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug with readFile and named pipes
In local.glasgow-haskell-bugs, you wrote: Programs that read from a named pipe usually block until a writer opens the pipe and writes something to it. The following program, main = putStr = readFile /tmp/p (where /tmp/p refers to a named pipe) exhibits this behavour when compiled with HBC or when run with runhugs, but *not* when compiled with GHC. Instead the program immediately exists, returning the empty string. I don't know if we`re talking about different things, but when I played around with fifos (e.g. For TCP/Hugs :-), I noticed that it is recommended to open the FIFO for *writing* *before* *opening* it for *reading*, even if you`re not going to write to it yourself. I wouldn`t want readFile opening my file for writing under normal cases, so I'd recommend you use a hack which opens the file for writing first. One could imagine that readFile tests the filetype and does The Right Thing(TM), but I`m not sure I want that, either. -- Neues aus Genua? http://germany.indymedia.org/ Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: POLL: GC options
In local.glasgow-haskell-users, you wrote: Issue 1: should the maximum heap size be unbounded by default? Currently the maximum heap size is bounded at 64M. Arguments for: this stops programs with a space leak eating all your swap space. Arguments against: it's annoying to have to raise the limit when you legitimately need more space. I'm for boundless wasting of memory. If I'd cared, I'd set the ulimits correspondingly. You really don't want to get to work on Monday morning finding that your favourite prime-finder stopped Friday five minutes after you left :-) -- Neues aus Genua? http://germany.indymedia.org/2001/07/4866.html Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 2 questions regarding ghci and --make
In local.glasgow-haskell-users, you wrote: 1.- What is the option that I have to change to build the system for interactive use? At this moment, when I run ghci, I obtain You have to rebuild ghc-5 with the compiler you just built. Then you will get a running ghci. 2.- If I want to have modules in separate directories. How can I tell --make to look for them? Use the same options as you´d use for plain ghc: -i Saludos, Volker -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fixed^2 (Re: Fixed! (Re: [5.01] Runtime error in SocketPrim?!))
In local.glasgow-haskell-bugs, I wrote: Unluckily, this seems to create a new problem: After binding to a specific address, socketPort always returns 0. net@atlas [16:47:28] diff -u SocketPrim.old SocketPrim.hsc --- SocketPrim.old Thu Jun 7 16:29:47 2001 +++ SocketPrim.hsc Wed Jun 13 16:46:32 2001 @@ -233,7 +233,7 @@ #endif (#const AF_INET) - do addr - (#peek struct sockaddr_in, sin_addr) p - port - (#peek struct sockaddr_in, sin_addr) p + port - (#peek struct sockaddr_in, sin_port) p return (SockAddrInet (PortNum port) addr) -- size of struct sockaddr by family #if !defined(cygwin32_TARGET_OS) !defined(mingw32_TARGET_OS) -- Abstrakte Syntaxträume. Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[5.01] Runtime error in SocketPrim?!
Suddenly my program which would work fine in 4.08.2 5.00 throws a pattern-match failure in SocketPrim/228 when compiled using 5.01. There is the test for AF_INET/AF_UNIX. When catching this in an otherwise-rule and printing the passed value, it is 7368, just for the record. Is someone feeling guilty of perhaps having broken things? Below the probably offending code I use. The reason for reimplementing listen is that I can specify the interface to bind to. listenOn :: Maybe String -- Interface (x.x.x.x) - PortID -- Port Identifier - IO Socket.Socket -- Connected Socket listenOn iface (PortNumber port) = do proto - BSD.getProtocolNumber tcp sock - SocketPrim.socket SocketPrim.AF_INET SocketPrim.Stream proto SocketPrim.setSocketOption sock SocketPrim.ReuseAddr 1 i - case iface of Nothing - return SocketPrim.iNADDR_ANY Just s - do SocketPrim.inet_addr s SocketPrim.bindSocket sock (SocketPrim.SockAddrInet port i) SocketPrim.listen sock SocketPrim.maxListenQueue return sock -- Abstrakte Syntaxträume. Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [5.01] Runtime error in SocketPrim?!
In local.glasgow-haskell-bugs, you wrote:
Suddenly my program which would work fine in 4.08.2 5.00 throws
a pattern-match failure in SocketPrim/228 when compiled using 5.01.
There is the test for AF_INET/AF_UNIX. When catching this in an
otherwise-rule and printing the passed value, it is 7368, just for
the record. Is someone feeling guilty of perhaps having broken things?
Perhaps, but I can't repeat the bug. Your code fragment appears to work
fine here. Which arch/OS, BTW?
You're right, my assumption of the location is wrong. I tracked it down
to socketPort, please apologize my laziness (which as we all now is
mostly an appreciated feature around here ;)
listen _ iface port = do
-- sockInit
socket - listenOn iface (PortNumber (case port of
Nothing - SocketPrim.aNY_PORT
Just p - mkPortNumber p))
print reached
(PortNumber myPort) - socketPort socket
print NOT REACHED
let record = SocketR {
socketR = socket,
portR = (read (show myPort)) :: Port -- sigh
}
return record
I'm still on it.
--
Abstrakte Syntaxträume.
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC5] Creating Socket.PortNumber from Int?
Until 5.00 I could use mkPortNumber to get what I want, i.e. PortNumber (mkPortNumber port) Now in 5.01, this function now longer exists. (PortNumber 5) works, but (PortNumber (5::Int)) does not, so I have to use fromIntegral to get it to work again: PortNumber (fromIntegral (5::Int)) I suppose I'm missing something essential here, as there must be a better way of doing it when passing a variable of type Int. -- 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
ghc5 --make question
Hi, I'm trying to generate automatic makefiles for my project using --make. Unluckily it seems ghc prefers .hs over .hi. The programs require a fair amount of separate libraries (Tcl/Tk, a Concurrent Haskell Debugger, a network wrapper,...) which I currently don't have to care much about: I just have to provide the corresponding top-level .hi and some .a-files to the ghc command line for compiling. Is there any way to use ghc --make without having to provide access to all of the *source* files and make it use the pre-compiled stuff? -- 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: [GHC5] Creating Socket.PortNumber from Int?
In local.glasgow-haskell-users, you wrote: Think of it this way: mkPortNumber has been renamed to fromIntegral, and now supports making port numbers from any integral type, not just Int. I didin't see the need for a special purpose convesion from Int, when fromIntegral does the job in a much more general way. Okay, here a nice way to handle this: #if __GLASGOW_HASKELL__ = 501 mkPortNumber = fromIntegral #endif -- 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
finalizers broken (4.08.2 5.00)
Okay, I suppose I ain't telling any news here, *but* *usually* people complained
about finalizers being never run. I just discovered that my finalizers are run
*too* *early*, probably because of unsafe{Perform,Interleave}IO:
Consider this fragment which will interleave two lists/streams (they're
created using something similiar getChanContents using unsafeInterleaveIO, too).
mergeStreams :: [a] - [b] - IO [Either a b]
mergeStreams a b = do
ch - newChan
t1 - forkIO (writeList2Chan ch (map Left a))
t2 - forkIO (writeList2Chan ch (map Right b))
result - getChanContents ch
addFinalizer result (print fin! killThread t1 killThread t2)
return result
The finalizer is run after I access the second argument of the resulting
stream, although more items are in the list. Removing the addFinalizer statement
will give the desired behaviour.
This happens both in 4.08.2 5.00.
--
Abstrakte Syntaxträume.
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Exceptions and sockets
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
Patch [Re: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]]
I attached a fix which will NOT source a suspicious file and print out a warning. Could anyone with Wintendo please confirm that the Posix-stuff doesn't break anything for them? -- Abstrakte Syntaxträume. Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME --- ghci/InteractiveUI.orig Mon Apr 30 09:41:28 2001 +++ ghci/InteractiveUI.hs Mon Apr 30 10:27:08 2001 @@ -40,12 +40,13 @@ import Directory import IO import Char -import Monad ( when ) +import Monad ( when, unless ) import PrelGHC ( unsafeCoerce# ) import Foreign ( nullPtr ) import CString ( peekCString ) +import Posix - ghciWelcomeMsg = \ @@ -144,14 +145,33 @@ options = [ShowTiming] } return () - +-- check permissions on .ghci files, so we don't slurp any nasty stuff like :! rm +-rf +checkPerms :: String - IO Bool +checkPerms name = do + Exception.catch (do + st - getFileStatus name + let owner = fileOwner st + me - getRealUserID + if owner /= me then do + putStrLn $ *** WARNING: ++ name ++ is owned by someone else, IGNORING! + return False + else do + let mode = fileMode st + if (groupWriteMode == (mode `intersectFileModes` groupWriteMode)) || +(otherWriteMode == (mode `intersectFileModes` otherWriteMode)) then do + putStrLn $ *** WARNING: ++ name ++ is writeable by someone else, +IGNORING! + return False + else return True + ) ( \_ - return True) -- doesn't really matter + runGHCi :: GHCi () runGHCi = do -- read in ./.ghci - dot_ghci - io (IO.try (openFile ./.ghci ReadMode)) - case dot_ghci of - Left e - return () - Right hdl - fileLoop hdl False + c - io $ checkPerms ./.ghci + when c $ do +dot_ghci - io (IO.try (openFile ./.ghci ReadMode)) +case dot_ghci of + Left e - return () + Right hdl - fileLoop hdl False -- read in ~/.ghci home - io (IO.try (getEnv HOME)) @@ -160,11 +180,13 @@ Right dir - do cwd - io (getCurrentDirectory) when (dir /= cwd) $ do - dot_ghci - io (IO.try (openFile (dir ++ /.ghci) ReadMode)) - case dot_ghci of -Left e - return () -Right hdl - fileLoop hdl False - + let file = dir ++ /.ghci + c - io $ checkPerms file + when c $ do + dot_ghci - io (IO.try (openFile file ReadMode)) + case dot_ghci of + Left e - return () + Right hdl - fileLoop hdl False -- read commands from stdin #ifndef NO_READLINE readlineLoop @@ -185,20 +207,18 @@ case l of Left e | isEOFError e - return () | otherwise- throw e - Right l - - case remove_spaces l of -- fileLoop hdl prompt - l - do quit - runCommand l -if quit then return () else fileLoop hdl prompt + Right l - do + let l = remove_spaces l + quit - runCommand l + unless quit $ fileLoop hdl prompt stringLoop :: [String] - GHCi () stringLoop [] = return () stringLoop (s:ss) = do - st - getGHCiState - case remove_spaces s of -- stringLoop ss - l - do quit - runCommand l - if quit then return () else stringLoop ss + -- XXX [vs] NOP? st - getGHCiState + let l = remove_spaces s + quit - runCommand l + unless quit $ stringLoop ss #ifndef NO_READLINE readlineLoop :: GHCi () @@ -210,16 +230,17 @@ Nothing - return () Just l - case remove_spaces l of -- readlineLoop - l - do - io (addHistory l) - quit - runCommand l - if quit then return () else readlineLoop + - readlineLoop + l - do + io (addHistory l) + quit - runCommand l + unless quit readlineLoop #endif -- Top level exception handler, just prints out the exception -- and carries on. runCommand :: String - GHCi Bool +runCommand = return False runCommand c = ghciHandle ( \exception - (case exception of PGP signature
Re: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]
In local.glasgow-haskell-bugs, you wrote: fstat() (this is one reason why using access() is generally discouraged). Using fstat() isn't particularly convenient from Haskell - there's Posix.getFdStatus, but we'd have to use the Posix openFile interface and fdToHandle. Alternatively we also can check ownership of the directory. And the ownership of .., and ../.. and ... Hm. Maybe the best way would be to steal some C-code from things like ssh and paste it. Michael keeps on mumbling something about a libflock, whatever. -- Abstrakte Syntaxträume. Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ghc5] (internal?) Bug in Socket.listen
Disclaimer: I noticed that Socket.lhs didn't change from 4.08.2. However, while Socket.listen works on 4.08.2, it *blocks* with ghc5. The listening socket isn't even visible by netstat -an! A Linux-strace looks like this: socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4 fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 --- SIGVTALRM (Virtual timer expired) --- sigreturn() = ? (mask now []) [SIGVTALRM ad libitum, nothing else happens] Does somebody have any thoughts about what's happening here? -- Abstrakte Syntaxträume. Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: RTLD_GLOBAL not available on FreeBSD 3.x
In local.glasgow-haskell-bugs, you wrote: The RTLD_GLOBAL symbol (used as an argument to dlopen in rts/Linker.c) is not available on FreeBSD 3.x. I'm replacing the offending line as follows // hdl = dlopen(buf, RTLD_NOW | RTLD_GLOBAL ); hdl = dlopen(buf, RTLD_LAZY ); and hoping for the best. SimonM: is RTLD_GLOBAL available on more modern FreeBSD's? I guess it must be, because I never had any trouble with this code on FreeBSD 4.x. While we're on the subject of FreeBSD: I'll be updating the FreeBSD package in the next week or so and sending the changes to the FreeBSD ports folk. Last time I checked (about a month ago), GHCi works fine on FreeBSD 4.x. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs -- Abstrakte Syntaxträume. Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ghci] Comparison with Hugs
In Hugs I can throw some definitions into a file and load it on the shell command line or using :l in Hugs. ghci however will complain that main is missing and even won't keep the defined functions in scope. Is there anything I can do about that? It even doesn't invoke main if it's present. I could hack ghci do add main = print 1 in case main is undefined, but that's not really something I'd like to admit afterwards... -- 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: [ghc5] getDirectoryContents: trouble on Linux/NFS
In local.glasgow-haskell-bugs, I wrote:
On several Linux machines
where my home directory is mounted by NFS from a Solaris machine,
I get the following behaviour both in ghc and ghci:
Directory.getDirectoryContents will throw an error on any directory in
"NFS-space", so even *calling* ghc or ghci causes problems:
Okay, Michael W. and I tracked this s*cker down: There's a known breakage
in glibc, which is fixed at least in the current ver. 2.2.2 (maybe earlier).
Sometimes NFS will cause this error and readdir(2) -- which is used by
Directory.getDirectoryContents! -- will fail.
Our suggestions to Linux-owners with NFS mounts from non-Linux machines:
Upgrade to a recent glibc. It's not GHC's fault.
Although the arising problem is sometimes reported as being rather
non-deterministic, it proved quite "reliable" in our department where
several machines consistently show the faulty behaviour.
--
\usepackage[latin1]{inputenc}!
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
