July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Where do you want to go tomorrow? 25 years, 10 months

Michael Sperber

Many thanks, Reggie, for your arguments on Common Lisp. I plan to put this in a write-up on the Web page for the near future. Naturally, I appreciate it somewhat less than Hrvoje :-) >>>>> "Reggie" == Reggie Perry <Reggie.Perry(a)digital.com> writes: Reggie> There are several arguments for common lisp. Emacs-lisp is a maclisp Reggie> variant and common lisp is designed with the explicit intent to easily Reggie> migrate maclisp programs to common lisp. Intent is not reality. Reggie> The let argument that people were mentioning earlier does not Reggie> really exist because all globals are treated as special Reggie> variables and will be shadowed by a let just like it happens Reggie> in elisp now. As several people have pointed out, this is precisely *not* like it happens in Elisp now. (Also, DEFVAR's intended semantics are not really "I explicitly want dynamic binding for this variable.") If the Elisp semantics change as Hrvoje suggested, a lot of code will have to change with it. I claim that migration to Common Lisp is roughly as expensive as migration to Scheme. Reggie> Third common lisp has the #+ and #- feature reader Reggie> macros which allow you to take advantage of features that may Reggie> or may not be available in the compiled XEmacs system on a Reggie> particular platform like minimal tagbits or CDE. #+ and #- also have huge downsides, especially in an XEmacs setting, which is why they are hopefully going away in XEmacs RSN. Reggie> None of these things are available in standard scheme, and this to me is Reggie> what separates a language designed for properly engineering a complex Reggie> system like XEmacs has become. The perfect example, to me is scheme48. Reggie> Look at the things that were added to the system to make it usable from Reggie> an engineering standpoint and note that its non-standard Reggie> scheme. Note also that Scheme 48 provides portable implementations of almost all of the additions written in totally standard Scheme. Furthermore, Scheme 48 will bootstrap from just about any implementation of R4RS Scheme. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Where do you want to go tomorrow? 25 years, 10 months

Hrvoje Niksic

Thanks, Reggie. Michael, I think you should include this, along with Bruno's argument, to the "case for Common Lisp" on your pages. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

1 participants
0 comments

RE: Where do you want to go tomorrow? (reformat) 25 years, 10 months

Reginald Perry

I was planning to just lurk during this discussion, but since my name actually got mentioned, I guess I should give an opinion. Ill give a thesis statement first so people can just delete the message if they violently disagree. Common Lisp is a better language for managing software engineering projects than scheme. First let me say that I like scheme a lot and it would be cool to have a scheme engine available in XEmacs so that I would get a chance to hack scheme. But I don't think that cool is a good enough reason for attempting the huge job of evolving the codebase to another language. The questions always are the wins in doing it, and how hard will it be. There are several arguments for common lisp. Emacs-lisp is a maclisp variant and common lisp is designed with the explicit intent to easily migrate maclisp programs to common lisp. The let argument that people were mentioning earlier does not really exist because all globals are treated as special variables and will be shadowed by a let just like it happens in elisp now. Second common-lisp has structures, objects, and generic functions so that you can generalize a lot of common code that is probably laying around. Packages give you namespace separation so that you can worry less about name clashes and having to have lots of conventions to avoid these clashes. Third common lisp has the #+ and #- feature reader macros which allow you to take advantage of features that may or may not be available in the compiled XEmacs system on a particular platform like minimal tagbits or CDE. Fourth and probably most important, common lisp has powerful exceptions which are CLOS objects and powerful exception handling semantics which will allow better handling of exceptional situations have the potential to make the system very robust. None of these things are available in standard scheme, and this to me is what separates a language designed for properly engineering a complex system like XEmacs has become. The perfect example, to me is scheme48. Look at the things that were added to the system to make it usable from an engineering standpoint and note that its non-standard scheme. So although you may hurt yourself and others trying to lift the common lisp standard. That same standard provides all of the things you need to evolve elisp to common lisp and make it more manageable and robust from an engineering standpoint and will allow future designs to be a lot cleaner if you can take advantage of CLOS. -Reggie

1 participants
0 comments

RE: Where do you want to go tomorrow? 25 years, 10 months

Reggie Perry

I was planning to just lurk during this discussion, but since my name actually got mentioned, I guess I should give an opinion. Ill give a thesis statement first so people can just delete the message if they violently disagree. Common Lisp is a better language for managing software engineering projects than scheme. First let me say that I like scheme a lot and it would be cool to have a scheme engine available in XEmacs so that I would get a chance to hack scheme. But I dont think that cool is a good enough reason for attempting the huge job of evolving the codebase to another language. The questions always are the wins in doing it, and how hard will it be. There are several arguments for common lisp. Emacs-lisp is a maclisp variant and common lisp is designed with the explicit intent to easily migrate maclisp programs to common lisp. The let argument that people were mentioning earlier does not really exist because all globals are treated as special variables and will be shadowed by a let just like it happens in elisp now. Second common-lisp has structures, objects, and generic functions so that you can generalize a lot of common code that is probably laying around. Packages give you namespace separation so that you can worry less about name clashes and having to have lots of conventions to avoid these clashes. Third common lisp has the #+ and #- feature reader macros which allow you to take advantage of features that may or may not be available in the compiled XEmacs system on a particular platform like minimal tagbits or CDE. Fourth and probably most important, common lisp has powerful exceptions which are CLOS objects and powerful exception handling semantics which will allow better handling of exceptional situations have the potential to make the system very robust. None of these things are available in standard scheme, and this to me is what separates a language designed for properly engineering a complex system like XEmacs has become. The perfect example, to me is scheme48. Look at the things that were added to the system to make it usable from an engineering standpoint and note that its non-standard scheme. So although you may hurt yourself and others trying to lift the common lisp standard. That same standard provides all of the things you need to evolve elisp to common lisp and make it more manageable and robust from an engineering standpoint and will allow future designs to be a lot cleaner if you can take advantage of CLOS. -Reggie

1 participants
0 comments

Still can't build 21.0-b46 on Solaris 25 years, 10 months

Dan Rich

I'm still unable to successfully build a working xemacs on Solaris. When it gets to the final build stages it core dumps the first time xemacs runs. I've gone through and made sure that I don't have any duplicate libraries or include files in my local include directories that duplicate the existing ones (and there are *definately* no X11R6 files outside of /usr/openwin). Here's the crash: MAKE='make' EMACS='./src/xemacs' sh /home/drich/Src/xemacs-21.0-b46/lib-src/update-elc.sh (using ./src/xemacs) Recompiling in /home/drich/Src/xemacs-21.0-b46 with /home/drich/Src/xemacs-21.0-b46/src/xemacs... Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. Please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /home/drich/Src/xemacs-21.0-b46/src/xemacs core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: make: *** [all-elc] Error 139 The stack trace: 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-solaris2.5.1), Copyright 1996 Free Software Foundation, Inc... Core was generated by `./src/xemacs -batch -vanilla -l /home/drich/Src/xemacs-21.0-b46/lisp/cleantree'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/dt/lib/libXm.so.3...done. Reading symbols from /opt/local/lib/libtiff.so...done. Reading symbols from /opt/local/lib/libpng.so.2...done. Reading symbols from /usr/openwin/lib/libXpm.so.4.11...done. Reading symbols from /usr/dt/lib/libDtSvc.so.1...done. Reading symbols from /usr/openwin/lib/libtt.so.2...done. Reading symbols from /usr/openwin/lib/libXmu.so.4...done. Reading symbols from /usr/openwin/lib/libXt.so.4...done. Reading symbols from /usr/openwin/lib/libXext.so.0...done. Reading symbols from /usr/openwin/lib/libX11.so.4...done. Reading symbols from /usr/openwin/lib/libSM.so.6.0...done. Reading symbols from /usr/openwin/lib/libICE.so.6.3...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /opt/gnu/lib/libncurses.so.3.0...done. Reading symbols from /usr/lib/libkvm.so.1...done. Reading symbols from /usr/lib/libkstat.so.1...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/lib/libelf.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libw.so.1...done. Reading symbols from /usr/lib/libintl.so.1...done. Reading symbols from /usr/lib/libmp.so.1...done. Reading symbols from /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1...done. Reading symbols from /usr/lib/nss_files.so.1...done. #0 0xef074728 in kill () (gdb) where #0 0xef074728 in kill () #1 0x4af98 in fatal_error_signal (sig=11) at emacs.c:262 #2 <signal handler called> #3 0x1e490 in mark_object (obj=541086720) at alloc.c:3168 #4 0x325d4 in mark_char_table (obj=3319884, markobj=0x1e3b4 <mark_object>) at chartab.c:145 #5 0x1e4d8 in mark_object (obj=540190720) at alloc.c:3178 #6 0x218d4 in mark_buffer (obj=3325440, markobj=0x1e3b4 <mark_object>) at bufslots.h:96 #7 0x1e4d8 in mark_object (obj=540196352) at alloc.c:3178 #8 0x120474 in mark_symbol_value_buffer_local (obj=3838944, markobj=0x1e3b4 <mark_object>) at symbols.c:909 #9 0x1e4d8 in mark_object (obj=540709856) at alloc.c:3178 #10 0x1e610 in mark_object (obj=3768420) at alloc.c:3232 #11 0x1e5b8 in mark_object (obj=3076096) at alloc.c:3214 #12 0x201c4 in garbage_collect_1 () at alloc.c:4491 #13 0x53214 in funcall_recording_as (recorded_as=-1607448628, nargs=4, args=0xefff4020) at eval.c:3114 #14 0x54ff4 in call3 (fn=-1607448628, arg0=-1607540732, arg1=736, arg2=-1607540732) at eval.c:3238 #15 0xa8e1c in Finsert_file_contents_internal (filename=1615667612, visit=-1607540732, beg=268435455, end=2859008, replace=2859008, codesys=-1607417732, used_codesys=-1606468164) at fileio.c:3073 #16 0x537e8 in funcall_recording_as (recorded_as=-1607448356, nargs=7, args=0xefffc528) at eval.c:3197 #17 0x53a14 in Ffuncall (nargs=8, args=0xefffc528) at eval.c:3238 #18 0x29528 in Fbyte_code (bytestr=1613202104, vector=-2144894156, maxdepth=67) at bytecode.c:416 #19 0x52ec8 in Feval (form=1076331176) at eval.c:3063 #20 0x4fdcc in condition_case_1 (handlers=1076331472, bfun=0x52698 <Feval>, barg=1076331176, hfun=0x4fe18 <run_condition_case_handlers>, harg=-1607133884) at eval.c:1653 #21 0x50024 in condition_case_3 (bodyform=1076331176, var=-1607133884, handlers=1076331472) at eval.c:1715 #22 0x299e8 in Fbyte_code (bytestr=1613201824, vector=-2144894400, maxdepth=12) at bytecode.c:576 #23 0x54974 in funcall_lambda (fun=539460772, nargs=4, arg_vector=0xefffd118) at eval.c:3597 #24 0x539a0 in funcall_recording_as (recorded_as=-1607448844, nargs=4, args=0xefffd114) at eval.c:3214 #25 0x53a14 in Ffuncall (nargs=5, args=0xefffd114) at eval.c:3238 #26 0x29528 in Fbyte_code (bytestr=1613201040, vector=-2144895136, maxdepth=106) at bytecode.c:416 #27 0x54974 in funcall_lambda (fun=539459664, nargs=3, arg_vector=0xefffd4a4) at eval.c:3597 #28 0x539a0 in funcall_recording_as (recorded_as=-1607436116, nargs=3, args=0xefffd4a0) at eval.c:3214 #29 0x53a14 in Ffuncall (nargs=4, args=0xefffd4a0) at eval.c:3238 #30 0x29528 in Fbyte_code (bytestr=1612674676, vector=-2145421676, maxdepth=5) at bytecode.c:416 #31 0x52ec8 in Feval (form=1075803748) at eval.c:3063 #32 0x4fdcc in condition_case_1 (handlers=1075803820, bfun=0x52698 <Feval>, barg=1075803748, hfun=0x4fe18 <run_condition_case_handlers>, harg=-1607540636) at eval.c:1653 #33 0x50024 in condition_case_3 (bodyform=1075803748, var=-1607540636, handlers=1075803820) at eval.c:1715 #34 0x299e8 in Fbyte_code (bytestr=1612674596, vector=-2145421756, maxdepth=9) at bytecode.c:576 #35 0x54974 in funcall_lambda (fun=538933168, nargs=1, arg_vector=0xefffdc14) at eval.c:3597 #36 0x539a0 in funcall_recording_as (recorded_as=538933168, nargs=1, args=0xefffdc10) at eval.c:3214 #37 0x54f44 in call1 (fn=538933168, arg0=1614398608) at eval.c:3238 #38 0xb43a0 in mapcar1 (leni=74, vals=0x0, fn=538933168, seq=1078174972) at fns.c:3237 #39 0xb45c8 in Fmapc (fn=538933168, seq=1078174972) at fns.c:3320 #40 0x53744 in funcall_recording_as (recorded_as=-1607445756, nargs=2, args=0xefffdf80) at eval.c:3197 #41 0x53a14 in Ffuncall (nargs=3, args=0xefffdf80) at eval.c:3238 #42 0x29528 in Fbyte_code (bytestr=1612675036, vector=-2145421324, maxdepth=4) at bytecode.c:416 #43 0x54974 in funcall_lambda (fun=538933252, nargs=2, arg_vector=0xefffe30c) at eval.c:3597 #44 0x539a0 in funcall_recording_as (recorded_as=-1607265724, nargs=2, args=0xefffe308) at eval.c:3214 #45 0x53a14 in Ffuncall (nargs=3, args=0xefffe308) at eval.c:3238 #46 0x29528 in Fbyte_code (bytestr=1612675164, vector=-2145421196, maxdepth=6) at bytecode.c:416 #47 0x54974 in funcall_lambda (fun=538933384, nargs=1, arg_vector=0xefffe91c) at eval.c:3597 #48 0x539a0 in funcall_recording_as (recorded_as=-1607265628, nargs=1, args=0xefffe918) at eval.c:3214 #49 0x53a14 in Ffuncall (nargs=2, args=0xefffe918) at eval.c:3238 #50 0x29528 in Fbyte_code (bytestr=1612970036, vector=-2145126092, maxdepth=151) at bytecode.c:416 #51 0x54974 in funcall_lambda (fun=539228948, nargs=0, arg_vector=0xefffead8) at eval.c:3597 #52 0x5437c in apply_lambda (fun=539228948, numargs=0, unevalled_args=-1607540732) at eval.c:3501 #53 0x53050 in Feval (form=1077518164) at eval.c:3085 #54 0x4fdcc in condition_case_1 (handlers=-1607540636, bfun=0x52698 <Feval>, barg=1077518164, hfun=0x332dc <cmd_error>, harg=-1607540732) at eval.c:1653 #55 0x33368 in top_level_1 (dummy=-1607540732) at cmdloop.c:206 #56 0x4fbb0 in internal_catch (tag=-1607462812, func=0x33330 <top_level_1>, arg=-1607540732, threw=0x0) at eval.c:1328 #57 0x329c0 in initial_command_loop (load_me=209712) at cmdloop.c:285 #58 0x4c854 in xemacs_21_0_sparc_sun_solaris2_5_1 (argc=8, argv=0xeffff1f4, envp=0xeffff218, restart=0) at emacs.c:1702 #59 0x4cfac in main (argc=0, argv=0xeffff1f4, envp=0xeffff218) at emacs.c:2119 (gdb) q And the Installation file: uname -a: SunOS sandman 5.5.1 Generic_103640-14 sun4u sparc SUNW,Ultra-1 ./configure '--site-libraries=/opt/local/lib' '--site-includes=/opt/local/include' '--with-mule' '--dynamic' '--prefix=/usr/local/beta' XEmacs 21.0 "Toggenburg" configured for `sparc-sun-solaris2.5.1'. Where should the build process find the source code? /home/drich/Src/xemacs-21.0-b46 What installation prefix should install use? /usr/local/beta 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 -g -O3 -Wall -Wno-switch 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: /opt/local/include Additional libraries: /opt/local/lib Runtime library search path: /opt/local/lib:/usr/dt/lib:/usr/openwin/lib:/opt/gnu/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. 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. Any ideas?

1 participants
0 comments

drag-n-drop core dump 25 years, 10 months

Colin Rafferty

I am running XEmacs 21.0 Toggenburg on my SGI box, and decide that since I have an NT on the corner of my desk, I should run Exceed on it and get another monitor for XEmacs. I normally have no problem running on multiple displays. I will dial in from home and attach/detach that display. However, something is going on, and maybe it's Exceed, but it seems weird. The first weirdness is that every time an XEmacs frame on my SGI would gain focus, it would pop up a "*MIME-Drop data*" buffer. I tracked that down by replacing the `experimental-dragdrop-drop-functions' with my own function that throws an error. Here is the backtrace: It appears that XEmacs thinks that it is getting a drop event, even though it is a normal window-enter. Here are the event and object from the callback: event: #<misc-user-event (dragdrop-drop-dispatch (dragdrop-MIME (("application/octet-stream") "8bit" "")))>, object: (dragdrop-MIME ((application/octet-stream) 8bit )) Of course, it gets worse. When I then close the XEmacs frame on the NT, the next time I move focus into an SGI frame, I get the following stack trace on a SEGV. Of course, this is all running -vanilla. Does anybody have a similar problem? Does anyone run a similar configuration and not have this problem? -- Colin

1 participants
0 comments

Re: Where do you want to go tomorrow? 25 years, 10 months

Hrvoje Niksic

Andy Piper <andyp(a)parallax.co.uk> writes: > At 12:53 PM 7/2/98 +0200, Hrvoje Niksic wrote: > >When using a subset of a standardized language, you can still write > >conformant programs. The reason to use the subset instead of the > >unabridged experience is, of course, efficiency. > > I am dead against this. A subset loses us much of what we would gain > through swapping to a standard language engine. You are wrong, Andy. The benefit is that the stripped-down clisp would still be maintained independently. > We would just have eclisp instead of elisp which is just as bad > IMHO. I think you misunderstood my meaning. Perhaps I have a problem with expressing myself? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- - Now what did we learn from this? - I learned what my liver looks like!

4 participants
3 comments

Re: Where do you want to go tomorrow? 25 years, 10 months

Raymond Toy

Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: > I never encountered any bugs on a grown-old 17f on Sun Systems. Note > that currently most development on CMUCL seems to be done on Intel > systems, so the situation is much likely to change [or has already > improved]. With clisp I had had problems in the past of even compiling Yes, most work is on Intel because that's what the main implementers have. The sparc port has almost everything the Intel version has except for generational GC and the multithreading. Lack of people knowledgeable with other architectures and access to them prevents CMUCL for going farther. Besides, my 300MHz Pentium II recompiles CMUCL faster than my 300 MHz Ultra 30. Ray

1 participants
0 comments

Re: Where do you want to go tomorrow? 25 years, 10 months

Raymond Toy

Hrvoje Niksic <hniksic(a)srce.hr> writes: > sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > > > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > Exactly. And it's almost impossible to compile. And it's fucking > huge. Etc. Clisp doesn't have a native compiler, but it would > probably serve our purposes much better. Actually it's pretty easy to recompile CMUCL with itself. If you want to add some new feature or something, then it's a nightmare. You usually end up having to use a cross compiler to do it, and even then not always. I guess that's what happens when it can't bootstrap itself without an already working version. I don't find the size that huge. A typical CMUCL image for me is about 20-25 MB. XEmacs is about the same for me. CMUCL isn't what we want to use. Ray

1 participants
0 comments

Re: Where do you want to go tomorrow? 25 years, 10 months

Raymond Toy

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > Hrvoje> I don't like CMU CL (far too slow and buggy IMHO), > > Actually, CMU CL produces pretty much the fastest CL code around. > Unfortuntately, it only works on very few architectures. I find CMUCL to be the fastest around for floating-point code (even faster than ACL 4.3/5.0beta), after you've put in the necessary declarations. However, for other code, some numeric and some not, sometimes CLISP and GCL is much faster, sometimes twice as fast. If we choose lisp, I think CLISP would be an excellent choice. Ray

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