[Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
> I see. If you're using the darcs 1 binary I would encourage you to > upgrade. If you meant darcs 1 repository format then I would > encourage you to consider darcs 1 hashed repository format. You don't > even have to upgrade the public facing repo. Just 'darcs get --hashed > ...'. I mean that I'm currently using Debian's 1.0.3 on my stable servers, and the old repository format all over the place. I'm using 2.0.2 on my desktop machines. I will definitely switch to the Darcs 2 implementation at some point, but Darcs 1 hasn't broken down yet, and I've got other stuff to do right now. >> The alternative is to build a static version of Darcs that I can install on >> my stable (soon to be oldstable) servers. That might actually be the simplest solution, now I come to think about it. >> The alternative to both alternatives is to switch to git. > Right. But I hope you're not saying that because you find this thread > upsetting. No. That was just a way of pointing out that other revision control systems do not have such complex build dependencies. Juliusz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
> I wanted to know if anyone who is using distros with 6.6 need to be > able to build current releases of darcs from source. If there turns out to be a significant issue with Darcs 1, I need to be able to build a recent version of Darcs in my Debian stable chroot. The alternative is to build a static version of Darcs that I can install on my stable (soon to be oldstable) servers. Last time I checked, building static Darcs didn't work. The alternative to both alternatives is to switch to git. Juliusz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
> Also, note that Lenny has 6.8, and it is scheduled to become stable Real > Soon Now. That's irrelevant. Lenny going stable will not cause my servers to automatically get upgraded. FWIW, the experimental server is scheduled to switch to lenny in the summer of 2009. There is no ETA for the production servers, which tend to be managed more conservatively still. Juliusz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
> Debian is nice in some ways and it's really great that stable lives up > to its name, but I am sad that Debian has such old software for so > long. Jason, I know it's frustrating, but please understand where we're coming from. There are a number of servers that support our research. The important thing to understand is that nobody is paid full-time to maintain these servers. For example, in our lab, the production servers are maintained by one technician that has a number of other machines in charge, the server for experimental stuff is maintained by myself and one postdoc in our copious free time. As far as the server I'm in charge of is concerned, we apply security patches in a timely manner, and we try to check the logs on a weekly basis. Other than that, we avoid touching it. Once every two years, usually in August, we move it from oldstable (head - 2) to stable (head - 1). We then spend a couple of weeks reading the logs daily and ironing out any remaining issues. (The production servers are managed even more conservatively, the DNS server has only just switched to stable, the web/SMTP server is still running oldstable.) So please understand that it's not a matter of Debian or no Debian. If we were to upgrade my server more than once in two years, I would need to find funding for a technician. Juliusz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Value-weak hash tables for GHC?
Hi, Does anyone have an implementation of value-weak hash tables for GHC he'd be willing to share? (Hash tables where an entry is removed when the value, not the key, is collected.) Since GHC has (usable) weak pointers, finalisers and hash tables, I could in principle roll my own, but I'd rather get an efficient implementation off someone competent. Oh, and it needs to be under a license that makes it suitable for inclusion in Darcs. Thanks a lot, Juliusz P.S. I am not subscribed to the list -- I'd be grateful if you could CC me with any replies. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] Re: [Haskell-cafe] fptools in darcs now available
>> If I do 'darcs get' to get a bunch of different repositories from >> cvs.haskell.org to my local filesystem, they won't all end up >> hard-linked together, surely? > Not automatically in that case, no. But you could use > darcs optimize --relink to restore them to linked status. Or better yet: Just to be precise, if A, B and C are the repositories, optimally you'd do something like (cd B; darcs optimize --relink --sibling ../C) (cd A; darcs optimize --relink --sibling ../B --sibling ../C) This will link anything that can be linked from C into B, then anything that can be linked from either B or C into A. But you shouldn't worry about being optimal; just call ``optimize --relink'' with all the other likely repositories as siblings, and you'll end up converging to maximal sharing. Optimize --relink is relatively fast, and it should be safe, so nothing prevents you from relinking often (for example, each time you pull a new pool of changes). > 1) Check out the most recent common ancestor > 2) darcs get it n times across the local filesystem (resulting in a > bunch of hardlinked patches) > 3) darcs pull the appropriate repo that you want in each one of them Yes, this will avoid the extra network traffic. However, you should still manually ``optimize --relink'' after doing that, as ``get'' doesn't currently link pristine trees (it only links patches). Juliusz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
