June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: LDAP support enhancements... (XEmacs) 26 years

Didier Verna

wmperry(a)aventail.com (William M. Perry) writes: > I think being able to add an arbitrary file descriptor to the event loop > would be really useful. We could get rid of the select_process() cruft in > the event loop and just use the generic interface. You're damn right, man! -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: [PATCH] `LDAP' as opaque data type 26 years

William M. Perry

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > >>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: > > >> [...] My patch is a little more extensive than yours and handles > the errors in > >> compliance with the current IETF draft-ietf-ldapext-ldap-c-api-02. > >> Furthermore if I read it well, yours should fail if you use > libraries > >> without liblber. > > William> Are there any such? > > Netscape's Directory SDK on Solaris at least. Uhhh, the 3.0 SDK (the one that is publicly available) comes with liblber - I link against it every day. :) What version are you using? -Bill P.

1 participants
0 comments

Re: LDAP support enhancements... (XEmacs) 26 years

William M. Perry

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > >>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: > > William> I think we could pretty easily do _really_ asynchronous > searches. We can > William> actually get the socket out of the LDAP library by using > > William> #ifdef HAVE_LDAP_GET_OPTION > William> LBER_SOCKET fd; > > William> if (ldap_get_option(ld,LDAP_OPT_DESC,&fd) != LDAP_SUCCESS) > William> { > William> /* Could not get the descriptor, bail */ > William> return(-1); > William> } > William> #else > William> int fd = ld->ld_sb.sb_sd; > William> #endif > > William> /* Somehow add the socket to the list of fd's the event loop > is > William> ** waiting on. If the event loop sees the FD as getting > data, > William> ** go into a do { } while (1) loop calling ldap_result() with > a > William> ** 0-second timeout. > William> ** > William> ** If we get a '0' back indicating a timeout, we must have > William> ** gotten only a partial result back, and there are no more > records to be > William> ** read, so break out of the loop and handle the rest of the > events. > William> ** > William> ** Otherwise, we got a result back, call a callback function > that > William> ** just gets a single LDAP record, and continue through the > loop. > William> */ > > William> This would be really nice, I think. We'd just have to add an > William> 'event-stream-select-fd' that would be really close to the > existing > William> event-stream-select-process > > William> -Bill P. > > Sounds nice but to tell the truth I've never experienced a situation > where I wished we had that feature so I really don't know if it's worth > the effort given the sensitivity of the code we need to plug into. But > if you feel it's important then definitely go for it, I am sure I will be > happy to use it in the end. Oh, being stud-monkey-asynchronous is really very nice. :) I would use this for Emacs/W3 and it's ldap support. The LDAP 'asynchronous' API really sucks and should be renamed to 'polling' - this could make it really asynchronous. I think being able to add an arbitrary file descriptor to the event loop would be really useful. We could get rid of the select_process() cruft in the event loop and just use the generic interface. -Bill P.

1 participants
0 comments

NT makefiles broken? [was Re: colourless xemacs on NT :-(] 26 years

Jan Vroonhof

Norbert Koch <n.koch(a)delta-ii.de> writes: > When I started xemacs -vanilla and loaded the custom library it told > me cus-edit.el was newer - and bingo, the cusXXX.el files all have > been newer than the respective byte-compiled files. After > byte-compiling them and a restart, everything looks Ok now, phew! > > Now, I don't know why the files haven't been updated. Perhaps, there's > a problem during the make process? Dimitri had exactly the same problems! Is there some bug in the NT make files so that dependencies do get tracked properly? JAn

1 participants
0 comments

NT makefiles broken? [was Re: colourless xemacs on NT :-(] 26 years

Jan Vroonhof

Norbert Koch <n.koch(a)delta-ii.de> writes: > When I started xemacs -vanilla and loaded the custom library it told > me cus-edit.el was newer - and bingo, the cusXXX.el files all have > been newer than the respective byte-compiled files. After > byte-compiling them and a restart, everything looks Ok now, phew! > > Now, I don't know why the files haven't been updated. Perhaps, there's > a problem during the make process? Dimitri had exactly the same problems! Is there some bug in the NT make files so that dependencies do get tracked properly? JAn

1 participants
0 comments

Re: sample.emacs to break custom-set-face in 21.2b16 under native NT 26 years

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > (custom-set-faces > '(font-lock-comment-face ((t (:foreground "forest green" :bold t)))) > '(font-lock-doc-string-face ((t (:foreground "brown" :bold nil))))) > > fail to work. Please give the values of the relevant specifiers. > Colors are OK, but they are rendered italic given > (copy-face 'italic 'font-lock-comment-face) that seems correct. The patch changes the definition of the customize specs to merge its explicit properties with the other settings. For most properties that seems like the correct thing to do and gets rid off all kinds of ugly problems. > and I cannot correct them > via custom. This however seems like a bug. You should be able to check [x] italic and with a setting to off to force a non-intalic face). Could you try calling (make-face-unitalic font-lock-comment-face tags '(custom)) and if that does not work: (make-face-unitalic font-lock-comment-face tags) and may be single step through them to where they don't give the right result. -- 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: colourless xemacs on NT :-( 26 years

Norbert Koch

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > nothing as far as I can see. > > What happens if you give the color some definition by using > set-face-foreground and _then_ use customize to modify it? Hi Jan! To be frank, I don't care any longer, because - it works now :-) When I started xemacs -vanilla and loaded the custom library it told me cus-edit.el was newer - and bingo, the cusXXX.el files all have been newer than the respective byte-compiled files. After byte-compiling them and a restart, everything looks Ok now, phew! Now, I don't know why the files haven't been updated. Perhaps, there's a problem during the make process? Cheers, norbert, colourised again :-)

1 participants
0 comments

[Failure] XEmacs 21.1.2 "2", 20 Minutes to Nikko 26 years

Adrian Aichner

Updated from CVS. Fails building under native NT. Adrian > XEmacs Build Report as generated with > M-x build-report RET > by build-report-version $Revision: 1.1.1.1 $ follows: > Contents of e:\export\home\tmp\21.0\xemacs\nt\Installation: > (Output from most recent run of ./configure) OS: Windows_NT XEmacs 21.1.2 \"20 Minutes to Nikko\" configured for `i386-pc-win32'. Where should the build process find the source code? e:\\export\\home\\tmp\\21.0\\xemacs\\nt What compiler should XEmacs be built with? ＠cl -nologo What window system should XEmacs use? MS Windows > Contents of e:\export\home\tmp\21.0\xemacs\nt\xemacs-make-install.err > keeping lines matching > "^--\[\[\|\]\]$\|^$cd\|n?make$\s-\|errors?\|warnings?\|pure.*$space\|size$\|hides\b\|strange\|shadowings\|^Compil$ing\s-+in\|ation$\|^Using\|not\s-+found\|^While\s-+compiling.*$ \s-+.+$*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" > and then deleting lines matching > "confl.*with.*auto-inlining" cd e:\export\home\tmp\21.0\xemacs\nt\ nmake /f xemacs.mak HAVE_XPM="1" HAVE_PNG="1" HAVE_TIFF="1" HAVE_JPEG="1" USE_UNION_TYPE="1" COMPFACE_DIR="e:\\export\\home\\tmp\\libs4xemacs\\compface" JPEG_DIR="e:\\export\\home\\tmp\\libs4xemacs\\jpeg-6b" TIFF_DIR="e:\\export\\home\\tmp\\libs4xemacs\\tiff-v3.4" ZLIB_DIR="e:\\export\\home\\tmp\\libs4xemacs\\zlib" PNG_DIR="e:\\export\\home\\tmp\\libs4xemacs\\libpng-1.0.2" XPM_DIR="e:\\export\\home\\tmp\\libs4xemacs\\xpm-3.4k" install Compilation started at Mon Jun 14 10:26:36 1999 Compiling in support for native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for TIFF images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for native sounds. Compiling in fast dired implementation. Using union type for Lisp object storage. 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. copy puresize-adjust.h ..\src 1 file(s) copied. ..\nt\runemacs.c(39) : warning C4101: 'sec_desc' : unreferenced local variable ..\src\glyphs-msw.c(1589) : warning C4146: unary minus operator applied to unsigned type, result still unsigned E:\Program Files\Microsoft Visual Studio\VC98\include\direct.h(132) : warning C4030: first formal parameter list longer than the second list ..\src\gif_io.c(118) : warning C4013: 'close' undefined; assuming extern returning int ..\src\editfns.c(858) : warning C4013: 'getcwd' undefined; assuming extern returning int ..\src\editfns.c(858) : warning C4047: '=' : 'char *' differs in levels of indirection from 'int ' ..\src\filemode.c(82) : warning C4761: integral size mismatch in argument; conversion supplied ..\src\filemode.c(83) : warning C4761: integral size mismatch in argument; conversion supplied ..\src\filemode.c(84) : warning C4761: integral size mismatch in argument; conversion supplied ..\src\keymap.c(2086) : warning C4244: '=' : conversion from 'long ' to 'unsigned char ', possible loss of data ..\src\line-number.c(297) : warning C4146: unary minus operator applied to unsigned type, result still unsigned ..\src\nt.c(1660) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(int )' ..\src\nt.c(1813) : warning C4715: 'msw_raise' : not all control paths return a value ..\src\ntproc.c(887) : warning C4028: formal parameter 2 different from declaration ..\src\unexnt.c(552) : warning C4101: 'bss_data' : unreferenced local variable ntproc.obj : error LNK2001: unresolved external symbol _GET_C_STRING_FILENAME_DATA_ALLOCA ..\src\temacs.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Compilation exited abnormally with code 2 at Mon Jun 14 10:35:23 -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

2 participants
1 comments

Re: sample.emacs to break custom-set-face in 21.2b16 under native NT 26 years

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> I noticed in 21.2b16 that my APA> (custom-set-faces APA> '(font-lock-comment-face ((t (:foreground "forest green" :bold t)))) APA> '(font-lock-doc-string-face ((t (:foreground "brown" :bold nil))))) APA> fail to work. APA> Colors are OK, but they are rendered italic and I cannot correct them APA> via custom. As a workaround, (custom-set-face-bold 'font-lock-comment-face t) will in fact make the face bold, which cannot currently be done via M-x customize-face RET font-lock-comment-face RET under the circumstances. Adrian APA> Turns out, these lines from sample.emacs: APA> (copy-face 'italic 'font-lock-comment-face) APA> (copy-face 'font-lock-comment-face 'font-lock-doc-string-face) APA> cause the problem. APA> I have no idea where the breakage happened but I'm pretty sure someone APA> will. APA> Does sample.emacs need adjustment? APA> Is (copy-face ...) broken? APA> Is (custom-set-face ...) broken? APA> Regards, APA> Adrian APA> -- APA> Adrian Aichner Teradyne GmbH, European Design Center APA> Integra Test Division Telephone +49/89/41861(0)-208 APA> Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) APA> D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: colourless xemacs on NT :-( 26 years

Norbert Koch

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: Hi Adrian, > shows correct face colors for me. Some face properties seem wrong > though. > My font-lock-comment-face is rendered italic instead of bold (which I > have set via custom. Huh? Strange. > What do you see when you: > > runxemacs -vanilla > M-x find-library RET simple RET > M-x font-lock-mode RET > > Do you get colors again? In the customisation buffer some of the colours are displayed correctly, although not all of them. No difference in any other buffer. > Using Options->Edit Faces... > Is face "Bold" rendered in bold-face? > Is face "Italic" rendered in italic? Yep, those are rendered correctly. Also, bold-italic looks the way I'd like to have it. > All this works for me. Lucky you ;-) Ok, one other difference is my usage of Mule, but I don't think this causes these troubles ... XEmacs 21.2 (beta16) "Sumida" [Lucid] (i586-pc-win32, Mule) of Mon Jun 14 1999 on KEATS What font do you use, btw? I don't have any choice but the default Courier New:Regular:10::Western Should't the font selection work by now (but, probably, there's a difference between NT 4.0 and NT 2000 which I use?) 'norbert.

2 participants
1 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 June 1999