August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Meeting in Paris? 26 years, 8 months

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > It is very likely that I will attend this year's DECUS conference > (apparently named Eureka98 in this year's incarnation) in Paris, > beginning at September 13th. I am very interested in meeting les > XEmacs'ers Parisiens, as well as other worldly XEmacs'ers who plan to > attend the conference. Feel free to contact me if you actually come. It's not so often that we can meet, and what's more outside of the US. Anybody else … [View More]

1 participants
0 comments

Re: Faster lisp engine 26 years, 8 months

Michael Sperber

>>>>> "Chipsy" == Michael Sperber <sperber(a)Informatik.Uni-Tuebingen.De> writes: >>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: Glynn> Olivier Galibert wrote: >>> > By the way, I don't think that the lisp engine itself is that much of >>> > a bottleneck in XEmacs, so we should not be looking at a replacement >>> > lisp engine specifically for a blazing fast XEmacs. >>> >>> I … [View More]

2 participants
1 comments

Re: Faster lisp engine 26 years, 8 months

SL Baur

Glynn Clements <glynn(a)sensei.co.uk> writes in xemacs-beta(a)xemacs.org: ... > Strong typing probably wouldn't hurt either. We already have strong typing. Static typing is inappropriate.

1 participants
0 comments

Re: Faster lisp engine 26 years, 8 months

Michael Sperber

>>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: Glynn> Olivier Galibert wrote: >> > By the way, I don't think that the lisp engine itself is that much of >> > a bottleneck in XEmacs, so we should not be looking at a replacement >> > lisp engine specifically for a blazing fast XEmacs. >> >> I think that lexical scoping would make a huge difference by allowing >> much tighter optimizations of the compiled … [View More]

1 participants
0 comments

Showstopper: unix_send_process is badly broken 26 years, 8 months

SL Baur

It appears that unix_send_process was broken by the MS Windows port. I'm getting repeated SIGPIPE crashes (which are supposed to be handled -- I have not yet reduced it to a simple test case, though I have found a repeated signal 11 test case), and the `This function can GC' labeling has been removed even though it can GC. This is a show stopper and I'm not releasing 21.0 until it is fixed. It wasn't this badly broken in 20.4. [I'm not interested in assigning blame, I only want the code fixed.]

1 participants
0 comments

Re: Faster lisp engine 26 years, 8 months

Jareth Hein

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> By the way, I don't think that the lisp engine itself is that Martin> much of a bottleneck in XEmacs, so we should not be looking at Martin> a replacement lisp engine specifically for a blazing fast Martin> XEmacs. Martin> The best things to look at from a performance point of view, Martin> judging from my profiling runs, are Martin> - redisplay Martin> - redisplay some more … [View More]

2 participants
1 comments

Faster lisp engine 26 years, 8 months

Martin Buchholz

News of this is getting out, so I may as well make it official. I'm working on making the elisp engine (mostly eval.c) faster, using ideas supplied by Ben, and a few of my own. If anyone else is making changes to this part of the code, talk to me first so we don't collide. By the way, I don't think that the lisp engine itself is that much of a bottleneck in XEmacs, so we should not be looking at a replacement lisp engine specifically for a blazing fast XEmacs. The best things to look at … [View More]

3 participants
2 comments

Re: [Crash] gnuclient -nw 26 years, 8 months

Karl M. Hegbloom

>>>>> "Glynn" == Glynn Clements <glynn(a)sensei.co.uk> writes: Glynn> Karl M. Hegbloom wrote: Glynn> Well, I've just built gpm-1.14, and the problem has Glynn> vanished. I'll put this one down to a shared library Glynn> mismatch. >> >> Can you suspend XEmacs with `C-z' now? I hope they fixed that. Glynn> Yes, C-z works. Are you sure? With `gpm' running, support for it compiled into XEmacs, and running on the … [View More]

2 participants
1 comments

Re: libpng! 26 years, 8 months

Jareth Hein

>>>>> "nbecker" == nbecker <nbecker(a)fred.net> writes: nbecker> I'm trying to build on i686-pc-linux-gnu RH5.1. It seems I nbecker> need libpng-1.0.2. nbecker> OK, I built libpng-1.0.2 modifying the makefile to build nbecker> share lib via libtool. nbecker> What to call the soname? I'm assuming that libpng-1.0.2 is nbecker> not binary compatible with 1.0.1. On RH5.1 libpng-1.0.2 is nbecker> called libpng-2.1.0 (I think that was actually my doing … [View More]when nbecker> I put it into libgr, IIRC). 1.0.2 is binary compatible with what little testing I gave it. There are a couple of new functions/features, but the rest is bugfixes. nbecker> So I'm calling libpng-1.0.2 libpng-3.0.0. What do you think? I don't quite understand where your question comes from... The libpng-1.0.2 makefile should create for you a shared library with the soname of 2.1.0.2. If you look at the top of png.h, you will see the following: * Note about libpng version numbers: * * Due to various miscommunications, unforeseen code incompatibilities * and occasional factors outside the authors' control, version numbering * on the library has not always been consistent and straightforward. * The following table summarizes matters since version 0.89c, which was * the first widely used release: * * source png.h png.h shared-lib * version string int version * ------- ------ ----- ---------- * 0.89c ("1.0 beta 3") 0.89 89 1.0.89 * 0.90 ("1.0 beta 4") 0.90 90 0.90 [should have been 2.0.90] * 0.95 ("1.0 beta 5") 0.95 95 0.95 [should have been 2.0.95] * 0.96 ("1.0 beta 6") 0.96 96 0.96 [should have been 2.0.96] * 0.97b ("1.00.97 beta 7") 1.00.97 97 1.0.1 [should have been 2.0.97] * 0.97c 0.97 97 2.0.97 * 0.98 0.98 98 2.0.98 * 0.99 0.99 98 2.0.99 * 0.99a-m 0.99 99 2.0.99 * 1.00 1.00 100 2.1.0 [int should be 10000] * 1.0.0 1.0.0 100 2.1.0 [int should be 10000] * 1.0.1 1.0.1 10001 2.1.0 * 1.0.1a-e 1.0.1a-e 10002 2.1.0.1a-e * * Henceforth the source version will match the shared-library minor * and patch numbers; the shared-library major version number will be * used for changes in backward compatibility, as it is intended. The * PNG_PNGLIB_VER macro, which is not used within libpng but is available * for applications, is an unsigned integer of the form xyyzz corresponding * to the source version x.y.z (leading zeros in y and z). Hope this helps. -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder [View Less]

1 participants
0 comments

Re: [patch] Removal of GIF support 26 years, 8 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > I am very uncomfortable with XEmacs losing GIF support. Many other > programs support displaying GIFs without alleged legal problems. As were we all. Keep catching up on old mail and examine the latest test release. :-)

1 participants
0 comments

2025

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