February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Gunnar Evermann

Kyle, is this the bug you have fixed a couple of days ago?

1 participants
0 comments

Re: Undo glyphs.c change 24 years, 9 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > >The big question is.. how? > > What about generating a hash code for the structure so that by default this > is the only thing you check? But the common case is (hopefully) for the rune to be equal. Unless you can guarantee the hash is perfect you need to compare the complete structure anyway. What would be nice is to just create only one rune of each type and then just store the address. That would cut down on memory consumption a lot too. I recall that rune-cache thing that never happened was something like that. Jan P.S. I'm still convinced I must have made some stupid mistake when implementing the memcmp thing. I'll dig up the path

2 participants
1 comments

Re: Update to psgml 24 years, 9 months

Hrvoje Niksic

james(a)eecs.ukans.edu (Jerry James) writes: > I wrote to Andreas awhile back about looking at updating the psgml > package (for my own selfish purposes, of course). It took me > awhile, but I've taken a stab at it at last. It's very cool that you did this. Thanks. > 1) In psgml-edit.el: > > - The current XEmacs psgml package uses tempo to do string > insertion. However, psgml-1.2.1 does not do so. I didn't know > if the use of tempo was an XEmacs team change, or if the psgml > maintainer simply stopped using it. I went on the latter > assumption for now, since there is no mention of the matter in > the ChangeLog. I think the former is correct. The ChangeLog wouldn't mention it, as psgml was added at the time when ChangeLogs were not being maintained. > For the future, what should be done with htmlpro.dtd and > README.htmlpro? The URL given in README.htmlpro is dead. htmlpro was a nice idea, but it never got finished. I was never able to establish contact with the author, or find out what happened with the effort. We should probably declare htmlpro obsolete, and remove it in a later release. I doubt that anyone would miss it. > Finally, now that I have added a bunch of new DTDs, I'm starting to > think that XEmacs should only ship with a handful of the most widely > used ones. What's the point in having all those old versions of > HTML around, for example? A few people might need them, but most > won't. I suggest we keep HTML 3, 3.2, 4, and 4.01, XHTML 1.0, > Docbook 3.1 (and maybe 3.0 as well), and ditch the rest, possibly > with instructions on how to add them back in. You are as qualified to make that decision as anyone else. Maybe you could do a poll on c.e.x.

2 participants
1 comments

Re: [c.e.x] void-function exec-installed-p in image-mode? 24 years, 9 months

Hrvoje Niksic

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > > >>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > > Gunnar> exec-installed-p is in apel/path-utils.el > > Gunnar> shouldn't there be something like (require 'path-utils) > > Gunnar> in image-mode.el? > > > > Probably unnecessary. It's autoloaded if APEL is installed. > > of course. but then we need to make sure it is actually installed. I > guess the error "void-function exec-installed-p" is not very helpful > to the user. Exactly. I've been seeing that error for ages, and it's terribly annoying. BTW, I'm staying clear of APEL.

2 participants
1 comments

Update to psgml 24 years, 9 months

Jerry James

I wrote to Andreas awhile back about looking at updating the psgml package (for my own selfish purposes, of course). It took me awhile, but I've taken a stab at it at last. I would have posted a diff to xemacs-patches, but it's ... well, slightly enormous. So I stashed it in the only place I have available right now, which is <URL:http://www.ittc.ukans.edu/kan/psgml-11022000.tar.gz>. There are no links to that file (since it doesn't really belong there!); you have to go directly to that URL. It is 634K. I do not plan to leave it there for more than a month. If a few hardy souls wouldn't mind taking a look at it and letting me know what I messed up, I'd appreciate it. This is my first foray into making a package. It didn't seem terribly complicated, but that might be because I overlooked something. The rest of this message consist of notes on what I did to make the new package. I updated the lisp files to match psgml-1.2.1. I did my best to do the merge without tossing out patches submitted to the XEmacs team. I even included a patch to psgml-edit.el that was submitted a couple of months ago. I should pick out the differences and forward them to the psgml maintainer, but that will have to wait for another day. In trying to preserve old patches, I may have made some mistakes. In particular, I was unsure of the following: 1) In psgml-edit.el: - The current XEmacs psgml package uses tempo to do string insertion. However, psgml-1.2.1 does not do so. I didn't know if the use of tempo was an XEmacs team change, or if the psgml maintainer simply stopped using it. I went on the latter assumption for now, since there is no mention of the matter in the ChangeLog. - One change marked "Wing change" was removed by me. As far as I can tell, it is wrong, perhaps given subsequent development to psgml. It dealt with the insertion of end tags. 2) psgml-lucid.el was psgml-xemacs.el in the last XEmacs release of this package. Who changed the name? The ChangeLog is silent on that score, but I went ahead and changed the name from psgml-lucid.el to psgml-xemacs.el anyway. Also, I removed psgml-other.el from the distribution, as it contains FSF Emacs-specific code. The XEmacs-specific code is in psgml-xemacs.el. That wasn't bad, actually. All the work (and most of the diffs) came in etc/psgml. Many of the DTDs had updates (usually minor), so I imported a new set from w3.org. In addition, I did the following: FILES RENAMED ------------- 1) html-3.2f.dtd -> html-3.2.dtd This is the final version of the HTML 3.2 specification, and is appropriately named html-3.2.dtd. With the draft html-3.2.dtd gone (see html-3.2.dtd in the "FILES REMOVED" section), that name change has been made. 2) ie3tables.dtd -> ie30tables.dtd This change brings the name into conformance with w3.org usage. FILES REMOVED ------------- 1) Wing.ISOlat1.sgml This is not used by any of the DTDs, and it is superfluous anyway. This problem is taken care of in individual DTDs and html-latin.sgml. 2) html-2.dtd This DTD does not appear on w3.org. I presume this means it was a draft DTD. There is no point in keeping such an old draft around. Furthermore, html-2.dtd does not appear in the previous CATALOG, so nobody was able to use it anyway! Hence the number of people impacted by the removal of this file is zero. See the notes on html-2.1e.dtd in the "FILES ADDED" section. 3) html-3.2.dtd This DTD was a draft version of the HTML 3.2 specification. There is no point in keeping it now that the final version is available. See html-3.2f.dtd in the "FILES RENAMED" section. 4) webtechs.catalog Our new catalog has all of the stuff from w3.org that is needed to describe the DTDs present, and includes all relevent entries from this, so this is superfluous. 5) sinfo.dtd This DTD does not describe itself, give sample public identifiers, or otherwise give the user any clue as to what it might be. Plus, it isn't in the previous catalog either. Hence, anybody informed enough to be using it has a custom catalog and so can presumably handle adding the DTD to her personal collection. Actually, it looks like a DTD for dealing with RFCs, right? If somebody can help me get it into the CATALOG, that might be useful. It would also be useful to know if this DTD has been updated recently. FILES ADDED ----------- 1) ISOlat1.ent The ISO Latin-1 entity specification for HTML 1) html-2.1e.dtd The HTML 2.1e specification. Unfortunately, psgml steadfastly refuses to compile this DTD. I haven't discovered why yet. 2) html-3-as.dtd The HTML 3 specification, as extended by asWedit 2.0 in HTML 3 mode. 3) html-sq.dtd The HTML 3 specification, as extended by HoTMetal PRO 2.0 4) HTML4.decl Declarations for the April 24, 1998 W3 Recommendation for the HTML 4 specification. The other HTML 4 files were here already, but this one was missing. 5) HTML4.01.decl, html-4.01frame.dtd, html-4.01l.dtd, html-4.01s.dtd The August 24, 1999 W3 Proposed Recommendation for the HTML 4.01 specification. 6) xhtml* The January 26, 2000 W3 Recommendation for the XHTML (XML-based) 1.0 specification. 7) d* and cals-tbl.dtd Docbook 3.1 and CALS Table Model, the only non-(X)HTML DTDs now that sinfo.dtd (whatever that was) is gone. IANAL, but it seems safe to include this, given that it ships with most Linux distributions (and the license appears to be quite unrestrictive). In addition, I added nearly all of the DTDs to ECAT and compiled them. The exceptions were html-2.1e.dtd, which causes an error in psgml's DTD compiler, and some of the supporting (i.e., included) DTDs, which are not meant to be used as standalones. They get compiled into whatever uses them, so there is no point in compiling them separately. For the future, what should be done with htmlpro.dtd and README.htmlpro? The URL given in README.htmlpro is dead. Further investigation shows that Silmaril has moved to a new web server. The pages on the new server are full of dead links, and none of them lead to or so much as mention htmlpro. Also, the ISO_8879-1986/entities directory needs to be cleaned up. What is the point in having 2 copies of each file, with differing names? We should be able to stick to 1 naming scheme and get rid of the other one. Does anybody know if XML DTDs need to be put into the catalog? To use them, you have to give both a system and a public identifier, right? So a catalog seems redundant, but I know basically nothing about XML, so I don't know what The Right Thing To Do is here. Finally, now that I have added a bunch of new DTDs, I'm starting to think that XEmacs should only ship with a handful of the most widely used ones. What's the point in having all those old versions of HTML around, for example? A few people might need them, but most won't. I suggest we keep HTML 3, 3.2, 4, and 4.01, XHTML 1.0, Docbook 3.1 (and maybe 3.0 as well), and ditch the rest, possibly with instructions on how to add them back in. Feedback is welcome. But then again, so are chocolate-covered peanuts. -- Jerry James Email: james(a)eecs.ukans.edu (formerly jerry(a)cs.ucsb.edu)

1 participants
0 comments

Re: Problem compiling 21.2.28 on cygwin because of missing winspool.h 24 years, 9 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> Sigh. This is because the cygnus folks changed all the headers between Andy> b20.1 and cygwin 1.0 (i.e. it works for me :). If you can cons up a patch Andy> that would be great. I ran into this same problem, of course, and I'm still running 19.1. (Too lazy to upgrade because it works for what I want.) I'd make the patch if someone could tell me what to do. Where is winspool.h? Can I just remove that? What about the PHYSICALHEIGHT warnings? Can I include Windows/Defines.h in s/cygwin32.h? Or just leave it out completely? Ray

2 participants
1 comments

21.2-b28 crash 24 years, 9 months

Valdis Kl=?iso8859-4?Q?=BA?=tnieks

I hit the key sequence for Enlightenment to raise an xemacs window, and poof. Sorry for the shabby backtrace, was compiled with -O3. If I can replicate it with -g I'll follow up. Built from CVS as of yesterday-ish. /Valdis xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 8 (X_MapWindow) Resource id in failed request: 0x380101a Serial number of failed request: 744359 Current serial number in output stream: 744366 xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 12 (X_ConfigureWindow) Resource id in failed request: 0x3801024 Serial number of failed request: 744364 Current serial number in output stream: 744366 xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 2 (X_ChangeWindowAttributes) Resource id in failed request: 0x3801024 Serial number of failed request: 744365 Current serial number in output stream: 744366 ..Lisp backtrace follows: dispatch-event(#<magic-event Expose>) # (unwind-protect ...) # bind (mouse-down xthresh ythresh orig-x orig-y buffer mouse-grabbed-buffer mouse-moved event) mouse-track(#<magic-event Expose>) # bind (command-debug-status) call-interactively(mouse-track) # (condition-case ... . error) # (catch top-level ...) emacs.fatal_error_signal() at 0x1000351c Intrinsic._XtWindowedAncestor(??) at 0xd0d779f8 Geometry.XtConfigureWidget(??, ??, ??, ??, ??, ??) at 0xd0d82530 glyphs-x.x_map_subwindow() at 0x10171904 glyphs.map_subwindow() at 0x10128868 redisplay-output.redisplay_output_subwindow() at 0x100c69c4 redisplay-x.x_output_display_block() at 0x101e9c34 redisplay-output.redisplay_output_display_block() at 0x100c20f0 redisplay-output.output_display_line() at 0x100c35ec gutter.output_gutter() at 0x101efbcc gutter.redraw_exposed_gutter() at 0x101ef21c gutter.redraw_exposed_gutters() at 0x101f1c90 redisplay-x.x_redraw_exposed_area() at 0x101eded0 event-Xt.emacs_Xt_handle_magic_event() at 0x101ca19c event-stream.event_stream_handle_magic_event() at 0x100f95bc event-stream.execute_internal_event() at 0x100f58f0 event-stream.Fdispatch_event() at 0x100faad4 eval.Ffuncall() at 0x1001eee8 bytecode.execute_optimized_program() at 0x101bcd3c bytecode.funcall_compiled_function() at 0x101bed14 eval.Ffuncall() at 0x1001ee5c callint.Fcall_interactively() at 0x100d971c eval.Fcommand_execute() at 0x10020170 event-stream.execute_command_event() at 0x100f2b30 event-stream.Fdispatch_event() at 0x100faefc cmdloop.Fcommand_loop_1() at 0x10215eb4 eval.condition_case_1() at 0x10021fd4 cmdloop.command_loop_3() at 0x10215828 cmdloop.command_loop_2() at 0x102157a4 eval.internal_catch() at 0x100220e4 cmdloop.initial_command_loop() at 0x102160dc emacs.xemacs_21_2_b28_powerpc_ibm_aix4_3_3_0() at 0x100020fc emacs.main() at 0x10000b54

2 participants
1 comments

Re: Undo glyphs.c change 24 years, 9 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > >In real life this code is not reached unless glyphs changed, see > >redisplay-output.c:(compare_runes) > > > > else if (crb->type == RUNE_DGLYPH && > > XFRAME (w->frame)->glyphs_changed) > > > >Note that this code is called on every redisplay, much much > >more often than glyphs really change, and the glyph cache is > >reset every so often. > > Yes, Jan has already pointed out that this code needs optimising. The big question is.. how? In December I tried doing the memcmp-ing thing.. I was so convinced it was the right idea that I even did it the clean way (i.e. make substructures that identify the part that can be memcmp'ed like Ben proposed) and spend a whole night doing the grepping and the replacing. Then the final compile. Indeed compare_runes was now (almost) a simple inlined memcmp... the result.. 15% SLOWER redisplay :-(. I still haven't figured out what went wrong. Jan P.S. If anybody want I can try and dig up the patch.

2 participants
1 comments

Re: runaway proc... 24 years, 9 months

John A. Turner

[Andy sent Jeff and I a patch privately to hopefully fix the crashes/ hangs we had reported] >>>>> "AP" == Andy Piper <andy(a)xemacs.org> writes: AP> Attached is the definitive. I'm interested if the asserts get AP> triggered. The patch is untested ... >>>>> I wrote: JAT> ok, I just hit it again (after applying the patch manually as I JAT> mentioned)... exactly same msg I reported before... I'm going to JAT> rebuild with debug and full error-checking to see if that gives JAT> more info... >>>>> "JM" == Jeff Miller <jmiller(a)cablespeed.com> writes: JM> same as john, i had to hand apply the patch.... JM> JM> up and running ok so far. thanks andy. I did rebuild with debug and full error-checking, so I was ready the next time it went crazy. However, yet again it left a useless core. I dunno... -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 381-8400

1 participants
0 comments

231.2-b28 abort under AIX 4.3.3 24 years, 9 months

Valdis Kl=?iso8859-4?Q?=BA?=tnieks

This ring any bells to anybody? CVS code from last few days, was just typing away and it blew up. Fortunately, I was already in dbx waiting for it to replicate a *different* crash. Not sure I can reproduce this one. I've got the output of (while functions_left "up;dump" ;) if anybody wants it. Not appended because of length. /Valdis Intrinsic._XtWindowedAncestor(??) at 0xd0d779f8 Geometry.XtConfigureWidget(??, ??, ??, ??, ??, ??) at 0xd0d82530 glyphs-x.x_map_subwindow(0x205afa80, 0x4, 0x4, 0x2ff21978), line 2152 in "glyphs-x.c" unnamed block glyphs.map_subwindow.$b2051, line 4308 in "glyphs.c" glyphs.map_subwindow(0x205afa80, 0x4, 0x4, 0x2ff21978), line 4308 in "glyphs.c" redisplay-output.redisplay_output_subwindow(0x205ffa00, 0x205afa80, 0x2ff21a10, 0x2ff21a20, 0x11, 0x0, 0x0, 0x0), line 1200 in "redisplay-output.c" unnamed block redisplay-x.x_output_display_block.$b3662, line 482 in "redisplay-x.c" redisplay-x.x_output_display_block(0x205ffa00, 0x205e3c00, 0x0, 0x0, 0x1, 0x4, 0x0, 0x0), line 482 in "redisplay-x.c" redisplay-output.redisplay_output_display_block(0x205ffa00, 0x205e3c00, 0x0, 0x0, 0x1, 0x4, 0x0, 0x0), line 1088 in "redisplay-output.c" redisplay-output.compare_display_blocks(0x205ffa00, 0x205e3400, 0x205e3c00, 0x0, 0x0, 0x4, 0x0, 0x0), line 471 in "redisplay-output.c" unnamed block redisplay-output.output_display_line.$b3036.$b3040, line 721 in "redisplay-output.c" unnamed block redisplay-output.output_display_line.$b3036, line 721 in "redisplay-output.c" redisplay-output.output_display_line(0x205ffa00, 0x205da360, 0x205da6a0, 0x0, 0xffffffff, 0xffffffff), line 721 in "redisplay-output.c" gutter.output_gutter(0x205ffe00, 0x0), line 257 in "gutter.c" unnamed block gutter.update_frame_gutters.$b2348, line 361 in "gutter.c" gutter.update_frame_gutters(0x205ffe00), line 361 in "gutter.c" redisplay.redisplay_frame(0x205ffe00, 0x0), line 6362 in "redisplay.c" redisplay.redisplay_device(0x20372f00, 0x1), line 6475 in "redisplay.c" unnamed block redisplay.redisplay_without_hooks.$b2783, line 6564 in "redisplay.c" redisplay.redisplay_without_hooks(), line 6564 in "redisplay.c" redisplay.redisplay(), line 6621 in "redisplay.c" event-stream.Fnext_event(0x20564744, 0x20078804), line 2238 in "event-stream.c" cmdloop.Fcommand_loop_1(), line 566 in "cmdloop.c" cmdloop.command_loop_1(0x20078804), line 490 in "cmdloop.c" eval.condition_case_1(0x20078864, 0x20028c80, 0x20078804, 0x20028c8c, 0x20078804), line 1629 in "eval.c" cmdloop.command_loop_3(), line 252 in "cmdloop.c" cmdloop.command_loop_2(0x20078804), line 263 in "cmdloop.c" eval.internal_catch(0x2008afe4, 0x20028c74, 0x20078804, 0x0), line 1304 in "eval.c" cmdloop.initial_command_loop(0x20078804), line 301 in "cmdloop.c" emacs.xemacs_21_2_b28_powerpc_ibm_aix4_3_3_0(argc = 8261, argv = 0x000053e8, envp = (nil), restart = 2), line 1894 in "emacs.c" emacs.main(argc = 1, argv = 0x2ff225c0, envp = 0x2ff225c8), line 2320 in "emacs.c"

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 February 2000