May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: b38: Tiff support misdetected 26 years, 6 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Martin, I'm not going to apply the patch you posted for this, I think > I've found a better way to do it. The TIFFLIB_VERSION symbol is what > we should be looking at. Excellent -- that's better than checking for random functions. (note that Martin posted the patch, not me.) > > I'll upgrade, that's out of the question -- but XEmacs shouldn't > > misdetect the old library version; it should simply assume there is no > > TIFF support. Looking that way, it's a good coincidence that I have > > the old version, so we were able to fix that bug. > > O.K. Look in tiff.h and tiffio.h. What is TIFF_VERSION (tiff.h) and > TIFFLIB_VERSION (tiffio.h)? > > I see: > > tiff.h: > #define TIFF_VERSION 42 > > tiffio.h: > /* > * This define can be used in code that requires > * compilation-related definitions specific to a > * version or versions of the library. Runtime > * version checking should be done based on the > * string returned by TIFFGetVersion. > */ > #define TIFFLIB_VERSION 19960307 /* March 7, 1996 */ I see: tiff.h: /* * Tag Image File Format (TIFF) * * Based on Rev 6.0 from: * Developer's Desk * Aldus Corporation * 411 First Ave. South * Suite 200 * Seattle, WA 98104 * 206-622-5500 */ #define TIFF_VERSION 42 tiffio.h: /* * This define can be used in code that requires * compilation-related definitions specific to a * version or versions of the library. Runtime * version checking should be done based on the * string returned by TIFFGetVersion. */ #define TIFFLIB_VERSION 19970127 /* January 27, 1997 */ which is quite strange, because it is supposed to mean that I have a *later* tifflib than you do. Weird! -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Personifiers Unite! You have nothing to lose but Mr. Dignity!

1 participants
0 comments

[Success] 21.0 "Repartida" XEmacs Lucid (beta38) on hppa1.1-hp-hpux9.05 26 years, 6 months

Pekka Marjola

> XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /tools/contrib/beta/src/xemacs-21.0-b38/Installation: > (Output from most recent run of ./configure)

1 participants
0 comments

[Almost OK] "Repartida" 21.0-b38) on alpha-unknown-linux (Redhat5) 26 years, 6 months

Aki Vehtari

>From tarballs. Runs OK but... Problem description: I have following in .Xdefaults Emacs.default*attributeBackgroundPixmap: /u/ave/.xemacs/etc/marblebg.xpm src/xemacs --vanilla Open buffer which has more text than one page eg. C-h n It looks okay, but press eg. PageDown and there's gray (default background color) areas where tehre should not be. C-l clears they appear again when text scrolls. This works OK on i686-pc-linux Redhat5/4. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /usr/local/xemacs/xemacs-21.0-b38/Installation: > (Output from most recent run of ./configure)

1 participants
0 comments

Re: b38: Tiff support misdetected 26 years, 6 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > > It appears that I have an older TIFF library, so linking fails: > > > symbol in file > > _TIFFmalloc glyphs-eimage.o > > TIFFClientOpen glyphs-eimage.o > > _TIFFfree glyphs-eimage.o > > ld: fatal: Symbol referencing errors. No output written to temacs > > Just how old is your libtiff? `ls' says "Sep 23 1997", but that has little relevance to the actual libtiff version. > Perhaps it's time you considered upgrading? I'll upgrade, that's out of the question -- but XEmacs shouldn't misdetect the old library version; it should simply assume there is no TIFF support. Looking that way, it's a good coincidence that I have the old version, so we were able to fix that bug. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth

1 participants
0 comments

Re: b38: Tiff support misdetected 26 years, 6 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Note that this is not specific to b38 -- I've been seeing it for a > while, but didn't report it because I worked on other stuff. > It appears that I have an older TIFF library, so linking fails: > symbol in file > _TIFFmalloc glyphs-eimage.o > TIFFClientOpen glyphs-eimage.o > _TIFFfree glyphs-eimage.o > ld: fatal: Symbol referencing errors. No output written to temacs Just how old is your libtiff? The oldest libtiff.so I have laying around has a timestamp of January 4th, 1996[1] and it has all of those symbols. Perhaps it's time you considered upgrading? Footnotes: [1] The great a.out -> ELF upgrade, so the library is at least from the autumn of '95.

1 participants
0 comments

Re: Package error 26 years, 6 months

SL Baur

Jeff Miller <jmiller(a)smart.net> writes: > the mail-libs package is defined as a single package in > package-get-base.el. > It should be a regular package. Right. I've corrected it for the next update.

1 participants
0 comments

Re: Utter coolness! 26 years, 6 months

Karl M. Hegbloom

> Some time ago, William M. Perry wrote... |+ | Hrvoje Niksic <hniksic(a)srce.hr> writes: | | > Evaluate this: | > | > (deallocate-event last-command-event) | > | > Now press a key. :-) | | Ummm.... nothing happened, other than self-insert-char worked as it | should. Do you mean it is cool that it works at all after you do this, or | that it explodes very prettily for you? :) kkm> For me, it eats the key, and displays "Someone deallocated kkm> last-command-event!" I *do* find it cool. kkm> $ rm foo kkm> $ ls foo kkm> ls: someone deleted foo!!! Great! Does it know where I put that program I thought I already wrote last month?

1 participants
0 comments

extra crap in mule-base 26 years, 6 months

Jeff Miller

in mule-base-1.14 -rw-r--r-- 1 jmiller jmiller 0 Jan 25 23:28 thai-util.el -rw-rw-r-- 1 jmiller jmiller 587 Apr 4 22:04 thai-util.elc -rw-r--r-- 1 jmiller jmiller 0 Jan 25 23:28 thai.el -rw-rw-r-- 1 jmiller jmiller 577 Apr 4 22:04 thai.elc -rw-r--r-- 1 jmiller jmiller 11406 Jan 25 23:28 vietnamese.el (no .elc file) -rw-r--r-- 1 jmiller jmiller 0 Jan 25 23:28 hebrew-hooks.el -rw-rw-r-- 1 jmiller jmiller 593 Apr 4 22:04 hebrew-hooks.elc

1 participants
0 comments

Package error 26 years, 6 months

Jeff Miller

the mail-libs package is defined as a single package in package-get-base.el. It should be a regular package. jeff

1 participants
0 comments

Mule & Thai 26 years, 6 months

Jeff Miller

Folks, Someone where i work is interested in using XEmacs w/Mule to read Thai encoded files. I see that thai support was removed from XEmacs around January or so, apparently it was broken. I'd like to help him use XEmacs to read his Thai files, but I know little about coding systems, thai, etc, but I'm willing to try to hack a bit on it. I see Emacs 20.2 apparently has thai support, how close are their language/thai*.el files to our old ones? How hard is it to port them to what our mule expects? I can't find the old ones that were removed, to do any comparision. If anyone has them, could they send them, please? Jeff

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 May 1998