ghci
The following code works fine under ghc, but produces a strange error under ghci: Main main *** Exception: failed Action: connect Reason: Unknown error 141312000 It is deterministic - i.e I have verified that it isn't a network fault. module Main(main) where import Socket import IO(hPutStr,hFlush,hGetLine) alexa_host = iq.org. main = connectUp alexa_host 80 connectUp :: Hostname - Integer - IO () connectUp host port = do h - connectTo host (PortNumber (fromIntegral port)) hPutStr h GET / HTTP/1.0 \r\n\r\n hFlush h line - hGetLine h putStrLn line Additionally, I'm a little confused about how to import the PortNumber constructor from Socket, without importing everything else. It's behavior seems odd. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
unliftM
Is there a standard construct for something of this ilk: unliftM :: Monad m a - a In this case, I need to construct a localised stateful computation comp :: Int - Int comp n = unliftM (do x - ... return x) -- Julian Assange|If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and [EMAIL PROTECTED] |work, but rather teach them to long for the endless [EMAIL PROTECTED] |immensity of the sea. -- Antoine de Saint Exupery ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
Peter Douglass [EMAIL PROTECTED] writes: Julian Assange wrote (Dec 28, 2000): This is why all non S-exp like lanaguage are doomed to progressive syntactic cancer as the useful parts of operator name space and syntax space become progressively polluted and mutated by one fad after another. Could you expand on this? I would think that all languages have identifies that, through common usage become standardized, and that this meaning becomes a de-facto part of the language. Do you feel that this has not happened in Lisp/Scheme? The identifier space in lisp/scheme has wide tree depth and is (essentially) lexically scoped. Infix operator identifiers in other languages are the antithesis of this. It could be argued, both fairly and unfairly, that the verbosity of S-exp bracketing leaves short identifiers less desirable than they otherwise would be, however tree-width arguments remain. Polution of syntax space is a more difficult problem. As new syntactic axioms are intruded, they should remain consistant with the existing syntax elements. This poses ever increasing restraint on the evolution of the language. New syntax elements appear less intuitive and more arbitary in an attempt to fit in with the morass of ever increasing restraints. If these restraints are not honnored, the language becomes inconsistant. Eventually the language is guarenteed to become either inconsistant or moribund as the number of interactions between language elements overwhelms a language designers attempts understand them. The same is even more true of language semantics. The trouble lays in finding initial axioms which can cleave large sections of future concept space between them. -- Julian Assange|If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and [EMAIL PROTECTED] |work, but rather teach them to long for the endless [EMAIL PROTECTED] |immensity of the sea. -- Antoine de Saint Exupery ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
George Russell [EMAIL PROTECTED] writes: I'm writing, but that shouldn't be too hard to tweak. In particular I have followed SML in using "." to express qualification by something, even though Haskell already used "." for something else, because I can't be bothered right now to dig up a better symbol. This is why all non S-exp like lanaguage are doomed to progressive syntactic cancer as the useful parts of operator name space and syntax space become progressively polluted and mutated by one fad after another. -- Julian Assange|If you want to build a ship, don't drum up people |together to collect wood or assign them tasks [EMAIL PROTECTED] |and work, but rather teach them to long for the endless [EMAIL PROTECTED] |immensity of the sea. -- Antoine de Saint Exupery ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Programming in Latin
Monash University School of Computer Science and Software Engineering 2000 Clayton campus Seminar Series -- Seminar: Programming in Latin (and Why You Really Might Want To) Speaker: Dr Damian Conway ([EMAIL PROTECTED]), School of Computer Science and Software Engineering, Monash University Date: MONDAY, 11 September 2000 Time: 2:00 pm Venue: Room 135, Computer Science Building (26), Clayton Campus Video Wall at Caulfield Campus Seminar Abstract: English has a comparatively weak lexical structure. Much of the grammatical load of a sentence is carried by positional cues. A statement such as: "The boy gave the dog the food." only makes sense because of the convention that the subject precedes the verb, which precedes the indirect object, which precedes the direct object. Changing the order -- "The food gave the boy the dog." -- changes the meaning. Most programming languages use similar positional grammatical cues. The instruction: maximum = next; is very different in meaning from: next = maximum; Generally speaking, older languages have richer lexical structures (such as inflection for noun number and case) and so rely less on word order. For example, in Latin the sentences "Puer dedit cani escam." and "Escam dedit puer cani." both mean "The boy gave the dog the food." Indeed, the more usual word order would be "Reverse Polish", with the verb coming last: "Puer cani escam dedit." This flexibility is possible because Latin uses inflection to denote lexical roles. There is no reason that programming languages could not also make use of inflection, rather than position, to denote lexical roles. This talk will describe an alternative syntactic binding for the Perl programming language. This binding uses inflections based on classical Latin grammar, rather than positional constraints. No prior knowledge of Latin will be assumed, but by the end of the talk the following program will make perfect sense: pre maximum inquementum tum biguttam tum stadium egresso scribe. vestibulo perlegementum da meo maximo . maximum tum novumversum egresso scribe. da duo tum maximum conscribementa meis listis. dum damentum nexto listis decapitamentum fac sic lista sic hoc tum nextum recidementum cis vannementa listis da. next tum biguttam tum nextum tum novumversum scribe egresso. cis /pre About The Speaker: Dr Damian Conway is a Senior Lecture in the School of Computer Science and Software Engineering at Monash University. His research interests include: language design, the teaching of programming, object orientation, software engineering, natural language generation, synthetic language generation, morphing, human-computer interaction, geometric modelling, the psychophysics of perception, nanoscale simulation, and parsing. School Contact: Damian Conway ([EMAIL PROTECTED] ) - - A complete list of forthcoming Monash (Clayton) Computer Science and Software Engineering seminars is available from: http://www.csse.monash.edu.au/cgi-bin/seminar?forthcoming Clayton campus parking information is available from: http://www.csse.monash.edu.au/cgi-bin/seminar?parking - - Andrew P. Paplinski (seminar coordinator) ([EMAIL PROTECTED]) - - Updated: 05 Sep 2000
Re: Precision problem
Fergus Henderson [EMAIL PROTECTED] writes: Jon Fairbairn was talking about Haskell. MSVC is a C/C++ compiler, not a Haskell compiler. For C and C++, there are many many areas of undefined, unspecified, or implementation-defined behaviour. If a C or C++ program gives different behaviour on different runs or with different compilation flags, this is almost always due to the program depending on one of those areas, rather than due to the compiler not conforming to the standard. Standard, shmandard. If a compiler can't produce reproducable code, then its of little value for scientific computing. Julian.
Re: Precision problem
Jon Fairbairn [EMAIL PROTECTED] writes: to me, anyway. If two runs (with different flags) of the compiler produce programmes that give different results, then one of them isn't adhering to the standard, (and so should be noted as such). Microsoft VCC once (still?) suffers from this problem. Whether it is because it accesses random, unassigned memory locations or because the optimiser has time thesholds, is unknown. Cheers, Julian.
ANNOUNCE: irc.haskell.org available!
We've created irc.haskell.org, linked into the Open-Projects irc network. The channels of interest are #haskell and #functional. Haskell has an excellent sense of community but real time communication (whether on-line or at conferences) is unsurpassed for bouncing prospective ideas about. Meeting times are 19:00 GMT Tuesdays and Fridays, although at other times there will generally be a couple of, albeit a little sleepy, people about who if treated nicely will probably be happy to answer haskell related questions. Ocaml users also meet at the same time (if there are any sml, moscow-ml, miranda or other functional language users on this list, perhaps they could be encouraged to #functional at the above times too to maximise cross-fertilisation). For more information about where to obtain an IRC client (dozens are available for any platform you care to name), see http://www.irchelp.org/ Server and port specifications are: Server: irc.haskell.org Port: 6667 One of the the four haskell.org name servers, serv3.net.yale.edu is currently out of date. If on the off chance (1/4) you hit this bogus name-server when trying to resolve `irc.haskell.org', you always use `suburbia.com.au' or `irc.ocaml.org' instead. btw can one of the www.haskell.org maintainers add the above to the list of www.haskell.org resources? Thanks. Cheers, Julian.
Re: More on Quantum vectors...
Frank Atanassow [EMAIL PROTECTED] writes: I would not be surprised to find this article appearing in the next Scientific American. Consider these gems: "Finger-Length Ratios and Sexual Orientation," Terrance J. Williams, "Why are Toads Right-Handed?" Nature, T. Naitoh and R.J. Wassersug, "Effect of Ale, Garlic, and Soured Cream on the Appetite of Leeches," Anders "Bed Rest: A Potentially Harmful Treatment Needing More Careful Evaluation," "Pigeons' Discrimination of Paintings by Monet and Picasso," Shigeru So, no matter what your problem, rest assured that, sometime, somewhere, somewhy, a scientist has probably already reported on it. [These citations are courtesy of the Annals of Improbable Research, http://www.improbable.com.] The Annals have gone down hill over time, three* of these papers were excellent. *No, I'm not telling you which three :) Cheers, Julian.
Re: Changing - to :=
"Mike Jones" [EMAIL PROTECTED] writes: imperative constructs, then build it in another language. If I can use :=, I can make it look more like the final system, which is good for "-" is visually intuitive and faster to type than ":=". So even in completely new (non ML/Haskell derived) language it seems preferable.
Re: Additions to the FFI API
Sven Panne [EMAIL PROTECTED] writes: 1) Although the Haskell 98 report states that Char should be a Unicode character, a plain char is used here. No implementation uses Unicode so far, and char is what one wants most of the time, anyway. HBC uses unicode for source. I'm not sure if this includes type Char ;) Cheers, Julian.
Re: Additions to the FFI API
Sven Panne [EMAIL PROTECTED] writes: itself and that compound values are a case for a (un-)marshaling library. We already have some ideas what this lib should look like and some slightly differing modules for this exist, see e.g. C-HS, the MPI binding or HOpenGL. Before a design for this is presented, the low-level details should be finished. Have you looked at the nice (un-)marshaling features of Ocaml? The implementation is such that fist class functions can be marshaled, un-marshaled and subsequently executed, even for natively compiled code. md5 checkums of functions ensure functional equivalence. Though in the native case you have to be running the same bit for bit binary at both ends of the marshaling pipe. i.e the scope of the md5 checksum is the entire binary. More interesting would be checksuming the function and type dependencies of functions to be marshalled as a parse tree. Or merely the names and types. In the latter cases marshaling would inolve either agreeing on function and type enumerations or sending canonical strings, although just how his can consistantly be done with anonymous lambdas remains to be seen. If you expect to be able to unmarshall stored functions after a code change, or have a number of possibly divergent co-operating (un-)marshalers that pass functions to one another, this ability to abstract away variance within a category from variance TO the category is vital, and something that haskell might be well suited to, given it's strong referential transparency. Cheers, Julian.
Re: why software needs an explicit license
George Russell [EMAIL PROTECTED] writes: I have no problem with software having an explicit license, I just don't see that it normally needs to be quoted at the top of EVERY module. (There are probably exceptional jurisdictions where it does, but not many.) The GHC method, where the license file is in the distribution and easy to find if you want it, seems fair enough to me. I take a compromise position and simply write (c) Copyright . See "LICENSING" file for details. -- Stefan Kahrs in [Kah96] discusses the notion of completeness--programs which never go wrong can be type-checked--which complements Milner's notion of soundness--type-checked programs never go wrong [Mil78].
Re: FYI: ghc to be dropped from potato (debian) + hbc
Antti-Juhani Kaijanaho [EMAIL PROTECTED] writes: On Fri, Mar 10, 2000 at 06:32:00AM -0500, Sengan wrote: http://www.debian.org/Lists-Archives/debian-devel-announce-0003/msg7.html It already *has* been dropped. Apparently the "sponsor" idea did not work as well as it should have. Hasn't been dropped from NetBSD :) btw, lennart, if you are reading, how about a hbc NetBSD pkg?
HOpenGL
I'm having problems building HOpenGL on NetBSD/i386: /usr/local/bin/green-card --target ghc --name-mangling-scheme=classic --haskell1.4 GLUT_Callbacks.gc -o GLUT_Callbacks.hs "GLUT_Callbacks.gc", proc. spec "", line 354: Parse error: Enum,Bounded) CUnsignedInt [ % GLUT_JOYSTICK_BUTTON_A, % GLUT_JOYSTICK_BUTTON_B, % GLUT_JOYSTI gmake[1]: *** [GLUT_Callbacks.hs] Error 1 gmake: *** [depend] Error 1 the same error is apparent both with and without --haskell1.4. Also, you were using --taget=ghc, which was wrong (should be --target ghc). Comments in GLUT_Callbacks.gc suggest that my green-card is antiquated, but however /usr/local/bin/green-card --version produces: green-card, version 2.0 And I can't seem to find any more recent version than that. Any ideas? Cheers, Julian.
Re: Haskell Clean
Michael Hobbs [EMAIL PROTECTED] writes: Adrian Hey wrote: On Mon 24 Jan, Michael Hobbs wrote: (*) One place where the World - (World, a) model breaks down is when the IO function is a blocking function such as "getChar :: IO Char". If this function was equivalent to World - (World, a) then that would mean that the result is completely determined by the input World value. As a world value sceptic myself, I am reluctant to say this, but in all honesty I don't think that this argument holds. If I understand you correctly your objection is that getChar should never block, it should get a character instantly because the information about which character will eventually be got should already be embedded in the input world value. Actually, I never thought about whether or not getChar should ever block. My intention is to point out that trying to wed referential transparency with I/O using the concept of World values is filled with philosophical ambushes and tiger traps. The particular trap I was trying to point out here was that of determinism. You just pointed out a different one along the same lines: If getChar really was referentially transparent, with respect to the given World value, should it block? This doesn't seem to be a problem to me. The second time around the world is different. Consequently the code is executed. Haskell has no sense of time, so whether it blocks or not is unimportant to the language. But the passage of time can be mixed in with the change of state in the world, if need be. Minerva uses world state passing too, btw. Cheers, Julian.
Re: On Haskell and Freedom
Jerzy Karczmarczuk [EMAIL PROTECTED] writes: The tombstone of Nicos Kazantzakis (The Last Temptation of Christ) has the following inscription: I hope for nothing. I fear nothing. I am FREE. Perhaps this is a tiny bit closer to my personal perception of freedom than the metaphysics of the Free Software Foundation. Well and good, but without fear and hope there is no motivation to do anything. Which is quite apt for a body in the ground, but for upright specimens such philosophical sentiment leads to stagnation. Cheers, Julian.
Re: Haskell Clean
Julian Assange [EMAIL PROTECTED] writes: Minerva uses world state passing too, btw. s/Minerva/Mercury Cheers, Julian.
Re: rounding in haskell
George Russell [EMAIL PROTECTED] writes: (LONG and about floating point, so I suspect many Haskellers are not going to be interested in this message . . .) Excellent, thanks george. Now I think the original suggestor wanted the library to spot that the answer is "very close to" 0 and actually replace it with 0. Absolutely not! For example, suppose I am trying to approximate the derivative of sin(x) near x=pi, by computing sin(x+epsilon) for very small epsilon, then the last thing I need is for the graph of the computed function to look like [..] Once you are within a few UDP, the underlaying grainyness of the representation is going to get you, so that smoothe, monotonic line segment you have below, will look like an appalling zigzag at best. This is my point. Near the limits of precession, the error introduced by rounding is trivial compared to the error introduced by the precission itself. This gsl library has special flags to deal with ieee maths on just this issue. See: http://sourceware.cygnus.com/gsl/ref/gsl-ref_toc.html#TOC306 \ \ \ -- \ \ \ -- Stefan Kahrs in [Kah96] discusses the notion of completeness--programs which never go wrong can be type-checked--which complements Milner's notion of soundness--type-checked programs never go wrong [Mil78].
rounding in haskell
The precission and or rounding used by hugs/ghc seems strange, to wit:
Prelude sin(pi)
-8.74228e-08
Prelude pi
3.14159
sin(3.14159265358979323846)
-8.74228e-08
ghc:
module Main where
main = do
print pi
print (sin pi)
./a.out
3.141592653589793
1.2246467991473532e-16
While this maybe accurate in terms of ieee foat and double, most maths
libraries round if a value is `close' to a small integer (such as 1,
0, -1), inorder to avoid amplification of missing precission during
iterative processes.
#include math.h
#include stdio.h
main(){
printf("sin(%f) = %f\n", M_PI, sin(M_PI));
}
M_PI is defined by math.h as 3.14159265358979323846
./a.out
sin(3.141593) = 0.00
Cheers,
Julian.
--
Warren Air Force Base in Cheyenne, Wyoming, recorded a message that
one of its Minuteman III intercontinental ballistic missiles was
about to launch from its silo due to a computer malfunction. To
prevent the possible launch, an armored car was parked on top of
the silo.
- Shaun Gregory, The Hidden Cost of Deterrence: Nuclear Weapons
Accidents, Brassey's UK, London, 1990, pp. 181-182.
Re: rounding in haskell
Lennart Augustsson [EMAIL PROTECTED] writes: Haskell performs no worse or better than C. Your comment about how math libraries round might be accurate for some languages, but for C it's pure nonsense. It seems that you are right in this instance. However I recall seeing comments about error cascading reducing rouding in the guts of libmsun, or in some fpe code somewhere (perhaps billm's linux fpe code?). Maybe they were only comments and not code. Does IEEE Std 754-1985 make internal rounding verboten? What about if you have 64 bits in your fp regs, but only advertise 56 bits through to the api? Cheers, Julian.
netbsd ghc pkg now available
Hi Simon.
The ghc package has been commited to the netbsd cvs repository
and is now available in pkgsrc as lang/ghc.
ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/lang/ghc
Simon Marlow [EMAIL PROTECTED] writes:
By the way, did you also modify fptools/configure.in in order to get the
netbsd-elf target?
Yes, I did, however it's done in a way that is somewhat dependent on pkg magic,
i.e:
--- /p/lang/ghc/old/fptools/configure.inWed Sep 15 09:03:35 1999
+++ configure.inWed Dec 15 16:37:23 1999
@@ -138,7 +138,16 @@
HostPlatform_CPP='i386_unknown_netbsd'
HostArch_CPP='i386'
HostVendor_CPP='unknown'
-HostOS_CPP='netbsd'
+ if test "$HASKELL_OBJ_FMT" = "a.out"; then
+ HostOS_CPP='netbsd'
+ else
+ if test "$HASKELL_OBJ_FMT" = "ELF"; then
+ HostOS_CPP='netbsd_elf'
+ else
+ echo bad \$HASKELL_OBJ_FMT = "$HASKELL_OBJ_FMT"
+ exit 1
+ fi
+ fi
;;
i[[3456]]86-*-solaris2*)
HostPlatform=i386-unknown-solaris2 # hack again
Here's the pkg Makefile (with a few targets removed) that defines
HASKELL_OBJ_FMT. the nature of the ghc.lprl hackage is
self-evident. It would be nice to be able to pass the default ghc
compiler link paths in via configure.
Keep well,
Julian.
# $NetBSD$
DISTNAME= ghc-4.04
CATEGORIES= lang
MASTER_SITES= http://www.haskell.org/ghc/dist/4.04/
DISTFILES= ghc-4.04-src.tar.gz ghc-4.04-x86-hc.tar.gz
MAINTAINER= [EMAIL PROTECTED]
HOMEPAGE= http://www.haskell.org/ghc/
DEPENDS+= readline-4.0:../../devel/readline
DEPENDS+= gmp-2.0.2:../../devel/gmp
USE_PERL5= yes
USE_GMAKE= yes
GNU_CONFIGURE= yes
CONFIGURE_ARGS+= --enable-hc-boot --libdir=${PREFIX}/lib/ghc
CONFIGURE_ENV+= HASKELL_OBJ_FMT=`cat ${WRKDIR}/obj_fmt`
WRKSRC= ${WRKDIR}/fptools
pre-configure:
( lnl=${WRKDIR}/longandlow; \
${ECHO} 'int main(){exit(0);}' $$lnl.c \
${CC} $$lnl.c -o $$lnl \
file $$lnl | ( ${EGREP} '[^a-zA-Z][Ee][Ll][Ff][^a-zA-Z]' \
${ECHO} ELF || ${ECHO} a.out ) \
) ${WRKDIR}/obj_fmt
${SED} ${WRKSRC}/ghc/driver/ghc.lprl \
${WRKSRC}/ghc/driver/ghc.lprl.hacked \
'/push(@SysLibrary, "-l$LibGmp")/s%^%push(@SysLibrary,
"-L'${LOCALBASE}/lib'");%' \
${MV} -f ${WRKSRC}/ghc/driver/ghc.lprl.hacked \
${WRKSRC}/ghc/driver/ghc.lprl
Re: netbsd ghc pkg now available
Is NetBSD moving to ELF permanently? NetBSD supports 27 different platforms (see http://www.netbsd.org/Ports/). Some of platforms have always had native elf support, due to object format standisation by the vendor (e.g alpha). The i386 port has supported elf for a number of years, primarily for linux + freebsd binrary compatability. As of NetBSD1.5 (which given the combined forces of the moon and sun should be released sometime early next century), the i386 port shall stride into the faery kingdom and, as it were, `go native with elves'. To confuse matters further, on those platforms which support it, the entire build system can be instructed to produce elf _or_ a.out executables, libraries, etc, by simply setting OBJECT_FMT to `a.out' or `ELF'. Unbelievably this `just works' -- however -- if the aforementioned variable is not set, the only reliable way to determine the object encoding preference is to build a test executable (which is the approach I've taken in the NetBSD ghc package). Keep well, Julian. Here's the pkg Makefile (with a few targets removed) that defines HASKELL_OBJ_FMT. the nature of the ghc.lprl hackage is self-evident. It would be nice to be able to pass the default ghc compiler link paths in via configure. Good point. I'll take a look at this. Cheers, Simon -- Stefan Kahrs in [Kah96] discusses the notion of completeness--programs which never go wrong can be type-checked--which complements Milner's notion of soundness--type-checked programs never go wrong [Mil78].
Re: 4.04 posix/AF_UNIX lossage
Hi Simon, I eventually managed to produce an executable (but see
below) with the following patches (note that the address family
enumeration below is *not* identical to freebsd):
$NetBSD$
--- ghc/lib/misc/SocketPrim.lhs Wed Sep 15 09:06:26 1999
+++ ghc/lib/misc/SocketPrim.lhs Tue Dec 14 13:00:08 1999
@@ -941,10 +941,56 @@
#endif
+#if netbsd_TARGET_OS || netbsd_elf_TARGET_OS
+
+data Family =
+ AF_UNSPEC -- unspecified
+ |AF_UNIX -- local to host (pipes, portals)
+ |AF_INET -- internetwork: UDP, TCP, etc.
+ |AF_IMPLINK -- arpanet imp addresses
+ |AF_PUP -- pup protocols: e.g. BSP
+ |AF_CHAOS-- mit CHAOS protocols
+ |AF_NS -- XEROX NS protocols
+ |AF_ISO -- ISO protocols
+--|AF_OSI is the same as AF_ISO
+ |AF_ECMA -- european computer manufacturers
+ |AF_DATAKIT -- datakit protocols
+ |AF_CCITT-- CCITT protocols, X.25 etc
+ |AF_SNA -- IBM SNA
+ | AF_DECnet -- DECnet
+ | AF_DLI -- DEC Direct data link interface
+ | AF_LAT -- LAT
+ |AF_HYLINK -- NSC Hyperchannel
+ |AF_APPLETALK-- Apple Talk
+ |AF_ROUTE-- Internal Routing Protocol
+ |AF_LINK -- Link layer interface
+ |Pseudo_AF_XTP -- eXpress Transfer Protocol (no AF)
+ | AF_COIP -- connection-oriented IP, aka ST II
+ | AF_CNT -- Computer Network Technology
+ | Psuedo_AF_RTIP -- Help Identify RTIP packets
+ | AF_IPX -- Novell Internet Protocol
+ | AF_INET6 -- IPv6
+ | Pseudo_AF_PIP -- Help Identify PIP packets
+ | AF_ISDN -- Integrated Services Digital Network
+--| AF_E164is the same as AF_ISDN
+ | AF_NATM-- native ATM access
+ | AF_ARP -- (rev.) addr. res. prot. (RFC 826)
+ | Pseudo_AF_KEY -- Internal key-management function
+ | Pseudo_AF_HDRCMPLT -- Used by BPF to not rewrite hdrs in iface output
+ | AF_MAX
+ deriving (Eq, Ord, Ix, Show)
+
+packFamily = index (AF_UNSPEC, AF_MAX)
+unpackFamily family = (range (AF_UNSPEC, AF_MAX))!!family
+
+#endif
+
+
-- Alpha running OSF or a SPARC with SunOS, rather than Solaris.
#if osf1_TARGET_OS || osf3_TARGET_OS || sunos4_TARGET_OS || hpux_TARGET_OS || \
- aix_TARGET_OS || freebsd2_TARGET_OS || freebsd3_TARGET_OS
+ aix_TARGET_OS || freebsd2_TARGET_OS || freebsd3_TARGET_OS || \
+ netbsd_TARGET_OS || netbsd_elf_TARGET_OS
data SocketType =
Stream
| Datagram
diff -u -r old/fptools/ghc/rts/MBlock.c work.i386/fptools/ghc/rts/MBlock.c
$NetBSD$
--- ghc/rts/MBlock.cWed Sep 15 09:06:54 1999
+++ ghc/rts/MBlock.cTue Dec 14 10:27:15 1999
@@ -47,6 +47,10 @@
*/
#define ASK_FOR_MEM_AT 0x5000
+#elif netbsd_TARGET_OS
+/* NetBSD i386 shared libs are at 0x4000
+ */
+#define ASK_FOR_MEM_AT 0x5000
#elif linux_TARGET_OS
/* Any ideas?
*/
$NetBSD$
--- ghc/driver/ghc-asm.lprl Wed Sep 15 09:05:45 1999
+++ ghc/driver/ghc-asm.lprl Tue Dec 14 22:09:04 1999
@@ -104,7 +104,7 @@
$T_HDR_direct = "\t.SPACE \$TEXT\$\n\t.SUBSPA \$CODE\$\n\t\.align 4\n";
##
-} elsif ( $TargetPlatform =~
/^i386-.*-(linuxaout|freebsd2|nextstep3|cygwin32|mingw32)$/ ) {
+} elsif ( $TargetPlatform =~
+/^i386-.*-(linuxaout|freebsd2|netbsd|nextstep3|cygwin32|mingw32)$/ ) {
# NeXT added but not tested. CaS
$T_STABBY = 1; # 1 iff .stab things (usually if a.out format)
@@ -135,12 +135,12 @@
$T_HDR_direct = "\.text\n\t\.align 2,0x90\n";
##
-} elsif ( $TargetPlatform =~ /^i386-.*-(solaris2|linux|freebsd3)$/ ) {
+} elsif ( $TargetPlatform =~ /^i386-.*-(solaris2|linux|freebsd3|netbsd_elf)$/ ) {
$T_STABBY = 0; # 1 iff .stab things (usually if a.out format)
$T_US = ''; # _ if symbols have an underscore on the front
$T_PRE_APP = # regexp that says what comes before APP/NO_APP
- ($TargetPlatform =~ /-(linux|freebsd3)$/) ? '#' : '/' ;
+ ($TargetPlatform =~ /-(linux|freebsd3|netbsd_elf)$/) ? '#' : '/'
+;
$T_CONST_LBL= '^\.LC(\d+):$'; # regexp for what such a lbl looks like
$T_POST_LBL= ':';
$T_X86_PRE_LLBL_PAT = '\.L';
@@ -150,7 +150,7 @@
$T_MOVE_DIRVS =
'^(\s*(\.(p2)?align\s+\d+(,0x90)?|\.globl\s+\S+|\.text|\.data|\.section\s+.*|\.type\s+.*|\.Lfe.*\n\t\.size\s+.*|\.size\s+.*|\.ident.*)\n)';
$T_COPY_DIRVS = '\.(globl)';
-if ( $TargetPlatform =~ /freebsd3/ ) {
+if ( $TargetPlatform =~ /freebsd3|netbsd_elf/ ) {
$T_hsc_cc_PAT = '\.ascii.*\)(hsc|cc)
Makefile typos
--- /p/lang/ghc/old/fptools/MakefileWed Sep 15 09:03:33 1999 +++ MakefileWed Dec 15 16:04:58 1999 @@ -15,7 +15,7 @@ # on whether we do `make install' or not. Having a $(ifeq ... ) would # be preferable.. CURRENT_TARGET = $(MAKECMDGOALS) -SUBDIRS = $(shell if (test x$(CURRENT_TARGET) = xinstall) ; then echo $(ProjectsToInstall); else echo $(ProjectsToBuild); fi) +SUBDIRS = $(shell if test x$(CURRENT_TARGET) = xinstall) ; then echo +$(ProjectsToInstall); else echo $(ProjectsToBuild); fi) ifneq "$(Project)" "" include $(shell echo $(Project) | tr A-Z a-z)/mk/config.mk
4.04 posix/AF_UNIX lossage
when attempting to bootstrap under netbsd-current: ==fptools== gmake all -r; in /orb/s/netbsd/usr/pkgsrc/lang/ghc/work.i386/fptools/ghc/lib/misc rm -f CString.o ; if [ ! -d CString ]; then mkdir CString; else find CString -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -i../concurrent:../posix -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir CString -static-c CString.lhs -o CString.o -osuf o ghc: 90101184 bytes, 52 GCs, 2037934/3905668 avg/max bytes residency (4 samples), 10M in use, 0.00 INIT (0.00 elapsed), 2.22 MUT (2.51 elapsed), 0.97 GC (0.96 elapsed) :ghc ghc: module version unchanged at 1 touch CString.o ; rm -f SocketPrim.o ; if [ ! -d SocketPrim ]; then mkdir SocketPrim; else find SocketPrim -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -i../concurrent:../posix -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir SocketPrim -static -I../std/cbits -H12m -optc-DNON_POSIX_SOURCE -c SocketPrim.lhs -o SocketPrim.o -osuf o SocketPrim.lhs:14: Variable not in scope: `packSocketType' SocketPrim.lhs:14: Variable not in scope: `unpackFamily' SocketPrim.lhs:14: Variable not in scope: `packFamily' SocketPrim.lhs:14: Type constructor or class not in scope: `SocketType' SocketPrim.lhs:14: Type constructor or class not in scope: `Family' SocketPrim.lhs:134: Type constructor or class not in scope: `Family' SocketPrim.lhs:134: Type constructor or class not in scope: `SocketType' SocketPrim.lhs:235: Type constructor or class not in scope: `Family' SocketPrim.lhs:235: Type constructor or class not in scope: `SocketType' SocketPrim.lhs:241: Variable not in scope: `packFamily' SocketPrim.lhs:241: Variable not in scope: `packSocketType' SocketPrim.lhs:273: Data constructor not in scope: `AF_UNIX' SocketPrim.lhs:308: Data constructor not in scope: `AF_UNIX' SocketPrim.lhs:480: Data constructor not in scope: `AF_INET' SocketPrim.lhs:500: Data constructor not in scope: `AF_INET' SocketPrim.lhs:678: Variable not in scope: `unpackFamily' SocketPrim.lhs:678: Type constructor or class not in scope: `Family' SocketPrim.lhs:679: Variable not in scope: `packFamily' SocketPrim.lhs:679: Type constructor or class not in scope: `Family' SocketPrim.lhs:681: Variable not in scope: `packSocketType' SocketPrim.lhs:681: Type constructor or class not in scope: `SocketType' SocketPrim.lhs:1090: Data constructor not in scope: `AF_UNIX' SocketPrim.lhs:1090: Data constructor not in scope: `Stream' SocketPrim.lhs:1093: Data constructor not in scope: `AF_UNIX' SocketPrim.lhs:1131: Type constructor or class not in scope: `Family' SocketPrim.lhs:1134: Data constructor not in scope: `AF_UNIX' SocketPrim.lhs:1140: Data constructor not in scope: `AF_INET' SocketPrim.lhs:1150: Variable not in scope: `unpackFamily' SocketPrim.lhs:1152: Data constructor not in scope: `AF_UNIX' SocketPrim.lhs:1154: Data constructor not in scope: `AF_INET' SocketPrim.lhs:1186: Data constructor not in scope: `AF_UNIX' SocketPrim.lhs:1192: Data constructor not in scope: `AF_INET' Compilation had errors gmake[1]: *** [SocketPrim.o] Error 1 gmake: *** [all] Error 1 *** Error code 2
