October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: hashtable-based marking and cleanups 24 years, 11 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > Yes, it does matter. It is usually allocated at the end of the > memory, and since the gc only frees memory, if your malloc is any > decent, the virtual space is given back to the system when the final > free is done. It somehow seems perverse to allocate almost as much memory as you are using for the process of freeing up... Jan

1 participants
0 comments

Re: 21.2.19 crash in ldap on Solaris 2.7 24 years, 11 months

Oscar Figueiredo

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Raymond> The manpage for ldap_open gives an example for the elements of struct Raymond> ldap, but I can't find that in any include file. Oscar> I second that. In its current state, Sun's LDAP Oscar> implementation seems to be fairly unusable : manpages and Oscar> header files are inconsistent and ldap.h doesn't provide Oscar> neither a definition of struct ldap nor a prototype for Oscar> ldap_set_option. Raymond> I took a look at ldap.h in the UMICH version. The struct ldap looks Raymond> very, very much like the example code in Sun's ldap_open manpage. Raymond> Maybe it's the same. :-) It's certainly the same (most LDAP implementations derive from the UMich distribution, Sun's is no exception, see the copyright statement at the top of ldap.h) but we cannot make any assumptions based on this. Raymond> Maybe we should just not do auto-detect of ldap on Solaris 2.7, and Raymond> add yet another option to configure to use ldap explicitly. This could be a solution. The switch --with-ldap already exists. If I don't find a solution to identify precisely Sun's implementation I think I will disable auto-detection for Solaris 2.7 Raymond> Or punt and just put it in the Problems file and tell people to get Raymond> the some other ldap library. Raymond> (BTW, has anyone successfully used Netscape's implementation? I tried Raymond> it once, didn't get it to work, and used the UMICH version, which, Raymond> obviously, works.) I did some builds and a few searches with it. It's supposed to work, problems with it should be reported. Oscar

1 participants
0 comments

zero padding bug in format 21.1 & 21.2 24 years, 11 months

SL Baur

[Report forwarded from Morioka Tomohiko] $ xemacs -vanilla => (format "%05d" 1) "00001" => (format "%05d" -1) "000-1"

1 participants
0 comments

markobj, markedp 24 years, 11 months

Olivier Galibert

Is there any fundamental reason to pass pointers to these functions around everywhere instead of calling them directly? If not, I'm going to remove them, since I'm already in the process of removing a bunch of GC-related cruft (the GC_* macros). It would make the gc unnoticably faster, too. OG.

2 participants
1 comments

Re: hashtable-based marking and cleanups 24 years, 11 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: [I have no time to compile with the patch at the moment, sorry] > I'm very interessed to know whether people feels a slowdown with this > patch. My current computer is too powerful to notice. Do you have an infinite amount of memory too? +/* An estimation (not the exact number) of the number of currently existing l(c)rcords */ +static int object_count; + [..] + quickhash_init (object_count*4); Unless I am going mad the memory overhead is now 4+1 words per object, i.e. 125% (only during the sweep, but does that matter?). I don't think you can really say much about the speed of the GC unless you use one which actually space efficient (and thus has to do more shifts & masks). If you don't want to do the pool thing just yet: What about using a "conservative" garbage collector in the sense that you marked the hash(address)'ed bit in a bit array of size object_count*4. This reduces the sweep array to 4 bits per object, or <6.3%. This doesn't free all free objects (i.e. those that hash to the same value as a referenced object), but by slightly varying the hash function from sweep to sweep (introducing a bit of pseudo-randomness) most of them will be freed later. Does somebody have numbers on the expected ratio of hash clashes for varying hash sizes handy? Well.. Maybe doing the pools is just as easy... Jan P.S. I just spent waaaaaaayyyyy to much time debugging the 21.1.7 unexec problems on Linux, so AFAIC the portable dumper stays whatever the overhead.

3 participants
2 comments

Re: (call-process ...) to return correct exit-status on NT 24 years, 11 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> A Weak Spot: APA> When OpenProcess() returns an invalid process handle I fake a signal APA> termination signal. APA> synch_process_death = signal_name (SIGTERM); APA> This is nothing than a wild guess, but better than setting APA> synch_process_retcode = status; APA> I have tested this using external cygnus executables "sleep" and APA> "grep" as follows. APA> Patch against latest CVS source of 21.2-b19 is at end. I have successfully applied this patch to 21.1.7 as well (with an offset of some 300 lines). Below test-cases all work fine. I am going to send a formal patch soon, unless there are any serious objections. Best regards, Adrian APA> ;;; Sleeping for 3 seconds, then returns 0. APA> (apply 'call-process "sleep" nil nil nil (list "3")) APA> 0 APA> ;;; Trying to sleep for 30 seconds, but killed via Windows NT Task APA> ;;; Manager. APA> (apply 'call-process "sleep" nil nil nil (list "30")) APA> "software termination signal from kill" APA> ;;; Looking for drivers in sysem file succeeds, returning 0. APA> (apply 'call-process "grep" nil nil nil APA> (list "drivers" "c:\\winnt\\system.ini")) APA> 0 APA> ;;; Looking for passangers in sysem file fails, returning 1. APA> (apply 'call-process "grep" nil nil nil APA> (list "passangers" "c:\\winnt\\system.ini")) APA> 1 APA> ;;; Looking for drivers in invalid file fails, returning 2. APA> (apply 'call-process "grep" nil nil nil APA> (list "drivers" "c:\winnt\system.ini")) APA> 2

1 participants
0 comments

Re: 21.2.19 crash in ldap on Solaris 2.7 24 years, 11 months

Raymond Toy

>>>>> "Oscar" == Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: >>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Raymond> The manpage for ldap_open gives an example for the elements of struct Raymond> ldap, but I can't find that in any include file. Oscar> I second that. In its current state, Sun's LDAP Oscar> implementation seems to be fairly unusable : manpages and Oscar> header files are inconsistent and ldap.h doesn't provide Oscar> neither a definition of struct ldap nor a prototype for Oscar> ldap_set_option. I took a look at ldap.h in the UMICH version. The struct ldap looks very, very much like the example code in Sun's ldap_open manpage. Maybe it's the same. :-) Raymond> Oh well, if this is true, I think we'll have to put something in Raymond> configure so that we DON'T use Sun's ldap on Solaris 2.7. (I hope I Raymond> didn't miss anything.) Oscar> I fear this is going to be really difficult: I must find Oscar> some sure way of identifying this particular Oscar> implementation. I'll give it a look. Maybe we should just not do auto-detect of ldap on Solaris 2.7, and add yet another option to configure to use ldap explicitly. Or punt and just put it in the Problems file and tell people to get the some other ldap library. (BTW, has anyone successfully used Netscape's implementation? I tried it once, didn't get it to work, and used the UMICH version, which, obviously, works.) Ray

1 participants
0 comments

Re: [SGI, Linux, Urgent, 21.1] Fix broken dumping on Linux machines 24 years, 11 months

Vin Shelton

>>>>> On 12 Oct 1999, Jan Vroonhof <vroonhof(a)math.ethz.ch> said: Jan> The merge in of IRIX < 6 dumping in unexec.c brakes dumping on Jan> Linux i86 in subtle ways. This patch has been confirmed to fix Jan> it. It would be nice if other architectures using unexelf.c could Jan> test this. Jan> Otherwise this needs to go in a 21.1.8 very soon. Please explain this. I build on a Linux x86 box. What problems are you seeing? - vin

1 participants
0 comments

Re: 21.2.19 crash in ldap on Solaris 2.7 24 years, 11 months

Oscar Figueiredo

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Oscar> First check the manpages. If you don't find anything about Oscar> ldap_set_option then you can try to undefine Oscar> HAVE_LDAP_SET_OPTION in the file eldap.c and recompile it. Raymond> I'll try this in a few minutes. Raymond> This doesn't work. gcc complains that I'm dereferencing a pointer to Raymond> an incomplete type on lines 319 of eldap.c. This is true. I can't, Raymond> for the life of me, actually find out where struct ldap is really Raymond> defined. The only hint is in /usr/include/ldap.h where a comment says Raymond> LDAP is the opaque connection type. No kidding! Raymond> The manpage for ldap_open gives an example for the elements of struct Raymond> ldap, but I can't find that in any include file. I second that. In its current state, Sun's LDAP implementation seems to be fairly unusable : manpages and header files are inconsistent and ldap.h doesn't provide neither a definition of struct ldap nor a prototype for ldap_set_option. Sigh... Raymond> Oh well, if this is true, I think we'll have to put something in Raymond> configure so that we DON'T use Sun's ldap on Solaris 2.7. (I hope I Raymond> didn't miss anything.) I fear this is going to be really difficult: I must find some sure way of identifying this particular implementation. I'll give it a look. Oscar

1 participants
0 comments

Re: 21.2.19 crash in ldap on Solaris 2.7 24 years, 11 months

Raymond Toy

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Oscar> First check the manpages. If you don't find anything about Oscar> ldap_set_option then you can try to undefine Oscar> HAVE_LDAP_SET_OPTION in the file eldap.c and recompile it. Raymond> I'll try this in a few minutes. This doesn't work. gcc complains that I'm dereferencing a pointer to an incomplete type on lines 319 of eldap.c. This is true. I can't, for the life of me, actually find out where struct ldap is really defined. The only hint is in /usr/include/ldap.h where a comment says LDAP is the opaque connection type. No kidding! The manpage for ldap_open gives an example for the elements of struct ldap, but I can't find that in any include file. Oh well, if this is true, I think we'll have to put something in configure so that we DON'T use Sun's ldap on Solaris 2.7. (I hope I didn't miss anything.) Ray

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