August 2005 - Libraries

Re: Foreign language parsers
by Dimitry Golubovsky 05 Aug '05

05 Aug '05

Dominic, You wrote: ========================== Has anyone looked at positioning foreign language parsing modules in the standard libs, or specifying a common framework or contract for such modules? ========================== I wrote up a proposal earlier on this list how to extend Cabal to integrate hsffig (and I believe tools like c2hs might be integrated the same way, if not integrated already). As for "library use", one of the future directions of hsffig development may be adding a wrapper around its parser to represent parsing results as a collection of items, with possiblilty to run queries over it such as: - get the list of constants whose name matches a regexp - get the name of the enumeration containing the given constant etc. This might help develop custom wrappers, like one John Goerzen developed for openldap. -- Dimitry Golubovsky Anywhere on the Web

1 0

Cabal proposal: user-configurable prefixes (thinking of HSFFIG integration as a preprocessor)
by Dimitry Golubovsky 03 Aug '05

03 Aug '05

I have been thinking how HSFFIG (Isaac once suggested this) could be integrated with Cabal as a preprocessor. The problem is, external library header file might be located arbitrarily, up to the decision of local system maintainer. I am proposing to extend the "setup configure" command. Currently, one may invoke: setup configure --with-alex=/path/to/alex/installed/bin/alex If however a .cabal file contained stanzas like this: user-prefix-key: mylib user-prefix-default: /usr/local/lib user-prefix-help: The library absolutely necessary to build this package and the cabal program was appropriately modified (I realize this may be hard) then it would become possible to run: setup configure --with-mylib=/path/to/the/location/of/mylib/installed and setup-configure --help would mention --with-mylib as one of the possible configuration options. Then if someone is installing a package requiring this library, and its installation is not done in standard way, it is up to that person to locate the library. Going further, this "mylib" token might become a part of the `extra-lib-dirs' field: extra-lib-dirs: $mylib to be substituted with whatever the user specifies as --with-mylib. And then a new field needs to be added to the .cabal file format: extra-include-dirs: $mylib/../include because a library may be installed anywhere, but relative position of its include files and the library itself is unlikely to vary. This extra-include-dirs will be used by the wrapper for HSFFIG, so that these tokens will be passed to the C preprocessor telling where to look for headers. And then HSFFIG may be fit in the preprocessors framework of Cabal. Suppose we have a file MYLIB.h in the directory where other source files are placed. Then, having defined HSFFIG as a preprocessor for .h suffix (I will have to write a replacement of the HSFFIG main program so that the module name will match the header name without postfixing with "_H"), MYLIB.h will be converted to MYLIB.hs (or more files if the splitter is applied) MYLIB.h will contain then just this #include <mylib.h> assuming that the library's include file is mylib.h. As the extra-include-dirs will be passed properly to the C preprocessor, the library include file will be found correctly. PS I understand, this may be hard to implement and I am ready to help with coding if there is interest in such an integration. -- Dimitry Golubovsky Anywhere on the Web

1 0

Announce: HSFFIG 1.0 Stable Release
by Dimitry Golubovsky 01 Aug '05

01 Aug '05

Dear List Subscribers, I am pleased to announce the first stable release of HSFFIG, yet another tool for autogeneration of FFI bindings from C include files. The project is now hosted at Sourceforge: http://hsffig.sourceforge.net Downloads page: http://www.sourceforge.net/projects/hsffig Darcs repo: darcs get http://hsffig.sourceforge.net/repos/hsffig-1.0 Tutorial: http://www.haskell.org/hawiki/HsffigTutorial The wiki page "HsffigExamples" has been separated from the Tutorial. If anybody has an interesting example of using HSFFIG please update the page with code samples. Brief summary of changes: - The distribution is now cabalized. Please read the INSTALL file. - The multiparameter class and combinators to access members of structures/unions are moved to separate library. It is necessary to specify -package HSFFIG when compiling applications. Thanks to everybody who participated in discussions related to HSFFIG on this list, and privately. This helped me with implelentation of some features and gave some ideas for future improvement. Debian, RPM, and other packagers: if you create a HSFFIG package please let me know the package URL so I can update the Freshmeat project information page, and the project homepage. For any problems related to this project feel free to contact me. -- Dimitry Golubovsky

1 0

RE: [Haskell] runProcess with out=err
by Simon Marlow 01 Aug '05

01 Aug '05

On 28 July 2005 14:35, Ian Lynagh wrote: > With the below code (compiled by ghc) I get > "a.out: thread blocked indefinitely". > > Changing the second (Just hout) to Nothing makes it run as expected. > > If I dup fdout to get an fderr and then try to also convert that to > a handle then I get "a.out: openFile: resource busy (file is locked)". > > Is there a way to write this with stdout and stderr going to the same > handle? > > ------------------- > module Main (main) where > > import System.Posix (openFd, defaultFileFlags, stdFileMode, > OpenMode(ReadOnly, WriteOnly), fdToHandle) > import System.Process (runProcess, waitForProcess) > > main :: IO () > main = exec "echo" ["foo"] "in" "out" > > exec :: String -> [String] -> FilePath -> FilePath -> IO () > exec c args inp out > = do fdin <- openFd inp ReadOnly Nothing defaultFileFlags > fdout <- openFd out WriteOnly (Just stdFileMode) > defaultFileFlags hin <- fdToHandle fdin > hout <- fdToHandle fdout > ph <- runProcess c args Nothing Nothing > (Just hin) (Just hout) (Just hout) > waitForProcess ph >>= print This bug was fixed in rev. 1.12 of System.Process.Internals, and has been merged into the 6.4 branch. Cheers, Simon

1 0

RE: Error manipulation functions
by Simon Marlow 01 Aug '05

01 Aug '05

On 28 July 2005 15:05, Ian Lynagh wrote: > I couldn't see a way to write any of these functions without using > GHC.IOBase. Did I miss one? > > If not, can they (or something that would allow them to be written) > please be added to System.IO.Error? > > > import GHC.IOBase ( IOException(ioe_location), > IOErrorType(UnsupportedOperation, HardwareFault) ) > > add_to_error_loc :: Exception -> String -> Exception > add_to_error_loc (IOException ioe) s > = IOException $ ioe { ioe_location = s ++ ": " ++ ioe_location > ioe } add_to_error_loc e _ = e I don't think all implementations have a "location" field in their IOErrors, since it isn't required by Haskell 98. Interestingly, the GHC implementation of mkIOError fills in the location field rather than the description field, so I suspect you could use mkIOError to construct add_to_error_loc. One possibility is to add support for the location of an IOError to System.IO.Error. > isUnsupportedOperationError :: IOError -> Bool > isUnsupportedOperationError = isUnsupportedOperationErrorType . > ioeGetErrorType > > isUnsupportedOperationErrorType :: IOErrorType -> Bool > isUnsupportedOperationErrorType UnsupportedOperation = True > isUnsupportedOperationErrorType _ = False This one is easier. I'm happy for this to go in, if there are no objections. There are some other ErrorTypes that GHC supports that aren't in H98, IIRC. Cheers, Simon

1 0

RE: finding the dependecies of cabal packages
by Simon Marlow 01 Aug '05

01 Aug '05

On 01 August 2005 11:31, Krasimir Angelov wrote: > Visual Haskell works quite well with hooks. Hmm, I'm not sure it does. The hooks are only run when building the project, not when interactively editing the source code. We can't discover what hooks are being used, because they are embedded in the Setup.lhs script. If we knew what the hooks were, then we could run them from VS (security issues aside). It's not entirely clear when to run the preBuild/postBuild hooks given that we're essentially building continuously, but I'm sure doing something simple will work most of the time. > We are already using hooks > in order to build Visual Haskell itself. In Visual C++ projects you > can specify a sequence of shell commands which can be executed at > specified point in the build process. In Visual Haskell you can use > Cabal hooks to perform the same actions but the hooks approach is more > flexible. > The only limitation of Visual Haskell is that it can work only with > the simple build architecture. It can be extended with the makefile > based system but the drawback will be that we will lose the project > editing features, interactive type checking and all other advanced > features. The situation is the same with the Makefile based Visual C++ > projects. Visual C++ provides only basic support for Makefiles. > > Cheers, > Krasimir > > On 8/1/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> On 29 July 2005 21:18, Duncan Coutts wrote: >> >>> However an IDE wants even more. It wants to be able to rebuild >>> individual files quickly (so dependency tracking is required and >>> linear build scripts are out). It will want to provide a GUI >>> interface for changing build system parameters (which means that the >>> build system has to be declarative, not scripted). And no doubt >>> there are other things too. >>> >>> The point is that fulfilling these requirements might be possible >>> for some imagined future version of the "simple" build system, >>> however if the Cabal interface is extended to stipulate these same >>> features then it would exclude most other build system >>> implementations. >> >> My feeling is that the requirements for incremental building should >> be part of the simple build system. >> >> It's not quite true now, because we allow arbitrary hooks into the >> simple build system. So tools like Visual Haskell only work >> properly if you don't use hooks. This is one reason why being more >> explicit about whether a package uses hooks or not would be useful. >> >> Cheers, >> Simon >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries

2 1

RE: finding the dependecies of cabal packages
by Simon Marlow 01 Aug '05

01 Aug '05

[ oops, hit send by mistake ] On 01 August 2005 11:31, Krasimir Angelov wrote: > Visual Haskell works quite well with hooks. Hmm, I'm not sure it does. The hooks are only run when building the project, not when interactively editing the source code. We can't discover what hooks are being used, because they are embedded in the Setup.lhs script. The preXXX hooks are a one-way mechanism for obtaining the PackageDescription: there's no way to re-inject a modified PackageDescription. The postXXX hooks, on the other hand, are fine. As long as you stick to postXXX hooks, then VH works fine, because the PackageDescrption is static and in a known place. This isn't an argument against hooks, just an observation that (a) there are uses of hooks that work fine with an IDE, (b) there are uses of hooks that don't, and (c) the IDE can't tell whether a package is even using hooks, let alone whether it is using safe hooks or not. We should at least do something about (c). Sorry for not bringing this up when hooks were being discussed... Cheers, Simon > We are already using hooks > in order to build Visual Haskell itself. In Visual C++ projects you > can specify a sequence of shell commands which can be executed at > specified point in the build process. In Visual Haskell you can use > Cabal hooks to perform the same actions but the hooks approach is more > flexible. > The only limitation of Visual Haskell is that it can work only with > the simple build architecture. It can be extended with the makefile > based system but the drawback will be that we will lose the project > editing features, interactive type checking and all other advanced > features. The situation is the same with the Makefile based Visual C++ > projects. Visual C++ provides only basic support for Makefiles. > > Cheers, > Krasimir > > On 8/1/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> On 29 July 2005 21:18, Duncan Coutts wrote: >> >>> However an IDE wants even more. It wants to be able to rebuild >>> individual files quickly (so dependency tracking is required and >>> linear build scripts are out). It will want to provide a GUI >>> interface for changing build system parameters (which means that the >>> build system has to be declarative, not scripted). And no doubt >>> there are other things too. >>> >>> The point is that fulfilling these requirements might be possible >>> for some imagined future version of the "simple" build system, >>> however if the Cabal interface is extended to stipulate these same >>> features then it would exclude most other build system >>> implementations. >> >> My feeling is that the requirements for incremental building should >> be part of the simple build system. >> >> It's not quite true now, because we allow arbitrary hooks into the >> simple build system. So tools like Visual Haskell only work >> properly if you don't use hooks. This is one reason why being more >> explicit about whether a package uses hooks or not would be useful. >> >> Cheers, >> Simon >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: finding the dependecies of cabal packages
by Simon Marlow 01 Aug '05

01 Aug '05

On 29 July 2005 21:18, Duncan Coutts wrote: > However an IDE wants even more. It wants to be able to rebuild > individual files quickly (so dependency tracking is required and > linear build scripts are out). It will want to provide a GUI > interface for changing build system parameters (which means that the > build system has to be declarative, not scripted). And no doubt there > are other things too. > > The point is that fulfilling these requirements might be possible for > some imagined future version of the "simple" build system, however if > the Cabal interface is extended to stipulate these same features then > it would exclude most other build system implementations. My feeling is that the requirements for incremental building should be part of the simple build system. It's not quite true now, because we allow arbitrary hooks into the simple build system. So tools like Visual Haskell only work properly if you don't use hooks. This is one reason why being more explicit about whether a package uses hooks or not would be useful. Cheers, Simon

2 1

RE: finding the dependecies of cabal packages
by Simon Marlow 01 Aug '05

01 Aug '05

On 29 July 2005 23:19, Isaac Jones wrote: > Brian Smith <brianlsmith(a)gmail.com> writes: >> I think what VHS.NET does--and what I am/was planning to do--is use >> Cabal files as projects, but reimplement Distribution.Simple.Build >> et. al. to work in an better in an "interactive" GUI environment >> than the current system, which is batch-compile oriented. In >> particular, VHS.NET and maybe my tool will use the GHC API >> extensively. >> >> For example, using the GHC API I can do dependency analysis that will >> allow me to say "build just this one source file because that other >> source file changed." But, Cabal always restarts dependency analysis >> over at the root modules, which make it too slow for interactive use. > > (snip) > > Why not work to speed up Cabal's execution time rather than > reimplement so much from scratch, and in a compiler-dependent way? > > There's nothing inherent about Cabal's interface that makes it do > things in a batch, or slows compilation time. It uses GHC's --make > flag (though it always relinks the library, which is not always > necessary). > > If your tool is written in Haskell, and could be made compiler > agnostic, perhaps we could add such features to cabal itself... maybe > we could have a "./setup build --continuous" which emits status to a > file or uses a socket interface or something in order to communicate > w/ eclipse, VS, and your tool, since they often want the same kind of > information. Brian is talking about having access to the same facilities that Visual Haskell uses when editing a Cabal project in the environment. For example, when a source file is edited (without even being saved), we can invoke the GHC API to re-typecheck it in the context of the rest of the project, and ask GHC about the types of its identifiers. This is an interactive application, and it needs a programmatic interface so that state can be maintained between calls. A command-line interface isn't the right thing here. I suppose the question is whether there is a useful re-usable abstraction that we can provide as part of the Cabal libraries. Essentially, it would be an abstraction over the GHC API that communicates the details of the program in terms of a PackageDescription. Actually, this would make more sense as part of the GHC API rather than part of Cabal (you don't want a dependency from Cabal on the ghc package, but ghc already depends on Cabal). Using this abstraction, we could construct "ghci --cabal" very easily. Using it in Visual Haskell would be tricky, because I believe we have a different internal representation of PackageDescription. Brian - if you'd like to think about the API, I'll be happy to comment on it. Cheers, Simon

2 1

RE: on when to build ghci libs in cabal
by Simon Marlow 01 Aug '05

01 Aug '05

On 30 July 2005 21:05, Isaac Jones wrote: > Henning Günther and Duncan Coutts / the Gentoo team have sent me a > patch to move creation of ghci libs to the build phase rather than the > register phase. It makes more sense there and should be somewhat > better for debian and gentoo. > > Though Duncan points out that maybe some ppl want to build the ghci > libs during register because it could save room in a binary > distribution (like debian and rpm). Any opinions here? > > Also, I noticed the "FIXME" that mentions the -x flag is only > supported on some platforms; what effect will this have on platforms > that don't support it? Will they be broken during build? What about > platforms where we know the ghci libs don't work, like MacOS; will > this patch cause building to break? > > The patch adds a couple extra configure options, > --enable-library-for-ghci / --disable-library-for-ghci. I'm sorta > thinking of just having one option "--disable-interpreter-libs" or > something to make this seem more generic, though at the moment, it > still only makes sense for a combo compiler / interpreter build (that > is, --ghc). I'll be happy to add this to the manual once we settle on > a flag. Do we ever really need to disable it anyway? Definitely a good thing. The ghc-pkg --auto-ghci-libs was only ever a hack, because it doesn't make any attempt to find the right way to build GHCi libs on the current platform; Cabal can do a much better job. I'm happy we're shifting this burden onto Cabal. I'm not sure you would ever want to disable it; it should be completely transparent. Arguably GHCi should be able to use the .a files directly, but we've never gotten around to implementing that. It'll be a non-issue when we start using shared libraries, too. Cheers, Simon

1 0