- Glasgow-haskell-users

FREE Biotech Stock Info! 71
by biotechstox57＠juno.com 24 Mar '01

24 Mar '01

1 0

wanted: examples of Socket.hs usage
by Johannes Waldmann 23 Mar '01

23 Mar '01

Dear all, I am looking for some code that uses ghc's Socket module. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0

RE: Question concerning ftp and GHC binaries for HP-UX
by Simon Marlow 22 Mar '01

22 Mar '01

> I would like to download the GHC binaries to our HP 9000 > machine (HP-UX > 11.0), but have access only to ftp (i.e., no Web browser is > available). > Does anyone know what ftp address to use? Also, does anyone > know whether > the GHC binaries for the HP-UX operating system will work on > HP-UX 11.0? I've put the GHC dists in ftp://www.haskell.org/pub/ghc, you should be able to download them from there. I don't know if it'll work with HP-UX 11.0, it was built on 10.20 with gcc 2.7.2.1. Also, gcc 2.95.2 is known not to work with GHC on HP-UX at the moment. Cheers, Simon

1 0

Question concerning ftp and GHC binaries for HP-UX
by ADAMS,RICHARD (Non-HP-Roseville,ex1) 21 Mar '01

21 Mar '01

I would like to download the GHC binaries to our HP 9000 machine (HP-UX 11.0), but have access only to ftp (i.e., no Web browser is available). Does anyone know what ftp address to use? Also, does anyone know whether the GHC binaries for the HP-UX operating system will work on HP-UX 11.0? I am not sure whether it is relevant, but I use Reflection terminal emulation to telnet from my PC to the HP 9000 machine. Truly 'hi-tech' :) . Thank you. Sincerely, Richard E. Adams Softmatrix, Inc. Roseville, CA Email: richard_adams(a)non.hp.com

1 0

Proposed change to ghc installation procedures
by Julian Seward (Intl Vendor) 21 Mar '01

21 Mar '01

Greetings, GHC users. If you install GHC from .rpm's, Debian .deb's, InstallShields, or other package formats, READ NO FURTHER. The following DOES NOT AFFECT YOU. The following applies ONLY if you install GHC from binary .tar.gz files. (Sparc-solaris users might, for example). As the GHC 5 release approaches, we're considering changing how binary builds of GHC are installed. The main aim of this proposal is to simplify parts of the GHC build system which have gotten a bit out of hand and are proving difficult to maintain as a result. The purpose of this message is to show the proposed changes and find out if it will cause problems for people. Up till now, the installation procedure (eg with 4.08.2) was gzip -dc ghc-4.08.2-my-platform-descriptor.tar.gz | tar xvf - cd ghc-4.08.2 ./configure --prefix=/where/ghc/should/be/installed make install The proposed new installation scheme is in fact a return to an old scheme: gzip -dc ghc-4.08.2-my-platform-descriptor.tar.gz | tar xvf - and then edit by hand ghc-4.08.2/bin/my-platform-descriptor/ghc5 to set the GHC_TOPDIR env variable to point to the top of the installation tree. So you run the distributed image in-place. The initial edit of the ghc5 script allows it to know where it is installed. This simplifies our build process; no longer do we need to create an installation-time Makefile or configure script and all its supporting junk. I assume that most users install from .rpms, so this change only affects package builders and sparc-solaris users. Please eeeep ASAP if this will cause you problems; otherwise we will go ahead with it in in the next couple of days. J

3 2

Re: Lightningspeed haskell
by Ketil Malde 20 Mar '01

20 Mar '01

Jan-Willem Maessen <jmaessen(a)mit.edu> writes: > Absolutely. Good high-level thread support trumps anything provided > by the operating system. Unless you have more than one CPU... > Similar dramatic performance disparities have cropped up in the Java > community. There are Java benchmarks which create thousands of > threads; most implementations slow to a crawl when this happens, as > the operating system collapses under the crushing load. In particular, Linux will have a problem with thousands of *runnable* processes. There's some potentially nasty O(>n) complexities when processing the run queue, so while a couple of runnable processes is very fast, having lots is not. In practice, most processes are blocked on IO most of the time, so it seems it's only a problem for certain Java benchmarks. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

RE: AIX port
by Simon Marlow 19 Mar '01

19 Mar '01

> I've got access to an IBM RS/6000SP system, with the > Power3 CPUs. I'd love to see GHC up and running on > this system. According to the list of working ports, > this wouldn't be too hard to get working. > > Has anyone tried doing this? Are there any tips > for how to begin? No one has tried recently, as far as I know. A good place to start would be to read the recent discussions on this list regarding porting to PowerPC/MacOS-X. The basic idea is to get the system up and running "unregisterised" first, which can be done with just a C compiler on the host system, then try to get the registerised bits working. The MacOS X port is still at the unregisterised stage, but they have a problem with a seriously crippled gcc. Asuming AIX's gcc is ok, it's just a case of updating a few bits & pieces, and possibly pulling in some small bits of code from the GHC 3.X runtime. We'll be happy to help out along the way. Cheers, Simon

1 0

AIX port
by Brian Gregor 19 Mar '01

19 Mar '01

I've got access to an IBM RS/6000SP system, with the Power3 CPUs. I'd love to see GHC up and running on this system. According to the list of working ports, this wouldn't be too hard to get working. Has anyone tried doing this? Are there any tips for how to begin? -brian

1 0

Re: How do I force evaluation?
by Matthias Fischmann 13 Mar '01

13 Mar '01

Yes, that does not look very nice but it should work. In a private response, I was also pointed out the alternative solution of using case together with `seq` to trigger evaluation, which looked like the default way to me (what else is seq for?): | case monstrousDS `seq` True of True -> hPutStr stderr "ok." I first tried to wrap this in a `force' function, thereby proving that I still haven't grasped the concept entirely. (-: But maybe it is possible to make a primitive of this in the same way as has been done with assert? Anyway thanks for all your help, Matthias "Jan de Wit" <jwit(a)studenten.net> writes: > Hi, > > > I want to do something like: > > > > | main = do > > | monstrousDataStructure <- monstrousComputation > > | hPutStr stderr "success!" > > | ... > > > > The important point is that I want to make sure that the computation > > has terminated and not failed before I go to `...'. > If the monstrous data structure has a 'serious' equality (not always > returning True), you can try: > > | main = do > | monstrousDataStructure <- monstrousComputation > | if (monstrousDataStructure == monstrousDataStructure) then > | hPutStr stderr "success!" > | else > | hPutStr stderr "failure?" > > The idea is that comparing for equality walks over the entire data > structure, forcing evaluation because every location has to be inspected. > > Hope this helps, > Jan de Wit > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Matthias Fischmann | Research Engineer | +358 (9) 8565 7474 fis(a)ssh.fi | SSH Communication Security Corp | +358 (40) 752 5291

2 1

GHC HQ are looking for a Linux-IA64 box
by Julian Seward (Intl Vendor) 12 Mar '01

12 Mar '01

[Apologies if you get multiple copies of this msg.] Folks, Following a recent discussion about future development directions for GHC, it seems one thing we want to start thinking about is support for the IA64 architecture. Does any kind person have an IA64 box, running Linux, on which we could have an account? The extent of the work would be to make GHC's runtime-support system work again on a 64-bit platform (it used to), and possibly to build an IA64 native code generator. This work would be spread across a couple of months, I imagine. Basic requirements are: * IA64 Linux box, with development tools (gcc, perl, autoconf, gdb, etc -- all the usual Linux/Unix stuff). * As many spare processor cycles as possible. GHC building/debugging tends to CPU intensive. Also, probably at least 256MB of memory would be necessary to keep us out of trouble. * At a bare minimum, 300 MB of free disk space; 1 GB would be preferable, since it would allow more thorough testing of the system. * Decent, permanent, reliable internet connection from so that we can work remotely (obviously) and so that we can talk to our CVS server. I'd say at a bare minimum a 128 kb/sec connection. Preferably as few as possible network hops from Cambridge, UK. This work is likely to be on-and-off (not all the time) over a couple of months, I'd guess. We probably won't be ready to start on it for at least a month, so some time around the start of May would be when we'd really want to start moving on this. Availability of such a machine would be a useful contribution to the GHC development effort, so we'd be grateful if any of you could point us in the right direction. J (speaking for the GHC crew as a whole)

2 1