April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: giflib, what version and WHERE? 26 years, 7 months

P. E. Jareth Hein

Jens Lautenbacher <jens(a)tellux.de> writes: > OK, it seems XEmacs wants version 3.1, but I've been unable to find > this somewhere... all I see are rpms for 3.04 or such... > > any pointers would be welcome.. giflib 3.1 is mine, but I'm getting cold feet... Unisys is apparently getting frisky (again) about enforcing patents, and my publicly releasing giflib sounds like I could be opening myself up for a world of hurt. For now, you can find the latest version on http://www.camelot-soft.com/~jareth but I'm not sure how long it'll be there. Anybody have any experience with patent law and how that applies to public, freely available software? -- Jareth Hein | jareth(a)camelot-soft.com | ハインジェラス Toolsmith & Program lead | http://www.camelot-soft.com | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."

3 participants
2 comments

Re: [Success] XEmacs 21.0-b38 "Repartida-pre2" on i686-linux 26 years, 7 months

SL Baur

toge <toge(a)accad1.kek.jp> writes: > BTW, gnus in the X-window mode barks at me unless I also install w3. > The reason is that gnus wants images.el which is part of w3. > I guess there are cases where the user wants to use gnus but not w3. > Can images.el be part of xemacs-base or something, or am I too picky? Could you please get and post a lisp stack backtrace? Thanks. (setq debug-on-error t) and recreate the problem.

2 participants
1 comments

Re: select-window focus problem [was: Re: minor compile.el bug] 26 years, 7 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> BTW, are you aware that FSF 20.3 sets focus-follows-mouse to t by > Hrvoje> default? Maybe we should copy what they do? > > I've had the vague feeling that our focus-handling has been bogus for > a long time. Apparently it's something that is hard to get right, and > some past patches have been switching between different behaviors, > none of which make everyone happy. This is true, but, as I said before, I am very satisfied with Greg's latest patch, except for the `C-x 5 o' part. Note, though, that I have *not* read the relevant X docs, so I cannot guarantee that this behaviour is X-ly correct. Maybe someone who knows X should look at it and comment? Glynn, maybe? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Jone's law: The man who smiles when things go wrong has thought of someone to blame it on.

3 participants
2 comments

Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows) 26 years, 7 months

Hrvoje Niksic

Pete Ware <ware(a)pc-786a.cis.ohio-state.edu> writes: > > Before coding systems came into the picture, Fmd5 was an exemplary > > of Lisp elegance: > > > > `md5' is a built-in function > > (md5 OBJECT &optional START END) > > > > Documentation: > > Return the MD5 message digest of OBJECT, a buffer or string. > > > > Optional arguments START and END denote positions for computing the > > digest of a portion of OBJECT. > > > I'm a MOLE (MOnoLingual Emacs) so take what I have with a shalt shaker > but shouldn't OBJECT be in the already appropriate coding system for > whatever the message digest is being computed? Nope. OBJECT is a buffer or string in internal XEmacs format, and we don't want to calculate a digest of the internal representation (that's what the old non-Mule-ized code did), but of the external representation, as saved to disk etc. > To put it another way, shouldn't there be a set of functions that > given an OBJECT in one coding system return another OBJECT in a > different coding system? It would be very wasteful, I think. -- 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!

2 participants
1 comments

Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows) 26 years, 7 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> No, the idea is fine. But is it the best thing to infest > Hrvoje> random primitives with CODING-SYSTEM arguments? Isn't > Hrvoje> there a more general variable that can be set? Please > Hrvoje> bear with me -- I know very little about coding systems > Hrvoje> and stuff, so maybe I'm just raving. > > Sigh. You _should_ rave. Heaven knows, Erik Naggum does. :-) > In the current implementation of Mule, coding systems are a property > of ... you can't really be sure. And their semantics are ... rather > ad hoc. This looks like a major problem, in major need of fixing. > In the particular case of Fmd5 and the uses of it that I know about, > it probably doesn't need it; proper care in implementation should > have Fmd5 use the output coding-system (but this must be specified > by the mailer, and most mailers do the translation to standard > Internet mail encodings as a post-processing step). But then, the > original implementor of md5 didn't consider that Steve Baur was > going to use XEmacs to md5 checksum packages' external > representation; he thought it would be OK as long as the buffer > representation would be checksummed correctly. So I wouldn't bet on > it. For the record: I *do* note that md5 checksums are useful for things other than the internal buffer representation. But I don't think that `md5' *function* should have that additional CODING-SYSTEM argument. Couldn't it pick the coding system from a generally useful variable, like coding-system-for-write? Am I making any sense? > The problem is that often textual source which you would like to > combine in a buffer have varied encodings to start with. So some > choice of buffer representation and mechanisms for translation are > needed. Note that "textual source" not only means files that are > encoded differently, but also you may have process and user input > in yet other encodings. Well, this is true, but the case of `md5' calculating a digest is surely no harder than the case of `C-x C-s' saving the buffer, if you see what I mean... > The problems that we are currently discussing stem, in my opinion, > from the lack of an good extent abstraction in Mule. This means that > source and target encodings must be defined either as properties of > characters or as a property of a whole stream. The former is ugly, > time-consuming, and mistake-prone; the latter is simply not > fine-grained enough. So you end up with coding-system specifications > in operators. Yuck. Yes, I think you have a point. > Concretely, this would be like the current situation with no-mule > XEmacs where you can change a buffer displayed as junk to legible > Croatian by changing the face from a *-iso8859-1 to a *-iso8859-2 > font.[4] That would be cool. Even cooler would be to be able to specify the default latin* character set, so that when I encounter Š anywhere in a file, I want to see it as Š, not as the copyright symbol. Sort of "trus me pal, I know it's latin2." This is one big advantage of non-Mule XEmacs over Mule XEmacs for Croatian (and similar languages.) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Personifiers Unite! You have nothing to lose but Mr. Dignity!

3 participants
3 comments

Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows) 26 years, 7 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > But if you're actually going to stuff it into a TCP/IP stream via a > process buffer, you need to use coding-system-for-process-output (or > whatever the appropriate variable is named). OK, this is the crux of your argument, and I see what you mean. Still, how often does coding-system-for-write differ from coding-system-for-process-output? If such case is degenerated, then using a coding-system-for-md5 variable might not be such a bad idea, because it would be used only very rarely. > It seems to me that in any case where external and internal > encodings differ, Fmd5 needs to know how you plan to use its value. > In a world where the external encodings are chosen by oracle, you > need an argument to Fmd5. You can either make it explicit, > optional, and default it as Jareth has done It's not as simple as that. Remember that we are creating, among other things, a programming language. Before coding systems came into the picture, Fmd5 was an exemplary of Lisp elegance: `md5' is a built-in function (md5 OBJECT &optional START END) Documentation: Return the MD5 message digest of OBJECT, a buffer or string. Optional arguments START and END denote positions for computing the digest of a portion of OBJECT. This is as nice as it can get. However, with Mule, it suddenly got 10 additional lines of docstring and two more optional arguments that have *nothing* to do with the process of md5-ing a stream of bytes, and that are very (Mule)-implementation specific. These uglifications are not to be taken lightly. Imagine what would happen if we wanted to, say, add another "real" argument to Fmd5, say GRANULARITY, or whatever? For compatibility, it would have to go *after* the Mule arguments, and callers would have to write: (md5 foo nil nil nil nil 10000) The number of useless arguments is obscene. This example is, of course, purely hypothetical (there is no such thing as MD5 granularity), and the point I'm trying to make is that interface to user-visible Lisp functions should be well thought-out, or problems will arise. -- 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!

3 participants
3 comments

Plea for minimal tagbits 26 years, 7 months

Olivier Galibert

I'd like to see --use-minimal-tagbits being default, and the other alternative actually removed. Rationale: - per Kyle's study, performance is equivalent - we have to settle on one of the options for code-freezing time in order to ensure proper testing on all architectures - not munging pointers is infinitely better because: * it removes the need for DATA_SEG_BITS which, basically, sucks * it makes purify-like memory leak detection possible - it gives us 31bits integers and 30bits characters, and *ensures* that we have them as soon as version>=21.0 - code in lisp.h becomes cleaner (the less #ifdefs, the better) What do you think ? OG.

3 participants
3 comments

Re: [patch] mic-paren auto-insinuates 26 years, 7 months

Greg Klanderman

Steve, Did this get applied? greg >>>>> "gk" == Greg Klanderman <greg(a)alphatech.com> writes: gk> gk> Bitten while browsing the customize menus... gk> gk> Reversing the sense and renaming this `paren-activate-on-load' gk> would avoid a confusing double negative. I sat and looked at gk> this for far too many seconds thinking "but it's already `nil'"... gk> gk> greg gk> gk> gk> gk> 1998-03-15 Greg Klanderman <greg(a)alphatech.com> gk> gk> * mic-paren.el (paren-dont-activate-on-load): default to t. gk> gk> gk> --- ../.backups/mic-paren.el!!!proj!mstar!software!xemacs!xemacs-20.5!packages!lisp!edit-utils!.~1~ Wed Feb 4 04:41:57 1998 gk> +++ lisp/edit-utils/mic-paren.el Sun Mar 15 18:16:17 1998 gk> ＠＠ -181,7 +181,7 ＠＠ gk> gk> ;;; ------------------------------ gk> gk> -(defvar paren-dont-activate-on-load nil gk> +(defvar paren-dont-activate-on-load t gk> "*If non-nil mic-paren will not activate itself when loaded.") gk> gk> ;;; ------------------------------ gk>

1 participants
0 comments

Re: [Failure] 21.0 "Repartida-pre1" XEmacs Lucid (beta38) on sparc-sun-solaris2.6 26 years, 7 months

Gunnar Evermann

SL Baur <steve(a)xemacs.org> writes: > Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > > > beta38-pre1 works if I compile without workshop support (see > > build-report below) > > Do you have the `pc' package installed? At first I didn't but when I added it nothing changed, so I removed it again. Right now I only have: Sun-1.05-pkg.tar.gz mail-lib-1.10-pkg.tar.gz tooltalk-1.04-pkg.tar.gz xemacs-base-1.18-pkg.tar.gz > Jason has reported problems with Workshop support for quite awhile > now. Oh, I must have missed those (Jason uses x86, right?) > Maybe someday, someone with access to a Sun will fix it. I do have the access, but lack the knowledge :-( > > If I compile --with-workshop xemacs crashes (see Lisp/C backtraces > > this looks very similar to the crash George reported in his bleeding > > edge OS/cc environment) > > I have a feeling this is fixed by Jareth's image patch. > > I'm going to make another snapshot tonight, btw. didn't help! (same backtrace, see below) I ran xemacs from inside dbx and put a breakpoint in print_error_message. - at first everything looks great (I think?!) (dbx) pobj error_object (struct Lisp_Cons *) 7319308 = 0x6faf0c *(struct Lisp_Cons *) 7319308 = { lheader = { type = 6U mark = 0 pure = 0 } car = 5992620 cdr = 7319260 } (dbx) pobj stream (struct Lisp_Symbol *) 5992480 = 0x5b7020 *(struct Lisp_Symbol *) 5992480 = { lheader = { type = 5U mark = 0 pure = 0 } next = (nil) name = 0x4aa9f4 value = 5992480 function = 5719156 obarray = 0 plist = 5992452 } Symbol name: 0x477cb8 "t" - at line 664 "Wrong type argument:" is printed by FPrinc - the first time Fprin1 at line 669 is executed "stringp" is printed (dbx) pobj tail (struct Lisp_Cons *) 7319260 = 0x6faedc *(struct Lisp_Cons *) 7319260 = { lheader = { type = 6U mark = 0 pure = 0 } car = 6072408 cdr = 7319248 } - tail= Fcdr(tail) is executed (dbx) pobj tail (struct Lisp_Cons *) 7319248 = 0x6faed0 *(struct Lisp_Cons *) 7319248 = { lheader = { type = 6U mark = 0 pure = 0 } car = 6067492 cdr = 5992452 } at the next call to FPrin1 at line 669 everything blows up! in FPrin1: (dbx) pobj object warning: subscript out of range Unknown Lisp Object type object = 6067492 I'm not sure what to do next.... (I promise to read the Internals Manual over the weekend :-) ) Gunnar ---------------------------------------------------------------------- (dbx) where [1] 0x4b0360(0x5c9524, 0x5d21e0, 0x1, 0xefffda74, 0x13, 0x0), at 0x4b035f =>[2] print_internal(obj = 6067492, printcharfun = 6103520, escapeflag = 1), line 1203 in "print.c" [3] print_cons(obj = 7315628, printcharfun = 6103520, escapeflag = 1), line 904 in "print.c" [4] print_internal(obj = 7315664, printcharfun = 6103520, escapeflag = 1), line 1203 in "print.c" [5] Fprin1(object = 7315664, stream = 6103520), line 502 in "print.c" [6] Fbacktrace(stream = 6103520, detailed = 5992480), line 4927 in "eval.c" [7] fatal_error_signal(sig = 4), line 244 in "emacs.c" ---- called from signal handler with signal 4 (SIGILL) ------ [8] 0x4b0360(), at 0x4b035f [9] Fprin1(object = 6067492, stream = 5992480), line 502 in "print.c" [10] print_error_message(error_object = 7315664, stream = 5992480), line 669 in "print.c" [11] Fdisplay_error(error_object = 7315664, stream = 5992480), line 700 in "print.c" [12] funcall_recording_as(recorded_as = 6103268, nargs = 2, args = 0xefffe7c8), line 3197 in "eval.c" [13] Ffuncall(nargs = 3, args = 0xefffe7c8), line 3238 in "eval.c" [14] Fbyte_code(bytestr = 5073904, vector = 5074044, maxdepth = 11), line 416 in "bytecode.c" [15] funcall_lambda(fun = 5074248, nargs = 1, arg_vector = 0xefffeb5c), line 3599 in "eval.c" [16] funcall_recording_as(recorded_as = 6070724, nargs = 1, args = 0xefffeb58), line 3200 in "eval.c" [17] Ffuncall(nargs = 2, args = 0xefffeb58), line 3238 in "eval.c" [18] call1(fn = 6070724, arg0 = 7315664), line 3912 in "eval.c" [19] cmd_error(data = 7315664, dummy = 5992452), line 195 in "cmdloop.c" [20] condition_case_1(handlers = 5992564, bfun = 0x100650 = &Feval(Lisp_Object form), barg = 6235724, hfun = 0xa5710 = &`xemacs`cmdloop.c`cmd_error(Lisp_Object data, Lisp_Object dummy), harg = 5992452), line 1636 in "eval.c" [21] top_level_1(dummy = 5992452), line 206 in "cmdloop.c" [22] internal_catch(tag = 6070780, func = 0xa57f0 = &`xemacs`cmdloop.c`top_level_1(Lisp_Object dummy), arg = 5992452, threw = (nil)), line 1328 in "eval.c" [23] initial_command_loop(load_me = 5992452), line 285 in "cmdloop.c" [24] xemacs_21_0_b38_sparc_sun_solaris2_6(argc = 1, argv = 0xefffeffc, envp = 0xeffff004, restart = 0), line 1673 in "emacs.c" [25] main(argc = 1, argv = 0xefffeffc, envp = 0xeffff004), line 2090 in "emacs.c" (dbx)

3 participants
2 comments

[PATCH] Support Neanderthal vendor-provided makes 26 years, 7 months

Martin Buchholz

I don't have access to a SGI or HP make. Could someone check that with this patch, make now works? (Steve, this is to be applied in any case) 1998-04-30 Martin Buchholz <martin(a)xemacs.org> * Makefile: Support generic makes by avoiding `%' syntax. It breaks my heart to uglify the Makefile like this, but this is going to be a perpetual FAQ otherwise. General cleanup. Comment out w3 and vm info rules. Use paranoid cd ./$＠ syntax to avoid losing with luser's CDPATH. --- man/Makefile.old +++ man/Makefile ＠＠ -36,73 +36,121 ＠＠ RECURSIVE_MAKE = $(MAKE) $(MFLAGS) MAKEINFO='$(MAKEINFO)' TEXI2DVI='$(TEXI2DVI)' +# Ughhh! The things we do to have portable makefiles... + +INFODIR = ../info + +info_files = \ + $(INFODIR)/cl.info \ + $(INFODIR)/custom.info \ + $(INFODIR)/external-widget.info \ + $(INFODIR)/info.info \ + $(INFODIR)/standards.info \ + $(INFODIR)/term.info \ + $(INFODIR)/termcap.info \ + $(INFODIR)/texinfo.info \ + $(INFODIR)/widget.info \ + $(INFODIR)/xemacs-faq.info + +dvi_files = \ + cl.dvi \ + custom.dvi \ + external-widget.dvi \ + info.dvi \ + standards.dvi \ + term.dvi \ + termcap.dvi \ + texinfo.dvi \ + widget.dvi \ + xemacs-faq.dvi + +../info/cl.info : cl.texi + -$(MAKEINFO) cl.texi -o ../info/cl.info + +../info/custom.info : custom.texi + -$(MAKEINFO) custom.texi -o ../info/custom.info + +../info/external-widget.info : external-widget.texi + -$(MAKEINFO) external-widget.texi -o ../info/external-widget.info + +../info/info.info : info.texi + -$(MAKEINFO) info.texi -o ../info/info.info + +../info/standards.info : standards.texi + -$(MAKEINFO) standards.texi -o ../info/standards.info + +../info/term.info : term.texi + -$(MAKEINFO) term.texi -o ../info/term.info + +../info/termcap.info : termcap.texi + -$(MAKEINFO) termcap.texi -o ../info/termcap.info + +../info/texinfo.info : texinfo.texi + -$(MAKEINFO) texinfo.texi -o ../info/texinfo.info + +../info/widget.info : widget.texi + -$(MAKEINFO) widget.texi -o ../info/widget.info + +../info/xemacs-faq.info : xemacs-faq.texi + -$(MAKEINFO) xemacs-faq.texi -o ../info/xemacs-faq.info + + +# ../info/w3.info : w3.texi +# -$(MAKEINFO) w3.texi -o ../info/w3.info + +# ../info/vm.info : vm.texi +# -$(EMACS) $(EMACSFLAGS) -insert vm.texi -l texinfmt \ +# -f texinfo-format-buffer -f save-buffer +# -mv vm.info* ../info + +# special = # ../info/w3.info ../info/vm.info ../info/texinfo.info + +all: info + # Subdirectories to make recursively. SUBDIR = xemacs lispref new-users-guide internals +.PHONY: $(SUBDIR) -../info/%.info : %.texi - -$(MAKEINFO) -o $＠ $< +info : $(info_files) + -for d in $(SUBDIR) ; do (cd ./$$d && $(RECURSIVE_MAKE) $＠) ; done -srcs = cl custom external-widget \ - info \ - standards term \ - termcap texinfo widget xemacs-faq - -info = $(srcs:%=../info/%.info) -dvi = $(srcs:%=%.dvi) - -special = # ../info/w3.info ../info/vm.info ../info/texinfo.info - -all : info -info : $(info) $(special) - -for d in $(SUBDIR) ; do (cd $${d} && $(RECURSIVE_MAKE) $＠) ; done +.PHONY: info dvi xemacs: FRC.xemacs - -cd $＠ && $(RECURSIVE_MAKE) + -cd ./$＠ && $(RECURSIVE_MAKE) lispref: FRC.lispref - -cd $＠ && $(RECURSIVE_MAKE) + -cd ./$＠ && $(RECURSIVE_MAKE) new-users-guide: FRC.new-users-guide - -cd $＠ && $(RECURSIVE_MAKE) + -cd ./$＠ && $(RECURSIVE_MAKE) internals: FRC.internals - -cd $＠ && $(RECURSIVE_MAKE) -tm: FRC.tm - -cd $＠ && $(RECURSIVE_MAKE) -gnats: FRC.gnats - -cd $＠ && $(RECURSIVE_MAKE) -FRC.xemacs FRC.lispref FRC.new-users-guide FRC.internals FRC.tm FRC.gnats: + -cd ./$＠ && $(RECURSIVE_MAKE) +# tm: FRC.tm +# -cd ./$＠ && $(RECURSIVE_MAKE) +# gnats: FRC.gnats +# -cd ./$＠ && $(RECURSIVE_MAKE) +# FRC.xemacs FRC.lispref FRC.new-users-guide FRC.internals FRC.tm FRC.gnats: +FRC.info FRC.dvi FRC.xemacs FRC.lispref FRC.new-users-guide FRC.internals: -../info/w3.info : w3.texi - -$(MAKEINFO) w3.texi -o ../info/w3.info -../info/texinfo.info : texinfo.texi - -$(MAKEINFO) texinfo.texi -o ../info/texinfo.info - - -../info/vm.info : vm.texi - -$(EMACS) $(EMACSFLAGS) -insert vm.texi -l texinfmt \ - -f texinfo-format-buffer -f save-buffer - -mv vm.info* ../info - -texinfo.dvi: texinfo.texi - $(TEXI2DVI) $< .texi.dvi: $(TEXI2DVI) $< -.PHONY: dvi -dvi : $(dvi) - -for d in $(SUBDIR) ; do (cd $${d} && $(RECURSIVE_MAKE) $＠) ; done +dvi : $(dvi_files) + -for d in $(SUBDIR) ; do (cd ./$${d} && $(RECURSIVE_MAKE) $＠) ; done + .PHONY: mostlyclean clean distclean realclean extraclean mostlyclean: - -for d in $(SUBDIR) ; do (cd $${d} && $(RECURSIVE_MAKE) $＠) ; done - rm -f *.toc *.aux *.log \ + -for d in $(SUBDIR) ; do (cd ./$${d} && $(RECURSIVE_MAKE) $＠) ; done + rm -f *.toc *.aux *.log *.op \ *.cp *.cps *.fn *.fns *.ky *.kys *.pg *.pgs *.vr *.vrs *.tp *.tps clean: mostlyclean - -for d in $(SUBDIR) ; do (cd $${d} && $(RECURSIVE_MAKE) $＠) ; done + -for d in $(SUBDIR) ; do (cd ./$${d} && $(RECURSIVE_MAKE) $＠) ; done rm -f *.o core *.dvi distclean: clean - -for d in $(SUBDIR) ; do (cd $${d} && $(RECURSIVE_MAKE) $＠) ; done + -for d in $(SUBDIR) ; do (cd ./$${d} && $(RECURSIVE_MAKE) $＠) ; done realclean: distclean - -for d in $(SUBDIR) ; do (cd $${d} && $(RECURSIVE_MAKE) $＠) ; done + -for d in $(SUBDIR) ; do (cd ./$${d} && $(RECURSIVE_MAKE) $＠) ; done extraclean: distclean - -for d in $(SUBDIR) ; do (cd $${d} && $(RECURSIVE_MAKE) $＠) ; done + -for d in $(SUBDIR) ; do (cd ./$${d} && $(RECURSIVE_MAKE) $＠) ; done -rm -f *~ \#*

2 participants
1 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 April 1998