June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 24 years, 10 months

SL Baur

Watch the quoting. Andy Piper <andy(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > At 04:05 PM 6/25/99 +0900, SL Baur wrote: Michael Sperber wrote: >>> - A new variant of REQUIRE would allow specifying a version or minimum >>> version for it to succeed. >> >> O.K. > BTW I am intending to modify provide so that you can do things on a device > specifc basis. This is sorely needed for some of the graphics capabilities, > e.g. > (provide 'button 'mswindows) > Speak now if this is ideologically unacceptable. Probably. Why at a device level? What do you propose the corresponding semantics of (require 'button) to be? -- 果報は寝て待て

2 participants
1 comments

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 24 years, 10 months

Michael Sperber

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> [It's time, I think, to move this to xemacs-beta] Yes. sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-review(a)xemacs.org: >>>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-review(a)xemacs.org: sb> ... >>>> I don't really intend to mess with the package layout (as opposed to >>>> the package hierarchy layout) at all; I personally think this whole >>>> issue is fucked beyond the point of redemption. sb> These are strong words. If things are really this fucked up then they sb> should be fixed. I did not mean to offend anyone. I don't disagree with the way things have gone. It's just that package organization questions are generally very difficult. (Debian and RedHat spent inordinate amounts of time creating giant general-purpose packaging tools, and they still suck.) Thus, things could be much worse. sb> All of the changes I've made have been fairly conservative. If we sb> really needed to, it wouldn't take more than perhaps a day to undo sb> everything and return to a 20.4-style source tree. I pray we do not do sb> this. Recall that we went through that exercise to create 20.3. Absolutely. That was also my main goal in reimplementing startup path searching. Still I got yelled at massively for even the tiniest change (justifiedly in some cases), moreover, I was made responsible for package system design issues I had had no part in. This makes me not very eager to go through something much worse. I've tried posting design notes before implementing things, and still got yelled at when the beta came out that actually had them. I tried being responsive to people's suggestions in response to my designs, and then got yelled at for not implementing something which turned out to be my original design noone had bothered to read carefully. At this point, to do anything, I need some backing from at least one of the major maintainers. I'll share all my thoughts, but I don't want to have to respond to every single nitpick. >> - A package version would be able to associate or disassociate itself >> with/from a certain Emacs version. sb> I suppose. I really, really don't like code that decides what to do sb> based on an Emacs version. Wrong wording on my part. You want a package to be able to say that it doesn't run in a certain Emacs, based on arbitrary criteria. A toolbar package (or whatever) might not make sense in a tty-only Emacs, for instance. sb> That would be a departure from how things worked in XEmacs 20.x and sb> that is why I didn't do it that way. Right, and I agree with that decision. sb> I am not adverse to changing things now, and so long as the sb> programming interface remains the same or very similar, it sb> shouldn't be a lot of work to migrate to a different layout. I guess I need to know what exactly the programming interface really is. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

seen on /. -- what LINUX stands for 24 years, 10 months

SL Baur

Did you ever think... by Anonymous Coward on Friday June 25, ＠09:16AM JST ...that she might have done this on purpose just to get some attention to her cause. blah. It looks that way. Think about it, microsoftsearch? or linuxsearch (and say linux stands for the 'Linguistic Institute of Nocutrnal Undertakers on Xemacs'. :-) -- 善は急げ

1 participants
0 comments

Thoughts on XEmacs packaging (was Re: Making docdir configurable) 24 years, 10 months

SL Baur

[It's time, I think, to move this to xemacs-beta] Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-review(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-review(a)xemacs.org: sb> ... >>> I don't really intend to mess with the package layout (as opposed to >>> the package hierarchy layout) at all; I personally think this whole >>> issue is fucked beyond the point of redemption. These are strong words. If things are really this fucked up then they should be fixed. All of the changes I've made have been fairly conservative. If we really needed to, it wouldn't take more than perhaps a day to undo everything and return to a 20.4-style source tree. I pray we do not do this. Recall that we went through that exercise to create 20.3. When InfoDock sources get released in a few weeks, you should probably take a look at how it uses packaging. It is a hybrid system, half-way between monolithic 20.4 and packaged 21.x. sb> Then how would you have done it? > Back when the discussion about the package system started (Chuck was > still around then), I posted a fairly complete concept for one; this > was probably in 1997, I don't know if anyone still has archives. This was on the old xemacs-beta-discuss, right? I no longer have archives but I recall the message you are referring to. I thought long and hard about it as I first started coding things up. > I even started coding it, but when I asked for volunteers to help, > noone stepped forward. When the current system popped up, I assumed > nobody was interested. I didn't know about the coding part. I vaguely recall[1] you mentioning that you would code it yourself if no one else was going to do it, but then you disappeared for awhile. If I had seen any code whatsoever, I wouldn't have started a variant implementation. It's not like there has been a massive investment of coding anyway. Nearly all of the work has been organizational in nature. > The main insight is that XEmacs needs to know about package versions, > and that there need to be several mechanisms to deal with them. I know. I started to deal with this via an ill-defined `package-provide' and `package-require' that never worked out. > Roughly: > - Several versions of the same package can coexist, if not in the same > running XEmacs, then at least within its reach before any of them > have been loaded. O.K. > - A new variant of REQUIRE would allow specifying a version or minimum > version for it to succeed. O.K. > - There needs to be a way to specify version preferences. O.K. > - A package version would be able to associate or disassociate itself > with/from a certain Emacs version. I suppose. I really, really don't like code that decides what to do based on an Emacs version. > Back then, I thought that symbolic links would solve the problem. > (They work well enough for our 200+-package software installation, for > which we have locally developed tools.) Today, I've concluded > (especially now that the NT port is around) that this information can > more flexibly be encoded in Elisp. Yes. > The obvious symptom currently is that XEmacs doesn't know which > package an auto-autoloads.el file belongs to, and cannot deal with > several auto-autoloads.el files belonging to different versions of the > same package, short of coming up with a meaningless error message. Right. I've never been happy about this currently works. > This is something I plan to fix once I have the time. Share with us your thoughts on what The Right Thing to do is. Perhaps you won't have to code it yourself. > I also think it's a mistake to spread a package over different places > in a package hierarchies, and to require consistency of the > installation situation with the MANIFEST files. The MANIFEST files were an accidental feature. There certainly isn't a requirement that they be kept in synch, but it makes things somewhat easier if they are. > With one directory per package, things like package deletion would > be much more simple, and access to auxiliary files could actually do > the Right Thing and ensure coherence between different parts of one > package. That would be a departure from how things worked in XEmacs 20.x and that is why I didn't do it that way. I am not adverse to changing things now, and so long as the programming interface remains the same or very similar, it shouldn't be a lot of work to migrate to a different layout. I like a plug-n-play XEmacs (and InfoDock for that matter) that I can strip of useless bloat I will never use. I like that a lot. I recognize there are some problems left to solve, but I think things are better off now than they were in 20.x and the hardest work has been done. The main problems are ones that existed in a monolithic XEmacs too. Fine tuning things so it actually works well under the conditions you mention above shouldn't be impossible (IMHO). Footnotes: [1] If one really trusts a blonde's memory. Gravity exists so that blondes don't forget which way to get out of bed in the morning. :-) -- 雨降って地固まる (Adversity builds character)

2 participants
1 comments

Re: more CVS lossage? 24 years, 10 months

Karl M. Hegbloom

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: >> The other files in test/automated look strange, too (notice the >> ATTIC part): >> ge204＠chicago$ cvs stat tests/automated/lisp-tests.el >> =================================================================== >> File: lisp-tests.el Status: Up-to-date >> Working revision: 1.1.2.6 Repository revision: 1.1.2.6 >> /usr/CVSroot/XEmacs/xemacs/tests/automated/Attic/lisp-tests.el,v >> Sticky Tag: r21-2-17 (revision: 1.1.2.6) Sticky Date: (none) >> Sticky Options: (none) >> I doubt that this is a local problem as I am seeing this on >> both of my CVS trees (work and home). sb> They are really in the Attic. I do not know why. -- ~~~~~ I think that anything not on the HEAD goes into the ATTIC. Since the r21-2-.* stuff isn't on the trunk, files committed to it are in the ATTIC in the repository.

1 participants
0 comments

[BUG:21.2.b17] Cannot open ssh forwarded display. 24 years, 10 months

Karl M. Hegbloom

I'm logged into a machine across the room with ssh, and compiled XEmacs 21.2 there. It starts fine with -nw, but seg faults when I try to let it open on the X server in front of me. Here's a paste-in of the `where'. #0 0x401a93b5 in () #1 0x8135c22 in Xatoms_of_xselect (d=0x8260bd0) at select-x.c:1740 #2 0x81238b5 in x_init_device (d=0x8260bd0, props=136231156) at device-x.c:731 #3 0x8069c50 in Fmake_device (type=136353092, connection=136231156, props=136231156) at device.c:581 #4 0x807a6ad in Ffuncall (nargs=3, args=0xbffff594) at eval.c:3189 #5 0x8059f5e in execute_optimized_program (program=0x8270554 "ÀÁ\n\"\207", stack_depth=3, constants_data=0x82a5b38) at bytecode.c:748 (I think that's the relevant section.) I do not know how to fix it. Hope someone will.

1 participants
0 comments

[SUCCESS] 21.2 (beta17) "Chiyoda" XEmacs Lucid on i586-pc-linux 24 years, 10 months

John Mignault

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patched up from b16. So far so good. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /usr/local/src/xemacs-21.2.12/Installation: > (Output from most recent run of ./configure) uname -a: Linux jbm 2.0.34 #1 Fri May 8 16:05:57 EDT 1998 i586 unknown ./configure '--dynamic' '--with-database=gnudbm' '--with-xpm' '--with-mule=no' '--with-png=yes' '--with-ldap' '--with-sound=native' '--use-union-type' '--compiler=egcs' '--debug' XEmacs 21.2-b17 "Chiyoda" configured for `i586-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21.2.12 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? egcs -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) 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/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for GNU DBM. Compiling in support for LDAP. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using the union type for Lisp_Objects. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- > /usr/local/src/xemacs-21.2.12/beta.err does not exist! - -- #!/usr/bin/perl $dot="\x2e";$lt="\x3c";$gt="\x3e";$at="\x40"; print "J Mignault ${lt}jbm${at}panix${dot}com${gt}\n"; $quote = qq(I just got my PRINCE bumper sticker.. But now I can't remember WHO he is...); -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.2 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE3coJ87c6UCGj7aaURAng1AJ4/F2MSxgD1OIgMJglu8F7qWjKoPACfSlod oRLOrcWmX9SdUwHpgt8Ov10= =sVa9 -----END PGP SIGNATURE-----

1 participants
0 comments

Re: Weirdness with Fonts in 21.2b17 24 years, 10 months

Jan Vroonhof

Erik Arneson <erik(a)starseed.com> writes: Please give me the values of (face-font 'default) (specifier-spec-list (face-font 'default)) (face-font 'italic) (specifier-spec-list (face-font 'italic)) just before and just after your custom settings are applied. Please also give your custom settings. > They looked just fine before the upgrade. Any idea what could be > causing this? I don't have the time to work on it for the next few days, but if there is anybody brave enough: This is probably because frob-face-property is to able to handle the proper way of doing the fonts. In particular the locale = nil case should _merge_ the fall-back specifier it got from the default font in with the font specifier and not just throw the specifier away. (The problem is that 'italic' has only a device specific specifier, but no global one). Jan

2 participants
1 comments

Re: [Failure] XEmacs 21.2-b17 "Chiyoda", i586-pc-win32 24 years, 10 months

SL Baur

Andy Piper <andy(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > At 09:46 PM 6/23/99 +0900, SL Baur wrote: >> Maybe Andy Piper can comment on what went wrong. There is probably >> something wrong with file-coding/no-Mule. > Its not a file-coding problem, CHAR_ASCII_P and word_boundary_p have been > used unconditionally but are only defined for mule builds. O.K. > All non-mule builds will fail. Someone should fix this quick. O.K. I'm looking at it. > The temporary fix to to back up syntax.c a version to 1.7.2.2. Which isn't an option at all. The Mule bug fixed is a real and highly annoying one. -- 郷に入っては郷に従え

2 participants
1 comments

Re: [Failure] XEmacs 21.2-b17 "Chiyoda", i586-pc-win32 24 years, 10 months

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > Andy Piper <andy(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: >> At 09:46 PM 6/23/99 +0900, SL Baur wrote: >>> Maybe Andy Piper can comment on what went wrong. There is probably >>> something wrong with file-coding/no-Mule. >> Its not a file-coding problem, CHAR_ASCII_P and word_boundary_p have been >> used unconditionally but are only defined for mule builds. > O.K. >> All non-mule builds will fail. Someone should fix this quick. > O.K. I'm looking at it. >> The temporary fix to to back up syntax.c a version to 1.7.2.2. This patch restores the non-Mule code that was removed by the extword patch. Patch tested with file-coding on Unix. 1999-06-24 SL Baur <steve(a)miho.m17n.org> * syntax.c (scan_words): Restore non-Mule code. (word_constituent_p): Restore. Index: src/syntax.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/syntax.c,v retrieving revision 1.7.2.3 diff -u -r1.7.2.3 syntax.c --- src/syntax.c 1999/06/23 08:05:00 1.7.2.3 +++ src/syntax.c 1999/06/24 02:43:21 ＠＠ -327,7 +327,7 ＠＠ } - +#ifdef MULE /* Return 1 if there is a word boundary between two word-constituent characters C1 and C2 if they appear in this order, else return 0. There is no word boundary between two word-constituent ASCII ＠＠ -337,6 +337,17 ＠＠ && word_boundary_p (c1, c2)) extern int word_boundary_p (Emchar c1, Emchar c2); +#else +static int +word_constituent_p (struct buffer *buf, Bufpos pos, + struct Lisp_Char_Table *tab) +{ + enum syntaxcode code = SYNTAX_UNSAFE (tab, BUF_FETCH_CHAR (buf, pos)); + return ((words_include_escapes && + (code == Sescape || code == Scharquote)) + || (code == Sword)); +} +#endif /* Return the position across COUNT words from FROM. If that many words cannot be found before the end of the buffer, return 0. ＠＠ -347,8 +358,10 ＠＠ { Bufpos limit = count > 0 ? BUF_ZV (buf) : BUF_BEGV (buf); struct Lisp_Char_Table *mirrortab = XCHAR_TABLE (buf->mirror_syntax_table); +#ifdef MULE Emchar ch0, ch1; enum syntaxcode code; +#endif while (count > 0) { ＠＠ -358,28 +371,41 ＠＠ { if (from == limit) return 0; +#ifdef MULE ch0 = BUF_FETCH_CHAR (buf, from); code = SYNTAX_UNSAFE (mirrortab, ch0); +#else + if (word_constituent_p (buf, from, mirrortab)) + break; +#endif from++; +#ifdef MULE if (words_include_escapes && (code == Sescape || code == Scharquote)) break; if (code == Sword) break; +#endif } QUIT; - while ( from != limit ) + while ((from != limit) +#ifndef MULE + && word_constituent_p (buf, from, mirrortab) +#endif + ) { +#ifdef MULE ch1 = BUF_FETCH_CHAR (buf, from); code = SYNTAX_UNSAFE (mirrortab, ch1); if (!(words_include_escapes && (code == Sescape || code == Scharquote))) if (code != Sword || WORD_BOUNDARY_P (ch0, ch1)) break; - from++; ch0 = ch1; +#endif + from++; } count--; } ＠＠ -392,7 +418,12 ＠＠ { if (from == limit) return 0; +#ifndef MULE + if (word_constituent_p (buf, from - 1, mirrortab)) + break; +#endif from--; +#ifdef MULE ch1 = BUF_FETCH_CHAR (buf, from - 1); code = SYNTAX_UNSAFE (mirrortab, ch1); if (words_include_escapes ＠＠ -400,20 +431,27 ＠＠ break; if (code == Sword) break; +#endif } QUIT; - while ( from != limit ) + while ((from != limit) +#ifndef MULE + && word_constituent_p (buf, from - 1, mirrortab) +#endif + ) { +#ifdef MULE ch0 = BUF_FETCH_CHAR (buf, from - 1); code = SYNTAX_UNSAFE (mirrortab, ch0); if (!(words_include_escapes && (code == Sescape || code == Scharquote))) if (code != Sword || WORD_BOUNDARY_P (ch0, ch1)) break; - from--; ch1 = ch0; +#endif + from--; } count++; } -- 弱り目に祟り目

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 June 1999