diff manual

[Ben Goodrich]

I guess the diffed manual never got compiled for v1.0.3. I have (as of 69b3db9b006f5d70b3ea147181e8deac4dff20a3) started putting the patch necessary to fix whatever LaTeX errors STAN_HOME/src/docs/stan-reference/diff.sh induces into the STAN_HOME/src/docs/stan-reference/diff_patches directory instead of attaching them to the list. So, now anyone with git, grep, sed, and bash should be able to do from STAN_HOME

./diff_manual.sh v1.0.3. v1.1.0

and upload the manual. I would except I don't have the special fonts so some things look weird and the page numbers are off relative to the plain manual.

Ben

[Bob Carpenter]

Here's what I get:

On 12/18/12 5:54 PM, Ben Goodrich wrote:
> I guess the diffed manual never got compiled for v1.0.3. I have (as of 69b3db9b006f5d70b3ea147181e8deac4dff20a3) started
> putting the patch necessary to fix whatever LaTeX errors STAN_HOME/src/docs/stan-reference/diff.sh induces into the
> STAN_HOME/src/docs/stan-reference/diff_patches directory instead of attaching them to the list. So, now anyone with git,
> grep, sed, and bash should be able to do from STAN_HOME
>
> |
> ./diff_manual.sh v1.0.3. v1.1.0

With the "." after 3 I get all sorts of errors, starting
with:

~/stan>./diff_manual.sh v1.0.3. v1.1.0
fatal: ambiguous argument 'v1.0.3.': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions


Removing the period, I get this:

~/stan>./diff_manual.sh v1.0.3 v1.1.0
Processing additions to abstract.tex
Processing additions to acknowledgements.tex
sed: 1: "acknowledgements.tex": command a expects \ followed by text
Diffing failed, aborting
HEAD is now at 1f6ac49 add diff_manual.sh
Already on 'master'

It also created two files:

~/stan>git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# src/docs/stan-reference/additions.sh
# src/docs/stan-reference/search.txt

- Bob

[Ben Goodrich]

On Tuesday, December 18, 2012 8:18:17 PM UTC-5, Bob Carpenter wrote:

Here's what I get:

With the "." after 3 I get all sorts of errors, starting
with:

That was a typo, it is supposed to be without the intermediate ".".

Removing the period, I get this:

   ~/stan>./diff_manual.sh v1.0.3 v1.1.0
   Processing additions to abstract.tex
   Processing additions to acknowledgements.tex
   sed: 1: "acknowledgements.tex": command a expects \ followed by text
   Diffing failed, aborting
   HEAD is now at 1f6ac49 add diff_manual.sh
   Already on 'master'

What is

sed --version

for you?
 

It also created two files:

   ~/stan>git status
   # On branch master
   # Untracked files:
   #   (use "git add <file>..." to include in what will be committed)
   #
   #        src/docs/stan-reference/additions.sh
   #        src/docs/stan-reference/search.txt

You can delete those. The script deletes them if it goes all the way through to completion.

Ben
 

[Bob Carpenter]

On 12/18/12 8:42 PM, Ben Goodrich wrote:

>
> What is
>
> |
> sed --version
> |
>
> for you?

Not to be a comedian, but

~/stan>sed --version
sed: illegal option -- -
usage: sed script [-Ealn] [-i extension] [file ...]
sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]
~/stan>sed -version
sed: illegal option -- v
usage: sed script [-Ealn] [-i extension] [file ...]
sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]

I did "man sed" and don't see a version number, but
a web search seems to indicate it's an old one.

- Bob

[Ben Goodrich]

Nevermind, your sed works differently than mine anyway; FYI:

http://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-and-linux

I now use a tempfile rather in-place. Try ./diff_manual.sh v1.0.3 v1.1.0 again after a git pull.

Ben

[Bob Carpenter]

Better, but still doesn't succeed here.

I'm attaching the output temp.txt from:

-----------------------------
~/stan> ./diff_manual.sh v1.0.3 v1.1.0 > temp.txt

sed: 1: "stan-reference.tex": unterminated substitute in regular expression
Already on 'master'
~/stan>
-------------------------------

- Bob

[Ben Goodrich]

Okay, it got 99% of the way there before it ran into a leftover sed -i. Pull and take three.

Ben

[Bob Carpenter]

It ran after the most recent pull, but there
seem to be a lot of false negatives on the markup.

Ben -- did you want me to send you a copy of
the new manual? Or do you think we should use that
one instead of the un-annotated one? Now that the
annotations are relatively unintrusive, I wouldn't
mind making this the regular manual.

- Bob

On 12/19/12 12:36 AM, Ben Goodrich wrote:
> ./diff_manual.sh v1.0.3 v1.1.0

[Ben Goodrich]

On Thursday, December 20, 2012 2:53:54 AM UTC-5, Bob Carpenter wrote:

It ran after the most recent pull, but there
seem to be a lot of false negatives on the markup.

False negatives happen for various reasons, but there should be no false positives. Basically, there are a lot of

"no unique match found for: ..."

messages, where it finds a change in a small snippet but refrains from marking that snippet because the same snippet appears multiple times in a file. Maybe this can be improved for future versions, but I sort of hoped that it would at least mark something on a page that had been changed even if it did not mark 100% of the changed lines.

Ben -- did you want me to send you a copy of
the new manual?  Or do you think we should use that
one instead of the un-annotated one?  Now that the
annotations are relatively unintrusive, I wouldn't
mind making this the regular manual.

Maybe attach it, just so that I can make sure it worked as well as it was intended to work. I don't really care if it is an alternative to or a replacement for the plain manual because it should be identical aside from the margins and the last page(s).

Ben

[Bob Carpenter]

On 12/20/12 3:09 AM, Ben Goodrich wrote:
> On Thursday, December 20, 2012 2:53:54 AM UTC-5, Bob Carpenter wrote:
>
> It ran after the most recent pull, but there
> seem to be a lot of false negatives on the markup.
>
>
> False negatives happen for various reasons, but there should be no false positives. Basically, there are a lot of
>
> "no unique match found for: ..."
>
> messages, where it finds a change in a small snippet but refrains from marking that snippet because the same snippet
> appears multiple times in a file. Maybe this can be improved for future versions, but I sort of hoped that it would at
> least mark something on a page that had been changed even if it did not mark 100% of the changed lines.

That totally explains what's going on. It did
a good job finding changed regions.

>
> Ben -- did you want me to send you a copy of
> the new manual? Or do you think we should use that
> one instead of the un-annotated one? Now that the
> annotations are relatively unintrusive, I wouldn't
> mind making this the regular manual.
>
>
> Maybe attach it,

Done.

- Bob

[Ben Goodrich]

There was one mistake, and it does affect the pagination a little bit. But it seems to be basically as expected.

Ben