November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > cl.el is smarter than you think. I really have to read the documentation. But can I switch the safety of just for the inner-loops? > > > I would love to be proven wrong though. > > Good enough? :-) Yes. But this time I would love to have Kyle's permission first. Jan

1 participants
0 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 25 years

William M. Perry

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > >>>>> "Ben" == Ben Wing <ben(a)666.com> writes: > > Ben> Again, please please follow standard conventions. The lower-level > Ben> functions should be called ldap-add, ldap-delete, etc. (Or even > Ben> better, use ldap-put, ldap-remove.) No -internal, -basic-, -1, > Ben> whatever. These are parallel to the database routines. > > Ben> I'm still not completely convinced we need convenience wrappers. > Ben> The db interface doesn't have them, for example. > > IIRC someone said on that list nobody actually uses the db interface. But I was proved wrong. :) > That might explain why we don't need those wrappers. LDAP on the other > hand is already used by three packages. > > Ben> If you want them, though, call them something like > Ben> create-ldap-entry, or similar names -- i.e. longer, to convey that > Ben> they do more than you might expect. > > Though I'm not convinced this renaming is good, I'll send the > corresponding patch, you probably know better than I what's good for > XEmacs. I still think someone used to LDAP will find its way more easily > through the current high-level API which reminds the traditional LDAP > command-line tools rather than through the naming you propose. Someone > not used to LDAP won't care that much. I would agree that your high-level interface is akin to the command line tools, and the ldap-*-internal routines are much closer to the actual C LDAP API. And since we are using a 'real' programming language (just assume for the moment :) we should encourage using the API-level functions, which is what most LDAP programmers will be used to. I'd say there are a lot less people writing shell scripts around the 'ldapmodify' and 'ldapsearch' commandline tools, especially since there are 'real' Perl modules for ldap, etc. -Bill P.

1 participants
0 comments

Re: itimer rewrite 25 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Ben Wing <ben(a)666.com> writes: > > > Could you possibly rewrite this a bit so as to use defstruct? cl is > > now a standard part of XEmacs so there's absolutely no point in > > continuing to use vectors for structs. > > I thought about that. But if I interpret the defstruct macro > correctly that generates functions that cannot be inlined and do > redundant type checks. They can and they don't. Accessors like `person-name' normally check their arguments (effectively using `person-p') and signal an error if the argument is the wrong type. This check is affected by `(optimize (safety ...))' declarations. Safety level 1, the default, uses a somewhat optimized check that will detect all incorrect arguments, but may use an uninformative error message (e.g., "expected a vector" instead of "expected a `person'"). Safety level 0 omits all checks except as provided by the underlying `aref' call; safety levels 2 and 3 do rigorous checking that will always print a descriptive error message for incorrect inputs. Test it like this. Create a file, say x.el, with the following contents: (proclaim '(optimize (speed 3) (safety 0))) (defstruct (foo) (bar nil) (count 0)) (defun test (x) (foo-count x)) Byte-compile it and load-file x.elc. Then try: (disassemble 'test) byte code for test: args: (x) 0 varref x 1 constant 2 2 aref 3 return So foo-count is inlined and there are no safety checks. Note that #'foo-count is still a regular function, not a macro, meaning you can feed it to #'mapcar etc. But when you *compile* the stuff, the CL additions to the compiler do the right thing. cl.el is smarter than you think. > I would love to be proven wrong though. Good enough? :-)

1 participants
0 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 25 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Ben Wing <ben(a)666.com> writes: > > > Again, please please follow standard conventions. > > Huh? The standard convention is to use -internal for C level > functions that are not supposed to be used directly. But if I understand Oscar correctly, the users who want the lower-level functionality *are* supposed to use the C functions. So they shouldn't be called "-internal". The -internal stuff is something you *never* ought to want to use.

1 participants
0 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 25 years

William M. Perry

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Ben Wing <ben(a)666.com> writes: > > > Again, please please follow standard conventions. > > Huh? The standard convention is to use -internal for C level functions > that are not supposed to be used directly. But these SHOULD be used directly in certain circumstances (long-lived LDAP connections, multiple operations (like search, add, modify, etc). -bp

1 participants
0 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 25 years

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > Again, please please follow standard conventions. Huh? The standard convention is to use -internal for C level functions that are not supposed to be used directly. I still cannot see your point. Jan

1 participants
0 comments

Re: itimer rewrite 25 years

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > Could you possibly rewrite this a bit so as to use defstruct? cl is > now a standard part of XEmacs so there's absolutely no point in > continuing to use vectors for structs. I thought about that. But if I interpret the defstruct macro correctly that generates functions that cannot be inlined and do redundant type checks. I don't want those in the inner loop. I would love to be proven wrong though. Jan

1 participants
0 comments

Re: Martin makes man & Makefile makeover 25 years

Adrian Aichner

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Hi Martin! Martin> xemacs.mak uses the built-in lisp formatter texinfmt.el, Martin> not makeinfo. I sure know because I put it in and made it work! :-) I added external makeinfo support in following patch to xemacs-patches. > From: Adrian Aichner <aichner(a)ecf.teradyne.com> > Subject: 21.2 xemacs.mak: generate info with texinfo package or makeinfo.exe > To: xemacs-patches(a)xemacs.org > Date: 19 Nov 1999 03:20:10 +0100 > References: <14384.56980.560513.767776(a)lasker.666.com> > <uu2mkoeeb.fsf(a)ecf.teradyne.com> > <14387.43590.807635.654577(a)lasker.666.com> > Message-ID: <u3du3dxyd.fsf(a)ecf.teradyne.com> Hacked on the texinfo package a while back too to make this work. Martin> For the record, even the texinfmt.el in a 20.5 GNU Emacs Martin> pretest fails with info.texi in the same manner. So Martin> currently texinfmt.el is broken for processing standard Martin> info files. Someone could take on the project of syncing Martin> the texinfo stuff from GNU Emacs 20.5 (release should be Martin> imminent) and then fixing it so that all of the info files Martin> can be formatted by it. Well, I have run all your texi files past c:\temp\texinfo-3.12\makeinfo\makeinfo.exe. See my previous mails for what fails. I may take a look at them. As it stands now, it is not true that all texi files are conformant to texinfo-3.12. Best regards, Adrian Martin> Martin

1 participants
0 comments

Re: Martin makes man & Makefile makeover 25 years

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> - Make sources compatible with makeinfo 4.0 *and* 3.12. APA> Hello Martin, APA> trying to generate info.info using texinfo-3.12 on Windows NT I get APA> this error: Hi Martin, All files process fine with texinfo-4.0 on Windows NT: cd d:\tmp\21.2\xemacs\nt\ d:\tmp\texinfo-4.0\makeinfo\makeinfo.exe --version Compilation started at Fri Nov 19 01:35:29 1999 +0100 (W. Europe Standard Time) makeinfo (GNU texinfo) 4.0 Copyright (C) 1999 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. Compilation finished at Fri Nov 19 01:35:29 So obviously, contrary to what the ChangeLog says, not all texi files are compliant with makeinfo 1.68 after your patch. Adrian APA> cd d:\tmp\21.2\xemacs\man\ d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe APA> info.texi Compilation started at Thu Nov 18 10:55:16 1999 +0100 APA> (W. Europe Standard Time) Making info file `../info/info.info' from APA> `info.texi'. info.texi:69: No matching `＠end ifnottex'. APA> info.texi:77: Unmatched `＠end'. makeinfo.exe: Removing output file APA> `../info/info.info' due to errors; use --force to preserve. APA> Compilation exited abnormally with code 2 at Thu Nov 18 10:55:18 APA> What do you make of this? APA> Can you generate .info files for all .texi files in the latest 21.2 CVS APA> sources using APA> cd c:\XEmacs\xemacs-packages\etc\psgml\ APA> d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe --version APA> Compilation started at Thu Nov 18 11:28:48 1999 +0100 (W. Europe Standard Time) APA> makeinfo (GNU texinfo 3.12) 1.68 APA> Copyright (C) 1998 Free Software Foundation, Inc. APA> There is NO warranty. You may redistribute this software APA> under the terms of the GNU General Public License. APA> For more information about these matters, see the files named COPYING. APA> Compilation finished at Thu Nov 18 11:28:48 APA> ? APA> Best regards, APA> Adrian

2 participants
1 comments

Re: Any objections against xemacs/*/xemacs.mak files in 21.2? 25 years

Adrian Aichner

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> I say, put all the nt makefiles in the proper directories, Ben> not in nt. Windows is not a second-class citizen Ben> w.r.t. xemacs. Hurrah! How about a suggestion by Paul Krause <pkrause(a)ibelong.com> to rename xemacs.mak to someting meaningful? I'd suggest "windows.mak" as the name for a native windows makefile for NMAKE (MS's make, ahem, "invention"), regardless of where it is in the xemacs source tree. The question remains whether it will be able to handle NT, 95, 98 always. The xemacs95.mak of 21.1 is gone in 21.2 so it seems feasible. TIA for any suggestions, Adrian

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