gmane.comp.version-control.darcs.devel

trouble with type witnesses

Michael Hendricks — 2012-05-18T22:14:20

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'

Cron darcs>~/bin/darcs-missing-screened

Cron Daemon — 2012-05-13T07:00:01

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:

how can Darcs dev be more agile ?

Simon Michael — 2012-05-10T15:15:31

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:

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

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

Matthias Kilian — 2012-05-02T15:36:00

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

unicode handling

Ganesh Sittampalam — 2012-04-13T06:55:35

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

GHC 6.10.and 6.12 dropped from HEAD

Ganesh Sittampalam — 2012-04-01T14:55:46

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

Haddock and Code-Style Policies

Owen Stephens — 2012-03-02T15:21:26

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

FilePaths

Andreas Brandt — 2012-02-18T23:22:25

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

licensing

Will Langstroth — 2012-01-30T02:50:14

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

open source licenses

Will Langstroth — 2012-01-26T19:01:47

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

darcs style

Will Langstroth — 2012-01-23T04:12:41

Hi all,

Wondering if you're accepting "janitorial" patches. If you've seen Johan
Tibell's Haskell Style
Guide<https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md>,
and it seems reasonable, I'd be happy to have a go at making darcs stick to
that one style (or one comparable) for easier reading. I'm just getting
into the code, and the existing style is eclectic enough to be distracting.

Not sure where that fits in the bug tracker workflow, either - since these
types of changes are strictly formatting, would an email patch be
sufficient?

Thanks,
Will
_______________________________________________
darcs-devel mailing list
darcs-devel< at >darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel

minor BTS update

Eric Kow — 2012-01-06T19:10:33

At the risk of creating processing churn, I've updated the BTS by replacing the status "need-action" with something I hope is easier to use:

- need-reproduction
- need-testcase
- need-design
- need-implementation [same as before]

The hope is for these to be more self-explanatory, and also more clear cut.  I want to cut down on things being left "unknown" for lack of clarity, and also for people using "need-action" to mean "somebody, please do something!" (which is understandable)

This means we now have a bunch of bugs which are pessimistically set to need-reproduction (formerly need-action)

Thanks,

PS: need-action was from when I was trying to be the issue manager, and wanting to see if a GTD-based workflow would work.  I still think fairly rigid buckets are a good idea, but using obscure GTD jargon was a recipe for disaster.  Oh well.

minor BTS update

Eric Kow — 2012-01-06T19:10:33

At the risk of creating processing churn, I've updated the BTS by replacing the status "need-action" with something I hope is easier to use:

- need-reproduction
- need-testcase
- need-design
- need-implementation [same as before]

The hope is for these to be more self-explanatory, and also more clear cut.  I want to cut down on things being left "unknown" for lack of clarity, and also for people using "need-action" to mean "somebody, please do something!" (which is understandable)

This means we now have a bunch of bugs which are pessimistically set to need-reproduction (formerly need-action)

Thanks,

PS: need-action was from when I was trying to be the issue manager, and wanting to see if a GTD-based workflow would work.  I still think fairly rigid buckets are a good idea, but using obscure GTD jargon was a recipe for disaster.  Oh well.

minor BTS update

Eric Kow — 2012-01-06T19:10:33

At the risk of creating processing churn, I've updated the BTS by replacing the status "need-action" with something I hope is easier to use:

- need-reproduction
- need-testcase
- need-design
- need-implementation [same as before]

The hope is for these to be more self-explanatory, and also more clear cut.  I want to cut down on things being left "unknown" for lack of clarity, and also for people using "need-action" to mean "somebody, please do something!" (which is understandable)

This means we now have a bunch of bugs which are pessimistically set to need-reproduction (formerly need-action)

Thanks,

PS: need-action was from when I was trying to be the issue manager, and wanting to see if a GTD-based workflow would work.  I still think fairly rigid buckets are a good idea, but using obscure GTD jargon was a recipe for disaster.  Oh well.

darcs-announce

Eric Kow — 2011-11-23T13:15:58

Here's my thinking on darcs-announce

1. Context is that it would provide a super-low traffic way for people to follow darcs.  It's an alternative to being completely in the dark

2. Implementation would likely be just: ask osuosl to create it

3. Now a selfish comment :-(

I'd be a bit annoyed about adding a 4th list to moderate for spam (we now have bugs, devel, users).  I don't really want to push this to anybody else (as in "I'll create the list if somebody wants to take over moderation").  Would prefer a better or more creative solution.

Yes, there is the command line mailman tool, but it's sort of a pain to use because you have to sit wade through it, answering yes/no to each individual likely spam.  If the universe were to write me a tool that combines the at-a-glance one-shot-response of the mailman web interface with the mailing list aggregation of the mailman script, I'd be more enthusiastic.

Sorry, I realise this is rather small-minded thinking on my part.  Ideas?

review team: please screen your own patches!

Ganesh Sittampalam — 2011-08-13T14:32:22

Hi,

I'd like to remind the review team that they really should be pushing
their own patches to screened promptly, otherwise much of the point of
screened is lost.

Currently the following patches seem to be in this state:

http://bugs.darcs.net/patch629
http://bugs.darcs.net/patch630
http://bugs.darcs.net/patch631
http://bugs.darcs.net/patch632
http://bugs.darcs.net/patch635

If you're not sure it's ready, use "in-discussion". If you don't get any
comment after a bit then you just have to use your own discretion as to
whether to push it or keep poking people for comment.

Going through patches to figure out what should be applied is a pain in
the neck, particularly where there've been multiple updates. The
original submitter really ought to be in the best position to know what
to apply. Patches by the review team are often more complex than most
and therefore particular prone to this.

Cheers,

Ganesh

Darcs course-work report

Iago Abal — 2011-08-08T15:34:35

Hi,

The report about the job I have done about Darcs quality (some months
ago...) is online here
http://sites.google.com/site/iagoabal/projects/mfes_darcs.pdf , I'm sending
it to you because I don't know exactly where it should be in the Darcs wiki
(well, I guess it could be placed in the Darcs Sprint page). I was asked for
the slides but I think the report is much better than the slides, but if the
slides are important for some reason then please say me (in such a case I
would like to polish them before).

By the way, I am waiting for some response about how we should name of
test-suite modules.

Just some remark, I think we should adopt some convention to name test-suite


As usual nobody answers (...) so I am still waiting :P. I was and I am still
under a pretty big workload so I won't contribute significantly to Darcs in
the next months, but I would like to contribute doing some boring testing
job (as I planned).

Cheers,

wrong status on bug tracker

Ganesh Sittampalam — 2011-05-09T05:34:37

Hi,

FYI the bug tracker is getting some patches incorrectly marked as
"accepted" at the moment because darcswatch doesn't know about the
reviewed/screened changes. I'm going through and manually fixing
statuses at the moment.

Ganesh

HEADS UP! screened/reviewed changeover

Eric Kow — 2011-05-08T10:15:19

Hi all,

As agreed during 2011-04 Darcs Hacking Sprint, we are now using a
simplified workflow with a stronger emphasis on the screened branch.

 http://blog.darcs.net/2011/04/darcs-hacking-sprint-6-report.html

This should not change very much for users, except that darcs.net
is now a tiny bit more bleeding edge.

What's changed:

1. Core Team Members: when pushing reviewed patches, you may
   need to

     darcs push --set-default darcs-unstable< at >darcs.net:reviewed

   because your repository most likely now points to the screened
   branch

2. darcs get http://darcs.net now fetches the screened branch
   It points to the same location as http://darcs.net/screened

   The same is true for the darcs symlink on darcs.net

3. The reviewed branch now lives at http://darcs.net/reviewed

4. The workflow is simpler (screened => reviewed => release).
   Previously, use of the screened branch was optional.

Reminders:

5. Patches to the screened branch have only been subjected to
   very light review, just screening out obviously crazy things.
   Core Team members also typically push their code directly
   on to screened.

6. You can only amend a patch until it has been screened.
   http://wiki.darcs.net/Development/FAQ#can-i-amend-a-patch-i-sent-to-the-tracker

I've attempted to document our current workflow at
http://wiki.darcs.net/Development/PatchReview

Let me know if you have any questions or if you notice anything
going wrong in the switchover.

Thanks!

Darcs.Utils.breakCommand

Iago Abal — 2011-04-06T16:55:57

When writing tests for Darcs.Utils I see



breakCommand s = case words s of

                   (arg0:args) -> (arg0,args)

                   [] -> (s,[])


and now I wonder if it should not be defined as

breakCommand :: String -> (String, [String])

breakCommand s = case words s of

                   (arg0:args) -> (arg0,args)

                   [] -> bug "..."


?

AFAIK 'words' only returns "" for the input "", so the command "" seems to
be something unexpected.

Cron darcs>~/bin/darcs-missing-screened

Cron Daemon — 2011-03-24T07:00:02

MISSING PATCHES WARNING
-----------------------
 
The following patches are in unstable but missing from screened:

Sun Mar 13 17:31:10 PDT 2011  Ganesh Sittampalam <ganesh< at >earth.li>
  * update website for 2.5.2

Making no changes:  this is a dry run.