headers
Glenn Morris | 1 Mar 2010 02:01
Picon

broken bzr history?


The following is from http://debbugs.gnu.org/5652#8 and onwards.
It sounds potentially serious. Is it?

Juri Linkov wrote:

>>> I typed `C-x v g' (vc-annotate) in info.el, and it displays:
>>>
>>>   49780.1.32 henrik. | (forward-line (1- (nth 3 (car Info-index-alternatives))))
>>
>> Looks like a bug in bzr.  With git blame it points to f4ed1f85:
>>
>> commit f4ed1f852b3fb7650178446ac53db773d9fd25d6
>> Author: Juri Linkov <juri <at> jurta.org>
>> Date:   Tue Apr 27 06:39:46 2004 +0000
>
> Yes, I can confirm this is the correct commit.  In read-only CVS I see:
>
> revision 1.393
> date: 2004-04-27 09:39:46 +0300;  author: jurta;  state: Exp;  lines: +80 -42;
> [...]
> (Info-index-next): Decrement line number.
Permalink | Reply | 3 comments |
headers
Óscar Fuentes | 1 Mar 2010 03:20
Picon

Re: broken bzr history?

Glenn Morris <rgm <at> gnu.org> writes:

> The following is from http://debbugs.gnu.org/5652#8 and onwards.
> It sounds potentially serious. Is it?
>
> Juri Linkov wrote:
>
>>>> I typed `C-x v g' (vc-annotate) in info.el, and it displays:
>>>>
>>>>   49780.1.32 henrik. | (forward-line (1- (nth 3 (car Info-index-alternatives))))
>>>
>>> Looks like a bug in bzr.  With git blame it points to f4ed1f85:
>>>
>>> commit f4ed1f852b3fb7650178446ac53db773d9fd25d6
>>> Author: Juri Linkov <juri <at> jurta.org>
>>> Date:   Tue Apr 27 06:39:46 2004 +0000
>>
>> Yes, I can confirm this is the correct commit.  In read-only CVS I see:
>>
>> revision 1.393
>> date: 2004-04-27 09:39:46 +0300;  author: jurta;  state: Exp;  lines: +80 -42;
>> [...]
>> (Info-index-next): Decrement line number.

I don't think that the branch is corrupted.

What is now known as bzr revision number 49780 was the point where the
rmail-mbox branch was created on CVS. That branch synched at least once
with mainline. At certain point, the branch was merged into
mainline. Much later, Emacs migrated to bzr. And after that, on revision
(Continue reading)

Permalink | Reply | 2 comments |
headers
Miles Bader | 1 Mar 2010 03:42
Picon
Gravatar

Re: emacs-w3m?

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> There'd be very little justification for such a prompt:
> - prompts suck for command line tools that can be used in scripts (or
>   by Emacs packages ;-)
> - "bzr add" prints the list of files it actually added, so if it adds
>   some files you didn't expect, you have a fair chance of noticing it
>   after the fact.
> - the effect of an overzealous "bzr add" can be cancelled without harm
>   any time until the next "commit".
> - it's usually recommended to use "<backend> diff" before a "<backend> commit"
>   so as to make sure you don't commit something by mistake, and that
>   would give one last chance to catch a "bzr add" that added more
>   than expected.

All that said, it seems far better to just do what git does, and require
one to type "... add ." instead.  Mistakes are still possible (and thus
your points remain), but much more difficult in practice.

-Miles

--

-- 
97% of everything is grunge
Permalink | Reply | 5 comments |
headers
Stefan Monnier | 1 Mar 2010 05:55
Picon

Re: broken bzr history?

> Stefan, how did you create that merge revision?

IIRC it was something like:

  bzr merge <branch>
  [... inspect bzr diff to make sure there's nothing left unmerged ...]
  bzr revert .
  bzr commit -m <msg>

In any case, it was a stupid idea on my part, and I'm "glad" to see that
I'll get to regret it some more in the future.

        Stefan
Permalink | Reply | 1 comment |
headers
Stefan Monnier | 1 Mar 2010 05:56
Picon

Re: emacs-w3m?

>> There'd be very little justification for such a prompt:
>> - prompts suck for command line tools that can be used in scripts (or
>> by Emacs packages ;-)
>> - "bzr add" prints the list of files it actually added, so if it adds
>> some files you didn't expect, you have a fair chance of noticing it
>> after the fact.
>> - the effect of an overzealous "bzr add" can be cancelled without harm
>> any time until the next "commit".
>> - it's usually recommended to use "<backend> diff" before a "<backend> commit"
>> so as to make sure you don't commit something by mistake, and that
>> would give one last chance to catch a "bzr add" that added more
>> than expected.

> All that said, it seems far better to just do what git does, and require
> one to type "... add ." instead.  Mistakes are still possible (and thus
> your points remain), but much more difficult in practice.

Probably doesn't make any difference: he would have typed "bzr add ."
rather than "bzr add" and the result would have been the same.

        Stefan
Permalink | Reply | 4 comments |
headers
Óscar Fuentes | 1 Mar 2010 07:03
Picon

Re: broken bzr history?

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Stefan, how did you create that merge revision?
>
> IIRC it was something like:
>
>   bzr merge <branch>
>   [... inspect bzr diff to make sure there's nothing left unmerged ...]
>   bzr revert .
>   bzr commit -m <msg>
>
> In any case, it was a stupid idea on my part, and I'm "glad" to see that
> I'll get to regret it some more in the future.

Well, that method was what I used while migrating some svn repos to bzr,
after the bzr developers sanctioned it. I guess that they are not aware
of the effects on `annotate'.
Permalink | Reply | 0 comments |
headers
Miles Bader | 1 Mar 2010 08:06
Picon
Gravatar

Re: emacs-w3m?

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> Probably doesn't make any difference: he would have typed "bzr add ."
> rather than "bzr add" and the result would have been the same.

No, I think that's wrong.

I don't really know why he typed "bzr add" (i.e., whether by sheer
accident, or in confusion about what it did), but in general it seems
_much_ more likely for somebody to accidentally type a command with no
arguments, than with an explicit "this directory".

Thus given the somewhat rare nature of needing to do such a thing, this
default for "bzr seems" an exceedingly poor choice.  Hopefully the bzr
devs will change this.

-Miles

--

-- 
Selfish, adj. Devoid of consideration for the selfishness of others.
Permalink | Reply | 3 comments |
headers
白い熊 | 1 Mar 2010 11:05

Creating modem process and receiving output of AT commands

Hi:

I'm creating a frontend to GNU Emacs BBDB for sending SMSes via AT
commands, on a Nokia N900 mobile.

It has a `pnatd' program which when run works as a modem and enables you
to send AT commands to the phone.

As per http://www.gnu.org/software/emacs/manual/html_node/elisp/Output-from-Processes.html#Output-from-Processes
I've been messing with this back and forth, along the following
lines:
(defun nokia-n900-send-output-keep (process output)
  (setq nokia-n900-send-output-kept (cons output nokia-n900-send-output-kept)))

(defun testos ()
  (start-process "n900-sms-dispatch" "*n900-sms-dispatch*" "pnatd")
  (setq nokia-n900-send-output-kept nil)
  (set-process-filter (get-process "n900-sms-dispatch") 'nokia-n900-send-output-keep)
  (process-send-string "n900-sms-dispatch" "at\r")
  (accept-process-output (get-process "n900-sms-dispatch"))
  (process-send-string "n900-sms-dispatch" "AT+CSCS=\"HEX\"\r")
  (accept-process-output (get-process "n900-sms-dispatch"))
  (process-send-string "n900-sms-dispatch" "AT+CSMP=17,167,0,8\r")
  (accept-process-output (get-process "n900-sms-dispatch"))
  (process-send-string "n900-sms-dispatch" "at+cmgf=1\r")
  (accept-process-output (get-process "n900-sms-dispatch")))

But running (testos), it doesn't even get to sending the first `at\r'. I think the reason
is, as the page says: When a subprocess terminates, Emacs reads any
pending output, then stops reading output from that
(Continue reading)

Permalink | Reply | 5 comments |
headers
Thien-Thi Nguyen | 1 Mar 2010 13:37
Favicon

Re: Creating modem process and receiving output of AT commands

() 白い熊 <emacs-devel_gnu.org <at> sumou.com>
() Mon, 01 Mar 2010 13:05:55 +0300

  (defun nokia-n900-send-output-keep (process output)
    (setq nokia-n900-send-output-kept (cons output nokia-n900-send-output-kept)))

Probably you want to add output to the tail, not the head.

   But running (testos), it doesn't even get to sending the first `at\r'.

What does that mean, precisely?  Does Emacs signal an error?

   I think the reason is [...].

It's possible that \r is being mangled.
See `process-coding-system-alist' (and friends).

You should make sure the subprocess sees what Emacs is purporting to send,
first, before worrying about whether or not Emacs sees what the subprocess
outputs.

thi
Permalink | Reply | 4 comments |
headers
白い熊 | 1 Mar 2010 14:24

Re: Creating modem process and receiving output of AT commands

Thien-Thi Nguyen <ttn <at> gnuvola.org> writes:
>   (defun nokia-n900-send-output-keep (process output)
>     (setq nokia-n900-send-output-kept (cons output nokia-n900-send-output-kept)))
>
> Probably you want to add output to the tail, not the head.

Yeah, however, if adding to the tail, for some reason it adds some
strange quotation marks and brackets. This way, the variable has an
identical log, just in reverse order, as when you don't use a filter,
and have output logged to a buffer. Not a big deal, could probably
figure out what's wrong later, after I get it working...

>    But running (testos), it doesn't even get to sending the first `at\r'.
>
> What does that mean, precisely?  Does Emacs signal an error?

No, there is no error, the first AT command doesn't get sent, Emacs just
waits forever.

>    I think the reason is [...].
>
> It's possible that \r is being mangled.
> See `process-coding-system-alist' (and friends).

It's not. If I run all the commands by hand, i.e. line by line, then
Emacs updates, and they are carried out, but if run in a function, it
just halts before getting to the first AT command, if I interrupt the
process, and inspect the value of nokia-n900-send-output-kept it's still
empty.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane