Socket documentation
Hi, The function mkPortNumber is gone from the Socket library: Prelude :t Socket.mkPortNumber interactive:1: Variable not in scope: `Socket.mkPortNumber' Though it is still mentioned in the documentation for GHC-5.02. /Koen. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Socket documentation
The function mkPortNumber is gone from the Socket library: Prelude :t Socket.mkPortNumber interactive:1: Variable not in scope: `Socket.mkPortNumber' Though it is still mentioned in the documentation for GHC-5.02. Sorry about that. Duly removed. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): Oversize heap check detected. Please try compiling with -O.
On Mon, Oct 01, 2001 at 10:52:32AM +0100, Simon Marlow wrote: This is a known bug, but thanks for reporting it anyway. The workaround is as suggested, try compiling with -O. I *was* compiling with -O. IIRC the problem occured with any level of optimisation I tried if and only if profiling was enabled. Any other suggestions? You could try breaking up the structure into smaller pieces. If you have a local GHC build, you can also bump the BLOCK_SIZE to 8k in ghc/rts/Constants.h. Did you mean ghc/includes/Constants.h? Changing #define BLOCK_SIZE 0x1000 to #define BLOCK_SIZE 0x2000 in there and rebuilding produced a build which produces code that segfaults. Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: enormous executable
| Surely the executable itself is only linked with the | functions that are actually used by the program? AFAIUI the GNU linker is not clever enough to remove junk on a per-function basis, only on a per-object basis. This is why we do object-splitting -- by breaking libraries up into thousands of .o files before rolling them into a .a, the effectiveness of what GNU ld can do is enhanced. Perhaps more recent GNU ld's do better on some platforms? I have a vague recollection of some -gc-sections flag. Yup, but it needs compiler support. The idea is to get the compiler to put each function in its own section, then the linker removes unused sections from the linked image. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-pkg
I notice that the method for detecting the configuration of ghc (for building 'hmake') no longer works with 5.02. This must be the most unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00, and now 5.02 as well! ghc-pkg-5.00 --show-package std --field import_dirs /usr/malcolm/local/lib/ghc-5.00/imports/std ghc-pkg-5.02 --show-package std --field import_dirs $libdir/imports/std There does not appear to be any way to persuade the new ghc-pkg to reveal what $libdir is set to. Can someone give me a clue how to discover this information? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-pkg
I notice that the method for detecting the configuration of ghc (for building 'hmake') no longer works with 5.02. This must be the most unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00, and now 5.02 as well! ghc-pkg-5.00 --show-package std --field import_dirs /usr/malcolm/local/lib/ghc-5.00/imports/std ghc-pkg-5.02 --show-package std --field import_dirs $libdir/imports/std There does not appear to be any way to persuade the new ghc-pkg to reveal what $libdir is set to. Can someone give me a clue how to discover this information? Oh woe is me. Sorry about that - we went to some effort to make the package configuration independent of the installation location, in order to make various things less fragile. The installation location can be discovered on a Unix system by looking up the -Bdir argument in the ghc script. On a Windows installation, you have to derive $libdir from the location of GHC itself. Perhaps it would be easier to have hmake just invoke 'ghc --make' under the hood? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: enormous executable
Mon, 1 Oct 2001 09:55:11 +0100, Simon Marlow [EMAIL PROTECTED] pisze: We don't have support for shared libraries under Unix at the moment. It has been investigated at various times in the past, and I believe the story is that we couldn't do it without at least losing some performance (more performance loss than you get from compiling C into a shared library). There is also a big problem of binary incompatibility between different versions of ghc, and dependence on the exact version of modules our package depends on. Dynamic libraries work for C because C has a very stable ABI. Also it's easy to maintain binary compatibility in libraries. I'm afraid that cross-module optimizations of ghc make dynamic libraries nearly impractical. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-pkg
Simon Marlow wrote: Perhaps it would be easier to have hmake just invoke 'ghc --make' under the hood? I don't think ghc --make is mature enough to replace other make tools yet. For example, when trying to compile Fudgets with ghc-5.02 --make -O2, with GHCRTS=-M100M, I got GHC's heap exhausted; while trying to allocate 0 bytes in a 9744-byte heap; use the `-Hsize' option to increase the total heap size. after about 2/3 of the library had compiled. GHC also left 54MB of junk behind in /tmp. I don't know exactly how big the heep needs to be, or how much free space in /tmp is needed to compile all of fudgets (285 modules), but I think it is clear that this behaviour is horrendous... As a comparison, using hmake, or some other make tool, fudgets compile just fine with ghc-5.02 -O2 , GHCRTS=-M40M (perhaps even less, I haven't tried), using only a few megabytes of space in /tmp. Additionally, ghc --make lacks (AFAIK) several useful features found in other make tools (although not all in the same tool...): 1. The ability to distingush directories containing source code to be compiled from directories containing previously compiled code (hmake has the flags -P and -i, hbcmake has -i and -I). (I guess you could use -package-conf as a cumbersome substitute, though.) 2. The ability to specify compiler flags for individual modules without putting them in the source code. (Some flags are 'static' and can not be put in the source code.) 3. The ability to compile several modules in parallel, on a multi-processor machine, or a network of workstations. 4. The ability to automatically invoke program generators (e.g. happy)... 5. A graphical user interface. Regards, Thomas Hallgren ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: enormous executable
Simon Marlow [EMAIL PROTECTED] wrote, | Surely the executable itself is only linked with the | functions that are actually used by the program? AFAIUI the GNU linker is not clever enough to remove junk on a per-function basis, only on a per-object basis. This is why we do object-splitting -- by breaking libraries up into thousands of .o files before rolling them into a .a, the effectiveness of what GNU ld can do is enhanced. Perhaps more recent GNU ld's do better on some platforms? I have a vague recollection of some -gc-sections flag. Yup, but it needs compiler support. The idea is to get the compiler to put each function in its own section, then the linker removes unused sections from the linked image. Sounds much better than the mess that -split-objs produces on the harddisk. Cheers, Manuel ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: enormous executable
On 2001-10-03T10:37:24+1000, Manuel M. T. Chakravarty wrote: Simon Marlow [EMAIL PROTECTED] wrote, | Surely the executable itself is only linked with the | functions that are actually used by the program? AFAIUI the GNU linker is not clever enough to remove junk on a per-function basis, only on a per-object basis. This is why we do object-splitting -- by breaking libraries up into thousands of .o files before rolling them into a .a, the effectiveness of what GNU ld can do is enhanced. Perhaps more recent GNU ld's do better on some platforms? I have a vague recollection of some -gc-sections flag. Yup, but it needs compiler support. The idea is to get the compiler to put each function in its own section, then the linker removes unused sections from the linked image. Sounds much better than the mess that -split-objs produces on the harddisk. I don't think the native ld on alpha-dec-osf3 supports such a feature, so we would (I assume) have to leave -split-objs in ghc even if we do implement -ffunction-sections/-fdata-sections. (Would it just be a matter of enabling it when invoking gcc? Would I be able to try it on my i386-linux box with -optc-ffunction-sections? Or I suppose the mangler would need to be educated...) -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig PGP signature
Haskell 98 Report: October release
It's that time of the month! Another iteration of the Revised Haskell 98 Report! http://research.microsoft.com/~simonpj/haskell98-revised I'm happy to say that my orbit is diminishing in radius and I shall shortly turn into a black hole. Seriously, the main things I've done this time (apart from a few more typos) is to * revise yet again the wording about export lists * revoke the change that removed Ord as a superclass of Ix But there are other minor things: grep for Oct 2001 in the list of chages. Feedback please... Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
WICS'2002: Extended Deadline
Apologies if you receive multiple copies * Due to a number of requests and some other reasons, the Deadline is extended. * WICS'2002 The Fourth Workshop on Information Computer Science March 17-18, 2002 King Fahd University of Petroleum Minerals, Dhahran, Saudi Arabia Information Computer Science Department (KFUPM) in collaboration with IEEE Computer Society Saudi Arabia Chapter Theme: Internet Computing Best papers will be published in A Special Issue Of Information Sciences Journal Important Dates: November 05, 2001 Papers due (about 15 pages). December 20, 2001 Notification of acceptance. January 20, 2002 Camera-ready papers. March 17 - 18, 2002 Workshop. For detailed information, please visit: http://www.ccse.kfupm.edu.sa/wics/ Contact Address : Chairman, Organizing Committee, WICS'2002 Department of Information Computer Science KFUPM # 5066 King Fahd University of Petroleum and Minerals Dhahran 31261, Saudi Arabia Tel.: +966-3-860-2175 Fax: +966-3-860-2174 Email: [EMAIL PROTECTED] WWW: www.ccse.kfupm.edu.sa/wics/ BEGIN:VCARD VERSION:2.1 N:;Sarfraz,;Muhammad FN:Sarfraz, Muhammad EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20011002T085816Z END:VCARD
Re: Haskell 98 Report: October release
the main things I've done this time is to * revise yet again the wording about export lists Two of the changes to Export Decls (Section 5.2) now conflict with each other. [Oct 2001] The form `module M' abbreviates the set of all entities whose unqualified name, e, is in scope, and for which the qualified name M.e is also in scope and refers to the same entity as e. [Sept 2001] For example module A ( module B, C.f, g ) where -- an invalid module import qualified B(f,g) import qualified C(f) g = True There are name clashes in the export list between B.f and C.f and between g and B.g even though there are no name clashes within module A. The latter example is now in fact a perfectly valid module, since there is no unqualified entity f in scope, and g and B.g do not refer to the same entity. Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell tutorial
Just spotted this Haskell tutorial at IBM developerWorks (free registration required): http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-b ytitle/9A31A3C4A0CE683E86256AD400822942?opent=grl,l=805,t=haskell (hope that URL doesn't get mangled by Exchange...). Looks like it's aimed at non-functional-programmers. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GHC doesn't compile Happy example
Carlos Scheidegger writes:
First, the Happy example uses some functions that exist in
Hugs but not in GHC, like isAlpha, isDigit and isSpace (I think so,
at least, because i type ':t isAlpha' in GHCi and get
'variable not in
scope'), so I created a module called CharClasses with these
functions.
This is a long-standing known bug in Hugs. These functions are
available from the Char module.
So, I ran happy and generated calc.hs without any problems.
When I try to compile calc.hs, by doing
ghc -o calc.exe calc.hs CharClasses.hs
I get:
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__1.o)(.text+0x16)://c/tmp/ghc1756.hc:
undefined reference to `__stginit_Main'
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__2.o)(.text+0x4)://c/tmp/ghc1756.hc:
undefined reference to `Main_main_closure'
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__2.o)(.text+0x33)://c/tmp/ghc1756.hc:
undefined reference to `Main_main_closure'
It looks like perhaps the calc.hs module isn't declared as module Main.
Another strange behavior is that I can only call the main function
once. Any other call I get:
Happy main
*** Exception: illegal operation
Action: hGetContents
Handle: {loc=stdin,type=semi-closed,binary=False,buffering=line}
Reason: handle is closed
File: stdin
This is the defined behaviour of getContents: it puts the stdin Handle
in a state known as semi-closed, wherein any further I/O operations on
it are forbidden. Because I/O state is retained between computations,
the semi-closed state persists until the next :load or :reload command.
You can make these handles reset themselves after every evaluation by
giving GHCi the command ':set +r'. This works because stdin, stdout and
stderr are just top-level expressions that can be reverted to their
unevaluated state in the same way as any other top-level expression
(CAF).
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98 Report: October release
hello, this was a bug in the report, the B import should not be qualified. it has been fixed in the latest version of the report. [Sept 2001] For example module A ( module B, C.f, g ) where -- an invalid module import qualified B(f,g) import qualified C(f) g = True There are name clashes in the export list between B.f and C.f and between g and B.g even though there are no name clashes within module A. The latter example is now in fact a perfectly valid module, since there is no unqualified entity f in scope, and g and B.g do not refer to the same entity. bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: update in-place
Cagdas Ozgenc [EMAIL PROTECTED] writes:
Could you help me on this notation?
Perhaps?
data Foo = Foo { a :: Int, b :: String }
This declares a Foo constructor with two named fields, and Int a and
a String b. This is equivalent to declaring
data Foo = Foo Int String
but with a couple of extra features added, among others that
you automatically get defined functions a and b which take a Foo
object and return the values of the respective parts.
instance Show Foo where
show f = show (a f) ++ ++ show (b f)
...so the (a f) and (b f) parts are just extracting the relevant
information from the Foo.
If you know Lisp, it's fairly similar to defstruct.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Doing exercises from Haskell tutorial ...
02 Oct 2001 15:16:27 +0300, Dmitry Astapov [EMAIL PROTECTED] pisze: I need to define SetsAsLists as an instance of Set by supplying definitions for all Set methods, but definitions I wrote led me to adding additional constraints on union and memeber methods. What constraints? The class already says that these operations require Eq on the element type: class Set s where empty :: s a isEmpty :: s a - Bool singleton :: a - s a union :: Eq a = s a - s a - s a member :: Eq a = a - s a - Bool choice :: s a - (a, s a) -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
