December 2006 - Libraries

Re: Using putStrLn/printf from DLL in GUI application
by Simon Marlow 04 Dec '06

04 Dec '06

Krasimir Angelov wrote: > How many times you tried to use putStrLn from Haskell or printf from C > when you are building DLL loaded in GUI application? > > This simply doesn't work because by default the GUI application > doesn't have console window. The solution is to use > allocConsole/freeConsole from the attached library. > > > Example: > > do allocConsole > ..... > ..... > putStrLn "Hello, world!" > ..... > ..... > freeConsole > > This could be a good addition to the standard Win32 library if someone > take care to integrate it. So that we don't lose this: will someone propose a patch to packages/Win32? Cheers, Simon

1 0

Re: Data.List documentation improvements
by Andriy Palamarchuk 04 Dec '06

04 Dec '06

----- Original Message ---- From: Neil Mitchell <ndmitchell(a)gmail.com> >> The deadline is Wednesday, December 6th. > > That's incredibly soon, two days is just not enough time to do > anything! I recommend a minimum deadline of a week for anything, some > people may only catch up with their Haskell mail a couple of times a > week. Will keep in mind for the future submissions. Leave this one as is. It is easy to update the docs later. > As for your patch, I think its great, and its exactly the type of > thing that should be in the libraries documentation for pretty much > everything. My only suggestion would be to include the "corner" cases: > > take 3 [1] = [1] > drop 3 [1] = [] > > (ditto splitAt) > > i.e. show that they produce a result, not an error. I'm for it. Will add. Andriy ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.

1 0

Success Story: Cabal and Dlls
by Jason Dagit 01 Dec '06

01 Dec '06

Hello, I would like to report that I was able to use Cabal with Visual Haskell to build Dlls in windows. I have posted the details about this on the Haskell wiki (and started an extremely minimal Cabal page). If my content is in the wrong place, please feel free to move it (or edit it or whatever). http://www.haskell.org/haskellwiki/Cabal The trick was to take the final HSfoo-0.1.o file generated by the normal build process (and linked with the DllMain.c code) and tell ghc to build a dll. I use -package with each of the dependencies in the cabal file to link with the needed libraries. The resulting dll seems to be working. This approach is a bit hackish and while I've tried to implement as much of it as I can in a general way it requires you to hack your Setup.lhs file if you want to 1) build static 2) specify your exports 3) specify the name of the resulting dll. Also, it's only been tested on my setup which uses Visual Haskell so it may not be fit for general consumption. Finally, I just started really looking at Cabal yestarday so I may not have considered things which an experienced Cabal user would think about. Is it possible to get this functionality built directly into Cabal so that I tell it I want a DLL built from a library and it knows how to make it happen? Thanks, Jason

5 11

Announce of Core (ghc-base) library
by Bulat Ziganshin 01 Dec '06

01 Dec '06

This message is of primary interest for developers of Haskell compilers and core libraries. it duplicated at http://haskell.org/haskellwiki/Library/Core Thanks to Cabal, now we can easily upgrade any installed library to new version. There is only one exception - Base library that is closely tied to compiler internals, so you cannot use Base library shipped with GHC 6.4 in GHC 6.6 and vice versa. The Core library is a project of dividing Base library into two parts - small compiler-specific one (the Core library proper) and the rest - new, compiler-independent Base library that uses only services provided by Core lib. Then, any version of Base library can be used with any version of Core library, i.e. with any compiler. Moreover, it means that Base library will become available for the new compilers, like yhc and jhc - this will required adding to Core lib only a small amount of code implementing low-level compiler-specific functionality. Core library consists of directories GhcCore, HugsCore... implementing compiler-specific functionality and Core directory providing common interface to this functionality, so that external libs should import only Core.* modules in order to be compiler-independent. In practice, implementation of Core lib became a refactoring of GHC.* modules by splitting them into GHC-specific and compiler-independent parts. Adding then implementations of compiler-specific parts for other compilers will allow us to compile refactored Base library by any compiler including old versions of GHC. At this moment, the following modules was succesfully refactored: GHC.Arr, GHC.Base, GHC.Enum, GHC.Float, GHC.List, GHC.Num, GHC.Real, GHC.Show, GHC.ST, GHC.STRef, and the next step is to refactor IO functionality Like the original GHC.* modules, Core library builds up its functionality in layers, where each next layer use features provided by previous ones. Already written layers are, in order of dependencies: Base Integer Integral Float ST/Int/Word Arr Each layer includes both compiler-specific and compiler-independent modules, say first layer is represented by GhcCore.Base/HugsCore.Base and Core.Base modules in contrast to initial design i proposed, compiler-dependent modules in each layer can import and use compiler-independent functionality of previous layers, this greatly simplifies writing of compiler-dependent code and allow to avoid code duplication. For example, GhcCore.* modules widely use && operation defined in Core.Base module. So, when compiling with GHC, dependencies order will be as follows: GhcCore.Base -> Core.Base -> GhcCore.Integer -> Core.Integer -> ... at last end, this mean that Core library can't be split to GhcCore, HugsCore and other separate ones, but need to be united library that includes code for all compilers we support speaking in terms of versions, Base and other higher-level libraries can request specific Core version (say, 2.0.*) and be sure that some set of services should be available. Inside these version range, Core library may grow to support additional compiler versions, say only GHC 6.6 in 2.0.0, GHC 6.6/6.8 and Hugs 2006 in 2.0.1 and so on Why i stopped further development of Core at this stage? First, it was not so hard task - in a week or two i've refactored, afair, 1/3 of GHC.* code. My next goal was to implement Hugs support for all already implemented facilities, but i find serious problems with redefinition of Prelude types and classes. may be, using a feature of upgrading Base, this will become no problem. The same problem, although in less degree, i had with GHC too Second problem that stopped me was I/O part of GHC.* library. It seems impossible to move this out of Core (!) library because Handle type used in definition of Exception type which used by 'fail' for IO Monad and IO monad used everywhere. so, we need some brainstorming to analyze the situation and general tendency of Base library to use too many dependencies. One example was provided by Ross: Data.HashTable is used in Data.Dynamic, that is used in Exception.. so, again, it can't be moved out of Core lib! but even if we can't extract Core library from Base as "compliler-equalizer" subset of modules which includes only Core.* and don't includes Data.*, System.* and other code, at least it's possible to split existing GHC.* code into simple compiler-dependent and more complex compiler-independent parts and simplify way to support 1) new compilers like JHC and YHC 2) range of compiler versions instead of just one version so, i hope that this work will be interesting and helpful for community, especially in order to help new compilers support rich set of libraries with a minimal effort library is available as http://www.haskell.org/library/Core.tar.gz please note that Data.* modules should be considered not as part of library but as examples of modules from future Base library that will be based on services provided by Core -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: Library docs on Debian
by Yitzchak Gale 01 Dec '06

01 Dec '06

I wrote: >> ...Haddock docs for all of the standard libraries... >> through a single consolidated index... >> many of them are gone... mtl and network. >> What is the new Right Way to install these docs on >> a Debian system? Conrad Parker wrote: > the docs are in the package ghc6-doc. No, that is the point, they are not there. That package only contains the docs for libraries that come with GHC. In GHC 6.6 that has been cut down considerably. How do I install the docs for the rest of the standard library? Thanks, Yitz

1 0