3:36 p.m.
Mats Lidell writes:
might not be installed, but... It is the byte compilations that
fails. Shouldn't the byte compiler do its job regardless of what
features the xemacs-binary is configured with and regardless of what
OS environment there is as long as the package tree is installed so
that all elips-files are available?
No. "eval-when-compile" means that code can be run at compile time.
In particular, x-symbol is trying to make X bitmap glyphs on a no-X
build, inside an eval-when-compile (see x-symbol-vars.el).
Try evaluating
(canonicalize-spec-list `(((x) . [xbm :data (6 20 ,(make-string 20 0))])
((mswindows)
. [xbm :data (6 20 ,(make-string 20 0))])
((tty) . [string :data " "]))
'image)
in your 21.5 build.
This
(make-glyph `(((mswindows) . [bmp :data (6 20 ,(make-string 20 0))])
((tty) . [string :data " "])))
gives me "Invalid specifier locale (mswindows)" in my Linux build. So
it seems that glyph is actually tried to be instantiated, but why this
doesn't work I'm not sure. My guess is that the thing to do for now
is to remove the eval-when-compile from the make-glyph call in
x-symbol-vars.el, although that code probably should work.
The 21.4 build isn't failing in the byte compiler. The event loop is
somehow broken. It's trying to get events from a file descriptor that
claims to be a console (ie, a tty) but it somehow isn't. See l. 147
of src/event-tty.c.
I'm not sure why this would happen. You could try putting
if (!c) fprintf (stderr, "failing on FD #%d", i);
before the assert on l. 147 and see which FD is causing problems.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
6:39 p.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
Ar an cúigiú lá is fiche de mí Iúil, scríobh Stephen J. Turnbull:
Mats Lidell writes:
> might not be installed, but... It is the byte compilations that
> fails. Shouldn't the byte compiler do its job regardless of what
> features the xemacs-binary is configured with and regardless of what
> OS environment there is as long as the package tree is installed so
> that all elips-files are available?
No. "eval-when-compile" means that code can be run at compile time.
In particular, x-symbol is trying to make X bitmap glyphs on a no-X
build, inside an eval-when-compile (see x-symbol-vars.el).
Try evaluating
(canonicalize-spec-list `(((x) . [xbm :data (6 20 ,(make-string 20 0))])
((mswindows)
. [xbm :data (6 20 ,(make-string 20 0))])
((tty) . [string :data " "]))
'image)
in your 21.5 build.
This
(make-glyph `(((mswindows) . [bmp :data (6 20 ,(make-string 20 0))])
((tty) . [string :data " "])))
gives me "Invalid specifier locale (mswindows)" in my Linux build.
I get exactly the same on Cygwin with mswindows support; that error is
misleading, you also get it if your instantiator syntax is incorrect, as
happens to be the case here. This syntax works, though, and also doesn’t
provoke any complaints on FreeBSD:
(make-glyph `(((mswindows) . [xbm :data (6 20 ,(make-string 20 0))])
((tty) . [string :data " "])))
On FreeBSD, when I build without X11 support, I can provoke the error that
is blocking the build on evaluating the code in x-symbol-vars.el. Mats, I
suspect, but haven’t confirmed, that the following will allow the build to
continue, I can certainly evaluate it without problems:
--- x-symbol-vars.el~ 2010-07-25 17:58:39.000000000 +0100
+++ x-symbol-vars.el 2010-07-25 17:53:53.000000000 +0100
＠＠ -1099,7 +1099,8 ＠＠
:group 'x-symbol-input-init)
(defvar x-symbol-heading-strut-glyph
- (make-glyph (eval-when-compile
+ (make-glyph (remove-if-not
+ #'(lambda (spec) (valid-instantiator-p (cdr spec) 'image))
`(((x) . [xbm :data (6 20 ,(make-string 20 0))])
((mswindows) . [xbm :data (6 20 ,(make-string 20 0))])
((tty) . [string :data " "]))))
We also really should apply something like the following in specifier.el,
which would have made the whole thing a lot easier to debug (misleading
error messages never make anything easy):
diff -r f3eca926258e lisp/specifier.el
--- a/lisp/specifier.el Sat Jul 24 17:38:35 2010 +0100
+++ b/lisp/specifier.el Sun Jul 25 18:30:02 2010 +0100
＠＠ -105,13 +105,16 ＠＠
;; this will signal an appropriate error.
(check-valid-instantiator inst-pair specifier-type)))
- ((and (valid-specifier-tag-p (car inst-pair))
- (valid-instantiator-p (cdr inst-pair) specifier-type))
+ ((not (valid-instantiator-p (cdr inst-pair) specifier-type))
+ (if noerror
+ t
+ (check-valid-instantiator (cdr inst-pair) specifier-type)))
+
+ ((valid-specifier-tag-p (car inst-pair))
;; case (b)
(cons (list (car inst-pair)) (cdr inst-pair)))
- ((and (valid-specifier-tag-set-p (car inst-pair))
- (valid-instantiator-p (cdr inst-pair) specifier-type))
+ ((valid-specifier-tag-set-p (car inst-pair))
;; case (c)
inst-pair)
＠＠ -199,9 +202,12 ＠＠
(if (not (valid-specifier-locale-p (car spec)))
;; invalid locale.
- (if noerror t
- (signal 'error (list "Invalid specifier locale" (car spec))))
-
+ (if noerror
+ t
+ (if (consp (car spec))
+ ;; If it's a cons, they're probably not passing a locale.
+ (error 'invalid-argument "Not a valid instantiator list" spec)
+ (error 'invalid-argument "Invalid specifier locale" (car spec))))
;; case (b)
(let ((result (canonicalize-inst-list (cdr spec) specifier-type
noerror)))
So it seems that glyph is actually tried to be instantiated, but why
this
doesn't work I'm not sure. My guess is that the thing to do for now is to
remove the eval-when-compile from the make-glyph call in
x-symbol-vars.el, although that code probably should work.
That eval-when-compile doesn’t come into it; because a top-level (require
'x-symbol-vars) is in x-symbol.el, and because top-level #'require has an
implicit surrounding (eval-when-compile ...), x-symbol-vars.el gets loaded
at compile time, and the top-level code there gets run.
The 21.4 build isn't failing in the byte compiler. The event
loop is
somehow broken. It's trying to get events from a file descriptor that
claims to be a console (ie, a tty) but it somehow isn't. See l. 147
of src/event-tty.c.
I'm not sure why this would happen. You could try putting
if (!c) fprintf (stderr, "failing on FD #%d", i);
before the assert on l. 147 and see which FD is causing problems.
I’ve no real idea what’s happening with this, though.
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
12:09 a.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> No. "eval-when-compile" means that code can be run at compile
time.
Stephen> In particular, x-symbol is trying to make X bitmap glyphs on a no-X
Stephen> build, inside an eval-when-compile (see x-symbol-vars.el).
Aha. Missed that but isn't that evil. We need to build the packages on
a machine that has all features, but having both X and mswindows at
the same time isn't possible... but I guess I'm missing something
basic here.
Stephen> Try evaluating ...
Stephen> This ...
Stephen> [...]
I need to sleep on this. Maybe I get it tomorrow.
Stephen> The 21.4 build isn't failing in the byte compiler. The event loop is
Stephen> somehow broken. It's trying to get events from a file descriptor that
Stephen> claims to be a console (ie, a tty) but it somehow isn't. See l. 147
Stephen> of src/event-tty.c.
Yes. I know. The odd thing is that when I try to recreate by running
the same build, on the same machine, in a copy of the package tree,
using the same 21.4.22 binary, I don't get that error. It breaks on
the x-symbol thing as the 21.5 build.
Stephen> I'm not sure why this would happen. You could try putting
Stephen> if (!c) fprintf (stderr, "failing on FD #%d", i);
Stephen> before the assert on l. 147 and see which FD is causing problems.
OK. I'll try that.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
3:59 a.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
Mats Lidell writes:
Aha. Missed that but isn't that evil. We need to build the
packages on
a machine that has all features, but having both X and mswindows at
the same time isn't possible... but I guess I'm missing something
basic here.
Aidan has a better grasp of details than I do, read his posts. I
think there's still a puzzle piece missing, specifically it seems that
the order of the instantiators matters.
Yes. I know. The odd thing is that when I try to recreate by running
the same build, on the same machine, in a copy of the package tree,
using the same 21.4.22 binary, I don't get that error.
I think that what is probably happening is that XEmacs is being run as
a subprocess of some program that doesn't close unneeded file
descriptors before forking XEmacs -- and then does close them later.
Why this hasn't been a problem in the past I'm not sure; perhaps it
has to do with multicore architectures becoming common.
Eg, are you perhaps running make -j N for N > 1?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
5:36 p.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> Aidan has a better grasp of details than I do, read his
Stephen> posts. I think there's still a puzzle piece missing,
Stephen> specifically it seems that the order of the instantiators
Stephen> matters.
Well I will try to read both of your posts again.
Just a quick report here that the patch aidan supplied made the 21.5
build pass when run in a debug environment. (a copy of the smoktest
setup on the same machine.)
Stephen> I think that what is probably happening is that XEmacs is
Stephen> being run as a subprocess of some program that doesn't close
Stephen> unneeded file descriptors before forking XEmacs -- and then
Stephen> does close them later. Why this hasn't been a problem in the
Stephen> past I'm not sure; perhaps it has to do with multicore
Stephen> architectures becoming common.
Interesting idea. In fact the current machine is a virtual thing with
just one CPU assigned. The old server was a multi CPU thing. Maybe
there is some limit when run through cron that isn't there when run in
a login shell!?
Stephen> Eg, are you perhaps running make -j N for N > 1?
No. I haven't taken that bold step yet. I have assumed that the
makefiles for the smoketest isn't prepared for that. (And on the
current machine would do much good either.)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
5:57 p.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
Ar an séú lá is fiche de mí Iúil, scríobh Mats Lidell:
[...] Just a quick report here that the patch aidan supplied made
the
21.5 build pass when run in a debug environment. (a copy of the smoktest
setup on the same machine.)
OK; I’ll commit that change, then.
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
11:48 p.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> I'm not sure why this would happen. You could try putting
Stephen> if (!c) fprintf (stderr, "failing on FD #%d", i);
Stephen> before the assert on l. 147 and see which FD is causing problems.
I get FD #0 => stdin!? Ideas?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
6:53 a.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
Stephen> I'm not sure why this would happen. You could try putting
Stephen> if (!c) fprintf (stderr, "failing on FD #%d", i);
Stephen> before the assert on l. 147 and see which FD is causing problems.
I get FD #0 => stdin!? Ideas?
YOW! That "!?" is definitely justified. I have no idea! :-/
Maybe stdin is getting closed because it's backgrounded? But why
wouldn't this have blown up in the past? Why does X matter?
*sigh*
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
10:25 a.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> Maybe stdin is getting closed because it's backgrounded? But
Stephen> why wouldn't this have blown up in the past? Why does X
Stephen> matter?
I started a forced rebuild build from a terminal and then it worked
fine. So it is likely something with the background thing.
Both no-mule builds does then crash on the "Symbol's value as variable
is void: mouse-yank-function" that I have reported earlier. No
suggestions on that issue?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
11:24 a.m.
New subject: [COMMIT] Apply Stephen's bugfix to my advice.el changes
Ar an naoú lá is fiche de mí Iúil, scríobh Stephen J. Turnbull:
Mats Lidell writes:
> >>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
>
> Stephen> I'm not sure why this would happen. You could try putting
> Stephen> if (!c) fprintf (stderr, "failing on FD #%d", i);
> Stephen> before the assert on l. 147 and see which FD is causing problems.
>
> I get FD #0 => stdin!? Ideas?
YOW! That "!?" is definitely justified. I have no idea! :-/
Maybe stdin is getting closed because it's backgrounded? But why
wouldn't this have blown up in the past? Why does X matter?
Different event loops. If XEmacs is built with X11 support, event-Xt.c is
used even when running headless on the TTY. I saw matter this years ago when
a non-X11 build would drop input characters on the TTY while an X11 build
wouldn’t--see http://hg.debian.org/hg/xemacs/xemacs/rev/0c544f2f566c .
I doubt it’s that specific issue this time, but it’s probably something in
event-tty.c.
*sigh*
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
5228
days inactive
5234
days old
9 comments
3 participants
participants (3)
-
Aidan Kehoe -
Stephen J. Turnbull -
The XEmacs Package Smoketest