- Glasgow-haskell-users

RE: Network/Notwork?
by Simon Marlow 17 Mar '03

17 Mar '03

> - in Network.Socket: SocketOptions may include Linger, but > setSocketOptions uses packSocketOptions, which doesn't know > about Linger? That looks like a bug, thanks. > And shouldn't Linger be on by default for the > high-level Network lib? It looks that way to me, but perhaps a Network Guru could comment? > - using hFlush does *not* seem to cure the problem?? That's worrying, and it perhaps indicates that there's another problem somewhere. I just tried a small test and hFlush does appear to do the right thing, so do you think you could boil down your example to something small that demonstrates the problem? Does it happen only on Windows, or Un*x too? Cheers, Simon

1 0

RE: Hugs extension in GHC ?
by Simon Marlow 17 Mar '03

17 Mar '03

> Is there a way to express the following Hugs (Gofer) Haskell > extension in GHC? > > From the Hugs User's Manual, "Section 7.3.5 Restricted type synonyms" GHC doesn't support restricted type synonyms, sorry. Cheers, Simon

1 0

Network/Notwork?
by Claus Reinke 16 Mar '03

16 Mar '03

Happy with my Winsock work-arounds for my small client-/server-test, I decided to try integrating the Network use into my target project, and got nothing but trouble. Again, things that work happily under Unix simply fail under windows. My best guess at the moment is that the socketToHandle conversion used within accept and connectTo simply doesn't work as advertised, under windows (at least, handle-based operations such as hGetLine or hClose on the handles returned by accept/connectTo results in errors, whereas avoiding the socketToHandle conversion and using Network.Socket.send and Network.Socket.recv yields some improvements..). A little more digging in mail-archives brings up the following rather discouraging thread/message: Socket library ghc 5.02.1 http://www.haskell.org/pipermail/glasgow-haskell-users/2001-November/002673… in which Sigbjorn summarizes: FYI, in case you're planning on doing socket programming with GHC-5.02 on a Win32 platform, stay away from using the higher-level Socket module, since its IO.Handle based view of sockets is just broken. Stick with the lower-level SocketPrim interface instead. Is it just me doing something stupid, or is this problem still pertinent, for the higher-level Network module in GHC-5.04? If the latter, could this please be flagged in the GHC documentation, so that people don't have to rediscover the problem by painful debugging? (if the former, any suggestions on what I should try instead?) Is anyone else here using GHC's Network module under Windows? Claus FPI: foreign problem interface

1 1

Hugs extension in GHC ?
by Ed Komp 16 Mar '03

16 Mar '03

Is there a way to express the following Hugs (Gofer) Haskell extension in GHC? >From the Hugs User's Manual, "Section 7.3.5 Restricted type synonyms" >> Hugs supports the use of restricted type synonyms, first introduced >> in Gofer, and similar to the mechanisms for defining abstract >> datatypes that were provided in several earlier languages. The purpose >> of a restricted type synonym is to restrict the expansion of a type >> synonym to a particular set of functions. Outside of the selected >> group of functions, the synonym constructor behaves like a standard >> datatype. More precisely, a restricted type synonym definition is a >> top level declaration of the form: >> > type T a1 ... am = rhs in f1, ..., fn >> where T is a new type constructor name and rhs is a type expression >> typically involving some of the (distinct) type variables a1, ..., >> am. The major difference with a normal type synonym definition is that >> the expansion of the type synonym can only be used within the binding >> group of one of the functions f1, ..., fn (all of which must be >> defined by top-level definitions in the module containing the >> restricted type synonym definition). In the definition of any other >> value, T is treated as if it had been introduced by a definition of >> the form: >> > data T a1 ... am = ... For my intended application, this last line, the type synonym is treated as if it had been introduced with "data" is of key importance. Here are some code snippets, taken from the paper "Using catamorphisms, subtypes and monad transformers for writing modular functional interpretors" by Luc Duponcheel (Nov. 1995) further explain what I to express: >> data Sum x y = L x | R y >> >> type E x = Sum (E1 x) (E2 x) in fmapE, phiE >> >> fmapE :: (x -> y) -> (E x -> E y) >> fmapE g = (L . fmap1 g) <+> (R . fmap2 g) >> >> phiE :: E Int -> Int >> phiE = phi1 <+> phi2 >> >> data Rec1 f = In (f (Rec1 f)) >> >> type Expr = Rec1 E >> >> instance Functor E where >> fmap = fmapE Trying to compile this with GHC (after removing the "in fmapE, phiE"), generates the (expected) error: >> Type synonym `E' should have 1 argument, but has been given 0 >> In the type: Rec1 E >> While checking the RHS of a type synonym declaration `Expr' for the line: type Expr = Rec1 E and, if I replace that line with: type Expr x = Rec1 E x I get the following error message: >> Couldn't match `*' against `k -> k1' >> Expected kind: * >> Inferred kind: k -> k1 >> When checking kinds in `Rec1 E x' >> In the type synonym declaration for `Expr' and, more problems are anticipated for: >> instance Functor E where >> fmap = fmapE Thanks in advance for all help, Ed Komp komp(a)ittc.ku.edu

1 0

RE: Effect of large binaries on garbage collection
by Simon Peyton-Jones 15 Mar '03

15 Mar '03

| In the current CVS GHC, undoubtedly the right thing to use is | Foreign.mallocForeignPtr. Internally these are implemented as | MutableByteArray#, so you get fast allocation and GC, but from the | programmer's point of view it's a normal ForeignPtr. I wonder how it is for a random FFI user to discover this. Does some advice belong in the FFI spec, or in GHC's FFI chapter? Simon

3 2

RE: DuplexHandle finalizer fix missing...
by Simon Marlow 14 Mar '03

14 Mar '03

> I have also noticed the fix for DuplexHandle finalizers is not in > this release, I believe the finalizer > should be attached to the write side (which is pointed to by the read > side) but its still attached to the > read side as in previous versions... Once again this is a > critical fix, > as otherwise applications keep one > half of the connection open until they quit, or crash due to lack of > resources. Darn! That fix is sitting in my tree uncommitted because I never got around to testing it properly. Sigh, I think I need a holiday :-( /me wanders off looking a bit sheepish. Cheers, Simon

2 1

RE: Can't build GHC on Mac OS X
by Simon Marlow 14 Mar '03

14 Mar '03

> I installed GHC 5.04.2 from binaries on my machine (running > Mac OS 10.2.1 > and gcc 3.1) and proceeded to try to build the latest version of GHC > from cvs, resulting in the following error message: > [lots of stuff snipped] > -------------------------------------------------------------- > ---------- > ==fptools== make all - --no-print-directory -r; > in /Users/krc/Work/fptools/green-card/lib/hugs > -------------------------------------------------------------- > ---------- > gcc -fPIC -shared -I . -DSTRICT -o StdDIS.so StdDIS.c > gcc: unrecognized option `-shared' > ld: Undefined symbols: > _main > make[3]: *** [StdDIS.so] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [all] Error 1 > make: *** [build] Error 1 > > Any idea what's up? Looks like you're trying to build green-card, which isn't part of a standard GHC build. Try removing fptools/green-card (unless you have a good reason to want it, in which case try contacting the green-card folks). Cheers, Simon

1 0

RE: fix missing from 5.04.3 ???
by Simon Marlow 14 Mar '03

14 Mar '03

> Previous 5.04 releases had an exception handler missing from > connectTo > that results in a socket leaking if socketToHandle fails for > some reason > (I cant remember the exact circumstances at the moment, but > it causes a > server to die - I think the leak is caused when the client closes the > connection during the handshake - ie somebody presses stop on a web > browser because of a slow connection after the handshake has just > started) - I suggested a fix along the lines of: > > connectTo hostname (Service serv) = do > proto <- getProtocolNumber "tcp" > port <- getServicePortNumber serv > he <- getHostByName hostname > sock <- socket AF_INET Stream proto > (do > connect sock (SockAddrInet port (hostAddress he)) > socketToHandle sock ReadWriteMode) > `Control.Exception.catch` (\e > -> do sClose sock; throw e) Sorry, that one didn't get merged into 5.04.x. An oversight on my part. You can work around the problem by using your own implementation of connectTo, or copying the one from Network.hs in CVS. Cheers, Simon

1 0

Can't build GHC on Mac OS X
by Kirsten Chevalier 14 Mar '03

14 Mar '03

Hi, I installed GHC 5.04.2 from binaries on my machine (running Mac OS 10.2.1 and gcc 3.1) and proceeded to try to build the latest version of GHC from cvs, resulting in the following error message: [lots of stuff snipped] ------------------------------------------------------------------------ ==fptools== make all - --no-print-directory -r; in /Users/krc/Work/fptools/green-card/lib/hugs ------------------------------------------------------------------------ gcc -fPIC -shared -I . -DSTRICT -o StdDIS.so StdDIS.c gcc: unrecognized option `-shared' ld: Undefined symbols: _main make[3]: *** [StdDIS.so] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 Any idea what's up? -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

1 0

Re: ANNOUNCE: GHC vesrion 5.04.3 released
by C.Reinke 13 Mar '03

13 Mar '03

> ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 5.04.3 > ============================================================== > > We are pleased to announce a new patchlevel release of the Glasgow > Haskell Compiler (GHC), version 5.04.3. This is a bugfix-only > release. For all the changes since 5.02.3, see the release notes: > > > http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.html Actually, I find it difficult to extract the sometimes drastic differences between releases from that document (just one example: does this release include last week's bugfixes in the Network module?). How do I find out about the various bugfixes between releases, to decide whether or not to upgrade (and whether or not upgrading will help with specific problems)? After all, the reason for patchlevel releases is that you've fixed some bugs, so why be so secretive about what these fixes are?-) Cheers, Claus

2 1