2:11 p.m.
I'm running the carbon2 CVS branch of XEmacs on Mac OS X. (Andrew Choi
requested that bugs relating to carbon2 get reported to c.e.x, but I
have also seen this problem on Linux, so it seems to be a more general
XEmacs problem. That's why I'm posting here.)
TRAMP (package version 1.22 from sumo) is unable to find files. I get
lots of messages like this:
itimer "with-timeout<5>" signaled: (void-function with-timeout-handler)
and then:
Invalid state: Bogus value for `default-process-coding-system', nil
Anybody knows what's going on, or can help me debug it?
Andrew
5:38 p.m.
Andrew Nesbit <andrew(a)siru.org> writes:
I'm running the carbon2 CVS branch of XEmacs on Mac OS X. (Andrew
Choi
requested that bugs relating to carbon2 get reported to c.e.x, but I
have also seen this problem on Linux, so it seems to be a more general
XEmacs problem. That's why I'm posting here.)
TRAMP (package version 1.22 from sumo) is unable to find files. I get
lots of messages like this:
itimer "with-timeout<5>" signaled: (void-function with-timeout-handler)
and then:
Invalid state: Bogus value for `default-process-coding-system', nil
Sounds remotely familiar.
What are the tramp methods you're using?
Are you using the XEmacs tramp syntax vs. the Emacs tramp syntax?
If you do get a lisp errors, then a lisp backtrace would be helpful:
XEmacs <= 21.1
Options->General Options->Debug On Error
XEmacs >= 21.4
Options->Troubleshooting->Debug On Error
Provoke the error again.
If XEmacs hangs, then Debug on Quit
and
C-g (keyboard-quit)
at the point of the hang should give you a backtrace.
Send the *Backtrace* to xemacs-beta(a)xemacs.org.
Good Luck,
Adrian
Anybody knows what's going on, or can help me debug it?
Andrew
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
5:45 p.m.
Adrian Aichner <adrian(a)xemacs.org> writes:
Andrew Nesbit <andrew(a)siru.org> writes:
> I'm running the carbon2 CVS branch of XEmacs on Mac OS X. (Andrew Choi
> requested that bugs relating to carbon2 get reported to c.e.x, but I
> have also seen this problem on Linux, so it seems to be a more general
> XEmacs problem. That's why I'm posting here.)
>
> TRAMP (package version 1.22 from sumo) is unable to find files. I get
> lots of messages like this:
Ah, so you're up-to-date.
>
> itimer "with-timeout<5>" signaled: (void-function
with-timeout-handler)
There are some known itimer infidelities.
I do get messages like this but can still tramp fine via sshx and
multihop ssh/sudo.
>
> and then:
>
> Invalid state: Bogus value for `default-process-coding-system', nil
Sounds remotely familiar.
What are the tramp methods you're using?
Are you using the XEmacs tramp syntax vs. the Emacs tramp syntax?
See
http://www.xemacs.org/Documentation/packages/html/tramp_5.html#SEC20
This look like it:
http://list-archive.xemacs.org/cgi-bin/wilma_hiliter/xemacs-beta/200409/m...
If you do get a lisp errors, then a lisp backtrace would be helpful:
XEmacs <= 21.1
Options->General Options->Debug On Error
XEmacs >= 21.4
Options->Troubleshooting->Debug On Error
Provoke the error again.
If XEmacs hangs, then Debug on Quit
and
C-g (keyboard-quit)
at the point of the hang should give you a backtrace.
Send the *Backtrace* to xemacs-beta(a)xemacs.org.
Good Luck,
Adrian
>
> Anybody knows what's going on, or can help me debug it?
>
> Andrew
>
>
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
5:51 p.m.
On 20 Mar 2005, at 17:38, Adrian Aichner wrote:
Andrew Nesbit <andrew(a)siru.org> writes:
> TRAMP (package version 1.22 from sumo) is unable to find files. I get
> lots of messages like this:
>
> itimer "with-timeout<5>" signaled: (void-function
> with-timeout-handler)
>
> and then:
>
> Invalid state: Bogus value for `default-process-coding-system', nil
Sounds remotely familiar.
What are the tramp methods you're using?
The default one, ssh.
Are you using the XEmacs tramp syntax vs. the Emacs tramp syntax?
XEmacs syntax, i.e.:
C-x C-f /[machine.name]:~/ TAB TAB
etc. Using the Emacs syntax makes efs kick in instead of tramp.
If you do get a lisp errors, then a lisp backtrace would be helpful:
[snip]
Provoke the error again.
XEmacs does not hang. Here are the contents of the *Backtrace* buffer:
Debugger entered--Lisp error: (invalid-state "Bogus value for
`default-process-coding-system'" nil)
signal(invalid-state ("Bogus value for
`default-process-coding-system'" nil))
byte-code("..." [buf data kill-buffer signal] 3)
find-file-noselect("/[ssh/dspmac2.elec.qmul.ac.uk]/Users/andrew/foo")
mapcar(find-file-noselect
("/[ssh/dspmac2.elec.qmul.ac.uk]/Users/andrew/foo"))
find-file-noselect("/[dspmac2.elec.qmul.ac.uk]~/foo" nil nil t)
#<compiled-function (filename &optional codesys wildcards) "...(53)"
[coding-system-for-read wildcards filename codesys value
get-coding-system find-file-noselect nil mapcar switch-to-buffer] 6
1033199 (list (read-file-name "Find file: ") (and current-prefix-arg
...) t)>("/[dspmac2.elec.qmul.ac.uk]~/foo" nil t)
call-interactively(find-file)
HTH,
Andrew
5:59 p.m.
On 20 Mar 2005, at 17:45, Adrian Aichner wrote:
Adrian Aichner <adrian(a)xemacs.org> writes:
> Andrew Nesbit <andrew(a)siru.org> writes:
>
>> itimer "with-timeout<5>" signaled: (void-function
>> with-timeout-handler)
There are some known itimer infidelities.
[snip]
This look like it:
http://list-archive.xemacs.org/cgi-bin/wilma_hiliter/xemacs-beta/
200409/msg00374.html
OK, thanks for pointing that out. So it seems it's a bug in some
uudecode/uuencode tool on the remote Mac OS X.
The itimer bug is still there, though.
Andrew
6:12 p.m.
Sun, 20 Mar 2005 17:59:51 +0000, Andrew Nesbit wrote:
On 20 Mar 2005, at 17:45, Adrian Aichner wrote:
> Adrian Aichner <adrian(a)xemacs.org> writes:
>
>> Andrew Nesbit <andrew(a)siru.org> writes:
>>
>>> itimer "with-timeout<5>" signaled: (void-function
>>> with-timeout-handler)
>
> There are some known itimer infidelities.
[snip]
> This look like it:
> http://list-archive.xemacs.org/cgi-bin/wilma_hiliter/xemacs-beta/
> 200409/msg00374.html
OK, thanks for pointing that out. So it seems it's a bug in some
uudecode/uuencode tool on the remote Mac OS X.
I'm using the workaround for this:
,----[ init.el ]
| (defvar tramp-coding-commands
| '(("mimencode-bad -b" "mimencode-bad -u -b"
| base64-encode-region base64-decode-region)
| ("mmencode-bad -b" "mmencode-bad -u -b"
| base64-encode-region base64-decode-region)
| ("recode data..base64" "recode base64..data"
| base64-encode-region base64-decode-region)
| ("uuencode-bad xxx" "uudecode-bad -o -"
| tramp-uuencode-region uudecode-decode-region)
| ("uuencode-bad xxx" "uudecode-bad -p"
| tramp-uuencode-region uudecode-decode-region)
| ("uuencode-bad xxx" "tramp_uudecode"
| tramp-uuencode-region uudecode-decode-region)
| ("tramp_encode_with_module" "tramp_decode_with_module"
| base64-encode-region base64-decode-region)
| ("tramp_encode" "tramp_decode"
| base64-encode-region base64-decode-region)))
`----
This is only a hack.
--
Regards,
Andrey.
6:18 p.m.
Andrew Nesbit <andrew(a)siru.org> writes:
On 20 Mar 2005, at 17:38, Adrian Aichner wrote:
> Andrew Nesbit <andrew(a)siru.org> writes:
>
>> TRAMP (package version 1.22 from sumo) is unable to find files. I get
>> lots of messages like this:
>>
>> itimer "with-timeout<5>" signaled: (void-function
>> with-timeout-handler)
>>
>> and then:
>>
>> Invalid state: Bogus value for `default-process-coding-system', nil
>
> Sounds remotely familiar.
>
> What are the tramp methods you're using?
The default one, ssh.
Hi!
Another hint:
Get rid of any tramp buffers staying around from previous sessions,
while debugging.
Use
(setq tramp-debug-buffer t)
and see if that reveals any problems in buffers named
*debug tramp/sshx ...
*tramp/sshx ...
or similar.
For the ssh methods I had to specify two -t switches to avoid a
pseudo-terminal not allocated warning.
> Are you using the XEmacs tramp syntax vs. the Emacs tramp syntax?
XEmacs syntax, i.e.:
C-x C-f /[machine.name]:~/ TAB TAB
You're not using that : in the line above, right?
That would not be proper syntax.
etc. Using the Emacs syntax makes efs kick in instead of tramp.
> If you do get a lisp errors, then a lisp backtrace would be helpful:
[snip]
> Provoke the error again.
XEmacs does not hang. Here are the contents of the *Backtrace* buffer:
Debugger entered--Lisp error: (invalid-state "Bogus value for
`default-process-coding-system'" nil)
signal(invalid-state ("Bogus value for
`default-process-coding-system'" nil))
byte-code("..." [buf data kill-buffer signal] 3)
Ah, you should load the .el file instead of the .elc file for a better
*Backtrace*.
Don't know which file it would be in this case, but you could load all
tramp*.el files for debugging.
Good Luck,
Adrian
find-file-noselect("/[ssh/dspmac2.elec.qmul.ac.uk]/Users/andrew/foo")
mapcar(find-file-noselect
("/[ssh/dspmac2.elec.qmul.ac.uk]/Users/andrew/foo"))
find-file-noselect("/[dspmac2.elec.qmul.ac.uk]~/foo" nil nil t)
#<compiled-function (filename &optional codesys wildcards)
"...(53)" [coding-system-for-read wildcards filename codesys value
get-coding-system find-file-noselect nil mapcar switch-to-buffer] 6
1033199 (list (read-file-name "Find file: ") (and current-prefix-arg
...) t)>("/[dspmac2.elec.qmul.ac.uk]~/foo" nil t)
call-interactively(find-file)
HTH,
Andrew
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
7:11 p.m.
On 20 Mar 2005, at 18:18, Adrian Aichner wrote:
Another hint:
Get rid of any tramp buffers staying around from previous sessions,
while debugging.
Hi Adrian. Yes, I've been doing this. In fact, having stale tramp
buffers around often stops it working at all.
Use
(setq tramp-debug-buffer t)
and see if that reveals any problems in buffers named
*debug tramp/sshx ...
*tramp/sshx ...
or similar.
For the ssh methods I had to specify two -t switches to avoid a
pseudo-terminal not allocated warning.
Did you do this on OS X? When I was using GNU Emacs on Jaguar, there
was a bug in the operating system which had to be worked around by
setting process-connection-type to nil (as opposed to its default value
of t). But Apple fixed this in the Panther release, so this workaround
was no longer necessary. Are you referring to this?
Anyway, using sshx doesn't help.
> C-x C-f /[machine.name]:~/ TAB TAB
You're not using that : in the line above, right?
That would not be proper syntax.
Ah, of course not :-) The colon there was just a typo. I should've used
something like cut & paste, or something, instead.
Ah, you should load the .el file instead of the .elc file for a
better
*Backtrace*.
Don't know which file it would be in this case, but you could load all
tramp*.el files for debugging.
OK, I did this by renaming all the *.elc files in the tramp package to
give them a "disable" suffix, and then restarting XEmacs. For my own
future reference, is there a better way than this?
Debugger entered--Lisp error: (invalid-state "Bogus value for
`default-process-coding-system'" nil)
signal(invalid-state ("Bogus value for
`default-process-coding-system'" nil))
byte-code("..." [buf data kill-buffer signal] 3)
find-file-noselect("/[ssh/127.0.0.1]/Users/andrew/README")
mapcar(find-file-noselect ("/[ssh/127.0.0.1]/Users/andrew/README"))
find-file-noselect("/[127.0.0.1]~/README" nil nil t)
#<compiled-function (filename &optional codesys wildcards) "...(53)"
[coding-system-for-read wildcards filename codesys value
get-coding-system find-file-noselect nil mapcar switch-to-buffer] 6
1033199 (list (read-file-name "Find file: ") (and current-prefix-arg
...) t)>("/[127.0.0.1]~/README" nil t)
call-interactively(find-file)
N.B. I've changed my test case, but it the results are essentially the
same.
I've found that disabling the remote uuencode and uudecode command line
tools makes the problem go away. Of course this is not the correct
solution. In this case, the tramp debug buffer shows that their
nonexistence is detected, tramp uses its own encoding/decoding
commands, and then decoding of the requested file is done locally with
base64-decode-region and it's OK.
In the buggy case, the tramp debug buffer shows
# Decoding remote file /[ssh/127.0.0.1]/Users/andrew/README with
function uudecode-decode-region...
at which point the debugger comes on and I see the backtrace.
Is this helpful?
Andrew
8:17 p.m.
Andrew Nesbit <andrew(a)siru.org> writes:
On 20 Mar 2005, at 18:18, Adrian Aichner wrote:
> Another hint:
>
> Get rid of any tramp buffers staying around from previous sessions,
> while debugging.
Hi Adrian. Yes, I've been doing this. In fact, having stale tramp
buffers around often stops it working at all.
> Use
> (setq tramp-debug-buffer t)
> and see if that reveals any problems in buffers named
> *debug tramp/sshx ...
> *tramp/sshx ...
> or similar.
>
> For the ssh methods I had to specify two -t switches to avoid a
> pseudo-terminal not allocated warning.
Did you do this on OS X? When I was using GNU Emacs on Jaguar, there
No, only on Windows XP in a native Windows XEmacs
XEmacs 21.5 (beta20) "cilantro" (+CVS-20050314) [Lucid] (i586-pc-win32, Mule)
of Tue Mar 15 2005 on D5DC120J
was a bug in the operating system which had to be worked around by
setting process-connection-type to nil (as opposed to its default
value of t). But Apple fixed this in the Panther release, so this
workaround was no longer necessary. Are you referring to this?
Nope
Anyway, using sshx doesn't help.
>> C-x C-f /[machine.name]:~/ TAB TAB
>
> You're not using that : in the line above, right?
>
> That would not be proper syntax.
Ah, of course not :-) The colon there was just a typo. I should've
used something like cut & paste, or something, instead.
:-)
> Ah, you should load the .el file instead of the .elc file for a better
> *Backtrace*.
>
> Don't know which file it would be in this case, but you could load all
> tramp*.el files for debugging.
OK, I did this by renaming all the *.elc files in the tramp package to
give them a "disable" suffix, and then restarting XEmacs. For my own
future reference, is there a better way than this?
I would just mark all .el files in dired by extension or regexp, then
do L in dired.
% e runs the command dired-mark-extension
L runs the command dired-do-load
Debugger entered--Lisp error: (invalid-state "Bogus value for
`default-process-coding-system'" nil)
signal(invalid-state ("Bogus value for
`default-process-coding-system'" nil))
byte-code("..." [buf data kill-buffer signal] 3)
find-file-noselect("/[ssh/127.0.0.1]/Users/andrew/README")
mapcar(find-file-noselect ("/[ssh/127.0.0.1]/Users/andrew/README"))
find-file-noselect("/[127.0.0.1]~/README" nil nil t)
#<compiled-function (filename &optional codesys wildcards)
"...(53)" [coding-system-for-read wildcards filename codesys value
get-coding-system find-file-noselect nil mapcar switch-to-buffer] 6
1033199 (list (read-file-name "Find file: ") (and current-prefix-arg
...) t)>("/[127.0.0.1]~/README" nil t)
call-interactively(find-file)
N.B. I've changed my test case, but it the results are essentially the
same.
I've found that disabling the remote uuencode and uudecode command
line tools makes the problem go away. Of course this is not the
correct solution. In this case, the tramp debug buffer shows that
their nonexistence is detected, tramp uses its own encoding/decoding
commands, and then decoding of the requested file is done locally with
base64-decode-region and it's OK.
Now that sounds familiar!
See
https://sourceforge.net/tracker/?func=detail&atid=350001&aid=1052...
where I had issues with mimencode at SourceForge?
In the buggy case, the tramp debug buffer shows
# Decoding remote file /[ssh/127.0.0.1]/Users/andrew/README with
function uudecode-decode-region...
at which point the debugger comes on and I see the backtrace.
Is this helpful?
Yes, thanks.
Andrew
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:53 p.m.
Andrew Nesbit <andrew(a)siru.org> writes:
Did you do this on OS X? When I was using GNU Emacs on Jaguar, there
was a bug in the operating system which had to be worked around by
setting process-connection-type to nil (as opposed to its default value
of t). But Apple fixed this in the Panther release, so this workaround
was no longer necessary. Are you referring to this?
That reminds me the following code snippet from tramp.el:
| ;; Logging in to a remote host normally requires obtaining a pty. But
| ;; Emacs on MacOS X has process-connection-type set to nil by default,
| ;; so on those systems Tramp doesn't obtain a pty. Here, we allow
| ;; for an override of the system default.
| (defcustom tramp-process-connection-type t
| "Overrides `process-connection-type' for connections from Tramp.
| Tramp binds process-connection-type to the value given here before
| opening a connection to a remote host."
|:group 'tramp
|:type '(choice (const nil) (const t) (const pty)))
Maybe you play a little bit with `tramp-process-connection-type'.
[...]
I've found that disabling the remote uuencode and uudecode
command line
tools makes the problem go away. Of course this is not the correct
solution. In this case, the tramp debug buffer shows that their
nonexistence is detected, tramp uses its own encoding/decoding
commands, and then decoding of the requested file is done locally with
base64-decode-region and it's OK.
In the buggy case, the tramp debug buffer shows
# Decoding remote file /[ssh/127.0.0.1]/Users/andrew/README with
function uudecode-decode-region...
That is an indication that `uudecode-decode-region' is not working
correctly for you.
Could you, please, open some text in a buffer, and apply the following
commands:
M-: (tramp-uuencode-region (point-min) (point-max))
M-: (uudecode-decode-region (point-min) (point-max))
Andrew
Best regards, Michael.
9:16 p.m.
On 20 Mar 2005, at 18:12, Andrey Slusar wrote:
I'm using the workaround for this:
,----[ init.el ]
| (defvar tramp-coding-commands
| '(("mimencode-bad -b" "mimencode-bad -u -b"
| base64-encode-region base64-decode-region)
| ("mmencode-bad -b" "mmencode-bad -u -b"
| base64-encode-region base64-decode-region)
| ("recode data..base64" "recode base64..data"
| base64-encode-region base64-decode-region)
| ("uuencode-bad xxx" "uudecode-bad -o -"
| tramp-uuencode-region uudecode-decode-region)
| ("uuencode-bad xxx" "uudecode-bad -p"
| tramp-uuencode-region uudecode-decode-region)
| ("uuencode-bad xxx" "tramp_uudecode"
| tramp-uuencode-region uudecode-decode-region)
| ("tramp_encode_with_module" "tramp_decode_with_module"
| base64-encode-region base64-decode-region)
| ("tramp_encode" "tramp_decode"
| base64-encode-region base64-decode-region)))
`----
This is only a hack.
Thanks for the tip, Andrey. I found that using scp connection method
works well too.
Andrew
4:44 a.m.
>>>> "Andrew" == Andrew Nesbit
<andrew(a)siru.org> writes:
Andrew> OK, thanks for pointing that out. So it seems it's a bug
Andrew> in some uudecode/uuencode tool on the remote Mac OS X.
No, it's a bug in the uudecode library in Gnus, which assumes that
'nil is always a valid coding system pair. In XEmacs it isn't.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
11:48 a.m.
New subject: Bug in gnus/uudecode.el (was: Possible bug in TRAMP?)
On Tue, Mar 22 2005, Stephen J. Turnbull wrote:
>>>>> "Andrew" == Andrew Nesbit
<andrew(a)siru.org> writes:
Andrew> OK, thanks for pointing that out. So it seems it's a bug
Andrew> in some uudecode/uuencode tool on the remote Mac OS X.
No, it's a bug in the uudecode library in Gnus, which assumes that
'nil is always a valid coding system pair. In XEmacs it isn't.
Could you be more specific (which function, ...) and maybe provide a
patch making it compatible with XEmacs, please?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
2:55 p.m.
New subject: Bug in gnus/uudecode.el
>>>> "Reiner" == Reiner Steib
<reinersteib+gmane(a)imap.cc> writes:
> No, it's a bug in the uudecode library in Gnus, which
assumes
> that 'nil is always a valid coding system pair. In XEmacs it
> isn't.
Reiner> Could you be more specific (which function, ...) and maybe
Reiner> provide a patch making it compatible with XEmacs, please?
*sigh* I hate doing this---I don't have very good reason to suppose
this will work for anyone but me---but I don't have time to do it
right. Here's a patch against current XEmacs package CVS, but it
should be pretty close for this ancient protocol.
Index: lisp/uudecode.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/gnus/lisp/uudecode.el,v
retrieving revision 1.3
diff -u -p -r1.3 uudecode.el
--- lisp/uudecode.el 28 Sep 2004 02:21:21 -0000 1.3
+++ lisp/uudecode.el 22 Mar 2005 14:51:09 -0000
＠＠ -99,7 +99,7 ＠＠ (defun uudecode-decode-region-external
(make-temp-name "uu")
uudecode-temporary-file-directory))))
(let ((cdir default-directory)
- default-process-coding-system)
+ (default-process-coding-system '(binary . binary)))
(unwind-protect
(with-temp-buffer
(insert "begin 600 " (file-name-nondirectory tempfile) "\n")
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6980
days inactive
6982
days old
14 comments
6 participants
participants (6)
-
Adrian Aichner -
Andrew Nesbit -
Andrey Slusar -
Michael Albinus -
Reiner Steib -
Stephen J. Turnbull