ACTIVITY SUMMARY (2015-01-06 - 2015-01-13)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
563 open ( +0) / 317 closed ( +0) / 880 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1972 days.
Median duration of open issues: 2138 days.
Open Issues Breakdown
new 255 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi all,
In the process of trying to get some things working properly on my
Mac "Yosemite" box, I noticed that configure.ac is in pretty bad
repair.
In particular, the Makefiles use $c_switch_all in the compile command,
but Installation reports $XE_CFLAGS, which on my box contains only
warnings. I think that the use of various cflag variables is so
confused that it's worth re-thinking the whole thing. For starters,
at least I'd like to change the XE_CFLAGS in the compile command
reported in Installation to c_switch_all.
A second issue is that a lot of changes have been made to the core
configure.ac that are not reflected in the modules' configure.acs.
I think it might be a good idea to move our XEmacs-specific macros to
an aclocal file (or whatever it is), and perhaps macro-fy more of our
special tests.
In preparation for this, I created a patch (attached) which moves all
of the macros defined in configure.ac into the "Local macros" section
(which was already present). (I see I need to improve the ChangeLog.)
I wonder how much of the work done to improve SXEmacs's build process
might be relevant to us.
Comments (and volunteers! -- my autoconf-foo is poor :-/ ) welcome.
Steve
# HG changeset patch
# Parent 6b57aad276aaed84a34704bd39a01984dc60de1e
diff -r 6b57aad276aa ChangeLog
--- a/ChangeLog Sat Jan 10 21:11:10 2015 +0900
+++ b/ChangeLog Sat Jan 10 23:55:16 2015 +0900
@@ -1,3 +1,7 @@
+2015-01-10 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * configure.ac (XE_EXPAND_VARIABLE): Move to other macro definitions.
+
2015-01-10 Stephen J. Turnbull <stephen(a)xemacs.org>
* configure.ac (Postgresql): Improve Installation text.
diff -r 6b57aad276aa configure.ac
--- a/configure.ac Sat Jan 10 21:11:10 2015 +0900
+++ b/configure.ac Sat Jan 10 23:55:16 2015 +0900
@@ -107,6 +107,30 @@
echo " " $1
echo " Use \`$progname --help' to show usage.") >&2 && exit 1])dnl
dnl
+dnl CPP_to_sh(CPP_SYMBOL, SH_VAR, DEFAULT_VALUE)
+define([CPP_to_sh],
+[[#]ifndef [$1]
+[#]define [$1]ifelse([$3],,, [ "$3"])
+[#]endif
+configure___ [$2]=[$1]
+])dnl CPP_to_sh
+dnl
+dnl CPP_boolean_to_sh(CPP_SYMBOL, SH_VAR)
+define([CPP_boolean_to_sh],
+[[#]ifdef [$1]
+configure___ [$2]=yes
+[#]else
+configure___ [$2]=no
+[#]endif
+])dnl CPP_boolean_to_sh
+dnl
+define(COLON_TO_SPACE_WARN,
+ [case "$[$1]" in *:* [)] dnl
+case "$opsys" in *cygwin* [)]
+ echo " WARNING: Paths containing spaces will be misinterpreted." ;;
+esac
+[$1]="`echo '' $[$1] | sed -e 's/^ //' -e 's/:/ /g'`";; esac])dnl
+dnl
dnl PRINT_VAR(var var ...) prints values of shell variables
define([PRINT_VAR],[for var in patsubst([$1],[[
]+],[ ]); do eval "echo \"$var = '\$$var'\""; done])dnl
@@ -234,12 +258,23 @@
dnl
dnl The construct foo=`echo $w1 $w2 $w3` fails on some systems if $w1 = -e or -n
dnl So we use the following instead.
+dnl #### Other macros save the computed value in the 2nd arg, but
+dnl #### XE_SPACE returns the value in the first arg.
dnl XE_SPACE(var, words)
define([XE_SPACE],[
T=""
for W in $2; do if test -z "$T"; then T="$W"; else T="$T $W"; fi; done
$1="$T"
])dnl XE_SPACE
+dnl XE_EXPAND_VARIABLE(original,expanded)
+define([XE_EXPAND_VARIABLE],
+[$2=[$]$1
+while true; do
+ case "[$]$2" in
+ *\[$]* ) eval "$2=[$]$2" ;;
+ *) break ;;
+ esac
+done])dnl XE_EXPAND_VARIABLE
dnl Autoconf 2.59 and 2.60 have slightly different versions of m4_cdr that
dnl return different values for an empty list. XE_CDR is a copy of the 2.60
dnl version which will be used with both versions.
@@ -1087,15 +1122,6 @@
AC_DEFINE(EXEC_PREFIX_USER_DEFINED)
fi
-define([XE_EXPAND_VARIABLE],
-[$2=[$]$1
-while true; do
- case "[$]$2" in
- *\[$]* ) eval "$2=[$]$2" ;;
- *) break ;;
- esac
-done])dnl XE_EXPAND_VARIABLE
-
XE_EXPAND_VARIABLE(prefix,prefix_expanded)
XE_EXPAND_VARIABLE(datadir,datadir_expanded)
XE_EXPAND_VARIABLE(exec_prefix,exec_prefix_expanded)
@@ -1706,23 +1732,6 @@
dnl anyway.
tempcname="conftest.c"
-dnl CPP_to_sh(CPP_SYMBOL, SH_VAR, DEFAULT_VALUE)
-define([CPP_to_sh],
-[[#]ifndef [$1]
-[#]define [$1]ifelse([$3],,, [ "$3"])
-[#]endif
-configure___ [$2]=[$1]
-])dnl CPP_to_sh
-
-dnl CPP_boolean_to_sh(CPP_SYMBOL, SH_VAR)
-define([CPP_boolean_to_sh],
-[[#]ifdef [$1]
-configure___ [$2]=yes
-[#]else
-configure___ [$2]=no
-[#]endif
-])dnl CPP_boolean_to_sh
-
cat > $tempcname < confdefs.h
cat >> $tempcname <<EOF
#define NOT_C_CODE
@@ -5841,14 +5850,6 @@
*nocombreloc*) echo " Linking with \`-z nocombreloc'.
- Consider configuring with --with-pdump." ;;
esac
-
-define(COLON_TO_SPACE_WARN,
- [case "$[$1]" in *:* [)] dnl
-case "$opsys" in *cygwin* [)]
- echo " WARNING: Paths containing spaces will be misinterpreted." ;;
-esac
-[$1]="`echo '' $[$1] | sed -e 's/^ //' -e 's/:/ /g'`";; esac])dnl
-
echo "
Package Search (a 'root' contains '{xemacs,mule,site}-packages'):"
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
PATCH 21.5
On Tue, Jan 6, 2015 at 9:19 AM, Marcus <marcus.harnisch(a)xemacs.org> wrote:
> Jerry James <james(a)xemacs.org> writes:
>
>> Does the compile succeed if you cast to long first, then to int?
>
> Indeed, it does. The secrets of "why" are part of the C++ standard, I
> reckon. I am not even getting a warning despite the fact that casting
> long to int is lossy.
Stephen already explained the whys and wherefores, so I'll just paste
the patch in here for public consideration.
diff -r 9e5f3a0d4e66 lwlib/ChangeLog
--- a/lwlib/ChangeLog Sat Jan 03 16:24:56 2015 +0100
+++ b/lwlib/ChangeLog Wed Jan 07 09:14:09 2015 -0700
@@ -1,3 +1,8 @@
+2015-01-07 Jerry James <james(a)xemacs.org>
+
+ * lwlib-Xaw.c (xaw_scrollbar_scroll): Add typecast to fix g++ build,
+ problem reported by Marcus Harnisch.
+
2013-06-23 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.34 "kale" is released.
diff -r 9e5f3a0d4e66 lwlib/lwlib-Xaw.c
--- a/lwlib/lwlib-Xaw.c Sat Jan 03 16:24:56 2015 +0100
+++ b/lwlib/lwlib-Xaw.c Wed Jan 07 09:14:09 2015 -0700
@@ -613,10 +613,10 @@
return;
id = instance->info->id;
- event_data.slider_value = (int) call_data;
+ event_data.slider_value = (int) (long) call_data;
event_data.time = 0;
- if ((int) call_data > 0)
+ if ((int) (long) call_data > 0)
/* event_data.action = SCROLLBAR_PAGE_DOWN;*/
event_data.action = SCROLLBAR_LINE_DOWN;
else
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
xemacs is crashing at startup with fatal error (11) in opensuse 13.2
see terminal output & core info below:
wilko131@trein-pc:~/ntrein> xemacs
Warning: Missing charsets in String to FontSet conversion
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Your version of XEmacs was distributed with a PROBLEMS file that may
describe
your crash, and with luck a workaround. Please check it first, but do
report
the crash anyway.
Please report this bug by invoking M-x report-emacs-bug, or by selecting
`Send Bug Report' from the Help menu. If that won't work, send ordinary
email to `xemacs-beta(a)xemacs.org'. *MAKE SURE* to include this entire
output from this crash, especially including the Lisp backtrace, as well as
the XEmacs configuration from M-x describe-installation (or equivalently,
the file `Installation' in the top of the build tree).
*Please* try *hard* to obtain a C stack backtrace; without it, we are
unlikely
to be able to analyze the problem. Locate the core file produced as a
result
of this crash (often called `core' or `core.<process-id>', and located in
the directory in which you started XEmacs or your home directory), and type
gdb /usr/bin/xemacs core
then type `where' at the debugger prompt. No GDB on your system? You may
have DBX, or XDB, or SDB. (Ask your system administrator if you need help.)
If no core file was produced, enable them (often with `ulimit -c unlimited')
in case of future reoccurrence of the crash.
Lisp backtrace follows:
# (unwind-protect ...)
# (unwind-protect ...)
# bind (inhibit-quit)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
redisplay-frame(#<x-frame "XEmacs" on #<x-device on ":0.0" 0x2> 0x2>)
# bind (ext gutter-string val inhibit-read-only frame value message)
raw-append-progress-feedback("Fontifying *scratch*..." 0 #<x-frame
"XEmacs" on #<x-device on ":0.0" 0x2> 0x2>)
# bind (tmsg top frame value message label)
append-progress-feedback(font-lock "Fontifying *scratch*..." 0 nil)
# bind (frame value message label)
display-progress-feedback(font-lock "Fontifying *scratch*..." 0)
# bind (str)
# (unwind-protect ...)
# bind (args value fmt label)
progress-feedback-with-label(font-lock "Fontifying %s..." 0 "*scratch*")
# bind (maybe-loudly end beg)
font-lock-default-unfontify-region(1 1 t)
# bind (loudly end beg)
font-lock-unfontify-region(1 1 t)
# bind (was-on font-lock-verbose font-lock-message-threshold aborted)
# (unwind-protect ...)
font-lock-default-fontify-buffer()
# bind (font-lock-verbose)
font-lock-fontify-buffer()
# bind (on-p maximum-size arg)
font-lock-mode(1)
turn-on-font-lock()
# bind (explicit-defaults)
font-lock-set-defaults()
# (unwind-protect ...)
# bind (command-line-args-left)
command-line()
# (condition-case ... . ((t (byte-code " ��" [error-data data nil]
1))))
# bind (error-data)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
Segmentation fault (core dumped)
wilko131@trein-pc:~/ntrein> gdb /usr/bin/xemacs core
GNU gdb (GDB; openSUSE 13.2) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
warning: /etc/gdbinit.d/gdb-heap.py: No such file or directory
Reading symbols from /usr/bin/xemacs...(no debugging symbols found)...done.
[New LWP 2536]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `xemacs'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f7b234ad457 in kill () from /lib64/libc.so.6
Missing separate debuginfos, use: zypper install
xemacs-debuginfo-21.5.34-5.1.11.x86_64
(gdb) quit
Program editing is not possible using my favourate editor xemacs!!
Best wishes,
Wilko Keegstra
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
The Internals manual says:
,-------------------
| The C code is actually written in a dialect of C called "Clean C",
| meaning that it can be compiled, warning-free, with either a C or C++
| compiler.
`-------------------
This doesn't seem to be true for lwlib at least (not that I care about
lwlib specifically -- I just heppened to have used my standard
configure command line). Has anyone actually compiled XEmacs with a
C++ compiler recently and has a recipe that I could borrow?
Thanks
Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2014-12-30 - 2015-01-06)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
563 open ( +0) / 317 closed ( +0) / 880 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1965 days.
Median duration of open issues: 2131 days.
Open Issues Breakdown
new 255 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Ralf Soergel writes:
To post to the list, you need to be a member, or use the
report-xemacs-bug function. These simple tests catch a lot of "new"
spam that gets through the content filters.
Thanks for figuring this out.
> (gdb) ptype ThreeDWidget
> type = struct _ThreeDRec {
> CorePart core;
> SimplePart simple;
> ThreeDPart threeD;
> } *
> (gdb) ptype GaugeWidget
> type = struct _GaugeRec {
> CorePart core;
> SimplePart simple;
> ThreeDPart threeD;
> LabelPart label;
> GaugePart gauge;
> } *
This is as expected.
> GaugeWidget should inherit ThreeDWidget, ok. But the offset of the
> ThreeDPart will depend on the used struct type for dereferencing:
>
> (gdb) p &((GaugeWidget)w)->threeD
> $9 = (ThreeDPart *) 0x210f378
> (gdb) p &((ThreeDWidget)w)->threeD
> $10 = (ThreeDPart *) 0x210f380
>
> this leads to misinterpreted variables in ThreeDPart and below in the
> GaugeWidget and results in SIGSEGV
>
> The different offsets seems result of different versions of the
> SimpleWidgetClass in my runtime loaded /usr/lib64/libXaw3d.so.8 and
> the libXaw3d version at xemacs compile time. See the difference:
Right, I see it now. This is because (at least in my Gentoo system)
when I grepped the /usr/include/X11 tree, there was no #define of
XAW_INTERNATIONALIZATION there, but it's used in many of the widget
struct declarations. So the "Boolean international" declaration isn't
part of the structure as compiled into XEmacs code that accesses the
struct, although apparently it is there in the distributed libraries.
> Maybe in compiling system XAW_INTERNATIONALIZATION was not set
> during build of athena lib, but in my running system it was.
> Also see in include/X11/Xaw3d/SimpleP.h for meaning of
> XAW_INTERNATIONALIZATION
>
> But I don't know how to fix. Do we need a static linked xemacs?
No, we need statically linked Xorg developers. Changing the structure
of SimpleWidget was a bad idea in the first place, but they couldn't
even bother to keep Xaw3d in sync with Xaw. I suspect that
distributors have figured out that they need to build Xaw3d with
XAW_INTERNATIONALIZATION, but it doesn't get defined because there's
no place for it to be defined (it should be in XlibConf.h, I think,
but the regular Xaw doesn't use it).
I don't have time right now, maybe tonight, but you could try
building XEmacs with
./configure <your usual options> XAW_INTERNATIONALIZATION=1
I think the configure test is pretty easy (link to libXaw3d, check if
the w->SimplePart.internationalization member is present, if so,
#define XAW_INTERNATIONALIZATION).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Ar an dara lá de mí Eanair, scríobh Stephen J. Turnbull:
> So while in theory lexical-* code would be the "stablest, most
> reliable" approach, in practice that will be punishing developers
> porting code from GNU Emacs by requiring them to either do the
> necessary analysis for applying dynamic scope to code designed
> assuming lexical binding, or substitute lexical-let and friends for
> the unmarked versions everywhere (which will result in spurious diffs
> and probably a fair number of spurious merge conflicts). Can we
> really afford to do that?
I’ve no particular reason to punish people porting GNU code in that way, and
I think we should support -*- lexbind: t -*- as soon as possible.
I think it is a bad design choice, it makes two functions from two different
versions of the same file more difficult to compare, in a relatively subtle
way that is easy to get wrong, and that is asking for bugs. It is very
confusing to someone non-expert at Emacs Lisp, even people comfortable with
other languages, since dynamic binding is so rare today that they’re
unlikely to be acquainted with the choice. But that’s something to just put
up with, with GNU code that we’re using.
I don’t much care what their plans are, if I did I’d have worried about
Guile support within XEmacs. I care about what their committed code does.
--
‘Tramadol is further fed to cattle […] when working them […] (as draft
animals) so that the animals do not get tired quickly. …’
— Angewandte Chemie, Sept 2014, describing the social context of
(synthetic) tramadol having been found in Cameroon tree roots.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
More and more Emacs packages provide test files based on ert. It might
be useful to have ert provided as XEmacs package, because the tests from
GNU Emacs could run under XEmacs as well.
For example, for me as Tramp maintainer it would be very appreciated to
run ert under XEmacs, because today I cannot apply serious tests with
XEmacs before I release a new Tramp version. With ert, I could apply
tramp-test.el, and I would be much more confident that Tramp works also
with XEmacs.
Opinions?
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta