- Libraries - Haskell.org

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

On 21 April 2005 12:07, Ross Paterson wrote: > On Thu, Apr 21, 2005 at 10:32:59AM +0100, Simon Marlow wrote: >> In GHC, you can assume that >> >> hGetByte h = do c <- hGetChar h; return (fromIntegral (ord c)) >> >> you must open the file in binary mode (openBinaryFile). I don't >> think this works with Hugs, though. > > It does, provided the file was opened in binary mode. Right, thanks for the clarification. Simon

1 0

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

You might be thinking of Hugs. GHC's behaviour hasn't changed. Cheers, Simon On 21 April 2005 13:33, Keean Schupke wrote: > But hasn't ghc just changed its IO (with regards to localisation)? If > it can happen once it can happen again. > > Keean. > > Simon Marlow wrote: > >> On 21 April 2005 11:16, John Meacham wrote: >> >> >> >>> but a useful stopgap, because their use would guarentee your code >>> wouldn't suddenly stop working when ghc changes its IO system. >>> >>> >> >> That isn't going to happen, but I take your point. >> >> Simon >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Suggestion re Data.Storable.Array
by Simon Marlow 21 Apr '05

21 Apr '05

On 21 April 2005 02:10, Paul Steckler wrote: > I recently needed to access C-like arrays > from Haskell. Everyone pointed me to > Data.Storable.Array, but that wasn't quite > what I wanted. The MArray class that provides > the interface for storable arrays insists that > it create the storage via newArray or newArray_. > But I already had the C storage I needed; I justed > wanted to wrap that in Haskell. > > I cons'ed up my own primitives, which work just > fine, but it would be nice to just use something > already in the libraries. Concretely, adding > a way to create a storable array from an existing > Ptr would've done the trick. I can see that's > less safe, but sometimes you have to live > dangerously! Ok, I've added a suitable back door: unsafeForeignPtrToStorableArray :: ForeignPtr e -> (i,i) -> IO (StorableArray i e) Cheers, Simon

1 0

RE: Cabal vs Haskell (was RE: build-depends harmful (was RE: import resolution))
by Simon Marlow 21 Apr '05

21 Apr '05

Hi Alex, I'm going to take a break from this discussion for a while. If I responded to your previous message, I feel I'd be repeating a lot of things I've already said in this thread, and not really making any progress. That's not to say there isn't progress to be made. I suggest that if you want to propose a change to Haskell and/or Cabal, you write it down as precisely as possible and send it to the list. If possible, separate proposals into smaller parts - separate changes to the Haskell definition from changes to the package system and changes to Cabal. Cheers, Simon On 20 April 2005 19:43, S. Alexander Jacobson wrote: > Simon, > > Right now, a module name in an import declaration identifies a module > specification, a module name in a module declaration identifies an > implementation, and some "external mechanism" resolves specifications > to implementations. The big issue on the table here is what exactly > this "external mechanism" should be. I'll suggest some requirements: > > 1. It should require minimal work for a user to share an > implementation. > > 2. It should work with and accross the Internet. > > 3. It should allow arbitrtary sets of implementations to be > delivered together as needed. > > 4. It should be able to work without substantial user > intervention. > > 5. Module users rather than module authors should select how > imported module names are resolved to implementations. > > 6. Interface changes should be local to users of those interfaces. > > 7. It needs to handle foreign implementations (FFI) > > Unfortunately, our existing module resolver mechanisms are severely > inadequate here. Build-depends and -package both violate #1 because > they both force users to create packages even to share standalone pure > haskell modules. The fact that module/package names can't currently > be resolved to URLs means both also violate #2 and #4. That packages > can contain at most one implementation of any module violates #3 and > #5 (and it is just a file format problem!). That package > build/install processes can modify overall system state violates #4. > Build-depends MAJORLY violates #5 and #6. On the plus side, they both > handle #7. > > I'd like Haskell to have a module resolver mechanism that fulfills our > requirements and does not have these problems. > > -Alex- > > ______________________________________________________________ > S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com > > > > On Wed, 20 Apr 2005, Simon Marlow wrote: > >> On 20 April 2005 11:56, S. Alexander Jacobson wrote: >> >>> Lastly, I think you proposal to add package naes to the source is >>> seriously at odds with your commment from earlier: >> >> I'm not proposing to add package names to source code. >> >> The rest of your post was based on this misconception, so I won't >> answer it. >> >> I realise my description of the idea wasn't as complete as it could >> have been. I'll try to describe the idea more precisely. (note >> this isn't a proposal as such). >> >> - source code continues to use module *names* only. >> >> - define module *identifier* as (package name, module name) pair >> >> - in the context of each module's source, there is assumed to be >> a mapping from module name to module identifier established by >> some external mechanism. >> >> The "external mechanism" referred to here could be GHC's -package >> flags, or Cabal's build-depends, for example. For the purposes of >> the language definition, it doesn't matter. >> >>> Also, the Haskell module hierarchy is supposed to reflect >>> functionality, whereas package names are purely administrative. >>> This is a reason for not including package names in source code. >>> >>> >>> http://www.haskell.org//pipermail/libraries/2005-April/003513.html >> >> My position on this has (still) not changed! >> >> Cheers, >> Simon

1 0

Suggestion re Data.Storable.Array
by Paul Steckler 20 Apr '05

20 Apr '05

Hi, I recently needed to access C-like arrays from Haskell. Everyone pointed me to Data.Storable.Array, but that wasn't quite what I wanted. The MArray class that provides the interface for storable arrays insists that it create the storage via newArray or newArray_. But I already had the C storage I needed; I justed wanted to wrap that in Haskell. I cons'ed up my own primitives, which work just fine, but it would be nice to just use something already in the libraries. Concretely, adding a way to create a storable array from an existing Ptr would've done the trick. I can see that's less safe, but sometimes you have to live dangerously! -- Paul

1 0

Binary IO
by Iavor Diatchki 20 Apr '05

20 Apr '05

Hello, I've been playing around with decoding binary files, and I couldn't find a function in the libraries to read a byte from a file. Does anyone know if there is such a function? If not, I think we should add one. Currently I am using hGetChar for this purpose but it seems that we should have: hGetByte :: Handle -> IO Word8 I don't think that hGetChar is good enough because characters are not bytes. In particular it seems that an implementation could consult the system's locale settings and use a variable character encoding such as UTF8. Also on a related note, is there a way to work with memory mapped files in Haskell/GHC? -Iavor

2 1

Re: Cabal Installing Executables
by Dominic Steinitz 20 Apr '05

20 Apr '05

On Saturday 16 Apr 2005 9:10 am, Niklas Broberg wrote: > > Can someone tell me what I have to do to install the executables in the > > current directory or my home directory and also set the permissions (and > > ownership) to be that of the installer? > > Give the flag --prefix=/my/chosen/dir when you run ./Setup configure, > that will put the executables in /my/chosen/dir/bin. Very handy. =) > > /Niklas Niklas, Thanks for this. It doesn't quite do what I want. I want the executables in /my/chosen/dir/bin but the library to be in /usr/local/lib rather than /my/chosen/dir/lib. Actually now I think about it, what I really want is for the user of the package would build it, test it and then install it. The executables are actually tests and examples. I'd like the installer to be able to run the tests locally and then, if they are happy, install it. I suppose a solution is: 1. ./Setup configure --prefix=/my/chosen/dir ./Setup build ./Setup install --user 2. Run the tests in /my/chosen/dir/bin 3. ./Setup unregister --user ./Setup clean ./Setup configure ./Setup build ./Setup install One final thought: why is there no uninstall? Dominic.

4 5

RE: Cabal vs Haskell (was RE: build-depends harmful (was RE: import resolution))
by Simon Marlow 20 Apr '05

20 Apr '05

On 20 April 2005 02:00, S. Alexander Jacobson wrote: > You appear be proposing to change the definition of a Haskell program > from a set of Haskell modules connected by import to a set of Cabal > packages connected by build-depends. Not at all - the definition of a Haskell program is still a collection of modules with distinct names. If we were to "lift the overlap restriction" then the definition would change to a collection of modules with distinct (package name, module name) pairs. Two changes are required: - define module name as (package name, module name) pair - in the context of each module's source, there is a mapping from module name to package name that is used to resolve an import. the definition doesn't require Cabal, or build-depends. Given that this model doesn't rely on Cabal or build-depends, I'm afraid I don't understand the rest of your post. I think you may have misunderstood what the module overlap restriction is. > == Lifting The Overlap Restriction == > > The Haskell model is much simpler for the user and sacrifices little > expressive power. > > Under the Haskell model, M.T means the same thing in every module and > lifting the overlap restriction means programs just have a lookup > table mapping module names to module locations; resolution follows > simply and directly without worrying about package structure. If programs are still collections of modules with distinct names, then the module overlap restriction is still in place. Perhaps you could define some terms more precisely, to avoid confusion: for example things like "module location", and what you understand by "overlap restriction". Cheers, Simon

2 1

RE: Cabal compiling with profiling
by Simon Marlow 20 Apr '05

20 Apr '05

We could extend the .cabal syntax along the lines of: Package: foo Version: 1.0 etc. extensions: CPP extra-libraries: X11 [Release] ghc-options: -O2 [Debug] ghc-options: -O0 -DDEBUG and extend PackageDescription to include multiple BuildInfos, each with an attached configuration tag. How does that sound? The .cabal syntax remains backwards compatible. Cheers, Simon On 20 April 2005 09:07, Krasimir Angelov wrote: > What I have in mind is to have multiple .buildinfo files. One for each > configuration. For example <pkg>.buildinfo.debug & > <pkg>.buildinfo.release. Each hook can check for a specific > --config=<..> command line option and will load the appropriate > .buildinfo file. The disadvantage here is that in this way I need to > maintain multiple files in addition to the central .cabal file. > Another trouble is that with hooks API I cann't change the destination > directory where the .hi and .o files are created. They all will go to > dist/build while I need to keep them separated. > > It would be simpler if the Cabal library was aware of this > configurations. In this case the configuration descriptions can be > moved to .cabal file. We can have few predefined configurations like > "Debug", "Release", "Profiling", ... which are always with predefined > options. For Debug we can add -DDEBUG option to GHC, for Release -O > option and maybe -split-obj and for Profiling -prof option. Of course > we have to leave the user to change the default options and he have to > be able to define its own configurations. > > Cheers, > Krasimir > > On 4/19/05, Isaac Jones <ijones(a)syntaxpolice.org> wrote: >> Krasimir Angelov <kr.angelov(a)gmail.com> writes: >> >>> We need something more general in VSHaskell. Usually each project in >>> the Visual Studio environment has two configurations "Debug" and >>> "Release" but the user can define his own configurations. The only >>> difference between each configuration is in the command line >>> switches passed to the compiler. >> >> Or to the configure step? >> >>> For Haskell projects this mean that each configuration will have >>> different HookedBuildInfo associated. The profiling can be >>> implemented in this more general framework if we add "Profiling" >>> configuration. I still don't have clear design for configurations in >>> Cabal. My first thought was that I can do this on top of hooks API >>> but I am not sure whether it will be flexible enough. >> >> Can you flesh this out a bit? What do you mean by "configurations in >> cabal"? What are the issues that you're facing with the hooks? We >> need good feedback on the hooks. >> >> peace, >> >> isaac >> > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1

Cabal compiling with profiling
by Isaac Jones 20 Apr '05

20 Apr '05

I have a patch from Arthur Baars to build profiling libraries for GHC. I'm wondering how people think it should be integrated? Should we have a --prof option that JUST builds profiling libraries, or which builds both non profiling and profiling? I know that the makefile system has some "ways" that I think are related to profiling. Should we have something more flexible, or is --prof or --with-prof flexible enough? peace, isaac

3 4