darcs switchover
Hi Folks, As you probably know, there is a mirror of the GHC source tree in a darcs repository. (information about accessing the darcs repository is here: http://cvs.haskell.org/trac/ghc/wiki/GhcDarcs). The aim is to eventually switch over to using darcs for our revision control. The point of this message is to find out what constraints people have that will affect when we can throw the switch. It doesn't look like we'll be able to keep a CVS mirror going once we switch to darcs, so darcs will be the only way to get an up-to-date GHC source tree. How will it affect you? - If you just get the GHC sources from anonymous cvs, then you have to switch to getting sources using darcs. It's pretty simple. - If you are a developer, then you need to: (a) get sources from darcs, and (b) use 'darcs push' instead of 'cvs commit'. - You won't be able to browse the CVS repository via cvsweb any more. You can browse the contents of the darcs repository directly, and we hope to set up some kind of darcs-aware browsing too. We've switched some of our nightly builds over to using darcs, and it seems to be working nicely. darcs get --partial can actually get the sources quicker than anonymous CVS used to. Please let me know if the switchover is going to adversely affect your life, so that we can formulate a plan and timescale for switching over. Malcolm, Ross - since you both also use the CVS libraries tree, is it going to be possible for you to switch to using darcs to get the libraries? Any idea how long you'll need? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
Simon Marlow [EMAIL PROTECTED] writes: Malcolm, Ross - since you both also use the CVS libraries tree, is it going to be possible for you to switch to using darcs to get the libraries? Any idea how long you'll need? I've been looking at the cvs configuration file CVSROOT/modules. I /think/ the procedure is something like changing this: nhc98src-d nhc98 nhc98 nhc98libraries -d nhc98/src/libraries fptools/libraries nhc98 -a nhc98src nhc98libraries to this: nhc98src-d nhc98 nhc98 nhc98libraries -o darcs get --reponame=nhc98/src/libraries \ http://cvs.haskell.org/darcs/libraries nhc98 -a nhc98src nhc98libraries and then a fresh cvs checkout of the nhc98 would be required in order to pick up the new location. Has anyone else tried this kind of tweak before and confirm that it is likely to work? If not, I might test it out with the smaller cpphs module initially. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Preparing a Registered hc-file-bundle (Was BootstrappingwithHCfiles)
On 15 December 2005 16:19, Andrew Walrond wrote: Hi Simon, On Wednesday 14 December 2005 09:49, Simon Marlow wrote: Actually, looking at ghc/Makefile, it is possible that ghc/lib isn't getting built early enough. Try changing: SUBDIRS = includes rts docs compiler lib utils driver to SUBDIRS = includes rts lib docs compiler utils driver Did that. Now I get to here: ===fptools== Recursively making `all' in compat ... PWD = /home/andrew/test/ghc/bs/target/ghc-6.4.1/ghc/lib ==fptools== make all - --no-print-directory -r; in /home/andrew/test/ghc/bs/target/ghc-6.4.1/ghc/lib/compat make[2]: *** No rule to make target `Compat/Directory.o', needed by `ghccompat.o'. Stop. make[1]: *** [all] Error 1 make: *** [all] Error 1 make: Leaving directory `/home/andrew/test/ghc/bs/target/ghc-6.4.1/ghc' Any clues how to proceed? I have no idea what has gone wrong here. We ought to be able to make Compat/Directory.o. However, we don't need ghccompat.o, so you could try adding: GhcWithInterpter=NO to ghc/lib/compat/Makefile, right after the NO_INSTALL_LIBRARY setting. If that doesn't work, please run 'make -p -d' in ghc/lib/compat and send me the output. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: utf8 strings: memory optimization and case-ignoring comparision
Hello Simon, Thursday, December 15, 2005, 12:44:35 PM, you wrote: 2. what is the most memory-efficient representaion for such strings? data UArray i e = UArray !i !i ByteArray# SM I don't know why an extra 8/16 bytes per string is that worrying - if SM you have so many small strings perhaps you should be sharing them via a SM hash table? i also use hash table in another part of program, but in this list (it's a basenames of files on disk) 70% of strings are unique SM ForeignPtr and mallocForeignPtr are the way to go these days. In GHC SM 6.6 these will be much faster than before. can you please say what is a representation of ForeignPtr in 6.6? GHC 6.4.1 uses PinnedByteArray. as far as i can understand, there is only two alternatives - either use pinned arrays and have access to C functions which needs address of memory area, or use unpinned ByteArray and do all processing in Haskell? how pinned byte arrays work with garbage collector? are they allocated in special memory blocks so they don't alternate with movable data? can the memory, used by these arrays, be deallocated and then used again? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
