March 2004 - Libraries

RE: DData revision (isSubsetOf / shorter names)
by Simon Marlow 18 Mar '04

18 Mar '04

> JP Bernardy wrote: > > http://users.skynet.be/jyp/DData/doc > > Now, where "isEmpty" is replaced by "null", I'ld rather see "subset" > instead of "isSubsetOf", particularly also because > "isProperSubsetOf" is so long. I vote for consistently using isXXXX for predicates. Cheers, Simon

6 9

RE: Win32 process spawning, POpen and Hugs, revisited
by Simon Marlow 18 Mar '04

18 Mar '04

My apologies to those who couldn't read the attachment. I've put it here; http://www.haskell.org/~simonmar/process/Process.hs Haddock docs here: http://www.haskell.org/~simonmar/process/System.Process.html > The abstraction could use an option to control whether > exiting or killing the parent process also terminates the child. Good point. > I'm not sure on what Windows foundation you are thinking of > implementing this, > but it's not easy to handle the command and arguments on the > Win32 API. The > arguments are handled by the API as a raw string, so the > caller must quote > the arguments according to awkard (possibly undocumented) > rules. I've worked > with this both in the Win32 API and using Perl. Perl didn't > have it right, so > in one case I was unable to invoke a certain command using > the full pathname, > because it contained spaces. We've already solved this problem: see System.Cmd.rawSystem in GHC 6.2. On Windows this translates the command line in such a way that the program will see exactly the arguments that you pass to rawSystem. Well, there's a small caveat: the target program has to be using Microsoft's standard C runtime semantics for parsing the command line (which pretty much everything does, I believe). Cheers, Simon

1 0

Data.Typeable
by Simon Peyton-Jones 18 Mar '04

18 Mar '04

Folks Ralf Laemmel and I have been making good progress with "scrap your boilerplate". (In fact there's a new paper at http://research.microsoft.com/~simonpj/papers/hmap/gmap2.ps; we'd love your comments.) Section 7 describes how to extend the Typeable story to higher kinds, in a manner that I know George Russell has already tried. It's rather beautiful, aside from the need to define a family of classes Typeable1, Typeable2, etc. But we've turned up a bad shortcoming in the Data.Typeable library. The present construction signature is like this: mkAppTy :: TyCon -> [TypeRep] -> TypeRep funTc :: TyCon mkFunTy :: TypeRep -> TypeRep -> TypeRep -- | Applies a type to a function type. Returns: @'Just' u@ if the -- first argument represents a function of type @t -> u@ and the -- second argument represents a function of type @t@. applyTy :: TypeRep -> TypeRep -> Maybe TypeRep What is missing is a function that takes two TypeReps and simply applies one to the other. So if one TypeRep is (ST T), and the other is Int, we want to build (ST T Int). The obvious name for this is 'applyTy' or 'mkAppTy', but they are both taken. Indeed, 'applyTy' is a bad name, because it only applies to *function* types. I'd like to suggest some re-naming mkTyConApp :: TyCon -> [TypeRep] -> TypeRep -- renaming of mkAppTy mkAppTy :: TypeRep -> TypeRep -> TypeRep -- new function mkFunTy -- no change funResultTy :: TypeRep -> TypeRep -> Maybe TypeRep -- ranming of applyTy I'm pretty sure about the first three. The last is the only "take this TypeRep apart" function that is currently offered, and it seems pretty specialised. Perhaps a more generic function would be splitTyConApp :: TypeRep -> (TyCon, [TypeRep]) (Remember, TypeReps only represent monotypes, so they are always a TyConApp.) Then we could build funResultTy from splitTyConApp. Is everyone happy with this? The main thing that seems unclear is what 'funResultTy' should be called. I guess we could just about stick with 'applyTy'. Opinions? Simon

1 0

RE: Win32 process spawning, POpen and Hugs, revisited
by Graham Klyne 17 Mar '04

17 Mar '04

Simon, Further to my previous message, this abstraction looks reasonable to me. If I ever manage to get the POpen module working, I think the code will adapt very easily to most of this interface. I do think your naming is more helpful. One area where I'm wary: your runInteractiveProcess returns a process handle, which can be used for further synchronization with the offspring process. I wonder if (a) this is really needed, and (b) if it might expose some awkward interactions with the interactive I/O streams. I don't have a particular problem in mind, just concerned that this might turn tricky in the future. #g -- At 12:01 17/03/04 +0000, Simon Marlow wrote: > >On a related note, I recently implemented a System.Process library on >Unix. Source code attached. The Windows implementation should be >relatively straightforward. Porting it to Hugs will require >System.Posix.forkProcess, but I don't see any great difficulties there. > >One warning: if you want to use it in a concurrent environment with GHC, >you need to use GHC's threaded RTS (i.e. use the -threaded option in the >forthcoming GHC 6.2.1), otherwise waitForProcess will block all threads. > >POpen-type abstractions can easily be layered on top of the >functionality here - indeed the library should probably contain some >higher-level versions which correspond to common usage. > >I think this is a good platform-independent abstraction for process >management. What do others think? > >Cheers, > Simon > >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Win32 process spawning, POpen and Hugs, revisited
by Graham Klyne 16 Mar '04

16 Mar '04

Further to my previous messages: http://www.haskell.org//pipermail/haskell/2004-February/013522.html http://www.haskell.org//pipermail/haskell/2004-February/013679.html I've come back to my stripped-down test case, and recreated the C test program SpawnEchoShiftLetters.c [1] in Haskell SpawnEchoShiftLetters.hs [2]. I've also added some diagnostic code. To recap: the C code demonstrates that that the Win32 API used by spawnProc.c [4] is working as expected, so the problem appears to be in the Haskell interface to it. My problem seems to be occurring about here: [[ spawn cmd = withCString cmd $ \ p_cmd -> withObject 0 $ \ p_wIn -> withObject 0 $ \ p_rOut -> withObject 0 $ \ p_rErr -> do rc <- spawnProc p_cmd p_wIn p_rOut p_rErr when (rc /= 0) (ioError (userError ("runProc: unable to spawn " ++ show cmd))) wIn <- peek p_wIn (-1-} trace ("wIn "++show wIn) $ return () {- : -} (-2-} hIn <- openFd (fromIntegral wIn) False WriteMode False (-3-} trace ("hIn "++show hIn) $ return () ]] -- http://www.ninebynine.org/Software/HaskellUtils/Win32/POpen.hs Specifically: + the trace at {-1-} displays the expected value (i.e. the same as a similar trace in the C version of the code [1], namely the value 3), + the trace at {-3-} is not displayed, indicating... + failure of the openFd call at {-2-}, also indicated by a Hugs error message, thus: [[ SpawnEchoShiftLetters> runTest wIn 3 Program error: openFd: does not exist (file does not exist) SpawnEchoShiftLetters> ]] Thus, it would appear that I'm misunderstanding how to use the openFd function that is part of the Hugs-supplied library code, declared as a primitive: [[ -- Creating a handle from a file descriptor/socket. -- primitive openFd :: Int -- file descriptor -> Bool -- True => it's a socket. -> IOMode -- what mode to open the handle in. -> Bool -- binary? -> IO Handle ]] -- http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/libraries/Hugs/IO.hs?rev=1… Can anyone help me out here? My current experimental code is all visible at [4]. Thanks. #g -- [1] http://www.ninebynine.org/Software/HaskellUtils/Win32/SpawnEchoShiftLetters… [2] http://www.ninebynine.org/Software/HaskellUtils/Win32/SpawnEchoShiftLetters… [3] http://www.ninebynine.org/Software/HaskellUtils/Win32/spawnProc.c [4] http://www.ninebynine.org/Software/HaskellUtils/Win32/ ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: [Haskell] New version of the HTTP module
by Simon Marlow 16 Mar '04

16 Mar '04

> > The modified HTTP module is available from: > > > > > http://www.dtek.chalmers.se/~d00bring/haskell-xml-rpc/http.html > > > > In line with Graham Klyne's suggestion [3] that a > > consistent version of > > this module be brought into some "community space", > > it will probably > > move to the haskell-libs project at SourceForge in > > the not too distant > > future. > > Is it possible to move the module to the network > package from the standard libraries > (fptools/libraries). There already exists modules for > CGI,Socket and URI. Possibly. In general we're moving to a more decentralised model for distributing libraries with the Library Infrastructure Project, but it may still be a while before that's stable. Guidelines for fptools/libraries are here: http://www.haskell.org/hierarchical-modules/libraries/libraries.html Parts of that document are out of date, but the "Reference Libraries" section is still relevant for the parts of fptools/libraries that we ship with compilers. Cheers, Simon

1 0

RE: version control and LIP
by Simon Marlow 15 Mar '04

15 Mar '04

> >The original question was whether to move the LIP repository > to CVS or > >keep it in an arch repository, or use something else. This seems to > >have lead on to the question of whether the whole of fptools > should move > >to a new VC system. > > > >My opinion: I hate CVS, but I don't think we should switch at this > >stage. The main problems in CVS that affect us every day are: > > > > - lack of support for versioning of directories (I'd like to > > rearrange bits of the tree, but find that the fact that we'd > > lose history means it isn't worth it). > > > > > > This can be done in CVS. (I'm not a CVS fan, but that is > neither here > nor there.) CVS can't do it automatically. However, you can easily > move the RCS files and in this manner change the directory > structure. > What you lose is any history of the directory operations themselves. > But it is possible to move files. Yes, I'm aware of this. If you move the RCS file, then you lose the ability to check out the tree at an earlier date. You have to copy the RCS file, and then edit the copy to mark all the old revisions as "dead", thus keeping the history and allowing checkouts of old trees. One gets the feeling that this isn't a well-supported feature ;-p Cheers, Simon

2 1

version control and LIP
by Isaac Jones 15 Mar '04

15 Mar '04

Greetings. I've been using the arch (tla) version control system for the Library Infrastructure Project. Since its designed to be distributed, arch has many advantages over a system like CVS. You can read about them here: http://web.verbum.org/blog/freesoftware/distributed-future So I'm thinking about how to proceed with the VC of LIP. Someone asked me to move it to the central CVS repository, and someone else asked if I would move it to darcs. I'm using arch at work, and since I'm interested in such system, I'm using darcs at home for my Debian packages (darcs is in Debian unstable now, by the way). Darcs is written in Haskell. I know I've harassed several of you to read about arch, so my question is, will anyone throw tomatoes at me if I switch to CVS or darcs? Is anyone else using my arch repository? By the way, the Library Infrastructure Project is still moving forward; I've been sending patches for stuff we'll need to the upstream author of HMake (CC'd). peace, isaac

12 21

RE: version control and LIP
by Simon Marlow 15 Mar '04

15 Mar '04

The original question was whether to move the LIP repository to CVS or keep it in an arch repository, or use something else. This seems to have lead on to the question of whether the whole of fptools should move to a new VC system. My opinion: I hate CVS, but I don't think we should switch at this stage. The main problems in CVS that affect us every day are: - lack of support for versioning of directories (I'd like to rearrange bits of the tree, but find that the fact that we'd lose history means it isn't worth it). - lack of atomic multi-file commits. I often want to know "what other files were modified by this commit". Or to "merge this entire changeset into the branch". Neither of these is well supported by CVS, although they are possible to do by hand. - lack of "good" support for branches and merging. If branches were easier to use, we'd use them more. Instead, we end up keeping lots of local development outside CVS altogether. Distributed repos might help here too. I looked at Subversion, but I must admit I'm not too keen on keeping the repository in a monolithic database. In some sense it might be the Right Thing, but it certainly limits transparency, and what external tools you can use on the repo. Distribution isn't something we really need, but it might be nice. Fixing the above 3 issues I'd say is more important. Sven's point about the amount of momentum that CVS has is a good one. Changing our VC would be a huge upheaval, which is why it isn't going to happen any time soon. The ideal alternative isn't yet clear (to me) either. Cheers, Simon > -----Original Message----- > From: libraries-bounces(a)haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Simon Peyton-Jones > Sent: 15 March 2004 09:17 > To: Isaac Jones; Krasimir Angelov > Cc: libraries(a)haskell.org > Subject: RE: version control and LIP > > I don't have any opinion about the relative merits of different VC > systems (except selfish reluctance to learn a new one) but > whatever you > choose *must* work flawlessly on Windows as well as Unix. Lots of > people use Haskell on Windows machines. > > With Gour's encouragement I managed to build GHC quite easily using > MSYS, a lightweight cousin of Cygwin. When I install the > MSYS developer > toolkit I get CVS and ssh. I'm certain I don't get arch/darcs etc. > It's not a big deal to install something else, but the something else > should be guaranteed available for Windows and (strong preference) not > require Cygwin. > > Simon > > | -----Original Message----- > | From: libraries-bounces(a)haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Isaac Jones > | Sent: 15 March 2004 02:51 > | To: Krasimir Angelov > | Cc: libraries(a)haskell.org > | Subject: Re: version control and LIP > | > | Krasimir Angelov <ka2_mail(a)yahoo.com> writes: > | > | > Does the arch works under Windows? > | > | It seems that there is some support, as you've already discovered. > | Apparently, cygwin is only one out of 3 options: > | > | http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support > | > | I hope you can solve this problem. Perhaps this is another reason I > | should move to darcs? How's darcs support in windows? > | > | > | peace, > | > | isaac > | _______________________________________________ > | Libraries mailing list > | Libraries(a)haskell.org > | http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

2 1

RE: DData in hierarchical libraries
by Simon Marlow 15 Mar '04

15 Mar '04

> Am Donnerstag, 26. Februar 2004 15:07 schrieb JP Bernardy: > > [...] > > > Well, DData is meant to replace Data.Set and > Data.FiniteMap, and add some > > functionality. > > Is it for sure that Data.Set and Data.FiniteMap will be > replaced by the DData > stuff? Will the DData modules get the Data prefix when they > are included in the hierarchical libraries? I would like to see that happen, but I'd like to see more people comment on the design (and performance) of the DData libraries first. The breakage to code will be fairly minimal: Data.FiniteMap can be left in place but deprecated, many of the operations from Data.Set can also be provided by the new Data.Set (but deprecated, of course). The other modules don't conflict. Cheers, Simon

3 2