Re: darcs patch: Remove unused import. (and 7 more)

Jason Dagit <dagit <at> codersbase.com> writes:

> On Fri, Jun 26, 2009 at 12:36 AM, Trent W.Buck <trentbuck <at> gmail.com> wrote:
>
>> Hopefully these remove the GHC warnings without breaking anything.
>>
>> [...]
>> Fri Jun 26 16:03:07 EST 2009  Trent W. Buck <trentbuck <at> gmail.com>
>>  * Keep GHC quiet about orphaned typeclass instances in Darcs.Gorsvet.
>>  This should actually be fixed by moving these instances to another
>>  module, because as GHC's user manual says:
>>
>>    The trouble with orphans is that GHC must pro-actively read the
>>    interface files for all orphan modules, just in case their instances
>>    or rules play a role, whether or not the module's interface would
>>    otherwise be of any use. See Section 4.6.12, “Orphan modules and
>>    instance declarations” for details.
>
>
> There was a thread in the last 3 months or so on Haskell-Cafe about
> orphan instances and, in particular, if they cause any problems in
> practice.  I admit I didn't read the thread.  We have them in lots of
> places through out the darcs code.  Personally, I've never really
> understand what it's all about or why I would want to remove them.  As
> far as I know, we've never had problems (read: bugs) because of them.

My reading of the GHC documentation was that it doesn't cause "bugs",
but rather it forces GHC to do more work, or be less parallelized.  My
goal with these patches was to remove (spurious) warnings from the 2.3b2
build.  Since I'm hiding (instead of fixing) what appears to be a

Re: darcs 2.3 beta 1

On 30/06/2009 17:09, Petr Rockai wrote:
> Simon Marlow<marlowsd <at> gmail.com>  writes:
>> I tried this, and it worked!  Nice going.
> Thanks!
>
>> Did a quick comparison between my installed 2.2.0 and 2.3-beta on my laptop,
>> where I'm using hashed repositories.  On a GHC repository with lots of local
>> changes, whatsnew went from 0.26 seconds to 0.22 seconds. On a GHC testsuite
>> repository with zero changes, whatsnew went from 1.1s to 0.06 seconds (cool!).
> Yes, the textual diffing code is basically the same, so as soon as textual diff
> becomes the bottleneck, hashed-storage won't help.
>
>> On this machine with hashed repositories I often suffer from the problem
>> whereby darcs seems to randomly forget about timestamps, causing it to take
>> ages in whatsnew and other operations.  So I take it this problem is partially
>> fixed in 2.3?  Is there any way around it?
> Yes, for whatsnew, this is no longer an issue. The problem of course happens
> whenever darcs needs to diff working copy against pristine: a number of
> commands does this (I have already replaced all such code in darcs-hs, but it's
> not deemed safe enough for the 2.3 release).
>
> The origin of the problem (as far as I can tell) is, that as soon as you have
> more than a single branch of a darcs project, darcs will use hardlinking for
> pristine files. Now because the timestamp feature copies timestamps from
> working copy to the pristine cache, and because the two branches will generally
> have timestamps totally different from each other, these two branches will
> "fight" for the pristine timestamps. The only way I can think of to prevent
> this is not to use hardlinks at all. However, darcs 2.3 will fix the problem
> for at least whatsnew, and 2.4 should fix it for good. (Alas, we may choose to
> make 2.4 sooner than 6 months from 2.3, especially if the code turns out to be

sh on windows

_______________________________________________
darcs-users mailing list
darcs-users <at> darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users

Re: darcs 2.3 beta 1

Simon Marlow <marlowsd <at> gmail.com> writes:

> The User Manual already recommends not hard-linking the pristine - see
> the docs for "darcs optimize", and "Reducing disk space usage" under
> "Getting Started".  So, it seems rather strange that darcs does this
> itself, by default, with no way to disable it!

It is probably referring to the pristine trees of pre-hashed
repositories.

> The user manual suggests that the darcs cache has to be explicitly
> enabled, but as far as I can tell it's on by default.

That's also stale documentation; by default a cache is created in
~/.darcs/cache (%APPDATA%/darcs/cache on Windows).

> How is it disabled?

By creating an empty ~/.darcs/sources file, and by removing any lines
starting with "cache:" from _darcs/prefs/sources of any existing
repositories.

Note that the cache ~/.darcs/cache is only useful for repositories that
share the same filesystem as ~/.darcs/cache is on -- for example, if all
your repositories live in /srv/vcs and that's a separate NFS mount to
/home, then the default cache is totally useless (and probably unused).
You'd want to create /srv/vcs/.cache-twb or something, or maybe make
/srv/vcs/.darcs-cache a world-writable directory with a sticky bit.  I
don't know if that would work, nor if Darcs is susceptible to cache
poisoning attacks.

> Can I strongly suggest that there should be a way to turn off
> hard-linking of pristine files in darcs 2.3, and furthermore that
> having it turned off should be the default.

+1 for that idea.

> I tried to find the manual for 2.3 - is it online anywhere?

It won't be until Petr makes an autoconf-based source release, and a
manual is built from that.  For now, the manual built from HEAD should
be close -- nobody touches the TeX-only parts of the manual much.

(Most of my work so far has been about making what was/is visible in TeX
also visible in "darcs help" and in "man darcs", rewriting and updating
it at the same time.)

As usual, a problem with a specific bit of documentation should be
addressed by filing a bug at bugs <at> darcs.net, either fixing it or
assigning it to me.  You can assign the bug to me when you first report
it by putting "[assignedto=twb]" at the end of the Subject header field.

Re: sh on windows

Jason Dagit <dagit <at> codersbase.com> writes:

> I've lost track of the status of darcs on windows, but as I was just
> setting up a windows box, looking for ways to make it more
> "comfortable" I discovered:
>
> http://sourceforge.net/projects/win-bash/
>
> I haven't tried it (I think I'm going to install and Linux on this
> machine), but I suspect this may provide an sh replacement on windows
> (for running the test suite) that doesn't require all of cygwin or
> msys.
>
> Perhaps this leads to simpler dev environment for our windows hackers?
> Perhaps all you need these days to dev darcs on windows AND run the
> tests these days is a recent ghc the above bash?  Or maybe while I
> wasn't looking it became even easier than that.

You will probably also need POSIX-compliant core utilities -- things
like sed(1).  Perhaps busybox has been ported to Windows' native POSIX.1
implementation?

Re: darcs 2.3 beta 1

Trent W. Buck wrote:
> Note that the cache ~/.darcs/cache is only useful for repositories that
> share the same filesystem as ~/.darcs/cache is on -- for example, if all
> your repositories live in /srv/vcs and that's a separate NFS mount to
> /home, then the default cache is totally useless (and probably unused).
> You'd want to create /srv/vcs/.cache-twb or something, or maybe make
> /srv/vcs/.darcs-cache a world-writable directory with a sticky bit.  I
> don't know if that would work, nor if Darcs is susceptible to cache
> poisoning attacks.

Er... I wouldn't say "totally useless". A cross-filesystem file copy is 
still (in many/most cases) faster/cheaper than a SSH or HTTP download. 
It may not be the most space efficient caching situation, but it would 
still be a cache.

--
--Max Battcher--
http://worldmaker.net

Re: sh on windows

On Jul 1, 2009, at 18:25, trentbuck <at> gmail.com (Trent W. Buck) wrote:

> Jason Dagit <dagit <at> codersbase.com> writes:
>
>> I've lost track of the status of darcs on windows, but as I was just
>> setting up a windows box, looking for ways to make it more
>> "comfortable" I discovered:
>>
>> http://sourceforge.net/projects/win-bash/
>>
>> I haven't tried it (I think I'm going to install and Linux on this
>> machine), but I suspect this may provide an sh replacement on windows
>> (for running the test suite) that doesn't require all of cygwin or
>> msys.
>>
>> Perhaps this leads to simpler dev environment for our windows  
>> hackers?
>> Perhaps all you need these days to dev darcs on windows AND run the
>> tests these days is a recent ghc the above bash?  Or maybe while I
>> wasn't looking it became even easier than that.
>
> You will probably also need POSIX-compliant core utilities -- things
> like sed(1).  Perhaps busybox has been ported to Windows' native  
> POSIX.1
> implementation?
>

I forgot to reply back but, I tried it and I wasn't that impressed. At  
least for interactive use it does not appear to behave correctly on  
vista. I could run some commands and not others.

It may work fine for noninteractive use.  I've never looked for a  
busybox port.

Jason

Re: darcs 2.3 beta 1

On Wed, Jul 01, 2009 at 11:13:26PM -0400, Max Battcher wrote:
> Trent W. Buck wrote:
>> Note that the cache ~/.darcs/cache is only useful for repositories that
>> share the same filesystem as ~/.darcs/cache is on -- for example, if all
>> your repositories live in /srv/vcs and that's a separate NFS mount to
>> /home, then the default cache is totally useless (and probably unused).
>> You'd want to create /srv/vcs/.cache-twb or something, or maybe make
>> /srv/vcs/.darcs-cache a world-writable directory with a sticky bit.  I
>> don't know if that would work, nor if Darcs is susceptible to cache
>> poisoning attacks.
>
> Er... I wouldn't say "totally useless". A cross-filesystem file copy is  
> still (in many/most cases) faster/cheaper than a SSH or HTTP download.  
> It may not be the most space efficient caching situation, but it would  
> still be a cache.

You're right; I withdraw the remark in question.

failure in issue1248.sh

Hi,

In the 2.3 release branch and on HEAD, issue1248.sh fails for me, on a 
Debian lenny box (which is GHC 6.8.2, with some patch applied IIRC). I 
configured -fzlib (though I think that is now the default anyway, at least 
on the release branch).

The failure isn't actually related to what the test is checking for, but 
rather it happens in a call to darcs optimize --reorder, with the 
following error:

darcs: _darcs/patches/pending.new-0: openBinaryFile: resource busy (file 
is locked)

It seems to be triggered by the following patch:

Wed Jun  3 21:37:02 BST 2009  Petr Rockai <me <at> mornfall.net>
   * Fix index invalidation in the move command.
   Ignore-this: e2fa46552a1ac28aea587c96c0932298

Thorkil was unable to reproduce the problem on a couple of other machines 
with different GHCs etc, so it would be good to know if anyone else is 
seeing this.

Cheers,

Ganesh

darcs patch: add option to limit gzcrc check/repair t... (and 6 more)

Mon Jun 29 18:26:32 BST 2009  Ganesh Sittampalam <ganesh <at> earth.li>
  * add option to limit gzcrc check/repair to current repo

Thu Jun 25 22:17:26 BST 2009  Ganesh Sittampalam <ganesh <at> earth.li>
  * improve wording of help text
  Ignore-this: b5ad695140d32c531bb57c8ca3d4e80c

Tue Jun 30 06:09:50 BST 2009  Ganesh Sittampalam <ganesh <at> earth.li>
  * make gzDecompress just return a flag to report corruption
  This interface is simpler to understand (especially in terms of strictness 
  properties) than the previous one that was overloaded over a monad.

Tue Jun 30 06:26:24 BST 2009  Ganesh Sittampalam <ganesh <at> earth.li>
  * further gzcrcs docs updates

Wed Jul  1 22:04:26 BST 2009  Ganesh Sittampalam <ganesh <at> earth.li>
  * add a comment to gzDecompress

Thu Jul  2 15:14:25 BST 2009  Ganesh Sittampalam <ganesh <at> earth.li>
  * Remove unnecessary pattern signature (it's not H98)

Thu Jul  2 21:41:40 BST 2009  Ganesh Sittampalam <ganesh <at> earth.li>
  * fix (fairly harmless) bug in test script

_______________________________________________
darcs-users mailing list
darcs-users <at> darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users