- Libraries - Haskell.org

RE: Environment variable does not work (especially DARCS_EDITOR)
by Simon Marlow 22 Apr '05

22 Apr '05

On 21 April 2005 17:57, Glynn Clements wrote: > Simon Marlow wrote: > >>> The test program works after applying the following patch to GHC >>> that disables nonblocking mode after the fork and before the exec. > >> If we did this, we would also need to re-enable non-blocking mode >> after the rawSystem completes. Also, this doesn't work well if >> runProcess is used and the Haskell program continues to run while >> the subprocess is executing, because the O_NONBLOCK flag is shared >> between parent and child. > > Presumably the Haskell program won't like it very much if the spawned > program disables O_NONBLOCK itself? > > Is there a reason (other than performance) why the use of O_NONBLOCK > can't be replaced with calling select/poll before accessing the > descriptor? That would work, as long as the current process is the only user of that file descriptor: otherwise there's a race condition between the select() and the read(). This is really a Unix design blunder, there ought to be a non-blocking version of read(). > Is non-blocking I/O only necessary if you need explicit concurrency? > Or do the runtime or critical libraries require it? Right, it's only important if you need concurrency. Cheers, Simon

1 0

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

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

3 2

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

On 20 April 2005 22:35, Scott Turner wrote: > On 2005 April 20 Wednesday 15:56, Iavor Diatchki wrote: >> 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? ....... it seems >> that we should have: >> hGetByte :: Handle -> IO Word8 > > hGetByte could be implemented on top of hGetBuf and StorableArray, > but the overhead would be ugly. Recently I needed binary input for > similar reasons, and would have used hGetByte had it been available. > I ended up performing input using a reasonable-sized buffer. 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. Personally, I think this ought to be part of the redesign of the I/O library. hGetByte and hPutByte would be a stopgap. But, not much progress is being made on an I/O redesign right now. Cheers, SImon

5 5

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 21 Apr '05

21 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