June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 25 years, 1 month

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > That is not an option. Many many many people care. > > Absolutely agree. The FSF Emacs camp made many enemies by doing > this. At the same time, I'm sure they improved the quality of their > internationlization work by forcing themselves and every user to > constantly deal with it. But I don't know if that is an efficient > way to do business. The more I learn about internationalization the > more I think it is best handled by specialists, much the way > computer security work is handled today. I'm not sure I understand the last sentence, just as I can't gather what's being said on the sound clip, but I'm glad you agree with the sentiment. I have great fears regarding Mule development. Recent plans seem to be taking Mule to the directions I don't like at all. One of these days I'll once again relieve my heart of the Mule burden, and it will be for good. <sniffle> <whimper>! P.S. Note that FSF also took the easy/ier way out by allowing a `--unibyte' option and the corresponding EMACS_UNIBYTE environment variable.

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > Finally, I do need integers as large as I can get, even when it's not > > the full 32 bits. We'll have to find another way for dealing with > > UCS-4. > > Do the swap only on Mule? That would be the worst possible option. Mule should bring new functionality, not cripple XEmacs. I can already hear people saying, "Oh, you need larger buffers? Why, compile without Mule -- everyone sensible does that." > You do not really want to do O(n^2) operations on 1 Gbyte buffers > anyway. You don't. Why do you ask?

1 participants
0 comments

RE: Thoughts on XEmacs packaging (was Re: Making docdir configura ble) 25 years, 1 month

Brian Bailey

I agree with Kyle. And in the same tone of voice. :-) Keep the no-mule. -----Original Message----- From: Kyle Jones [mailto:kyle_jones＠wonderworks.com] Sent: Tuesday, June 29, 1999 8:25 AM To: XEmacs Beta List Subject: Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) Hrvoje Niksic writes: > SL Baur <steve(a)xemacs.org> writes: > > > Or maybe no one cares and we can drop XEmacs/no-Mule entirely ...

1 participants
0 comments

Re: efs-hang on NT 25 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Having EFS just implementing the FTP protocol or just shipping a > sane FTP client with the NT port sound more and more attractive now. Implementing FTP is impossible without support for listening sockets -- we would have to rely on the "passive" transfer mode always being available.

1 participants
0 comments

Secure CVS: Have yous seen this? 25 years, 1 month

Karl M. Hegbloom

Secure CVS via an SSH tunnel: <URL:http://cuba.xs4all.nl/~tim/scvs/> I found that at: <URL:http://www.loria.fr/~molli/cvs-index.html> ... which is in the CVS 1.10 info documentation. Should I post stuff like that, or is it a waste of time?

1 participants
0 comments

Re: efs-hang on NT 25 years, 1 month

Jan Vroonhof

Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: > It jumps to the else part and then happily loops. Introducing a > time-out to accept-process-output didn't change that. > > I'm certainly at a loss, You need to step through the process filter. See whether it is getting any data and if not up to what point there is still data coming in. If you have established that EFS is not receiving some data from its process filter then you need to go in with a debugger to find out whether XEmacs gets any data from ftp.exe at all. Having EFS just implementing the FTP protocol or just shipping a sane FTP client with the NT port sound more and more attractive now. Jan

1 participants
0 comments

efs-hang on NT 25 years, 1 month

Holger Schauer

Hi efs-folks ! I've reported a reproducible hang (for me, at least) on NT4SP4, with the current efs-package for XEmacs 21. That is, efs-version 1.18/1.57. First hint: the ftp-client is "eingedeutscht", i.e. it answer for example "Hash EIN (2048 Bytes/sec)" instead of using "hash mark". Fiddling with efs-hash-mask-msgs didn't help. >>>>"JV" == Jan Vroonhof schrieb am 29 Jun 1999 19:15:13 +0200: JV> Does this patch help (It basically trying to push the NT ftp JV> client into flushing the buffer the same way as at other points). No, unfortunately it doesn't. But I can show where it hangs - in the same function, i.e. efs-raw-send-command in (prog1 (if nowait nil ;; hang around for command to complete ;; Some clients die after the command is sent, if the server ;; times out. Don't wait on dead processes. (efs-kbd-quit-protect proc (while (and efs-process-busy ;; Need to recheck nowait, since it may get reset ;; in a cont. (null efs-process-nowait) (memq (process-status proc) '(run open))) (accept-process-output proc))) It jumps to the else part and then happily loops. Introducing a time-out to accept-process-output didn't change that. I'm certainly at a loss, Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "In Scheme, as in C, every programmer has to be a genius, but often comes out a fool because he is so far from competent at every task required." -- Erik Naggum in comp.lang.lisp

1 participants
0 comments

Re: [Success] 21.1 (patch 3) "Acadia" XEmacs Lucid on i386-pc-win32 25 years, 1 month

Holger Schauer

>>>>"JV" == Jan Vroonhof schrieb am 29 Jun 1999 19:20:01 +0200: >> 230 Logged in. hash Hash EIN (2048 Bytes/Hash). JV> N.B. Your `eingedeutschte' ftp client does not follow the JV> response pattern EFS expects. JV> (defvar efs-hash-mark-msgs "[hH]ash mark [^0-9]*\\([0-9]+\\)") ;; I set it to an appropriate value, to no avail. I then tried setting efs-hash-mark-size manually to 2048, again to no avail. Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "In Scheme, as in C, every programmer has to be a genius, but often comes out a fool because he is so far from competent at every task required." -- Erik Naggum in comp.lang.lisp

1 participants
0 comments

Re: [Success] 21.1 (patch 3) "Acadia" XEmacs Lucid on i386-pc-win32 25 years, 1 month

Jan Vroonhof

Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: > 230 Logged in. > hash > Hash EIN (2048 Bytes/Hash). N.B. Your `eingedeutschte' ftp client does not follow the response pattern EFS expects. (defvar efs-hash-mark-msgs "[hH]ash mark [^0-9]*\\([0-9]+\\)") ;; Regexp matching the FTP client's output upon doing a HASH command. Jan -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

1 participants
0 comments

Re: [Success] 21.1 (patch 3) "Acadia" XEmacs Lucid on i386-pc-win32 25 years, 1 month

Jan Vroonhof

Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: > The EFS problem is still there. This is what happens (help: lossage) > after C-x C-f /supreme＠schauer:/home/schauer Does this patch help (It basically trying to push the NT ftp client into flushing the buffer the same way as at other points). diff -u /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el~ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el --- /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el~ Tue Jun 29 19:03:14 1999 +++ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el Tue Jun 29 19:03:14 1999 ＠＠ -3348,7 +3348,7 ＠＠ " Turtle Power!\n") (setq efs-process-cmd cmd) (insert cmd "\n"))) - (process-send-string proc (concat cmd "\n")) + (process-send-string proc (concat cmd "\nhelp help\n")) (set-marker (process-mark proc) (point)) ;; Update the mode-line (if (and (or efs-mode-line-format efs-ftp-activity-function) -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

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