July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

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

Adrian Aichner

>>>>> "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 Don't know which would be the right one. I guess you'd have to `SPAM' him :-) Adrian sb> Specifically, we need to get permission to convert the GIFs in xmine sb> to PNG. -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

Re: scheme - my opinion 26 years, 2 months

Holger Schauer

>>>>"RP" == Reginald Perry schrieb am Mon, 13 Jul 1998 18:44:07 -0700: RP> One quick thing. Kent Pitman has recomended that people stop RP> referencing CLtL1 and CLtL2 and instead reference the ansi RP> spec. Since that is quite expensive the next best thing online is RP> the HyperSpec: RP> http://www.harlequin.com/education/books/HyperSpec/FrontMatter/index.html I would like to second that a CL-using XEmacs *should* follow Ansi CL as close as possible. If one wants to sell Lisp as a language, we should opt for being as standarized as possible (note that Clisp is not ANSI CL, there are some points where it does not follow the standard). RP> I know that CLtLn make for good toilet reading, but its not a RP> representation of the official spec. No, no. CLtLn is not good for toilet reading. Anybody stating that one could learn Common Lisp from CLtLn is either a guru or is shouting "Jehova !" Note also that the HyperSpec is also not a representation of the official spec, but it is probably very close (read: really _very_ close). If I should recommend one book on Lisp (especially ANSI CL), I would recommend "ANSI CL" by Paul Graham, which I think is just excellent. Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- "It's of utmost importance, we're dealing with volitiale substance." -- Violent Femmes, "Never Tell"

1 participants
0 comments

problem with 21.0-b47/pre4 and Solaris 2.7 (pre-fcs) 26 years, 2 months

Glenn Barry

XEmacs 21.0-b47/pre4 "Uzbek Black" on Solaris 2.7 (fcs in a few months) spits out the following err many times doing X ops: xemacs-21.0: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 60 (X_FreeGC) Resource id in failed request: 0x1140002a Serial number of failed request: 2176 Current serial number in output stream: 2236 Solaris 2.7 has a new Motif shared lib (libXm.so.4) and I'm told that this is for the new Motif 2.0. XEmacs 21.0 built (pre Solaris 2.7) against the old shared lib (libXm.so.3) does not have this problem. A few months ago we filed a bug internally for this problem against the Motif/X11 libs and the folks who evaluated it said it was a bug with XEmacs (to my surprise). They even supplied a suggested fix for XEmacs 20.4. I've applied it to 20.4 and 21.0 and it does indeed seem to fix the problem (at least the symptom goes away). I'll include it below. Anyways, if somebody who knows this area well could take a look, pls do so and let me know if I can help. cheers, glenn files modified: lwlib/xlwmenu.c, lwlib/xlwscrollbar.c *** xlwmenu.c.orig Fri Jun 12 21:28:08 1998 --- xlwmenu.c Fri Jul 10 15:43:33 1998 *************** *** 2803,2815 **** --- 2803,2833 ---- xgcv.fill_style = FillOpaqueStippled; xgcv.foreground = mw->menu.top_shadow_color; xgcv.background = mw->core.background_pixel; + /* xgcv.stipple = mw->menu.top_shadow_pixmap; gtb */ + #ifdef NEED_MOTIF + if (mw->menu.top_shadow_pixmap && + mw->menu.top_shadow_pixmap != XmUNSPECIFIED_PIXMAP) + xgcv.stipple = mw->menu.top_shadow_pixmap; + else + xgcv.stipple = 0; + #else xgcv.stipple = mw->menu.top_shadow_pixmap; + #endif /* NEED_MOTIF */ pm = (xgcv.stipple ? GCStipple|GCFillStyle : 0); mw->menu.shadow_top_gc = XtGetGC((Widget)mw, GCForeground|GCBackground|pm, &xgcv); xgcv.foreground = mw->menu.bottom_shadow_color; + /* xgcv.stipple = mw->menu.bottom_shadow_pixmap; gtb */ + #ifdef NEED_MOTIF + if (mw->menu.top_shadow_pixmap && + mw->menu.top_shadow_pixmap != XmUNSPECIFIED_PIXMAP) + xgcv.stipple = mw->menu.bottom_shadow_pixmap; + else + xgcv.stipple = 0; + #else xgcv.stipple = mw->menu.bottom_shadow_pixmap; + #endif /* NEED_MOTIF */ pm = (xgcv.stipple ? GCStipple|GCFillStyle : 0); mw->menu.shadow_bottom_gc = XtGetGC ((Widget)mw, GCForeground|GCBackground|pm, &xgcv); *** xlwscrollbar.c.orig Tue Mar 31 12:11:14 1998 --- xlwscrollbar.c Fri Jul 10 15:47:08 1998 *************** *** 485,490 **** --- 485,496 ---- } /*-------------------------- GC and Pixel allocation --------------------*/ + #ifdef NEED_MOTIF + #ifndef XmUNSPECIFIED_PIXMAP + #define XmUNSPECIFIED_PIXMAP 2 + #endif + #endif /* NEED_MOTIF */ + static GC get_gc (XlwScrollBarWidget w, Pixel fg, Pixel bg, Pixmap pm) { *************** *** 506,513 **** values.background = bg; values.fill_style = FillOpaqueStippled; values.stipple = pm; mask = GCForeground | GCBackground | ! (pm == None ? 0 : GCStipple | GCFillStyle); return XtGetGC((Widget) w, mask, &values); } --- 512,530 ---- values.background = bg; values.fill_style = FillOpaqueStippled; values.stipple = pm; + /* mask = GCForeground | GCBackground | + (pm == None ? 0 : GCStipple | GCFillStyle); gtb */ + #ifdef NEED_MOTIF + if (pm != None && pm != 0 && pm != XmUNSPECIFIED_PIXMAP) + values.stipple = pm; + else + values.stipple = None; + #else + values.stipple = pm; + #endif /* NEED_MOTIF */ mask = GCForeground | GCBackground | ! (values.stipple == None ? 0 : GCStipple | GCFillStyle); ! return XtGetGC((Widget) w, mask, &values); }

1 participants
0 comments

Re: My thoughts on package-delete (was Re: Fighting with packages!) 26 years, 2 months

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: > How about _before_ the installation? I have in mind conflicts among > files in etc/, especially in cases where for some reason the package > contents change by addition or deletion of libraries. There are no conflicts at present. The one potential place where we have a conflict is in the sounds-au and sounds-wav packages. I rejected a patch that would have made a conflict in the README files. > This could also affect files in subdirectories of lisp/, although we > can catch that via shadow detection. There should be no conflicts by definition in lisp/. If there is a conflict, then it is a package upgrade and it will be handled by the mechanism I described. It is an unwritten golden rule that packages only touch one lisp directory. sb> We could save either the list of files or a machine-generated sb> deletion shell script. The former would be more flexible. > Deletion is rare. No, it won't be. Deletion will be the *most* common thing done in 21.0. I strongly suspect nearly everyone will attempt loading the SUMO/相撲 tarball first and then want to delete the stuff they don't want -- just as always has been the case. > Let's have flexibility; either way the machine can generate the > script at little cost. Agreed about having flexibility. sb> This won't completely work for de-installation because we need sb> things to work somewhat even if the MANIFEST files get sb> misplaced[1]. sb> Footnotes: sb> [1] Do we really? > If not, we should forget about running source packages in-place, I think. That's officially unsupported anyway. You're on your own and if things break you get to keep both pieces.

1 participants
0 comments

Re: What is /usr/dt/lib? 26 years, 2 months

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes: > Users can always override /usr/dt contents using --site-libraries and > --site-includes. Why? If /usr/dt, by your own writings contains X11 libraries and usually, but not always only Motif and/or CDE, why the hell doesn't --x-includes and --x-libraries override it? Has the meaning of X changed? If I tell configure that I don't want any stinking CDE/Motif by an unfortunately large number of options, then what business does it have sticking that directory ahead of others that I have explicitly asked to be put ahead via --x-includes and --x-libraries. Excuse me, but configure is clearly broken in this area. > Users are also free to `rm -rf /usr/dt' and XEmacs will build just > fine with just the vendor-supplied X in /usr/openwin. But most > users will choose not to shoot themselves in the foot this way. A brilliant suggestion. > Does anyone actually have a real live PROBLEM that removing /usr/dt > would solve? There would certainly be many problems that it would > introduce. Yes. I couldn't build an XEmacs binary on HP/UX against /usr/contrib X11R6 libraries without manually modifying configure to make /usr/dt go away. I have that patch sitting in my incoming queue. I'm almost in enough of a foul mood over this to consider applying it.

2 participants
1 comments

21.0-b48: w3 fails to load 26 years, 2 months

Gregory Neil Shapiro

Trying to use w3 to display an html inline message with VM yields the error below. I noticed that variable is set in w3/mule-sysdp.el so it's possible only a require is needed in w3-display.el. Adding one fixed the problem for me but this should probably be verified with the author. Signaling: (void-variable mule-sysdep-version) byte-code("..." [mule-sysdep-version xemacs find-charset w3-dingbats make-charset "Dingbats character set for Emacs/W3" (registry "" dimension 1 chars 96 final ?\:) (4.0 3.0 3.1) charsetp define-charset nil vector 1 96 ?\: 0 "dingbats" "emacs/w3-dingbats"] 13) load-internal("/home/gshapiro/Work/xemacs/xemacs-21.0-b48/packages/lisp/w3/w3-display.elc" nil t t nil nil) efs-real-load("/home/gshapiro/Work/xemacs/xemacs-21.0-b48/packages/lisp/w3/w3-display.elc" nil t t) load("/home/gshapiro/Work/xemacs/xemacs-21.0-b48/packages/lisp/w3/w3-display.elc" nil t t) apply(load ("/home/gshapiro/Work/xemacs/xemacs-21.0-b48/packages/lisp/w3/w3-display.elc" nil t t)) dired-handler-fn(load "/home/gshapiro/Work/xemacs/xemacs-21.0-b48/packages/lisp/w3/w3-display.elc" nil t t) load-internal("/home/gshapiro/Work/xemacs/xemacs-21.0-b48/packages/lisp/w3/w3-display.elc" nil t t nil nil) efs-real-load("/home/gshapiro/Work/xemacs/xemacs-21.0-b48/packages/lisp/w3/w3-display.elc" nil t t) load("w3-display" nil nil nil) w3-region(1 7239) byte-code("..." [w3-region] 3) vm-mime-display-internal-text/html([("text/html" "charset=us-ascii") ("text/html" "charset=us-ascii") "7bit" nil nil ("inline" "filename=netscape.htm") ("inline" "filename=\"netscape.htm\"") #<marker at 4677 in .vmail 0x87c764c> #<marker at 4805 in .vmail 0x87c7634> #<marker at 12043 in .vmail 0x87fe0d4> nil nil nil]) byte-code("..." [intern "vm-mime-display-internal-" type layout] 3) vm-decode-mime-layout([("text/html" "charset=us-ascii") ("text/html" "charset=us-ascii") "7bit" nil nil ("inline" "filename=netscape.htm") ("inline" "filename=\"netscape.htm\"") #<marker at 4677 in .vmail 0x87c764c> #<marker at 4805 in .vmail 0x87c7634> #<marker at 12043 in .vmail 0x87fe0d4> nil nil nil]) vm-mime-display-internal-multipart/mixed([("multipart/mixed" "boundary=---bOuNdArY---") ("multipart/mixed" "boundary=\"---bOuNdArY---\"") "7bit" nil nil nil nil #<marker at 2563 in .vmail 0x87c78d4> #<marker at 4514 in .vmail 0x87c78bc> #<marker at 12064 in .vmail 0x87c77e4> ([... ... "7bit" nil nil nil nil #<marker at 4577 in .vmail 0x87c7784> #<marker at 4653 in .vmail 0x87c776c> #<marker at 4659 in .vmail 0x87c7664> nil nil nil] [... ... "7bit" nil nil ... ... #<marker at 4677 in .vmail 0x87c764c> #<marker at 4805 in .vmail 0x87c7634> #<marker at 12043 in .vmail 0x87fe0d4> nil nil nil]) nil nil]) byte-code("..." [intern "vm-mime-display-internal-" type layout] 3) vm-decode-mime-layout([("multipart/mixed" "boundary=---bOuNdArY---") ("multipart/mixed" "boundary=\"---bOuNdArY---\"") "7bit" nil nil nil nil #<marker at 2563 in .vmail 0x87c78d4> #<marker at 4514 in .vmail 0x87c78bc> #<marker at 12064 in .vmail 0x87c77e4> ([... ... "7bit" nil nil nil nil #<marker at 4577 in .vmail 0x87c7784> #<marker at 4653 in .vmail 0x87c776c> #<marker at 4659 in .vmail 0x87c7664> nil nil nil] [... ... "7bit" nil nil ... ... #<marker at 4677 in .vmail 0x87c764c> #<marker at 4805 in .vmail 0x87c7634> #<marker at 12043 in .vmail 0x87fe0d4> nil nil nil]) nil nil]) vm-decode-mime-message() vm-show-current-message() vm-scroll-forward(nil) call-interactively(vm-scroll-forward)

1 participants
0 comments

My thoughts on package-delete (was Re: Fighting with packages!) 26 years, 2 months

SL Baur

[I'm redirecting this response back to xemacs-beta] >>> Currently, you need to know exactly which info/ and etc/ files >>> get installed by the package to actually remove it. The lisp/ >>> directory at least has subdirectories for each of the packages. sb> Right. Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: > Lists of these files should be slots in the package-get-base > structure. That's not the way I'm planning on doing it. For the first implementation I planned on being very simple minded about it. We know the list of files to install by doing and saving a `tar tf' of the package we're installing. This MANIFEST needs to be saved somewhere after installation. We could save either the list of files or a machine-generated deletion shell script. The former would be more flexible. As good a place as any to save these would be in etc/MANIFEST/, with the individual file names being derived from the package name. That way we can `locate-data-file' and friends to access them from Lisp. If we store it as the package name + package version number, we have the ability to detect the situation where the installed Lisp package doesn't match the version in the database. I am assuming that this file *does not* come in the package tarball. It is generated by the same procedure that installs it. This won't completely work for de-installation because we need things to work somewhat even if the MANIFEST files get misplaced[1]. We also need to deal with files that may not be present at installation (*~ backup files come to mind). A brute force thing to do is to `/bin/rm -rf etc/${PACKAGE} lisp/${PACKAGE}' in addition to removing all the files from a previously installed version. This will also catch the case where a file has been removed from a package and the installed MANIFEST file is missing. If the MANIFEST generation/previous version deletion is done in the lib-src shell scripts it will be transparent to package-get *and* still allow for manual package installation from the command line so long as the scripts are used. Footnotes: [1] Do we really? It will certainly help testers who already have a populated Lisp package hierarchy and bozos like me who will forget and install things by manual untar in the appropriate directory.

2 participants
1 comments

Re: scheme - my opinion 26 years, 2 months

Hrvoje Niksic

"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. Neither CL nor Scheme contain descriptions of "text objects", I think. > 2. What constructs in one dialect would be difficult or impossible to > implement efficiently in the other? Why is this an issue? I don't *want* to implement Scheme in CL, nor do I want to implement CL in Scheme. > 3. Where will it be hard to emulate current elisp efficiently? It is my hope that it will be possible to evaluate Emacs Lisp from Common Lisp "directly", within a specific package, without the need for a translator. I have not delved into this further, but Erik Naggum proposed some interesting ideas in his articles. An example of Erik's idea is to use the CL package system for our advantage. For example, in `.el' files, `elisp' would be the current package, and elisp::mapcar would grok strings and vectors. Also, within these files, the reader would grok [] as vector syntax. Etc. > 4. Where the semantics of common constructs differ among elisp, > Common Lisp, and Scheme, how hard is it going to be for casual elisp > programmers to make the switchover? Lars expanded on this nicely. It is much easier for elisp programmers to switch to CL than to Scheme. > 5. Do we or CLisp or any of the suggested Scheme variants have an API > that will allow us to separate the Lisp engine proper from extensions, > like the C-level support for fontification? I'm not sure about clisp. Michael claims that there are Scheme variants with excellent FFI's, and I believe him. > This is especially important if we hope to offload Lisp engine > maintenance, as Bruno has offered to do for CLisp. Bruno already maintains clisp, no matter what we do. What he offered to do is help us implement the additional Emacs-specific stuff within clisp, such as `DEFINE_LRECORD_IMPLEMENTATION' lookalikes. > mb> Scheme has been designed for programming language research, > mb> rather than practical use. It has such a history of > mb> minimalism that all scheme implementations had to provide > mb> extensions to be useful. > > Hmm. Sounds like Common Lisp is going to require lots of extensions > to be useful to us, to me. CLtL1, at least, makes no reference to > editing buffers or multilingual text processing, frames or extents. True, but the same goes for Scheme. What Martin really meant was more clearly explained in Lars' messages. > Minimal is good, if we want to support different extension > languages. I don't think we want to do that, with the single exception of Emacs Lisp. At least I would argue against that. > Minimal is good, if we are going to end up having to maintain the Lisp > engine ourselves. Yes, Bruno says that he will help maintain a Common > Lisp engine specific to XEmacs. Does he understand that that will > possibly include things like C-level support for fontification? C-level support for fontification has nothing to do with the Lisp engine, and will surely not be maintained by Bruno. > mb> It still is missing many things. For example, my beloved > mb> (when ...) is missing (from the standard). Hashtables are > mb> missing. > > (when ...) is a trivial macro, isn't it? ("Very useful" and now > "beloved"! What loyalty a trivial extension can engender!) > > Hashtables, we can do. > > Why would having these (and many similar items, I'm sure) _in the > standard_ be useful to us? Because then you don't have to rely on incompatible extensions. Again, see Lars' DELETE-IF example. > mb> (call-with-current-continuation) is a very interesting > mb> function, but one cannot expect ordinary humans to understand > mb> it. It is only a tool for system implementors. > > XEmacs is a system, is it not? _We_ are system implementors. (Sorry > for the implicit self-aggrandizement.) However, I will leave call/cc's > serious usage to Michael and the Mark II version of Karl Hegbloom ;-) > I imagine most package writers and so on will do so, too. > > If we can get coroutines and threads as cheaply as Michael suggests, > that is a _big_ deal. I'm afraid we can't. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- 4. Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if it bee the sig of the Inner Circle.

2 participants
1 comments

Eek! 26 years, 2 months

SL Baur

Ben Wing <ben(a)666.com> writes: > ;;;;;;;;;;;;;;;;;;;;;;;;;;;; `point' > (define-obsolete-function-alias 'dot 'point) > (define-obsolete-function-alias 'dot-marker 'point-marker) > (define-obsolete-function-alias 'dot-min 'point-min) > (define-obsolete-function-alias 'dot-max 'point-max) > (define-obsolete-function-alias 'window-dot 'window-point) > (define-obsolete-function-alias 'set-window-dot 'set-window-point) This crap was obsolete in Emacs 18! Um, looking through all this ancient cruft we're carrying around is *so* depressing ... :-(

1 participants
0 comments

RE: scheme - my opinion 26 years, 2 months

Reginald Perry

One quick thing. Kent Pitman has recomended that people stop referencing CLtL1 and CLtL2 and instead reference the ansi spec. Since that is quite expensive the next best thing online is the HyperSpec: http://www.harlequin.com/education/books/HyperSpec/FrontMatter/index.html I know that CLtLn make for good toilet reading, but its not a representation of the official spec. You may now return to your normal discourse. -Reggie -----Original Message----- From: owner-xemacs-beta(a)xemacs.org [mailto:owner-xemacs-beta＠xemacs.org]On Behalf Of Jerry James Sent: Monday, July 13, 1998 5:44 PM To: xemacs-beta(a)xemacs.org Subject: Re: scheme - my opinion On Mon, 13 Jul 1998 at 13:23:59 +0900 (JST), "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> wrote: > Hmm. Sounds like Common Lisp is going to require lots of extensions > to be useful to us, to me. CLtL1, at least, makes no reference to > editing buffers or multilingual text processing, frames or extents. > Also, it seems possible to me that Common Lisp specifies some things > we would rather be free to implement in our own way (doesn't CL > specify the use of bucky bits and fonts in character representation, > or did that go away?---I can't find the passage I'm sure I remember in > CLtL1, sorry if this is misinformed). <delurk> Doesn't CLISP include some CLtL2 constructs? I seem to remember that it does. In that case, rather than sifting through the large CLtL1, you may need to dig through the enormous CLtL2. Fortunately for those of us who don't want to buy a copy, it can be accessed online here: <URL:http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html> The part about bits and fonts you mentioned above was removed for CLtL2, as documented here: <URL:http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node25.html> I don't know whether CLISP follows CLtL1 or CLtL2 in this case. </delurk> -- Jerry James Email: jerry(a)cs.ucsb.edu WWW: http://www.cs.ucsb.edu/~jerry/

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