July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Michael Sperber

Sorry about me dropping off the discussion so suddenly. I caught a virus while in Copenhagen on business. That, together with only very sporadic net connectivity, and a paper deadline on Friday, just about did me in. I'll try to update the Web pages on Scheme and Common Lisp first, and then try to answer some of the questions raised. A lot of backlog to wade through ... -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

build-report problem 26 years, 2 months

Larry Ayers

list, but didn't prepend any comments to the report (generated by build-report 1.35) due to an odd intermittent problem. Occasionally my build reports have had one or more lines lost somewhere in the mailing process, always the first lines of any comments I'd made just before the generated report stuff. At first I thought it may have been a problem with sendmail, but no other mailer seems to be affected. Has any one else experienced this, or have suggestions for tracking down the problem? The Zhong Wei release is working well here; the only problem I've seen is that during the build I see the following error message: While compiling toplevel forms in file /usr/local/src/xemacs-21.0-b48/lisp/finder-inf.el: !! Invalid read syntax ((". in wrong context")) I'm using egcs 1.03 on a Debian 2 (libc6) system, if that makes a difference. Thanks for any help which might be forthcoming! Larry -- ~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= *o Larry Ayers <layers(a)marktwain.net> *o*o o*o *o* *o*o Knox County, Missouri Troublesome Creek Watershed *o =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

1 participants
0 comments

Re: scheme - my opinion 26 years, 2 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >> 1. Do the respective standards specify things (like behavior > >> of text objects) that we would prefer to specify ourselves? > >> (Neither camp has said anything about this AFAIK.) If so, this > >> is harmful to ease of migration. > > Hrvoje> Neither CL nor Scheme contain descriptions of "text > Hrvoje> objects", I think. > > By "text objects" I mean characters, strings, buffers, extents, and > other things that I don't know about or possibly don't exist yet that > are used to contain and manipulate text. They surely do define some > of the above. I think both specify characters as strings, as you surely guessed. > >> 2. What constructs in one dialect would be difficult or > >> impossible to implement efficiently in the other? > > Hrvoje> Why is this an issue? I don't *want* to implement Scheme > Hrvoje> in CL, nor do I want to implement CL in Scheme. > > Some people _are_ thinking in those terms. So it's an issue. > Closed, from your standpoint. Still open, from mine. Can you name some of these people? What exactly do they want to achieve by implementing CL in Scheme, or vice versa? And what does that have to do with what we are discussing here (extension language for XEmacs)? > >> This is especially important if we hope to offload Lisp engine > >> maintenance, as Bruno has offered to do for CLisp. > > Hrvoje> Bruno already maintains clisp, no matter what we do. What > Hrvoje> he offered to do is help us implement the additional > Hrvoje> Emacs-specific stuff within clisp, such as > Hrvoje> `DEFINE_LRECORD_IMPLEMENTATION' lookalikes. > > Are you implying that he doesn't plan to help maintain them? Maintain what? XEmacs? No. Clisp? Yes. Provide extensions to clisp so that XEmacs is easier to maintain? Yes, or so he told me. > I'm trying to get an understanding of the advantages and > disadvantages of the dialects. When you take advantage of my > ignorance to be legalistic like that, it doesn't build my confidence > in your position. I have no idea what you mean here. I haven't "taken advantage" of you. You noticed that Bruno should maintain font-lock.c, and I said he shouldn't. I see no reason in this world why clisp maintainer should maintain XEmacs code. > Can we assert with some confidence that we will be able to depend on > a separately-maintained Common Lisp engine, presumably CLisp, or > not? That would be the whole point of the move. > We _know_ we're going to have to extend and maintain a Scheme > engine, Huh? We only have to extend it, not maintain it. > >> If we can get coroutines and threads as cheaply as Michael > >> suggests, that is a _big_ deal. > > Hrvoje> I'm afraid we can't. > > And I'm afraid of maintaining the > ":not-when-otherwise-not-because-it-just-might-possibly" keyword, and > all its brethren. Bruno does that already, or whoever maintains the Lisp substrate. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Personifiers Unite! You have nothing to lose but Mr. Dignity!

3 participants
2 comments

Re: Jens Lautenbacher, GIFs in xmine 26 years, 2 months

Jens Lautenbacher

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: > > sb> [Apologies in advance for the SPAM] > sb> Does anyone have a current email address for Jens? <jens(a)metrix.de> > sb> is bouncing. > > Here's what my BBDB has: > > Jens Lautenbacher > net: jens(a)tellux.de, jens(a)lemming0.lem.uni-karlsruhe.de, > jens(a)lemcbed.lem.uni-karlsruhe.de, jens(a)metrix.de > timestamp: 13 Dec 1997 > Of all these addresses, only the metrix one will surely bounce.... the other ones should all work, but best thing is to use jens(a)tellux.de. I'll try to post a bit more again into xemacs-beta :-) jtl

1 participants
0 comments

Re: Obsolescence -- I like `eval-current-buffer' 26 years, 2 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes: > SL Baur <steve(a)xemacs.org> writes: >> Ben Wing <ben(a)666.com> writes: >> >> > yes yes yes and these too (all pre-19.12 I think): >> ... >> > (define-obsolete-function-alias 'eval-current-buffer 'eval-buffer) >> >> Is there anyone else who would like to see this *un*obsoleted? > In FSF Emacs, `eval-current-buffer' is an alias to `eval-buffer', and > their `eval-buffer' does not take a BUFFER argument. Ah, I suppose I should have checked that. > I think we should keep `eval-buffer' the way we have it, and > unobsolete and document `eval-current-buffer'. So yes, I agree with > you. The current policy being enforced is this: 1. If a symbol in XEmacs has been renamed, but the old name exists and is in active usage in FSF Emacs, it is (make-compatible)'d where it was previously (make-obsolete)'ed. These are mostly done, but some symbols have fallen through the cracks, like `eval-current-buffer'. I do not want package authors turning off bytecompiler warnings due to obsolescence warnings from the bytecompiler due to portability with FSF Emacs. I consider this an XEmacs bug to be fixed. 2. If a symbol has been obsoleted in ancient versions of Emacs (ie. Emacs 18, Lucid Emacs, XEmacs pre-19.12) it will be deleted now. 3. If a symbol has been obsoleted at least three years and is not in active usage it will be deleted. 4. Other symbols that have long (long == >= 3 years) been obsolete are candidates for reassignment. The best example of this is `lisp-indent-hook'. It has been obsolete for ages, however it is still more widely used than its replacement `lisp-indent-function'. Maybe in 22.0 it could be changed. At the moment I fail to see the point. I am serious about XEmacs 21 signaling "The bloat stops here." XEmacs shall not be the prime example of a huge, bloated pig of a piece of software. Deleting stuff no one has used, and the editor has signalled for years as being on the verge of imminent deletion definitely counts. We've been doing very well on the performance side. I've received numerous comments to the effect that while XEmacs has always been a huge drain of system resources it *has not* steadily increased its draw on resources and is both getting natively faster and getting better hardware to run on. The combination of which has meant that XEmacs is getting *much* faster than people are used to. This is Good. Thanks to Ben, the non-Mule XEmacs has no Mule baggage to carry around. This is also Good. Hopefully, as the MS Windows port matures there will be little need in the near future for NTemacs as well. I've gotten kind of cranky in the last couple of weeks as my nose has been pushed in the fact that XEmacs 21.0 is going to really suck. For that I apologize. It's not the end of the world, there will be another version of XEmacs after it. I've opened 21.2 and 22.0 development trees so bleeding edge development can occur and get patched into XEmacs development source trees while the problems of 21.0 are worked out over the Summer.

1 participants
0 comments

RE: Crash caused by gnuclient 26 years, 2 months

Amir J. Katz

Here's the full lisp backtrace: -- /* Amir J. Katz mailto:amir＠nuke-spam.com */ /* [For e-mail, replace 'nuke-spam' with 'ndsoft'] */ /* EagleEye Control Software, LTD. http://www.ndsoft.com */ /* 'Is "tired old cliche" one?' (Steven Wright) */

1 participants
0 comments

Crash caused by gnuclient 26 years, 2 months

Amir J. Katz

I'm running XEmacs 21.0 "Zhong Wei" on SunOS 4.1.4. I invoked gnuclient from the same host and I was able to edit a file. GNU_HOST and GNU_SECURE are set correctly. However, when I invoked a 20.4 gnuclient from a remote machine (a Solaris 2.6), XEmacs crashed: 1. Lisp backtrace x-win-init-sun() # bind (vendor) x-initialize-keyboard() # (unwind-protect ...) # bind (--letf-save--86128 console) #<compiled-function (console) "...(26)" [selected-console --letf-save--86128 (...) console --store--86127 select-console console-type x x-initialize-keyboard x-initialize-compose] 2>(#<x-console on "piccard:0" 0x3b6f>) # bind (frame-being-created) make-frame(nil #<x-device on "piccard:0.0" 0x3b74>) # bind (device dest-frame new-frame old-device-num quick view flags list type) gnuserv-edit-files((x "piccard:0.0") ((1 . "/felix:/h/amir/testpvcs/makes/Makefile"))) eval((gnuserv-edit-files (quote (x "piccard:0.0")) (quote (...)))) byte-code("..." [eval read-from-string gnuserv-string header] 4) 2. Stack trace from gdb 4.16: GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (sparc-sun-sunos4.1.4), Copyright 1996 Free Software Foundation, Inc... Core was generated by `xemacs'. Program terminated with signal 10, Bus error. #0 0x2ce3a8 in kill () (gdb) bt #0 0x2ce3a8 in kill () #1 0x51ba0 in fatal_error_signal (sig=10) at emacs.c:262 #2 <signal handler called> #3 0x1a1b74 in reject_constant_symbols (sym=-1605369852, newval=540675704, function_p=1, follow_past_lisp_magic=-1605369852) at symbols.c:564 #4 0x1a1fa8 in Ffset (sym=-1605369852, newdef=540675704) at symbols.c:662 #5 0x1d4e8 in Fbyte_code (bytestr=1614418652, vector=-2143677484, maxdepth=3) at bytecode.c:740 #6 0x5e14c in funcall_lambda (fun=540678160, nargs=0, arg_vector=0xefffcce4) at eval.c:3597 #7 0x5cc50 in funcall_recording_as (recorded_as=540678160, nargs=0, args=0xefffcce0) at eval.c:3214 #8 0x5ccb4 in Ffuncall (nargs=1, args=0xefffcce0) at eval.c:3238 #9 0x1ca78 in Fbyte_code (bytestr=1614406772, vector=-2143689564, maxdepth=21) at bytecode.c:416 #10 0x5e14c in funcall_lambda (fun=540665148, nargs=0, arg_vector=0xefffd04c) at eval.c:3597 #11 0x5cc50 in funcall_recording_as (recorded_as=540665148, nargs=0, args=0xefffd048) at eval.c:3214 #12 0x5ccb4 in Ffuncall (nargs=1, args=0xefffd048) at eval.c:3238 #13 0x1ca78 in Fbyte_code (bytestr=1614408892, vector=-2143687452, maxdepth=21) at bytecode.c:416 #14 0x5e14c in funcall_lambda (fun=540667232, nargs=1, arg_vector=0xefffd3dc) at eval.c:3597 #15 0x5cc50 in funcall_recording_as (recorded_as=540667232, nargs=1, args=0xefffd3d8) at eval.c:3214 #16 0x5ccb4 in Ffuncall (nargs=2, args=0xefffd3d8) at eval.c:3238 #17 0x5e5e0 in run_hook_with_args_in_buffer (buf=0xa0408004, nargs=2, args=0xefffd3d8, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3757 #18 0x5e654 in run_hook_with_args (nargs=2, args=0xefffd3d8, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3770 #19 0x5e6ec in va_run_hook_with_args (hook_var=-1606306996, nargs=1) at eval.c:3842 #20 0xf4444 in Fmake_frame (props=-1606385660, device=546831872) at frame.c:495 #21 0x5ca74 in funcall_recording_as (recorded_as=540029568, nargs=2, args=0xefffde10) at eval.c:3197 #22 0x5ccb4 in Ffuncall (nargs=3, args=0xefffde10) at eval.c:3238 #23 0x1ca78 in Fbyte_code (bytestr=1619146160, vector=-2140415488, maxdepth=121) at bytecode.c:416 #24 0x5e14c in funcall_lambda (fun=546026176, nargs=2, arg_vector=0xefffdfa8) at eval.c:3597 #25 0x5d898 in apply_lambda (fun=546026176, numargs=2, unevalled_args=-1606385660) at eval.c:3501 #26 0x5c544 in Feval (form=1082587468) at eval.c:3085 #27 0x5ca60 in funcall_recording_as (recorded_as=540019584, nargs=1, args=0xefffe3c8) at eval.c:3197 #28 0x5ccb4 in Ffuncall (nargs=2, args=0xefffe3c8) at eval.c:3238 #29 0x1ca78 in Fbyte_code (bytestr=1619144936, vector=-2138066176, maxdepth=8) at bytecode.c:416 #30 0x5c364 in Feval (form=1083236316) at eval.c:3063 #31 0x59688 in condition_case_1 (handlers=1083217412, bfun=0x5b900 <Feval>, barg=1083236316, hfun=0x596f0 <run_condition_case_handlers>, harg=-1603559476) at eval.c:1653 #32 0x598a4 in condition_case_3 (bodyform=1083236316, var=-1603559476, handlers=1083217412) at eval.c:1715 #33 0x1cf68 in Fbyte_code (bytestr=1619144792, vector=-2141487296, maxdepth=29) at bytecode.c:576 #34 0x5e14c in funcall_lambda (fun=546026036, nargs=2, arg_vector=0xefffeb4c) at eval.c:3597 #35 0x5cc50 in funcall_recording_as (recorded_as=546026036, nargs=2, args=0xefffeb48) at eval.c:3214 #36 0x5ccb4 in Ffuncall (nargs=3, args=0xefffeb48) at eval.c:3238 #37 0x5e8fc in call2 (fn=-1603559500, arg0=546140544, arg1=1619129128) at eval.c:3937 #38 0x5fba4 in catch_them_squirmers_call2 (cons=1082201516) at eval.c:4441 #39 0x59688 in condition_case_1 (handlers=-1606385564, bfun=0x5fa4c <catch_them_squirmers_call2>, barg=1082201516, hfun=0x5ee90 <caught_a_squirmer>, harg=541080000) at eval.c:1653 #40 0x5ff34 in call2_trapping_errors (warning_string=0x154798 "Error in process filter", function=-1603559500, object1=546140544, object2=1619129128) at eval.c:4505 #41 0x1549d8 in read_process_output (proc=546140544) at process.c:846 #42 0xb2264 in execute_internal_event (event=543853012) at event-stream.c:2963 #43 0xb7d40 in Fdispatch_event (event=543853012) at event-stream.c:4690 #44 0x294e0 in Fcommand_loop_1 () at cmdloop.c:579 #45 0x29108 in command_loop_1 (dummy=-1606385660) at cmdloop.c:494 #46 0x59688 in condition_case_1 (handlers=-1606385564, bfun=0x29064 <command_loop_1>, barg=-1606385660, hfun=0x281b8 <cmd_error>, harg=-1606385660) at eval.c:1653 #47 0x28334 in command_loop_3 () at cmdloop.c:256 #48 0x2835c in command_loop_2 (dummy=-1606385660) at cmdloop.c:267 #49 0x59170 in internal_catch (tag=-1606307988, func=0x28350 <command_loop_2>, arg=-1606385660, threw=0x0) at eval.c:1328 #50 0x287d8 in initial_command_loop (load_me=164688) at cmdloop.c:305 #51 0x5318c in xemacs_21_0_sparc_sun_sunos4_1_4 (argc=1, argv=0xeffff7dc, envp=0xeffff7e4, restart=3995648) at emacs.c:1702 #52 0x53d64 in main (argc=0, argv=0xeffff7dc, envp=0xeffff7e4) at emacs.c:2119 (gdb) quit -- /* Amir J. Katz mailto:amir＠nuke-spam.com */ /* [For e-mail, replace 'nuke-spam' with 'ndsoft'] */ /* EagleEye Control Software, LTD. http://www.ndsoft.com */ /* 'Is "tired old cliche" one?' (Steven Wright) */

1 participants
0 comments

Regarding packages .. 26 years, 2 months

Holger Schauer

Hi ! Yesterday I tried `package-get-update-all', which went fine up to the moment, where the xemacs.org-FTP-Server asked me for a password ? How do I get that ? And as a second point, two weeks ago, I posted a starter document on packages. What happened to it, did nobody receive it ? Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- "Das ist wirklich traurig. Mein Linux verwandelt sich immer noch nicht Schlag zwoelf in ein Schinkensandwich." -- Robin Socha in de.comp.os.linux.misc

2 participants
1 comments

Re: Obsolescence -- I like `eval-current-buffer' 26 years, 2 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Ben Wing <ben(a)666.com> writes: > > > yes yes yes and these too (all pre-19.12 I think): > ... > > (define-obsolete-function-alias 'eval-current-buffer 'eval-buffer) > > Is there anyone else who would like to see this *un*obsoleted? In FSF Emacs, `eval-current-buffer' is an alias to `eval-buffer', and their `eval-buffer' does not take a BUFFER argument. I think we should keep `eval-buffer' the way we have it, and unobsolete and document `eval-current-buffer'. So yes, I agree with you. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Reporter: Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea.

1 participants
0 comments

XKB-Extensions and [Success] 21.0b48 on Solaris 26 years, 2 months

Holger Schauer

Hi ! I did not encounter any problems so far with 21.0b48, see below. Two notes on the XKB-problems reported some weeks ago: last night I compiled a 21.0b46 Toggenburg on my Linux box, which is a modified SuSE5.1 with XFree3.3.1 and a german keyboard. 1) Without having the nodeadkey-option set, I was able to produce a "~" by hitting "~" and a space afterwards. The dead_circumflex however is still there. 2) I was able to use AltGr+Control to simulate MultiKey, i.e. Compose. I think that this is good news. Holger uname -a: SunOS frandance.coling.uni-freiburg.de 5.6 Generic sun4u sparc SUNW,Ultra-1 ./configure 'sparc-sun-solaris2.6' '--cflags=-O6' '--prefix=/home/schauer/misc/' '--with-dialogs=lucid' '--site-includes=/home/schauer/misc/include' '--site-libraries=/home/schauer/misc/lib' XEmacs 21.0 "Zhong Wei" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /home/schauer/misc/src/packages/xemacs/xemacs-21.0-b48 What installation prefix should install use? /home/schauer/misc/ What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -O6 Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include /usr/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Additional header files: /home/schauer/misc/include Additional libraries: /home/schauer/misc/lib Runtime library search path: /home/schauer/misc/lib:/usr/dt/lib:/usr/openwin/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for GIF image conversion. Compiling in support for JPEG image conversion. Compiling in native sound support. Compiling in support for GNU DBM. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. -- --- http://www.coling.uni-freiburg.de/~schauer --- "Das ist wirklich traurig. Mein Linux verwandelt sich immer noch nicht Schlag zwoelf in ein Schinkensandwich." -- Robin Socha in de.comp.os.linux.misc

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 July 1998