March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Steve's 21.2.32 crashes 24 years, 2 months

Didier Verna

Andy Piper <andy(a)xemacs.org> wrote: > I can't commit right now and xrdb doesn't work on my broken windows system. > Can you try the attached patch which I think clears up the brokeness I > introduced earlier (but may not fix your problem). That fixes the crash (I was also experimenting) for me. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

Re: Accelerator I18N [was: I don't wont the f* underlinings ...] 24 years, 2 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > What Ben did moved _all_ of the menu commands I ever use under English > titles, none of whose common Japanese synonyms (at least in my wife's > usage) correspond to the terms used for those menus in Japanese, and > some of which are abbreviations that a typical Japanese could not > parse. Others are outright misleading: "Internet" in Japanese means > IE and Netscape, but no Japanese use them for mail, so they wouldn't > think to look there for mail, and probably not for Gnus. How about not "translating" the menus at all. Wouldn't it be almost as much work to simply provide a complete new menubar for each language (or at least for each major culture group) so you can address these issues and translation at the same time. Just brainstorming, Jan

2 participants
1 comments

Re: cannot build xemacs-21.1.9 on mips-sgi-irix6.5 24 years, 2 months

Jan Vroonhof

David Starks-Browning <starksb(a)ebi.ac.uk> writes: > I've since ruled out the old ranlib as a factor. Even after removing > the suspect ranlib, the gcc-2.95.2 build fails on mips-sgi-irix6.5. Did you try without "-g". There are reports that that helps. Jan

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 2 months

Jan Vroonhof

Jens Lautenbacher <jtl(a)schlund.de> writes: > the word "simply" wasn't meant to be taken serious of course. What I > wanted to say is if in the very long run it wouldn't make sense to I think you meant "wouldn't it make sense"? > move to a display engine that has no problems with proportional, > different sized fonts, can display graphics with clipping them when > they're partly offscreen and so on. The XEmacs redisplay engine can already do all these things (Andy added clipping in 21.2). One thing what would be nice to have would be absolute positioning. The question is more that some point you are reinventing libart (or similar) anyway, so you might as well use it. Note that a large part of the redisplay engine is not about rendering, but about keeping the View in sync with the Model efficiently. As far as I can see there are not pre-baked solutions for that. > There are people toying with the idea of enabeling xemacs to act as > a wordprocessor, a task that for sure isn't possible with the > current (state of the) display engine. I really have my doubts about this as it is stretching the concept of buffers quite far too. Jan

1 participants
0 comments

another 21.2.32 meltdown, again in VM 24 years, 2 months

John A. Turner

this one was much more spectacular - for an instant I got the "blue gutters" as mentioned in: http://www.xemacs.org/list-archives/xemacs-beta/200003/msg00128.html then all XEmacs frames disappeared, and in the terminal window in which I was running gdb it just said: Error: Object "InitialResourcesPersistent" does not have windowed ancestor Program exited with code 01. (gdb) where No stack. environment as in: http://www.xemacs.org/list-archives/xemacs-beta/200003/msg00021.html -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 825-8319

1 participants
0 comments

Re: the Athena trick vs. the Sound trick 24 years, 2 months

William M. Perry

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Didier Verna <didier(a)xemacs.org> writes: > > > | /* For use in #include statements. > > | You can't use macros directly within the <> of a #include statement. > > | The multiply nested macros are necessary to make old gcc's happy. > > | However, those nested macros are too much for AIX xlc to deal with. */ > > | #if defined(_AIX) && !defined(__GNUC__) > > | #define ATHENA_INCLUDE(header_file) <ATHENA_H_PATH/header_file> > > | #else > ... > > * Each time a new inclusion macro needs to be written, you have to > > redo the AIX test. I concede that this is not very satisfactory. > > That kills it IMO. AIX /per se/ is of course not the issue. The > issue is that only God knows how many more compilers have exactly the > same problem. These #ifdef's scattered through code might only > increase. > > Idea: maybe we should design a configure test to test which kind of > configure glue the user's preprocessor likes. Then our config.h.in > could say something like: > > #define ATHENA_INCLUDE ＠INCLUDE_GLUE＠(...) Or why not just put it in one place as SMART_INCLUDE, and then #if defined(_AIX) && !defined(__GNUC__) #define SMART_INCLUDE(path,header_file) <path/header_file> #else #define INCLUDE_GLUE_2(dirname,basename) <##dirname##/##basename##> #define INCLUDE_GLUE_1(dirname,basename) INCLUDE_GLUE_2(dirname,basename) #define SMART_INCLUDE(path,header_file) INCLUDE_GLUE_1(path,header_file) #endif #define ATHENA_INCLUDE(x) SMART_INCLUDE(ATHENA_H_PATH,x) #define SOUND_INCLUDE(x) SMART_INCLUDE(SOUND_H_PATH,x) #define FOO_INCLUDE SMART_INCLUDE(FOO_H_PATH,x) etc, etc? That way whenever you find that some compiler has problems you just smarten up SMART_INCLUDE in one place, voila. -bp

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 2 months

Per Abrahamsen

SL Baur <steve(a)etl.go.jp> writes: > William M Perry <wmperry(a)aventail.com> writes in xemacs-beta(a)xemacs.org: > ... > > But, using Qt would bring in horrendous licensing issues. > > Please. Not this again. I thought the Qt licensing issue was dead > with Qt-2.0. Qt 2.0 (QPL) did change the political situation, as it is now under a certified Open Source license. However, the legal situation is exectly the same as before. The legal problem has never been with the Qt license, but with the GPL. It still depends on whether the law would consider Qt to fall under this clause: GPL> However, as a special exception, the source code distributed need GPL> not include anything that is normally distributed (in either GPL> source or binary form) with the major components (compiler, GPL> kernel, and so on) of the operating system on which the GPL> executable runs, unless that component itself accompanies the GPL> executable. An alternative to betting on what the law would say, is to get a "special exception" from the copyright holder.

2 participants
1 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 2 months

William M. Perry

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > SL Baur <steve(a)etl.go.jp> writes: > > > William M Perry <wmperry(a)aventail.com> writes in xemacs-beta(a)xemacs.org: > > ... > > > But, using Qt would bring in horrendous licensing issues. > > > > Please. Not this again. I thought the Qt licensing issue was dead > > with Qt-2.0. > > Qt 2.0 (QPL) did change the political situation, as it is now under a > certified Open Source license. However, the legal situation is > exectly the same as before. The legal problem has never been with the > Qt license, but with the GPL. It still depends on whether the law > would consider Qt to fall under this clause: > > GPL> However, as a special exception, the source code distributed need > GPL> not include anything that is normally distributed (in either > GPL> source or binary form) with the major components (compiler, > GPL> kernel, and so on) of the operating system on which the > GPL> executable runs, unless that component itself accompanies the > GPL> executable. > > An alternative to betting on what the law would say, is to get a "special > exception" from the copyright holder. Hmmm... what does that 'unless that component itself accompanies the executable'? mean exactly? Would you just need to ship a copy of Qt with the executable? Grumble grumble. -Bill P.

1 participants
0 comments

Re: cannot build xemacs-21.1.9 on mips-sgi-irix6.5 24 years, 2 months

Jan Vroonhof

Simon Josefsson <jas(a)pdc.kth.se> writes: > Perhaps I should start by seeing what problems there might be > compiling it with gcc then? :-) I'll do that now. This is Max Matveev describing the invariant his code is expecting. Does that hold when compiling with gcc? 1999-12-28 Max Matveev <max(a)melbourne.sgi.com> * unexelfsgi.c (unexec): Change the way we decide which segment should be extended. Assumption that .bss section should be outside the PT_LOADable segment. On IRIX with version 6.2 and above, .bss (or .sbss, if it's present) is inside the 'data' segment. This would fail the test which was used to find a segment to grow and cover new heap. Instead of this assumption, I created another one - on IRIX the segment to grow should start below .bss and it's address should extent above the end of .bss. Once this segment is identified, it's grown to accommodate the new heap and new zero-length .bss section is added at the end of .data2.

4 participants
4 comments

Re: configure error with XFree86-4.0 24 years, 2 months

Michael Harnois

On Tue, 21 Mar 2000 23:33:37 -0800, "Meinhard E. Mayer" <mmayer(a)uci.edu> said: > I tried to run configure with the new release of XFree86 version > 4.0 installed, and configure failed to find X11/Intrinsic.h. The problem (at least here) seems to be with configure's defining _XOPEN_SOURCE=500. When I brute-force changed that to 1 the problem went away. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org Never invoke the gods unless you really want them to appear. It annoys them very much. -- G.K. Chesterton

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