January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Beware of modules. 26 years, 2 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > 2- What we're talking about is function call (trampoline or indirect) > vs. _inline_. The 30% slowdown of mule is mostly due to the fact that > moving to the surrouding characters is more complex than p++ and p--, > and you would want to change that to a _function_call_ ? Totally off-topic, but if someone mentions the "30%" figure once again, I'll SCREAM! It's a myth. Subjectively, Mule is at least 3 times slower than non-Mule -- and Martin's benchmarks confirmed that "30% slowdown" is an insulting euphemism. Not that I have any problem with what you, Olivier, are saying here -- I just want to draw everyone's attention that repeating the 30% myth won't make it true.

3 participants
2 comments

Re: Beware of modules. 26 years, 2 months

Norbert Koch

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > > :) I'm OK with this. It was the Lisp directories that I wanted > > consolidated, for speed. But that looks completely out of the > > question now, so forget it. > > Well, I clearly remember you saying that you'd freak out if the C > sources were split the same way that the Lisp sources have been. Please, Hrvoje, don't push the point :-)

1 participants
0 comments

Re: Beware of modules. 26 years, 2 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > May I hear technical arguments _for_ modules for a change ? Modules are a nice way of introducing a simple and efficient FFI to XEmacs. Many things that are currently coded in C for the sole reason of needing to interface to C libraries (such as LDAP) can be written as modules. Such use of modules has a chance of being cleanly defined and not overly error-prone. I agree with you and Kyle that while having TTY/X/stream/... support modularized in this fashion has a high coolness factor, it is probably not all that useful in practice. However, even if we don't use the modules in the standard distribution at all, I think that having the *ability* to dynamically load object files into a running XEmacs is a great thing from the developers' perspective. Even if *we* don't know what to do with the modules, we give the ability to others who might have a use for them. And this is a Good Thing. I congratulate J. Kean Johnston on the modules code, which looks like high-quality stuff to me.

4 participants
4 comments

Re: Using CVS 26 years, 2 months

Christoph Wedler

>>>>>"AB" == Alastair Burt <burt(a)dfki.de> writes: AB> Could someone also please tell me the tricks I need to get Mule and AB> non-Mule versions of XEmacs to be installed in the same tree without the AB> DOC files clashing. ;; both XEmacs/no-Mule and XEmacs/Mule: ;; (1) ./configure ... '--with-mule'; make ;; (2) mv src/xemacs src/xemacs-mule ;; mv lib-src/DOC lib-src/DOC-mule ;; (3) ./configure ...; make (and (featurep 'mule) (file-readable-p (expand-file-name "DOC-mule" doc-directory)) (setq internal-doc-file-name "DOC-mule")) - Christoph

1 participants
0 comments

Re: rssh.el interactions with ange-ftp/efs 26 years, 2 months

Alan Shutko

>>>>> "D" == David Maslen <david(a)binary.net.au> writes: D> IF, the URL syntax had been available I would have tried it because D> I regognised it. It would have worked. FWIW, whenever I've tried using ~ or ~ats in netscape for ftp, it doesn't work. Just checked... doesn't work. It still would have been frustrating.... -- Alan Shutko <ats(a)acm.org> - By consent of the corrupted "I am Juan Sanchez Villa Lobos Ramirez, and I'm at your service."

1 participants
0 comments

Re: rssh.el interactions with ange-ftp/efs 26 years, 2 months

David Maslen

Just like to say, I would be pleased if you addopt some form or URL syntax for EFS. I find xemacs quite obscure until you stumble across something someone says; example. I wanted to edit my homepage on my ISP BSDi box. /david＠isp.com:/ followed by a tab, got me in, but at the root directory. I could find my home directory, because they have a complicated and changing setup. A email to support, got a 'sorry we don't support that' reply. IF, the URL syntax had been available I would have tried it because I regognised it. It would have worked. Instead I had to wait until reading your email today and adding it up. I'd been trying /david＠ftp.isp.com:/ /david＠ftp.isp.com:/~ So adding to the todo list would be great, and hopefully my little piece of user feedback might make you feel good about making such terific software available. -- Binary Bar - Australia's first free access internet bar/cafe/gallery. 243 Brunswick Street, Fitzroy, Melbourne, Australia. 3pm - 1am http://www.binary.net.au/ Running on Debian/GNU Linux

1 participants
0 comments

Re: Beware of modules. 26 years, 2 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Olivier Galibert <galibert(a)pobox.com> writes: > > > Do you realize that if external third party C modules become the > > rule, we can't change anything to the Mule implementation or the > > lisp system? That we couldn't have ported to win32? That the "gung > > ho" changes would have been impossible to make? > > I don't think we need to worry about binary compatibility at all. It's > clear that, given the current state of affairs, it is impossible to > maintain anything close to that. > > As for the source compatibility, the only sane way of handling modules > I can think of is to define and document a *minimum* set of primitives > that are allowed in modules. But not even these should be cast in > stone, I think -- modules are pretty much meddling with the > implementation (more convenient meddling, but still meddling), and we > should always have a right to change it. Even if we do not move some things out into loadable modules, I think it would be nice to restructure a lot of the source code for the next major release (after 21.2, whatever that may be) so that things are a little more isolated. Move stuff into (redisplay|event)/(x11|win32|tty) type of thing. This way, if someone steps up to `take over' officially maintaining a piece of code, it can be clear who owns what, and can make it easier for someone to drop in a complete new code drop into CVS. Having everything in src/ bugs me. I tend to go the opposite extreme. Our product at aventail is spread over gobs of directories. Our autoconf script spits out 82 whole makefiles, 5 fragments, and a couple of support scripts. :) -Bill P.

2 participants
1 comments

Re: rssh.el interactions with ange-ftp/efs 26 years, 2 months

Sandy Rutherford

>>>>> On Fri, 15 Jan 1999 15:37:33 -0800, >>>>> bill(a)carpenter.ORG (WJCarpenter) said: > Again, see RFC-1738. I don't know what Netscape needs, but the "~/" > in the above example is redundant (or might not even work) against > some servers. Do all servers support "CWD ~"? No, but that's irrelevant anyway. EFS does all file name expansions itself and talks to the server using only full path names. It defines "~" to expand to whatever the server returned to pwd immediately after connecting. This is part of the reason why a pwd is always executed right after connecting. The other reason is to get the first piece of information about the remote system type. SYST is often not supported and sometimes lies. > What you get is more close to what you'd expect. You know, as if the > people who wrote RFC-1738 were also FTP users. You log onto the > remote system using the user name and password. The first "/" is just > a delimiter telling you where the hostname stops. Things after that > are what you'd feed to FTP CWD (or "cd" in most ftp client > implementations). If you need to use a literal slash, it has to be > encoded using the usual URL encoding rules. > So, the answer to your original question is that there isn't a special > syntax for things relative to your remote home directory. That's the > more or less default view. You could consider it to be a special > syntax to access absolute pathnames (you put a "%2f" where you'd > expect the root "/" to be). Yuck! This is horrible syntax. I frequently use EFS to edit files as root on the local host. In fact, since the null string for the hostname defaults to the local host, then a quick edit of /etc/hosts can be accomplished by editing /root＠:/etc/hosts. The RFC 1738 syntax that you describe above would turn this into a mess. ...Sandy

1 participants
0 comments

Anyone actually used the new modules stuff yet? 26 years, 2 months

Mike McEwan

love the ability to speed up those labour intensive tasks that remind me of lisp's interpreted nature. Some small niggles that I had though: Why is `-ldl' not being included in the link time libraries? For some reason (I'm on a i586) configure does not seem to pass its tests for `dlopen', `dlerror' etc. - is `-ldl' missing when these tests are conducted? Consequently it was very hard to work out why a compiled version of the supplied `sample.c' was not loading properly - `dll_error' was simply returning: "Shared library error" ...not very illuminating. It was only after manually updating Makefile.in to turn on HAVE_DLOPEN, HAVE_DLERROR and rebuilding that I was able to discover via dlerror that my xemacs had not been linked with `Wl,-E' (or should this be a -shared compile time flag?), mentioned in earlier posts to this list, and so symbols internal to my xemacs executable were not visible to dynamically loaded modules. The other small niggle is the lack of `＠'s in the example makefile which results in `$＠' been resolved to `$' after makeinfo. This had me flummoxed for a good few minutes :-). I hope someone can figure out what's up with `configure' - my knowledge of m4, autoconf isn't yet up to the such complex scripts that come with xemacs. -- Mike.

1 participants
0 comments

Re: rssh.el interactions with ange-ftp/efs 26 years, 2 months

WJCarpenter

>>> OK, it's been some years since I have had the time to stay up to >>> date with these things. How does it handle relative remote paths? >>> Is there a special syntax for filenames in my remote home >>> directory? Without this, editing remote files would still be a >>> pain. >> Unfortuantely, no, but the answer is fairly obvious: >> ftp://user:password＠host/~/filename (should hit the location where >> ftp starts, which will be your home directory). Again, see RFC-1738. I don't know what Netscape needs, but the "~/" in the above example is redundant (or might not even work) against some servers. Do all servers support "CWD ~"? What you get is more close to what you'd expect. You know, as if the people who wrote RFC-1738 were also FTP users. You log onto the remote system using the user name and password. The first "/" is just a delimiter telling you where the hostname stops. Things after that are what you'd feed to FTP CWD (or "cd" in most ftp client implementations). If you need to use a literal slash, it has to be encoded using the usual URL encoding rules. So, the answer to your original question is that there isn't a special syntax for things relative to your remote home directory. That's the more or less default view. You could consider it to be a special syntax to access absolute pathnames (you put a "%2f" where you'd expect the root "/" to be). -- bill(a)carpenter.ORG (WJCarpenter) PGP bill(a)bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3

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