December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

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

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > jan wrote > > > Are you sure about that? Sorry, I was unclear (wrong citing). I meant "are you sure about it crashing in report_extent_modification_mapper?". I am fairly sure it already crashes before we get that far (i.e. in the buftos to bytind conversions in map_entent). Jan

1 participants
0 comments

Uploaded vhdl 3.30 as xemacs-package 24 years, 11 months

Andreas Jaeger

I've uploaded vhdl 3.30 as xemacs-packages to ftp.xemacs.org/xemacs/beta/incoming. The package has the name: vhdl-1.10-pkg.tar.gz Please give it (and also the other packages) some testing before I make it official. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: Jobs assignments 24 years, 11 months

Gunnar Evermann

Terje Bless <link(a)tss.no> writes: > On 11.12.99 at 23:56, Martin Buchholz <martin(a)xemacs.org> wrote: > > >rms explicitly denies XEmacs developers [...] access to the Emacs > >pre-testers list. > > Say what??!?! It's true. The same happened to me when I offered to check whether bugs we fix in XEmacs also exist in Emacs > I'm probably showing my ignorance here but why the hell would he want to do > that? Free Software for all... ...unless you happen to be on his shitlist? I am not going to quote RMS's email but what he said basically comes done to: - Lucid released code from an unreleased GNU Emacs - he considers XEmacs and FSF Emacs to be rivals - we can use his code, but he can't use ours maybe this also illustrates why the FSFmacs-XEmacs merge is not going to happen anytime soon... Gunnar

3 participants
2 comments

Re: Scanning FSF 20.5 for fixes.. 24 years, 11 months

Andreas Jaeger

>>>>> Martin Buchholz writes: >>>>> "AJ" == Andreas Jaeger <aj(a)suse.de> writes: AJ> Btw. we check for < 70 but shouldn't we check for < 69? AFAIK the AJ> rule is that 69-99 refers to the twentieth century. Martin> According to what standard? That's the way we handle it in glibc: /* The "Year 2000: The Millennium Rollover" paper suggests that values in the range 69-99 refer to the twentieth century. */ and glibc is standard enough for me ;-) Martin> It seems `obvious' to me that a 2-digit year specification should use Martin> a +-50 year window from the *current* date. Another possibility is to Martin> look backwards in time 67 years, forward 33 years, since people live Martin> more in the distant past than the distant future. Martin> ``Ah, yes... I remember, way back in '45, when the war was finally over...'' Martin> But I'm not seriously suggesting we implement that. Martin> Martin -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: First Packages *TEST* release 24 years, 11 months

Andreas Jaeger

Hi Jeff, I'm including xemacs-beta in my reply in the hope to get some help from there. >>>>> Jeff Miller writes: > two quick observations about the test packages. > *) the new ispell package does not work with aspell, an ispell replacement. > <http://metalab.unc.edu/kevina/aspell/>. I have not investigated > much, it appears to start up then bomb out with an error 255. I'm > guessing some type of command line switch changed, but am not sure at > this point. Could you check this, please? > *) I did not update gnus, since I was running pgnus. But starting up > a new xemacs after updating packages caused a massive core dump. It > appears to have been related to the progress bar thing. I recompiled > with scrollbars and widgets = athena and the core dump went away. > which package changed to make pgnus use the progress bar thingie? No idea. I haven't seen that myself. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Memory leaks in 21.2 when using menubar 24 years, 11 months

Martin Buchholz

Andy, I think this is your area. Could you look at this? Popping up menu items on the menubar creates many memory leaks like this: * This memory was allocated from: malloc [rtlib.o] xmalloc [alloc.c:280] xstrdup [alloc.c:376] button_item_to_widget_value [gui-x.c:343] menu_item_descriptor_to_widget_value_1 [menubar-x.c:137] menu_item_descriptor_to_widget_value_1 [menubar-x.c:304] menu_item_descriptor_to_widget_value_1 [menubar-x.c:304] menu_item_descriptor_to_widget_value_1 [menubar-x.c:304] menu_item_descriptor_to_widget_value [menubar-x.c:352] compute_menubar_data [menubar-x.c:528] set_frame_menubar [menubar-x.c:571] x_initialize_frame_menubar [menubar-x.c:631] x_create_widgets [frame-x.c:1989] x_init_frame_1 [frame-x.c:2176] Fmake_frame [frame.c:389] Ffuncall [eval.c:3178] execute_optimized_program [bytecode.c:743] funcall_compiled_function [bytecode.c:519] Ffuncall [eval.c:3210] execute_optimized_program [bytecode.c:743] funcall_compiled_function [bytecode.c:519] Ffuncall [eval.c:3210] execute_optimized_program [bytecode.c:743] funcall_compiled_function [bytecode.c:519] Feval [eval.c:3034] condition_case_1 [eval.c:1630] top_level_1 [cmdloop.c:202] internal_catch [eval.c:1305] initial_command_loop [cmdloop.c:281] xemacs_21_2_b23_sparc_sun_solaris2_6 [emacs.c:1898] main [emacs.c:2323] _start [crt1.o]

2 participants
1 comments

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

Martin Buchholz

Somewhere along the line we renamed the 21.2 tarballs from xemacs-21.2-b3.tar.gz to xemacs-21.2.16.tar.gz Is the current naming convention documented? Is it a bug that xemacs is still *installed* into directories with names like xemacs-21.2-b23 ?? ObPatch (completely untested): --- configure.in 1999/12/08 07:43:35 1.111.2.53 +++ configure.in 1999/12/09 12:17:43 ＠＠ -954,12 +954,11 ＠＠ AC_DEFINE_UNQUOTED(EMACS_MAJOR_VERSION, $emacs_major_version) AC_DEFINE_UNQUOTED(EMACS_MINOR_VERSION, $emacs_minor_version) if test -n "$emacs_beta_version" ; then + version="${version}.${emacs_beta_version}" if test "$beta" = "yes"; then - version="${version}-b${emacs_beta_version}" - AC_DEFINE_UNQUOTED(EMACS_BETA_VERSION, $emacs_beta_version) + AC_DEFINE_UNQUOTED(EMACS_BETA_VERSION, $emacs_beta_version) else - version="${version}.${emacs_beta_version}" - AC_DEFINE_UNQUOTED(EMACS_PATCH_LEVEL, $emacs_beta_version) + AC_DEFINE_UNQUOTED(EMACS_PATCH_LEVEL, $emacs_beta_version) fi fi AC_DEFINE_UNQUOTED(XEMACS_CODENAME, "$xemacs_codename")

3 participants
2 comments

21.2.20 crash 24 years, 11 months

Marcus Thiessel

Never seen such a strange stack trace. I was pressing button1 to drag the scrollbar here and there. --Marcus #0 0xc01eb938 in kill () from /usr/lib/libc.2 #1 0xa0db8 in fatal_error_signal () #2 <signal handler called> #3 0xc0f12ecc in () from /usr/lib/X11R6/libXt.3 #4 0xc0f3fa00 in CallSetValues () from /usr/lib/X11R6/libXt.3 #5 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #6 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #7 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #8 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #9 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #10 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #11 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #12 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #13 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #14 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #15 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #16 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #17 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #18 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #19 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #20 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #21 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #22 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #23 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #24 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #25 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #26 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #27 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #28 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #29 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #30 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #31 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #32 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #33 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #34 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #35 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #36 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #37 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #38 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #39 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #40 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #41 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #42 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #43 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #44 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #45 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #46 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #47 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #48 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #49 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #50 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #51 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #52 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #53 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #54 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #55 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #56 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #57 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #58 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #59 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #60 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #61 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #62 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3 #63 0xc0f3ff8c in XtSetValues () from /usr/lib/X11R6/libXt.3 #64 0x24c080 in x_resize_subwindow () #65 0x16db8c in Fresize_subwindow () ---Type <return> to continue, or q <return> to quit--- #66 0xae5a8 in Ffuncall () #67 0x6c4f0 in $gntt_label () Lisp backtrace follows: resize-subwindow(#<image-instance (widget) on #<x-device on "tmbbwmt:0.0" 0x2199> (#<face default "default face">)Buffers 843x25 on #<x-frame > 0x40ae2a00 0x84d5> 843 nil) # bind (inst locale frame-or-buffer) update-tab-in-gutter(#<buffer "*Article*">) select-window(#<window on "*Article*" 0x84d3>) # bind (window) #<compiled-function (window) "...(10)" [select-window window lazy-lock-mode lazy-lock-fontify-window] 2>(#<window on "*Article*" 0x84d3>) # bind (walk-windows-current walk-windows-start device all-frames minibuf proc) walk-windows(#<compiled-function (window) "...(10)" [select-window window lazy-lock-mode lazy-lock-fontify-window] 2> no-minibuf nil) byte-code("..." [walk-windows #<compiled-function (window) "...(10)" [select-window window lazy-lock-mode lazy-lock-fontify-window] 2> no-minibuf lazy-lock-walk-windows all-frames] 5) # (condition-case ... . ((wrong-type-argument (byte-code "âedê#ô û áéó \"" ... 4)))) # (unwind-protect ...) # bind (original-window) # (unwind-protect ...) lazy-lock-fontify-walk-windows() lazy-lock-pre-idle-fontify-windows() # (condition-case ... . error) # (unwind-protect ...) scrollbar-vertical-drag((#<window on "*Article*" 0x84d3> . 2035)) # (condition-case ... . error) # (catch top-level ...) [1] - Bus error(coredump)

3 participants
2 comments

Incompatibility 24 years, 11 months

ShengHuo ZHU

The attached file can be compiled in Emacs 20.5 but not in XEmacs 21.2.23. Any ideas? -- Shenghuo

2 participants
1 comments

Re: Incompatibility 24 years, 11 months

Hrvoje Niksic

Shenghuo ZHU <zsh(a)cs.rochester.edu> writes: > The attached file can be compiled in Emacs 20.5 but not in XEmacs > 21.2.23. Any ideas? Idea: the code is broken. The (function NAME) special form is supposed to return the lexically apparent function definition of NAME, where NAME may be a symbol or a lambda expression. In Emacs, this boils down to just returning NAME unevaluated. What you're trying to do is, when you strip read-time syntactic sugar, the following: (function (backquote (lambda (arg2) (\, arg1)))) Obviously, the argument to FUNCTION is neither a symbol nor a lambda expression. The interpreter groks it because `function' is exactly the same as `quote'. The compiler needs to do more analysis, which is why it gets to complain more. What you want to do is: (defun test-func (arg1) `(lambda (arg2) ;; code here ,arg1)) The problem here is that the `;; code here' part will not be compiled. If you don't have compunctions about using CL-isms, you can do this: (defun test-func (arg1) (lexical-let ((arg1 arg1)) (lambda (arg2) ;; code here, does get compiled. arg1))) When elisp becomes lexically scoped, the `lexical-let' part will not be necessary.

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