May 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: still hosed with 21.2 cvs 23 years, 11 months

Jan Vroonhof

Michael Harnois <mdharnois(a)home.com> writes: > The latest CVS still fails as per below, in case anyone is interested > .. I have rolled my tree back to r21-2-32 and that builds and works > without incident. Hmmm... Are you compiling with or without pdump? > #2 0x80aaaf1 in dead_wrong_type_argument (predicate={...}, value={...}) > at /usr/src/xemacs-21.2/src/data.c:110 > #3 0x80e97ff in Fget_coding_system (name={...}) > at /usr/src/xemacs-21.2/src/file-coding.c:549 > #4 0x8092ff4 in dfc_convert_to_external_format (source_type=DFC_TYPE_DATA, > source=0xbfffd9e4, coding_system={...}, sink_type=DFC_TYPE_DATA, > sink=0xbfffd9dc) at /usr/src/xemacs-21.2/src/buffer.c:1881 > #5 0x8170840 in std_handle_out_va (stream=0x404818e0, > fmt=0x821a700 "malloc_set_state failed, rc = %d\n", args=0xbffffa18) > at /usr/src/xemacs-21.2/src/print.c:177 > #6 0x8170904 in stderr_out ( > fmt=0x821a700 "malloc_set_state failed, rc = %d\n") > at /usr/src/xemacs-21.2/src/print.c:193 I think it is wrong that XEmacs is trying to do code conversion at this point. Anyway the real problem seems to be that malloc_set_state is failing.. Jan

1 participants
0 comments

Re: William Piper 23 years, 11 months

William M. Perry

rossini(a)biostat.washington.edu (A.J. Rossini) writes: > >>>>> "WMP" == William M Perry <wmperry(a)aventail.com> writes: > > WMP> Vin Shelton <acs(a)xemacs.org> writes: > >> That's wonderful news! Congratulations, Andy! > >> > >> BP's family picnic sounds like a fine idea. Please be sure to > >> pick Becky, Noah and me up on your way to the midwest. > > WMP> Seattle is another likely candidate, I'm out there every 6 > WMP> weeks or so. *bleah* But of course it is 82 and sunny here > WMP> and its only may 5th... > > Seattle would be convenient for some of us. I'll offer to help with > the arrangements of an XEmacs family picnic here if there is > interest... The only problem with seattle for me is I typically don't bring my family... will have to talk to the wifey. -Bill P. ObWeatherUpdate: 86 and sticky today... going to be a good summer. :)

1 participants
0 comments

Re: Sick idea for GTK/XEmacs menubar/toolbar code... 23 years, 11 months

William M. Perry

Andy Piper <andy(a)xemacs.org> writes: > At 06:57 PM 5/7/00 -0500, William M. Perry wrote: > >What if... instead of writing menubar-gtk.c and toolbar-gtk.c, I just > >exported the GtkWidget that is the XEmacs frame to lisp, and wrote all the > >menu and toolbar code in lisp? > > As long as the APIs remain identical on all platforms I can't see a > problem with this. Unless it means you are always calling lisp for > redisplay.... I don't think it would mean calling lisp from redisplay. Menus shouldn't ever be popped up during redisplay, right? Otherwise we wouldn't be able to deal with :filter :included :config and friends. The toolbars shouldn't either (I think)... I'll have to give that one some thought. -Bill P.

1 participants
0 comments

Sick idea for GTK/XEmacs menubar/toolbar code... 23 years, 11 months

William M. Perry

What if... instead of writing menubar-gtk.c and toolbar-gtk.c, I just exported the GtkWidget that is the XEmacs frame to lisp, and wrote all the menu and toolbar code in lisp? Eh? Eh? Who's a sick bastard? The voices in my head just won't stop. :) -Bill P.

2 participants
1 comments

xemacs-21.1.10 experimental linux RPM available 23 years, 11 months

Neal D. Becker

I built an (experimental) xemacs-21.1.10 linux RPM on RH6.2. Any interest? If so, can I upload it somewhere?

1 participants
0 comments

Re: new subject: proper X session management 23 years, 11 months

Hamish Macdonald

>>>>> On 05 May 2000 16:10:12 -0500, >>>>> In message <86k8h8d7pn.fsf(a)megalith.bp.aventail.com>, >>>>> wmperry(a)aventail.com (William M. Perry) wrote: William> I'm going to futz with this in a few days with my GTK flavor William> of XEmacs. I don't know if you can use the gnome session William> objects without using the gtk event loop and widgets though. I wasn't going to mess around with the gnome session stuff. I was going to hook bog-standard X session management to lisp.

1 participants
0 comments

Re: new subject: proper X session management 23 years, 11 months

Hamish Macdonald

>>>>> On 06 May 2000 16:55:42 +0200, >>>>> In message <by8zxn3ez5.fsf(a)math.ethz.ch>, >>>>> Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote: Jan> I agree it would be a nice thing to have. Preferably this would Jan> consist of exporting the Xsession protocol to lisp hooks and then Jan> fitting something like session.el (which I have never used but i Jan> supposed to be good) it in. That's the sort of thinking that I had.

1 participants
0 comments

Balloon help bug in 21.2.33 (Was: New problem) 23 years, 11 months

Markus Alt

georgn(a)somanetworks.com wrote: > > I generally wouldn't care about balloon help except that I leave my > mouse over the envelope icon in the modeline and let the balloon help > tell me about my mail (from which I decide to read mail or not). > > As of now, the balloon geometry is hosed making the balloon windows > about 2-3 pixels wide. Hey, this display-time-mail-balloon is a neat useful feature (at least in my opinion) that I wasn't aware of. Thanks for the hint ... :-) Until today, I didn't care about balloon help, too. Unfortunately, it doesn't work for me under 21.2.33 (even with Andy's latest patches applied): Balloon help's windows are drawn correctly, but no text! Background color is ok and can be set with Customize. Works with 21.2.32. Markus

1 participants
0 comments

GTK/XEmacs - wow... :) 23 years, 11 months

William M. Perry

Well, I got signals to work on the first pass, minus the stupid typo that kept it from compiling at all. I'm sure something is #%!＠!ing stupid in it, but you can now attach lisp callbacks to GTK widgets, and they are done appropriately. If anyone wants to play around with it, please check out the latest CVS version. This test app should get you going. Another sick & twisted thing you might want to try is using: (setq box (frame-property (selected-frame) 'container-widget)) (setq widget (... muck with other widgets here ...)) (gtk-box-pack-start box widget nil t 5) (gtk-widget-show-all widget) That should stick whatever widgets you want at the top of the screen. I think it is doable to implement menus and toolbars using this instead of C code. There are a few functions that are not currently implemented... I'm not sure how to deal with functions that return things via pointers (some functions in GTK even return SINGLE values (integers even!) like this - lame!) I'm going to take a look at guile-gtk to see how they fixed that, but they have taken a fundamentally different approach and have a defs file that generates gobs of C code that you then compile, instead of calling the functions from the DLL directly. hrm. -Bill P. (load-library "gtk") (let ((win (gtk-window-new GTK_WINDOW_TOPLEVEL)) (vpane (gtk-vpaned-new)) (hpane (gtk-hpaned-new)) (clist (gtk-clist-new 5)) (box (gtk-hbutton-box-new)) (calendar (gtk-calendar-new)) (frame (gtk-frame-new "Combo box test")) (combo (gtk-combo-new)) (button nil) (ctr 0)) (gtk-container-add win vpane) (gtk-paned-add1 vpane hpane) (gtk-paned-add2 vpane box) (gtk-paned-add1 hpane calendar) (gtk-paned-add2 hpane clist) (gtk-clist-column-titles-show clist) (while (/= ctr 5) (gtk-clist-set-column-title clist ctr (format "Test row #%d" ctr)) (setq button (funcall (if (/= 0 (% ctr 2)) 'gtk-button-new-with-label 'gtk-check-button-new-with-label) (format "Test button #%d" ctr))) (gtk-container-add box button) (gtk-signal-connect-internal button 'clicked `(lambda () (message ,(format "Hello from button #%d" ctr)))) (setq ctr (1+ ctr))) (gtk-widget-show-all win))

1 participants
0 comments

Attempt to copy to unlocked clipboard! 23 years, 11 months

Falk Hueffner

Hi, I've tried to compile a recent cvs xemacs on an Debian Alpha Linux system using the Compaq C compiler. When starting src/xemacs -vanilla, and kill something (in this case ";; This buffer is"), I get repeatedly the message: Warning: Attempt to copy to unlocked clipboard! on the console and xemacs hangs. This doesn't happen if I turn off Options->Keyboard and Mouse->Yank/kill interact with clipboard. If I kill it I get: Fatal error (3). Your files have been auto-saved. Use `M-x recover-session' to recover them. If you have access to the PROBLEMS file that came with your version of XEmacs, please check to see if your crash is described there, as there may be a workaround available. Otherwise, please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/local/src/xemacs-21.2-05.07/src/xemacs core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: own-selection-internal(CLIPBOARD ";; This buffer is") # bind (append data type) own-selection-1(CLIPBOARD ";; This buffer is" nil) # (unwind-protect ...) # bind (--letf-save--95234 --letf-bound--95235 zmacs-region-stays append type data) own-selection(";; This buffer is" CLIPBOARD) # bind (append string) own-clipboard(";; This buffer is" t) # bind (replace string) kill-new(";; This buffer is") # bind (undo-high-threshold tail verbose end beg) kill-region(1 18 1) # bind (command-debug-status) call-interactively(kill-region) # (condition-case ... . error) # (catch top-level ...) zsh: quit (core dumped) src/xemacs -vanilla The backtrace is not really helpful: (gdb) bt #0 0x200015b3ba8 in __kill () at __kill:2 #1 0x120047054 in fatal_error_signal () Strangely, I cannot find the error message anywhere in the source. Does anybody have an idea how to track this down? Falk

2 participants
1 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 2000