June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Ben Wing

I've compiled a short list of bugs that I consider to be showstoppers for the 21.0 release. It's located at: http://devel.xemacs.org/xemacs/showstoppers.html Ben (typed by Martin)

6 participants
6 comments

Re: gud.el broken or is it just me? 23 years, 6 months

SL Baur

Aki Vehtari <Aki.Vehtari(a)hut.fi> writes in xemacs-beta(a)xemacs.org: ... > Btw. gud.el in XEmacs is dated 1993 and gud.el in emacs-20.3 is > dated 1998. Unfortunately gud.el in emacs-20.3 does not work in > XEmacs and I don't know much work it would need to make it work and I've done the initial port of gud.el to XEmacs. It mostly works[1], but it sorely lacks the functionality in gdbsrc.el. Making a gudsrc.el mode is on my list of things to do. It was in ftp://altair.xemacs.org/pub/xemacs-futures/ when I was on the 'net. It was delayed integration into the XEmacs packages pending 21.0 release. I also have a ported cua-mode.el to integrate. NOTE: The gud.el and cua-mode.el XEmacs portings are courtesy of Altrasoft, Inc. Thank you Altrasoft. Footnotes: [1] I have a report that my port does not work on Solaris with dbx.

2 participants
1 comments

RoboCup 23 years, 9 months

Akram Khodadadi

Hello Please answer my question. We maked a player in Linux with Lisp languaege ,but we dont know how to make a UDP connection between our player and the server with Lisp languaege. We looked in many sources ,but we didn't attain any affects. Please say to us for making a UDP connection and geting and sending messages with that Lisp languaege which orders . Please explan with an example. Thanks Mrs Khodadadi

3 participants
2 comments

Re: (insert 8000) crashes XEmacs 21.2.16 25 years

SL Baur

Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes in xemacs-beta(a)xemacs.org: > xemacs -vanilla > (insert 8000) Ouch! -- 窓番号を入力してください

4 participants
4 comments

Re: Doc string patch for XEmacs/InfoDock. 25 years, 4 months

SL Baur

I agree. Comments? Bob Weiner <weiner(a)altrasoft.com> writes: >> It would be really nice if format-time-string could take this format >> (date in seconds since 1970) as an input and output a formatted date >> from it. > Said another way, the emacs_strftime should be converted to a Lisp subr and > the system type `time_t' should be made into a Lisp type with easy back and > forth conversion operators where needed. Then we'd have pretty much native > UNIX time handling. Right now, I can't see a clear way to convert a given > UNIX time to a formatted date. > Bob -- 頭隠して尻隠さず

3 participants
2 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 5 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> What does direct UCS-4 support in characters buy me > Hrvoje> anyway? Will it be another case of all-encompassing Mule > Hrvoje> priorities breaking the neck of the rest of us? > > It buys you direct UCS-4 support in characters. And what does that buy me? Are we running in circles here? > o XEmacs will never again (well, for a future longer than the > history of electronic computers) need to change the abstract > format for a Lisp character. This is true without UCS-4 too. It's only the implementation that changes. > o Mule backwards compatibility. Lisp code that relies on a particular representation of characters is broken in the first place. > Sure, those may not excite you. They don't excite me at all. 700M buffers excite me. Whose 700M buffer is this? Zed's. Who's Zed? Zed's dead baby. Zed's dead... > Hrvoje> right, you have to modify all the C code that relies on > Hrvoje> Lisp_Object integers fitting in an integral type called > Hrvoje> "EMACS_INT" (int or long). And there's a *lot* of such > Hrvoje> code, with possibly long integers propagating all over the > Hrvoje> place. > > ...I don't see that it has to be done all at once. How else would you do it? Bignums are not just another opaque data type -- they have to be done right. Unless, of course, you are satisfied with half-assed solutions a la Python or, for that matter, C. > You can (partially) implement a bignum type, and implement it where > it helps somebody. Places where it has not yet been implemented > will throw a type error automatically if you try to pass them in; Don't you get it? It breaks any hope of large buffers working with bignums. Integers get propagated all over the place. If you take the easy way out and throw type errors in XINT, you could as well not bother in the first place. That's why I never tried to add them. > Hrvoje> Also, with bignums avaialble, you would probably want to > Hrvoje> provide compiler declarations so that reasonably > Hrvoje> efficient code can be written, i.e. (declare (fixnum > Hrvoje> x)). > > Sure. But again, that's a project that can be put off until it > matters to somebody. (Maybe; I realize that it's possible that > checks for bignums will slow everything down and everybody will > care. But then the --with-bignums=no option wins.) --without-bignums never wins. Either do it right or don't do it at all. We aren't developing crappy commercial software here, after all. :-)

3 participants
3 comments

Re: GCC 2.95 good news 25 years, 5 months

Jan Vroonhof

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes: > good to hear. Have you tried the skip-syntax-backward crash recipes? > Barry Warsaw has one in the BTS and I posted one here a long time ago. I Barry Warsaw's recipe doesn't crash this one. Jan

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 5 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I thought some operations on mule buffers become O(n^2)? Under Mule, access to the byte position of character index n is O(n). This means that simply iterating through characters is an O(n^2) operation. However, insdel.c maintains a cache of recent buffer byte positions which is supposed to remove O(n^2) for iteration. No such caches exist for strings. Noone has measured how well the cache actually fares. > I am not a fan limiting the integer range and I hope some other > solution can be found but if really makes implementing that much > easier I won't loose any sleep over it. That's worse-is-better.

1 participants
0 comments

Re: GCC 2.95 good news 25 years, 5 months

Jan Vroonhof

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes: > > I just build 21.1.3-latin-2 with the latest snapshot for GCC 2.95 on > ^^^^^^^^ > what does that mean? Have I misssed something here? Sorry for letting Hrvoje's hart miss a beat, but it was a typo :-) > > Sparc and so far there seem to be no problems. > > good to hear. Have you tried the skip-syntax-backward crash recipes? > Barry Warsaw has one in the BTS and I posted one here a long time ago. I I'll try. I forgot we had a recipe. I was just waiting for the big moment to come. Jan

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 5 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Would it be difficult to have a separate "unsigned integer type?". > > That could still go up to 2^30-1. > > That type would have to be an lrecord. Draw your own conclusion. No. In that case I want unsigned integers to be the "primitive type" and would I want normal integers to be an lrecord. Buffer positions could then still be represented by that new "unsigned integer type". With an lrecord lisp type you could have 32-bit integers. I am not even sure I want the lisp code to see the distinction. Maybe (probably?) such a thing will be extremely ugly to implement, I don't know. Maybe an even better idea would be to this for characters. > No "scheme" will buy you 31-bit integers except the current one, and > bignums. And bignums are hard. lrecord integers. Of course you could also argue for lrecord chars, presumably the actual value of chars will not be used that often, presumably less then integers. Did anybody ever do profiling on this? Maybe putting characters in lrecords for Mule is the way to go. Maybe even with the ugly small-character/big-character thing I reposed for unsigned/signed integers above. I think it is less of a crime if the internal representation of stuff changes depending on the Mule switch without changing any lisp visual limits. > > Because I think editing a 1 Gbyte buffer in a Mule XEmacs will be so > > slow that it doesn't matter much anyway. > > Have you tried it? I have tried 600M buffers, and things worked > reasonably fast -- i.e. slow as hell, but workable in case of > emergency. Ok we do better as I thought then. > I still don't understand your remark about O(n^2) operations, though. I thought some operations on mule buffers become O(n^2)? Or am I confusing things here. I am not a fan limiting the integer range and I hope some other solution can be found but if really makes implementing that much easier I won't loose any sleep over it. Jan

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 June 1999