headers
Michael Hendricks | 19 May 00:14
Gravatar

trouble with type witnesses

I'm playing with a new --reduce-context option for send and obliterate
which commutes the target patch(es) to reduce the number of 
irrelevant patches in the context.

I've spent about 8 hours across two days trying different variations
to placate the type witnesses, but can't seem to get it working.
The third patch below is the important one.

Any pointers on what I'm doing wrong?

Thanks.

Thu Apr 26 16:32:40 MDT 2012  Michael Hendricks <michael <at> ndrix.org>
  * draft: notes about obliterate --reduce-context

Fri May  4 14:39:54 MDT 2012  Michael Hendricks <michael <at> ndrix.org>
  * draft: tidy some bundle-related Haddock

Fri May 18 16:05:47 MDT 2012  Michael Hendricks <michael <at> ndrix.org>
  * draft: working on 'obliterate --reduce-context'

--

-- 
Michael
Attachment (patch-preview.txt): text/x-darcs-patch, 5595 bytes
Attachment (draft_-notes-about-obliterate-__reduce_context.dpatch): application/x-darcs-patch, 7578 bytes
_______________________________________________
darcs-devel mailing list
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cron Daemon | 13 May 09:00
Favicon

Cron <darcs-unstable <at> darcs> ~/bin/darcs-missing-screened


darcs failed:  Not a repository: /home/darcs-unstable/darcs
(/home/darcs-unstable/darcs/_darcs/inventory does not exist)

HINT: Do you have the right URI for the repository?

      If so, check with the repository owner to see if the following files
      are readable:

        1. _darcs/format    - might not exist; that's OK
        2. _darcs/inventory - should exist if #1 is missing
        3. _darcs/hashed_inventory - should exist if #2 is missing

MISSING PATCHES WARNING
-----------------------

The following patches are in unstable but missing from screened:
Permalink | Reply | 0 comments |
headers
Simon Michael | 10 May 17:15

how can Darcs dev be more agile ?

I'm forwarding this to -devel for wider comment. I think contributing to Darcs is harder and less inviting than it need be. Do you agree ? Any ideas about things we could do to update our process ?


Begin forwarded message:
From: Simon Michael <simon <at> joyful.com>
Subject: Re: join the darcs team?
Date: May 8, 2012 6:47:07 AM PDT

By the way I wonder if it would be wise to keep going and open up/loosen up/democratise the Darcs Team further ? With you two busy, and noone else obviously on the team, it has felt a bit closed/declining/anti-contributory. I know code review is important for Darcs and we still need that in some form. Feel free to reply on list if you prefer.

Thanks for your service guys,
-Simon

On May 8, 2012, at 6:37 AM, Simon Michael wrote:
Hi Eric. Thanks for asking. I'd be glad to, if that's the best way to facilitate the process. Ganesh also mentioned splitting off the site repo as a possibility.

On May 8, 2012, at 12:22 AM, Eric Kow wrote:
Thanks for your work on the darcs homepage, Simon.

Would you consider just up and joining the Darcs core team so you can make changes directly?

The idea is that you'd focus on patches to doc, and perhaps gradually expand your “remit”/comfort zone over time

_______________________________________________
darcs-devel mailing list
darcs-devel <at> darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
Permalink | Reply | 14 comments |
headers
Matthias Kilian | 2 May 17:36
Picon

darcs-2.8.0: tests "issue121" and "ask_deps" failing

Hi,

do the two tests mentioned in the subject succeed for other people?

when running the tests on OpenBSD, they fail with darcs-2.8.0 but
succeed with darcs-2.5.2 (built on exactly the same system with
exactly the same haskell libraries installed).

Test output below.

Is this a known regression? I'm using ghc-7.0.4 and the following
relevant libraries:

HUnit-1.2.4.2
binary-0.5.0.2
dataenc-0.13.0.4
deepseq-1.1.0.2
ghc-paths-0.1.0.8
hashed-storage-0.5.9
haskeline-0.6.4.0
html-1.0.1.2
mmap-0.5.6
mtl-2.0.1.0
parsec-3.1.1
regex-base-0.93.2
regex-compat-0.95.1
regex-posix-0.95.1
tar-0.3.1.0
terminfo-0.3.1.3
text-0.11.1.5
transformers-0.2.2.0
zlib-0.5.3.1

Running issue121.sh manually, with the grep pipe in the last command
commented out (to see the actual output), I get the following output:

rm -rf R
+ rm -rf R
darcs init      --repo R        # Create our test repos.
+ darcs init --repo R

cd R
+ cd R
touch a
+ touch a
darcs add a
+ darcs add a
darcs rec --ignore-times -am 'add a'
+ darcs rec --ignore-times -am 'add a'
Finished recording patch 'add a'
(echo '1' ; echo '1' ; echo '1') > a
+ echo 1
+ echo 1
+ echo 1
darcs rec --ignore-times -am 'patch X'
+ darcs rec --ignore-times -am 'patch X'
Finished recording patch 'patch X'
(echo '2' ; echo '1' ; echo '1') > a
+ echo 2
+ echo 1
+ echo 1
darcs rec --ignore-times -am 'patch Y'
+ darcs rec --ignore-times -am 'patch Y'
Finished recording patch 'patch Y'
(echo '2' ; echo '1' ; echo '2') > a
+ echo 2
+ echo 1
+ echo 2
darcs rec --ignore-times -am 'patch Z'
+ darcs rec --ignore-times -am 'patch Z'
Finished recording patch 'patch Z'

darcs obliterate --dry-run --patch 'patch Y' | not grep 'patch Z'
+ darcs obliterate --dry-run --patch 'patch Y'
+ not grep 'patch Z'
+ grep 'patch Z'
+ :

echo 'yy' | darcs amend-rec --ask-deps
+ echo yy
+ darcs amend-rec --ask-deps
Wed May  2 17:23:53 CEST 2012  tester
  * patch Z
Shall I amend this patch? [yNjk...], or ? for more options: Wed May  2
17:23:53 CEST 2012  tester
  * patch Y
Shall I depend on this patch? (1/1)  [ynW...], or ? for more options:
Finished amending patch:
Wed May  2 17:23:53 CEST 2012  tester
  * patch Z

darcs obliterate --dry-run --patch 'patch Y' # | grep 'patch Z'
+ darcs obliterate --dry-run --patch 'patch Y'
Would obliterate the following changes:
Wed May  2 17:23:53 CEST 2012  tester
  * patch Y

Making no changes:  this is a dry run.

And running ask_deps.sh produces this output:

rm -rf temp
mkdir temp
cd temp

darcs init
cat > _darcs/prefs/defaults <<.
ALL author test
ALL ignore-times
ALL ask-deps
.

# add three depending patches for file 'a'
# expect no dependency questions
# 'q' will abort and cause future failure if an unexpected dependency is
asked
touch a
darcs add a
echo q | darcs rec -am a0
Finished recording patch 'a0'
darcs ann -p a0
[a0
test**20120502152756
 Ignore-this: 867d991fe5680642e5df90b7db297f5
] addfile ./a
echo 1 > a
echo q | darcs rec -am a1
Finished recording patch 'a1'
darcs ann -p a1
[a1
test**20120502152756
 Ignore-this: 5c1048c1abdf795965e3706a3d0e9073
] hunk ./a 1
+1
echo 2 > a
echo q | darcs rec -am a2
Finished recording patch 'a2'
darcs ann -p a2
[a2
test**20120502152757
 Ignore-this: 83c33eb96558b18d2afb727ac385c772
] hunk ./a 1
-1
+2

# add some patches for file 'b'
# expect no dependency questions for file 'b',
# but every time expect questions for the three patches of file 'a'
# every 'n' should continue to ask about the next patch
# the first 'y' should make all following dependencies of 'a' implicit
and stop asking
# 'q' will abort and cause future failure if an unexpected dependency is
asked
touch b
darcs add b
# test 0
echo n/n/n/q | tr / \\012 | darcs rec -am b0
Wed May  2 17:27:57 CEST 2012  test
  * a2
Shall I depend on this patch? (1/3)  [ynW...], or ? for more options:
Wed May  2 17:27:56 CEST 2012  test
  * a1
Shall I depend on this patch? (2/3)  [ynW...], or ? for more options:
Wed May  2 17:27:56 CEST 2012  test
  * a0
Shall I depend on this patch? (3/3)  [ynW...], or ? for more options:
Finished recording patch 'b0'
darcs ann -p b0
darcs: Couldn't find patch matching "patch-name b0"

Ciao,
	Kili
Permalink | Reply | 0 comments |
headers
Ganesh Sittampalam | 13 Apr 08:55
Picon
Gravatar

unicode handling

Hi,

After quite a bit of digging, I discovered there was a simple workaround
for the GHC and unicode filenames problem that's been blocking correct
behaviour on GHC 7.4 on Unix. (http://bugs.darcs.net/patch777)

However, this still has some problems:
 - Filenames with Unicode codepoints >= 256 were previously broken on
Windows and they still are
 - It involves setting GHC-wide global variables, which may be a problem
for library users

I'm still not really sure what the "right" solution to this problem is.

Here follows a general braindump, since I will likely forget about all
this now the immediate problem is sorted :-)

The hashed-storage index relies on mmapping ByteStrings in the on-disk
file via Data.ByteString.Internal.fromForeignPtr and then passing it to
stat via Data.ByteString.Unsafe.unsafeUseAsCString. This code path is
supposed to be fast; it supports quick darcs record/whatsnew, because
the index maps last modified time to a content hash, allowing any file
which hasn't changed since the last index update to be compared with
pristine without actually reading the file.

Independently of any language implementation/library, using ByteString
or an equivalent representation is the right thing to do on POSIX
systems where the raw OS API indeed uses just a string of bytes.

However on Windows, the raw OS APIs give UTF16. Currently hashed-storage
truncates this to 8 bits on read to stuff it into a ByteString, hence
the above-mentioned bug with codepoints >= 256. One alternative would be
to explode the UTF16 into a ByteString using two bytes per character,
although I'm not sure if there's a good API for doing that translation
fast (though at the moment we go via String even on the Unix side, so it
can't really get worse).

Right now hashed-storage mostly gets paths from the OS as String,
converts to ByteString and then converts back to String when calling the
OS again. I think darcs itself is similar, although patches themselves
store paths as String. The Printer code stores things as either String
or ByteString, or in a few cases both at once (I think this is just for
constant strings like punctuation).

This is all a bit of a mess :-) Pushing some newtypes into the code
seems like a natural first step to clarifying representations and intent.

Ganesh
Permalink | Reply | 0 comments |
headers
Ganesh Sittampalam | 1 Apr 16:55
Picon
Gravatar

GHC 6.10.and 6.12 dropped from HEAD

Hi,

Following the rules in
http://wiki.darcs.net/Development/Policy#ghc-versions, I have dropped
support for GHC 6.10 and 6.12 from darcs HEAD - i.e. the screened repo,
and thus later the reviewed repo.

The 2.8 branch will continue to support these versions.

By the time 2.10 is ready, GHC 7.4 should be in a released Haskell
Platform and that a new Debian stable should have released with a newer
GHC, keeping us in compliance with the policy. If this doesn't
materialise we might have to think about what to do, but I think it's
unlikely.

Note that GHC 7.2 is only supported on Windows because of Unicode issues
on Linux/MacOSX; now that 7.4 is out I would recommend against using 7.2
for anything.

Ganesh
Permalink | Reply | 0 comments |
headers
Eric Kow | 30 Mar 19:11
Favicon

[issue1806] better error message when just posthook fails


Eric Kow <kowey <at> darcs.net> added the comment:

Also, the error message is wrong when it says things like

change sent successfully
./my-fun-posthook: line 6: hlint: command not found
Posthook failed!
Finished applying...
Command not found:
   ["ssh","foo <at> example.com","darcs apply --all  --repodir 'blah'"]
Apply failed!

I don't know if this should be a separate issue.  Diagnosis:

17:56:08 - kowey: well, it's coming from Darcs.External
17:56:41 - kowey: in both cases from exit 127 from a pipeDoc
17:57:09 - kowey: so Darcs.RemoteApply uses pipeDoc
17:57:34 - kowey: pipeDocSSH repo [Ssh.remoteDarcs (remoteDarcs opts) ++" 
apply --all "++unwords (applyopts opts)+
17:58:03 - kowey: huh, but exit 127?

Ganesh also mentions there's some Linux/Windows mess scattered throughout 
relating to exit127.

Hmm, this may be sprawling a bit out of the ProbablyEasy range

----------
nosy: +mndrix -darcs-devel

__________________________________
Darcs bug tracker <bugs <at> darcs.net>
<http://bugs.darcs.net/issue1806>
__________________________________
Permalink | Reply | 0 comments |
headers
Owen Stephens | 2 Mar 16:21
Picon

Haddock and Code-Style Policies

Hello (would-be-)developers of Darcs!

A recent discussion has taken place [1] on #darcs, on the subject of
Haddock; ...no, not the fish, but comments!

We'd like to introduce a Darcs policy that requires patches to include haddock
whenever they make significant changes to a piece of code, or wherever the
intent of a function is not obvious.

Some guiding principles:

* If you've written it - Haddock it!
* If you've read it and understood it - Haddock it!
* If you've read it and can't understand it - Haddock it, with a question!
* If you're working in an area of code, ensure it ends up Haddock'd!

What makes something “significant” or “obvious”?  I'd hope to take a
common-sense approach here:

"significant" - if you're adding a new class constraint, then you shouldn't be
                expected to haddock every function that you touch. Similarly
                with typos/small changes - we don't want the effort of
                understanding/haddocking to dominate the effort of a small
                clean-up patch.

"obvious" - Igloo made a good point: we shouldn't require haddock everywhere,
            else we face the prevalence of "tin" comments (as in, "does what it
            says on the tin"), these are pointless and a waste of time. E.g. a
            comment on an isConflictor function probably isn't necessary, but
            use common sense - is the function's meaning/purpose intuitive?

Personally, I've recently been fighting with the Conflictor implementation and
the lack of descriptive/intuitive haddocks has really been holding me back.

As a good example of what I'm striving for, consider commuteNoConflicts [3],
it's haddock tells us what it does, but more importantly *why*, giving us the
intuition of the function's behaviour.

We have also discussed the use of an established-by-the-community Haskell
style-guide, such as that of tibbe [2]. I feel it'd be easy to adopt this as
policy, and provide easy tasks for beginners to get into the code (for example,
ensuring that import lists are correctly sorted, that modules build without
warnings etc.).

I feel that adopting these guidelines, we can help bring Darcs in line with
what is expected of a modern community-developed Haskell project. That said,
there are many people with much more experience of these things on this list -
I'd really like to collect comments/objections, so please come forth and reply!

Cheers,
Owen.

[1] http://irclog.perlgeek.de/darcs/2012-03-02#i_5234478
[2] https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md
[3] http://darcs.net/api-doc/Darcs-Patch-Conflict.html#v:commuteNoConflicts

_______________________________________________
darcs-devel mailing list
darcs-devel <at> darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
Permalink | Reply | 2 comments |
headers
Andreas Brandt | 19 Feb 00:22

FilePaths

Hi all,

i'm still not sure how to handle FilePaths correctly.
Today i encountered code like this:
     df = darcsdir++"/format"
     repo ++ "/" ++ df
     repo++"/"++darcsdir++"/inventory"

Usually i would import System.FilePath and use </> instead of the string 
stuff.
I already learned that in Darcs, System.FilePath.Posix is used instead 
for... historical reasons?

But somebody also mentioned that there has been work done (by mornfall i 
think) to make the switch off *.Posix. What is this work and can i help 
to make the transition?

What is the right thing to do when seeing code like above?

Thanks,
Andreas
Permalink | Reply | 1 comment |
headers
Will Langstroth | 30 Jan 03:50

licensing

Hi all,


Sorry if I didn't notice it, or someone tried to mention it and I didn't understand what they were saying, but I found the licensing notes in the release directory. I'll try my best to follow everyone's wishes while doing my little reformatting. Also sorry if I gave the impression that I had some ulterior motive in pushing for a simpler license set-up. Permissive licenses are easier to deal with, that's all.

Thanks to everyone who was kind enough to try and help me understand what was going on.

Will
_______________________________________________
darcs-devel mailing list
darcs-devel <at> darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
Permalink | Reply | 3 comments |
headers
Will Langstroth | 26 Jan 20:01

open source licenses

Hi Professor Roundy,


I've just started getting into the darcs source, with the hope of being able to organize it to work with Haddock automated documentation. In the process, I've learned that some of the darcs developers have a preference for the BSD3 license over the GPL. Stephen Turnbull was kind enough to outline the perils built in to the GPL, which led me to wonder: would you consider switching the license on your code to the BSD3, or another more permissive license?

To make any change, I know I would have to contact more people, but you're the original author. My motivation is simply to clean up the darcs code base, and have more flexibility in my ability to do so.

Thanks,

Will
_______________________________________________
darcs-devel mailing list
darcs-devel <at> darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
Permalink | Reply | 0 comments |

Gmane