March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: A real database for Emacs 24 years, 8 months

Jan Vroonhof

SL Baur <steve(a)beopen.com> writes: > Attached are patches to XEmacs 21.1.10 to add runtime support for the > PostgreSQL relational database. Did mean for this to go to -patches? Or did you send it here because it still preliminary.. Three comments... 1. Can we have this as a module pleeeze? 2. > Note: This entry point is provided for completeness, but its use is not > recommended. The preferred way to delete connections is to let the Emacs > garbage collection mechanism do it. Isn't this bad in the same way that closing files by finalization is? 3. The harlequin M-BS xanalysis common lisp SQL bindings allow iterating over the result of a query using map- and do- like functions. IIRC they do this not by downloading all the results but by transparently creating a database cursor[1] for you. That would be very cool. Jan Footnotes: [1] I think cursor is the correct term.

1 participants
0 comments

Fix failed window-gutter experiment 24 years, 8 months

Andy Piper

I mistakenly assumed that using the existing window gutter support was going to be easier than fixing frame gutters properly. Now that I've tried to fix all the outstanding bugs, I've just ended up in a mess of twistly little XEmacs code paths. This patch ditches the whole window gutter thing and calculates frame-based gutter geometries. This magically makes everything work and is what I should have done in the first place - except I didn't understand the XEmacs code well enough. andy 2000-03-01 Andy Piper <andy(a)xemacs.org> * window.c (window_top_frame_gutter_height): deleted. (window_bottom_frame_gutter_height): ditto. (window_left_frame_gutter_height): ditto. (window_right_frame_gutter_height): ditto. (window_top_gutter_height): don't use them. (window_bottom_gutter_height): ditto. (window_left_gutter_width): ditto. (window_right_gutter_width): ditto. (Fsplit_window): ditto. (Fwindow_pixel_edges): don't use border dimensions here. * scrollbar.c (update_scrollbar_instance): don't take gutters into account. (update_scrollbar_instance): ditto. * redisplay.c (generate_modeline): don't take gutters into account. (generate_modeline): ditto. (redisplay_frame): small gutter display optimisation. * redisplay-x.c (x_output_vertical_divider): don't take gutters into account. * redisplay-msw.c (mswindows_output_vertical_divider): don't take gutters into account. * gutter.h (WINDOW_REAL_*_GUTTER_BOUNDS): remove bogus checks for window position and type. * gutter.c (get_gutter_coords): fix for frame gutters. (update_frame_gutters): update frame geometry if the gutters have changed. (init_frame_gutters): record current gutter geometries. * glyphs-msw.c (mswindows_subwindow_instantiate): remove unused var. (mswindows_widget_instantiate): ditto. * frame.h (struct frame): add current_gutter_bounds. * frame.c (change_frame_size_1): position window and minibuffer appropriately taking into account the frame gutters. * frame-x.c: (x_initialize_frame_size): take into account the frame gutters. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
4 comments

Re: Intent to rename source files implementing lisp objects 24 years, 8 months

Andreas Jaeger

>>>>> SL Baur writes: sb> Andreas Jaeger <aj(a)suse.de> writes in xemacs-beta(a)xemacs.org: >> You should be able to move the file in the repository itself. This >> keeps the history. sb> Except that you will lose the ability to check out previous versions. You're right - ok, replace move by copy - and please test it with a private CVS server first ;-). Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: Intent to rename source files implementing lisp objects 24 years, 8 months

SL Baur

Andreas Jaeger <aj(a)suse.de> writes in xemacs-beta(a)xemacs.org: > You should be able to move the file in the repository itself. This > keeps the history. Except that you will lose the ability to check out previous versions.

1 participants
0 comments

Re: First round of patches for 21.1.10 24 years, 8 months

Andreas Jaeger

>>>>> Vin Shelton writes: >>>>> On 04 Mar 2000 21:15:43 +0100, Andreas Jaeger <aj(a)suse.de> said: >>>>> Vin Shelton writes: Vin> I have applied the first round of patches for 21.1.10 to the CVS Vin> archive. Here's the list of patches applied; I think this covers all Vin> the patches I currently have. Let me know if I've missed any. Andreas> Just one note: I compiled 21.1.10 and noticed that I now have a "load Andreas> .emacs" button in the menubar: Andreas> This doesn't happen with the current 21.2 version from CVS. Vin> Yes. I had tried 'xemacs -vanilla', but not without -vanilla. Vin> I'm about to apply this fix: That's fixed the problem for me. Thanks, Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: Intent to rename source files implementing lisp objects 24 years, 8 months

Andreas Jaeger

>>>>> Martin Buchholz writes: > Most lisp object types are associated with a source file bearing its > name, eg. window.c or buffer.c. For consistency with this, I propose > the name change > elhash.c ==> hash-table.c > elhash.h ==> hash-table.h > The period before the next CVS move of 21.2 onto the trunk is the > perfect time to rename files, since CVS history will have an > unavoidable discontinuity anyways. You should be able to move the file in the repository itself. This keeps the history. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: XEmacs slows down like hell 24 years, 8 months

Martin Buchholz

I tried to find gc problems in 21.2 xemacs, but all I could find was already known: - cons cells take 50% more storage in 21.2. - pure space is gone, so gc will always take longer by a fixed amount. If your physical memory size is near the size that will cause thrashing, the 50% extra space _could_ translate into 10 times more clock time used. For me, 21.1 is faster at gc only by less than 25% when I run (progn (compile-and-profile (let ((count 9000000)) (while (> count 0) (setq z (cons 1 2)) (setq count (- count 1))))) (compile-and-profile (loop repeat 10 do (garbage-collect)))) So, to fix this we need to: - make cons cells take up only 2 words using the Big Bag of Pages technique (perhaps too hard?) - implement some kind of generational gc. We've paid a pretty high price so far for portable dumping. Let's try to minimize it. Martin

2 participants
2 comments

Intent to rename source files implementing lisp objects 24 years, 8 months

Martin Buchholz

Most lisp object types are associated with a source file bearing its name, eg. window.c or buffer.c. For consistency with this, I propose the name change elhash.c ==> hash-table.c elhash.h ==> hash-table.h The period before the next CVS move of 21.2 onto the trunk is the perfect time to rename files, since CVS history will have an unavoidable discontinuity anyways. Similarly, chartab.c ==> char-table.c chartab.h ==> char-table.h Martin

3 participants
2 comments

XEmacs slows down like hell 24 years, 8 months

Michael Sperber

At first I thought it was Gnus because that's currently the most performance-critical app here: A beta XEmacs 21.2 that's run for a few days finished this benchmark: (let ((count 1000000)) (while (> count 0) (cons 1 2) (setq count (- count 1)))) in 52 seconds on my 43p-140. A fresh one, however, does the trick in 19 seconds. Is this to be expected because of the debugging code? I don't seem to remember that it's always been that way. If it's not, this is a serious problem. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

3 participants
3 comments

Re: First round of patches for 21.1.10 24 years, 8 months

Vin Shelton

>>>>> On 04 Mar 2000 21:15:43 +0100, Andreas Jaeger <aj(a)suse.de> said: >>>>> Vin Shelton writes: Vin> I have applied the first round of patches for 21.1.10 to the CVS Vin> archive. Here's the list of patches applied; I think this covers all Vin> the patches I currently have. Let me know if I've missed any. Andreas> Just one note: I compiled 21.1.10 and noticed that I now have a "load Andreas> .emacs" button in the menubar: Andreas> This doesn't happen with the current 21.2 version from CVS. Yes. I had tried 'xemacs -vanilla', but not without -vanilla. I'm about to apply this fix: Index: lisp/menubar-items.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/menubar-items.el,v retrieving revision 1.16 diff -u -r1.16 menubar-items.el --- menubar-items.el 2000/03/04 17:13:09 1.16 +++ menubar-items.el 2000/03/04 20:53:17 ＠＠ -962,8 +962,9 ＠＠ (defun maybe-add-init-button () "Don't call this. Adds `Load .emacs' button to menubar when starting up with -q." - (when (and (not init-file-loaded) - (file-exists-p (expand-file-name ".emacs" "~"))) + (cond + (init-file-user nil) + ((file-exists-p (expand-file-name ".emacs" "~")) (add-menu-button nil ["Load .emacs" ＠＠ -974,7 +975,8 ＠＠ (buffer-list)) (load-user-init-file (user-login-name))) ] - "Help"))) + "Help")) + (t nil))) (add-hook 'before-init-hook 'maybe-add-init-button) - vin

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