- Libraries - Haskell.org

RE: external core
by Simon Peyton-Jones 27 Jul '05

27 Jul '05

Good idea Josef Svenningsson at Chalmers is in charge of External Core these days. Let's see what he says. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of John | Meacham | Sent: 27 July 2005 03:23 | To: libraries(a)haskell.org | Subject: external core | | Now, the external core feature of ghc is great, but it is not utilized | very much. The main reason I think is that there is a large barrier to | entry in writing something that uses it since you need to parse/generate | it. | | It would be nice if there were a standard library that came with ghc (or | cabalized and portable even better) that could parse and pretty print | external core. | | ideally, one could write a simple pass-through core processor that | interacts with ghc in a single line and someone working on a new | optimization need only worry about that. | | Also, it would make it very easy for jhc to generate and parse ghc core | files (always an ulterior motive). I wanted to use jhcs front end to | generate ghc core so I could get a true measure of the difference in | just their back-end performance without taking into account ghc's | superior high-level optimizations. | | In any case. I think all the code is out there in ghc and it just needs | to be separated and cabalized. I know there was talk of creating a ghc | internals library, but it would be nice if this code were portable and | independent. | | John | | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Cabal: Conditional code and dependencies
by Simon Marlow 25 Jul '05

25 Jul '05

On 25 July 2005 14:52, John Goerzen wrote: > On 2005-07-21, Brian Smith <brianlsmith(a)gmail.com> wrote: >> (b) A program requires some unix-specific code (package unix) or >> windows-specific code (package win32) depending on what operating >> system the program is built for. > > I just ran into this problem with making MissingH work on Windows. I > finally wound up providing a batch file for Windows users that hacks > the .cabal file, which then can be used to build the package on > Windows. Ugly, but works. We should try to avoid these sort of things, the reason being that external tools need to slurp .cabal files, so having them be dynamic creates problems. The main problem I see is Visual Studio, which in a sense is a GUI for editing .cabal files. If the .cabal file needs preprocessing, it means that someone using VS won't be able to load up your library in VS. Not saying you should have done this differently if there's no alternative, but I just wanted to point this out as an issue. Cheers, Simon

1 0

Cabal: Conditional code and dependencies
by Brian Smith 25 Jul '05

25 Jul '05

It would be useful to have mechanisms in Cabal like these: (1) Optional dependencies: "if package foo-1.0 is available, then my program depends on it; otherwise, my program does not depend on it." (see also #3 below). Special case: "my program would prefer package foo-1.2, but if that is not available, I will take any version of foo." Use cases: (a) A tool has an optional "XML export" feature that requires HaXml. If HaXml is available, then the XML export feature will be built. Otherwise, the tool will be built without it. (b) A program requires some unix-specific code (package unix) or windows-specific code (package win32) depending on what operating system the program is built for. (c) Cabal depends on HUnit if DEBUG is set, but it doesn't depend on HUnit if DEBUG is not set. (The dependency isn't controlled by the existence of a package, but by a configuration option.) (c) Let's say I send in a patch that adds a "getAppBinaryDirectory" function to System.Directory, and this patch makes it into version 1.1 of the base package. Then, Cabal 1.3 can say "If the base package version is 1.1, then we want it because it defines getAppBinaryDirectory, otherwise, we will just use base-1.0 and will provide our own implementation of that function." (2) "process this stanza if package foo-1.1 is available," etc. Use cases: (a) A tool comes in a command line version and a GUI version. The command-line version can be used independently of the existence of the GUI version. The GUI version requires wxHaskell. So, we want to say "build the GUI executable if wxHaskell is available, otherwise skip it." (b) A tool has a test suite that requires HUnit. If HUnit isn't available, then the test suite should not be built. (3) It would be useful if Cabal/GHC/Hugs/etc. #defined symbols for installed packages. This would allow us to write: module My.Program.Compat.Lib(foo1, foo2,foo3) #if __PACKAGE_foo__ >= 110 -- Is package foo-1.1 or later available? import Foo(foo1,foo2,foo3) #else foo1 = .... foo2 = .... foo3 = ... #endif Consider the following fragment from Cabal's Distribution.Compat.Directory. The Cabal authors know that the version of System.Directory that is in GHC before 6.02 includes the features Cabal needs. However, other Haskell implementations have no such version test: #if !__GLASGOW_HASKELL__ || __GLASGOW_HASKELL__ > 602 import System.Directory #else /* to end of file... */ ... #endif Instead, we could have: #if __PACKAGE_base__ >= 100 import System.Directory #else /* to end of file... */ getAppUserDataDirectory = .... #endif #if __PACKAGE_base__ < 110 getAppBinaryDirectory = ... #endif Regards, Brian

3 2

[Haskell-cafe] Arbitrary files in a Cabal package: how to install
by Dimitry Golubovsky 25 Jul '05

25 Jul '05

Ross Paterson wrote: I think there should be a new field (data-files?) listing files to be installed where the program can find them: - for GHC under Unix, in {prefix}/share/{exeName}/ - for GHC under Windows, in the same directory as the executable ({Program Files}/{packageID}) - For Hugs, in the same directory as the Main module ({Hugs}/programs/{exeName}) =================== Is there a way for a program/library included in the package to know its installation prefix (and other details) from the .cabal file at compile time (so the necessary path would be hardcoded during compilation) - maybe a CPP macro to be set when preprocessing the sources? I thought about a bit different approach. For each data file to be installed, define a separate stanza (just like for each executable), like this: extra-files: list -- (i. e. one or more files covered by this stanza) preprocess: command line -- (e. g. cp -p) destination: path -- (relative to the package installation root) "preprocess" command will be called on each file separately. It is assumed to - be aware of the OS environment it runs on, if applicable - read the file pointed to by its first parameter and write the file where the second parameter points to, after preprocessing. The minimal preprocessor is cp. If command line options are needed, they are part of the preprocess' value e. g. preprocess: gcc -E In some cases preprocessor may be a shell script placed somewhere within the package source tree. Relative path to the script is necessary then to specify. -- Dimitry Golubovsky Anywhere on the Web

1 0

Re: [Haskell-cafe] Arbitrary files in a Cabal package: how to install
by Ross Paterson 25 Jul '05

25 Jul '05

[moving to libraries] On Sun, Jul 24, 2005 at 02:32:27AM -0400, Dimitry Golubovsky wrote: > I am trying to use Cabal for buiding HSFFIG as a package. Among other > files to install I have the special template for hsc2hs which is a C > include file. If I specify it in the Includes: clause nothing happens: > it is not copied anywhere during installation. > > I need this file to be placed somewhere in the package instalation > location, so when programs are compiled with my package could include > that file. > > Of course I may specify additional step in the Makefile, but it would be > more consistent to do this in Cabal. > > How can arbitrary files be declared parts of a package, and destination > directories for them be specified? There are several programs like this (e.g. hsc2hs, happy), but specifying destination directories would be non-portable. I think there should be a new field (data-files?) listing files to be installed where the program can find them: - for GHC under Unix, in {prefix}/share/{exeName}/ - for GHC under Windows, in the same directory as the executable ({Program Files}/{packageID}) - For Hugs, in the same directory as the Main module ({Hugs}/programs/{exeName})

1 0

WashNGo Won't Build
by Dominic Steinitz 24 Jul '05

24 Jul '05

I've just downloaded and tried to build WashNGo but I'm getting the errors below. Any help would be appreciated. Thanks, Dominic. make[2]: Entering directory `/home/dom/WashNGo-2.4.6/Mail' /usr//bin/ghc -M -optdep-exclude-directory=../Utility -package-name WASHMail -package text -i../Utility ContentDisposition.hs Email.hs EmailConfig.hs HeaderField.hs MIME.hs MailParser.hs Message.hs RFC2822.hs Could not find module `Unique': it is a member of package util-1.0, which is hidden (imported from Email.hs) make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/dom/WashNGo-2.4.6/Mail' make[2]: Entering directory `/home/dom/WashNGo-2.4.6/cgi' /usr//bin/ghc -M -package-name WASH-CGI -package text -i../Utility:../Mail:../WASH -optdep-exclude-directory=../WASH -optdep-exclude-directory=../Mail -optdep-exclude-directory=../Utility AbstractSelector.hs CGI.hs CGIConfig.hs CGIGraphics.hs CGIInternals.hs CGIMonad.hs CGIOutput.hs CGITypes.hs CGIXX.hs ContentType.hs Cookie.hs CookieIO.hs Debug.hs EventHandlers.hs Fields.hs Frames.hs GuaranteedCGI.hs HTMLMail.hs HTMLWrapper.hs Images.hs PPM.hs Persistent2.hs RawCGITypes.hs RawCGI.hs RawCGIInternal.hs StateItem.hs Style.hs Submit98.hs SubmitXX.hs Types.hs Could not find module `Unique': it is a member of package util-1.0, which is hidden (imported from CGIGraphics.hs) make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/dom/WashNGo-2.4.6/cgi' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/dom/WashNGo-2.4.6' make: *** [depend] Error 2

3 2

RE: Cabal: Conditional code and dependencies
by Simon Marlow 21 Jul '05

21 Jul '05

I haven't had time to think about the other points in your message yet, but wanted to comment on this one: On 21 July 2005 06:32, Brian Smith wrote: > (3) It would be useful if Cabal/GHC/Hugs/etc. #defined symbols for > installed packages. This would allow us to write: > > module My.Program.Compat.Lib(foo1, foo2,foo3) > #if __PACKAGE_foo__ >= 110 -- Is package foo-1.1 or later available? > import Foo(foo1,foo2,foo3) > #else > > foo1 = .... > foo2 = .... > foo3 = ... > > #endif Absolutely - this thought also crossed my mind recently. We should agree on a convention. __PACKAGE_<name>__ seems reasonable, but what about the version number? We could adopt the same policy as __GLASGOW_HASKELL__, namely major*100+minor, and discard any futher dimensions in the version number (e.g. 1.1.1 and 1.1.2 both get __PACKAGE_foo__==101). This perhaps isn't as intuitive as it could be: people tend to write 110 when they want 101. So is there an alternate/better scheme? Cheers, Simon

3 3

RE: cabal permissions problems
by Simon Marlow 20 Jul '05

20 Jul '05

On 25 June 2005 23:47, Frederik Eaton wrote: > I think I remember running into something like this a long time ago > and mentioning it to someone, is it fixed in a new version of Cabal? > I'm using ghc 6.4... > > The problem is that executable files are installed to be only > executable by user: > > $ ls -al built/bin/ > total 3644 > drwxrwxr-x 2 frederik frederik 4096 2005-06-25 15:35 . > drwxrwxr-x 3 frederik frederik 4096 2005-06-24 19:57 .. > -rwxrw-r-- 1 frederik frederik 1183668 2005-06-25 15:40 fcq > -rwxrw-r-- 1 frederik frederik 2528637 2005-06-25 15:40 fcq-www.cgi > $ umask > 002 > > I haven't experienced this with any other installation procedures, > only Cabal. This is a problem with GHC's System.Directory.copyFile, which arises because getPermissions f1 >>= setPermissions f2 doesn't copy the full permissions on Unix. I've fixed copyFile. Cheers, Simon

1 0

RFC: Time Library 0.1
by Ashley Yakeley 19 Jul '05

19 Jul '05

Sorry for the hiatus, my job has left less free time to work on this. Please take a look at a first attempt at writing a replacement for the standard time library. http://semantic.org/TimeLib/ Take a look at the Haddock documentation: http://semantic.org/TimeLib/doc/html/ Download the source: http://semantic.org/TimeLib/TimeLib-0.1.tar.gz Or keep up-to-date: darcs get http://semantic.org/TimeLib/TimeLib/ It needs GHC 6.4. Just run "make" to build the library, tests and documentation. There's also a cabal file (as a completely separate build process), but I've been having trouble with that on Mac OS X. I'm particularly interested in comments from people who try to write little applications for it. What did you have trouble with? What made no sense? Some points: 1. There is no leap second table provided, though there is a type (LeapSecondTable) for such things. Any software compiled with a fixed table would soon become out of date. 2. There is no table of time-zones provided, since these also change. However, if there's a good way of getting this from the TZ database on the machine, I'll add that. It is actually possible to get the local time-zone for any given time, indeed one of the test programs finds your local summertime transitions. The Timezone type includes name, minutes of offset, and a "summertime" flag. 3. I allow multiple calendars with the DayEncoding class. GregorianDay is the most obvious instance, but there are some other useful ones such as ISOWeek. And anyone interested in local cultural calendars can plug their own in here. 4. The TimeLocale type comes from the already existing System.Locale. 5. I've tried to balance simplicity and functionality. Of course, the majority of people will only be interested in ordinary Gregorian date and time, so I have a simple CalendarTime type synonym with associated functions: http://semantic.org/TimeLib/doc/html/System.Time.Calendar.html#8 6. It's not possible to expunge POSIX time. I've hidden it, but it's used behind the scenes. Why? Because it's the only way to do sensible arithmetic on UTC times without knowing the leap second table and without worrying about one-second offsets. 7. I include Data.Fixed which provides a fixed-point arithmetic type (wrapper around Integer). It probably should be in a separate package. It allows dealing with seconds as a single thing, rather than as an integer/picoseconds pair. 8. I don't have any text-parsing functionality. This is a fair amount of work, so it would be good to know sensible requirements. -- Ashley Yakeley, Seattle WA

9 22

RE: Cabal Release Candidate
by Simon Marlow 18 Jul '05

18 Jul '05

On 18 July 2005 05:55, Isaac Jones wrote: > Brian Smith <brianlsmith(a)gmail.com> writes: >> In particular, can we just skip support for GHC 6.4? The >> installation instructions for GHC 6.4 are workable, but it looks >> like the GHC 6.4.1 experience will be much better. Plus, I think >> that the package management changes between GHC 6.4.0 and 6.4.1 will >> cause problems for people packaging their stuff using Cabal. So, >> could we just say that Cabal 1.2 requires GHC 6.2.2 or GHC 6.4.1 or >> later? > > I do indeed think that the next version of GHC will be better for > installing packages, but I don't think we should give up on 6.4. > OTOH, I don't think that it's a huge deal to just document the > difficulties. It's really no harder than removing the old Cabal > before installing the new one. Maybe we should just force everyone to > do that, or make that the default behavior for "make install". > That'll probably offend some folks' sensibilities. What do folks here > think? It's a tough one. Skipping 6.4 is somewhat attractive, because there are some serious problems with upgrading Cabal on GHC 6.4. However, if we put appropriate warnings into the Cabal README and describe what the problems are, I think that's enough. I also need to check whether GHC can still be built if Cabal has been upgraded. >> * It should be possible for Windows users to build Cabal 1.1.1 on >> both GHC 6.2.2 and GHC 6.4.1 without having GNU make installed. This >> process needs to be documented. I will wait to send you the docs >> until I find out if GHC 6.4(.0) will be supported in Cabal 1.2. > > Yes, I would like to support it. The only extra steps are those in > the "make setup" command, which is just a couple of extra flags to GHC > for bootstrapping. A batch file / shell script would actually work > just as well. The GNUMakefile is really just a glorified shell script. With 6.4+, I hope you can use "runghc Setup.lhs". With 6.2.2, typing some GHC commands manually is probably required (perhaps we could include a .bat file?). Cheers, Simon

1 0