June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: NT makefiles broken? [was Re: colourless xemacs on NT :-(] 25 years, 5 months

Norbert Koch

SL Baur <steve(a)xemacs.org> writes: > The build process is supposed to run `temacs -batch -l update-elc.el' > before dumping xemacs, update-elc.el takes care of bytecompiling > out-of-date elcs, and lib-src/update-elc.sh after dumping. > update-elc.sh takes care of bytecompiling the remainder of the core. > Is this not happening? Everything seems to work fine now. Hmm, IIRC, there had been changes to update-elc.el. Perhaps, this was a leftover? BTW, does the script work on NT? norbert.

1 participants
0 comments

Re: colourless xemacs on NT :-( 25 years, 5 months

Norbert Koch

SL Baur <steve(a)xemacs.org> writes: > ??? I didn't know any of Mule worked on a non-Unix system. How much > does work? Uh, I don't use much of Mule, so I'm not the person to speak for it. Perhaps, I should build without Mule, after all? At least, the application doesn't crash more than an unMULEified build. Problem is that the number of fonts is pretty small, but we have international versions of the systems, too. Perhaps, I could install a Japanese set of fonts? Hmm, can I use the mule packages without having mule enabled during the build (my colleagues don't approve of English messages and I can't stand a German keyboard :-))? I remember that the feature is or at least has been cecked for. Thanks, norbert.

1 participants
0 comments

Re: [bug] C-x (space) debug loop with error 25 years, 5 months

SL Baur

Karl M Hegbloom <psu25682(a)odin.cc.pdx.edu> writes in xemacs-beta(a)xemacs.org: > With `debug-on-error' turned on, if I push `C-x (space)', I get a > recurring: Wrong type argument: number-char-or-marker-p, nil I get: Signaling: (undefined-keystroke-sequence [#<keypress-event control-X> #<keypress-event space>]) > It doesn't happen in `xemacs -vanilla'. Has anyone seen this before? > It's on my todo list... I'll try and find it if I can. The output from `C-h k C-x SPC' will probably tell you where to start looking. -- 窓番号を入力して下さい

1 participants
0 comments

Re: XEmacs is not 64-bit clean (was Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown) 25 years, 5 months

SL Baur

Justin Vallon <vallon(a)mindspring.com> writes in xemacs-beta(a)xemacs.org: > On 17 Jun 1999, Raymond Toy wrote: ... >> My solaris 2.5.1 machine says >> >> Death at Mon Jan 18 22:14:07 2038 >> Afterlife at Mon Jan 18 23:14:08 2038 > That's curious. Afterlife is Death + 01:00:01. Typo? No. I see it too on a Solaris 2.6 machine. It must be a Sun bug. It looks like Suns could be choking somewhat before black Tuesday/Monday. $ uname -a SunOS mule.m17n.org 5.6 Generic_105181-11 sun4u sparc SUNW,Ultra-60 $ TZ=US/Eastern /tmp/bug Death at Mon Jan 18 22:14:07 2038 Afterlife at Mon Jan 18 23:14:08 2038 Curiouser and curiouser though, is this: $ TZ=Japan /tmp/bug Death at Sat Dec 14 05:45:51 1901 Afterlife at Sat Dec 14 05:45:52 1901 > My RedHat R4 says: > $ ./bug > Death at Mon Jan 18 22:14:07 2038 > Afterlife at Fri Dec 13 15:45:52 1901 Yup. DEC OSF behaves exactly the same way. -- 雨が降っています。

2 participants
1 comments

Re: XEmacs is not 64-bit clean (was Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown) 25 years, 5 months

Raymond Toy

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> [1] Speaking of which, is it a standard POSIX feature that negative sb> times get treated as being before the epoch? sb> $ cat /usr/tmp/bug.c sb> main() sb> { sb> long int time = 0x7fffffff; sb> long int time2 = 0x80000000; sb> printf("Death at %s", ctime(&time)); sb> printf("Afterlife at %s", ctime(&time2)); sb> } sb> $ /usr/tmp/bug sb> Death at Tue Jan 19 12:14:07 2038 sb> Afterlife at Sat Dec 14 05:45:52 1901 My solaris 2.5.1 machine says Death at Mon Jan 18 22:14:07 2038 Afterlife at Mon Jan 18 23:14:08 2038 Ray

3 participants
2 comments

Re: 21.1.3: you-are-trapped-in-a-twisty-maze-of-cons-cells-all-alike 25 years, 5 months

SL Baur

Karl M Hegbloom <karlheg(a)cathcart.sysc.pdx.edu> writes in xemacs-beta(a)xemacs.org: > I've seen that debugger loop. It happens when I set debug on error to > true, then hit an error. If I run with -vanilla, it doesn't happen. > I have not tried to see what's causing it. I have seen this too. Unfortunately, I am equally in the dark as to the cause. -- 雨が降っています。

1 participants
0 comments

Re: [Failure] XEmacs 21.1.2 "2", 20 Minutes to Nikko 25 years, 5 months

SL Baur

Vin Shelton <acs(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > aichner(a)ecf.teradyne.com said: >> Hmmh, not any longer. How am I supposed to update to the latest >> sources? ... >> Is there a tag I could use to cvs update to 21.1.3? > No, not yet. I think 21.1.x is still on the mainline. Here's how I > built a copy of the 21.1.x archive: You don't ever need a tag to update to the latest sources. You only need to specify a branch. Since 21.1.x is the default branch, the latest is what you will get. -- 雨が降っています。

1 participants
0 comments

Re: NT makefiles broken? [was Re: colourless xemacs on NT :-(] 25 years, 5 months

SL Baur

Norbert Koch <n.koch(a)delta-ii.de> writes in xemacs-beta(a)xemacs.org: > Therefore, in my case it would be > the best way simply to byte-compile all el-files and don't fiddle > around with any dependencies. Hm, this takes a long time, though. Perhaps you should download the -elc tarball and install that too. -- 雨が降っています。

1 participants
0 comments

Re: NT makefiles broken? [was Re: colourless xemacs on NT :-(] 25 years, 5 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > Norbert Koch <n.koch(a)delta-ii.de> writes: >> When I started xemacs -vanilla and loaded the custom library it told >> me cus-edit.el was newer - and bingo, the cusXXX.el files all have >> been newer than the respective byte-compiled files. After >> byte-compiling them and a restart, everything looks Ok now, phew! >> >> Now, I don't know why the files haven't been updated. Perhaps, there's >> a problem during the make process? > Dimitri had exactly the same problems! Is there some bug in the NT > make files so that dependencies do get tracked properly? The build process is supposed to run `temacs -batch -l update-elc.el' before dumping xemacs, update-elc.el takes care of bytecompiling out-of-date elcs, and lib-src/update-elc.sh after dumping. update-elc.sh takes care of bytecompiling the remainder of the core. Is this not happening? -- 雨が降っています。

1 participants
0 comments

Re: colourless xemacs on NT :-( 25 years, 5 months

SL Baur

Norbert Koch <n.koch(a)delta-ii.de> writes in xemacs-beta(a)xemacs.org: > Ok, one other difference is my usage of Mule, but I don't think this > causes these troubles ... > XEmacs 21.2 (beta16) "Sumida" [Lucid] (i586-pc-win32, Mule) > of Mon Jun 14 1999 on KEATS ??? I didn't know any of Mule worked on a non-Unix system. How much does work? -- 雨が降っています。

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