April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Ben Wing

Perhaps it's not important enough to bother with? Hrvoje Niksic wrote: > load-average returns the average load values multiplied by 100. I > assume this is the result of the historical Emacs implementation, > before floating point numbers were implemented. It looks kind of > dirty now, at least to me. > > I wonder if there is a good way to fix it. Changing `load-average' > doesn't sound like a good idea, because it would introduce "silent" > incompatibility. Maybe we should define a new function for > floating-point load averages, and leave load-average as it is? > > -- > Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia > --------------------------------+-------------------------------- > Nostalgia isn't what it used to be. -- This message composed using voice recognition software and foot pedals. (No keyboards were harmed while composing this message.)

1 participants
0 comments

dlopen in SunOS 26 years

Amir J. Katz

Pardon my ignorance, but here are 2 silly questions: 1. When dlopen and friends are available, what are they used for in xemacs? With mule-less xemacs, the only library I see is liblw. The rest of the objects are linked in. 2. Assuming that I do choose to use dlopen, can it be done on SunOS? dlopen works just fine on good old SunOS. Thanks. -- /* Amir J. Katz mailto:amir＠nuke-spam.com */ /* [For e-mail, replace 'nuke-spam' with 'ndsoft'] */ /* EagleEye Control Software, LTD. http://www.ndsoft.com */ /* 'Is "tired old cliche" one?' (Steven Wright) */

1 participants
0 comments

Re: [PATCH] Some toolbar fixes. 26 years

Andy Piper

At 12:43 AM 4/23/98 +0400, Kirill M. Katsnelson wrote: >Andy: the four hashtables design has a serious flaw. When >you allocate an id, it is guaranteed to be unique in one >hastable. Although, it must to be unique accross all four >hashatbles, becuase command ids must be different in all >four toolbars. > >I suggest using single hashtable. The only change will >be that you would use Fremhash instead of Fclrhash when >deleting the toolbar, and use TB_GETBUTTON to get an id >to pass Fremhash. Other code is simplified though. After our discussions yesterday I realise this, and you are right. >Also, when computing toolbar checksum, it is necessary to >hash also toolbar glyphs. Otherwise, when toolbar images >change, checksum does not. This is why toolbar ignores >changing "captioned" toggle from the menu. Ok andy

1 participants
0 comments

Re: why is the line-number-mode option commented ? 26 years

Didier Verna

Ben Wing <ben(a)666.com> writes: > Blame Chuck, not Jamie. It is commented out because it has never been > implemented efficiently -- its current implementation is quadratic on large > files, which is very bad. A good reason to disable it default, but not to remove it from the options menu, IMHO. didier

1 participants
0 comments

Re: [PATCH] Make new toolbars SDK compile 26 years

Andy Piper

At 09:44 PM 4/22/98 +0400, Kirill M. Katsnelson wrote: >I have built with Andy's fixes. Coolbars! > >Attached is a patch with small fixes. Andy, if you compiled with higher >warning level, you'd caught one of these yourself. There is a bunch >of unprototyped function references also. > >Some notes. First, buttons are small, and places asymmetrically in height, >so there is about 10 pixels of gray between buttons and the first line of >text (see the attached picture). > >Second, there is one pixel gap at the right and bottom edges. > >Next, you reposition toolbars on grame redisplay. This is not very >good, because if a frame got shrunk, redisplay does not occur, so right >toolbar egde changes its shape. Although, sizing the toolbar so it is >wider at least 2 pixels than the frame will solve this problem. > >Then, the toolbar is wrappable. When window shrinks, the toolbars >wraps, and top pieces of second row buttons show up in that unused >gray space. > >Finally, toolbar gets redrawn on every mouse motion when sizing the frame. > >If Andy won't object, I would patch last 4 of 5 issues. If you know how to fix them - go ahead with my blessing. I've bashed my head against Win32 for long enough at the moment. The warning level is bugging me, I turned off stuff for cygwin because of the number of X warnings. Now I will turn it back on and fix my install of X. There is also 1 potential bug with tooltips that I know of. andy

1 participants
0 comments

Re: [SUCCESS] 21.0 "Pygmy-pre1" XEmacs Lucid (beta37) on i586-pc-linux 26 years

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> Just for the heck of it, I tried moving the installed hierarchy, and Stephen> got what I deserved. But this isn't very graceful. Couldn't find a Stephen> core dump, and it doesn't seem necessary here, so I'm not gonna do an Stephen> all-points bulletin except on request. [ ... ] Stephen> ./configure '--prefix=/playpen/install.share' '--exec-prefix=/playpen/install.local' '--package-path=~/.xemacs::/playpen/install.share/xemacs/packages' '--with-mule' '--with-xim=xlib' '--with-xfs' '--with-sound=both' '--use-union-type=yes' '--debug' '--gung-ho=yes' '--cflags=-g -O2 -fno-caller-saves -Wall -Wno-switch' This can't work 'cause your packages are in .../xemacs/packages as opposed to .../lib/xemacs/packages. When you do a vanilla install, it can pick up the packages because the configure'd package-path points the right way. Once you move the installed hierarchy, it doesn't anymore. Generally, if you want to be able to move the installed hierarchy, don't specify anything beyond --prefix and --exec-prefix on the configure command line. You'll get even better mileage if you omit those as well. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: [Joshua Rowe <rowe@eksystems.com>] Re: dlopen for xemacs 26 years

Ben Wing

A better approach than compiling Lisp into C code is to optimize the byte code interpreter. Here's something that I wrote earlier in a response to Martin: This way for example, you could convert unaligned accesses into aligned ones [1], substitute in array values from the constant array so as to avoid an extra indirection, check some parameters so they don't have to be checked at runtime, etc. Another likely place for speed up is in function calling, which currently is notoriously slow. There also probably speed ups that could be made in symbol value access. [1] what I mean to say is that the string of byte code instructions should be expanded into an array of integers, which will tremendously speed up access to those values. SL Baur wrote: > Subject: Re: dlopen for xemacs > Date: Mon, 20 Apr 1998 15:05:33 -0400 > From: Joshua Rowe <rowe(a)eksystems.com> > To: SL Baur <steve(a)xemacs.org> > References: <9801152235.AA13534(a)meta.eksystems.com> > <m2n2djg4dy.fsf(a)altair.xemacs.org> > > SL Baur writes: > > I don't recall if I ever got back with you on this. We've integrated > > dlopen into XEmacs and have been hacking on it. William Perry has > > done some further work on it, particularly with regards to portability > > and configure issues. The latest word is that Richard will be using > > a version of it in FSF GNU Emacs as well. > > > > Thanks for kicking things off. > > Sure thing. > > Maybe I should have posted this to a mailing list/newsgroup, but I > really don't pay attention to things like that. Forward this and > forget it if you wish. > > I'm not sure if I ever told you the intent of the code. Maybe you can > find someone to figure out the specifics: > > It is much more useful to use native compiled code if you don't have > to recompile xemacs whenever the code changes. > It is good to keep most of the code in xemacs in lisp form. > It would be good to have a lisp->native-machine-code compiler. > It is now possible to load native code without recompiling xemacs. > The lisp->native-machine-code compiler can be platform independent by > outputting xemacs-standard C - ie it uses all the C macros in lisp.h, > etc - and compiling that code into a shared library which can then be > dlopen'ed. > > The actual code that is output can be very simple for a first pass - > there is already a byte compiler. Take a piece of byte compiled code > and output the C that gets run for that bytecode. bytecode.c has the > operations and the C actions. Output those C actions. > > I'm not sure exactly how much faster the code could become in this > fashion, but I believe it could be _much_ faster if someone wrote a > lisp->C instead of my current suggestion of lisp->bytecode->C. > > For example, from disassemble bbdb-add-hook: > 0 constant boundp > 1 varref hook > 2 call 1 > 3 goto-if-not-nil 9 > > would become: > > Lisp_Object * bbdb_add_hook_constants; > > DEFUN ("bbdb-add-hook"...) > { > /* variable declarations, including constant's */ > Lisp_Object v1, v2; > int op; > > /* other stuff, including initialize the stack */ > > do switch (op = FETCH) { > 0: /* constant boundp */ > PUSH(bbdb_add_hook_constants [0]); > > 1: > v1 = bbdb_add_hook_constants [5]; > if (!SYMBOLP (v1)) > v2 = Fsymbol_value (v1); > else > { > v2 = XSYMBOL (v1)->value; > if (SYMBOL_VALUE_MAGIC_P (v2)) > v2 = Fsymbol_value (v1); > } > PUSH (v2); > > 2: > DISCARD (1); > TOP = Ffuncall (op + 1, &TOP); > > 3: > op = FETCH2; > if (!NILP (TOP)) > { > pc = op; > break; > } > } while (1); > ... > } > > -- > > jmr - http://meta.eksystems.com/~rowe > > Just because you're paranoid doesn't mean they're not after you. > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.1 > GCS dpu s: a--- C++++$ ULOU++++$ P+ L++++$ E+++$ W++ !N- !o>+ ?K > w---(++) O+ M-- V+++$ PS+ PE Y PGP- t+ 5 X+++ R>+ !tv b+++ DI++ D- G e > h++ r y > ------END GEEK CODE BLOCK------ -- This message composed using voice recognition software and foot pedals. (No keyboards were harmed while composing this message.)

1 participants
0 comments

Re: why is the line-number-mode option commented ? 26 years

Ben Wing

Blame Chuck, not Jamie. It is commented out because it has never been implemented efficiently -- its current implementation is quadratic on large files, which is very bad. By the way, the history of Jamie's life at Netscape is spelled out in excruciating detail in a book called Speeding the Net that is about to come out. Here is a random quote: In the summer of 1989, he followed a girlfriend out to Berkeley and found a Lisp-related job on campus before moving on to Lucid, in Menlo Park, which sold Lisp compilers. But a few months after he got there, Zawinski was forced to come down and peddle himself as a C++ programmer: Lisp, archaic and beautiful as ancient Greek, was dying as a language. It broke his heart. "Leaving Lisp to do work on C was like going to work for the Peace Corps." Mediocrity, he was coming to learn, has a better chance for survival than perfection. (A footnote to history: a lot of Lisp, as it turns out, lives on in the programming pidgin language known as Java.) SL Baur wrote: > It's been commented out since (at least) XEmacs 19.11. Let's blame Jamie! -- This message composed using voice recognition software and foot pedals. (No keyboards were harmed while composing this message.)

1 participants
0 comments

"X-Mailing-List:" 26 years

Kazuyoshi Furutaka

I'd like the "X-Mailing-List:" header to be "X-Mailing-List: <xemacs-beta(a)xemacs.org> archive/latest/28XXX" rather than "X-Mailing-List: <xemacs-beta(a)xemacs.org>". With the latter form, it is difficult to sort and trace threads... -- Kazuyoshi Furutaka furutaka(a)tokai.pnc.go.jp furutaka(a)jb3.so-net.ne.jp

1 participants
0 comments

Re: [PATCH] package-compile.el and path searching 26 years

Michael Sperber

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> This patch shouldn't be necessary. package-compile.el shouldn't be sb> searching for and finding external packages. It should *only* be sb> picking up core lisp, then adding specific directories via table sb> lookup. sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >> This is just for consistency, very low priority. >> 1998-04-17 Michael Sperber [Mr. Preprocessor] <sperber(a)informatik.uni-tuebingen.de> >> * package-compile.el: Used paths-load-path-depth variable. This isn't for external packages, this is for core Lisp. It certainly isn't necessary because it *limits* the load-path depth to be consistent with the way the rest of XEmacs sees it. I just want to avoid obscure consistency problems in cases where someone puts subdirectories underneath core Lisp deeper than 1. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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