4:06 a.m.
Hi XEmacs beta testers,
I'd like to solicit help testing the latest distributed pcl-cvs binary
package 1.30. This version is based on author version 2.0 beta 2, and
contains a significant parser rewrite, M-x cvs-status and M-x
cvs-examine, and many other new features.
Those of you who use pcl-cvs, could you please beat on it as much as
possible and give me feedback. In particular, if there are things the
parser does not handle, I'd like to add code to handle those things.
Fortunately the new parser will just insert a warning in the *cvs*
buffer and continue, unlike the old one.
Also I really need help choosing colors for the faces defined in
pcl-cvs-xemacs.el. They're only really defaulted for a dark
background, and even those I'm not very happy with.
I've just completed the rest of the merge with our previous XEmacs
version, notably I added parsing of conflicts on stdout (recent CVS
versions moved it from stderr) but this is untested. I also merged my
patch from last spring for setting flags to the underlying commands.
I've also made a first pass at updating the documentation. This stuff
is on the branch r1-31-devel. It'll get merged to the main branch in
a day or so once I test it some.
thanks,
Greg
4:02 p.m.
Those of you who use pcl-cvs, could you please beat on it as much as
possible and give me feedback. In particular, if there are things the
parser does not handle, I'd like to add code to handle those things.
Fortunately the new parser will just insert a warning in the *cvs*
buffer and continue, unlike the old one.
Unfortunately for me pcl-cvs is completely broken on Win NT. I have had
pcl-cvs working on b38, but the latest beta hoses it. This is despite
much better sub-process support - W3, efs and shell all work much
better.
With cvs-shell set to the default "/bin/sh" (which is probably broken
for NT anyway) and cygwin bash at /bin/sh I get the following:
Message:
Parser Error: 'Usage: cvs [cvs-options] command
[command-options-and-arguments]'
Message:
Parser Error: ' where cvs-options are -q, -n, etc.'
etc for all the rest of what cvs puts out when it doesn't recognise the
command. The trick appears to be to quote the arguments to
start-process after the "-c" so the command line looks like
/bin/sh -c "cvs update" rather than /bin/sh -c cvs update.
With cvs-shell set to cmd.exe (arguably the correct choice on NT - it
should probably be initialised from shell-file-name) I get no output
whatsoever - no output is produced from the sub-process.
This was working with pcl-cvs-1.12 and b38 (or earlier) with shell set
to cmd.
Hope this helps - if I find a solution I'll send in some patches.
Malcolm
4:27 p.m.
Sorry, I have no way to test NT at this point. Wow, I didn't know
pcl-cvs used to work on it. That's encouraging at least...
First, which pcl-cvs package version is broken? 1.30?
Can you try to determine whether the problem is pcl-cvs or XEmacs by
trying the newer pcl-cvs on the older XEmacs and vice-versa?
Which version of CVS appears first on your path (run "cvs -v")? One
change I made was to just use the one found on your path, and I nuked
the kludgy code that was trying to locate CVS. If "which cvs" is not
the right one to use, try setting `cvs-program' to a string containing
the full path.
The message below indicates CVS is being invoked incorrectly, so I
guess it is most likely an XEmacs or choice of shell problem.
greg
>>>> "Malcolm" == Malcolm Box
<malcolm(a)brownale.demon.co.uk> writes:
Malcolm>
> Those of you who use pcl-cvs, could you please beat on it as much
as
> possible and give me feedback. In particular, if there are things the
> parser does not handle, I'd like to add code to handle those things.
> Fortunately the new parser will just insert a warning in the *cvs*
> buffer and continue, unlike the old one.
Malcolm>
Malcolm> Unfortunately for me pcl-cvs is completely broken on Win NT. I have had
Malcolm> pcl-cvs working on b38, but the latest beta hoses it. This is despite
Malcolm> much better sub-process support - W3, efs and shell all work much
Malcolm> better.
Malcolm>
Malcolm> With cvs-shell set to the default "/bin/sh" (which is probably
broken
Malcolm> for NT anyway) and cygwin bash at /bin/sh I get the following:
Malcolm>
Malcolm> Message:
Malcolm> Parser Error: 'Usage: cvs [cvs-options] command
Malcolm> [command-options-and-arguments]'
Malcolm>
Malcolm> Message:
Malcolm> Parser Error: ' where cvs-options are -q, -n, etc.'
Malcolm>
Malcolm> etc for all the rest of what cvs puts out when it doesn't recognise the
Malcolm> command. The trick appears to be to quote the arguments to
Malcolm> start-process after the "-c" so the command line looks like
Malcolm> /bin/sh -c "cvs update" rather than /bin/sh -c cvs update.
Malcolm>
Malcolm> With cvs-shell set to cmd.exe (arguably the correct choice on NT - it
Malcolm> should probably be initialised from shell-file-name) I get no output
Malcolm> whatsoever - no output is produced from the sub-process.
Malcolm>
Malcolm> This was working with pcl-cvs-1.12 and b38 (or earlier) with shell set
Malcolm> to cmd.
Malcolm>
Malcolm> Hope this helps - if I find a solution I'll send in some patches.
Malcolm>
Malcolm> Malcolm
Malcolm>
4:58 p.m.
Sorry, I have no way to test NT at this point. Wow, I didn't
know
pcl-cvs used to work on it. That's encouraging at least...
I was surprised as well, since subprocesses were pretty broken on b38.
First, which pcl-cvs package version is broken? 1.30?
1.30 and 1.12 packages both fail.
Can you try to determine whether the problem is pcl-cvs or XEmacs by
trying the newer pcl-cvs on the older XEmacs and vice-versa?
Alas I have nuked the old install, so can't test on the old XEmacs.
However, it is noticable that all other subprocess things work better on
this XEmacs than the old one.
Which version of CVS appears first on your path (run "cvs
-v")?
1.9.26 which is the version I expect to be using.
change I made was to just use the one found on your path, and I
nuked
the kludgy code that was trying to locate CVS.
Yes, I had to patch round this on the previous versions since it was
very broken.
The message below indicates CVS is being invoked incorrectly, so I
guess it is most likely an XEmacs or choice of shell problem.
I agree that it is an invocation problem. However, it doesn't work with
cmd or bash, which are the only shells I have available (and one more
than most NT users will have!) It appears that the necessity for
redirection and quoting issues are mucking things up.
Is there a good reason for using redirection rather than processing
everything together? From a cursory look at the code it would appear
possible to send the output of the cvs command to a temporary buffer,
then use the process sentinel to parse the entire buffer into the
cookie-collection. It appears this would both make the code simpler and
remove the need to redirect, while only modifying run-cvs-process and
the process sentinels. If you think this is feasible I'll try to hack
this up.
Cheers,
Malcolm
4:37 p.m.
I now have this working, having replaced the hard-coded "-c" in
run-cvs-process with shell-command-switch, and setting shell-filename to
cmd.exe. I also think that the arguments to start-process should be
passed through quote-process-arguments, as otherwise it looks like
filenames with spaces in will break. This works on NT, but I can't test
it on Unix at the moment.
pcl-cvs 1.30, XEmacs 21.0 beta 57 (Poitou)
Malcolm
9541
days inactive
9544
days old
4 comments
2 participants
participants (2)
-
Greg Klanderman -
Malcolm Box