December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: ``xemacs-21.2-b23'' 24 years, 11 months

Didier Verna

Ben Wing <ben(a)666.com> wrote: > As far as I know, it was Steve who changed the numbering. I've never > liked it, and I suggest we switch back to the old system. Sure. Lemme jsut spam again what I've often said about this: we have a tendency to think in terms of what's more logical or convenient for /us/, and this is bad. We're not the majority of people using XEmacs, the whole bunch of beta testers aren't the majority either. The majority of people use stable releases, and we should try to provide /them/ with a coherent naming convention. So what kind of XEmacs version do these people expect ? - major versions, like 21 with major changes compared to the previous major branch, - minor versions, like 2, with minor changes compared to the previous minor releases within the same major branch, - patch level releases with bug fixes only on the previous major.minor release. I'm sorry but that's all there's to it. Everything else is /our/ problem, not theirs. From their point of view, which is mine on several applications I use, naming conventions that suddenly jump odd or even numbers to indicate an obscure release status which anyway varies from project to project is a total nonsense. Version numbers increase by one and that's all. So the only sensible numbering scheme is - major.minor (minor >= 0) for normal releases, - major.minor.patchlevel (patchlevel > = 1) for bug fixes releases. Then, if we need beta numbers, cvs commits numbers or anything else, let's just make them separate values, and print them like we want, 21.2-b12+6, 21.2 beta 12 cvs 6 or whatever. But let's not fuck up the version numbers with our problems. All of this IMHO obviously, and there's gonna be chuckles if we change the numbering scheme once again anyway... -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

Sumo: 1999-12-11 24 years, 11 months

Andreas Jaeger

I've uploaded again sumo tarballs to ftp.xemacs.org/xemacs/beta/incoming: xemacs-sumo-1999-12-11.tar.gz xemacs-mule-sumo-1999-12-11.tar.gz These files are real sumo tarballs of the current CVS archive of xemacs-packages. I'm planning to upload the single xemacs-packages during the next days. I'd appreciate your testing and comments. Please note that this is an alpha version. For a final release I'd like to hear some comments (especially: everything fine;-) and check the package generation process. Differences to the sumo from 1999-12-09 are: - browse-url bugfix - bash2 is recognised in sh-script I've updated Jan's summary about the package status, here it is: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So what has been in that queue (some patches have been in their so long they had cobwebs all over them) Methusalem patch: - After approximately a year the ps-print patch to make it believe in XEmacs > 19 has been applied. Critical Bug fixes: - jka-compr actually works the first time. - jka-compr, calendar and various other packages actually work under XEmacs-latin1 Super FAQ Fix: - pending-del.el was scandalously forked from the maintainer version to actually work with toolbar-paste Massive Changes: - Speedbar and imenu have had major updates.. - W3 has been updated. - RefTeX 4.09 + A lot of other minor upgrades and fixes. What is _not_ in there (yet) - New version of cperl-mode (volunteer needed) - pgml 1.2.x (volunteer needed) - vcursor.el - Gnus 5.8.x (wait for higher .x?/Volunteer needed) - Your favorite package that you always use your own copy from FSF 20.4/20.5/pre-releease for instead of our version (volunteer needed) - AucTex 9.9 (volunteer needed) - latest ilisp (server unavailable/volunteer need) - de roe. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please test the sumos, send patches and comments. Thanks, Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: XEmacs 21.2.23 crashes when url-insert-file-contents 24 years, 11 months

William M. Perry

Shenghuo ZHU <zsh(a)cs.rochester.edu> writes: > I am using the url package from the CVS. > > When I evaluate > (url-insert-file-contents "http://www.mail-archive.com/lists.html") > XEmacs crashes. > > The lisp backtrace: > > The C backtrace: > > #0 0x4040c4e1 in __kill () > (gdb) where > #0 0x4040c4e1 in __kill () > #1 0x808e884 in fatal_error_signal (sig=6) at emacs.c:276 > #2 <signal handler called> > #3 0xfe90a58d in ?? () > #4 0x4040d868 in abort () at ../sysdeps/generic/abort.c:88 > #5 0x808e7ca in assert_failed () at emacs.c:2825 > #6 0x81331a7 in bufpos_to_bytind_func (buf=0x8852670, x=1025) at insdel.c:581 > #7 0x8133b8a in bufpos_to_bytind (buf=0x8852670, x=1025) at buffer.h:985 > #8 0x80e4cc6 in map_extents (from=1, to=1025, > fn=0x80ea2f0 <report_extent_modification_mapper>, arg=0xbfffdf78, > obj=142943856, after=0x0, flags=15360) at extents.c:2272 > #9 0x80f023d in report_extent_modification (buffer=142943856, start=1, > end=1025, inside=0x8269b34, afterp=1) at extents.c:4697 > #10 0x8135b60 in signal_after_change (buf=0x8852670, start=1, orig_end=1, > new_end=1025) at insdel.c:2298 Eek, looks like a bug in the after-change-hooks processing... anybody familiar enough with the C code there to help? If the new URL stuff is being a bad boy, please let me know. -Bill P.

1 participants
0 comments

process-send-string broken between 21.2.20 and 21.2.22/23 under NT 24 years, 11 months

Dmitry Yaitskov

Hi, On my system, 21.2.22/23 fails while sending base64-encoded data via smtp. Using smtpmail-debug-info, I see that it starts sending lines of base64 encoded data, but after about 100-150 lines (the exact number varies) process-send-string just hangs. C-g cancels it successfully but the message does not get sent of course. This is 100% consistent, at least with a certain zipped file (.zip is around 115k) which I try to send as a mime attachment from gnus. Same gnus, same lisp code (in particular, the same mail-lib package) sends the same file successfully under 21.2.19 and 21.2.20. This is under NT 4.0 sp5, native win32 build. Any help/ideas would be greatly appreciated. Thanks. -- Cheers, -Dima.

2 participants
1 comments

XEmacs 21.2.23 crashes when url-insert-file-contents 24 years, 11 months

ShengHuo ZHU

I am using the url package from the CVS. When I evaluate (url-insert-file-contents "http://www.mail-archive.com/lists.html") XEmacs crashes. The lisp backtrace: The C backtrace: The description of installation: -- Shenghuo

1 participants
0 comments

Re: Give people with crashes more of a clue 24 years, 11 months

Justin Vallon

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > William M. Perry writes: > > Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes: > > > > > Could someone please test this patch before I send it to > > > xemacs-patches? You need to run autoconf after applying this > > > patch. Thanks. > > > > There should probably be some way to turn off these checks, just in case > > they get a false positive. Or a developer _wants_ to compile with known > > bad configurations to try and fix the > > problem. --i-know-what-im-doing-dammit=yes ? > > To someone able to track down a compiler bug and provide workaround, > hacking the configure script is no hurdle at all. If they can't > manage that simple task, then maybe they don't know what they're > doing, dammit. > > As for false positives, we want these to be reported, so adding a > switch to defeat the checks is counterproductive. Another approach would be to boil the mis-compiled code into a short bug-report class of program, and then gcc it during the configure script. If it crashes, or whatever, then gcc has the bug. Then, allow for '--ignore-failed-skip-syntax-test'. -- -Justin vallon(a)mindspring.com

1 participants
0 comments

Re: Xt exits still occurring 24 years, 11 months

Karl Kleinpaste

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Try --with-widgets=athena --with-scrollbar=athena > Athena3D is broken currently. This fixes the progressbars and my hunch > is that it fixes this one too. I tried it, and I just took my 2nd Xt exit since installing. This 2nd time, I had a gdb attached with a breakpoint on exit(). The complaint just prior to exit is generally the same... Error: Widget *Tree* has zero width and/or height ...though sometimes it has complained about Article instead. (I display Group, Summary, Article, and Tree in Gnus.) Stack trace begins: #0 exit (status=1) at exit.c:40 #1 0x2abdfeb3 in _XtDefaultError () #2 0x2abdff2a in XtError () #3 0x2abdfa94 in DefaultMsg () #4 0x2abdfb0b in _XtDefaultErrorMsg () #5 0x2abdfc0e in XtAppErrorMsg () #6 0x2abe9102 in XtCreateWindow () #7 0x2ab0f9fc in Realize () #8 0x2abe8b7b in RealizeWidget () #9 0x2abe8e54 in XtRealizeWidget () #10 0x81d36e5 in TabsChangeManaged (w=0x8a11570) at xlwtabs.c:972 #11 0x2abeba33 in ManageChildren () #12 0x2abebbe2 in XtManageChildren () #13 0x2abebcbb in XtManageChild () #14 0x2abdced9 in XtCreateManagedWidget () #15 0x81cbf6e in xaw_create_label (parent=0x8a11570, val=0x85aa6b8) at lwlib-Xaw.c:773 #16 0x81d2d9d in xlw_update_tab_control (instance=0x898b708, widget=0x8a11570, val=0x859dd38) at lwlib-Xlw.c:406 #17 0x81d2ed9 in xlw_update_one_widget (instance=0x898b708, widget=0x8a11570, val=0x859dd38, deep_p=1) at lwlib-Xlw.c:564 #18 0x81ca072 in lw_modify_all_widgets (id=65802, val=0x859e028, deep_p=1 '\001') at lwlib.c:687 #19 0x81ac278 in x_tab_control_set_property (image_instance=145859336, prop=136982276, val=137695768) at glyphs-x.c:2719 #20 0x812002f in widget_set_property (image_instance=145859336, prop=136982276, val=137695768) at glyphs-widget.c:309 #21 0x810f6d3 in Fset_image_instance_property (image_instance=145859336, prop=136982276, val=137695768) at glyphs.c:1362 #22 0x80908da in Ffuncall (nargs=4, args=0x7fffe844) at eval.c:3178 #23 0x8062929 in execute_optimized_program ( program=0x85d6ac8 "À\t!\002\t\032Ã\f\n\"+\r¬\004Æ \210ÇÈ! É\rÀ\t!\004Ê\t!\"\036\013Ì\016\013ÍÎÏ\n\"#\210Ð\016\013Ñ Ï#))\207W\037\b\031", stack_depth=6, constants_data=0x84bff88) at bytecode.c:743 #24 0x806250e in funcall_compiled_function (fun=139060136, nargs=1, args=0x7fffe9b0) at bytecode.c:519 #25 0x8090a24 in Ffuncall (nargs=2, args=0x7fffe9ac) at eval.c:3210 #26 0x809181f in run_hook_with_args_in_buffer (buf=0x8a96f10, nargs=2, args=0x7fffe9ac, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3661 #27 0x80918fa in va_run_hook_with_args (hook_var=136860140, nargs=1) at eval.c:3674 #28 0x805cd63 in Frecord_buffer (buffer=145321744) at buffer.c:1412 #29 0x80908b4 in Ffuncall (nargs=2, args=0x7fffea78) at eval.c:3178 #30 0x8062929 in execute_optimized_program ( program=0x86a0ce8 "À Á a«\005ÂÃ!\210ÄÁ !«\005ÂÅ!\210Æ\036\a\016\b¬\bÉp!\026\aª\025Ê\016\b!\211\026\a¬\fË\016\b!\026\aÌ\016\a!\210Í \210\016\aq\210\016\016¬\006Ï\016\a!\210ÐÁ À a«\aÑÀ !ª\003Á \016\a\"\210\016\a)\207ß\217¯\023\2019", stack_depth=4, constants_data=0x83e4a30) at bytecode.c:743 "xwininfo -tree" details: xwininfo: Window id: 0x4000029 "emacs: *Summary pgh.opinion*" Root window id: 0x26 (the root window) (has no name) Parent window id: 0x1806da1 (has no name) 1 child: 0x400002a (has no name): () 1267x976+0+0 +5+21 19 children: 0x4000f8b (has no name): () 80x18+0+0 +5+21 1 child: 0x4000f8c (has no name): () 4462x4339+0+0 +6+22 1 child: 0x4000f92 (has no name): () 158x14+1+22 +7+44 0x40002fd (has no name): () 15x661+1248+287 +1253+308 0x4000331 (has no name): () 1244x15+4+258 +9+279 0x40002f2 (has no name): () 15x173+1248+85 +1253+106 0x4000f6e (has no name): () 1259x18+4+67 +9+88 1 child: 0x4000f6f (has no name): () 1259x18+0+0 +9+88 2 children: 0x4000f80 (has no name): () 62655x61393+1+22 +10+110 0x4000f81 (has no name): () 1257x65531+1+22 +10+110 0x400031d (has no name): () 1244x15+4+258 +9+279 0x4000f51 (has no name): () 1259x18+4+67 +9+88 1 child: 0x4000f52 (has no name): () 1259x18+0+0 +9+88 2 children: 0x4000f64 (has no name): () 1257x65531+1+22 +10+110 0x4000f63 (has no name): () 1257x65531+1+22 +10+110 0x4000f12 (has no name): () 1259x18+4+67 +9+88 1 child: 0x4000f13 (has no name): () 1259x18+0+0 +9+88 4 children: 0x4000f87 (has no name): () 62409x61147+1+22 +10+110 0x4000f8a (has no name): () 26211x24949+1+22 +10+110 0x4000f89 (has no name): () 1257x65531+1+22 +10+110 0x4000f88 (has no name): () 9483x8221+1+22 +-65526+-65426 0x4000158 (has no name): () 481x15+4+258 +9+279 0x4000157 (has no name): () 15x173+485+85 +490+106 0x4000177 (has no name): () 15x661+485+287 +490+308 0x4000503 (has no name): () 1244x15+4+258 +9+279 0x40008f9 (has no name): () 1259x18+4+67 +9+88 1 child: 0x40008fa (has no name): () 1259x18+0+0 +9+88 4 children: 0x4000914 (has no name): () 16897x15635+1+22 +10+110 0x4000917 (has no name): () 62617x61355+1+22 +10+110 0x4000916 (has no name): () 62617x61355+1+22 +10+110 0x4000915 (has no name): () 9751x8489+1+22 +10+110 0x40008e6 (has no name): () 1259x18+4+67 +9+88 1 child: 0x40008e7 (has no name): () 1259x18+0+0 +9+88 2 children: 0x40009bd (has no name): () 62617x61355+1+22 +10+110 0x40009bc (has no name): () 1257x65531+1+22 +10+110 0x40008e3 (has no name): () 80x18+0+0 +5+21 1 child: 0x40008e4 (has no name): () 1259x18+0+0 +6+22 4 children: 0x4000910 (has no name): () 4713x3451+1+22 +7+44 0x4000913 (has no name): () 62617x61355+1+22 +7+44 0x4000912 (has no name): () 62499x61237+1+22 +7+44 0x4000911 (has no name): () 62617x61355+1+22 +7+44 0x40008d3 (has no name): () 1259x18+4+67 +9+88 1 child: 0x40008d4 (has no name): () 1259x18+0+0 +9+88 4 children: 0x40009d2 (has no name): () 62625x61363+1+22 +10+110 0x40009d5 (has no name): () 1257x65531+1+22 +10+110 0x40009d4 (has no name): () 11287x10025+1+22 +10+110 0x40009d3 (has no name): () 50205x48943+1+22 +10+110 0x400003a (has no name): () 80x18+0+0 +5+21 1 child: 0x400003b (has no name): () 1259x18+0+0 +6+22 4 children: 0x4000e8f (has no name): () 12837x11575+1+22 +7+44 0x4000e92 (has no name): () 8231x6969+1+22 +7+44 0x4000e91 (has no name): () 42141x40879+1+22 +7+44 0x4000e90 (has no name): () 12837x11575+1+22 +7+44 0x400002c (has no name): () 1267x950+0+26 +5+47 0x400002b (has no name): () 1265x24+0+0 +5+21 Once again, the widget being twiddled in frame #17 and higher (widget=0x8a11570) is not present in the xwininfo dump at all. In fact, it may be a garbage value, assuming these values are supposed to be related in the 1st place, since all the hex idents in the xwininfo dump are of the form 0x4000???. Linux RH6.0 XFree 3.3.5 "./configure --with-pop --with-mule --with-widgets=athena --with-scrollbars=athena" I'm disabling tabs again for now... --karl

1 participants
0 comments

Re: [BTS] unloading of auto-save.el 24 years, 11 months

Hrvoje Niksic

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > I'm not quite sure what to do about this... > any comments? [...] > With the advent of the package system in XEmacs 21.1, the file > auto-save.el moved from the "packages" subdirectory of the old lisp > hierarchy to the core lisp directory, where it is now loaded as part > of the default XEmacs build process; unlike past versions, you get > auto-save.el whether you want it or not. > > I don't particularly like/want the added auto-save.el functionality, > so I tried Greg, what exactly is your problem with auto-save.el? The way I see it, it doesn't do anything naughty by default; in fact, most people never noticed the transition. If you want auto-saving turned off, just set `auto-save-default' to nil. Is there anything particular that the old auto-save.el code did better than the new one? (I believe auto-save.el was added partly because of better support for MS Windows, which old routines didn't handle gracefully.)

1 participants
0 comments

Re: [BTS] unloading of auto-save.el 24 years, 11 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > [Greg writes] > > > I don't particularly like/want the added auto-save.el functionality, > > so I tried > > I'm not quite sure what to do about this... Ask him what he doesn't like about the auto-save.el. I thought it was by default compatible with the files.el stuff. jan

1 participants
0 comments

[BTS] unloading of auto-save.el 24 years, 11 months

Gunnar Evermann

I'm not quite sure what to do about this... any comments?

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta December 1999