February 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: allocate_nearest_color returned 0!!! (was Re: Copyright question for XEmacs icons.) 25 years, 9 months

Didier Verna

P E Jareth Hein writes: P> Well, I'm not sure what causes them, and I put that there originally to P> help me find out more about them. They won't cause crashes, but they are P> most likely indicative of mishandled colors (or possibly mis-read X P> specs... <grin>). I've never seen one in the 5 or six different platforms I P> work on, and would like to know why they happen, so I can fix whatever P> wierdness is there. But, they probably should go away for a non-beta P> release... Jareth, here are some clarifications you might find usefull: If I understood well the scheme you use in allocate_nearest_color, when you notice that the colormap is full, you scan it to find the closest one already available in the colormap, and try to allocate this one, right ? Well, this can fail (and thus generate the messages that Steve got) for to reasons that I can think of (I assume that we're talking about user-modifiable colormaps, e.g. PseudoColor): 1/ First, between the time you find the closest color and the time you try to allocate it, the colormap may have changed. For example, the reference count on that particular color cell went back to 0, and somebody else than you allocated it back with something else. No more closest color in the colormap. 2/ Second, the colormap doesn't change, but the candidate you found is allocated read/write by another client. I think that's what happens to Steve, since Netscape seems to perform a massive XAllocColorCells at startup. Then XAllocColor fails because it's supposed to return a read-only cell, and the one you found could be changed any time by its owner. As the second case is much more likely to happen than the first one, a solution would be to sort the colormap by closeness order, and try all candidates until one succeeds. Being aware, however, that this solution could still fail in very rare and weird cases[1]. But anyway, I think you shouldn't use fprintf, but maybe a standard error signaling routine. <pendantic PS> Ah, anda... you function doesn't follow the GNU coding standards very much ;-) </pendantic PS> Footnotes: [1] in such cases, you could also restart the whole algorithm. I mean rescanning the whole colormap and so on. Theoretically, what we'got here is a beautiful potential infinite loop :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Still trying to get AIX 21.2.10 compiled on AIX 4.3!?! 25 years, 9 months

Michael Sperber

>>>>> "Derek" == Derek Scherger <derek(a)echologic.com> writes: Derek> Hi there... I've been fighting with this build for a couple of weeks Derek> now with no real success yet. You really need to send in more information for us to be able to help you. Your Installation file would go a long way. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: allocate_nearest_color returned 0!!! (was Re: Copyright question for XEmacs icons.) 25 years, 9 months

SL Baur

P E Jareth Hein <jareth(a)camelot.co.jp> writes in xemacs-beta(a)xemacs.org: >>>>>> "SL" == SL Baur <steve(a)xemacs.org> writes: SL> I got a whole spew of these on the dtterm I started XEmacs from SL> when I viewed Jan's message. Shouldn't these either be formal SL> warnings or removed? > Well, I'm not sure what causes them, and I put that there originally > to help me find out more about them. They won't cause crashes, but > they are most likely indicative of mishandled colors (or possibly > mis-read X specs... <grin>). I am currently suffering under 8 bit pseudo color. > I've never seen one in the 5 or six different platforms I work on, and > would like to know why they happen, so I can fix whatever wierdness is > there. But, they probably should go away for a non-beta release... O.K. With 8 bit color depth, try loading XEmacs and Netscape without private color maps, then viewing Jan's message. That should probably do it.

1 participants
0 comments

Re: allocate_nearest_color returned 0!!! (was Re: Copyright question for XEmacs icons.) 25 years, 9 months

Jareth Hein

>>>>> "SL" == SL Baur <steve(a)xemacs.org> writes: SL> I got a whole spew of these on the dtterm I started XEmacs from SL> when I viewed Jan's message. Shouldn't these either be formal SL> warnings or removed? Well, I'm not sure what causes them, and I put that there originally to help me find out more about them. They won't cause crashes, but they are most likely indicative of mishandled colors (or possibly mis-read X specs... <grin>). I've never seen one in the 5 or six different platforms I work on, and would like to know why they happen, so I can fix whatever wierdness is there. But, they probably should go away for a non-beta release... -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder

1 participants
0 comments

Weird Gnus Crash 25 years, 9 months

John Mignault

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 "Boreas" [Lucid] (i586-pc-linux) of Fri Feb 5 1999 on jbm configured using `configure --dynamic --with-database=gnudbm --with-xpm --gung-ho --with-mule=no --with-png=yes --with-session' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Was reading news in Gnus via gnuclient -nw over a tty. Hit space several times to move to the next message. Terminal froze up. Lost conenction. Was able to connect again a few minutes later, but could not run gnuclient again, the reason being that XEmacs was no longer running. Got a core dump; this is the result of "gdb `which xemacs` core' followed by the "where" command (incidentally, what is the I/O error related to?): [ jbm＠jbm ~ 130 ] $ gdb `which xemacs` core GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or 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. This GDB was configured as "i386-redhat-linux"... Core was generated by `xemacs'. Program terminated with signal 3, Quit. find_solib: Can't read pathname for load map: Input/output error #0 0x40271781 in ?? () from /lib/libc.so.6 (gdb) where #0 0x40271781 in ?? () from /lib/libc.so.6 #1 0xbffff2e0 in ?? () #2 0x8122f8d in filedesc_writer (stream=0x8b17c48, data=0x8a16240 "\e[30m \e[m\017\e[3;29H\e[30m\e[3;30H\e[K\e[m\017\e[4;1H\e[30m \e[m\017\e[1m\e[30mtimestamp:\e[m\017\e[30m 17 Apr 1998\e[m\017\e[30m \e[m\017\e[4;29H\e[30m\e[4;30H\e[K\e[m\017\e[5;1H\e[30m \e[m\017\e[5;1H\e[30m\e[5;2H\e[K\e[m\017\e[6;1H\e[30m \e[m\017\e[6;1H\e"..., size=512) at lstream.c:984 #3 0x81223d1 in Lstream_flush_out (lstr=0x8b17c48) at lstream.c:343 #4 0x812263e in Lstream_write_1 (lstr=0x8b17c48, data=0xbffff427, size=1) at lstream.c:452 #5 0x8122bc8 in Lstream_fputc (lstr=0x8b17c48, c=91) at lstream.c:732 #6 0x80b5d7f in send_string_to_tty_console (c=0x8ba7068, str=0xbffff45b "[\204=f4=ff=bf=f5{\"＠[", len=1) at cm.c:74 #7 0x80b5dfe in cmputc (c=91) at cm.c:87 #8 0x40227bf5 in ?? () from /usr/lib/libncurses.so.4 #9 0x80b30e6 in tty_turn_on_face_1 (c=0x8ba7068, highlight_p=0, blinking_p=0, dim_p=0, underline_p=1, reverse_p=0, cinst_fore=141481376, cinst_back=137520440) at redisplay-tty.c:746 #10 0x80b32f9 in tty_turn_on_face (w=0x8a692d8, findex=12) at redisplay-tty.c:790 #11 0x80b2bec in tty_output_bufbyte_string (w=0x8a692d8, dl=0x8bdea38, str=0x8be0e88 "Panix Public Access UNIX, NYC", '-' <repeats 11 times>, "ow better. You really do. ng? y..ad)7hfke$h2e$1(a)news.panix.com> <7963pl$gnl$1(a)news.panix", len=29, xpos=15, findex=12, cursor=0) at redisplay-tty.c:586 #12 0x80b2ce5 in tty_output_emchar_dynarr (w=0x8a692d8, dl=0x8bdea38, buf=0x88ef688, xpos=15, findex=12, cursor=0) at redisplay-tty.c:617 #13 0x80b1e32 in tty_output_display_block (w=0x8a692d8, dl=0x8bdea38, block=0, start=0, end=45, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-tty.c:255 #14 0x814aea8 in redisplay_output_display_block (w=0x8a692d8, dl=0x8bdea38, block=0, start=0, end=45, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:999 #15 0x8149409 in compare_display_blocks (w=0x8a692d8, cdl=0x8c199a0, ddl=0x8bdea38, c_block=0, d_block=0, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:418 #16 0x814a2c4 in output_display_line (w=0x8a692d8, cdla=0x8a694d8, ddla=0x8c25118, line=1, force_start=-1, force_end=-1) at redisplay-output.c:653 #17 0x814cc61 in redisplay_output_window (w=0x8a692d8) at redisplay-output.c:1547 #18 0x813f3bf in redisplay_window (window=145134296, skip_selected=1) at redisplay.c:5258 #19 0x813f6a3 in redisplay_windows (window=144362288, skip_selected=1) at redisplay.c:5308 #20 0x813eacb in redisplay_window (window=144889856, skip_selected=1) at redisplay.c:4944 #21 0x813f98c in redisplay_frame (f=0x8b9f9f8, preemption_check=0) at redisplay.c:5308 #22 0x813fb37 in redisplay_device (d=0x8babb38) at redisplay.c:5536 #23 0x813ff1f in redisplay_without_hooks () at redisplay.c:5653 #24 0x81401a8 in redisplay () at redisplay.c:5722 #25 0x80bddc7 in Fnext_event (event=145595408, prompt=137373148) at event-stream.c:2238 #26 0x806e19a in Fcommand_loop_1 () at cmdloop.c:569 #27 0x806df29 in command_loop_1 (dummy=137373148) at cmdloop.c:493 #28 0x808be9d in condition_case_1 (handlers=137373260, bfun=0x806ded8 <command_loop_1>, barg=137373148, hfun=0x806d35c <cmd_error>, harg=137373148) at eval.c:1640 #29 0x806e3c4 in command_loop_2 (dummy=137373148) at cmdloop.c:255 #30 0x808ba78 in internal_catch (tag=137447884, func=0x806e390 <command_loop_2>, arg=137373148, threw=0x0) at eval.c:1315 #31 0x806d7c3 in initial_command_loop (load_me=137373148) at cmdloop.c:304 #32 0x8087701 in xemacs_21_2_b10_i586_pc_linux (argc=1, argv=0xbffffc64, envp=0xbffffc6c, restart=0) at emacs.c:1736 #33 0x8087e75 in main (argc=1, argv=0xbffffc64, envp=0xbffffc6c) at emacs.c:2165 Recent keystrokes: TAB DEL DEL - 2 1 TAB e t TAB RET RET misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user button1 button1up RET button1 button1up button1 button1up RET C-x b * s h TAB RET q u i t RET g d b SPC ` w h i c h SPC x e m a c s ` SPC c o r e RET w h e r e RET misc-user Recent messages (most recent first): Loading footnote... Loading emacsbug...done Loading emacsbug... Checking new news...done Checking new news... Selecting menu item Q2.1.1...done Selecting menu item Q2.1.1... Selecting menu item Q2.0.6...done Selecting menu item Q2.0.6... Composing main Info directory...done j -- #!/usr/bin/perl $dot="\x2e";$lt="\x3c";$gt="\x3e";$at="\x40"; print "J Mignault ${lt}jbm${at}panix${dot}com${gt}\n"; $wright = qq(If olive oil comes from olives, where does baby oil come from?);

1 participants
0 comments

allocate_nearest_color returned 0!!! (was Re: Copyright question for XEmacs icons.) 25 years, 9 months

SL Baur

I got a whole spew of these on the dtterm I started XEmacs from when I viewed Jan's message. Shouldn't these either be formal warnings or removed?

1 participants
0 comments

Re: curiosity 25 years, 9 months

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > giacomo boffi <giacomo.boffi(a)polimi.it> writes in xemacs-beta(a)xemacs.org: >> how many people are currently subscribed to xemacs-beta? > 411. For completeness, xemacs-mule has 152 and xemacs-nt has 381.

1 participants
0 comments

Re: curiosity 25 years, 9 months

SL Baur

giacomo boffi <giacomo.boffi(a)polimi.it> writes in xemacs-beta(a)xemacs.org: > how many people are currently subscribed to xemacs-beta? 411.

1 participants
0 comments

Patch to vc.el 25 years, 9 months

Barry A. Warsaw

This fix still hasn't made it into vc.el, even with VC package 1.16. Please consider installing this patch, as it makes vc-version-diff when invoked with `C-u C-x v =' actually useful. Thanks, -Barry *** vc.el 1999/02/16 23:57:27 1.3 --- vc.el 1999/02/16 23:58:29 1.4 *************** *** 1354,1369 **** (setq rel2-default (vc-workfile-version file)))) ;; construct argument list (list file ! (let ((minibuffer-default rel1-default)) ! (read-string (if rel1-default ! (concat "Older version: (default " ! rel1-default ") ") ! "Older version: "))) ! (let ((minibuffer-default rel2-default)) ! (read-string (if rel2-default ! (concat "Newer version: (default " ! rel2-default ") ") ! "Newer version (default: current source): ")))))) (if (string-equal rel1 "") (setq rel1 nil)) (if (string-equal rel2 "") (setq rel2 nil)) (if (file-directory-p file) --- 1354,1378 ---- (setq rel2-default (vc-workfile-version file)))) ;; construct argument list (list file ! (let ((minibuffer-default rel1-default) ! (rel1-choice ! (read-string (if rel1-default ! (concat "Older version: (default " ! rel1-default ") ") ! "Older version: ")))) ! (if (string-equal rel1-choice "") ! rel1-default ! rel1-choice)) ! (let ((minibuffer-default rel2-default) ! (rel2-choice ! (read-string (if rel2-default ! (concat "Newer version: (default " ! rel2-default ") ") ! "Newer version (default: current source): ") ! ))) ! (if (string-equal rel2-choice "") ! rel2-default ! rel2-choice))))) (if (string-equal rel1 "") (setq rel1 nil)) (if (string-equal rel2 "") (setq rel2 nil)) (if (file-directory-p file)

1 participants
0 comments

Re: python-mode 3.90; IM-Python Broken 25 years, 9 months

Neal D. Becker

>>>>> "BAW" == Barry A Warsaw <bwarsaw(a)cnri.reston.va.us> writes: >>>>> "nbecker" == <nbecker(a)fred.net> writes: nbecker> Clicking on the menu item Im-python gives this error: nbecker> Menu name (first element) must be a string: (nil) BAW> IIRC, this was actually due to a problem in XEmacs' imenu.el, and at BAW> some point Hrvoje posted a fix. I'm using version 1.27 of the BAW> xemacs-base package (where imenu is found) and it seems to work well BAW> for me. I'm using 1.29 (the current) and it doesn't work for me.

2 participants
2 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 1999