12:06 p.m.
Hello CVS-team!
Could you please comment why output from CVS sometimes uses 73
character =-separator lines while sometimes only 67 of them are used?
See the thread starting at
http://list-archive.xemacs.org/xemacs-beta/200201/msg00306.html
if you have the time.
Currently pcl-cvs expects 67 and reports parser errors otherwise.
A possible fix for pcvs-parse.el would be to change
(cvs-match
"===================================================================$")
to
(cvs-match
"[=]\{67,\}$")
but understanding what's going first is always a good idea :-)
Thanks in advance,
Adrian
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
1:31 p.m.
Adrian Aichner <adrian(a)xemacs.org> writes:
Hello CVS-team!
Could you please comment why output from CVS sometimes uses 73
character =-separator lines while sometimes only 67 of them are used?
See the thread starting at
http://list-archive.xemacs.org/xemacs-beta/200201/msg00306.html
if you have the time.
Currently pcl-cvs expects 67 and reports parser errors otherwise.
A possible fix for pcvs-parse.el would be to change
(cvs-match
"===================================================================$")
to
(cvs-match
"[=]\{67,\}$")
but understanding what's going first is always a good idea :-)
I think the problem is an XEmacs problem.
I have tried to provoke the long lines in a shell buffer, but have not
succeded.
To day I ran into another instance of the what I would expect to be
the same bug.
in the *cvs* buffer I got:
/--------------------------------------
|In directory .:
|Message: Parser Error: '======cvs server: Examining etc/eicq'
| Up-To-Date 1.1 .cvsignore
|1.57 Need-Update 1.54 ChangeLog
\--------------------------------------
In the " *cvs-tmp*" buffer I have
/--------------------------------------
|===================================================================
|File: icq2tcp.c Status: Needs Patch
|
| Working revision: 1.3
| Repository revision: 1.4 /cvsroot/eicq/eicq/icq2tcp.c,v
| Sticky Tag: (none)
| Sticky Date: (none)
| Sticky Options: (none)
|
|======cvs server: Examining etc/eicq
|===================================================================
|File: authorize-here.xpm Status: Up-to-date
|
| Working revision: 1.2
| Repository revision: 1.2 /cvsroot/eicq/eicq/etc/eicq/authorize-here.xpm,v
| Sticky Tag: (none)
| Sticky Date: (none)
| Sticky Options: (none)
\-----------------------------------------------
Comparing to what I get in a "*shell*" buffer which is
/--------------------------------------
|===================================================================
|File: icq2tcp.c Status: Needs Patch
|
| Working revision: 1.3
| Repository revision: 1.4 /cvsroot/eicq/eicq/icq2tcp.c,v
| Sticky Tag: (none)
| Sticky Date: (none)
| Sticky Options: (none)
|
|===================================================================
|File: infohack.el Status: Up-to-date
|
| Working revision: 1.1
| Repository revision: 1.1 /cvsroot/eicq/eicq/infohack.el,v
| Sticky Tag: (none)
| Sticky Date: (none)
| Sticky Options: (none)
|
|cvs server: Examining etc
|cvs server: Examining etc/eicq
|===================================================================
|File: authorize-here.xpm Status: Up-to-date
|
| Working revision: 1.2
| Repository revision: 1.2 /cvsroot/eicq/eicq/etc/eicq/authorize-here.xpm,v
| Sticky Tag: (none)
| Sticky Date: (none)
| Sticky Options: (none)
|
\----------------------------------------
Note that it seems that the " *cvs-tmp*" buffer does not contain the file
"infohack.el" it is entirely missing from in that buffer!
I think it has something to do with the speed in which XEmacs is able
to fetch what it gets back from the process-stream. Maybe some buffer is
just not large enough or something or something times out too fast or
what ever.
I have also tried to make a `cvs-status' with `cvs-run-process' and
`cvs-mode-run' as edebug-defun'ed. steping thorugh it manually makes
the output more stable.
I must admit that the problem seems deeper than just cvs gives
non-parseable feedback something lurking in either the *usage* of
xemacs network features within pcl-cvs or the implementation of the
XEmacs network features.
Jarl
5:26 p.m.
Jarl Friis <jarl(a)diku.dk> writes:
I must admit that the problem seems deeper than just cvs gives
non-parseable feedback something lurking in either the *usage* of
xemacs network features within pcl-cvs or the implementation of the
XEmacs network features.
Sorry, it seem not to be related to networking, since pcl-cvs is not
directly using the XEmacs network features, but just invokes cvs as a
process, nevertheless I consider it a XEmacs bug, but merely related
to the `start-process' function.
Jarl
8:33 p.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
Jarl Friis <jarl(a)diku.dk> writes:
Jarl Friis <jarl(a)diku.dk> writes:
>
> I must admit that the problem seems deeper than just cvs gives
> non-parseable feedback something lurking in either the *usage* of
> xemacs network features within pcl-cvs or the implementation of the
> XEmacs network features.
Sorry, it seem not to be related to networking, since pcl-cvs is not
directly using the XEmacs network features, but just invokes cvs as a
process, nevertheless I consider it a XEmacs bug, but merely related
to the `start-process' function.
I have made a very small program that demonstrates the location of the
bug. Essentially it is setting the variable `process-connection-type'
to nil that causes trouble. In the examples, please modify the
hardcoded strings as necessary.
The first one makes a cvs status using pipes, which creates spurious
output in " *mycvs-tmp*" buffer:
(let (
(process-connection-type nil) ; Use a pipe, not a pty.
(default-directory (cvs-expand-dir-name "~/projects/eicq"))
)
(apply 'start-process "mycvs" (get-buffer-create " *mycvs-tmp*")
"cvs" '("-f" "status"))
)
The second one uses a pty instead, and sends the password "manually",
which works!
(let (
(mypassword "PaSsWoRd");;insert a password here
(process-connection-type t) ; Use a pipe, not a pty.
(default-directory (cvs-expand-dir-name "~/projects/eicq"))
)
(apply 'start-process "mycvs" (get-buffer-create " *mycvs-tmp*")
"cvs" '("-f" "status"))
(process-send-string "mycvs" (concat mypassword "\n"))
)
Now the usage of `process-connection-type' is not to be found in
`start-process' so I guess it is used in `start-process-internal'
which is implemented in C, will someone please take over from here?
Now when the bug tracks into the C-code I guess it is relevant with
system information, how can I have XEmacs collect all the information
necessary for this? In short I run XEmacs 21.1.14, 21.5.4, linux,
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
gcc version 2.95.3 20010315 (SuSE)
Will someone please take over from here as I am not familiar with
XEmacs C code?
Jarl
10:27 p.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
Jarl> Jarl Friis <jarl(a)diku.dk> writes:
> Jarl Friis <jarl(a)diku.dk> writes:
>
> >
> > I must admit that the problem seems deeper than just cvs gives
> > non-parseable feedback something lurking in either the *usage* of
> > xemacs network features within pcl-cvs or the implementation of the
> > XEmacs network features.
>
> Sorry, it seem not to be related to networking, since pcl-cvs is not
> directly using the XEmacs network features, but just invokes cvs as a
> process, nevertheless I consider it a XEmacs bug, but merely related
> to the `start-process' function.
Jarl> I have made a very small program that demonstrates the
Jarl> location of the bug. Essentially it is setting the variable
Jarl> `process-connection-type' to nil that causes trouble. In the
Hi Jarl,
thanks for narrowing in on this!
I am using a slightly modified version which names the process buffers
uniquely so I can diff them afterwards.
Could you please do the same on send in the diffs?
I am not getting any diffs in cvs output in native Windows 2000 XEmacs
on all of of XEmacs packages module monster!
On a second try I got following diff which I think is unrelated
(waiting for a lock in CVS):
--- C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYA2he Thu Jan 24 23:23:03 2002
+++ C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYADsk Thu Jan 24 23:23:03 2002
ï¼ ï¼ -15338,6 +15338,8 ï¼ ï¼
Sticky Options: (none)
cvs server: Examining xemacs-packages/ilisp
+cvs server: [23:05:53] waiting for cvs's lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
+cvs server: [23:06:23] obtained lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
===================================================================
File: .cvsignore Status: Up-to-date
ï¼ ï¼ -31917,4 +31919,4 ï¼ ï¼
Sticky Options: (none)
-Process mycvs finished
+Process mycvs<1> finished
Jarl> examples, please modify the hardcoded strings as necessary.
Jarl> The first one makes a cvs status using pipes, which creates spurious
Jarl> output in " *mycvs-tmp*" buffer:
Jarl> (let (
Jarl> (process-connection-type nil) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> )
Jarl> The second one uses a pty instead, and sends the password
"manually",
Jarl> which works!
Jarl> (let (
Jarl> (mypassword "PaSsWoRd");;insert a password here
Jarl> (process-connection-type t) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> (process-send-string "mycvs" (concat mypassword "\n"))
Jarl> )
Jarl> Now the usage of `process-connection-type' is not to be found in
Jarl> `start-process' so I guess it is used in `start-process-internal'
Jarl> which is implemented in C, will someone please take over from here?
Ah,
xemacs-21.5\src\process-unix.c
allocates a pty for process-connection-type t, while
xemacs-21.5\src\process-nt.c
is not doing anything with process-connection-type!
This is probably why I don't see this kind of problem.
In xemacs-21.5\src\process-unix.c there is ...
static int
unix_create_process (Lisp_Process *p,
Lisp_Object *argv, int nargv,
Lisp_Object program, Lisp_Object cur_dir)
{
int pid;
int inchannel = -1;
int outchannel = -1;
/* Use volatile to protect variables from being clobbered by longjmp. */
volatile int forkin = -1;
volatile int forkout = -1;
volatile int pty_flag = 0;
if (!NILP (Vprocess_connection_type))
{
/* find a new pty, open the master side, return the opened
file handle, and store the name of the corresponding slave
side in global variable pty_name. */
outchannel = inchannel = allocate_pty ();
}
Jarl> Now when the bug tracks into the C-code I guess it is relevant with
Jarl> system information, how can I have XEmacs collect all the information
Jarl> necessary for this? In short I run XEmacs 21.1.14, 21.5.4, linux,
If necessary/possible, please install the latest net-utils package (>=
1.23) and then use
Help->Send Bug Report...
or
M-x report-emacs-bug
as suggested in
http://www.xemacs.org/Debug/index.html
Jarl> $ gcc -v
Jarl> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
Jarl> gcc version 2.95.3 20010315 (SuSE)
Jarl> Will someone please take over from here as I am not familiar with
Jarl> XEmacs C code?
Thanks for tracking this down, Jarl. This should bring us a lot
closer to a solution!
I'll be skiing for a week starting saturday.
I hope somebody will take this up meanwhile.
Best regards,
Adrian
Jarl> Jarl
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
7:18 a.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>>>>> "Jarl" == Jarl Friis
<jarl(a)diku.dk> writes:
Jarl> Jarl Friis <jarl(a)diku.dk> writes:
>> Jarl Friis <jarl(a)diku.dk> writes:
>>
>> >
>> > I must admit that the problem seems deeper than just cvs gives
>> > non-parseable feedback something lurking in either the *usage* of
>> > xemacs network features within pcl-cvs or the implementation of the
>> > XEmacs network features.
>>
>> Sorry, it seem not to be related to networking, since pcl-cvs is not
>> directly using the XEmacs network features, but just invokes cvs as a
>> process, nevertheless I consider it a XEmacs bug, but merely related
>> to the `start-process' function.
Jarl> I have made a very small program that demonstrates the
Jarl> location of the bug. Essentially it is setting the variable
Jarl> `process-connection-type' to nil that causes trouble. In the
Hi Jarl,
thanks for narrowing in on this!
Thank *you* for helping and commenting and taking the thread seriously.
I am using a slightly modified version which names the process buffers
uniquely so I can diff them afterwards.
Modified version of what? pcl-cvs? XEmacs C code? net-utils?
Could you please do the same on send in the diffs?
I'm not sure I understand what you mean here; "diffs" of what? "do the
same" as
what?
I am not getting any diffs in cvs output in native Windows 2000 XEmacs
on all of of XEmacs packages module monster!
Are you here suggesting/proposing that this could be yet another
"instance" of the same bug?
On a second try I got following diff which I think is unrelated
(waiting for a lock in CVS):
--- C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYA2he Thu Jan 24 23:23:03 2002
+++ C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYADsk Thu Jan 24 23:23:03 2002
ï¼ ï¼ -15338,6 +15338,8 ï¼ ï¼
Sticky Options: (none)
cvs server: Examining xemacs-packages/ilisp
+cvs server: [23:05:53] waiting for cvs's lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
+cvs server: [23:06:23] obtained lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
===================================================================
File: .cvsignore Status: Up-to-date
ï¼ ï¼ -31917,4 +31919,4 ï¼ ï¼
Sticky Options: (none)
-Process mycvs finished
+Process mycvs<1> finished
Jarl> examples, please modify the hardcoded strings as necessary.
Jarl> The first one makes a cvs status using pipes, which creates spurious
Jarl> output in " *mycvs-tmp*" buffer:
Jarl> (let (
Jarl> (process-connection-type nil) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> )
Jarl> The second one uses a pty instead, and sends the password
"manually",
Jarl> which works!
Jarl> (let (
Jarl> (mypassword "PaSsWoRd");;insert a password here
Jarl> (process-connection-type t) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> (process-send-string "mycvs" (concat mypassword
"\n"))
Jarl> )
Jarl> Now the usage of `process-connection-type' is not to be found in
Jarl> `start-process' so I guess it is used in `start-process-internal'
Jarl> which is implemented in C, will someone please take over from here?
Ah,
xemacs-21.5\src\process-unix.c
allocates a pty for process-connection-type t, while
xemacs-21.5\src\process-nt.c
is not doing anything with process-connection-type!
This is probably why I don't see this kind of problem.
You may be very right on this, so for now let's assume (until
otherwise is proven by an example) that the problem only affects unix
versions.
In xemacs-21.5\src\process-unix.c there is ...
static int
unix_create_process (Lisp_Process *p,
Lisp_Object *argv, int nargv,
Lisp_Object program, Lisp_Object cur_dir)
{
int pid;
int inchannel = -1;
int outchannel = -1;
/* Use volatile to protect variables from being clobbered by longjmp. */
volatile int forkin = -1;
volatile int forkout = -1;
volatile int pty_flag = 0;
if (!NILP (Vprocess_connection_type))
{
/* find a new pty, open the master side, return the opened
file handle, and store the name of the corresponding slave
side in global variable pty_name. */
outchannel = inchannel = allocate_pty ();
}
Jarl> Now when the bug tracks into the C-code I guess it is relevant with
Jarl> system information, how can I have XEmacs collect all the information
Jarl> necessary for this? In short I run XEmacs 21.1.14, 21.5.4, linux,
If necessary/possible, please install the latest net-utils package (>=
1.23) and then use
Help->Send Bug Report...
or
M-x report-emacs-bug
as suggested in
http://www.xemacs.org/Debug/index.html
OK, I will do that if I get stuck.
Nevertheless getting this close I probably will continue until fixed
:-) I am competent in unix system C programmer so I guess it's just
a question of getting a grip of the XEmacs C code. I may ask the guy
who splitted `process-unix.c' Kirill M. Katsnelson <kkm(a)kis.ru>.
Jarl> $ gcc -v
Jarl> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
Jarl> gcc version 2.95.3 20010315 (SuSE)
Jarl> Will someone please take over from here as I am not familiar with
Jarl> XEmacs C code?
Thanks for tracking this down, Jarl. This should bring us a lot
closer to a solution!
I hope it will. I wonder what other process-related hidden bugs it will
solve:-) Anyway I hope it will be back-ported to 21.1.x branch since
the bug is also reproducible there.
I'll be skiing for a week starting saturday.
Have a good holyday, it's my turn next friday; heading for Val. T. on
my snowboard :-DD)
I hope somebody will take this up meanwhile.
I will continue for some time. Please catch me up on this I tend to
forget it, that is I'll be back from snow-land the 10. February.
Jarl
8 a.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
Jarl> Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>> >>>> "Jarl" == Jarl
Friis <jarl(a)diku.dk> writes:
>
Jarl> Jarl Friis <jarl(a)diku.dk> writes:
> >> Jarl Friis <jarl(a)diku.dk> writes:
> >>
> >> >
> >> > I must admit that the problem seems deeper than just cvs gives
> >> > non-parseable feedback something lurking in either the *usage* of
> >> > xemacs network features within pcl-cvs or the implementation of the
> >> > XEmacs network features.
> >>
> >> Sorry, it seem not to be related to networking, since pcl-cvs is not
> >> directly using the XEmacs network features, but just invokes cvs as a
> >> process, nevertheless I consider it a XEmacs bug, but merely related
> >> to the `start-process' function.
>
Jarl> I have made a very small program that demonstrates the
Jarl> location of the bug. Essentially it is setting the variable
Jarl> `process-connection-type' to nil that causes trouble. In the
>
> Hi Jarl,
>
> thanks for narrowing in on this!
Jarl> Thank *you* for helping and commenting and taking the thread
Jarl> seriously.
>
> I am using a slightly modified version which names the process buffers
> uniquely so I can diff them afterwards.
Jarl> Modified version of what? pcl-cvs? XEmacs C code? net-utils?
Oh, I modified your test case to this:
>
> Could you please do the same on send in the diffs?
Jarl> I'm not sure I understand what you mean here; "diffs" of
Jarl> what? "do the same" as what?
Diffs between
" *mycvs-tmp-pty*" and " *mycvs-tmp-pipe*".
>
> I am not getting any diffs in cvs output in native Windows 2000 XEmacs
> on all of of XEmacs packages module monster!
Jarl> Are you here suggesting/proposing that this could be yet another
Jarl> "instance" of the same bug?
I don't think so. This is the cvs server saying it's waiting for a
lock to go away. That can happen any time.
>
> On a second try I got following diff which I think is unrelated
> (waiting for a lock in CVS):
>
> --- C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYA2he Thu Jan 24 23:23:03 2002
> +++ C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYADsk Thu Jan 24 23:23:03 2002
> ï¼ ï¼ -15338,6 +15338,8 ï¼ ï¼
> Sticky Options: (none)
>
> cvs server: Examining xemacs-packages/ilisp
> +cvs server: [23:05:53] waiting for cvs's lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
> +cvs server: [23:06:23] obtained lock in
/pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp
> ===================================================================
> File: .cvsignore Status: Up-to-date
>
> ï¼ ï¼ -31917,4 +31919,4 ï¼ ï¼
> Sticky Options: (none)
>
>
> -Process mycvs finished
> +Process mycvs<1> finished
>
Jarl> examples, please modify the hardcoded strings as necessary.
>
Jarl> The first one makes a cvs status using pipes,
which creates spurious
Jarl> output in " *mycvs-tmp*" buffer:
>
Jarl> (let (
Jarl> (process-connection-type nil) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> )
>
Jarl> The second one uses a pty instead, and sends
the password "manually",
Jarl> which works!
>
Jarl> (let (
Jarl> (mypassword "PaSsWoRd");;insert a password here
Jarl> (process-connection-type t) ; Use a pipe, not a pty.
Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq"))
Jarl> )
Jarl> (apply 'start-process "mycvs" (get-buffer-create "
*mycvs-tmp*") "cvs" '("-f" "status"))
Jarl> (process-send-string "mycvs" (concat mypassword "\n"))
Jarl> )
>
Jarl> Now the usage of
`process-connection-type' is not to be found in
Jarl> `start-process' so I guess it is used in `start-process-internal'
Jarl> which is implemented in C, will someone please take over from here?
>
>> Ah,
>> xemacs-21.5\src\process-unix.c
>> allocates a pty for process-connection-type t, while
>> xemacs-21.5\src\process-nt.c
>> is not doing anything with process-connection-type!
>
>> This is probably why I don't see this
kind of problem.
Jarl> You may be very right on this, so for now let's assume (until
Jarl> otherwise is proven by an example) that the problem only affects unix
Jarl> versions.
OK.
>
>> In xemacs-21.5\src\process-unix.c there is
...
>
>> static int
>> unix_create_process (Lisp_Process *p,
>> Lisp_Object *argv, int nargv,
>> Lisp_Object program, Lisp_Object cur_dir)
>> {
>> int pid;
>> int inchannel = -1;
>> int outchannel = -1;
>> /* Use volatile to protect variables from being clobbered by longjmp. */
>> volatile int forkin = -1;
>> volatile int forkout = -1;
>> volatile int pty_flag = 0;
>
>> if (!NILP (Vprocess_connection_type))
>> {
>> /* find a new pty, open the master side, return the opened
>> file handle, and store the name of the corresponding slave
>> side in global variable pty_name. */
>> outchannel = inchannel = allocate_pty ();
>> }
>
Jarl> Now when the bug tracks into the C-code I
guess it is relevant with
Jarl> system information, how can I have XEmacs collect all the information
Jarl> necessary for this? In short I run XEmacs 21.1.14, 21.5.4, linux,
>
>> If necessary/possible, please install the
latest net-utils package (>=
>> 1.23) and then use
Help-> Send Bug Report...
> or
> M-x report-emacs-bug
> as suggested in
> http://www.xemacs.org/Debug/index.html
Jarl> OK, I will do that if I get stuck.
Jarl> Nevertheless getting this close I probably will continue
Jarl> until fixed :-) I am competent in unix system C programmer
Jarl> so I guess it's just a question of getting a grip of the
Jarl> XEmacs C code. I may ask the guy who splitted
Jarl> `process-unix.c' Kirill M. Katsnelson <kkm(a)kis.ru>.
Good plan!
If you use vc, try this in process-unix.c:
C-x v g runs the command vc-annotate
>
Jarl> $ gcc -v
Jarl> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
Jarl> gcc version 2.95.3 20010315 (SuSE)
>
Jarl> Will someone please take over from here as I
am not familiar with
Jarl> XEmacs C code?
>
>> Thanks for tracking this down, Jarl. This
should bring us a lot
>> closer to a solution!
Jarl> I hope it will. I wonder what other process-related hidden
Jarl> bugs it will solve:-) Anyway I hope it will be back-ported
Yep, that would be great.
Jarl> to 21.1.x branch since the bug is also reproducible there.
That will depend on the fix you come up with, but don't worry about it
now.
>
>> I'll be skiing for a week starting
saturday.
Jarl> Have a good holyday, it's my turn next friday; heading for
Jarl> Val. T. on my snowboard :-DD)
Once I stop falling out of the lifts I'll probably be a snowboard god. :-)
>
>> I hope somebody will take this up meanwhile.
Jarl> I will continue for some time. Please catch me up on this I
Jarl> tend to forget it, that is I'll be back from snow-land the
Jarl> 10. February.
Have a good one too!
Stay away from skiers!
Jarl> Jarl
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
9:29 a.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>>>>> "Jarl" == Jarl Friis
<jarl(a)diku.dk> writes:
Jarl> Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>> >>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
>>
Jarl> I have made a very small program that demonstrates the
Jarl> location of the bug. Essentially it is setting the variable
Jarl> `process-connection-type' to nil that causes trouble. In the
>>
>> Hi Jarl,
>>
>> thanks for narrowing in on this!
Jarl> Thank *you* for helping and commenting and taking the thread
Jarl> seriously.
>>
>> I am using a slightly modified version which names the process buffers
>> uniquely so I can diff them afterwards.
Jarl> Modified version of what? pcl-cvs? XEmacs C code? net-utils?
Oh, I modified your test case to this:
I see, now I get it. to make it even easier I suggest the following
bug-reproducing code:
,----
| (let (
| (mypassword "PaSsWoRd");;insert a password here
| (default-directory (cvs-expand-dir-name
"~/projects/cvs-sandbox/xemacs-devel/packages"))
| )
| (progn
| (setq process-connection-type nil) ; Use a pipe.
| (kill-buffer (get-buffer-create " *mycvs-tmp-pipe*"))
| (apply 'start-process "mycvs-pipe" (get-buffer-create "
*mycvs-tmp-pipe*") "cvs" '("-f" "status"))
| (setq process-connection-type t) ; Use a pty.
| (kill-buffer (get-buffer-create " *mycvs-tmp-pty*"))
| (apply 'start-process "mycvs-pty" (get-buffer-create "
*mycvs-tmp-pty*") "cvs" '("-f" "status"))
| (process-send-string "mycvs-pty" (concat mypassword "\n"))
| )
| )
`----
To Steve (and other (unix) tester ): If there are "major" differences
in the two buffers, then that demonstrates the bug.
>>
>> Could you please do the same on send in the diffs?
Jarl> I'm not sure I understand what you mean here; "diffs" of
Jarl> what? "do the same" as what?
Diffs between
" *mycvs-tmp-pty*" and " *mycvs-tmp-pipe*".
I see. You should know I am not hooked up by that fast a line
(256kb/s) so doing a cvs status on the 'packages' module takes some
time.
Another thing is that it seem not very reproducible to me on that
module, but Steve had experienced this, Steve would you please do the
bug-demonstration on the 'packages' module?
Jarl> Nevertheless getting this close I probably will
continue
Jarl> until fixed :-) I am competent in unix system C programmer
Jarl> so I guess it's just a question of getting a grip of the
Jarl> XEmacs C code. I may ask the guy who splitted
Jarl> `process-unix.c' Kirill M. Katsnelson <kkm(a)kis.ru>.
Good plan!
If you use vc, try this in process-unix.c:
C-x v g runs the command vc-annotate
OK, cool. I am not sure of what it is, I see a lot of comments and
code snippets (in different colours) in the file with names (probably
authors). Is it such that I can for any line in the code see who
'touch'ed this line last time and when that happend? kind of who to
blaim/contact for the specific part of the code?
>>
>> I'll be skiing for a week starting saturday.
Jarl> Have a good holyday, it's my turn next friday; heading for
Jarl> Val. T. on my snowboard :-DD)
Once I stop falling out of the lifts I'll probably be a snowboard god. :-)
>>
>> I hope somebody will take this up meanwhile.
Jarl> I will continue for some time. Please catch me up on this I
Jarl> tend to forget it, that is I'll be back from snow-land the
Jarl> 10. February.
Have a good one too!
Stay away from skiers!
Were I surf there aren't any skiers anyway, they tend to stick to the
slopes, not the powder and cliff edges where I hang out :-)
Jarl
11:31 a.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
Jarl> Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>> >>>> "Jarl" == Jarl
Friis <jarl(a)diku.dk> writes:
>>
Jarl> Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>> >> >>>> "Jarl" == Jarl
Friis <jarl(a)diku.dk> writes:
>> >>
Jarl> I have made a very small program that demonstrates the
Jarl> location of the bug. Essentially it is setting the variable
Jarl> `process-connection-type' to nil that causes trouble. In the
> >>
> >> Hi Jarl,
> >>
> >> thanks for narrowing in on this!
>
Jarl> Thank *you* for helping and commenting and taking the thread
Jarl> seriously.
>
> >>
> >> I am using a slightly modified version which names the process buffers
> >> uniquely so I can diff them afterwards.
>
Jarl> Modified version of what? pcl-cvs? XEmacs C code? net-utils?
>
> Oh, I modified your test case to this:
Jarl> I see, now I get it. to make it even easier I suggest the following
Jarl> bug-reproducing code:
Jarl> ,----
Jarl> | (let (
Jarl> | (mypassword "PaSsWoRd");;insert a password here
Jarl> | (default-directory (cvs-expand-dir-name
"~/projects/cvs-sandbox/xemacs-devel/packages"))
Jarl> | )
Jarl> | (progn
Jarl> | (setq process-connection-type nil) ; Use a pipe.
Jarl> | (kill-buffer (get-buffer-create " *mycvs-tmp-pipe*"))
Jarl> | (apply 'start-process "mycvs-pipe" (get-buffer-create
" *mycvs-tmp-pipe*") "cvs" '("-f" "status"))
Jarl> | (setq process-connection-type t) ; Use a pty.
Jarl> | (kill-buffer (get-buffer-create " *mycvs-tmp-pty*"))
Jarl> | (apply 'start-process "mycvs-pty" (get-buffer-create
" *mycvs-tmp-pty*") "cvs" '("-f" "status"))
Jarl> | (process-send-string "mycvs-pty" (concat mypassword
"\n"))
Jarl> | )
Jarl> | )
Jarl> `----
Jarl> To Steve (and other (unix) tester ): If there are "major"
differences
Jarl> in the two buffers, then that demonstrates the bug.
>
> >>
> >> Could you please do the same on send in the diffs?
>
Jarl> I'm not sure I understand what you mean here;
"diffs" of
Jarl> what? "do the same" as what?
>
> Diffs between
> " *mycvs-tmp-pty*" and " *mycvs-tmp-pipe*".
Jarl> I see. You should know I am not hooked up by that fast a line
Jarl> (256kb/s) so doing a cvs status on the 'packages' module takes some
Jarl> time.
Jarl> Another thing is that it seem not very reproducible to me on
Jarl> that module, but Steve had experienced this, Steve would you
Jarl> please do the bug-demonstration on the 'packages' module?
Jarl> Nevertheless getting this close I probably will continue
Jarl> until fixed :-) I am competent in unix system C programmer
Jarl> so I guess it's just a question of getting a grip of the
Jarl> XEmacs C code. I may ask the guy who splitted
Jarl> `process-unix.c' Kirill M. Katsnelson <kkm(a)kis.ru>.
>
> Good plan!
>
> If you use vc, try this in process-unix.c:
>
> C-x v g runs the command vc-annotate
Jarl> OK, cool. I am not sure of what it is, I see a lot of
Jarl> comments and code snippets (in different colours) in the
Jarl> file with names (probably authors). Is it such that I can
Jarl> for any line in the code see who 'touch'ed this line last
Jarl> time and when that happend? kind of who to blaim/contact for
Jarl> the specific part of the code?
Exactly, it's also referred to as the blame feature :-)
It tells you who to ask about pieces of code. Of course this breaks
down if the committer is not the author of the code. But the
committer should be able to establish contact with the author.
> >>
> >> I'll be skiing for a week starting saturday.
>
Jarl> Have a good holyday, it's my turn next friday; heading for
Jarl> Val. T. on my snowboard :-DD)
>
> Once I stop falling out of the lifts I'll probably be a snowboard god. :-)
>
> >>
> >> I hope somebody will take this up meanwhile.
>
Jarl> I will continue for some time. Please catch me up on this I
Jarl> tend to forget it, that is I'll be back from snow-land the
Jarl> 10. February.
>
> Have a good one too!
>
> Stay away from skiers!
Jarl> Were I surf there aren't any skiers anyway, they tend to
Jarl> stick to the slopes, not the powder and cliff edges where I
Jarl> hang out :-)
I may be around the corner, beware!
Jarl> Jarl
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
9 p.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
Hi Adrian and other readers.
Adrian Aichner <adrian(a)xemacs.org> writes:
>>>>> "Jarl" == Jarl Friis
<jarl(a)diku.dk> writes:
Jarl> Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>> >>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
>>
Jarl> Adrian.Aichner(a)t-online.de (Adrian Aichner) writes:
>> >> >>>>> "Jarl" == Jarl Friis
<jarl(a)diku.dk> writes:
>> >>
Jarl> I have made a very small program that demonstrates the
Jarl> location of the bug. Essentially it is setting the variable
Jarl> `process-connection-type' to nil that causes trouble. In the
>> >>
>> >> Hi Jarl,
>> >>
>> >> thanks for narrowing in on this!
Inspired by your earlier mails to cvs maintainer, I had a look on the
Emacs source too; looks much the same in this corner of CVS, so I
fired up an emacs and figured out that it contains exactly the same
bug. The exact same problem occurs, so no help from there.
The lazy way: to report a bug to the emacs developers and merge in the
diffs they eventually come up with.
The challengeing way: fix the problem our self and be a step ahead of
the Emacs team :-)
I head for the challenging way until friday If the problem is not
located, I may lean towards the lazy way =-( as if that would help.
Jarl
2:01 a.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
Jarl> fired up an emacs and figured out that it contains exactly
Jarl> the same bug. The exact same problem occurs, so no help from
Jarl> there.
Jarl> The lazy way: to report a bug to the emacs developers and
Jarl> merge in the diffs they eventually come up with.
You've already done that :-) because Stefan is in the loop. However a
formal bug report would be the polite thing to do.
Jarl> The challengeing way: fix the problem our self and be a step
Jarl> ahead of the Emacs team :-)
But only for a few hours, because of course you intend to send them
diffs, right? Please. :-) -> emacs-devel(a)gnu.org
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
2:58 p.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
>>>>> "Jarl" == Jarl Friis
<jarl(a)diku.dk> writes:
Jarl> fired up an emacs and figured out that it contains exactly
Jarl> the same bug. The exact same problem occurs, so no help from
Jarl> there.
Jarl> The lazy way: to report a bug to the emacs developers and
Jarl> merge in the diffs they eventually come up with.
You've already done that :-) because Stefan is in the loop.
I'm too busy these days to be really considered "in the loop" :-(
However a formal bug report would be the polite thing to do.
I don't know about polite, but it would probably help. Il would also
help if the report made it very clear it's got nothing to do with CVS
or PCL-CVS, so they don't waste their time waiting for my help ;-)
Jarl> The challengeing way: fix the problem our self and be a
step
Jarl> ahead of the Emacs team :-)
But only for a few hours, because of course you intend to send them
Actually XEmacs' faster release cycle means that it will be more quickly
integrated into an actual release (rather than just the CVS repository),
even if it is first fixed on the Emacs side.
Stefan
10:39 p.m.
New subject: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)
On 24 Jan 2002, jarl(a)diku.dk wrote:
Will someone please take over from here as I am not familiar with
XEmacs C code?
Jarl
It looks like the lisp code, except the parens are in the wrong place.
I'm being somewhat facetious, but not much. Look in src/process.c
there is code like:
DEFUN ("get-process", Fget_process, 1, 1, 0, /*
Return the process named PROCESS-NAME (a string), or nil if there is none.
PROCESS-NAME may also be a process; if so, the value is that process.
*/
(process_name))
...
-jeff
5:10 p.m.
Adrian Aichner writes:
Could you please comment why output from CVS sometimes uses 73
character =-separator lines while sometimes only 67 of them are used?
Which output? Different things use different separators. Looking at
the message thread, it looks like you're specifically referring to ``cvs
status'' output, which always uses 67 character separators; the 73
character case "can't happen" (but apparently does). I can only assume
that something funky is going on, either in the CVS server or in the
transport channel. Do you have a server where you can reliably
reproduce the problem?
-Larry Jones
I must have been delirious from having so much fun. -- Calvin
9:05 p.m.
>>>> "Larry" == Larry Jones
<larry.jones(a)sdrc.com> writes:
Larry> Adrian Aichner writes:
>
> Could you please comment why output from CVS sometimes uses 73
> character =-separator lines while sometimes only 67 of them are used?
Larry> Which output? Different things use different separators.
Larry> Looking at the message thread, it looks like you're
Larry> specifically referring to ``cvs status'' output, which
Larry> always uses 67 character separators; the 73 character case
Larry> "can't happen" (but apparently does). I can only assume
Hello Larry, thanks for spending your time on this!
Larry> that something funky is going on, either in the CVS server
Larry> or in the transport channel. Do you have a server where
Larry> you can reliably reproduce the problem?
The latter is the case as tracked down by Jarl Friis.
cvs itself is not the cause of this problem.
We will try to come up with a solution for XEmacs package pcl-cvs and
forward any patches to the upstream maintainer, Stefan Monnier.
Stefan, perhaps you even beat us in coming up with a fix for the
problem or has it never shown up in GNU Emacs?
Thanks again,
Adrian
Larry> -Larry Jones
Larry> I must have been delirious from having so much fun. -- Calvin
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
8336
days inactive
8341
days old
14 comments
7 participants
participants (7)
-
Adrian Aichner -
Adrian Aichner -
Jarl Friis -
Jeff Mincy -
Larry Jones -
Stefan Monnier -
Stephen J. Turnbull