April 2003 - Libraries

Re: announcing darcs
by Alastair Reid 10 Apr '03

10 Apr '03

[moved from cafe to libraries] David Roundy <droundy(a)abridgegame.org> writes: > [darcs] contains a few bits of code that you might find useful, > such as an interface to libcurl (for lazily reading files over http > or ftp) This sounds like it would be a valuable contribution all by itself. Could you make it available as a package with its own (copy of the) license? A very brief look at the existing network support suggests that Network/C_URL might be a good place to put it. A quick glance at libcurl documentation suggests that it is quite portable (unix and win32). > darcs is currently unix-only (counting MacOS X as unix). A port to > windows would be a fair amount of work, but probably would mostly be > straightforward (mostly dealing with slashes versus backslashes and > getting libcurl to work under windows). This reminds me of a library I have been wanting for a while: functions for manipulating filenames in a portable way. The main requirement is that you should be able to manipulate a filepath as though it was structured something like so: (Maybe [Directory], Maybe Filename, Maybe Suffix) For example, on a Unix system, /usr/lib/libcurl.so would be treated something like this: (Just ["/","usr","lib"], "libcurl", Just "so") There's an awful lot of code out there that assumes that you can find the suffix of a filename using dropWhile (/='.') or reverse . takeWhile (/='.') . reverse (try them on "/foo.bar/baz.exe" and "/foo.bar/baz") and there is (presumably) much reinvention of the wheel when people decide to implement functions which really work. Oh yes, I should say that 'darcs' sounds quite cool as well... -- Alastair Reid alastair(a)reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

6 7

RE: announcing darcs
by Simon Peyton-Jones 10 Apr '03

10 Apr '03

| He has a Linux machine, and is trying to cross-compile for a Windows | target machine. Thus, he needs to persuade his (Linux) GHC to use | the mingw GCC cross-compiler as a back-end, the goal being to end up | effectively with his GHC as a cross-compiler. | | A great (if brave) idea, I think you'll agree. Ah, I missed that. Indeed brave. We've never tried that. SImon

1 0

RE: announcing darcs
by Simon Peyton-Jones 10 Apr '03

10 Apr '03

| > I can't help you gain access to windows but Hugs is many, many times | > easier to install than GHC - you don't need mingw, cygwin or anything | > like that. (Truth in advertising: to use the ffi (e.g., to interface | > to libcurl), you do need a C compiler :-() | | Hmmmm. I hadn't thought of using hugs! I do need ffi (for libcurl), but I | already have the mingw c/c++ cross-compiler installed (I use it to compile | the windows version of my bridge game), so I may be able to port to windows | with less trouble that I had thought, by running hugs under wine... Lies, all lies :-) To install GHC you double click on the installer. That's all. No cygwin, no mingw, nothing. To *build* GHC from source you need these things, but to install and run it you need none of them. If this isn't the case I'd like to know about it. Simon

2 1

X11 libraries
by Alastair Reid 02 Apr '03

02 Apr '03

I'm in the process of moving the X11 libraries over from hslibs into fptools/libraries and thought I'd better check I'm doing it the approved way before I commit. At present, I'm modelling my infrastructure (Makefiles, directory structure, etc) on the HOpenGL infrastructure so, naturally, I'm putting it in fptools/libraries/X11 and have the following modules: module X11 -- reexports X11.Types and X11.Xlib module X11.StdDIS module X11.Types module X11.Xlib The X11 module lives in fptools/libraries/X11.hs. The X11 library is only built if GhcLibsWithX11 is set. The X11 library is covered by the same license as GHC, Hugs, etc. 1) Is this the right place to put X11 in the directory tree or should I put it under libraries/base or some other existing directory? 2) Is this the right place to put the X11 module in the hierarchial namespace? I'm hoping to get round to moving the Win32 and HGL libraries over pretty soon as well so whatever answer you give should apply to them too. -- Alastair ps The makefiles seem to be entirely for GHC usage but we will want to build X11 and Win32 for Hugs and NHC as well. Since we already have makefiles and other scripts for doing this (Hugs only at present), the easy way to do this would be to copy over the existing scripts and completely ignore the fptools Makefile infrastructure - but it would perhaps be nicer if we could easily exploit the existing infrastructure. (This applies to all the existing stuff in fptools/libraries/base too - the Hugs distro contains stuff to compile all the files that contain ffi code but this largely replicates the instructions from the fptools makefile.) pps Should I continue the unsavoury practice of committing GreenCard generated code to the repository? (Currently done for Win32, I'd do it for Xlib too for the sake of consistency.)

2 2

RE: X11 libraries
by Simon Marlow 02 Apr '03

02 Apr '03

> I'm in the process of moving the X11 libraries over from hslibs into > fptools/libraries and thought I'd better check I'm doing it the > approved way before I commit. > > At present, I'm modelling my infrastructure (Makefiles, directory > structure, etc) on the HOpenGL infrastructure so, naturally, I'm > putting it in fptools/libraries/X11 and have the following modules: > > module X11 -- reexports X11.Types and X11.Xlib > module X11.StdDIS > module X11.Types > module X11.Xlib > > The X11 module lives in fptools/libraries/X11.hs. > The X11 library is only built if GhcLibsWithX11 is set. > > The X11 library is covered by the same license as GHC, Hugs, etc. > > > 1) Is this the right place to put X11 in the directory tree or should > I put it under libraries/base or some other existing directory? fptools/libraries/X11 is fine. This will mean that X11 becomes a separate package in GHC-speak, but that's what we want. > 2) Is this the right place to put the X11 module in the hierarchial > namespace? According to the current hierarchy document[1] we have these libraries under Graphics.X11.Xlib. Perhaps these names would be correct: Graphics.X11.Xlib Graphics.X11.Xlib.Types Graphics.X11.X1ib.StdDIS The reason for separating Xlib into its own hierarchy is that there are other APIs under X11 (Xt, Xaw, Xmu). We could follow the convention of having the parent export the children though, and have Graphics.X11 export the contents of Graphics.X11.Xlib. > I'm hoping to get round to moving the Win32 and HGL libraries over > pretty soon as well so whatever answer you give should apply to them > too. Win32 is currently listed as being under System.Win32. However, since we've just put Dotnet at the top of the hierarchy, and Win32 contains a range of both systems and graphics stuff, I'd be happy for it to be at the top of the hierarchy too. HGL is assigned Graphics.HGL, which seems like the right thing. > ps The makefiles seem to be entirely for GHC usage but we will want to > build X11 and Win32 for Hugs and NHC as well. Since we already > have makefiles and other scripts for doing this (Hugs only at > present), the easy way to do this would be to copy over the > existing scripts and completely ignore the fptools Makefile > infrastructure - but it would perhaps be nicer if we could easily > exploit the existing infrastructure. Not sure what you mean here. Can't you use the existing mechanisms that Hugs uses to get access to the rest of the libraries? That way we can have fptools Makefiles too, and the X11 lib will build for GHC. The NHC folks seem to be using their own Makefiles, called Makefile.nhc98. > (This applies to all the > existing stuff in fptools/libraries/base too - the Hugs distro > contains stuff to compile all the files that contain ffi code but > this largely replicates the instructions from the fptools > makefile.) > pps Should I continue the unsavoury practice of committing GreenCard > generated code to the repository? (Currently done for Win32, I'd > do it for Xlib too for the sake of consistency.) I think the reason for this was that we could avoid a greencard dependency in a GHC build. I'm agnostic really, since we probably won't be including X11 in the default GHC build (see previous discussions about why we want to tighten up the set of libraries that GHC is shipped with). Cheers, Simon [1] fptools/libraries/doc/lib-hierarchy.html, and http://www.haskell.org/~simonmar/lib-hierarchy.html

2 1