January 2004 - Libraries

Re: Library Infrastructure code on Windows
by Graham Klyne 25 Jan '04

25 Jan '04

More feedback... basically, it works! I get one batch of warnings when compiling: [[ Compiling Distribution.Package ( ../Distribution/Package.hs, ../Distribution/Pac kage.o ) ../Distribution/Package.hs:317: Warning: Pattern match(es) are non-exhaustive In a record-update construct: Patterns not matched: NoVersion NumberedVersion _ _ _ ../Distribution/Package.hs:319: Warning: Pattern match(es) are non-exhaustive In a record-update construct: Patterns not matched: NoVersion NumberedVersion _ _ _ ../Distribution/Package.hs:321: Warning: Pattern match(es) are non-exhaustive In a record-update construct: Patterns not matched: NoVersion NumberedVersion _ _ _ ../Distribution/Package.hs:324: Warning: Pattern match(es) are non-exhaustive In a record-update construct: Patterns not matched: NoVersion DateVersion _ _ _ ../Distribution/Package.hs:326: Warning: Pattern match(es) are non-exhaustive In a record-update construct: Patterns not matched: NoVersion DateVersion _ _ _ ../Distribution/Package.hs:328: Warning: Pattern match(es) are non-exhaustive In a record-update construct: Patterns not matched: NoVersion DateVersion _ _ _ Compiling Main ( Test.hs, Test.o ) Linking ... ]] ... I get one failure from the unit test: [[ C:\DEV\Haskell\lib\LibInfrastructure\Distribution>testDist Cases: 9 Tried: 9 Errors: 0 Failures: 0 Cases: 28 Tried: 28 Errors: 0 Failures: 0 'diff' is not recognized as an internal or external command, operable program or batch file. ### Failure in: 1:package diff:'diff /tmp/xmlTest /tmp/xmlTestOut' failed expected: ExitFailure 1 but got: ExitSuccess Cases: 2 Tried: 2 Errors: 0 Failures: 1 ]] ... This looks like a unix-specific command. I was able to get the test suite to run successfully by changing test.hs thus: [[ hUnitTests :: [Test] hUnitTests = Distribution.Package.hunitTests ++ Distribution.Version.hunitTests testFilename1 :: String testFilename1 = "testDist\\xmlTest.tmp" testFilename2 :: String testFilename2 = "testDist\\xmlTestOut.tmp" diffCmd :: String diffCmd = "fc " ++ testFilename1 ++ " " ++ testFilename2 ]] Giving: [[ C:\DEV\Haskell\lib\LIBINF~1\DISTRI~1>testDist Cases: 9 Tried: 9 Errors: 0 Failures: 0 Cases: 28 Tried: 28 Errors: 0 Failures: 0 Comparing files TESTDIST\xmlTest.tmp and TESTDIST\XMLTESTOUT.TMP FC: no differences encountered Cases: 2 Tried: 2 Errors: 0 Failures: 0 ]] Rather than depending on an external file compare utility, would it not be easier to use a test something like: readFile(testFilename1) == readFile(testFilename2) ? For example: [[ testFilename1 :: String testFilename1 = "testDist/xmlTest.tmp" testFilename2 :: String testFilename2 = "testDist/xmlTestOut.tmp" main :: IO () main = do runTestTT $ test Distribution.Package.hunitTests runTestTT $ test Distribution.Version.hunitTests writeXml testFilename1 testPackage2 e <- (readXml testFilename1::IO PackageConfig) writeXml testFilename2 e f1 <- readFile(testFilename1) f2 <- readFile(testFilename2) runTestTT $ test ["write and read" ~: "failed" ~: show e ~=? show testPackage2, "file compare" ~: f1 ~=? f2 ] return () ]] gives: [[ C:\DEV\Haskell\lib\LIBINF~1\DISTRI~1>testDist Cases: 9 Tried: 9 Errors: 0 Failures: 0 Cases: 28 Tried: 28 Errors: 0 Failures: 0 Cases: 2 Tried: 2 Errors: 0 Failures: 0 ]] ... The Windows batch file I used to build this is this: [[ set WARNINGS=-Wall set PACKAGES=-package HaXml -package data set HUNIT=C:\DEV\Haskell\lib\HUnit\ set GHC=C:\DEV\ghc\ghc-6.2\bin\ghc if "%1"=="clean" goto clean :all mkdir testDist %GHC% -fglasgow-exts %WARNINGS% -i%HUNIT%;.;.. -package HaXml --make Test.hs -o testDist goto exit :clean DEL *.hi DEL *.o DEL /Q testDist\*.* :exit ]] ... See my separate message about building HaXml on windows. #g -- ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

ºÏ×÷
by libraries＠haskell.org 25 Jan '04

25 Jan '04

你好我公司专业代理网络邮件群发业务，国际和国内网络宣传均可，使你的业务蒸蒸日上，蓬勃发展。联系方式：makemoney2003_8(a)hotmail.com QQ 147628754 祝您新年快乐吉祥如意 --------------------------------------------------------------- 客户挖掘大师 http://www.i-miner.com 一边根据关键词搜集电子邮件地址一边发送电子邮件的网络营销利器 --------------------------------------------------------------- CustomerDigger http://www.webrobber.com Sending e-mails while collecting e-mail addresses by keywords ---------------------------------------------------------------

1 0

ANNOUNCE: Cryptographic Library for Haskell
by Dominic Steinitz 24 Jan '04

24 Jan '04

I would like to annouce a new release of the Haskell Cryptographic Library (1.1.2). See http://www.haskell.org/crypto/ReadMe.html for more details. This library collects together existing Haskell cryptographic functions. This release contains MD5 and now works with Hugs (November 2003 version). Dominic Steinitz

1 0

Re: Ejacu.late Like A P0RN Star!
by Template-haskell 24 Jan '04

24 Jan '04

1 0

Re: Ejacu.late Like A P0RN Star!
by Cvs-ghc 23 Jan '04

23 Jan '04

1 0

Re: Ejacu.late Like A P0RN Star!
by Hashmi 23 Jan '04

23 Jan '04

1 0

nesws regarding vigros adjourn
by Mgregor 22 Jan '04

22 Jan '04

childhood, How Vigras works. And you can better understand, what Vigras can do for you. If you are sensible about your health, reflect on what you can do for your seual health, to keep the chances that you will need Vigras as low as possible. thrusting refrained demur, barest. http://www.pvmsolutions.com/index.php?pid=genviag Inrease Seks Drive Bost Seual Performance Fuller & Harder Erecions Inrease Stamna & Endurance Quicker Rechages obliterate economies Antonovics, harsh. remnants inspects transit, mildew. Happy holidays, bootable

1 0

RE: Library Infrastructure code & help wanted
by Simon Marlow 22 Jan '04

22 Jan '04

> > Having a single package database for all Haskell > implementations seems a > > hard thing to implement: when GHC is installed, it will > have to check > > whether the database and haskell-config already exist, and > similarly for > > the other Haskell implementations. When a Haskell system is > > deinstalled, it has to decide whether to de-isntall > haskell-config and > > the package database. > > I don't think that's so bad. Figuring out if a package database > already exists should be a matter of having an agreed upon > System.Directory.systemConfigDir. Then maybe the package database > itself can tell you where to find haskell-config. What about multiple versions of GHC installed on a system, each with different sets of packages installed? Can I still install GHC in my own home directory, without needing to modify files in /etc? > I think that the compilers / interpreters installed on the system will > also be stored in the "package config" database. If you're > deinstalling yourself, the package database can tell you whether > you're the only compiler left and thus whether to get rid of > haskell-config. > > That said, I think there are still issues with having a single package > database, for instance, what if a package configuration for one > Haskell Implementation has a field that conflicts with the package > configuration for another implementation. Yuck! But maybe that won't > come up. For instance, right now there are separate flags for ghc, > nhc, and hugs opts, and probably there should be flags for > shared opts. Also, there doesn't seem to be provision in the package configuration for naming libraries specific to a particular implementation (eg. to use this package on GHC you must link in libHSwibble.a from /foo/bar, but on nhc98 you link in libHSnhc_wibble.a from ...). It seems to me that every field needs to be duplicated for each compiler installation; either that or you could put the compiler name in the package identifier, so you'd have packages like "ghc-6.2-base-1.0", "nhc98-1.3-base-1.0". Incedentally, GHC never uses the extra_ghc_opts in the package configuration. In fact, I don't think it should be there: it doesn't make sense in conjunction with auto packages (if I don't know whether I'm using a package or not, I don't know whether to add the flags). The flags fields should be disabled if auto is True. > > I'd rather just admit that the Haskell systems are > separate, and each > > provides its own implementation of Distribution.Package. Yes, this > > means that if you run Setup.lhs with Hugs it is different > than running > > it with GHCi: if I want to install a package for GHC I > have to run the > > Setup.lhs script using GHC. > > I think this would dash my hopes of being able to install a package > with a single command. The idea so far has been to have some kind of > haskell-interactive / runhugs-type executable /usr/bin/haskell which > will execute the setup script to install and configure the package > based on the already-installed compilers. It doesn't prevent you doing this. Here's how it might work: - Each compiler has their own package database, and their own implementation of Distribution.Package with an implementation-defined location for the package database(s). - There is a suite of tools, including haskell-config and /usr/bin/haskell, which are installed only once. These tools know about all the installed compilers on the system. We could install these tools with a compiler, or separately; installs/deinstalls of compilers need to update some state so that the tools are aware. - /usr/bin/haskell could run the script it is given using each compiler on the system, if that's what you want. eg. $ /usr/bin/haskell script.hs -- runs script.hs using the default compiler $ /usr/bin/haskell --all script.hs -- runs the script using each compiler on the system so to do an installation for all compilers, you say './Setup.lhs --all --install', assuming that Setup.lhs begins with '!#/usr/bin/haskell'. > Likewise, when you install a new compiler, it knows about what > packages are there already for the other ones and might take a crack > at building them for itself. > > This isn't so far fetched: elisp for emacs and xemacs already do > something similar on Debian at least. We can aim for this in the long term if you like - I still believe this is something that the package management system should do for us, though. The end result is the same, and it's a lot less work. Cheers, Simon

1 0

Don't Want To Be Busted ? ? ? . . . . . . . . rapturous
by Leanne 22 Jan '04

22 Jan '04

1 0

RE: Library Infrastructure code & help wanted
by Simon Marlow 21 Jan '04

21 Jan '04

> 2) I also would like someone to help out with the package > configuration file IO. Right now, it uses HaXmL, with no generated > code. Someone who has seen HaXmL before could give me advice about > how my code could be better, submit patches, or rewrite it. As > discussed on libraries(a)haskell.org, I'm open to not using XML if > someone wants to redo what I've got there (not a huge task). This > parsing code is in Distribution.Package. I do want something more > flexible than straight-up read/show. I rather think that this should be considered a "sample implementation" of the Distribution.Package API. A consumer of the API should neither know nor care about the on-disk representation of the package database. I think we should specify the form of the library meta-data, at least for the default build system (by meta-data I mean the form of toolInfo in the example in sec. 3.4 of the doc). We can take the approach that we specify a very simple form, which works for most straightforward Haskell-only libraries, or we could define a rich form which will provide enough for all but the most complex library packages. I think we should start with the simple form - complex libraries will probably continue to use their own build systems for a while yet. The idea, as I understand it, is that we're going to provide two main APIs: (b) The high-level API (Distribution.Core in the example). Used by simple Setup.lhs scripts to provide generic build, install, and package registration services. Consumes Distribution.Package internally. (a) The low-level API (Distribution.Package). This is for custom build-systems which provide their own build & install, so that they can register a package. Also used by the command-line tool (haskell-config?). There may also be a mid-level API (Distribution.Build, Distribution.Install), but I'm not sure I can see a clear use for that at the moment. If not, then we don't need to specify these APIs, and they can be internal to the default build system. Also, I really think we should clarify the situation as regards multiple Haskell implementations, which seems to be glossed over at the moment. Having a single package database for all Haskell implementations seems a hard thing to implement: when GHC is installed, it will have to check whether the database and haskell-config already exist, and similarly for the other Haskell implementations. When a Haskell system is deinstalled, it has to decide whether to de-isntall haskell-config and the package database. I'd rather just admit that the Haskell systems are separate, and each provides its own implementation of Distribution.Package. Yes, this means that if you run Setup.lhs with Hugs it is different than running it with GHCi: if I want to install a package for GHC I have to run the Setup.lhs script using GHC. I believe that's the right way to go, and it's much easier from our point of view: all we have to do is agree on the Distribution.* APIs, we don't have to have any clever install/deinstall magic to deal with shared components. Cheers, Simon

2 1