Subject: RE: MVar swap - msg#00091

Previous Message by Date: click to view message preview

MVar swap

Hi, I took a look at the implementation of the MVar function swap and I am just woundering where the atomicy comes from. -- |Swap the contents of an 'MVar' for a new value. swapMVar :: MVar a -> a -> IO a swapMVar mvar new = block $ do old <- takeMVar mvar putMVar mvar new return old Is it really just the Exception block, that makes it not interruptable? Thanks! Georg

Next Message by Date: click to view message preview

Re: Library Infrastructure code & help wanted

"Simon Marlow" <simonmar@xxxxxxxxxxxxx> writes: [snip a lot] > 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. Yep. > (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?). Yep. > 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. One use I thought of for the mid-level API is something to buid the module dependencies from the source code. This could definitely be reused by a wide variety of tools, including an hmake-type tool, a ctags-type tool, etc. That may be the only thing I've come up with, though. > Also, I really think we should clarify the situation as regards multiple > Haskell implementations, which seems to be glossed over at the moment. Yes, you've given me a lot to think about there... > 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. 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. > 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. 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. peace, Isaac, who is still thinking about it

Previous Message by Thread: click to view message preview

MVar swap

Hi, I took a look at the implementation of the MVar function swap and I am just woundering where the atomicy comes from. -- |Swap the contents of an 'MVar' for a new value. swapMVar :: MVar a -> a -> IO a swapMVar mvar new = block $ do old <- takeMVar mvar putMVar mvar new return old Is it really just the Exception block, that makes it not interruptable? Thanks! Georg

Next Message by Thread: click to view message preview

Interpreting fields in a buffer

Hi, I have a question related to a program I'm writing. I have to handle IP packets, which will be read into a buffer. What is the best haskell idiom for getting access to the fields in the buffer? The IP header has a number of fixed format fields. In C, I would define a struct, then cast the pointer to the beginning of the buffer to a pointer to the struct. I would then be able to access each field in the header as <packet_struct_ptr> -> <field>. Is there a way in haskell to declare the format of the header, then access the components of the buffer as elements of those types? I'm only going to do read access on the buffer (an unboxed array). Most fields won't be examined but I can't tell in advance which ones will have to be looked at. I've not seen an example of this kind and was wondering if this was especially awkward. Thanks. Best Wishes, Greg Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 gwright@xxxxxxxxxxx