python-ldap-dev — discussion among developers

TE INFORMAMOS

[COFOR<co...@wa...>]

Jacarilla 8.7.2001.Publicidad/Enseñanza a Distancia 
 
 
      Hola que tal:
 
      El motivo de la presente carta es informarte de la posibilidad de poder 
realizar algún curso a distancia de tu interés, cursos relacionados con tu 
trabajo inquietudes  y ocio.ect.El conocimiento es el mayor patrimonio de 
que podemos disponer.
 
      Nos dedicamos desde 1996.a impartir cursos a distancia disponemos 
de una amplia variedad de cursos sencillos  para poder seguirlos 
comodamente desde cualquier parte del mundo y a unos precios muy 
competitivos.
      
 
NET
------------
Comercio Electrónico
Redes y Sistemas
Sistemas Servers
Diseño Web
Direccion Empresa Net
Management  Business
 
BUSSINES
------------
Gestor Comercial y Marketing
Marketing Mix 
Relaciones Publicas
Dirección Planificación de Empresa
Recursos Humanos
Comercio Exterior
Direccion Comercial
Gestión Medio Ambiental
Control de Calidad
 Management  Bussines
Dirección de Restaurantes
----------------------------------
 
SALUD SUPERACION PERSONAL
-------------------------------------
Superación de Estrés
Psicoterapia
Dietética y Nutrición
Dieta Mediterránea 
Nutrí terapia y Salud
Nutrición y Deporte
Cocina Sana
Monitor Aeróbic-Fittnes
Monitor Yoga Tai-Chi
Hipnoterapia
Quiromasaje y Reflexoterapia
Aromaterapia
Cosmética Natural
Hierbas Medicinales
Balnoterapia y Salud
--------------------------------------
Los cursos  son de 200.horas lectivas el precio standar por curso es de 
35.000.pts.España a plazos.Iberoamerica 150.usa dolar aplazados.
El Diploma:
 "Técnico Especialista"
 El tiempo aproximado por curso dependiendo de los conocimientos en 
areas similares de que se disponga,es entre 2-6.meses.aprox.
 
Si desean que les ampliemos información pueden enviar un e-mail les 
contestaremos con la mayor brevedad y les indicaremos nuestro espacio 
web que se encuentra en reformas.
 
Envie e-mail:
      co...@wa...
     CO...@te... 
 
Sin otra que rogarte me envies un e-mail si estas interesado/a
Te enviamos un saludo.
 Merce Sanchez 
Gestión Integral 1.S.L
 C/ Virgen de Belén, 30
 03310 Jacarilla  (Alicante)ESPAÑA
 
Si desea no recibir mas  e-mail.  MA...@te...
                                                                                                                    
                                     

 
 
 
 
 
      

Re: compiling against OpenLDAP 2.0.11

[Konstantin C. <Kon...@da...>]

Hi David,

David Leonard wrote:

> this is good - commit it

I doubt I can do that: I'm not a python-ldap developer... :-)

>
> will the documentation need updating?
>

I'll prepare another patch for python-ldap/Doc/libldap.tex.

Regards,
    Konstantin.

>
> d
>
> ----- Original Message -----
> From: "Konstantin Chuguev" <Kon...@da...>
> To: <mi...@st...>
> Cc: <pyt...@li...>
> Sent: Tuesday, July 10, 2001 6:59 PM
> Subject: Re: compiling against OpenLDAP 2.0.11
>
> > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS
> > repository require a new version of patches. I've attached them.
> > The patches don't change the behaviour of python-ldap when compiled
> > against OpenLDAPv1, but create an alternative code when used with
> > OpenLDAPv2. Here are the differences between python-ldap compiled
> > against OpenLDAPv1 and v2 using the patches (seen from the point of view
> > of a programmer using python-ldap):
> >
> >    * new constants added for v2 (see constants.c.patch);
> >    * new errors/exceptions added for v2 (see errors.c.patch);
> >    * a set of LDAP session attributes changed:
> >         o only in v1: lberoptions (rw), refhoplimit (rw), options (rw),
> >           valid (ro);
> >         o only in v2: version (rw), referrals (rw), restart (rw);
> >         o in both versions: deref (rw), timelimit (rw), sizelimit (rw),
> >           errno (ro), error (ro), matched (ro).
> >    * new type of data added to the Python dictionary returned as a
> >      result of ldap_result:
> >      Dictionary keys are DNs, values are entry objects. If the key is
> >      empty, the value is the list of referrals (URL text strings).

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

Re: compiling against OpenLDAP 2.0.11

[Konstantin C. <Kon...@da...>]

Hi Michael,

Michael Ströder wrote:

> David was working to incorporate your patches but did not commit
> anything so far. The diffs based on your work he sent me does not
> seem to work with recent OpenLDAP 2.0.11. It seems to me that the

Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS
repository require a new version of patches. I've attached them.
The patches don't change the behaviour of python-ldap when compiled
against OpenLDAPv1, but create an alternative code when used with
OpenLDAPv2. Here are the differences between python-ldap compiled
against OpenLDAPv1 and v2 using the patches (seen from the point of view
of a programmer using python-ldap):

   * new constants added for v2 (see constants.c.patch);
   * new errors/exceptions added for v2 (see errors.c.patch);
   * a set of LDAP session attributes changed:
        o only in v1: lberoptions (rw), refhoplimit (rw), options (rw),
          valid (ro);
        o only in v2: version (rw), referrals (rw), restart (rw);
        o in both versions: deref (rw), timelimit (rw), sizelimit (rw),
          errno (ro), error (ro), matched (ro).
   * new type of data added to the Python dictionary returned as a
     result of ldap_result:
     Dictionary keys are DNs, values are entry objects. If the key is
     empty, the value is the list of referrals (URL text strings).

>
> OpenLDAP 2 API is still subject to minor changes (e.g.
> ldap_set_rebind_proc()). Unfortunately David is not available to

I haven't touched set_rebind_proc in python-ldap yet, because that would
change its API. At the moment you'll get a compile time warning and
possible crash if you use rebind_proc with python-ldap + OpenLDAPv2. It
is impossible to use the v1 set_rebind_proc syntax in v2. It is
theoretically possible to use the OpenLDAPv2 syntax of the function with
the OpenLDAPv1 library, using an internal conversion function. It would
require some programming and (needs your approval) a change to the
python-ldap API. Suggestions?

Regards,
    Konstantin.

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

Re: compiling against OpenLDAP 2.0.11

[Michael <mi...@st...>]

Konstantin,

nice to see you're back on list.

Konstantin Chuguev wrote:
> 
> I seem to have missed some changes in python-ldap that made it 
> incompatible with OpenLDAPv1.

Sorry, my fault probably related to a system upgrade. IMHO SuSE
changed something with the libs they're shipping and I had to
explicitly use -lresolv to solve my local build problem. See
http://python-ldap.sourceforge.net/faq.shtml, item 5.

David was working to incorporate your patches but did not commit
anything so far. The diffs based on your work he sent me does not
seem to work with recent OpenLDAP 2.0.11. It seems to me that the
OpenLDAP 2 API is still subject to minor changes (e.g.
ldap_set_rebind_proc()). Unfortunately David is not available to
work on this stuff for the next months.

Ciao, Michael.

Re: compiling against OpenLDAP 2.0.11

[Konstantin C. <Kon...@da...>]

Hi All,

Sorry, I've been doing completely different things last few months. I could
read the mailings from the list, but couldn't react. I re-started my work on
python-ldap patches in June, just few days before I went on holiday... Now I'm
back.

I seem to have missed some changes in python-ldap that made it incompatible
with OpenLDAPv1. I'm not quite sure about it. Am I right?
My patches (made against about a half year old CVSed python-ldap and CVSed
between v2.0.6 and 2.0.7 OpenLDAPv2) are not included into the current
python-ldap CVS, so I know it's not them that broke OpenLDAPv1 compatibility in
CVS.
If the patches do break compatibily when applied on their own, then well, blame
myself for it, not python-ldap developers :-)

Michael Ströder wrote:

> David Leonard wrote:
> >
> > the current status of the development tree seems to be:
> >         * supporting OpenLDAP 2.* (but dropping support for earlier
> >           versions)
>

Is it possible to keep support for both branches of OpenLDAP? I understand
Michael's concern about it. OpenLDAPv1 is still well developed version, it is
used by many people who don't need v2 functionality.

>
> I have to say that I'm feeling *very* unhappy about the current
> situation. I have absolutely no clue what to tell my users about how
> to install python-ldap.
>
> - There's no proper stable release since months although the CVS
> tree was pretty stable until a few weeks ago. I suggested to make a
> release before tinkering with the CVS version several times...

>
> - Undocumented OpenLDAP 2.0.x-related patches are floating around
> which actually break existing python-ldap applications.
>

I remember, one day I asked people if we could put the patches to CVS. I still
don't see any harm if we had _partial_ OpenLDAPv2 support in the main branch,
provided it doesn't break anything else. Partial, because there are some API
differences, so often you just can't use same functions for same operations in
OpenLDAPv1 and v2 cases (of course I mean the C API, but the current
python-ldap implementation generally inherits it).
We could even try to stick with a single python-ldap API, no matter whether
it's build with OpenLDAPv1 or v2. But in this case the current python-ldap API
should be changed. The examples are ldap_set_rebind_proc and SSL/TLS-related
calls.
But, in my area of interest (LDAPv3 referrals) API differences between
OpenLDAPv1 and v2 are hidden from a python-ldap user.

>
> I'd really prefer a stable version which builds against OpenLDAP
> 1.2.x, works rock-solid without memory leaks, do not core-dump and
> behaves as documented instead of OpenLDAP 2.0.x-patched version
> which break code and do not have any additional benefits.
>

Michael, if you are talking about my patches, I'd like to help. I made fresh
versions of them (built against the latest CVS version of python-ldap and
OpenLDAP-2.0.11. I tested them with the recent version of web2ldap. Referrals
work like a charm!
I haven't tested the patches against OpenLDAPv1, but I believe they shouldn't
pose any problems. If anybody is interested to check them, I can post them to
the mailing list.

Regards,
    Konstantin.

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

Re: Building python-ldap from CVS against OpenLDAP 1.2.11/12

[Michael <mi...@st...>]

Michael Str=F6der wrote:
> =

> Could someone with autoconf knowledge please have a look into the
> config.log attached? I simply do not understand why this won't work.
> =

> I guess it mainly fails because of this:
> /usr/local/openldap1/lib/libldap.so: undefined reference to
> `__dn_expand'
> /usr/local/openldap1/lib/libldap.so: undefined reference to
> `__res_search'
> /usr/local/openldap1/lib/libldap.so: undefined reference to
> `_getshort'

(Sigh!) I had to link explicitly against libresolv on my
system (S.u.S.E. Linux 7.1 with glibc-2.2).

export "LDFLAGS=3D-lresolv"
=2E/configure

Hmm, I wonder why this worked under 7.0...grrr!

Ciao, Michael.

Building python-ldap from CVS against OpenLDAP 1.2.11/12

[Michael <mi...@st...>]

HI!

Could someone with autoconf knowledge please have a look into the
config.log attached? I simply do not understand why this won't work.

I guess it mainly fails because of this:
/usr/local/openldap1/lib/libldap.so: undefined reference to
`__dn_expand'
/usr/local/openldap1/lib/libldap.so: undefined reference to
`__res_search'
/usr/local/openldap1/lib/libldap.so: undefined reference to
`_getshort'

Ciao, Michael.

Memory leaks with new LDAP API (the one in OpenLDAP 2.x.x)

[Michael <mi...@st...>]

HI!

Find below one more important note about hasty patches for linking
python-ldap against OpenLDAP 2 libs.

Ciao, Michael.

-------- Original Message --------
Subject: Re: Thanx for helping me...
Date: Mon, 25 Jun 2001 12:19:04 +0200
From: Stig Venaas <Sti...@un...>
To: Michael Str=F6der <mi...@st...>

[..]
One more thing. I've realized after looking more at the new
LDAP API (the one in OpenLDAP 2.x.x) that code using the old
API will compile and work just fine with the new API except
for one important thing. There will be memory leaks! So
people should be warned a bit against just using old applications
with OpenLDAP 2.x.x libs perhaps. The reason is changes in the
memory allocation. When using ldap_first_attribute and next
attribute, the attribute string must be freed, and one must also
free the ber structure used by those. Same holds for get_dn or
whatever it's called. I've just been fixing this in PHP.

Stig

ANNOUNCE: new mailing list python-ldap-commits

[David L. <dav...@cs...>]

Announcing a new mailing list on which CVS commits get announced.
I just committed some stuff and it seems to work fine.

	http://lists.sourceforge.net/lists/listinfo/python-ldap-commits

or send 'help' to the email interface at:

	pyt...@li...

I'm using syncmail as recommended by the sf docs.

But I'll probably switch to log_accum (buy David Hampton et al) since
it's output is easier to read.

d

PS If you want to look at how this is done, check out our CVSROOT module, and
look at these files:

	loginfo
	syncmail
	checkoutlist

--
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

.signature: Invalid argument

Re: compiling against OpenLDAP 2.0.11

[Michael <mi...@st...>]

Jens Vagelpohl wrote:
> 
> we have a setup here at digital creations which handles emailing people
> after commits.

David set it up and it seems to work:

http://lists.sourceforge.net/lists/listinfo/python-ldap-commits

Ciao, Michael.

Re: compiling against OpenLDAP 2.0.11

[Jens V. <je...@di...>]

> perhaps a read-only mailing list <python-ldap-cvs> that receives
> emails on commits?  i've found that works pretty good. sf docs don't
> mention anything about how to do it simply though...
>

we have a setup here at digital creations which handles emailing people 
after commits. it's just a couple python scripts. i've used it to do the 
same to my own CVS machine at home.

if bad comes to worse and there is direct access to the repository i'd be 
glad to put it in.

jens

Re: compiling against OpenLDAP 2.0.11

[Rich S. <rs...@zo...>]

> truthfully, i'm hoping for someone to step up and say "I'm doing all
> this good work that would fit well into python-ldap, I'm incorporating it,
> and have time and resources to do a comprehensive release. Give me commit
> access." (anyone?)

C'mon Michael -- go for it.

Re: compiling against OpenLDAP 2.0.11

[David L. <dav...@cs...>]

On Sun, 17 Jun 2001, Michael Str=F6der typed thusly:

> > perhaps a read-only mailing list <python-ldap-cvs> that receives
> > emails on commits?  i've found that works pretty good. sf docs don't
> > mention anything about how to do it simply though...
>
> That's definitely a good idea! I'll try to find out in SF docs.

well after looking one iota harder, i find section 6 of the sf docs that
describes this :)

    <https://sourceforge.net/docman/display_doc.php?docid=3D772&group_id=3D=
1>

d
--=20
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

=2Esignature: Invalid argument

Re: compiling against OpenLDAP 2.0.11

[Michael <mi...@st...>]

David Leonard wrote:
> 
> perhaps a read-only mailing list <python-ldap-cvs> that receives
> emails on commits?  i've found that works pretty good. sf docs don't
> mention anything about how to do it simply though...

That's definitely a good idea! I'll try to find out in SF docs.

Ciao, Michael.

Re: compiling against OpenLDAP 2.0.11

[David L. <dav...@cs...>]

sorry, michael :( it just takes too much time to get all this stuff
organised and done. for me its usually a bit of tinkering on weekends when
i get some time.

truthfully, i'm hoping for someone to step up and say "I'm doing all
this good work that would fit well into python-ldap, I'm incorporating it,
and have time and resources to do a comprehensive release. Give me commit
access." (anyone?)

in my situation, i don't seriously use ldap at all any more, which
is a big problem since I still want to help keep things going. i
can detect some talented and interested people on the list who may
want to do the dedicated work on this - but I can't force them
to..  that's how this open source game seems to work: it's pretty
much supply-driven.

> - It's completely unclear what the status of the current CVS tree
> is. Who really knows?
> - There were no on-list announcements about changes to the CVS tree
> but maybe there were significant changes. Who knows?

perhaps a read-only mailing list <python-ldap-cvs> that receives
emails on commits?  i've found that works pretty good. sf docs don't
mention anything about how to do it simply though...

i may as well commit everything I have in my tree now.. it seems to
be working for openldap2.0.7 and python2.1.. i thought the current
tree was stable, but if its not, then i'll put in what i have and
think is.

> - People ask for building against OpenLDAP 2.0.x libs without having
> enough knowledge about the differences of the APIs.
> - Undocumented OpenLDAP 2.0.x-related patches are floating around
> which actually break existing python-ldap applications.

> I'd really prefer a stable version which builds against OpenLDAP
> 1.2.x, works rock-solid without memory leaks, do not core-dump and

um, why is openldap 1.2.x support still needed?

> behaves as documented instead of OpenLDAP 2.0.x-patched version
> which break code and do not have any additional benefits.

if you want to create a cvs branch of the last release and incorporate
the various patches etc, and build releases on compile.sf, please feel
free to do so. you can find some of my attempts and maybe some
helpful notes in ~leonard/.

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

.signature: Invalid argument

Re: compiling against OpenLDAP 2.0.11

[\(::\) B. I. <bo...@re...>]

Quoting Michael Ströder <mi...@st...>:

> David Leonard wrote:
> > 
> > the current status of the development tree seems to be:
> >         * removing autoconf, in favour of python's distutils
> >           (which is weaker at detecting what is there but slightly
> more
> >            configurable and supposedly easier to build distributions
> with)
> >         * supporting OpenLDAP 2.* (but dropping support for earlier 
> >           versions)
> 
> I have to say that I'm feeling *very* unhappy about the current
> situation. I have absolutely no clue what to tell my users about how
> to install python-ldap.

Are you paying for the development of python-ldap?  Don't whine, it doesn't 
encourage people to give you stuff.  I feel sorry for "your users".  Anyways, 
dropping support for old APIs isn't a terrible idea, people don't change APIs 
because it's fun, they typically do it for a pretty good reason.


> 
> - There's no proper stable release since months although the CVS
> tree was pretty stable until a few weeks ago. I suggested to make a
> release before tinkering with the CVS version several times...

checkout an older version.  what do you think cvs is for?

> 
> - It's completely unclear what the status of the current CVS tree
> is. Who really knows?

I just managed to compile it and have it working with python 2.1 and openldap 
2.0.x.. all I had to do was make a change in setup.py to make it use normal 
dicts instead.  hasn't crashed yet (but i admit I've only been using it for 
like 10 hours, and never doing more than one search per connection).

> 
> - There were no on-list announcements about changes to the CVS tree
> but maybe there were significant changes. Who knows?
> 
> - People ask for building against OpenLDAP 2.0.x libs without having
> enough knowledge about the differences of the APIs.
> 
> - Undocumented OpenLDAP 2.0.x-related patches are floating around
> which actually break existing python-ldap applications.
> 
> I'd really prefer a stable version which builds against OpenLDAP
> 1.2.x, works rock-solid without memory leaks, do not core-dump and
> behaves as documented instead of OpenLDAP 2.0.x-patched version
> which break code and do not have any additional benefits.

so checkout an older version that you recall working well and fix the bugs 
yourself..  create your own python-ldap branch

> 
> I'm seriously considering switching to another LDAP programming
> platform.

so do it, perl has a decent and working interface last I used it.  but be 
productive, whining is *not* productive.

(::) bob

Re: compiling against OpenLDAP 2.0.11

[Michael <mi...@st...>]

David Leonard wrote:
> 
> the current status of the development tree seems to be:
>         * removing autoconf, in favour of python's distutils
>           (which is weaker at detecting what is there but slightly more
>            configurable and supposedly easier to build distributions with)
>         * supporting OpenLDAP 2.* (but dropping support for earlier 
>           versions)

I have to say that I'm feeling *very* unhappy about the current
situation. I have absolutely no clue what to tell my users about how
to install python-ldap.

- There's no proper stable release since months although the CVS
tree was pretty stable until a few weeks ago. I suggested to make a
release before tinkering with the CVS version several times...

- It's completely unclear what the status of the current CVS tree
is. Who really knows?

- There were no on-list announcements about changes to the CVS tree
but maybe there were significant changes. Who knows?

- People ask for building against OpenLDAP 2.0.x libs without having
enough knowledge about the differences of the APIs.

- Undocumented OpenLDAP 2.0.x-related patches are floating around
which actually break existing python-ldap applications.

I'd really prefer a stable version which builds against OpenLDAP
1.2.x, works rock-solid without memory leaks, do not core-dump and
behaves as documented instead of OpenLDAP 2.0.x-patched version
which break code and do not have any additional benefits.

I'm seriously considering switching to another LDAP programming
platform.

Ciao, Michael.

Re: compiling against OpenLDAP 2.0.11

[David L. <dav...@cs...>]

On Fri, 15 Jun 2001, Jens Vagelpohl typed thusly:

> can anyone confirm what the status is vis-a-vis OpenLDAP 2.x (or just 2.0.
> 11)? the postings led me to believe that no extra patches were needed at
> this point. if they are, can someone point them out? :)

python-ldap 1.10a3 won't work with OpenLDAP 2.x unless you apply those patches
that you refer to. (is that right?)

the current status of the development tree seems to be:
	* removing autoconf, in favour of python's distutils
	  (which is weaker at detecting what is there but slightly more
	   configurable and supposedly easier to build distributions with)
	* supporting OpenLDAP 2.* (but dropping support for earlier versions)

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

.signature: Invalid argument

Re: core dump / Objects/dictobject.c:471: bad argument to internal function

[David L. <dav...@cs...>]

On Sat, 16 Jun 2001, (::) Bob Ippolito typed thusly:
> I got it to work.. what I had to do was turn off CIDict.. like this in setup.py
>
> > ActivePython 2.1, build 210
> > SystemError: Objects/dictobject.c:471: bad argument to internal
> > function
> > Segmentation fault (core dumped)

my lazily written CIDict module worked by copying the python dict type
and then 'patching' it so that it lowercased its keys. Python (2.0?)
seems to check that the objects being passed back are really dicts, and
so thats why you get an internal error.. which leads later to a core dump.

i've rewritten cidict to get rid of that ugly hack... the patch below
indicates what i've done .. i haven't committed (or compiled) it yet
because i am re-installing python2.1 on this machine at the moment.
i just wanted to let you know that i'll try and get it tested and fixed
today because its so awful.

and if anyone wants to run their eye over it for memory leaks, please do :)

d

Index: functions.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/functions.c,v
retrieving revision 1.4
diff -u -r1.4 functions.c
--- functions.c	2000/08/17 23:50:28	1.4
+++ functions.c	2001/06/17 04:39:31
@@ -10,6 +10,7 @@
 #include "LDAPObject.h"
 #include "errors.h"
 #include "template.h"
+#include "CIDict.h"

 /* ldap_open */

@@ -131,6 +132,16 @@
 "\tThis function returns true if url `looks like' an LDAP URL\n"
 "\t(as opposed to some other kind of URL).";

+#if defined(USE_CIDICT)
+static PyObject *
+cidict(PyObject *unused, PyObject *args)
+{
+	if (!PyArg_NoArgs(args))
+		return NULL;
+	return CIDict_New();
+}
+#endif
+
 /* methods */

 static PyMethodDef methods[] = {
@@ -146,6 +157,11 @@
     { "init_templates", (PyCFunction)l_init_templates,		METH_VARARGS,
     	l_init_templates_doc },
 #endif
+#if defined(USE_CIDICT)
+    { "cidict",		(PyCFunction)cidict,			METH_VARARGS,
+    	NULL },
+#endif
+
     { NULL, NULL }
 };

Index: CIDict.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/CIDict.c,v
retrieving revision 1.4
diff -u -r1.4 CIDict.c
--- CIDict.c	2001/05/12 08:08:39	1.4
+++ CIDict.c	2001/06/17 04:39:33
@@ -23,13 +23,18 @@
  * XXX I forget whose idea this originally was, but its a good one. - d
  */

+typedef struct {
+	PyObject_HEAD
+	PyObject *dict;
+} CIDictObject;
+
 /*
  * Return a new object representing a lowercased version of the argument.
  * Typically this is a string -> string conversion.
  * Returns: New Reference
  */
 static PyObject *
-case_insensitive(PyObject *o)
+lowercase(PyObject *o)
 {
 	char *str, *cp;
 	int len, i;
@@ -55,74 +60,146 @@
 	return s;
 }

-/* read-access the dictionary after lowercasing the subscript */
-
 static PyObject *
-cid_subscript(PyObject *d, PyObject *k)
+subscript(CIDictObject *self, PyObject *k)
 {
 	PyObject *ret;
 	PyObject *cik;

-	cik = case_insensitive(k);
-	ret = (*PyDict_Type.tp_as_mapping->mp_subscript)(d, cik);
-	Py_XDECREF(cik);
+	cik = lowercase(k);
+	if (cik == NULL)
+		return NULL;
+	ret = PyObject_GetItem(self->dict, cik);
+	Py_DECREF(cik);
 	return ret;
 }
+
+static int
+length(CIDictObject *self)
+{
+	return PyMapping_Length(self->dict);
+}

-/* write-access the dictionary after lowecasing the subscript */

 static int
-cid_ass_subscript(PyObject *d, PyObject *k, PyObject *v)
+ass_subscript(CIDictObject *self, PyObject *k, PyObject *v)
 {
 	int ret;
 	PyObject *cik;

-	cik = case_insensitive(k);
-	ret = (*PyDict_Type.tp_as_mapping->mp_ass_subscript)(d, cik, v);
-	Py_XDECREF(cik);
+	cik = lowercase(k);
+	if (cik == NULL)
+		return -1;
+	ret = PyObject_SetItem(self->dict, cik, v);
+	Py_DECREF(cik);
 	return ret;
 }

-/* This type and mapping structure gets filled in from the PyDict structs */
-
-static PyMappingMethods CIDict_mapping;
-PyTypeObject CIDict_Type;
+static void
+dealloc(CIDictObject *self)
+{
+	Py_DECREF(self->dict);
+	PyMem_DEL(self);
+}

-/* Initialise the case-insensitive dictionary type */
+static int
+print(CIDictObject *self, FILE *fp, int flags)
+{
+	return PyObject_Print(self->dict, fp, flags);
+}

-static void
-CIDict_init()
+PyObject *
+getattr(CIDictObject *self, char *attr_name)
+{
+	return PyObject_GetAttr(self->dict, attr_name);
+}
+
+static int
+compare(CIDictObject *self, PyObject *o)
+{
+	PyObject *lo = NULL;
+	PyObject *oitems = NULL;
+	PyObject *key = NULL;
+	PyObject *item = NULL;
+	int len, i, ret = -1;
+
+	if (!PyMapping_Check(o))
+		return PyObject_Compare(self->dict, o);
+
+	/* Create equivalent dictionary with lowercased keys */
+	if ((lo = PyDict_New()) == NULL)
+		goto done;
+	if ((oitems = PyMapping_Items(o)) == NULL)
+		goto done;
+	len = PyObject_Length(oitems);
+	for (i = 0; i < len; i++) {
+		Py_XDECREF(item);
+		if ((item = PySequence_GetItem(oitems, i)) == NULL)
+			goto done;
+		Py_XDECREF(key);
+		if ((key = lowercase(PyTuple_GET_ITEM(item, 0))) == NULL)
+			goto done;
+		PyMapping_SetItem(key, PyTuple_GET_ITEM(item, 1));
+	}
+	ret = PyObject_Compare(self->dict, lo);
+    done:
+	Py_XDECREF(key);
+	Py_XDECREF(item);
+	Py_XDECREF(oitems);
+	Py_XDECREF(lo);
+	return ret;
+}
+
+static PyObject *
+repr(CIDictObject *self)
 {
-	/*
-	 * Duplicate the standard python dictionary type,
-	 * but override the subscript accessor methods
-	 */
-	memcpy(&CIDict_Type, &PyDict_Type, sizeof CIDict_Type);
-	CIDict_Type.tp_name = "cidictionary";
-	CIDict_Type.tp_as_mapping = &CIDict_mapping;
-
-	memcpy(&CIDict_mapping, PyDict_Type.tp_as_mapping,
-		sizeof CIDict_mapping);
-	CIDict_mapping.mp_subscript = cid_subscript;
-	CIDict_mapping.mp_ass_subscript = cid_ass_subscript;
+	return PyObject_Repr(self->dict);
 }

+static PyMappingMethods as_mapping = {
+	length, 			/* mp_length */
+	subscript, 			/* mp_subscript */
+	ass_subscript			/* mp_ass_subscript */
+};
+
+PyTypeObject CIDict_Type = {
+#if defined(WIN32) || defined(__CYGWIN__)
+	/* see http://www.python.org/doc/FAQ.html#3.24 */
+	PyObject_HEAD_INIT(NULL)
+#else /* ! WIN32 */
+	PyObject_HEAD_INIT(&PyType_Type)
+#endif /* ! WIN32 */
+	"cidictionary",			/* tp_name */
+	sizeof (CIDictObject),		/* tp_basicsize */
+	0,				/* tp_itemsize */
+	(destructor)dealloc,		/* tp_dealloc */
+	(printfunc)print,		/* tp_print */
+	(getattrfunc)getattr,		/* tp_getattr */
+	NULL,				/* tp_setattr */
+	(cmpfunc)compare,		/* tp_compare */
+	(reprfunc)repr,			/* tp_repr */
+	NULL,				/* tp_as_number */
+	NULL,				/* tp_as_sequence */
+	&as_mapping,			/* tp_as_mapping */
+};
+
 /* Create a new case-insensitive dictionary, based on PyDict */

 PyObject *
 CIDict_New()
 {
-	PyObject *mp;
-	static int initialised = 0;
+	CIDictObject *o;
+	PyObject *dict;

-	if (!initialised) {
-		CIDict_init();
-		initialised = 1;
-	}
-
-	mp = PyDict_New();
-	mp->ob_type = &CIDict_Type;
-	return (mp);
+	dict = PyDict_New();
+	if (dict == NULL)
+		return NULL;
+	o = PyObject_NEW(CIDictObject, &CIDict_Type);
+	if (o == NULL)
+		Py_DECREF(dict);
+	else
+		o->dict = dict;
+	return o;
 }

 #endif /* USE_CIDICT */
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

.signature: Invalid argument

Re: core dump / Objects/dictobject.c:471: bad argument to internal function

[\(::\) B. I. <bo...@re...>]

I got it to work.. what I had to do was turn off CIDict.. like this in setup.py

line 16: defines =       [#-- ('USE_CIDICT', None),

it fixed both modes (I guess they're called synchronous and asynchronous?).. no 
more SystemError or core dump.


Quoting "(::) Bob Ippolito" <bo...@re...>:

> I'm having a problem using python-ldap (redhat linux).
> 
> ActivePython 2.1, build 210
> OpenLDAP 2.0.11
> 
> This is with the latest CVS version of python-ldap.. 1.10alpha3 wouldn't
> 
> compile with OpenLDAP 2.0.11, I haven't found the patch to try it.
> 
> Any ideas?  I've tried using different values for bind and search, and
> it 
> worked fine if I issued a search that doesn't have any results.. but any
> search 
> that has results gets that dictobject error, or just core dumps!
> 
> (from the interpreter)
> 
> >>> import _ldap
> >>> l=_ldap.open("localhost")
> >>> l.simple_bind_s("","")
> >>> l.search_s("",0,"objectclass=*")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> SystemError: Objects/dictobject.c:471: bad argument to internal
> function
> >>> l.search("",0,"objectclass=*")
> 3
> >>> print l.result(3)
> Segmentation fault (core dumped)
> 
> It's a weird install of redhat, and I haven't been using RPM's.. so I
> don't 
> want to try one.  I just want to compile it myself and have it work.
> 
> (::) bob
> 
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> 



(::) bob

core dump / Objects/dictobject.c:471: bad argument to internal function

[\(::\) B. I. <bo...@re...>]

I'm having a problem using python-ldap (redhat linux).

ActivePython 2.1, build 210
OpenLDAP 2.0.11

This is with the latest CVS version of python-ldap.. 1.10alpha3 wouldn't 
compile with OpenLDAP 2.0.11, I haven't found the patch to try it.

Any ideas?  I've tried using different values for bind and search, and it 
worked fine if I issued a search that doesn't have any results.. but any search 
that has results gets that dictobject error, or just core dumps!

(from the interpreter)

>>> import _ldap
>>> l=_ldap.open("localhost")
>>> l.simple_bind_s("","")
>>> l.search_s("",0,"objectclass=*")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Objects/dictobject.c:471: bad argument to internal function
>>> l.search("",0,"objectclass=*")
3
>>> print l.result(3)
Segmentation fault (core dumped)

It's a weird install of redhat, and I haven't been using RPM's.. so I don't 
want to try one.  I just want to compile it myself and have it work.

(::) bob

Re: compiling against OpenLDAP 2.0.11

[Joe L. <jl...@op...>]

I answered this to Jens..

The problem is with the inclusion of ssl silently into MacOSX builds of 
OpenLDAP. He had to rebuild OpenLDAP --without-tls or to add -lssl to 
that lines.

second, its not a shared library, so you need to have _ldapmodule.so 
build with the libraries as objects (full path to libldap.a etc)

On Friday, June 15, 2001, at 05:16  PM, Daniel Schlenzig wrote:

> On Fri, Jun 15, 2001 at 11:29:57AM -0400, Jens Vagelpohl wrote:
>
>> a couple days ago there were some posts indicating that python-ldap 
>> does
>> indeed build against 2.0.11.
>>
>> i just tried building a python-ldap head CVS checkout against 2.0.11 
>> and
>> it stops with the well-known...
>>
>> <snip>
>> checking for library containing ber_free... -llber
>> checking for library containing ldap_open... no
>> checking for ldap_open... no
>> configure: error: Couldn't find LDAP library
>> </snip>
> When I first tried to compile python-ldap it behaved exactly like this.
> Actually I do have a workaround, but it is not anchored in the autoconf
> scripts, so you have to do it by hand.
>
> --- cut from the logs ---
>
> I startet vi on configure, skipped to line 1403 and replaced
>
> LIBS="$ac_func_search_save_LIBS"
>
> with
>
> LIBS="$ac_func_search_save_LIBS -lldap -lresolv"
>
> After rerunning configure and make everything worked as it should.
>
> --- cut ---
>
> This should do. libldap.so is after that recognized as "not needed", but
> do not worry about, because it still links correctly.
>
> bye, Daniel
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: compiling against OpenLDAP 2.0.11

[Daniel S. <da...@ma...>]

On Fri, Jun 15, 2001 at 11:29:57AM -0400, Jens Vagelpohl wrote:

> a couple days ago there were some posts indicating that python-ldap does 
> indeed build against 2.0.11.
> 
> i just tried building a python-ldap head CVS checkout against 2.0.11 and 
> it stops with the well-known...
> 
> <snip>
> checking for library containing ber_free... -llber
> checking for library containing ldap_open... no
> checking for ldap_open... no
> configure: error: Couldn't find LDAP library
> </snip>
When I first tried to compile python-ldap it behaved exactly like this.
Actually I do have a workaround, but it is not anchored in the autoconf
scripts, so you have to do it by hand.

--- cut from the logs ---

I startet vi on configure, skipped to line 1403 and replaced

LIBS="$ac_func_search_save_LIBS"

with

LIBS="$ac_func_search_save_LIBS -lldap -lresolv"

After rerunning configure and make everything worked as it should.

--- cut ---

This should do. libldap.so is after that recognized as "not needed", but
do not worry about, because it still links correctly.

bye, Daniel

Re: compiling against OpenLDAP 2.0.11

[Jens V. <je...@di...>]

joe,

> well, the patches are now a part of my RPM at open-it.org (Thanks to 
> Michael and Konstantin). I haven't been able to get an unpatched version 
> to compile either. David has his own tree which he indicated does compile 
> against 2.x, but I am unsure if/when that may be added to the main tree. 
> Some people like to stick w. 1.x for stability and completeness, others 
> just want 2.0. :)

unfortunately, RPM is of no help to me. i am trying to set it up so i can 
do development work on the Zope LDAPLoginAdapter and LDAPUserManager on my 
OS X-based powerbook while i'm abroad. i would need patches for the source,
  i already got OpenLDAP 2.0.11 running successfully.

and no, this is not a combo i would use for "production", it's just so i 
can work away from my development servers ;)


> Separately, email me directly. I've been playing around with ZopeLDAP and 
> jshell hasn't answered back. Maybe you can clue me in to the status of 
> all things LDAP in regards to Zope. (I'm most interested in documentation 
> of current ZClass integration, etc)

ZopeLDAP development has pretty much ended. jeffrey hasn't worked on it in 
a while and us unwilling (and has no time) to continue it. if i had time i 
would consider keeping it alive, but at this point i really don't.

there is a couple other LDAP products for zope that i know of:

- LDAPLoginAdapter: my own product. active development, will be combined 
with the LDAPUserManager into a single LDAPUserFolder product at some point

- LDAPUserManager: my own product. active development, will be combined 
with the LDAPLoginAdapter into a single LDAPUserFolder at some point

- LDAPAdapter: ross lazarus' and soren roug's LDAP-based user folder. i 
think development has pretty much ended.

i do not know about any ZClass integration. i personally do not use 
ZClasses at all, only file system-based python products.

jens

Re: compiling against OpenLDAP 2.0.11

[Joe L. <jl...@op...>]

well, the patches are now a part of my RPM at open-it.org (Thanks to 
Michael and Konstantin). I haven't been able to get an unpatched version 
to compile either. David has his own tree which he indicated does 
compile against 2.x, but I am unsure if/when that may be added to the 
main tree. Some people like to stick w. 1.x for stability and 
completeness, others just want 2.0. :)

Separately, email me directly. I've been playing around with ZopeLDAP 
and jshell hasn't answered back. Maybe you can clue me in to the status 
of all things LDAP in regards to Zope. (I'm most interested in 
documentation of current ZClass integration, etc)


On Friday, June 15, 2001, at 08:29  AM, Jens Vagelpohl wrote:

> hi guys,
>
> a couple days ago there were some posts indicating that python-ldap 
> does indeed build against 2.0.11.
>
> i just tried building a python-ldap head CVS checkout against 2.0.11 
> and it stops with the well-known...
>
> <snip>
> checking for library containing ber_free... -llber
> checking for library containing ldap_open... no
> checking for ldap_open... no
> configure: error: Couldn't find LDAP library
> </snip>
>
> can anyone confirm what the status is vis-a-vis OpenLDAP 2.x (or just 
> 2.0.
> 11)? the postings led me to believe that no extra patches were needed 
> at this point. if they are, can someone point them out? :)
>
> jens
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>