- Glasgow-haskell-users

Get Your Free $110
by promo＠casino.com 11 Jun '02

11 Jun '02

1 0

RE: Dynamic Libraries on MacOS X
by Simon Marlow 11 Jun '02

11 Jun '02

> And there's a problem: ghc-pkg uses Read, and that requires all the > fields to be there. It would be a Bad Idea to force everyone > to update > every single package.conf file out there. Is there any special reason > why it doesn't use the ParsePkgConf.y parser from > compiler/main? (Simon: Am I allowed to make it do so?) Sure, go ahead. That's been on my ToDo list for a while. I'm beginning to think that the way MacOS X does frameworks is the way we should have done packages: it's much simpler to install/remove packages ("xcopy install" in MS-speak) if they all hang off a common root. On the other hand, it wouldn't be possible to install packages in some non-standard place without giving GHC an extra flag each time you use the package. > > One interesting possibility would be to allow support for > .hi files in > > frameworks. This would mean GHC would look inside > frameworks specified > > by > > the -framework flag and "frameworks" package.conf entries > for .hi files, > > in addition to -I and "import_dirs". > > I don't see why I would want to add a Haskell-Framework to a > package.conf file... I would definitely like to be able to > drag&drop-install GHC-Packages (it could be done on all > platforms, not > only MacOS). It would require loading package.conf files from > framework-style directories - I'll take a look at whether > this could be > done easily (and without disturbing the existing system) when > I've got the more important things done. This does indeed sound useful, and perhaps it could co-exist with the existing global package.conf file: if a package isn't found in package.conf, then we just search the framework/package search path for <package>/pkg.conf. I'm sure this would make people distributing 3rd party packages happier. Cheers, Simon

1 0

RE: Dynamic Libraries on MacOS X
by Ashley Yakeley 11 Jun '02

11 Jun '02

At 2002-06-10 04:03, Simon Marlow wrote: >It sounds like frameworks are similar in concept to GHC's packages. They solve a similar problem in a quite different way. A framework is a "bundle": an actual directory with everything inside it, libraries, header files, localised strings, whatever, with a particular internal structure that does clever stuff with symbolic links to handle multiple versions. Frameworks and other bundles (such as applications) may be relocated by the user, though frameworks generally need to be in certain standard places so that other tools can find them. Bundles may be uninstalled simply by deleting the directory. Generally the Mac GUI shows the directory as an object rather than a folder, though there's a special menu option to open the directory up like any folder. By contrast, GHC packages are virtual i.e. the stuff is not necessarily all in one directory. And if any of it gets moved, the package.conf file would need to be updated. For code-generating tools, you point to frameworks on the command-line much as you do libraries. For instance, just as you do "-lfoo -L./foolibs" to refer to libfoo and to search for libraries in ./foolibs/, you'd do "-framework foo -F ./foofws" to refer to foo.framework and to search in ./foofws/ for frameworks (there are also standard places to search). The Darwin C compiler can use this to find include files, and then you can pass the same options to the linker, and it will find the libraries. Too bad frameworks aren't standard on all UNIX, they are an excellent way of packaging software. >> *) add two command line options that get passed on to the >> linker (-framework for linking with a framework and -F for >> specifying framework search paths) >> *) add corresponding entries to package.conf > >You mean add a new package for each framework? I think Wolfgang means add new package specification components, such as "frameworks" and "frameworks_dir". They just need to be passed on to the linker. One interesting possibility would be to allow support for .hi files in frameworks. This would mean GHC would look inside frameworks specified by the -framework flag and "frameworks" package.conf entries for .hi files, in addition to -I and "import_dirs". This would mean a bit more code but I believe Apple provides APIs for dealing with bundles easily. -- Ashley Yakeley, Seattle WA

2 1

Re: problems with FFI including h files
by cwitty＠newtonlabs.com 10 Jun '02

10 Jun '02

Alastair Reid <reid(a)cs.utah.edu> writes: > > I thought we established that generating valid C prototypes from the > > Haskell FFI type signature wasn't possible due to the incompleteness > > of the Haskell type (lack of 'const' modifiers for one thing - is > > there anything else?). > > Compilers use the same calling sequence whether you tell them about > const or not. > > I believe that we can call all C functions correctly knowing only the > calling convention (ccall, stdcall, etc) and the Haskell type. I > certainly hope this is true since Hugs' implementation of wrappers > depends on it. > > (Hmmm, some calling conventions do funny things when passing and > returning small structs. I don't know much about this though...) I think some ABI's specify a different calling convention for varargs functions than non-varargs functions. (I remember reading this on some Haskell mailing list some time back, one of the previous times this same discussion occurred.) Carl Witty

1 0

RE: Dynamic Libraries on MacOS X
by Simon Marlow 10 Jun '02

10 Jun '02

> Possible Solution: > Frameworks. A "Framework" on MacOS X is a directory that > contains a dynamic library plus associated resources and > header files. There is an extra compiler/linker option for > linking to a framework. The big advantage is that the place > they are supposed to be installed in is accessible from the > user interface. > I've created a framework called "HaskellSupport.framework", > and I've made ghc link to that. It sounds like frameworks are similar in concept to GHC's packages. It's usually a good idea to comply with whatever is the approved way of doing things on a given platform, so I think this sounds like a reasonable solution. > Disadvantage: > Problems with GHCi (yes, I've almost got it to work!) - > "-framework HaskellSupport" is in the extra_ld_opts field of > the RTS package, so GHCi doesn't know that it has to load the > libraries. That sounds fine... as long as HaskellSupport doesn't contain any static libraries, right? > Related Problem: > Sooner or later, GHC for MacOS X should support Apple's > Frameworks anyway, as almost all functionality beyond the > standard C library is packaged in frameworks. I don't know > yet how much work that would be for me, and I fear that the > ghc gurus would dislike too much platform-specific code for > Apple's non-standard features... Here's what I'd like to do: I don't object at all to adding MacOS X specific code for frameworks, as long as there's someone around to maintain it! > *) add two command line options that get passed on to the > linker (-framework for linking with a framework and -F for > specifying framework search paths) > *) add corresponding entries to package.conf You mean add a new package for each framework? That's what I would suggest, if it is at all possible. If that's the case, then is the -framework option needed at all, since you can use -package instead? > *) add code for GHCi to load frameworks. Same here: if a framework is really just a collection of libraries and a search path, then converting frameworks into packages will mean that GHCi can load them as normal. Cheers, Simon

1 0

Dynamic Libraries on MacOS X
by Wolfgang Thaller 06 Jun '02

06 Jun '02

Hi Everyone, I've run into some problems/"design issues" for GHC/MacOSX, and I'd like to hear other people's opinions on the subject. Sorry for the long post. Programs compiled by GHC for MacOS X currently depend on two libraries that are not included with MacOS X: *) dlcompat - a compatibility layer implementing the dlopen API, which is not normally available on MacOS X (BSD-style license) *) libgmp - support for the Integer type, under LGPL The Problem: *) Most Mac users don't know how to install unix-style dynamic libraries. They shouldn't be expected to know. The MacOS Finder (Apple's File Browser) hides the entire /usr directory hierarchy be default. Requiring everyone who uses a program written in Haskell to install a dylib is not an option on MacOS. *) The LGPL imposes serious restrictions on all programs statically linked with libgmp, so static linking is not an option, either. *) Dynamic libraries anywhere on the system take precedence over static libraries, so if GHC included static versions of the libraries, developers could still accidentally create programs that depend on the dylibs. Possible Solution: Frameworks. A "Framework" on MacOS X is a directory that contains a dynamic library plus associated resources and header files. There is an extra compiler/linker option for linking to a framework. The big advantage is that the place they are supposed to be installed in is accessible from the user interface. I've created a framework called "HaskellSupport.framework", and I've made ghc link to that. Disadvantage: Problems with GHCi (yes, I've almost got it to work!) - "-framework HaskellSupport" is in the extra_ld_opts field of the RTS package, so GHCi doesn't know that it has to load the libraries. Related Problem: Sooner or later, GHC for MacOS X should support Apple's Frameworks anyway, as almost all functionality beyond the standard C library is packaged in frameworks. I don't know yet how much work that would be for me, and I fear that the ghc gurus would dislike too much platform-specific code for Apple's non-standard features... Here's what I'd like to do: *) add two command line options that get passed on to the linker (-framework for linking with a framework and -F for specifying framework search paths) *) add corresponding entries to package.conf *) add code for GHCi to load frameworks. I'm looking forward to everyone's opinions. Cheers, Wolfgang

1 0

RE: problems with FFI including h files
by Simon Marlow 05 Jun '02

05 Jun '02

> > I thought we established that generating valid C prototypes from the > > Haskell FFI type signature wasn't possible due to the incompleteness > > of the Haskell type (lack of 'const' modifiers for one thing - is > > there anything else?). > > Compilers use the same calling sequence whether you tell them about > const or not. > > I believe that we can call all C functions correctly knowing only the > calling convention (ccall, stdcall, etc) and the Haskell type. I > certainly hope this is true since Hugs' implementation of wrappers > depends on it. Yes - but read the text I quoted before my message. I'm not talking about calling the function, I'm talking about generating C prototypes. You suggested that the Haskell compiler could generate prototypes and the C compiler could be used to check for mismatches, which would be great if it were possible, but sadly it's not. The Haskell compiler can't generate a C prototype that can be used to check for compatibility with any other C prototypes in scope, because the Haskell FFI declaration doesn't contain all the necessary information. It has just enough information to be able to call the function, nothing more. The FFI *is* restricted to invoking functions, not macros (consider GHC's native code generator, for example). However, when compiling via C, we have to rely on prototypes being in scope from external header files, because of the above problem. (look in the FFI mailing list archives, BTW - these issues were discussed at length a while back). Cheers, Simon

2 1

RE: problems with FFI including h files
by Simon Marlow 05 Jun '02

05 Jun '02

> 2) Restrict ffi to invoking functions not macros. > > In this case, GHC generates function prototypes itself > based on the > Haskell type and ignores the header files. > > If you want to detect mismatches between function > prototypes in the C > header file and the GHC-generated prototypes, you could > generate a C > file like this: > > #include <ffi_specified_headers.h> > #include <ghc_generated_prototypes.h> > > GHC_type_for_f *f_pointer = &f; > > and you'll get told of many mismatches. I thought we established that generating valid C prototypes from the Haskell FFI type signature wasn't possible due to the incompleteness of the Haskell type (lack of 'const' modifiers for one thing - is there anything else?). > This is roughly how the Hugs FFI header file will look once my current > hacking on it is finished. The current header file contains little > more than the final struct and a few typedefs. Looks good. Simon

2 1

SuSE 8.0 packages
by Ralf Hinze 04 Jun '02

04 Jun '02

You can find GHC packages (version 5.03.20020410) for SuSE's latest distribution here: http://www.informatik.uni-bonn.de/~ralf/ghc-5.03.20020410-1.i386.rpm http://www.informatik.uni-bonn.de/~ralf/ghc-prof-5.03.20020410-1.i386.rpm http://www.informatik.uni-bonn.de/~ralf/ghc-5.03.20020410-1.src.rpm Have fun, Ralf

1 0

RE: Replacing the Prelude
by Ashley Yakeley 04 Jun '02

04 Jun '02

Ping! At 2002-05-14 07:17, Simon Peyton-Jones wrote: >Ashley writes > >| > I was hoping to do something similar for 'do' notation by redefining >| > (>>), (>>=) etc., but unfortunately GHC is quite insistent >| that 'do' notation quite specifically refers to GHC.Base.Monad > >Dylan replies > >| I'm surprised that ghc uses the fromInteger and fromRational >| that are in scope; I thought there was general agreement that >| it should use the Prelude.from{Integer,Rational} in scope. > >Ashley is referring to a GHC extension. Normally, GHC uses >Prelude.fromInteger etc, regardless of what is in scope. But if you >say -fno-implicit-prelude, GHC will instead use whatver fromInteger >is in scope. (This is documented in the manual.) > >Ashley's question, as I understand is whether something similar >could be done for monads. > >Answer: I think so, without much bother. I'm beavering away on >a Haskell workshop paper at the moment, but ping me in a fortnight >to do it. > >Simon >_______________________________________________ >Glasgow-haskell-users mailing list >Glasgow-haskell-users(a)haskell.org >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0